If it's working for you, great, but presenting it like it's a general direct replacement for development teams is disingenuous.

---

> Looks like we just have different expectations: i don't want to micromanage my coding agents any more than i micromanage the developers i work with as a product manager. If the output does what it is supposed to do, and the software is maintainable and extendable by following certain best practices, i'm happy. And i expect that goes for most business people.

None of what i said implied any expectations of the process of using the tools, but if you've found something that works for you that's good.

On the subject of maintainability and extension, that is usually bound to the level of complexity of the project and the increase in requirements is not generally linear.

I agree, many business people would love what you've described, very few are getting it.

> And in practice i have more control with a coding agent than with developers as i can iterate over ideas quickly: "build this idea", "no change this", "remove this and replace it with this". Within an hour you can quickly iterate an idea into something that works well. With developers this would have taken days if not more. And they would've complained i need to better prepare my requirements.

Up to a point, yes.

If your application of this methodology works well enough before you hit the limitations of the tooling, that's great.

There is , however, a threshold of complexity where this starts to break down, this threshold can be mitigated somewhat with experience and a better understanding on how to utilise the tooling, but it still exists (currently).

Once you reach this threshold the approaches you are talking about start to work less effectively and even actively hinder progress.

There are techniques and approaches to software development that can further push this threshold out, but then you're getting into the territory of having to know enough to be able to instruct the LLM to use these approaches.