[lubujackson]

The key point is "relegating the reasoning". The real way to think about interfacing with LLMs is "abstraction engineering". You still should fully understand the reasoning behind the code. If you say "make a form that captures X, Y, Z and passes it to this API" you relegate how it accomplishes that goal and everything related to it. Then you look at the code and realize it doesn't handle validation (check the reasoning), so you have it add validation and toasts. But you are now working on a narrower level of abstraction because the bigger goal of "make a user form" has been completed.

Where this gets exhausting is when you assume certain things that you know are necessary but don't want to verify - maybe it let's you submit an email form with no email, or validates password as an email field for some reason, etc. But as LLMs improve their assumptions or you manage context correctly, the scale tips towards this being a useful engineering tool, especially when what you are doing is a well-trodden path.

[rTX5CMRXIfFG]

I find this to be too rosy a story about using agentic coding to add to a codebase. In my experience, miss a small detail about the code and the agent may can go out of control creating a whole new series of errors that you wouldn’t have had to fix. And even if you don’t miss a detail, the agent eventually forgets because of the limited context window.

This is why I’ve constrained my use of AI agents to mostly “read-only and explain” use cases, but I have very strict conditions for letting it write. In any case, whatever productivity gains you supposedly “get” for its write scenarios, you should be subtracting your expenses to fix its output later and/or payments made for a larger context window or better reasoning. It’s usually not worth the trouble to me when I have plenty of experience and knowledge to draw from and can write the code as it should be myself.