Will We Write Code Again?.

I've been writing code for most of my life, and every line of the first version of NestJS was typed by hand. That's why it feels a bit strange to write this, but I don't think we're going to write code by hand anymore, at least not most of it. And I believe it's going to happen very soon. For some of you it might not be the case yet, depending on what you work on and which tools you're allowed to use, but I don't think it's a matter of years anymore.

This isn't an announcement and there's no package to install at the end. These are just some thoughts I've had in my head for a few weeks now, and I figured it's time to write them down.

Are we going to write code again?

I believe we won't, except for chiming in here and there.

Agents got good enough to take a well-described task and deliver it end to end. They read the codebase, make the change, run the tests, fix whatever broke and try again. They're also much faster than we are. Something that used to take me an afternoon now takes minutes, and I can have a few of those running at the same time.

Here's an example from my own work. Agents have become really good at debugging SQL queries. They write the query, run EXPLAIN on it, figure out what's slow, optimize it, and when they need to reproduce a problem, they seed the local database with millions of records to reproduce it locally. With that instant feedback loop, they just keep iterating until it's fixed. A typical engineer would spend hours investigating something like that, while an agent is done in a few minutes.

You'll probably say that the amount of code was never the bottleneck and that quality was. I agree with the first part, but I'm not so sure anymore that quality is an argument in our favor.

There were studies in the past that found more issues in AI-assisted code than in code written by humans, but they used models nobody uses anymore, and frontier LLMs today are way better. A year ago I was hesitant to give any real work to agents myself. I mostly used LLMs for auto-completion. That has changed completely, and what I see today with agents that run tests, read logs and iterate on their own work in a codebase with clear conventions looks very different. We, on the other hand, get tired, we skip the edge case at 6 p.m., we copy-paste the wrong variable. I believe that if you give agents clear constraints and a way to verify their work, they're already less likely to make a mistake than we are, and the gap will only grow.

That "if" matters a lot, though. An agent is only as good as the task it gets, so the skill that matters most is moving from writing code to describing it: what has to be built, what must not change, which trade-offs are fine, and how you know it's done. It turns out that being precise in plain English is harder than being precise in TypeScript.

That's also why code isn't going away. We'll just use it differently. Instead of writing the implementation, we'll use code to communicate. Sometimes it's just easier to write a few lines and hand them to the agent than to explain in words what you want. An interface, a function signature, a rough sketch of how the data should flow, or a quick example of the API you'd like to end up with. The agent then knows exactly what you're after, and it takes care of the rest. That's the "chiming in" I mentioned above. It's less like writing code and more like drawing a quick diagram on a whiteboard for a colleague.

And this is where experienced people are still extremely important, probably more than ever. To describe a system well, you need to know what can go wrong, which corners you can cut, and which ones will come back to bite you a year later. You don't learn that from prompting. You learn it from years of building things, breaking them and fixing them.

I like to compare it to other professions. Even with a very capable AI, you can't just start working as an architect and design a building. The AI can draw the plans, sure, but someone still has to know why the load-bearing wall is where it is, what the soil can hold and what happens during a storm, and that someone has to notice when the plans are wrong. Or think about surgeons. Surgical robots have been used in operating rooms for years and they're steadier than any human hand, but nobody would let someone without medical training operate one. The robot doesn't know which tissue to cut and why, or what to do when something unexpected shows up mid-operation. The surgeon does. I don't see why software would be any different. The tools got a lot better, but you still need to understand what you're building and why.

Will we still review code?

Partially, yes, but not the way we've been doing it so far.

I don't think going through a diff line by line, nitpicking variable names or debating whether a for loop should have been a map() will be necessary in the coming months. This kind of review doesn't scale when one person is directing several agents that produce thousands of lines a day. Agents are also already better than most of us at catching the things no linter will ever catch, like a cache that never gets invalidated after an update, or two handlers racing for the same row.

So in my opinion, there will be only a few reasons left to review that work:

• to make sure the constraints were met (did it stay within the module it was supposed to touch, did it respect the architecture, the security model, the performance budget?)
• to check that what was delivered is what we actually wanted, which is a different question than whether the code is correct
• to understand the system as a whole
• to review changes in the critical parts of the system, especially in code that lots of other engineers depend on (a framework, a shared library, an auth layer), where a small mistake affects everyone
• to know how it works under the hood, because sooner or later you'll have to make a decision about this system, and you can't make a good decision about something you don't understand

