If you work in software you've probably heard this a lot: we need to ship faster (teams usually receive praise for that). PRs that used to take a few days are expected in a few hours. Features that used to take a whole quarter are now squeezed into a single sprint. Managers talk about velocity the way they used to talk about uptime. The reason is obvious. An engineer with a good LLM can spin up a prototype, build out a new service, clean up old code, or write a full test suite in a fraction of the time it took two years ago. So the bar moves. If the tools are faster, the people using them better be faster too.
I think this way of looking at it is wrong. Not because it doesn't make sense (it does). It's wrong because it wastes the real opportunity AI is giving us.
This Time Isn't Different
Let's start by being fair. Software engineers have always been asked to do more over time. Punch cards gave way to assemblers. Assemblers gave way to compilers. Compilers led to high-level languages, then to frameworks like Rails and React, then to IDEs that finish half your code for you before you've stopped typing. At every step, engineers got more productive. And at every step, the industry just asked for more. Nobody today writes raw assembly to build a basic web app, and nobody is sad about that.
So in one sense, LLMs are just the next step in a long line of tools. Asking people to ship more isn't some new betrayal of the job. It's the same pattern we've always had. Fair enough.
But here's where the comparison starts to fall apart.
What LLMs don't do, and probably won't
Every tool before this one helped with doing the work. Compilers didn't decide what to build, they just translated what you'd already decided. IDEs didn't pick your architecture, they just made typing faster. LLMs are different in a subtle but important way. They're great at the middle of the work: the actual writing of code, the boilerplate, the turning of an idea into something that runs. But they're still weak at the two ends.
They don't decide what to build. They don't know which of three possible designs will still make sense in eighteen months after the product has changed direction twice. They don't feel the weight of a choice that will shape the team for two years. They don't notice that the "small feature" a product manager just asked for, if you build it the obvious way, will quietly break the data model. And they don't really have taste. Not in a reliable way. They can't tell you when a system has gotten too clever, or when the codebase has drifted away from what it was originally trying to be.
These are design problems. Judgment problems. Vision problems. They need you to juggle a lot of things at once, most of which aren't written down anywhere. They need you to understand a business, a team, a user, a history and a product vision. An LLM can write the code once you've made the call. It can't make the call well enough.
If our response to AI is to keep engineers doing the same job they did before, just faster, we've taken the hardest-to-automate part of the work and buried it under deadlines. The design work will still happen. It always does. But it'll happen in a rush, squeezed into fifteen-minute gaps between shipping tickets.
Models don't learn from mistakes. People do.
To Err Is AI, To Learn Is Human
There's an idea from Nassim Taleb book that keeps coming back to me when I think about where LLMs actually fit in. Systems come in three flavours. Fragile means it breaks under stress, like your parcel from AliExpress. Robust means it survives stress without changing, like a IKEA furniture naming convention. Antifragile means it actually gets better from stress. Muscles get stronger when you push them. Your immune system gets smarter every time it deals with a new virus. A team with a good postmortem culture turns every outage into something they learn from, and the next quarter's architecture is better because of it. These systems don't just survive a hit. They use it. They need it.
Current LLMs are not antifragile, they're fragile, in a very specific way. If the model writes a subtle concurrency bug in your PR today, it'll write the same bug next week, and the week after, until someone builds something around it to stop it. Maybe a linter rule. Maybe a custom test. Maybe a fine-tuned version of the model. The model itself doesn't learn from being wrong. The correction you give it today disappears the moment the context vanishes. It has no memory of having made the mistake before, so it has no reason to avoid making it again. It doesn't heal. It just tries again.
This isn't a complaint. It's just what the tool is right now. But it changes how teams should be set up around it. Because the engineer, over a career, is the opposite. After you've shipped a database migration that took prod down for two hours, you don't forget. You become the engineer who double-checks every migration before it runs. After a clever abstraction turned into a six-month maintenance headache, you get more skeptical of clever abstractions. Every bug that bit you turns into a gut feeling about a whole class of mistakes. Every bad design you shipped and had to live with becomes taste. An engineer's judgment stacks up over time from real experience in a way that today's LLMs just don't. The human in the loop is the antifragile part.
Move Slow and Fix Things
When a team leans on the LLM like it knows your codebase, your conventions, your weird edge cases, they're leaning on the part that doesn't actually learn. The lesson from last quarter's outage lives in the engineer who ran the postmortem, not in the model. The gut feel for why a certain pattern is risky in your setup lives in the engineer who watched it blow up, not in the model. Pretend otherwise and you end up with teams shipping the same bug over and over, just faster each time, because the tool they're leaning on has no way of catching it.
This isn't forever. There's real work being done today on systems that keep learning, adapt to feedback from production, and get better from failures in ways that stick around. We might get there. But we're not there yet, and building as if we are is a mistake.
Slack Is New The Black
Here's the version of I want us to be building toward. LLMs handle the repetitive, mechanical, boring stuff. The CRUD endpoints. The database migrations. The glue code between two services. The unit tests for logic that's already clear. The docs for APIs that have stopped changing. These are the things that have always eaten up engineering time without teaching anyone much. Good riddance.
What that gets us isn't more tickets closed. It's space. Space to sit with a hard problem long enough to actually understand it. Space to read the paper, build the weird prototype, talk to a user you don't usually hear from, learn the next-door domain your system keeps bumping into. Space to notice that three bugs this quarter are really the same deeper problem. Space to write the design doc that saves your team a year of pain.
And it's not just time we get back. It's reach. An engineer who lives in TypeScript can now actually try building something in Rust or Elixir without first spending weeks just learning enough to be useful. A backend engineer can play with a consensus protocol they've only read about, a database engine they've never used, or a messaging pattern that's new to the team, with the LLM filling in the parts they don't know yet. A generalist can try a WebGPU shader, a weird trick with the type system, a low-level optimisation that used to sit behind a wall of stuff you'd have to learn first. These weren't off-limits because engineers weren't curious. They were off-limits because the cost of getting started was too high for something you weren't even sure would pay off. When that cost drops, the range of things you can try opens up a lot. Most of those experiments go nowhere. A few become things nobody on the team would have thought to build otherwise.
Engineers I know often say the best work they've ever done came from having freedom in their week. Not official "innovation time," just normal weeks where they happened to have an afternoon to chase something interesting. That kind of freedom has been shrinking for a decade. AI could give it back.
Easier Done Than Said
So what does that actually look like? Treat LLM output as a first draft, not a finished product. The engineer's job is to decide whether the draft is actually right. Not whether it runs (it usually does), but whether it should exist in this shape in this codebase. That's a design question, and it deserves the same time and attention it always did.
Measure what you actually want more of. If you measure lines of code shipped and tickets closed, that's what your team will give you. The deep work will starve. Measure things like design quality, fewer incidents, decisions you didn't have to revisit, new skills the team picked up. These are harder to count, which is exactly why they slip away when nobody pays attention to them.
Give engineers real time to explore. Not a hackathon once a quarter. Freedom to dig into things next door to what they normally work on. Systems they've never built. Papers they've never read. Tools they've never tried. This is how engineers turn into people who can make the calls LLMs can't. Cut that off, and in five years you'll have a team shipping huge amounts of average code with no idea why the architecture keeps falling over.
If the only reason to build something is that it's now cheap to build, that's not really a good reason. The extra feature nobody asked for is still more code to maintain. Someone has to pay for that later, and that someone is usually not an LLM.
To Ship or To Think
The real question AI is asking software engineering isn't how much more we can ship. It's what part of this job is actually worth a human doing. The answer, I think, is most of the interesting part. The thinking. The deciding. The designing. The imagining. LLMs are genuinely useful, and any engineer refusing to use them is making a mistake. But engineers (and the companies they work for) who use them just to go faster down the same road are making a bigger one.
Shipping more was never the point. Building the right thing, and building it well, was. AI is the best chance we've had in years to remember that.
Top comments (1)
the speed-to-forget ratio is the biggest hidden cost in dev right now. i usually prioritize vibe first, polish later—but that context debt eventually comes for your neck. still figuring it out in cursor... but honestly? austin taught me: just start the thing and hope your future-self is in a forgiving mood.