Every few months there's another headline that AI is coming for programmers' jobs. It's the wrong panic, pointed at the wrong noun. AI didn't come for software engineering. It came for the narrowest part of programming — turning an already-decided task into working syntax, the job traditionally (and unkindly) called being a "code monkey." That job is a very good candidate for automation, because it was never actually software engineering to begin with.
What that role actually does
The role is real, even if the term is unkind: someone handed a spec — a ticket, a wireframe, a Stack Overflow answer to adapt — who turns it into working code in a specific language and framework. That's a genuine, teachable skill, and it's exactly what a twelve-week coding bootcamp is built to produce, because it's the part of programming you actually can teach in twelve weeks: syntax, a stack, enough pattern-matching to get a common task done. There's nothing shameful about that skill. It just isn't the whole job.
What matters most here is scope, not skill. This role works inside the boundary of the ticket — that's the job as designed, not a personal failing. Nobody hands a junior developer the full architecture diagram; they hand them a ticket small enough that they don't need to know why the requirement exists or what happens to the record after it leaves their function. That's a silo by construction, and for a narrow, well-specified task it's even a feature — it's what lets a team of thirty people move in parallel without everyone holding the whole system in their head at once.
What software engineering actually is
"Engineering" implies applying a body of knowledge — algorithms, data structures, complexity, systems design, failure modes — to a problem that doesn't arrive pre-solved. A real engineering problem starts out ambiguous: a business process nobody has fully written down, a load nobody has tested for, constraints that conflict with each other in ways the person writing the ticket didn't notice. Answering it means stepping outside the ticket's walls on purpose — understanding not just what this piece is supposed to do, but what calls it, what it calls, and what quietly breaks two services away if it behaves even slightly differently than everyone assumed. The engineer's actual job is deciding the shape of the solution before a single line of code gets written — the data model, the algorithm, which trade-offs to accept on purpose, what happens when a dependency fails at 2 a.m.
Code is the artifact that comes out of that thinking. It was never the thinking itself.
What AI actually automated
Large language models are trained on an enormous corpus of "here's a described task, here's working code for it." That's precisely the code-monkey skill: pattern-match a specified problem to syntactically correct code in a known language and framework. It's not a coincidence AI is good at this — it's exactly the shape of problem these models are built to excel at. What a model can't do on its own is notice that your data model doesn't fit the business's real access pattern, that the "obvious" architecture won't survive a compliance requirement nobody mentioned, or that the ticket is solving the wrong problem entirely. That gap is exactly why AI-written code needs more testing, not less — nothing is checking its output against the parts of the problem that were never written down.
A model is fluent, not judged.
It's the same silo problem, just faster — though a shrinking one. Newer tools can hold more of a repository in context, trace a call across a dozen files, and sketch a rough plan before writing anything, which is a real improvement over a model that only sees the ticket. But a wider context window still isn't the whole picture: it doesn't contain the compliance requirement mentioned in a meeting six months ago, the rate limit on a third-party API nobody documented, or the reason last quarter's "obvious" fix got reverted. AI didn't remove the need for someone who holds that bigger picture — it removed the implementation friction that used to force that person to slow down and look before a locally plausible decision could spread through the system.
Why the two jobs looked identical for forty years
Here's what actually hid the difference: even after the design is right, writing the code by hand still takes a long time. A senior engineer with the right architecture already worked out and a bootcamp graduate translating a well-scoped ticket spent most of their visible working days doing the same thing — typing into an editor. From the outside, on a resume, and in a 45-minute interview, that looked like the same skill measured at different speeds. That's exactly why the industry built hiring pipelines around timed algorithm puzzles and syntax recall: a coding test measures how fast someone produces correct syntax under pressure — a reasonable enough proxy for junior output, but a weak one for the planning and judgment that separates a junior from a senior. The test wasn't wrong because it measured the wrong skill for a junior — it was wrong because everyone kept using it to hire seniors too.
Why the silo used to be safe, and isn't anymore
Twenty years ago, the blast radius of ticket-level implementation work was usually small — a monolith, one database, a release a human read line-by-line before it shipped. Get a ticket wrong and the failure was more likely to stay local — a broken screen, a bad report, a defect QA could reproduce without tracing events across six services. The walls around the silo mostly held because the system behind them wasn't that complicated either.
That's not the system most tickets get written against anymore. A typical production stack now spans a dozen services owned by different teams, several third-party APIs, an event queue or two, and increasingly an AI pipeline stitched into the middle of it. The number of places a locally-correct change can cause a system-level failure has gone up, not down — a retry policy that looks fine in isolation can take down a downstream service under load; a schema change that passes its own tests can silently break a consumer three hops away that nobody on the team even knew existed. Complexity didn't shrink to fit the silo. It grew past it.
That's exactly why staying inside the silo stops being safe at the moment it's needed most. The ticket-bound model quietly assumes someone else is holding the whole picture — the architecture, the failure modes, how this one ticket ripples through everything it touches. In a simple system, that assumption mostly held by accident. In a genuinely distributed one, it doesn't anymore — somebody has to actually do the job of understanding how the pieces fit together, on purpose, or the system quietly accumulates failures that never trace back to a single bad ticket.
Why the bootcamp on-ramp is collapsing
The bootcamp business model sold a specific outcome: learn a stack, build a portfolio, get hired as a junior developer writing small, already-scoped tickets. That junior role — take a well-defined task, produce working code for it — is the part of the workflow AI can now perform fastest and cheapest. It's not that "coding jobs are disappearing." It's that the specific, narrow slice of the job the bootcamp model was built to produce is exactly what's being automated out from under it.
What most short bootcamp programs can't teach deeply — because it doesn't fit into twelve weeks — is the discipline underneath programming: algorithms and complexity, data structures, distributed-systems failure modes, modeling a domain that doesn't map cleanly onto a database schema, reasoning about a system under load it's never seen. That was always the part of the job built on two things a bootcamp can't compress into twelve weeks: real fundamentals, and the judgment that only comes from years of practice applying them. It's also exactly the part that's more valuable now, not less, because it's the part AI still needs a human to supply.
What this changes, in practice
For hiring, it means retiring the test that measures the wrong thing. Stop treating routine syntax production under a clock as the main test — a model can now generate much of that work in seconds. Test whether they can take an ambiguous problem and land on the right shape of solution, without staying inside the walls of the ticket: why this data model and not the obvious one, what breaks first at ten times the load, what breaks somewhere else entirely if this piece behaves even slightly differently than assumed, what they deliberately chose not to build and why. That's the same argument at the center of why a timed coding test is the wrong tool for hiring a senior engineer — it was already true before AI. AI just removed the excuse for still doing it the old way.
For anyone starting out, the traditional on-ramp — learn a framework, build a few portfolio projects, get hired as a junior writing tickets — is broken, because that junior role is what's disappearing first. The more durable path runs through the fundamentals earlier than it used to: why an algorithm runs in O(n log n) instead of just memorizing one, why a queue decouples two services instead of just knowing an API for it. That was always the longer, harder path. It is now the most durable path toward work AI cannot perform independently.
Where this leaves you
The code monkey's job — translate an already-decided design into syntax — is a genuinely good candidate for automation, and AI is already doing a real version of it. Software engineering — deciding what the design should be, catching what a fluent AI-generated answer gets subtly wrong, owning the trade-offs a model has no way to know about — isn't going anywhere. It's the part of the job we've always been hired for. If you're evaluating a team, a candidate, or an AI-assisted build and you're not sure which of these two jobs you're actually looking at, tell us what you're building and we'll give you a straight read.