How a senior engineer works in 2026, and what your field sees next

I haven’t typed code in six months. I pay Anthropic $200 a month for the agent that types it for me. My output is higher than any prior year I’ve worked.

Ten years of writing code by hand bought me the only skill the new workflow rewards: judging code, not producing it. The shape of the job changed inside three years. What happened to programming is the early warning for every other knowledge-work field. The daily ritual below is what the new job actually looks like.

Claude Code is not a chatbot

Every task I take on starts the same way. I open a terminal, type claude, and a session starts. Claude Code is an agentic harness built by Anthropic. It’s the difference between a chat window that answers questions and an agent that does the work. The agent reads my project files directly, edits them, runs tests against them, and reports back.

Then I spend about five minutes drafting a prompt. The prompt names the goal, the constraints, the parts of the codebase that are relevant, and the way I want the work checked. A weak prompt looks like “add login.” A strong one names the existing auth file, the password rules I want enforced, the test coverage I expect, and what the agent should do if it gets confused. Five minutes on the prompt saves an hour of corrections later. The best return I get on any block of time in my day.

Prompting is a skill and it took practice. The instinct is to type the request the way you’d type a message to a colleague. That produces weak results. The strong version came from a year of writing prompts, reading what the agent did wrong, and learning which kinds of detail the agent actually uses versus which kinds it ignores.

The setup that stops the hallucinations

A fresh agent dropped into a codebase will produce work that compiles and is wrong, because it has no context for the team’s decisions. Three pieces of structure fix this.

First, a file called AGENTS.mdsits at the root of the project. It’s a plain English document that explains what the codebase is, what conventions the team follows, which libraries are approved, and which past patterns are mistakes. The agent reads it at the start of every session. This is the company handbook, written for the agent.

Second, skills. A skill is a small reusable instruction file the agent pulls in when a task matches. I have skills for writing in my own voice, for reviewing my own work like a hostile critic, for grading sources before I cite them, for the way I price proposals. The agent recognises the task and picks the skill up automatically. Skills are how a single person teaches the agent the parts of their craft that don’t fit into a one-line prompt.

Third, deterministic checks. Whenever the agent edits a file, my setup automatically runs four checks: a linter that catches style mistakes, a typechecker that catches whole categories of bugs, a dead-code detector, and a formatter. These catch typos, type mismatches, broken imports, unused code, and dozens of structural bugs. What they can’t tell me is whether the code does what the business actually wants. The agent sees the failures, fixes them, and tries again, with no input from me. By the time the work reaches me, the structural mistakes are already gone and I can focus on whether the work was the right work.

What I actually do now

The job is reading and judging, not typing.

When the agent finishes, I read the diff. The diff is the set of changes the agent proposes to make to the codebase. I read it carefully. Did the agent understand the task? Did it pick the right pattern? Did it cut a corner that will cost us in six months? Did it touch files it shouldn’t have? Did the tests actually exercise the change, or did the agent write a test that passes regardless of whether the code works?

If something is wrong, I describe what’s wrong and the agent fixes it. If the architecture is wrong, I say so, and the agent rewrites the larger pattern. The cycle continues until the diff is acceptable, then I commit it.

I’m structurally a manager of one. The thing I manage is fast, doesn’t take time off, costs a tiny fraction of a salary, and will redo a piece of work six times in a row without complaint. It also confidently produces wrong code, misunderstands subtle parts of the problem, and writes tests that lie about whether the code works. It needs a serious reviewer on the other side.

Why the ten years are still load-bearing

The agent does the typing. I do the judging. The judging is what ten years of writing code by hand bought me.

I can read a diff in fifteen seconds and tell whether the agent has picked the right abstraction, because I’ve picked the wrong one enough times to recognise the shape of it. I can spot a security mistake because I’ve made one. I can tell when the agent’s confidence is misplaced, because I have been the engineer whose confidence was misplaced. The agent writes code I could have written ten years ago, but I would have written it badly, and I wouldn’t have known why it was bad until production told me.