If you disagree with the last one, think about how many times someone outside of our industry asked you what you're working on. You had to simplify, replace the nomenclature with everyday words, come up with analogies that have nothing to do with code, and sometimes it still didn't work and you just gave up and said it's hard to explain without going into the details. Now imagine making decisions about your own system from that position. That's where you end up if you stop understanding it.

This is the part I care about most. Code review is turning from quality control into knowledge transfer. We won't read code to catch typos anymore, we'll read it to stay in charge.

There's also a simpler reason. An agent can write the code, but it can't be responsible for it. When something breaks in production, nobody is going to accept "the agent did it" as an answer, and it's still your name on what ships.

What's going to disappear?

I think a lot of practices we've been advocating for years were really answers to our own limitations, and once those limitations are no longer the bottleneck, there isn't much reason to keep them around.

Pair programming is the most obvious one. The idea was to put two brains on one problem, one person types, the other thinks ahead, and both catch each other's mistakes. Today a single developer can work with multiple agents at once, each one on a different task, and spend their own attention on directing and verifying. Two people in front of one keyboard doesn't make much sense anymore, at least as far as the typing goes. The other part of pairing, a senior showing a less experienced developer how they think, is still important, and I'll come back to it later.

TDD, as a ritual, is going away too. Writing a failing test by hand, then the minimal implementation, then refactoring, in tiny cycles, was a way to keep us disciplined and make us think about the design first. Agents don't need that kind of discipline imposed on them in the same way.

‼️ Tests aren't going anywhere, though. I'd even say they matter more than before, because a test suite is one of the few ways an agent can verify its own work, and one of the few ways you can verify it without reading every line. What's going away is writing them by hand, first, in tiny red-green steps. ‼️

Then there's DRY. "Don't repeat yourself" made a lot of sense when every duplicated piece of code had to be found and updated by a human, usually in five places, and you'd forget about the sixth one. Agents on their own won't keep your code DRY, they're actually pretty happy to copy and paste. But if you ask one to find duplication across the whole codebase and extract a shared component, it'll do it in a few minutes, so you can do it once the duplication actually becomes a problem. Deduplicating early just in case, or arguing in a code review about the "right" abstraction, isn't worth it anymore. A bit of repetition is cheap now, while a wrong abstraction is as expensive as it always was.

SOLID is in a similar place. It's a good exercise for your brain and I'd still recommend learning it, the same way it's good to know how a CPU works. But you won't be writing most of the classes, and I doubt you'll be the one deciding how all of them interact with each other either. Your job moves up a level, to the boundaries between modules, the contracts between services, and the constraints the agents have to follow.

Will frameworks matter?

You probably expect me to say yes, and I will 🙃 But I think the reasons are a bit different now.

First, frameworks make agents more efficient. An agent working inside a framework doesn't need to reinvent the wheel every time. It doesn't need to write its own dependency injection container, validation layer, module system or error handling. That means less code to generate, fewer tokens, less context to fill, and fewer places where something subtle can go wrong. And every line the agent doesn't write is a line nobody has to verify.

Second, and I think this one is even more important, declarative frameworks make things easier for us too. When an agent changes a NestJS application, the changes land in places you can predict. A new endpoint is a method decorated with @Get() in a controller, authorization is a guard, validation is a pipe or a DTO, business logic lives in providers, and the module tells you what depends on what. If you want to know how a request is handled, you know where to look.

Compare that to an arbitrary Express or Hono application, where every team (and every agent run!) wires things up a bit differently. Some middleware is registered in one place, a helper handles auth somewhere else, a route is defined in a third file. It works, but following and reviewing what an agent did there takes a lot more effort, and following what the agent did is pretty much what our job is turning into.

Conventions used to be mostly about onboarding developers faster. Now they help agents produce more consistent output and help us verify it quickly.

What about new tools?

There's one problem with everything I just said about frameworks. LLMs are naturally biased towards what they were trained on, meaning the libraries with the most GitHub stars, Stack Overflow answers and blog posts. Ask an agent to pick a tool and it'll most likely go with whatever was popular when its training data was collected. That's great for established projects, but a real problem for anything new.

