Your best engineers will stop writing the business logic

An operator changes how the company behaves on a Tuesday afternoon, and no engineer is in the loop. She isn't writing code, exactly. She's writing down how the work is actually done, the way she'd explain it to a sharp new hire on their first week, and handing that description to an agent that then does the work that way. The thing she wrote goes into production. Nobody opened a pull request. Nobody deployed. By the time an engineer would have picked up the ticket, the change is already handling real cases.

That scene is the whole essay, so it's worth being precise about what did and didn't happen. She didn't touch a database. She didn't get a permission she shouldn't have. She didn't ship anything an engineer hadn't already made shippable, in the sense that the rails she wrote on top of were built, and gated, by someone whose whole job is building rails. What changed is who authored the logic. For most of the history of software, the person who understood the work and the person who could make the computer do the work were two different people, and shipping a change meant translating across that gap. The gap is closing from one side.

I want to be careful, because I've watched this in exactly two industries, insurance and defense-adjacent work, and both are unusually rule-shaped. Insurance in particular is almost nothing but written-down judgment: appetite, guidelines, referral thresholds, the stuff that already lives in a PDF someone emails around. So the leap from "prose that describes the rule" to "prose the machine follows" is short in my world and might be long in yours. Adjust accordingly. But the shape feels bigger than my two examples, so start with what's already public, because the pieces are further along than the discourse suggests.

The primitives already shipped

Anthropic's Agent Skills are the clearest public version of the operator-facing half. A skill is a folder with a SKILL.md file of instructions plus whatever scripts and reference files it needs, and the model decides on its own when a skill is relevant and loads it. The framing in Anthropic's own post is the tell: they compare building a skill to "putting together an onboarding guide for a new hire," and describe the point as capturing and sharing procedural knowledge so agents specialize. That is not an engineering artifact. It's an operator artifact wearing a filename. Anthropic then published the format as an open standard, which is what you do when you want the authoring surface to be everywhere, not just inside your own product.

Now the other half, the connective tissue. Anthropic also shipped the Model Context Protocol, an open standard for wiring agents to the systems where the data and the actions live, described in the docs as a USB-C port for AI applications. When Anthropic open-sourced MCP the pitch was explicitly about replacing fragmented one-off integrations with a single way in. Read the two releases next to each other and the division of labor is forming in public. One layer is procedural knowledge, authored as prose by whoever holds it. The other is the set of tools and connections that make that prose safe to run against real systems, built by whoever builds infrastructure. Skills are what the operator writes. MCP is part of what the engineer builds so the writing has somewhere to go.

Here's the claim I want to defend: operators authoring the business logic is the real shift, not the last decade of low-code with better marketing. I lived through enough of that decade to be suspicious of my own excitement. Every low-code tool I ever touched made me author against a schema someone else drew first. The drag-and-drop canvas, the visual rule builder, the workflow with branches, each was a bounded vocabulary, and the moment my actual rule didn't fit it I was back to filing a ticket. The tool understood its own widgets, not the work, and my job was to translate the work into widgets. What changed is that the authoring surface is now prose, and the thing reading it can sit with ambiguity the way a competent colleague does. I'm not encoding my rule into someone's boxes. I'm describing it, and the runtime interprets a description instead of executing a diagram. Low-code moved the translation step around. This removes one. I'll hold that with caution, because "the model just understands it" is the kind of line that ages badly and I've been burned by demos that only worked on the demo. But the direction is genuinely different from the boxes, and the difference is the part I'd bet on.

The enterprise-agent vendors are drawing the same split into their own products, which is a decent tell that it isn't just my hobbyhorse. Sierra's platform, publicly, ships two authoring surfaces next to each other: Agent Studio, pitched at customer-experience teams to "build and manage agents" without writing a line of code, and an Agent SDK for developers to "develop agents in your existing programming environment and software development lifecycle." One product, two doors. You don't build and market two doors unless you've already decided the two roles are authoring different things.

Skills, not services

Here's the reframe I keep coming back to. For twenty years the way you gave non-engineers power over software was to build them a service: a form, a settings page, an admin panel, a rules engine with a UI. Someone had to anticipate every knob the operator might want, build it, and ship it. The operator's power was bounded by the imagination of whoever built the panel, and the lag between "I need a new knob" and "the knob exists" was most of the drag on the business. A skill inverts that. The operator doesn't ask for a knob. She writes the behavior. The engineer's job stops being "build the specific knob she asked for" and becomes "build the surface where any behavior she writes is safe to run." You go from anticipating requests to constraining outcomes, which is a genuinely different job, and I don't think most engineering orgs have noticed it's the job now.

