I don't get those depressing articles. If anything I've been working way more with LLMs and working harder.
I love that Codex added "Steer" to the chat, because I fucking pay attention to the conversation traces on coding agents and I was tired of the PANIC ESC - "No, that's not what you should do! We use a visitor to calculate all that stuff, I just need you to implement another visit method for this new Stuff according to the rules".
Nothing says you shouldn't write any code, in fact, I think that starting from a n interface and a few clients is superior to simply describing things only in natural language. Lots of refactors like extracting method, extracting interface, renaming symbol are way faster, cheaper (no tokens) and less error prone using the IDE.
When I am not sure about the concrete design to implement something, I talk to the coding agent, we discuss types, i suggest patterns, I wrote a small stub here and there, maybe a couple unit tests, but I like to activelly engage with the coding agent as if I was pair programming.
Yeah, I am not a fan of fire and forget, I see no point in being able to control agents remotelly, but nobody is complaining I am not fast enough. It is perfectly possible to have the huge productivity gains coding agents give you without entering vegetative programmer mode. You just need to engage yourself in the process.
You can describe the different categories of something, or you can go ahead and create an enum in rust, you can create a pydantic validator, a few tests here and there. The agent now has something more concrete than a natural language description, it has the compiler to check his code, it has the unit test. The flow becomes faster.
You can mention in your prompt that the agent should use AWS SDK v2 in your Go service, or you can go ahead and add the imports and the initialization somewhere in your code, the second option is a far stronger nudge towards the right direction.
The time you used to waste trying to shoehorn some stack overflow answer to your problem, now you can use to actually read the documentation of whatever you're trying to use. Go ahead, read it fully, you now have time to understand it deeply. The grunt work, the toil will be taken care of by the agent in a few minutes when you're finally feel yourself ready to move to implementation, because now you have the deep knowledge to take the best possible decisions.
There are plenty of places for you to apply your knowledge: the agent may write a correct function, but then this function does a remote HTTP call in the context of a database transaction, so, what happens when the remote http endpoint has a spike on latency? And what if the tables involved on this transaction are a hotspot in your application? You can't add all those small details in your context all the time, you can't add all single corner case and potential pitfall to your AGENTS.md.
Of course, you have to up your game. If all you ever did was completing JIRA tickets without thinking much about it, yes, there's no much you can add to the process beyond what your coding agent can do. But this is a choice.
We can either create a humongous era of slop and technical debt with coding agents, or we can use its hability to free ourselves from toil so we can finally improve our code in correctness, performance, efficiency, efficacy, security and compliance all the while keeping the business happy.
We can either use LLMs to have tens, hundreds, thousands of THERAC-25, or we can use them to liberate our time so we can do the deep work that ensures that you can't possibly deploy a THERAC-25 in production.