The Future of Engineering with AI
Engineering is shifting to the orchestration layer. This is what I think that means, who it affects first, and why the people dismissing LLMs are about to have a very bad year.
For the past year or so I have had this nagging feeling. Part dread, part urgency. Something about the job was shifting under me and I could not quite name it. I kept reaching for new tools, rethinking how I approach problems, feeling like the ground rules I learned were quietly expiring. It took a while to put it into words, but I finally realized what it is: the work and job of a software engineer is changing in real time, and I honestly do not know what the finished picture looks like.
What I do know is the direction. Steve Yegge and Geoffrey Huntley have been making this case for a while now, and I am fully on board: engineering is moving to the orchestration layer. Not eventually. Not in five years. Right now, today, at companies you have heard of.
Stripe shipped their Minion system. At PayPal, among the systems I work on day-to-day, one of them is an orchestration system. These are not side projects or research experiments. These are real production systems that route work to AI agents, enforce quality standards, and manage context across tasks. The engineer is not writing every line anymore. The engineer is designing the system that writes the lines, setting the constraints, and making sure the output is actually good. That is the job now. And it is harder than most people think.
Specialization is where it gets real
General-purpose coding models are impressive. They are also, by definition, general-purpose. Enterprise codebases do not look like tutorial apps. They have layers of convention, internal frameworks, specific patterns that took years to evolve. A general model does not know any of that.
That is where the opportunity is. Through the work I am doing and from talking to other engineers across the industry, specialized systems with proper quality gates are hitting around 80% accuracy on enterprise codebases. Not in a lab. In production. The model gets fed the right patterns, the right architectural context, the right conventions for that specific codebase, and the output goes from “interesting but unusable” to “this actually ships.”
What gets really interesting is the research happening around self-healing and self-correcting workflows. Geoffrey Huntley formalized one pattern with RALPH loops. But he is one person with one approach. Meta, Google, Anthropic, and plenty of others are all chasing the same thing from different angles: systems that notice when they failed, adjust their own context, and try again until they pass the quality bar. It is not AGI. Nobody is claiming it is AGI. But it turns out that a smart enough model with smart enough tooling around it produces something that functions like intelligence, and at some point the philosophical distinction stops being useful.
Anthropic shipping agent teams is a perfect example. Multiple agents, shared context, collaborating on a single task. That is not a chatbot anymore. That is a system. And the engineer who knows how to design the spec, break the work down, set up context boundaries, and orchestrate the whole thing? That person has building capacity that would have taken a team of five, two years ago.
Which brings me to how I actually work now. I write a spec. I break it into tasks. I save context into a structured memory system and start every task with fresh context. This is not a methodology I am evangelizing. It is just the thing that works. Vague prompts produce vague output. Structured specs with clean context boundaries produce code that ships. Once you see the difference, you do not go back.
Frontend is the canary in the coal mine
This is probably the take that will get me the most pushback, but I am going to say it anyway: the average frontend engineering role is heading toward extinction.
Browser automation is getting scary good, scary fast. AI models already build components well. They style them well. They handle straightforward state management well. That is the core of what most frontend engineers do every single day, and it is exactly the type of work that gets automated first. The role does not vanish entirely. You still need people who can architect complex frontend systems, people who own accessibility at a deep level, creative engineers doing wild custom animations at design studios, and people dealing with heavy client-side business logic (though the trend of companies dumping entire business logic layers onto the frontend is a whole separate rant). But the average “build components, make them look nice, wire up some state” role? That is the most exposed position in engineering right now. The natural path is fullstack. Frontend becomes one skill in a broader toolkit, not the whole job.
And honestly, this is not just about frontend. Every engineer should expect to be a domain expert and an architect within the next year. The floor is rising fast and if you are still thinking of yourself as “just a React dev” or “just a backend dev,” you are standing on ground that is actively disappearing under your feet.
People who say “it just predicts the next word” are not paying attention
This one really gets to me. There is this persistent, smug take floating around that LLMs are “just predicting the next word” and therefore cannot do real engineering. It sounds smart. It is not smart. It is the most dangerously reductive take in the industry right now.
Yes, the base mechanism is next-token prediction. Congratulations, you read the Wikipedia article. Now look around. These “word predictors” are generating photorealistic video. Seedance is producing output that is genuinely insane. Google has built an entire vertical AI stack: text-to-speech, Veo for video generation, Gemini Nano on-device, A2A for agent-to-agent communication, AI Studio for developers, all fully integrated with their cloud platform. That is not a parlor trick. That is a behemoth.
And on the engineering side, look at what is being built around the base models. Memory management systems that scope and retrieve context across long-running tasks. Self-healing protocols that detect failure and retry with adjusted inputs. Quality gates that enforce real standards before output is accepted. Agent orchestration layers that route work to specialized models and coordinate their output. These are genuine engineering problems. Hard ones.
Waving all of that away because the underlying mechanism “just predicts words” is like saying a car is “just controlled explosions” and therefore not real transportation. You are describing the mechanism and missing the system entirely. And the people making that mistake right now are going to be the most surprised when this thing hits them.
Claude 4.5 was when I went all in. I restructured how I work, how I think about building, how I approach problems. Claude 4.6 just confirmed I made the right call.
Cost is a speed bump, not a wall
The biggest friction right now is cost. Frontier models are expensive to run at scale and that limits how aggressively companies can adopt this stuff. Fair enough.
But think about the curve for a second. Six years ago GPT-3 could barely hold a coherent conversation. Today there are autonomous agent teams writing production code, reviewing each other’s work, and shipping it. That is not linear. Humans are terrible at thinking in exponentials because everything else in our lives moves linearly, but this is not moving linearly. It is accelerating.
The moment I am watching for is when open-source models from companies like GLM, Kimi, and Minimax hit frontier quality at a tenth of the cost. When you can get Claude 4.6-level output for the price of a Haiku call today, it is over. The floodgates open. Every company that was “waiting for costs to come down” will scramble to catch up with the ones that were already building. I do not think that moment is far away.
Will everyone make it?
Unfortunately, no. That is just the truth. Not everyone will adapt.
But I do not think the work dries up. The work changes shape. What a single engineer can take on is about to blow wide open, and that means a whole new class of problems becomes worth solving. Problems that nobody bothered with before because the engineering cost was too high. The engineers who come out the other side of this will not be the ones who wrote the most lines of code. They will be the ones who understood what to build and knew how to make the machines build it well.
Dario Amodei wrote The Adolescence of Technology and it is the clearest picture I have read of where we are right now. Not utopia, not doom. A rite of passage that we are going through whether we like it or not. Read it.