It is not glamorous, but this is where the work is going, and I would rather learn the tools than argue with them.
This is a short note before the posts that follow, because most of them are about things I built with an AI agent doing a lot of the typing, and I would rather say that up front than let you work it out.
I have been a backend engineer for a few years. Most of the job is reading code I did not write, then changing it without breaking something else. This year the tools got genuinely useful at that, not just at completing a line.
The shape of a working day changed a little. Instead of typing the change, I describe it, watch it get attempted, and read the result like a pull request from a stranger.
your message
|
v
[ the agent ] --reads--> your repo
| |
| v
| edits and tests
v
a diff you still have to review
How it got here
Lee Robinson counts four eras of developers working with AI, and the compressed version is the one worth internalising [1].
2022-23 copy and paste
chat in a tab, paste it in
2024-25 agents in the terminal
edit files, run commands
2025-26 apps built for agents
many at once, some in the cloud
now always-on agents
own memory, keeps working
The first era was copy and paste, and in his words, “copy-pasting code out of ChatGPT and putting it into your editor of choice, which feels like decades ago at this point, but it was really only a few years ago” [1]. Then came a harness in the terminal, editing files and running commands with your approval on each step. Then apps built for agents, several running at once, some in the cloud. Now always-on agents, which “run ambiently in the background where they have their own computer, they have their own memory, they learn new skills on the job, and they keep working after you go to bed” [1].
The detail that matches what I actually run is this. As the models got better, the interface got simpler, not more complicated. You stop queuing commands and start steering. Robinson’s example is interrupting an agent mid-task with “actually, do that on Thursday” and having it hold both instructions, where an earlier generation of models would have lost the thread [1].
The trust moved at the same time. Approving every shell command by hand felt like security, but a lot of it was fatigue, and companies are replacing it with auto review, a second model checking the commands of the first. Robinson’s claim is that in a blind test the model check usually does better than the human one [1]. I would not treat that as settled, but I have watched my own approval reflex get worse the longer a session runs, so I understand the argument.
The bottleneck moved
If writing code gets cheap, whatever sits downstream of writing code becomes the constraint. Laurie Voss puts the gap at roughly eight times more code for about thirty percent faster shipping [2], and the same shape shows up in harder data. An NBER study of more than 500,000 GitHub developers found commit activity up 240% once autonomous agents arrived, but actual releases up only 30%, and the authors explain it as a weak link: the gain gets eaten by the human steps around it [3].
So the bottleneck is review. Voss is blunt that the agents are not good enough to skip it, and that the automated checkers we built to replace it are not good enough either [2]. Anyone who has merged a nine hundred line diff at the end of a long day knows exactly where that lands.
We have had this job before
The framing I keep coming back to is his. The job has existed twice already. In the 1960s it was the systems analyst. From the 1980s it split into product manager and engineer, two separate careers. Now it is collapsing back into one [2].
The order things get eaten in is specific. Writing code, collapsed. Reviewing and maintaining, going soon. Shipping to production and scaling, next on the block. Possibly safe: deciding what to build, defining what “good” means, making it delightful [2]. Voss calls the survivor the product engineer, someone who “finds out what people need, defines what good looks like, and ships it with agents doing the typing” [2].
I do not know whether that schedule holds, and neither does he, which is why he calls it a bet. But it lines up with everything I ran into this year, and it explains why the useful skill in my own work has shifted from writing the change to describing it precisely and then checking it hard.
Why I am writing it down
I am not going to write a post about how it changed my life. Some of what it produced was worse than what I would have written by hand. The parts that were worse were also not obvious until they failed, which is the part worth writing about.
I have been wrong about a tool before, and always in the optimistic direction. That is why these posts keep the failures in.
But this is the direction the work is going. I would rather spend the next decade knowing these tools than arguing with them, and fighting something you are going to be handed anyway is a good way to end up slower at your own job.
So these posts are a record. What I asked for, what came back, what it cost, and where it broke. In a year I want to be able to check whether any of this held up, and I do not trust my memory enough to do that without notes.
The ones that follow are about a voice assistant with no phone number, a game I built twice to see what carried over, what a cheap agent plan actually costs, and a deleted world I got back off a disk. None of them are tutorials. All of them have a part where it went wrong.
References
[1] L. Robinson, “Stanford CS146S: How always-on agents work,” YouTube, Oct. 11, 2026. [Online]. Available: https://youtu.be/L1OBRtfPS34
[2] L. Voss, “AI Writes the Code. So What’s Left for Engineers?,” AI Engineer, YouTube, Oct. 25, 2026. [Online]. Available: https://youtu.be/kspZP5BgkEU
[3] M. Demirer, L. Musolff, and L. Yang, “Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools,” NBER Working Paper 35275, 2026. [Online]. Available: https://www.nber.org/papers/w35275