It's a feedback loop. Agents recommend what's popular, so it gets used more, more code gets written with it, and the next generation of models recommends it even more. A better library released last month basically doesn't exist from the model's point of view, so it never gets the chance to become popular in the first place.

I don't think it's a dead end. Agents can read docs, search the web and use tools, so how a project presents itself to agents now matters almost as much as how it presents itself to people. Think docs that are easy for an LLM to consume (like an llms.txt file), MCP servers, skills, and examples an agent can follow. New tools will have to be built so that agents can discover them, not only people, and honestly I don't think any of us has fully figured out how to do that well yet.

This also raises another question: whose decision is it to pick the right tool for the job?

I believe it's still yours, and the bias I just described is exactly why. When an agent picks a library by default, it isn't really making a decision, it's going with what it has seen most often. It doesn't know your team, your constraints, your compliance requirements, or that you already got burned by that exact library two years ago. The stack, the architecture and the dependencies are decisions you need to understand the system for, and you'll be living with them for years. Let the agent research the options and lay out the trade-offs, but make the call yourself.

What's more important than ever?

Observability.

If we're not going to read every line of code, we need another way to know how that code behaves, and the only place you can really find out is production: traces, logs, errors, latency, the background job that silently fails at 4 a.m. That's how we'll verify what agents built, and more and more, it's also how agents will verify and fix their own work, by reading the same telemetry we do.

This is a big part of why we built NestJS Observe. Instead of attaching a generic Node.js agent to your process, it hooks into Nest's own lifecycle (controllers, guards, interceptors, resolvers, queue consumers, cron jobs), so what you see in the dashboard uses the same vocabulary you (or your agent) used to write the code. When you didn't write the code yourself, seeing a request go through your controllers and your providers instead of a bunch of anonymous functions makes a huge difference.

If you're serious about adopting agents, invest at least as much in observability as you do in prompts.

Should you still learn to code?

Yes, definitely.

To communicate with a foreigner, you have to learn their language, and code is the language your agents speak. If you can't read it, you can't tell them exactly what you want, and you can't tell if what they gave you is what you asked for. Without knowing how to code, you'd be steering a ship blind. It might go fine for a while, until it doesn't, and you won't even know why.

What I think changes is what's worth learning. Learning five programming languages instead of mastering one doesn't make much sense anymore, since LLMs translate syntax from one language to another in seconds. What they can't give you is judgement. So instead of knowing how to write a class, a closure or an async iterator in three different languages, make sure you really understand what they are, when to use them and what they cost. Same goes for things below the syntax, like how memory, concurrency and the network behave, what a transaction actually guarantees, or what happens when a dependency is slow or down. That knowledge works in any language and with any agent, and it's what you need to decide whether what an agent built is right.

The problem is that you don't get that understanding just from reading. Nobody became a senior engineer by watching someone else code. You get there by writing code that doesn't work, staring at it until you figure out why, and fixing it. So if you're just starting out, write code by hand on purpose, even when an agent would be faster. The point isn't the output, it's building the judgement you'll need later. And if you're a senior, make sure the people around you still get that chance (this is the part of pair programming I said I'd come back to).

Is it still engineering?

After months of working with agents every day, I have one conclusion. There are still plenty of decisions that have to be made by humans, and people without a CS background, who don't know the software engineering nomenclature, won't be able to work with agents effectively. They won't know what to ask for, they won't understand the trade-offs the agent presents, and they won't notice when something is off.

So yes, I believe it's still engineering. It's different from what we used to do, where we wrote every line of code ourselves, but the hard part was never typing. It was knowing what to build and how the pieces fit together, and that part is still on us.

That doesn't mean nothing changes, though. Some kinds of work will disappear. For example, I don't think agencies that mostly build landing pages for companies will be around much longer. That kind of work is exactly what agents are already great at, and the companies that used to hire them can now do it themselves.

Am I sad?

A little, yes.

It's somewhat terrifying, and I do feel a bit empty. Writing code was never just a job for me, it's what made NestJS exist in the first place. Knowing that most of it will now be done by something else takes some getting used to.

But LLMs aren't going anywhere, and they'll most likely keep getting better, probably faster than we expect. So I don't really see another way around it. We can either wish it were different, or figure out what our role looks like now, which for me is setting the constraints, making the decisions, understanding the system and taking responsibility for what ships.

I'd rather do the latter.