Just Talk To It, the no-BS way of agentic engineering

Peter Steinberger builds software on his own. Not small stuff either: his current project is about 300,000 lines of code spread across a website, a browser add-on and some phone apps. The surprise is that he barely writes any of that code by hand any more. An AI coding assistant writes almost all of it. His actual job has shifted to deciding what to build and steering the AI while it does the typing.

The whole article is one argument, made over and over: stop making this complicated. Loads of people build elaborate systems to manage their AI. He thinks most of that effort is wasted. The title is his advice in four words: just talk to it.

Here is how he actually works. He runs several agents at the same time, laid out in a grid of terminal windows, like having six junior developers at their desks while he walks between them. When one is taking too long, he interrupts it, asks “what’s the status?”, then either nudges it or stops it. He judges every change by its blast radius: before he asks for something he already has a feel for whether it is a firecracker or a big bomb. He would rather set off lots of little firecrackers than one giant blast, because small changes are far easier to undo when they go wrong.

A big chunk of the post is him explaining why he swapped his main tool from one AI coding assistant (Anthropic’s Claude Code) to another (OpenAI’s codex). His reasons are practical and, he admits, a little personal: codex reads more of his project before it starts, pushes back when he asks for something daft, runs faster, and does not wind him up the way the other one did. He confesses he used to shout at the old one. This is his own preference, not a neutral verdict, and plenty of people would disagree.

Then he knocks down a long list of fashionable tools and tricks he thinks are mostly for show. He is unconvinced by subagents, by MCPs which he says quietly clog up the AI’s memory, and by RAG, which he reckons the newest models have made unnecessary for his kind of work. The pattern is the same each time: he says these things paper over weaknesses in older AI models, and the newer models simply don’t need the crutch.

He is just as blunt about how he writes instructions. He used to write long, careful prompts. Now they are often one or two sentences plus a screenshot dragged into the window, because the AI is good at reading his code and working out the rest. He has also let go of the older habit of writing a giant spec up front and having the AI build the whole thing at once. For screen-based work he now under-describes on purpose, watches it build, then keeps adjusting until it feels right, a bit like sketching rather than drawing the final line first.

He is honest that his chosen tool is not perfect. It sometimes works for half an hour, panics and undoes everything, occasionally replies in Russian or Korean, and loses lines of text on screen. He lists these flaws plainly and says he can live with them because the rest is so good. His closing thought is the same as his opening one: don’t waste time on clever scaffolding, just talk to the AI, play with it, and build up an instinct for it. He also notes that the skills for managing these agents look a lot like the skills for managing human engineers, and that deciding what to build is still genuinely hard even when you are not the one typing.