[stillpointlab]

My experience is that I am bottle-necked on specs. The agent loop is less of a thing for me now.

If I can get a clear understanding of what I want to build, communicate that to Claude Code in planning mode with the goal to write an actionable spec (not code, plan to write the spec) then I tend to get very good results once the agent goes to implement.

But this strategy, while effective, puts a big load on me to write the specs. The agent tends to knock each one out of the park (usually 2 to 3 follow ups based on code review) but then I'm back at the stage that requires the spec.

Another issue for me is that when I step away, if the agent finishes a task and could technically start on an existing spec (no overlap on files so no conflict possible) it doesn't know it can just create a new branch and start. Before I go to bed I'll often say "do task X and once done and pushed start on task Y". But I haven't had luck beyond that. Often I find that it starts on Y and has a question and then the agent is idle the rest of the time.

The final issue is dependency coupled with the above. For example, today I was writing a background job processor. Obviously, the jobs that are in subsequent tasks require the system. That happens with some frequency. Even the specs need to be refreshed after the implementation to take any details that were resolved at coding time into account.

But I am just on the cusp of wanting the outer loop. The gate is almost entirely on spec creation and PR review. In places where those gates don't matter, I want the agent to keep chugging away.

As an aside, I strongly believe we need to start using tools that are better for LLMs even if they are worse for us. For example, Rust is annoying because the compiler is so strict. Bad for me, great for LLMs.

[jschveibinz]

This is exactly the way it should be! This is great! This is the most important part of engineering of systems that has been minimized over the past two decades in the rush to build. Now that the building is more automated, the specifications and system design can take the important lead again. Engineering and quality might be back!

[stillpointlab]

One thesis I am developing is that LLMs have given us a new kind of tradeoff. We can use the intelligence and tremendous speed up that mechanically pumping out basic CRUD code has given and we can either deliver more features or deliver higher quality.

What that means to me is that there is a balance. My belief is that we have to take some of the new power and put it towards quality rather than spend it all on speed.

[npodbielski]

Do you really believe that? If I would be employer or manager of developers saying that they need to carefully design whole system for the agent to implement, so not a technical person, it would look like their are buying their time.

I believe that it will be the case. 'What design?! Just feed Jira ticket and business documentation to Claude and quit stalling!!'

[wonnage]

Joke’s on you, Claude is writing that too

[cognitiveinline]

Why's it a joke, looks like quality and good engineering will be faster for what we build and maintain.

[hatthew]

This matches my experience coding, and the expectations I (and many other) have been voicing for years about why AI is still a ways away from solving coding. The hard part of programming isn't pressing the keys to put code into a file, it's understanding the problem and coming up with a good, clean, extensible solution. AI is great at making ok solutions that technically work, but pretty bad at having a good vision for a solution. AI is still very useful for bouncing ideas off of and exploring to create a better understanding, but writing a good spec for an LLM to implement isn't much easier than just writing the code yourself.

[chairmansteve]

> I tend to get very good results

How do you define the good result? Does the definition of success include clean, maintainable code? I am finding I need to be in the loop. My code ships to thousands of users, so any issues get amplified.

[godelski]

Last time I saw one of these conversations on HN that was the key question.

What people disagreed on was what's good, or what's even good enough. I don't think that's a new thing but it's becoming far more apparent in the age of AI.

I'll make the claim, a demo is easy to make. But it's far from a minimum viable product. A demo is *maybe* 10% of the work. But for some people I know (and work with) they act like it's 90%.

[stillpointlab]

Yes, I review every PR (which is part of the bottleneck) and give strict feedback (as I mentioned, averaging 2 to 3 fixes per task).

What I'm saying is that there are some higher-level loops (as described in this article) that are outside of the bottlenecks I mentioned (spec creation and PR review).

For example, I may have 3 written and ready to go specs that are totally unrelated (don't touch the same files, each can go to PR stage with no conflict) but it isn't easy to keep the agent moving on them unless I do so manually. Having an outer-layer orchestrator that can move that along makes a lot of sense.

But when there are dependencies between tasks, it has to wait for my PR. And once I run out of good specs, it has to wait for me to write them.

[mlsu]

"Writing specs" is the essential complexity of programming. What you're saying is that there's no silver bullet. Agents or no agents, punchcards or interpreters, programming is programming at the end of the day.

[cheevly]

I'm pretty sure programmers weren't the ones writing the specs in the past...

[chickensong]

Same experience. Totally bottle-necked by specs. I don't really see a way past it that isn't sketchy and consumes excessive resources. I guess I'm not ready.

[Npovview]

> "Before I go to bed I'll often say "do task X and once done and pushed start on task Y".

Following could solve your problem.

https://www.aihero.dev/skills-handoff

/handoff is my new favourite skill

https://www.youtube.com/watch?v=dtAJ2dOd3ko

[andai]

Why can't Claude write the spec?

[stillpointlab]

It does, but I have to direct it and review it. That means I have to think about it, research it, consider how the new feature or system fits in with the existing feature or system. I have to make decisions on libraries/dependencies. I have to consider how the project will evolve in the next week, month, quarter. I communicate all of that to Claude in an interactive planning session and it outputs a detailed spec, ready for implementation.

All of that thinking, planning, rewriting, etc. takes almost as long as it takes Claude to actually deliver the feature. The big features Claude writes take ~30-45min of uninterrupted coding to deliver (I just checked the last feature was 39m 41s for +1,610/-26). To write that same code would have taken me probably 2 days.

[godelski]

How do you expect it to give you what you want if you don't think about it?

Solution spaces for even seemingly simple problems is incredibly large. There's a reason there's a thousand different types of nails and a million types of screw heads. Just making every screw head Phillips (or pick another) doesn't just make things work.

But you need expertise to know these things. They're the issues that are subtle and appear to work but you end up breaking things (often invisibly) and just end up chasing problem after problem. It looks like a new problem but it's rooted in something else.

[stillpointlab]

I agree, but that is the crux of my initial post. There is a ceiling to how quick I can deliver using LLM coding agents which is the speed at which I can write good enough specs.

I feel I'm at the point now where the time the LLM takes to deliver a feature, no matter how big, is nearly inconsequential. Because while it is in the process of delivering the feature, I am writing the next spec, and by the time I finish the spec the agent is waiting for the next feature. And at that point I have to review it's code, give it feedback, review it's fixes, merge, etc. All of the "waiting" is on me. It is basically delivering features as fast as I can write specs and could only get faster if I write specs faster.

[8note]

the bottleneck is still you knowing what the right thing is, and where the odd edges are.

either you tell claude or it tells you/is probably wrong

but, you can still be more agile i think, and just make the thing and see of it solves the problem or not, and if not, build something else