4 ms·

This. You _have_ to write the spec. The result is that instead of spending X units of time on spec and THEN y units of time on coding, you get the whole thing i

by fsloth 1y ago

This. You _have_ to write the spec. The result is that instead of spending X units of time on spec and THEN y units of time on coding, you get the whole thing in x units of time AND you have a spec. The trick is knowning where the particular LLM sucks. I expect in a short amount of time there is no productivity gain but when you start to understand the limitations and strengths - holey moley.

skydhash 1y ago
> The result is that instead of spending X units of time on spec and THEN y units of time on coding, you get the whole thing in x units of time AND you have a spec. It's more like x units of time thinking and y units of times coding, whereas I see people spend x/2 thinking, x typing the specs, y correcting the specs, and y giving up and correcting the code.
- fsloth 1y ago
  Sure! That's inefficient. I know just how I work and I've been writing the type of programs I do for quite many years. And I know what would take me normally a week takes me few days at best.
- nicce 1y ago
  But if you can’t define the specs, you can’t write the code without LLM either?
smsm42 1y ago
Unless you realize no LLM is good at what you need and you just wasted weeks of time walking in circles.
- fsloth 1y ago
  If you notice only after two weeks the project is off-kilter I would guess the chance of that happening without an LLM is not low either. These are not _tools_ -they are like cool demos. Once you have a certain mass of functional code in place, intuition - that for myself required decades of programming to develop - kicks in and you get these spider sense tinglings ”ahh umm this does not feel right, something’s wrong”. My advice would be don’t use LLM until you have the ”spider-sense” level intuition.