The Seat Keeps Sliding

The other night I watched an agent work through a ticket on its own. It read the issue, opened three files, made a plan, wrote the code, ran the tests, and waited. I had my hands hovering over the keyboard out of habit and then I put them down. The work was happening and I was not doing it. I was watching it. I caught myself in that small awkward moment, the one where you notice your posture has changed without your permission, and I thought about how I had gotten here. Not how the technology had gotten here. How I had.

This is a story about that. About where the human used to sit in the loop of building software, and where the human sits now, and where the seat is sliding next.

When AI was just a function in the backend

For most of computing history, what we called AI was a component. A recommender ranking products on a page. A fraud model scoring a transaction. A search relevance function deciding which result came first. Nobody talked to these models. They returned a number, or a list, or a probability, and the engineer's job was to build everything around the number. The model was a box you fed inputs to and got outputs from. It did not have opinions. It did not explain itself. You did not address it. You called it, the way you call any other function.

That was the whole arrangement, and it was the arrangement for a long time. The human wrote all the software. The model was a small specialist living inside the software the human wrote.

The machine learning years, which were mostly plumbing

Then there was a stretch where every company decided it needed a data science team. The phrase "machine learning" sat on every job description. Most of the actual work was not the modeling, it was the plumbing. Pipelines that moved data from one warehouse to another. Feature stores. Notebooks that someone ran on Tuesdays. The intelligence was real but invisible to anyone who used the product, and most of it could have been replaced by a thoughtful SQL query without anyone noticing.

The constraint that defined this era is easy to forget now. The model could not be asked a follow-up question. It could not explain why it scored that transaction as fraudulent. You could not say, "what if the customer was traveling?" You fed it features and prayed. The relationship was one way.

The chat moment was a UI breakthrough, not a model one

Then ChatGPT happened, and the common story is that the model got smart. That is not quite right. The model got addressable. The breakthrough was the interface. Suddenly the thing could be talked to like a person. You could ask a follow-up. You could push back. You could say, "no, do it this other way." For the first time in the history of this technology, the model could be in a conversation with you.

That changed who was allowed to use it. The barrier to entry collapsed from "can write Python and read a confusion matrix" to "can type." My mother asked ChatGPT to help her write a thank-you note. She had never opened a Jupyter notebook in her life. The interface did the work.

Asking it about code, badly at first

The first time I used it for code, I pasted a snippet and asked why it was slow. The answer was about half right. The other half was confidently wrong, which is worse than wrong. I learned, the same week as everyone else, that you had to be specific. You had to give it the right context. You had to know enough to catch it when it lied. Garbage in, garbage out was the honest summary, except now the garbage came back faster and looked more credible.

But the loop was tight. You asked, you got an answer, you tried it, you came back. Iteration is where the value showed up. People who used it like a search engine were disappointed. People who used it like a colleague were not. The difference was the willingness to talk back.

Most engineers learned a new posture during this stretch without naming it. We were no longer typing every character. We were editing what someone else had typed. That sounds like a small change. It was not.

From snippets to blocks to pages

Then the requests got bigger. Write me a function that does X. Write the SQL for this query. Write the React component for this page. Each step felt incremental at the time and each step quietly raised the stakes of being wrong. A wrong line was easy to spot. A wrong function was harder. A wrong component, with three subtle bugs spread across forty lines of plausible code, could ship.

A lot of engineers kept calling this autocomplete on steroids long after it had stopped being autocomplete. The framing was wrong but the framing was comforting. If it was just fancy autocomplete then nothing had really changed. The job was still the job. You could still tell yourself you were writing the code.

I told myself this for longer than I should have.

End to end, with the human at the checkpoint

The shift I could not paper over came when I started letting it work across whole sessions. Give it the goal. Let it touch multiple files. Let it write, test, fix, write again. Come back at the boundaries and review. This is the moment the job visibly changed for me, and I think for a lot of people. I was not writing software anymore. I was specifying it and sampling it and saying yes or no.

That was uncomfortable. It is still uncomfortable for plenty of good engineers, and some of them hate it openly, and I do not blame them. The craft you spent fifteen years learning was the craft of typing the right characters in the right order. Now the typing is the cheap part and the judgment is the expensive part. The skills are different. Some of them you have. Some of them you have to build from scratch in your forties, which is not anyone's favorite thing.

Agents, skills, and the team of one

Where we are now, for working developers paying attention, is agents. The model picks its own tools. It decides what to read first. It runs commands, looks at outputs, changes direction. Skills wrap up common workflows so you do not have to explain them every time. Sub-agents handle branches of work in parallel while the main thread keeps going. The pattern is one human at the top of a small swarm, fielding a queue of decisions instead of writing a queue of lines.

It is not all good. Agents get stuck on stupid things and then write four hundred words explaining why they are stuck. Agents lie confidently when they do not know. Agents will sometimes do the wrong work very well, which is the worst category of failure because it looks like success until you look closely. The new skill, the actual new skill, is detecting both. Knowing when the agent is in a loop. Knowing when the answer is plausible but wrong. Knowing when to stop it and intervene.

This skill is not in any computer science curriculum yet. It will be, eventually. By the time it is, the thing it teaches will have moved again.

The expensive future, and what it costs to be excellent

Here is the forecast, and this is the part I am least sure about, so take it as a guess. The cheap models keep getting cheaper. The middle of the market gets compressed because what used to require a frontier model now runs on something three tiers down. That is the part everyone agrees on.

The other end of the curve goes the other way. The frontier models will do genuinely senior engineering work, and they will cost what senior engineering work costs. Not per token, but in aggregate, for sustained use, the bill for a frontier model running an agent loop for a week will land somewhere in the neighborhood of what you would pay a person. That sounds like a contradiction. It is not. It is the market finally pricing the work at what the work is worth.

What this does to hiring is the part nobody wants to think about. If the cheapest way to get senior-grade output is to pay for tokens, the economic argument for hiring and training a junior gets harder every year. And juniors are how you get seniors. If the pipeline breaks, the supply of people who can actually tell when the agent is lying breaks with it, five or ten years downstream, and nobody notices until it is too late.

I do not have a clean answer to this. I think the companies that solve it will be the ones that keep hiring juniors anyway, not because the math works in year one but because the math works in year five. Most companies will not do this. Most companies have never been good at year five.

What does not move

The grounding point, the one I keep coming back to: taste does not get cheaper. Knowing what to build does not get automated. The willingness to delete a feature, to say no to a stakeholder who wants the wrong thing, to choose the boring solution that will still be running in six years. These stay human and they stay rare and they are not, as far as I can tell, anywhere on the model improvement curve.

The engineers who do well over the next five years will be the ones who figure this out early. Not the ones with the fastest fingers. Not the ones who memorized the most APIs. The ones who got good at deciding, at reviewing, at saying no, at knowing the difference between code that works and code that should exist. That is the part of the job the models cannot do, and I do not think they are going to learn it soon, because it is not really a code problem. It is a problem about humans and what we want.

Closing

The agent finished the ticket while I was writing the last paragraph. I went and read the diff. It got one thing wrong, a small thing, a default value that should have been nil and was an empty string instead. I fixed it. I approved the rest. The work is done and I barely touched it.

The keyboard sits there. The job is still here, it just does not look the way it looked five years ago, and it will not look the way it looks now in another five. The seat slid again, while I was not paying attention. It will slide again. The trick, as far as I can tell, is to keep noticing where it went, and to sit in the new place like you meant to all along.

That is the whole job now. Pay attention to where the seat is going. Get there before it does.