That's weird, I'm the opposite. Previously I would start coding immediately, because writing the code helps me figure out the what and the how, and because I'd end up with modular/reusable bits that will be helpful later anyway.

Now I sit on an idea for a long time, writing documentation/specs/requirements because I know that the code generation side of things is automated and effortlessly follows from exhaustive requirements.

I used to do this, but found scoping my agent usage down to smaller chunks got better results than trying to do it all from the get go. And looking back it makes sense - code is the most expressive form we have to tell the computer what to do, not English.

The size of the chunk varies heavily on what I’m doing ofc.

How to do that for a complex greenfield project? Do you scope out just one module and let the agent code only that, with the intention of reusing that module later in the full project?

>With agentic development, I have an idea, waste a few hours chasing it, then switch to other work, often abandoning the thing entirely.

How much of this is because you don't trust the result?

I've found this same pattern in myself, and I think the lack of faith that the output is worth asking others to believe in is why it's a throwaway for me. Just yesterday someone mentioned a project underway in a meeting that I had ostensibly solved six months ago, but I didn't even demo it because I didn't have any real confidence in it.

I do find that's changing for myself. I actually did demo something last week that I 'orchestrated into existence' with these tools. In part because the goal of the demo was to share a vision of a target state rather than the product itself. But also because I'm much more confident in the output. In part because the tools are better, but also because I've started to take a more active role in understanding how it works.

Even if the LLMs come to a standstill in their ability to generate code, I think the practice of software development with them will continue to mature to a point where many (including myself) will start to have more confidence in the products.

If you do not know what you want to build, how to ask the AI what you want and are unable to tell what the correct requirements are; then it becomes a waste of time and money.

More importantly, As the problem becomes more complex, it then matters more if you know where the AI falls short.

Case study: Security researchers were having a great time finding vulnerabilities and security holes in Openclaw.

The Openclaw creators had a very limited background in security even when the AI entirely built Openclaw and the authors had to collaborate with the security experts to secure the whole project.

> If you do not know what you want to build

That describes the majority of cases actually worth working on as a programmer in the traditional sense of the word. You build something to begin to discover the correct requirements and to picture the real problem domain in question.

> You build something to begin to discover the correct requirements and to picture the real problem domain in question.

That's one way, another way is to keep the idea in your head (both actively and "in the background) for days/weeks, and then eventually you sit down and write a document, and you'll get 99% of the requirements down perfectly. Then implementation can start.

Personally I prefer this hammock-style development and to me it seems better at building software that makes sense and solves real problems. Meanwhile "build something to discover" usually is best when you're working with people who need to be able to see something to believe there is progress, but the results are often worse and less well-thought out.

This.

It's better to have a solid concrete idea written down of the entire system that you know you want to build which has ironed out the limitations, requirements and the constraints first before jumping into the code implementation or getting the agent to write it for you.

The build-something-to-discover approach is not for building robust solutions in the long run. By starting with the code first without knowing what it is you are solving or just getting the AI to generate something half-working but breaks easily and changing it once again for it to become even more complicated just wastes more time and tokens.

Someone still has to read the code and understand why the project was built on a horrible foundation and needs to know how to untangle the AI vibe-coded mess.

> You build something to begin to discover the correct requirements and to picture the real problem domain in question.

You lose that if the agent builds it for you, though; there is no iteration cycle for you, only for the agent. This means you are missing out on a bunch of learning that you would previously had gotten from actually writing something.

Prior to agents, more than once a week I'd be writing some code and use some new trick/technique/similar. I expect if you feel that there is no programming skills and tricks left for you to learn, then sure, you aren't missing out on anything.

OTOH, I've been doing this a long time, and I still learn new things (for implementation, not design) on each new non-trivial project.

> With agentic development, I have an idea, waste a few hours chasing it, then switch to other work, often abandoning the thing entirely.

My experience with LLMs is that they will call any idea a good idea, one feasible enough to pursue!

Their training to be a people-pleaser overrides almost everything else.

it might depend how you word it, i specifically asked about a caldav and a firefox sync solution, explaining how much difficulty-adverse i was, and i have been berated both times

> Previously, I'd have an idea, sit on it for a while.

> With agentic development, I have an idea, waste a few hours chasing it,

What's the difference between these 2 periods? Weren't you wasting time when sitting on it and thinking about your idea?

Sitting on an idea doesn’t have to mean literally sitting and staring at the ceiling, thinking about it. It means you have an idea and let it stew for a while, your mind coming back to it on its own while you’re taking a shower, doing the dishes, going for a walk… The idea which never comes back is the one you abandon and would’ve been a waste of time to pursue. The idea which continues to be interesting and popping into your head is the worthwhile one.

When you jump straight into execution because it’s easy to do so, you lose the distinction.

They for sure weren't vaporating hundreds of litres of water and wasting a bunch of electricity while doing it

Sitting on an idea doesn't necessarily mean being inactive. You can think at the same time as doing something else. "Shower thoughts" are often born of that process.

I know, and letting an agent/LLM "think" about some ideas does not waste your time either. Yes, it "wastes" energy and you need to read and think about the results after, we don't have neural interfaces to computer, so the inner thinking feedback loop will always be faster. But I keep thinking GP comment was unfair: you can just have your idea in the background to check whether it is good or not exactly the same, and after that time "discuss" it with an LLM, or ask it to implement the idea because you think it's solid enough. It's a false dichotomy.

It's not a complaint about LLMs, it's a complaint about my own behaviour. Maybe I didn't make that clear enough.

Maybe like one of the siblings said, I just shouldn't jump right into execution even if that barrier has been lowered. But it sure is tempting for me.

I understand you, and I felt the same for a few days: the dopamine rush was hitting hard. You just need to control it (with a very big "just"), like any other dopamine rush.

with agentic development, I've finally considered doing open source work for no reason aside from a utility existing

before, I would narrow things down to only the most potentially economically viable, and laugh at ideas guys that were married to the one single idea in their life as if it was their only chance, seemingly not realizing they were competing with people that get multiple ideas a day

back to the aforementioned epiphany, it reminds me of the world of Star Trek where everything was developed for its curiosity and utility instead of money