The studies that claim AI tools don’t make people faster are usually right about the people they measured. A randomised trial published by METR in July 2025 found that experienced developers were 19 percent slower with AI tools than without, while reporting afterwards that they had been 20 percent faster. The 2024 DORA report from Google found a parallel pattern: individuals feel more productive, team throughput drops by 1.5 percent, team stability drops by 7.2 percent.

The studies aren’t capturing the speedup because most people using these tools haven’t learned how to use them. The speedup is real. It only shows up for the people who put the work in to get there.

The junior engineer is mostly gone

A senior engineer with the right setup does the work that used to need a team of five juniors. This isn’t a forward-looking prediction. It’s happening now.

Stanford’s Digital Economy Lab tracked employment for software developers aged 22 to 25 since the start of generative AI tools. That cohort is down about 20 percent from its late-2022 peak. Developers in their thirties and forties have continued to grow. Salesforce told investors in early 2025 that the company wouldn’t add any more software engineers. Shopify circulated an internal memo requiring managers to prove a job can’t be done by AI before approving new headcount.

The displacement compresses from the bottom. The senior who orchestrates absorbs the work of the juniors who used to type. This is the part most decision-makers underestimate, and it’s storing up a real problem. The pipeline that produces tomorrow’s seniors is closing while universities are still teaching the same syllabus they taught five years ago. The field still needs new people. It doesn’t need them to write the boilerplate any more, and nobody is teaching them what it does need.

What this looks like in your field

The pattern programming went through is generalisable. It’s the pattern your industry should expect.

The change wasn’t sudden. Three years ago I was copy-pasting code out of a chat window into my editor. Then I added a tool that suggested the next line of code while I typed. Then I trusted it to write entire functions. Then I trusted it to write entire features. Now it can take a brief, work across fifteen or more files, and produce a complex change in fifteen minutes that would have taken me days. After the prompt and the setup, I’m not in the loop until I review the diff.

Every field will move through a version of those phases. The first phase is the chat phase. People use a chatbot to draft documents, summarise reading, answer questions. The work feels easier. Nothing structurally changes. This is most knowledge-work fields right now.

The second phase is the agent phase. Tools start to take real actions inside the systems where the work happens. For lawyers, an agent inside the document-management system that drafts, edits, files, and tracks responses. For accountants, an agent inside the ledger system that classifies entries and reconciles accounts on its own. For marketers, an agent inside the campaign tool that writes copy, schedules sends, measures results, and re-targets. The agent takes the work the junior did. The senior orchestrates. This is starting now.

The third phase is what programming is going through. The senior writes no documents, no briefs, no schedules, no copy by hand. The senior describes the goal, reviews the agent’s output, and corrects it. The team of five becomes a team of one with a budget for model usage.

Two conditions decide whether your field reaches phase three or stalls at phase two. The first is whether deterministic checks exist for the work. Programming has compilers, type systems, test suites, and linters. The agent can be wrong, and a deterministic tool catches it before the human looks. If your field’s quality bar can be encoded in checks the agent runs against itself, the senior-orchestrator pattern holds. If it can’t, the senior has to read everything and the speedup never materialises.

The second condition is whether the field’s seniors have a clear vocabulary for what good work looks like. The senior who can articulate the difference between an acceptable output and an unacceptable one moves five times faster than the senior who can recognise quality but can’t describe it. Tacit knowledge does not transmit to an agent. Articulated knowledge does.

The position

A senior in any knowledge-work field who learns to orchestrate an agent does the work of five juniors. A senior who refuses to learn becomes the bottleneck of the team. A junior trying to enter the field on the old terms walks into a hiring market that no longer needs them.

The next twelve months will sort decision-makers in every field into two groups: the ones who are restructuring their teams around senior orchestrators, and the ones who will be explaining to their boards in 2027 why a competitor of half the headcount is moving twice as fast.

The teams that win this round won’t have the best agents. They’ll have the seniors who know exactly what to ask the agents for.