I haven't properly written code since around New Year 2026. I want to be precise about what I mean, because everybody says some version of this now and most of them are rounding up. I don't mean "I use autocomplete a lot." I don't mean "an agent writes the boring parts." I mean that the activity on my CV, the thing I get paid for, the thing I spent years getting good at, has left my calendar in 2026.
I still work on software systems all day. Architecture, infrastructure, business logic, integrations, failure modes, deployment, trade-offs, constraints, the eternal question of what the hell the thing is actually supposed to accomplish. I think about all of that constantly.
I usually don't look at the code. Sometimes I review it. Sometimes I open a file because something feels wrong. Occasionally, heroically, I type three lines myself because explaining a trivial change to an agent would take longer than doing it. Those are the exceptions. The code has become something that exists underneath the level where I work, the way an architect can spend a whole day on a building without inspecting a single brick.
And, hey, I'm not saying the machine is trustworthy. Not perfect. Not "give it production credentials, disable the guardrails, walk into the forest and never return" trustworthy. But it is good enough that manually implementing most conventional software has stopped feeling like the useful part of my job, and once that happens to you, you start asking the obvious question.
Are software engineers still needed?
For now, yes. Very much so.
Remember "for now." We're coming back to "for now," and when we do, you're not going to enjoy it too much.
The Code Was Never the Whole Job
Here's the version of this story everyone tells, and I'm going to tell it too, because it's mostly true.
Translating a ticket into Java, Python, TypeScript, Go, or whatever language was fashionable that year was always the cheap part. Anybody could learn it. The valuable part, the part that made a senior engineer worth three juniors, was the judgement wrapped around the code. What should we build? What should we absolutely not build? Where does this logic live? What happens when this dependency dies at 3 a.m., or when two requests arrive in the same millisecond? How do we migrate the old data? How do we ship this without ruining somebody's evening? Which assumption in the ticket is wrong? What part of the business process is nobody mentioning because everyone thinks it's obvious? What's going to balloon and become expensive in six months? What looks fancy af on a whiteboard and turns into operational nightmare in production?
An experienced engineer carries an enormous pile of scar tissue around those questions. That's still valuable. Possibly more valuable than ever, because the machine can now produce a frankly unreasonable amount of the implementation around those decisions. The application code. The tests. The migration, the Dockerfile, the deployment config, the API contract, the documentation, and the slightly weird Bash script that glues the whole mess together. And when something fails, it reads the failure and tries again, without sighing.
So "can the model write this function?" has become a boring question. Usually, yes. The interesting question is whether this is the right thing to build, in the right way, inside the actual environment it has to survive in.
That still needs judgement.
And that's the Comfortable Answer. AI writes the code. Engineers provide the judgement. Problem solved. Profession saved. Everybody gets a nicer title and goes home.
I'm going to spend the rest of this post pulling on that thread until the sweater is gone.
The Implementation Layer Is Already Becoming Machinery
Software engineering is abstraction all the way down, and every layer of it was once somebody's whole job. Most developers don't think about individual CPU instructions. They don't manage registers. They have no idea, and don't want one, how the operating system schedules a thread. A database hides a mountain of complexity, a framework hides another, cloud infrastructure hides a third. We take things programmers used to do by hand and bury them under a layer of machinery, and then we forget we ever did them.
Implementation is turning into one of those layers. For me it already has.
When I need a feature now, I don't open the relevant class and pick which method to write first. I describe the outcome. I explain the constraints. I point an agent at the system. It inspects what's there, makes the changes, runs things, finds problems, fixes them. I step in when the reasoning needs steering, when context is missing, or when a decision has consequences beyond the immediate change. That's already a long way from programming.
Then it gets weirder. After you do this for a while, reviewing every implementation detail starts to feel optional.
Of course I can inspect everything the agent changed. Sometimes I should. Sometimes I absolutely must. But reading every generated line because a machine generated it doesn't scale.
The real requirement was never "a senior engineer read it." The real requirement is confidence, and confidence comes from more places than eyeballs. Tests. Type systems. Static analysis. Integration checks. Runtime constraints. Policy enforcement. Architecture validation. Independent review. Observability. Reproducible verification. Don't worry about the taxonomy. The point is that the moment you start thinking like this, the job mutates again. You stop using AI to write code and start designing the environment in which AI can safely produce it.
And that's where it gets interesting.
The Dark Factory
The name comes from manufacturing. A "lights-out factory" is one automated enough that no human needs to be on the floor. No workers, no reason to pay for lighting, hence the slightly cyberpunk name. This is not science fiction, by the way. FANUC has been running one near Mount Fuji since 2001. Robots building robots. In the dark. For a quarter of a century. Nobody turns the lights on because there's nobody there to need them.
Now apply that to software.
Today, even with genuinely capable coding agents, the normal workflow is still interactive. You open Codex, Claude, Cursor, whatever you like. You give it a task. It works. You answer questions. You steer. It shows you what it did. You ask for changes. It tries again. This is dramatically more productive than typing everything yourself, and it is still, fundamentally, a human sitting at a machine pressing buttons. The dark-factory question is: what if we remove that part too?
Instead of spending an hour babysitting an agent, you hand a system a bounded task and let it manage the work internally. Something like:
task → analysis → planning → implementation → tests → review → repair → verification → result
The exact arrangement doesn't matter much and will be obsolete by the time you read this (lol). One model doing several roles, or five. A strong model planning and cheaper models implementing. Separate reviewers. Deterministic tools doing half the validation. The implementation details keep changing as models get better and cheaper.
The interesting property is the boundary. You say: build this. And eventually the system says: here is what I built, here is what I tested, here are the assumptions I made, here is the evidence it works, and here is what I could not verify.
That isn't AI-assisted development anymore. That's autonomous software production, or something very close to it.
And obviously the first reaction is: well then, software engineers really are cooked.
Perhaps. But go try to build one of these things. I have. Here's where it gets stupid.
"Build Anything" Is a Terrible Specification
The fantasy version of the software factory is universal. I'm going to call it the Build Anything Machine. You throw in a requirement and out comes working software. A mobile app. A banking backend. A game. A Kubernetes operator. A warehouse management system. Firmware. A React dashboard. A payment integration. A compiler. Whatever. Just feed the spec into the slot.
I would love that. It would also solve several other minor problems along the way, such as general artificial intelligence ;)
The closer I look at autonomous software production, the less I believe the Build Anything Machine is the interesting near-term target, and the reason is boring and enormous: software is too contextual.
Picture two companies. Both use Java. Both use PostgreSQL. From orbit they're identical. Zoom in on the first one and it requires:
- strict backwards compatibility
- schema migrations that run with zero downtime
- exhaustive audit logging; PCI-related controls
- deployment through one specific internal platform
- mandatory tracing
- certain libraries and certain authentication patterns
- a peculiar event-driven architecture somebody was once very proud of
- security review before any new dependency
- very specific retry semantics
- restrictions on where customer data is allowed to travel
The second company is an internal SaaS startup where the correct architectural decision is: put it in the existing service and ship it before lunch.
Those are two different engineering environments. Different definition of good software. Different definition of done. Different risk appetite, tools, architecture, tolerance for complexity, business context. All of it different. An autonomous system has to operate inside all of that, and suddenly the hard problem is no longer getting the model to write code. It already writes plenty of code. The hard problem is building the world the code has to live in.
Maybe the Factory Should Be Local
Which made me wonder whether we're chasing the wrong abstraction entirely.
Maybe companies don't need one universal factory. Maybe they need their own: a factory shaped to their architecture, domain, tooling, risk profile and constraints. And maybe even one per company is too broad. Maybe you need several.
Micro-factories.
Yes. I am aware that our industry spent fifteen years turning everything into microservices, and I am now proposing we do the same thing to the developers. I apologise in advance. I'm still going to do it.
Picture a backend-service factory. It knows the standard project structure. It knows which framework version is approved. It knows how authentication works, what the observability stack is, how services get deployed, what the migration conventions are, which internal libraries to use, how events are published, what the CI pipeline expects. And it knows that one particular internal service is cursed and must never, ever be called synchronously, no matter what its documentation claims. Give that factory a requirement and it has a constrained little world to operate in.
Picture another one that only does Salesforce. It knows the company's objects. It knows the historical mess of custom fields. It knows the naming conventions and the deployment process and which workflows are business critical. And it knows which fields technically exist but must never, under any circumstances, be touched, because Gerald built something in 2019 and nobody, including Gerald, knows how it works.
Remember Gerald. Gerald is the whole problem, and we're coming back to him.
Another factory does frontend. Another data pipelines, another infrastructure, another integrations, another migrations, another testing. Make them as narrow as you like. A factory whose entire purpose in life is "safely migrate REST API clients from version N to N+1." Or "take an internal manual process and produce a CRUD app that follows company conventions." Or "build and verify connectors between our platform and approved third-party APIs." Or even "handle this one recurring category of support ticket."
That sounds much less magical than "AI builds any software." It also sounds achievable. And, possibly, useful.
And imagine building a factory, or some kind of AI-manager, capable of operating other factories? Yeah, maybe let's not go into that now...
The Factory Is Mostly Constraints
This is the part I find myself thinking about in the shower.
The naive view of AI coding is that better models solve the problem. Smarter model, better software, go home. And that's partly true: a stronger model needs less supervision, understands bigger systems, makes fewer bizarre decisions, recovers from its own mistakes. Great.
But the moment you try to pull the human out of the loop, intelligence stops being the only interesting variable. You need constraints. A shitload of constraints.
What repositories can the system touch? What APIs can it call? What patterns are allowed, and what dependencies can it drag in? What environments can it reach?
How does it know the implementation actually works? Which tests are mandatory? What counts as enough evidence to declare the task done?
When should it abandon an approach? When should a second model review the work? When does it escalate to a human? Which assumptions must it write down?
How do you stop it from "fixing" unrelated things it happened to notice? How do you stop ten individually reasonable decisions from combining into one deeply unreasonable system? How do you give it enough context without dumping the company's entire accumulated digital landfill into a prompt? How do you tell whether the result is merely syntactically correct or actually appropriate for the business?
These stop sounding like prompting problems within about four seconds. They sound like software architecture problems. Because they are. The factory itself is software. It has policies, interfaces, failure modes, observability, feedback loops, permissions, state, tooling, budgets, escalation paths, trust boundaries. Somebody has to design all of that.
And, most importantly, somebody has to encode judgement.
Turning Tribal Knowledge Into Infrastructure
Every software company is held together by knowledge that exists in no specification anywhere. Some of it lives in documentation. Some lives in code, some in architecture diagrams, some in Slack threads from a channel that was archived. A terrifying amount lives exclusively inside the heads of three people who have been there seven years, one of whom is Gerald.
Experienced engineers swim through that environment without noticing the water. They know the documented API is technically correct and one particular endpoint falls over under load. They know the official database ownership boundaries, and they know the reporting job that violates them every night at 02:15. They know a "simple" change will make finance furious. They know a customer integration depends on behaviour nobody ever intended to become public API.
They know why the ugly code is ugly. Sometimes the ugliness is an accident. Sometimes it's a fossilised workaround holding the entire company together. Current coding agents cannot tell the difference, and if you let one "clean up" the second kind, you'll find out which kind it was at 4 a.m. on a Saturday.
So building a useful autonomous factory is largely an exercise in extracting organisational knowledge and turning it into constraints a machine can actually use. Documentation is the weakest form of that. What you really want is tests, policies, examples, schemas, architecture rules, static analysis, tool permissions, evaluation suites, known failure cases, historical incidents, production telemetry, dependency maps, maybe even simulators. Things that let the system check its own output against the environment it has to live in, rather than against some abstract idea of good software.
And all of that work is unmistakably software engineering. It just isn't the "write the application" kind.
The Engineer Moves Outside the Loop
Follow the direction far enough and the engineer leaves the implementation loop entirely. The typing goes first. Then the need to inspect every implementation decision goes too.
Instead of implementing features, you design the system that implements features. Instead of reviewing every line, you design verification that can reject a bad implementation on its own. Instead of explaining the company's architecture to an agent for the four hundredth time, you encode it into the environment. Instead of decomposing every ticket by hand, you design decomposition strategies. Instead of fixing the same class of model mistake over and over, you change the factory so that mistake becomes hard or impossible to make.
The question shifts from "did the agent write this correctly?" to "what evidence would convince us that this entire class of change is correct?"
That is a vastly more interesting question. It's also architecture, not programming.
At some point the source code becomes one artifact among many that the process spits out, rather than the primary object a human manipulates. And honestly? I find that appealing. I don't miss typing implementation code. The interesting part was never the typing. It was deciding how the system should behave and figuring out how to make that behaviour reliable.
This Has Happened Before
Rewind. Not far by history's standards, seventy-odd years, to rooms full of people writing machine instructions by hand.
Then assemblers took some of it. Then compilers. Then higher-level languages, libraries, frameworks, databases, operating systems, cloud platforms, managed services, infrastructure as code, platform engineering. Every generation removes a category of work that the previous generation considered the essential core of programming, and every generation's grumpiest members insisted it couldn't be done properly any other way and that "this new generation of programmers doesn't know shit".
Nobody building a billing platform today feels professionally threatened because they no longer allocate CPU registers by hand. The compiler does it. Told you it was coming back. We didn't lose the job; we moved the boundary of the job upward and forgot there was ever a boundary there.
Maybe manually implementing application logic joins that pile. Not gone completely. Somebody will always need to go down a layer: performance problems, weird failures, security investigations, novel systems, infrastructure internals. Someone still needs to read assembly or hardware-level C. But needing a skill to exist somewhere in the industry is not the same thing as it being the daily activity of millions of engineers.
That distinction is going to matter a lot.
Unfortunately, This Does Not Mean Everyone Gets Promoted
There's a comforting version of this story, and you've probably already told it to yourself. AI writes the code, therefore engineers ascend to become architects of AI development systems. Everyone keeps their job. Everyone gets a nicer title. We spend our afternoons drinking tea while autonomous agents close Jira tickets.
I would not bet heavily on that.
Abstraction increases leverage. That's the entire point of abstraction. If one experienced engineer can build and operate a set of reliable software factories with the implementation capacity that used to require ten engineers, the company does not automatically need ten factory engineers. Maybe it finds ten times more software to build. That can happen; demand for software is famously elastic, and there are countless internal tools, integrations, automations and weird niche products nobody builds today because the engineering cost doesn't justify them. When production gets dramatically cheaper we will absolutely build more things.
But "we will find infinite additional software work for everyone" is an assumption, not a law. Productivity gains can and do reduce headcount.
And some work is far more exposed than the rest. If your primary economic value is turning a detailed specification into conventional application code, the machines are getting alarmingly good at exactly that, and "I am senior, therefore AI cannot replace me" is not an escape hatch. Seniority is valuable because of judgement, context and responsibility. Those are harder to automate. Harder is not impossible.
Now here's circularity.
If the new engineering job is encoding judgement and context into autonomous factories, then the new job is, quite deliberately, taking the exact things that currently protect senior engineers from automation and teaching the machine how to do them. We are building the thing that makes us unnecessary and calling it a promotion.
That doesn't mean the project is doomed. It means I'd be very careful about declaring any particular abstraction layer permanently safe. Including the one I'm standing on.
So Are Software Developers Cooked?
Maybe.
I find both extreme answers unconvincing. "AI is just another tool, nothing fundamentally changes" gets harder to say with a straight face every month, given what these systems can already do. "Software engineers disappear next year" ignores how much engineering happens outside implementation and how gloriously messy real organisations are. (See: Gerald from above.)
My suspicion is that the profession changes unevenly. Code production gets dramatically cheaper. Direct implementation stops being the centre of the job. Human supervision moves upward. Small teams get ridiculous leverage. Some roles collapse into tooling; others turn into architecture. New work appears around orchestration, evaluation, domain modelling, platform constraints, organisational knowledge, and autonomous development systems. The ratios change. Maybe dramatically.
And maybe what I'm describing, the software-factory engineer, is itself a temporary profession. Maybe in a few years the models build the factories. Maybe companies just buy them. Maybe vendors sell factories specialised for entire industries. Maybe the right architecture looks nothing like what I'm experimenting with today. Maybe "micro-factories" ends up sounding as dated as "SOA governance committee."
I have no idea. That's partly why I find it so interesting. I'm not trying to predict the final shape of software engineering. I'm noticing that the question I personally wake up trying to answer has changed.
The Question Changed
A few years ago the impressive question was: can AI write this code? Then: can AI implement this feature? For me even that one is boring now. I mostly assume it can.
The question I'm asking now is: can I construct a system where AI implements this whole class of software, repeatedly, without me in the room?
Not one task. Not one carefully supervised session. A process. Bounded enough to trust. Specialised enough to understand its own environment. Capable of planning, implementing, checking, correcting, and eventually either handing back a verified result or admitting exactly where it got stuck.
That's a much bigger shift than a better coding assistant. The code becomes an intermediate artifact. The engineering moves into the environment around its production. And if that continues, the important skill becomes designing the machinery that produces software safely, repeatedly and in the right direction. Writing the software itself slides down a layer, next to the registers.
I don't know if those machines will be universal. I suspect not, for a while. Maybe every company gets one. Maybe every engineering org. Maybe a company ends up with dozens of tiny specialised factories, each welded to one narrow slice of the business.
Microservices for code production. God help us.
But if software engineers really are being squeezed out of the act of writing software, there is still one job left that needs doing. Someone has to build the factory.
For now, anyway.
Maybe engineers who build those dark factories will be the ones turning the lights out as they leave for the last time.
