Coding in 2026

I keep meeting people who think coding got easier in 2026. It didn't. What got cheaper is the ceremony that used to stand in for skill: scaffolding a CRUD app, remembering the exact signature of a library you use twice a year, turning a clear plan into a first draft. That work still exists. It just stopped being a reliable signal of whether someone can build software that survives contact with users, money, and time.

The uncomfortable truth is that the job moved upstream. The scarce thing used to be producing working code. Now the scarce thing is knowing what the code should be allowed to do, and having the taste to reject a plausible answer that is quietly wrong.

This is not a eulogy for programming. It's a field guide for people who still want to be good at it.

01What actually changed (and what didn't)

Three years ago, a competent engineer spent a surprising amount of a week on mechanical work: wiring the tenth endpoint that looked like the ninth, writing the migration that mirrors the model, fighting a type error that meant the docs were stale. That middle of the task compressed. Agents draft it. Models fill it. The compile loop got shorter for anyone willing to supervise it.

What did not compress:

• Deciding the boundary between two systems that will outlive the people who drew it
• Naming something that other teams will depend on for years
• Knowing when a clever abstraction is a future tax
• Debugging a production incident where the evidence isn't in the repository
• Saying no to a feature that would feel good in the demo and bad in month six

Those were always the hard parts. They just used to be hidden behind a lot of typing. Now the typing is optional, and the hard parts are sitting in the middle of the room looking at you.

Speed without judgment is just a faster way to dig the wrong hole.

02The new shape of the craft

If I had to redraw the job in one sentence: you are less a typist and more a director of consequences.

You still write code. You should. But the leverage moved from "can I make this compile" to a stack that looks more like this:

1. Frame the problem so a capable stranger (human or agent) couldn't misunderstand the outcome.
2. Choose constraints: what is in bounds, what is forbidden, what "done" means in a way you can check.
3. Generate and integrate: draft, wire, test, often with help.
4. Review adversarially: assume the output is confident and slightly wrong until proven otherwise.
5. Own the residue: the schema, the public names, the failure modes, the on-call story. That residue is the product.

People who skip steps 1, 2, and 4 and live in step 3 feel productive until they ship something they cannot explain. Then they feel haunted.

03How to approach the work now

Treat every non-trivial task like a short delegation, even when you're the one doing it. Five minutes of framing still beats forty minutes of thrashing, whether the thrashing is yours or an agent's.

Write the brief first. One sentence for the outcome. A short list of files or surfaces that may change. A named list of things that are off limits. If you can't write the brief, you don't understand the task yet. That is useful information. Act on it before you open a chat window.

Prefer small blast radii. Wide refactors and "just clean this up while you're in there" are where plausible garbage loves to hide. One concern per change. One reviewable story.

Make verification boring and automatic. "It builds" is not a bar. Plausible code always builds. Prefer a test that fails when you revert the change. Prefer a type that makes the illegal state unrepresentable. Prefer a log line you can grep for at 2 a.m.

Keep a written memory of the project. Preferences that only live in your head die between sessions. A short AGENTS.md or equivalent (stack, non-negotiables, definition of done) turns taste into defaults. The point isn't bureaucracy. The point is not re-teaching the same lesson every Tuesday.

Protect the decisions that don't reverse cleanly. Schema. Auth. Money. Public APIs. Anything a stranger will build on. Draft if you want. Merge only when you understand every line.

04What new developers should actually do

I get asked this constantly, usually with a quiet panic underneath: if the model can write the code, what am I training for?

You're training for the parts the model cannot own for you.

Build things end to end. Not tutorials you half-follow. Small products with a real user, even if the user is you. Deploy them. Break them. Fix them at night. The skill you're after is not syntax. It's the loop from intention → running system → feedback → revision.

Read code like a journalist. Open a codebase you didn't write. Trace one request from the edge to the database and back. Ask why the seams are where they are. Reading is still how taste arrives. Models can generate volume; they cannot give you a sense of proportion.

Get suspicious of comfort. If every answer arrives fully formed and you never feel stuck, you are outsourcing the part of learning that hurts on purpose. Struggle is not a bug in the curriculum. It is the curriculum.

Learn systems, not frameworks. HTTP, data models, concurrency, failure, auth, observability. Frameworks churn. The underlying questions (where does state live, who can touch it, what happens when this is slow or wrong) transfer.

Use agents as force multipliers, not as a personality transplant. Let them scout, scaffold, and draft tests for modules you already understand. Do not let them make the first shape of a hard idea. If the idea never lived in your head, you cannot review it. You can only admire it.

Write in public, ship in public, explain your work. The market is flooded with people who can paste a prompt. It is starving for people who can say: here is the tradeoff, here is what I refused, here is how we'll know this broke.

05A few lies worth retiring

"I don't need to understand it if the tests pass." Tests encode the assumptions you already had. They do not invent the ones you missed.

"The model knows the codebase better than I do." It knows a slice of tokens. You know the politics, the outages, the customer who will file a ticket if the edge case trips. That context is not optional.

"Senior means I stop writing code." Senior means you choose where code gets written, by whom, and what "done" means. Many days that still includes your own hands on the keyboard, especially on the irreversible parts.

"Shipping faster is the whole game." Shipping the wrong thing faster is how you get a calendar full of rewrites. Direction beats velocity when the road forks.

06What excellence looks like in this era

The best engineers I know in 2026 are not the ones with the cleverest prompts. They are the ones with the clearest taste:

• They can describe a change in one sentence before anyone types.
• They leave the public surface cleaner than they found it.
• They write the boring test that would have caught last quarter's incident.
• They are willing to delete a clever abstraction that only they love.
• They treat agents like sharp tools: useful, supervised, never trusted with the keys to the vault by default.

Excellence used to look like knowing more APIs than the person next to you. Now it looks like carrying responsibility for outcomes in a world where producing code is abundant and judgment is not.

07Closing the loop

Coding in 2026 is still one of the best crafts on earth. You get to turn fuzzy human need into something that runs while you sleep. The tools got louder. The responsibility got clearer.

So approach it like this: think harder at the start, generate freely in the middle, and review like the person who will be paged. If you're new, spend your reps on understanding and ownership, not on collecting generations you can't defend.

The keyboard is still there when you need it. The difference is you no longer have to prove yourself by wearing it out. You prove yourself by what you allow into the world.