I find it's great for very generic work, like boilerplate or where you have forgotten how to implement a specific single, well defined algorithm. However, relying on its output is very risky if you aren't verifying everything it puts out. A good test to show this is to ask it to write a short essay on something you know very well, then behold all the incorrect information it enthusiastically tries to feed you.
Also:
* It has a horrible habit of inventing properties on objects or methods in libraries.
* It will very happily straight up lie to you about things it does
* Often when you ask it to make a specific change, it will give you back exactly the same as last time.
* For the love of God, don't put any company-owned code into it.
Making an LLM explain parts of new code I don't understand has taught me a lot of useful new tricks and methods.
It's own code output will generally work for things that have been done before, but quickly fall apart when you are trying to create something new. You'll need to write a lot of pseudo code to make that work, which is actually excellent training as well.
It really does help if you instruct the language model to be honest and to not do it's very best to please you.
I have not found a solution to the repeating incorrect answer loop yet, although some environments offer a "banned response" list, that can mitigate the situation a bit.
As to the OPs question, yes, definitely use it! But more importantly, learn how to use it. Your approach sounds reasonable and similar to mine. Companies that ban the use of LLMs or developers that scoff at it's benefits are delusional.
Something that is easier to use might come eventually, but in the short term future I expect we will see a clear separation between developers with strong grammatical skills who have learned how to prompt and those without the ability or the experience.
Love that channel and the message that with a small amount of effort and skill you can make excellent dishes 1000% better (and probably healthier) than the pre-packaged version. You don't need the most expensive cuts, or a home made demi-glace, just solid fundamentals with common ingredients.
The most bizarre coffee I've ever had was from the Papua New Guinea Baroida Estate. STRONG tasting notes of tomato. I thoroughly enjoyed it, but I love weird flavours like that. Very interesting coffee.
I'm drinking some Papua New Guinea right now that I roasted myself, it's dry processed like many Ethiopian coffees are, and it tastes like berries and spice. The different origin flavors that can be found through different processing methods and soil conditions are amazing. There's so much variety. As a hobby roaster I value my relationship with coffee too much to deliberately drink bad stuff.
Unfortunately there are some major issues with your website that really turn me off or rub me the wrong way here. Please don't take this criticism the wrong way - this is entirely in good faith (I promise).
Firstly: I hate being presented with a 'sign up' screen when I click get started. At that point I have no idea if the product is a good fit for me. I don't necessarily want to give you my data.
Speaking of data - how do you handle my data or my customers' data if I choose to collect it? The privacy policy link doesn't go anywhere. What is your cookie policy and where can I opt in and out?
Why would I use Daspoll over something like SurveyMonkey, which is widely established in the industry? I'm not really sure what unique features you offer from what's on the homepage.
I would probably replace the 'why surveys' and 'example use cases' section with something that sells Daspoll specifically more. If I'm looking for survey software, I know I want survey software, and I know my usecase - you need to convince me to pick Daspoll over the alternatives. And you REALLY need to convince me if you want me to spend money to get more than 5 responses per survey!!
There are a few questionable UI decisions on your homepage, such as some of the content going right to the edge of the page, or the survey image in the CTA being cut off mid-question. Also, you have misspelled 'survey' in the description of the free tier, as well as 'doesn't required a credit card' in the CTA.
Also if you click the daspoll logo at the top left, it takes you to a blank page. This may be because I've not signed up.
--
On to what I like:
Having an easy way to set up a no code survey builder that's an alternative to the big boys is great! If it's super simple to smash together an anonymous survey that's not gonna give me 30458309 tracking cookies and loads of JS bloat, then amazing, I'd use it.
If the templates are good, then you probably save a lot of time.
--
It could be good if you play on the 'ease of creation' angle, and provide a more mature product, but it feels incomplete, more attention to detail on the UI/Layout, and I don't really know what the advantages of your product are.
Equity is a fascinating and complex/weird body of law, and estoppel is a great introduction to it. For anyone interested in learning more, a good starting point is learning about the maxims of equity and their applications in real property.
In practice, because they don't work the way most people think they work, and because it's really easy to screw up using them.
Hooks are called every render, which is a relatively transparent process that happens all of the time. All hooks have to be called every render, otherwise you're breaking the rules of hooks. The reason why is because the only way hooks know which hook they even are, is the order in which you call them.
For example, if I have
const a = useRef(true);
const b = useRef(false);
The only way react knows that the first value it should return the next time it renders is what I'm expecting to be value `a` is because that useRef is called first every render. These are all kinds of rules and assumptions about hooks that make them not behave at all like normal functions. I don't think people understand that, for useRef, for example, those two lines of code are run every render, passing in the initial starting values, which then react disregards after the initial render, and maintains a mapping of ref and state and memo etc values all by the order the hooks are called in. I see people use hooks in callbacks all of the time and just fundamentally not understand that they're doing it wrong.
Then there are all of the closure problems with useEffect and useCallback that I see people really struggle with.
And useState...lordie. The fact that it defers setting the state value, whereas useRef will immediately have its value updated. Deferring useState has caused so many bugs.
I don't like them because they hide program state in innocuous-seeming function calls. Want to call useContext in a helper? It'll work, until it doesn't. Want to display a loading spinner? You'd better not have any useState calls below it. Want to see what hooks a function will use? You have to run it or go through each line of every piece of code it calls, they're not in any way declarative.
The programming paradigms I like best are declarative and make invalid or undefined behaviour impossible to represent. Hooks do the opposite: they're procedural, make it very easy to write a program that compiles with subtle errors, and don't have compile time checks to stop bad code.
Also:
* It has a horrible habit of inventing properties on objects or methods in libraries.
* It will very happily straight up lie to you about things it does
* Often when you ask it to make a specific change, it will give you back exactly the same as last time.
* For the love of God, don't put any company-owned code into it.
* Maybe I'm just bad at prompting...