The frame is right up until someone treats it as a license to skip the hard part. It's correct about where authorship moves and silent about the fact that the surface underneath has to be more constrained, not less, than the admin panel it replaces. An admin panel was safe partly because it was small: you could only push the knobs that existed. Prose has no such ceiling, so a skill is only as safe as the runtime deciding what the prose is allowed to do. I use the frame, but I don't let it flatter me into thinking the engineering got easier. It moved to the part that decides whether the whole thing is safe.

The failure mode is obvious once you name it, which won't stop everyone from walking into it. If you let operators author logic but the runtime underneath will happily do whatever the prose implies, you've built a very fast way to break production in complete sentences. So the interesting engineering is all in the guardrails, and this connects to something I've written before, that human oversight is an architecture and not a checkbox. The agent can propose a change to how the work is done. What it can actually commit, and what fails closed and waits for a person, is a decision the platform makes, not the prose. Anthropic's study of agent autonomy in the wild found around 80% of agent tool calls came from agents with at least one safeguard in place, which tells you the industry already senses the runtime is where safety lives. The prose gets to be creative. The rails do not.

Agent-proposes, human-disposes is the pattern I'd build on, and for operator-authored logic it means something more specific than the version in that other post. Reviewing a single agent action is easy: you see the email it wants to send, you approve it, the blast radius is one email. Reviewing an authored behavior is a different animal, because what you're approving is a rule that will fire on cases you haven't seen yet. You can't eyeball the outcome. You're signing off on a function, not a value. So approving the words isn't enough; the useful review runs the rule against a spread of real-shaped cases so the operator sees where it bites before it's live, and the runtime still holds the irreversible actions behind their own gate even after the rule is approved. The human disposes twice, once over the rule and once over what the rule is ever allowed to actually do. That second gate is what keeps a well-meaning sentence from quietly committing something nobody would have signed off on case by case.

What most companies are getting wrong

I'll say the uncomfortable part. Most companies looking at this ask the wrong question, which is "how do we add agents to what our engineers already do." That keeps the engineer in the middle of every change and just makes the middle faster. The sharper mistake underneath it is about who the user is. When a company builds an internal agent platform, it almost always builds it for engineers, because engineers are the people in the room when the platform gets scoped. So the platform gets a great SDK, good logs, a nice deploy story, and no serious authoring surface for the person who actually holds the domain knowledge. The operator stays a customer of the engineer instead of a user of the platform. That's the error. The user of an agent platform is supposed to be the person who understands the work, and if it can't be handed to them without an engineer standing behind them, you built a faster middle, not a new shape.

The best agent-native writing pushes on the same nerve, framing it as designing the organization around agents from scratch rather than retrofitting them into existing processes, with a small human team steering a large array of agents. A lot of that genre is further over its skis than I'd go on my two industries. But the core move, reorganize around who authors the work rather than around who can code, is the one I'd stand behind.

There's a real objection here, the one I find hardest. If operators author the logic, you've just moved the bugs, not removed them. A subtle error in a written-down rule is still a subtle error, and now it was written by someone who can't read a stack trace to see why the thing did something surprising. True. My honest answer is that it relocates the failure to a layer where the person who owns the domain can actually see it, which beats three functions deep in code they'll never read. I believe that about seventy percent. The other thirty is where I'd warn people off. It goes badly when the domain owner mistakes fluency for correctness, writes a rule that reads beautifully and is quietly wrong, and no engineer is left in the loop who'd have felt the wrongness in the diff. Prose hides bugs better than code, because it never fails to compile. The relocation only pays off if the layer it moves to has the review and the replay and the gates I keep going on about. Skip the factory, and you haven't made the bug visible. You've moved it somewhere nobody's looking and made it sound confident.

And there's a version of this argument that's just insulting to engineers, so let me not make it. Nobody's job is going away. The most senior person I know spends almost none of their time writing business logic already. They spend it deciding what should be impossible.

What engineering becomes

So here's where I've landed, for now. The interesting engineering job stops being the authorship of what the company does and becomes the authorship of what the company can do. You build the factory. You build the guardrails that make it safe to hand to someone who doesn't know how the machines work. You decide what fails closed. That is not a smaller job. It's a stranger one, and you measure yourself less by the features you shipped than by the range of things other people shipped safely on top of you, and by how few of them blew up.

If you make me say what I actually believe, stripped of the hedging: the best engineers become the authors of what stays impossible. The prestige moves from the cleverness of the logic you wrote to the trustworthiness of the space you drew for other people to write in. That's a quieter kind of work, and a lonelier one, because the thing you're proudest of is the disaster that didn't happen in a rule you didn't write. I could be wrong about the timeline, and I'm nearly certain I'm wrong about the details. I've only really watched this in two industries, and both were already made of written-down judgment, which is the easiest possible case for the argument I just made. Maybe in messier domains the translation step never goes away and I'm generalizing from the two places it was always going to work first. That's the honest shape of my confidence. But if I had to bet where the interesting engineering goes, I'd bet it goes here, toward building the floor and handing everyone else the room.