AI-Native Systems Architect – Silas Reinagel

Bear Off First

Thu, 09 Jul 2026 09:00:00 +0000

Ten projects at eighty percent is zero projects shipped. You can push work forward across a dozen fronts and feel like a machine, but until something crosses the finish line, you have delivered nothing. In backgammon, the only move that actually scores is bearing off, removing a piece from the board entirely. Everything still in play is exposed and worth nothing until it gets home. Finishing one thing beats advancing ten.

The Board Is Full, Nothing Is Scoring

Why does everyone have fifteen things in flight? Because starting feels like progress. You open a new workstream, draft a new doc, spin up a new prototype. Each one delivers a little hit of momentum. Your board looks busy. Your standup sounds productive.

But here’s the thing about backgammon: you don’t win by having the most pieces in play. You win by getting pieces off the board. The game calls it “bearing off.” You move a piece all the way around, bring it home, and remove it from the board entirely. That piece is done. It’s scored. It can never be taken away from you.

Everything still sitting on the board? It’s at risk. Your opponent can knock it backward. You can get blocked. All that forward progress can evaporate in a single turn.

Shipped work is the only work that counts. I call this the Backgammon Principle: the move that finishes one thing is always worth more than the move that advances five things.

Every Open Project Is Exposed

Unfinished work isn’t just sitting there waiting patiently. It’s costing you.

Think about what happens to a piece that’s sitting out on a backgammon board by itself. It’s vulnerable. Your opponent can land on it, knock it off, and send it all the way back to the beginning. All of that forward progress, gone.

Your half-built feature works the same way. A priority change kills it. A reorg reassigns the team. Requirements drift while it sits. Even without any big disruption, context just quietly decays. Every day that passes means more ramp-up time when someone finally comes back to it. The cognitive cost of juggling multiple open threads is well-documented, but the strategic cost might be worse: work-in-progress is liability dressed up as progress.

Finished work can’t be taken back. That’s the asymmetry that matters. Completed work is permanent value. Unfinished work is temporary position that can be wiped out at any time.

Finishing Compounds, Spreading Collapses

Here’s the calculation most teams get wrong. You have a week. You can either:

A. Advance five projects by 20% each. B. Finish one project entirely.

Option A feels more productive. Five things moved forward! But at the end of the week, you’ve actually delivered zero value. Five things are still sitting on your board. Five contexts to keep loaded. Five things that could get knocked backward by the next reorg or strategy pivot.

Option B delivers one complete unit of value. It’s shipped. It’s working. It’s off your board. And now your attention is fully available for the next thing. Cycle time drops because you’re not paying context-switch tax on four other threads. Flow improves because you’re moving one piece through the whole pipeline instead of clogging five stages with five pieces.

This math compounds over time. A team that finishes things builds up a growing pile of shipped value and a shrinking list of obligations. A team that advances things builds up a growing pile of obligations and a shrinking capacity to deal with any of them. This is why forward flow works. It optimizes for throughput of completed improvements, not throughput of activity.

How to Play Bear-Off

The tactics are simple. The discipline is hard.

Finish what’s closest to done. Look at everything in flight. Which item is nearest the finish line? That’s your priority. Not the most exciting thing. Not the newest thing. The one that’s almost across the line. Any backgammon player will tell you: move the piece that’s almost home before you start developing a new one.

Stop starting. Before you begin anything new, ask yourself: is there something I could finish instead? If yes, finish it. Starting is cheap and it feels great. But finishing is where all the value actually lives.

Make done smaller. If a piece of work is too big to finish this week, break it down until a shippable slice fits inside a day or two. Ship the small piece. Then tackle the next one. Microtasking is the mechanical version of this same instinct: chop the work into units that can actually cross a finish line.

Count your work-in-progress. Every item that’s open and unfinished is exposed. Every one carries risk and maintenance cost. The fewer open items you’re carrying, the stronger your position. Specification is the bottleneck in most delivery systems, and specifying five things at once means none of them get specified well enough to actually finish.

Shipped Beats Started

The world rewards output, not activity. Your customers can’t see your board. They don’t know about your twelve in-flight initiatives or your ambitious roadmap. They only see what you’ve shipped: the features that work, the products they can use, the problems that got solved. Everything still in progress is invisible to them.

An agent running five tasks in parallel looks productive. A team with thirty open tickets looks busy. A founder with ten initiatives looks ambitious. But the person who shipped something today has the only kind of progress that’s real. No invisible work, and unshipped work is the most invisible work of all.

Bear off first. The board will still be there when you’re ready for the next piece.

Forward Flow

Wed, 24 Jun 2026 09:00:00 +0000

Most development pipelines optimize for the wrong thing. They optimize for correctness theater. Lengthy review cycles, bikeshed comment threads, approval queues that exist to make managers feel safe. The actual goal of a software delivery pipeline is simpler and more aggressive than that. Every merge makes the software better. Never worse. Everything else is overhead.

The One Rule

A healthy SDLC maximizes positive-improvement throughput. That phrase carries weight, so let me unpack it.

Positive-improvement throughput means: the rate at which incremental improvements reach production. Not the rate at which code is written. Not the rate at which PRs are opened. The rate at which the software gets better in the hands of users. I wrote about the principle of flow years ago. The principle hasn’t changed. What’s changed is that we now have operators fast enough to expose every ounce of pipeline drag.

Every merge should leave the product in a better state than before. If a change introduces a bug, a regression, a usability problem: block it. Rework it. That’s the only valid reason to slow down.

Everything else flows forward.

What Gets Blocked

The bar for blocking work is high and specific. A PR gets blocked when it would make the software worse:

It introduces a bug that didn’t exist before
It regresses performance, reliability, or correctness
It creates a usability problem users will hit
It ships an incomplete unit, something half-built that a user would encounter in a broken state

That last point matters. Every unit of work that reaches production must be complete and workable as-is. It doesn’t have to be the final form. It doesn’t have to cover every edge case. But it has to function. If the feature isn’t ready for users, it lives behind a feature flag until it is. The enforcement layer here is automated architecture tests and CI gates, not human vigilance.

What Flows Forward

Everything else. Specifically:

A PR that makes the software incrementally better, even if it’s small, even if you’d do it differently, even if there’s a follow-up improvement someone already sees: that PR merges. You don’t hold incremental improvement hostage to imagined perfection.

This means non-blocking comments are the default. A reviewer who sees a potential improvement doesn’t block the merge. They note it. If it matters, it becomes a ticket. If it doesn’t matter enough to ticket, it doesn’t matter enough to block. This is why code review as a practice is dying. The gatekeeping version of it, anyway. Product review lives. Blocking-comment review is drag.

Discovered Work Gets Ticketed, Not Hoarded

Here’s where most teams leak value. During implementation or review, someone spots related work. A better abstraction. A nearby refactor. A feature evolution. A test gap.

The wrong move: stuff it into the current PR. Expand the scope. Delay the shipment of something that was already an improvement.

The right move: create the ticket immediately. The moment the work is known, it enters the backlog. Not in someone’s head. Not in a comment that gets buried. In the system, ready to be prioritized and picked up.

This requires frictionless ticket creation. If making a ticket takes more than thirty seconds, the system is broken and discovered work will silently die in comment threads. Back-and-forth is the bottleneck in most delivery systems, and the #1 source of back-and-forth is discovered work that has no home.

The Fixup Heuristic

Not all discovered work should become a ticket. Some of it is trivial. A typo, a missing null check, a rename that takes fifteen seconds.

The rule: if the fix is fast and cheap, fix it now. If it would delay the shipment of the current improvement by any meaningful amount of time, cost, or effort, ticket it.

This heuristic works identically whether the operator is human or AI. An AI agent that can fix a lint error in two seconds should fix it. An AI agent that would need to restructure three files to address an improvement idea should ship what it has and create a follow-up ticket.

The boundary is effort relative to the value of shipping the current improvement now. Specification is the bottleneck, and shipping a clear, complete unit of specified work today beats shipping a sprawling half-specified mega-PR next week.

Same Pipeline, Any Operator

Forward Flow is operator-agnostic. The pipeline doesn’t care whether a human opened the PR or an agent did. The rules are the same:

Does it make the software better? Merge.
Does it make the software worse? Block and rework.
Is it incomplete? Feature-flag it or break it smaller.
Did you discover related work? Ticket it.
Is the fix trivial? Just fix it.
Would the fix delay shipping? Ticket it.

Humans and AI agents operate inside the same system with the same constraints. The pipeline is the authority, not the operator’s identity. This is why the operator role matters more than “developer” or “AI” as labels. The person running the pipeline has one job: keep improvements flowing forward and catch regressions before they land.

Velocity Comes From the Pipeline, Not the People

Teams that ship fast don’t have faster typists. They have pipelines that refuse to accumulate drag. Every blocking comment that could have been non-blocking is friction. Every improvement idea that lives in someone’s memory instead of a ticket is lost work. Every PR that sits in review while someone debates naming conventions is a completed improvement rotting in a queue.

A great SDLC pipeline flows fast, and faster. Throughput increases over time because the pipeline itself is being improved by the same principles it enforces. Each process improvement (faster CI, better auto-review, lower-friction ticket creation) is itself an incremental improvement that flows forward. The same close-the-loop principle that makes agents effective makes pipelines effective: tighten the feedback cycle, ship, measure, repeat.

Forward Flow is the pipeline improving the pipeline.

The velocity ceiling isn’t talent. It isn’t tooling. It’s the drag your process imposes on work that’s already good enough to ship. Cycle time is the product, and Forward Flow is how you protect it at the PR level.

Remove the drag. Let improvements flow.

AI Natives Won't Use Your Web App

Thu, 04 Jun 2026 09:30:00 +0000

AI-native users do not want another web app. They already live in Cursor, Codex, Claude Code, Claude CoWork, and whatever agent workspace holds the day’s context. If your product makes them create another account, learn another dashboard, and remember another place to check, you are asking them to work backwards. They want to connect once, grant narrow authority, and call your service from the place where the work is already happening.

The old SaaS motion was obvious: get the user into the app.

Drive the click. Capture the signup. Run onboarding. Teach the dashboard. Send lifecycle emails. Create daily active usage. Pull the customer back to your surface as often as possible.

That made sense when the browser was the operating environment. The web app was where the user saw the facts, made the decision, and pressed the button.

That era is ending for serious operators. I wrote that web pages are not the future because agents need capabilities, not pages. The customer version is harsher: AI-native people do not want to browse your product. They want their agent to use your product.

The app is no longer the destination.

The app is a connected capability.

For an AI-native user, login belongs in the wiring closet.

They will tolerate one OAuth flow. One permission review. One moment where they decide what your service is allowed to do. After that, asking them to come back to your web UI is a tax.

Every repeated login says your product has not learned the new shape of work.

The new expectation is simple:

Connect the service to Cursor, Codex, Claude Code, Claude CoWork, or whatever agent workspace owns the day.
Expose the capabilities in a way the agent can discover.
Scope the permissions.
Let the user invoke the work from wherever intent appears.

The agent workspace is where context, tools, credentials, rules, and outputs converge. Asking an AI-native user to leave that workspace to operate your product is like asking a surgeon to leave the operating room to sharpen a scalpel.

Maybe they will do it once.

They will resent it every time after that.

Product Surface Moved

The product surface used to be the UI.

Now it is the agent’s tool list, capability schema, permission boundary, and result format. Your beautiful dashboard still matters for exploration, administration, and exceptions. Daily usage moves somewhere else: intent in, action out.

This is the practical consequence of agentic shells becoming the application layer. If the user’s work happens inside an agentic shell, your product must show up there as a first-class capability. A real tool. Real data. Real actions. A result the agent can verify.

Capability discovery becomes onboarding. A good integration tells the agent what can be done, which parameters matter, what permissions are required, what the outputs mean, and when a human must approve. The same reason your AI agent needs a menu applies to every SaaS product now: invisible capabilities do not exist.

If your product has a powerful feature but no agent-readable description, it is hidden.

If your product requires a human to remember where the feature lives, it is hidden.

If your product requires five clicks and a table export before an agent can use the data, it is hidden behind motion waste.

Connect Once, Use Everywhere

The shape is already visible.

The user connects your service once. Your integration exposes a narrow, discoverable set of actions. The agent workspace stores the connection, respects the permission boundary, and makes the capability available where work happens.

The user stops thinking, “I should go open that web app.”

They start thinking, “Have my agent do it.”

That requires more than an API.

You need authentication that survives real use without spraying secrets into model context. You need scoped permissions. You need audit logs. You need a result contract the agent can understand. You need a capabilities endpoint or MCP server that describes the product in operational terms, not marketing terms.

Security architecture stops being a backend detail here. Agents cannot leak keys they never see, so serious integrations broker authority instead of handing raw credentials to the model. The agent can request action. The architecture decides what authority reaches the outside world.

That is the bar for AI-native SaaS:

Connect once.

Describe capabilities.

Broker authority.

Return proof.

Stop Optimizing for Visits

Stop measuring visits like they prove value.

Measure completed work from the user’s workspace.

If the user asks, “Summarize churn risk across Stripe, HubSpot, support tickets, and product usage,” your analytics product should not reply with a link to a dashboard. It should return the summary, the evidence, the accounts at risk, and the next actions. That is how products become one message away.

If the user asks, “Create a campaign from these notes, route it for approval, and schedule it for next Tuesday,” your marketing product should not require six screens of manual assembly. It should expose the workflow as a capability with explicit checkpoints.

If the user asks, “Which candidates need follow-up before Friday?” your recruiting product should not demand a login, a saved view, and a CSV export. It should answer from the source of truth and cite what changed.

Every time the answer is “open the app,” ask the AI-native question: why can’t AI do it?

Sometimes the answer is safety. Good. Add an approval gate.

Sometimes the answer is missing context. Good. Build the connector.

Sometimes the answer is product ego. Bad. Kill the ego.

Build for the Agent Workspace

Web apps are not going away. Humans still need places to explore, configure, review, audit, and recover. A great web app remains valuable.

But the cockpit moved.

For AI-native users, the browser is no longer the cockpit. The agent workspace is the cockpit. Your product is one instrument in that cockpit, and the user expects it to respond when called.

The companies that understand this will build integrations people barely notice because the work just happens. The companies that miss it will keep fighting for tab attention in a world where the best interface is the one the user never has to open.

AI natives will not use your web app.

They will use your product from their workspace.

Everything Should Be One Message Away

Thu, 28 May 2026 09:00:00 +0000

Management was a routing technology before it was a leadership philosophy. When a company got too large for one person to see the whole board, hierarchy became the compression layer: managers collected signals, filtered noise, relayed priorities, and checked whether the work happened. The internet connected everyone, but it did not make the company legible or executable from one place. AI changes that, because the right workspace turns almost every information-bound task into one message away.

The old company was built around distance.

Distance between the question and the answer. Distance between the decision and the person with context. Distance between the strategy and the hands that could execute it. Distance between the customer signal, the dashboard, the Jira ticket, the code change, the deployment, and the person accountable for the result.

Hierarchy existed because distance had to be managed.

One person could not monitor every customer, every metric, every project, every failure mode, every employee, every commit, every sales call, every incident, and every promise. So companies built layers. Directors watched managers. Managers watched teams. Teams watched tools. Tools watched fragments of reality.

Then mandates moved the other direction. A CEO said something. An executive translated it. A director scoped it. A manager assigned it. A team interpreted it. A ticket appeared. Someone did the work. Eventually.

This was not stupidity. It was an information architecture.

The internet made the pipes faster, but it did not remove the routing problem. Everyone got email. Everyone got Slack. Everyone could technically message everyone else. But the actual operating knowledge of the company still stayed scattered across people, dashboards, tools, meetings, documents, and private memory.

That is why real-time chat created so much noise. I wrote years ago about how Slack harms projects because messaging without completed context just accelerates interruption. It gives you low-latency communication, not low-latency execution.

The same pattern shows up in lean terms as motion waste: every back-and-forth needed to transfer information before work can happen. A status meeting is motion waste. A “who knows this?” thread is motion waste. A manager manually translating a goal into six different tool updates is motion waste.

AI-native organizations attack motion waste directly.

Message Distance Is the New Org Chart

The important metric is no longer headcount, reporting depth, or meeting cadence.

The important metric is message distance.

How many messages does it take to answer the question?

How many messages does it take to change the system?

How many messages does it take for a strategy to become a shipped artifact?

In the old model, “What is happening with enterprise onboarding?” might require a director, two managers, one analyst, one support lead, three dashboards, and a follow-up meeting. In the AI-native model, the correct answer is one message:

“Summarize enterprise onboarding risk this week across HubSpot, Linear, Slack, support tickets, call transcripts, and production logs. Include the three accounts most likely to slip, the blockers, the owner, and the next action.”

That query should return the answer.

Not because the model is magical. Because the company has done the work to make the company queryable. The data is connected. The permissions are scoped. The terminology is documented. The agent can reach the systems where reality lives.

This is why data connectors unlock everything else. A disconnected agent turns the founder back into the lookup service. A connected agent turns the company into a surface area for questions.

The same rule applies to execution.

“Create a weekly churn risk report” should not become a project proposal, a planning meeting, a dashboard ticket, a handoff to data, and a follow-up thread asking whether the report is ready. It should become one message to the right agent in the right workspace:

“Build the weekly churn risk report. Use Stripe, product usage, support tickets, and CRM stage changes. Draft it in the executive format. Schedule delivery every Monday at 8 a.m. Send me the first run for review.”

That does not mean the agent gets unlimited power. It means the agent workspace contains the tools, context, credentials, and guardrails needed for that class of work.

Every missing connector, missing permission, missing glossary, missing playbook, and missing verification step adds another hop.

Hops are latency.

Hops are distortion.

Hops are where companies leak execution.

Stop Being the Routing Layer

Most leaders are still the router.

They ask the question. Someone sends a partial answer. They ask another person. Someone pastes a screenshot. They compare it against a dashboard. They message a team lead. They carry context from one thread into another. They summarize the summary. They decide. Then they spend the rest of the week making sure the decision survived translation.

That job felt inevitable because no tool could hold enough context to replace the routing layer.

Now the routing layer is software.

When you spend forty-five minutes gathering facts for an agent, you are the human API. When a person has to translate the same instruction into five operational systems, they are the human orchestration layer. When a manager has to ask three people for status before answering a customer, the company is still organized around human relay.

That is the wrong shape now.

The right question is the one I keep returning to: why can’t AI do it?

If AI cannot answer the query, what is missing?

If AI cannot execute the task, what is blocked?

If AI cannot verify the result, what loop is open?

Each failure identifies a structural defect in the company. Not a model defect. A company defect.

No access. No context. No tool. No permission. No rubric. No owner. No eval. No source of truth.

Fix those, and the hop count drops.

One Message Does Not Mean One Human

The one-message company is not a cult of the omniscient CEO.

It is the opposite. It is an organization where information is externalized enough, tools are connected enough, and agents are specialized enough that the right work can be routed directly to the right executor without ceremony.

Sometimes the executor is a person.

Sometimes it is an agent.

Often it is both: a person supplying intent and judgment, an agent gathering context and doing the mechanical work, an operator verifying the output. That is why operators are the missing role in serious agent systems. The human does not disappear. The human stops being the courier.

This is also where naive automation breaks. “One message away” only works when the message contains enough intent. AI did not eliminate the need for specification. It made specification the bottleneck. The better the company gets at expressing intent, constraints, defaults, and success criteria, the more work becomes directly executable.

The future org chart is not a pyramid.

It is a capability graph.

Nodes are people, agents, tools, datasets, playbooks, evals, and approval boundaries. Edges are explicit permissions and communication paths. The goal is not to make everyone report to one person. The goal is to make every important query and every information-bound task reachable through the shortest safe path.

The shortest safe path should usually be one message.

Build for One-Hop Work

Here is the operating standard:

If a task is software-bound or information-bound, it should be one message away from done.

Not one meeting. Not one planning cycle. Not one chain of status updates. One well-formed message to the correct person or agent, in a workspace where the necessary context and tools already exist.

If that sounds impossible, good. The impossibility is the map.

Ask what would need to be true:

What data source has to be connected?
What tool has to exist?
What permission can be safely granted?
What context needs to be externalized?
What rubric would let an agent verify the result?
What operator owns the line?

Then close one gap.

The work compounds. A connector built once can answer a thousand future questions. A playbook written once can steer a hundred future runs. A verification harness built once can let agents close the loop without dragging a human back into the sensor role.

This is the AI-native company: not fewer humans, but fewer relays.

Fewer handoffs. Fewer translations. Fewer meetings whose only purpose is moving information from one skull to another.

Everything queryable.

Everything routable.

Everything executable.

One message away.

Deterministic Shells Control, Agentic Shells Explore

Tue, 26 May 2026 09:40:00 +0000

Every AI agent has a boss. Sometimes the boss is ordinary application code, calling the model for one bounded judgment. Sometimes the boss is the model, deciding what to inspect, what to call, and when to stop. That choice decides the failure mode before the first prompt ever runs.

Name the Boss

A deterministic shell is normal application code with a model call inside it. Your code owns the route. It decides the states, permissions, retries, validation, storage, and UI. The model gets a bounded job: classify this ticket, summarize this transcript, extract these fields, draft this reply, explain this metric.

The model is a component. A powerful component, but still a component.

An agentic shell puts the model in charge of the loop. It reads the task, picks the next move, calls a tool, reads the result, and keeps going. Cursor, Claude Code, OpenClaw, NanoClaw, and similar systems are execution environments for that loop. Files, browsers, terminals, APIs, and code become things the model can reach.

The Agentic Shell matters because the control plane moved.

Deterministic Shells Are for Known Roads

Reach for a deterministic shell when the path is already known.

Support triage. Structured extraction. Onboarding flows. Compliance checks. Customer notifications. Pricing assistants. Weekly reports. The shape of these jobs is not mysterious. The product knows the inputs, the allowed decisions, the outputs, and the places where a human must approve.

Put the model in a box and let code own the rest.

A deterministic shell gives you the boring gifts: tests, schemas, logs, permission checks, retry policy, cost ceilings, latency budgets. You can mock the model. You can replay the state machine. You can tell a customer why the thing did what it did.

It also gives you a product surface. Buttons. Menus. Review screens. Error states. A user should not need to negotiate with a blinking cursor just to get a predictable workflow done.

The price is rigidity. Every new branch becomes code. Every edge case becomes backlog. If the job keeps changing shape while it runs, the deterministic shell starts to feel like a hallway full of locked doors.

The split lines up with the agent taxonomy in Not Every Agent Needs AI. Level 0 and Level 1 systems belong here most of the time. A cron job does not need agency. A sentinel that runs a fixed check and asks the model to explain the result does not need an autonomous runtime. It needs boring code with one intelligent joint.

Deterministic shells are for known work with sharp boundaries.

Agentic Shells Are for Unmapped Work

Use an agentic shell when nobody can write the flowchart honestly.

“Fix this bug” is not a sequence. It is a hunt. The agent may need to read the stack trace, search the repo, run the failing test, inspect a migration, edit one file, break another file, back up, and try again.

Deep research has the same shape. So does incident diagnosis. So does cleaning up a weird data set, comparing vendors, or doing personal assistant work across calendar, email, browser, and files. The valuable step is often the one you could not name before the previous step finished.

That is where an agentic shell earns its keep. It composes tools without a developer wiring every path. It adapts when the next move depends on fresh evidence. It lets a trained human steer through work that used to require handoffs between engineering, ops, research, and support.

The tax is variance.

The same request can take a different path tomorrow. A tool call can wander. Token spend can creep. A broad tool surface can turn one bad instruction into a real incident. If the agent can read files, open browsers, call APIs, and run commands, you have stopped building a chatbot and started operating machinery.

That is where Operators become the missing role. An agentic shell without an Operator is a factory line with no one watching the line. It might produce gold. It might produce scrap. Either way, no one owns the run.

Agentic shells are for unknown work with high context requirements.

The Production Shape Is Hybrid

The production answer is usually a deterministic shell around an agentic core.

The outer shell owns identity, permissions, billing, audit logs, state, retries, approval gates, and the product experience. The inner shell owns the ambiguous run. The app decides what is allowed. The agent decides how to get there.

Picture a production bug assistant.

The deterministic shell receives the incident, checks severity, creates the run record, mounts the permitted repo, injects the dashboards, sets a token budget, and blocks writes until approval.

The agentic shell investigates. It reads logs, searches code, reproduces the failure, drafts a patch, runs tests, and writes the report.

Then the deterministic shell takes back the wheel. It enforces architecture rules with teeth, records the evidence, routes the PR, and waits for signoff.

That is production architecture. Code guards the edges. The agent handles the messy middle.

It also matches the path from Operate Before You Automate. Start by operating the workflow manually inside an agentic shell. Learn the variance. Find the intervention points. Discover what needs to be deterministic. Then move those pieces into code.

Choose by Risk, Not Vibe

Agentic is too coarse a word to design with.

Ask where control belongs.

If failure must be narrow, behavior must repeat, users need a polished surface, costs need a ceiling, or the work is already mapped, keep control in product code.

If the path changes per run, the agent needs rich context, the value comes from composing tools, and an Operator can watch the line, put control in the reasoning loop.

If the work is valuable enough to justify autonomy and risky enough to need rails, split control on purpose.

Context still matters. Your agent’s IQ matches your context, but the shell decides what the agent is allowed to do with that intelligence.

Deterministic shells control. Agentic shells explore. The best systems know which one is driving.

You Get the AI You Ask For

Tue, 19 May 2026 08:30:00 +0000

Two engineers open the same chat window, with the same model, on the same Tuesday morning. One ships a feature with public database queries, hardcoded keys, no rate limit, and a UI that converts at half the rate it should. The other ships the same feature audited against OWASP, profiled for hot paths, copy-tested against high-converting landing pages, and fully instrumented. Same model, same week, two completely different products, separated entirely by what each engineer knew to ask the model about.

Two Engineers, Same Model

Engineer A is vibing. The prompt is “build me a dashboard that shows sales by region.” The model writes the dashboard. It uses the most common pattern in its training data, because that is what models default to when nothing else is specified. The default pattern has public read access on the table. The default pattern has no authorization check on the endpoint. The default pattern logs the API key into the browser console. It runs. It looks fine. It ships.

Engineer B opens the same window. Same first prompt. Then: “audit this for the OWASP top 10.” Then: “what would the senior security engineer at a fintech say about this access pattern?” Then: “is this query going to do a full scan when we hit a million rows?” Then: “rewrite the empty state copy as if it were a top-converting SaaS dashboard.” Then: “what’s missing in the observability story?” Then: “are there duplicate code paths I should consolidate?”

Same model. Same Tuesday. Different output ceiling by an order of magnitude.

Between Engineer A and Engineer B, the model itself has not changed. Engineer B is just reaching further into it — calling a security expert, a database planner, a marketing strategist, an SRE, and a refactoring reviewer, all of which already live in the weights, dormant, waiting for a vocabulary trigger.

The AI you experience is the AI you invoke.

Capability Elicitation Is the Real Game

There is a phrase for this in the research literature: capability elicitation. It is the practice of getting a model to actually use what it already knows. The UK AI Safety Institute has shown that elicitation techniques can lift model performance by amounts comparable to a 5–20x increase in training compute. Same weights. Same model card. Different prompting strategy. Five to twenty times the output quality.

Five to twenty times.

Read that number again. The practical AI gains in 2026 are coming out of that gap — the distance between what the model already knows and what your prompts manage to surface — not out of the next model release. Models have trained on every published security audit, database design review, copy test, architecture critique, and code review humans have ever written. All of it is in there. None of it shows up unless you ask.

The default behavior of every chat model is to produce the most common pattern in its training data conditioned on the surface form of the prompt. The most common pattern in training data is code that compiles and runs, not code that is secure, performant, accessible, instrumented, and maintainable. Those properties live in different neighborhoods of the model’s latent space, and they only get activated when the prompt rhymes with the language those neighborhoods were trained on.

This is why your agent’s IQ matches your context is only half the story. Context is what the model can see. Prompt vocabulary is which regions of the model you actually reach into. You need both. People obsess over the first and ignore the second.

What’s Missing, Not What’s Present

The vibe coder ships exploitable code because security is mostly made of absences — the auth check that isn’t there, the rate limit that isn’t there, the input validation, the row-level security. Default LLM output is generative; it shows you what’s on the page. Absence is invisible unless someone asks “what’s missing?”

The same logic applies on every other axis you care about:

Performance. The query works on the data you have today. It might thrash on the data you have in eighteen months. The model will not volunteer that.
Accessibility. The UI passes the sight check. A screen reader’s path through it is a separate question, and only gets answered if you raise it.
Conversion copy. “No data yet” is the easy empty state. The one that actually activates a user to populate their first row takes a different prompt entirely.
Observability. Endpoints that work in dev are not the same thing as endpoints you can diagnose at 3 a.m. when they don’t.
Modularity. The function works in isolation. Whether you have now written it four times across the codebase is something only a refactoring-eyed prompt will surface.

Each of those is a different neighborhood of the model. Each requires a different prompt phrasing to enter. A vibe coder with a hundred-billion-parameter model and one-line prompts is using a Ferrari to drive to the corner store. The summoning is where the gains live now.

This is also why a single eval harness outperforms a hundred ad-hoc prompt tweaks. The harness forces you to enumerate the dimensions you care about. The act of enumeration is what reaches into the model.

Your Vocabulary Is Your Ceiling

Here is the uncomfortable part. The list of things you know to ask about is the list of things you already understand. Never read about SQL injection? You won’t ask the AI to check for it. Never thought about page-load budgets? You won’t ask the AI to audit them. The AI answers questions; it doesn’t volunteer the curriculum you never learned.

That is the mirror. The AI doesn’t flatter you the way a sycophantic model agrees with you. It reflects the limit of your professional vocabulary — every dimension you cannot articulate, every trade-off you cannot name, every expert you have never been exposed to, all stay below the surface of the response.

Vibe coders ship bad software because their internal checklist is short. The model is happily, dutifully producing exactly what was asked.

The output ceiling of any chat with any model is bounded by the asker’s vocabulary.

How to Raise the Floor

“Be a better engineer before you use AI” is true and unhelpful. The practical fix is to externalize the checklist so the model never has to rely on you remembering, at 11 p.m. on a Friday, every axis that matters.

Three concrete moves:

1. Write a prompting checklist for every recurring task. A “ship a new endpoint” checklist contains the questions you would otherwise forget: security audit, rate-limit check, auth check, input validation, pagination plan, index plan, observability hook, error envelope, empty state copy, loading state copy, test coverage on the unhappy path. Make it a file. Run the file before merging.

2. Codify the checklist into project rules that have teeth. Rules files (.cursor/rules, AGENTS.md, repo-level guidance) raise the default set of brain regions the model activates without you needing to retype the checklist every prompt. The model’s vocabulary gets bigger because yours did, once, in a file.

3. Add a forced “what am I missing?” pass. After the model finishes the task, prompt: “Audit this work as five different senior reviewers — a security engineer, an SRE, a database architect, a UX writer, and a tech lead doing a code review. List what each one would flag.” That single pass routes the model through five neighborhoods it did not visit on the first draft. It is the cheapest 5x you will ever get.

These three moves are how you build exactly what you want, instead of accepting the nearest plausible thing the model produced. None of them make the model smarter. They widen the door.

The Model Is a Polymath in Hibernation

Your chat window already contains a security expert. It also contains a database engineer, a conversion copywriter, an SRE, and a principal architect. They are all trained in, all already on the payroll, all sitting dormant. The session pays for them whether you invite them or not.

They wake up when you address them by name.

Most prompts only wake the generalist. The generalist writes something plausible. The work ships. The bugs the rest of the polymath would have caught ship too, because the rest of the polymath was never invited to the meeting.

You get the AI you ask for.

So address it like the polymath it is.

AI Agents Will Break Any Rule You Don't Test

Tue, 12 May 2026 14:00:00 +0000

Most teams give their AI agents an AGENTS.md, a CLAUDE.md, or a Cursor rule full of polite architectural guidance. Layers, boundaries, where secrets live, what may import from what. Three weeks later the codebase is spaghetti reaching across every line they wrote down, and they wonder why the agent ignored them. Documents do not enforce architecture. Tests do. The fix is small, language-agnostic, and unforgiving: take your most important architecture rules, write them as a deterministic test, wire it into a pre-commit hook, and let CI run it again. Now the agent literally cannot finish the work if it breaks the architecture.

The Document Does Not Enforce

Read any popular agentic coding setup and you will see the same playbook. A markdown file at the root of the repo. Sections like “Architecture”, “Module Layout”, “Do Not Cross These Boundaries”. A rule that says “agents must not import from clients in this codebase, only from interfaces.”

The agent reads it once. Maybe twice. Then a hundred thousand tokens go by, the context window churns, and the rule slides out of attention. Or the agent technically remembers but optimizes for the local task. Or a different agent on a different branch never had your rules in scope to begin with. By the time you notice, you have cross-layer imports, secrets read from process.env in five places, and a domain layer that calls HTTP clients directly.

This is the bloat-and-mess pattern that scares people off agents. Blaming the model misses what is actually happening — the model did what models do, which is generate plausible code, and nothing in the pipeline was checking the architecture. A rule that lives in prose is a suggestion. A rule that fails the build is a wall.

Make the Rule Executable

The move is simple. Pick the architecture rules you actually care about. Express each one as a script that returns non-zero on violation. Wire that script into your test runner.

Two rules cover most of the damage I see in real codebases:

Dependency direction. Layer X may not import from layer Y.
Capability allowlists. Only these specific files may touch this dangerous primitive (process.env, fs, fetch, raw SQL, the credential broker, whatever).

Both are trivially expressible as a file walk plus a regex. No AST, no fancy linter plugin, no language buy-in. Here is the entire enforcement layer for a Bun project I run, in one test file. The code is unglamorous on purpose:

import { describe, expect, test } from "bun:test";
import { readFileSync, readdirSync, statSync } from "node:fs";
import { join, relative } from "node:path";

const SRC = join(import.meta.dir, "../src");

function collectTsFiles(dir: string): string[] {
  const files: string[] = [];
  for (const entry of readdirSync(dir)) {
    const full = join(dir, entry);
    if (statSync(full).isDirectory()) {
      files.push(...collectTsFiles(full));
    } else if (entry.endsWith(".ts") && !entry.endsWith(".d.ts")) {
      files.push(full);
    }
  }
  return files;
}

function importsFrom(source: string, target: string): string[] {
  const lines = source.split("\n");
  return lines.filter((l) => /^\s*(import|export)\s/.test(l) && l.includes(`/${target}/`));
}

function processEnvUsages(source: string): string[] {
  return source
    .split("\n")
    .filter((l) => !l.trimStart().startsWith("//") && l.includes("process.env"));
}

describe("dependency boundaries", () => {
  test("agents/ must not import from clients/", () => {
    const agentFiles = collectTsFiles(join(SRC, "agents"));
    const violations: string[] = [];

    for (const file of agentFiles) {
      const rel = relative(SRC, file);
      const source = readFileSync(file, "utf-8");
      for (const line of importsFrom(source, "clients")) {
        violations.push(`${rel}: ${line.trim()}`);
      }
    }

    expect(violations).toEqual([]);
  });
});

describe("process.env access", () => {
  const ALLOWED = new Set([
    "config.ts",
    "instrument.ts",
  ]);

  test("only allowlisted files may use process.env", () => {
    const allFiles = collectTsFiles(SRC);
    const violations: string[] = [];

    for (const file of allFiles) {
      const rel = relative(SRC, file);
      if (ALLOWED.has(rel)) continue;

      const source = readFileSync(file, "utf-8");
      for (const line of processEnvUsages(source)) {
        violations.push(`${rel}: ${line.trim()}`);
      }
    }

    expect(violations).toEqual([]);
  });
});

That is it. Two tests. About fifty lines. No frameworks. The violation list is the error message — the agent gets handed every file and line that broke the rule, in plain text it can act on.

The Loop Is the Point

Writing the test is half the move. The other half is wiring it into a place the agent cannot route around.

Pre-commit hook. bun test (or pytest, or go test, or dotnet test) runs before any commit lands. Configure the hook so the architecture tests are not optional, not skippable, not separable from the rest of the suite.
CI on every push. Same tests, same exit code. The agent cannot pretend the rule does not exist by committing past a broken local hook.
A nice failure message. When the test fails, the output should read like a coach, not a stack trace. agents/foo.ts: import { Bar } from "../clients/bar" followed by agents/ must not import from clients/. The agent reads that, finds the offending line, and fixes it. Loop closed.

This turns architecture from a property the agent has to remember into a property the system enforces. The agent runs the tests because the loop forces it to. The test fails. The agent reads the violation. The agent fixes the import. The agent commits. Discipline is now a property of the pipeline, not the model.

You stop trusting the agent. You trust the failure.

Primitive Now, Proper Later

Regex on import lines is a hack and I do not pretend otherwise. It will miss creative obfuscations. It does not understand re-exports. It cannot distinguish a comment from code in every dialect. None of that matters for the use case. Agents do not write creative obfuscations. They write the most obvious shape of the code they are asked for, every time. A regex that catches the obvious shape catches the agent.

When the codebase grows up, swap the implementation, keep the rule:

C# / .NET. Roslyn analyzers, NetArchTest, ArchUnitNET.
Java / Kotlin. ArchUnit. The original. Still the gold standard.
TypeScript / JavaScript. ts-morph, eslint-plugin-boundaries, dependency-cruiser, madge for cycle detection.
Python. import-linter, pyflakes plugins, custom AST walks via ast.
Go. go vet plus custom analyzers, depguard.
Rust. cargo-deny, custom clippy lints.

These let you express richer rules: no cyclical dependencies, no public field access across module boundaries, this layer is sealed except through this interface, no calls into the database from anywhere except the repository module. Use them when the project deserves them. Until then, ship the regex test. Ugly enforcement beats elegant aspiration.

Why This Matters More With Agents Than With Humans

Architecture testing is not new. ArchUnit has been around for years, NDepend longer than that, and a small percentage of disciplined teams have always shipped this layer. With humans, it was a nice-to-have. Code review caught most violations. Senior engineers internalized the rules. Onboarding transmitted them.

Code review is dying. Onboarding does not apply to a model that loses its memory at end-of-session. Senior engineers are not in the loop on every line anymore. The mechanisms that used to hold architecture together quietly are gone. The new loop is agent generates → tests run → CI gates → human reviews product, not code. If your architecture is not in the test layer, it is nowhere.

This is the same insight as putting secrets behind a broker instead of in environment variables, or hiring Operators instead of trusting an autonomous agent’s judgment. Mature systems do not ask the model to be careful. They make carelessness expensive.

Set the Initial Architecture, Then Lock the Doors

Two practical takeaways for anyone shipping with agents.

First, set the initial architecture yourself. This is not optional. Agents are excellent at filling in scaffolding and terrible at choosing which scaffolding to use. Lay down the directories, name the layers, write a one-paragraph description of what each layer does and what it may depend on. That is your specification, and it is the cheapest insurance you will ever buy.

Second, lock the doors. Pick the three or four rules that, if violated, would create the most damage. Write a test for each. Run the suite in pre-commit and CI. Make the failure message readable. Now the agent cannot ship a violation, you cannot ship a violation, and you stop having to manually police the structure. The codebase stays clean because the build refuses to be dirty.

A rule that lives in prose is a suggestion. A rule that fails the build is a wall.

You do not need to trust the agent. You need to make it impossible to commit the wrong thing.

Pick a Lane: Factory or Frontier

Mon, 11 May 2026 09:00:00 +0000

A year ago I wrote that AI workers fall into four tiers (Conscript, Cyborg, Centaur, Centurion), stacked from least output per human to most. The tiers are still real. The implied ladder isn’t. The longer I work alongside agents and watch the people who do it well, the clearer it gets that there isn’t one destination at the top of the stack. Two lanes are opening up in front of every serious operator, and they reward completely different instincts. Pick the wrong one and you’ll either over-systemize a problem nobody has solved yet, or you’ll keep hand-crafting work the world has already turned into a commodity. Both mistakes are expensive. Only one is recoverable.

What I Got Right, and What I Missed

The original post said there’s a tier above Cyborg called Centurion: the operator running a hundred agents like a small company. That’s still true. People are doing it. Some of them are getting absurdly rich.

What I implied, and shouldn’t have, is that Centurion is the destination and Cyborg is a stop on the way there. As if every fluent human-AI hybrid should eventually graduate into running a fleet, and anyone who didn’t was simply less mature.

That’s wrong. Centurion is a different job from Cyborg, not a higher rung. (I’m using Cyborg in the sense Ethan Mollick mapped out in Centaurs and Cyborgs on the Jagged Frontier: human and AI braided into one continuous flow, instead of a clean handoff.)

The thing that finally cracked it for me is a much simpler observation:

AI is extraordinary at solved problems with known solutions. AI is mediocre at genuine innovation, taste, and frontier work.

That single asymmetry forks the entire career map.

Two Lanes, Not One Ladder

Two kinds of work exist in the world right now, and AI changes them in opposite directions.

Lane One: Solved Work. Patterns the world already knows. SOPs. CRUD. Reconciliation. Tier-1 support. Standard contracts. Standard refactors. Standard onboarding. Standard backoffice. Most of the actual labor inside every company is here. It’s been documented, blogged, fine-tuned, and embedded a thousand times over. AI eats this lane alive.

Lane Two: Frontier Work. Things nobody has done yet, or things that only work because of taste and context that doesn’t exist in any training corpus. New product categories. Novel architectures. Original research. New companies. New game mechanics. New aesthetic directions. AI helps here, but only as a tool inside the hands of someone with a frontier instinct.

These two lanes need different humans, different tooling, and different rituals. A Centurion’s stack is built for throughput on solved patterns. A Cyborg’s stack is built for speed of discovery in the dark. They look similar on the surface (both run agents, both use IDEs full of inference, both burn tokens like fuel) but the org charts, the eval loops, and the success metrics aren’t the same animal.

Centurions industrialize the solved. Cyborgs scout the unsolved.

The Centurion Lane: Industrialize the Known

If your work has a known shape, if there’s a playbook, a checklist, a regulatory pattern, a textbook process, your job is to turn that shape into a factory.

This is the Centurion lane, and it really is the new managerial superpower. The work looks like:

Codify the SOP into specs an agent can execute.
Build the eval harness that proves the agent is doing it right.
Wire the queues, the retries, the escalation rules, and operate before you automate.
Define budgets, kill switches, observability.
Hire Operators to babysit the line.
Compound on the same factory until it’s a moat.

The reward is enormous. One Architect plus a handful of Operators plus a hundred agents plus a tight feedback loop equals the output of a fifty-person team. That’s the dark factory I’ve been writing about. That’s the line Lovable can’t sell you, because you have to build exactly what you want. That’s the lane where systemization is the whole game.

But you can only run this lane on work that is genuinely solved. If the problem is novel, if the spec keeps mutating, if the eval can’t be written because nobody knows what “right” looks like yet, if every artifact has to be judged by a human with taste, your factory will produce a hundred confidently-wrong artifacts per hour and you’ll burn cash discovering you were never in this lane.

The Cyborg Lane: Scout the Unknown

The other lane is the one I underrated.

A Cyborg isn’t a worse Centurion. A Cyborg is the human-AI hybrid who is making things that didn’t exist yesterday. Building a new kind of agent. Designing a game mechanic. Writing original research. Prototyping a product in a category that doesn’t have a category yet. Running experiments where the next move is determined by what the last experiment surprised you with.

This is frontier work, and it has a different shape:

The spec is wrong until you build the prototype.
The eval can’t be written; the only judge is your own taste.
Most outputs get thrown away, and that’s the point.
The flow is human and AI moving through the same fog at the same speed, trading the wheel sentence by sentence.
You don’t run a hundred agents on this; you run two or three, very tightly, as extensions of yourself.

This is also a real career. It is, in many ways, a more durable career, because frontier work is the one thing AI can’t autonomously produce. AI averages. Frontier work is the opposite of averaging. It’s the deliberate refusal to accept the median answer. That refusal is a uniquely human signal, and the people who can wield it (with AI as a force multiplier rather than a replacement) are going to print value for the next decade.

A Cyborg’s job is to find, not to scale. Once they find, they hand the artifact off to a Centurion, sometimes themselves wearing a different hat, to industrialize.

The Two-Lane Map

Both lanes use agents. Both lanes burn tokens. A great Cyborg may run a dozen agent tools in a single afternoon, and a great Centurion is almost always personally a strong Cyborg too. The tooling overlaps. The intent doesn’t.

	Factory Lane (Centurion)	Frontier Lane (Cyborg)
Type of work	Solved patterns, known SOPs	Novel, unsolved, taste-driven
Goal	Throughput and margin	Discovery and originality
Spec	Written, versioned, evaluated	Emergent, mutable, sometimes private
Eval	Automated, measurable, ruthless	Human taste, slow, qualitative
Agents	50-500, parallel, queued	2-5, tight, intertwined
Failure mode	Process gaps, drift, silent errors	Premature systemization, lost magic
Career identity	Architect / Operator	Builder / Researcher

The Two Expensive Mistakes

Picking a lane requires brutal honesty about the problem, not the practitioner. Both lanes have a characteristic failure that costs founders, teams, and individual careers serious money.

Mistake one: the Cyborg who should have systemized. They keep hand-crafting the same workflow for the fortieth time because it feels artisanal. They love the flow state. They tell themselves the work is too judgment-heavy to automate. Meanwhile a competitor in the Factory lane has turned the same workflow into a $3-an-execution agent fleet and is eating their lunch while they polish their pottery. Most “irreducible judgment” is actually unwillingness to write the eval.

Mistake two: the Centurion who should have scouted. They take a problem that looks like it has a known shape (drug discovery, novel UX, original strategy, brand voice, anything genuinely creative) and pour it into a factory. The factory dutifully outputs a hundred mediocre, on-pattern artifacts per day. They confuse volume for value. They burn a runway industrializing a solution that the world hadn’t actually figured out yet, and they ship the median when the whole point was to ship the exceptional. Most “obvious automation” is actually a problem nobody has solved well in the first place.

The honest question, before you build the line or burn another week iterating manually, is this:

Is this problem actually solved? Or am I telling myself a story about that?

If solved, industrialize. Hire Operators. Compound. Stop typing.

If unsolved, stop pretending. Pull the agents in close. Trust your taste. Run small. Run weird. Throw most of it away. Find the thing.

Same Tools, Different Souls

The cleanest way I can put it: Cyborgs and Centurions both run agents, but they’re not running them for the same reason.

A Cyborg runs agents to extend their nervous system into the unknown. A Centurion runs agents to extract their nervous system from the known.

Both are real, lucrative careers. Neither is the upgrade path of the other. The original post made it sound like a ladder. It is, in fact, a fork.

Pick the lane that fits the problem in front of you. Not the one that flatters your self-image. Reassess the lane every quarter. Switch when the problem switches. The people who get richest in the agent era won’t be the ones who picked Centurion or Cyborg the loudest. They’ll be the ones who, every single time a new piece of work landed on their desk, asked the boring question first: factory or frontier?

And then actually answered it honestly.

Operators Are the Missing Role in AI Agent Design

Fri, 08 May 2026 09:00:00 +0000

Everyone is racing to build autonomous agents. Almost nobody is designing the human role that keeps those agents from drifting, lying, or quietly burning money in a corner. That role has a name, and it is not Prompt Engineer. It is Operator: the dedicated, specially trained human who knows one specific agent the way a factory operator knows their line. It is the most underrated job in AI right now, and it decides whether your agents ship value or ship excuses.

From Build to Operate

Software used to come in two roles separated by a wall.

Engineers wrote the code. When it was “done,” they tossed it over the wall to Ops, who kept it alive in production while the engineers moved on to the next thing. Two roles. One direction. Heavy walls.

Then DevOps arrived and the wall came down. Engineers learned to deploy, monitor, and operate the things they built. But the primary activity was still upstream: design, code, ship. Operating was a tax on engineering, not the work itself.

Agentic systems break the pattern. The artifact is no longer a static piece of code that runs the same way every time. The artifact is a decision-making process. It judges, drafts, calls tools, fails in new ways every hour, and must be supervised in motion. The center of gravity moves from build to operate.

Engineering is no longer the primary activity. Operating is.

Each Agent Needs Its Own Operator

An AI agent is a factory line. The model is the machine. The prompts, tools, and guardrails are the cells. And every factory line in human history has needed an Operator.

Not a generic “automation person.” An operator trained for that line, who knows its quirks, its failure modes, the smell of trouble before the alarms fire. You don’t staff Toyota’s Takaoka plant with someone who skimmed an O’Reilly book. You staff it with operators who have run that line for years.

Agents are no different. Each agent needs a dedicated, specially trained Operator who knows that agent’s workings the way a factory operator knows the line. Not the model. Not the framework. That agent. Its prompts. Its tools. Its eval rubric. Its known failure modes. Its blast radius.

This applies whether you are an engineer operating an agent inside your own IDE, a support lead running a customer-facing AI in production, or a Factory Architect overseeing a fleet of them. Same role. Same discipline. Same skill ladder.

The Operator Has Five Jobs

The Operator job is not a vibe. It is five concrete responsibilities, repeated every run.

Load Inputs. Curate the context the agent sees. Specs, examples, tools, prior runs, eval data. Garbage in is the most common failure mode for production agents, and it is the Operator’s failure, not the model’s.
Watch the Line. Stream the agent’s behavior live. Tool calls, intermediate outputs, latency, cost, retries. If you cannot see what the agent is doing while it is doing it, you are not operating. You are praying.
Intervene. When the line drifts, stop it. Steer it. Inject a correction, kill the run, swap the tool, escalate the input. The Flare Gun is for genuine unknowns. Most interventions are an Operator catching a known failure on its way to the floor.
Verify. Nothing ships without an Operator-level check. Eval scores, spot reviews, structured signoff. The Operator is the last clean signal before the work becomes the company’s.
Own the Result. When the agent ships garbage, the Operator owns it. When it ships gold, the Operator owns the line that produced it. No “the model did it.” The Operator did it, with the model.

These are not soft skills. They are a job, with artifacts: dashboards, run logs, eval suites, intervention playbooks, post-incident reviews. They have a career ladder. They will have certifications within two years.

Bad Workflow vs. Operator-Designed Workflow

A bad agent workflow looks like this. Someone fires a prompt, the agent does whatever it does for forty minutes, the human comes back, glances at the output, and ships it. No monitoring. No verification. No accountability. When something blows up in production a week later, everyone shrugs at the model.

An Operator-designed workflow looks like this. The Operator loads the spec, the eval set, and the relevant tool registry. They run the agent on a side branch with a live trace open. When the agent picks the wrong tool at step three, they pause, swap the tool, and resume. When the draft comes back, they run the eval suite, spot-check the top three risks, and either approve the artifact or send it back with concrete feedback. The run is logged. The intervention is logged. The signoff is logged. Every artifact has a name on it.

Same agent. Same model. Two completely different production systems. One ships value. The other ships excuses.

The Next Discipline Is Operator Design

The next discipline in AI Agent Design is not prompt engineering. Prompts are a tactic. Operating is a role. It is the job that determines whether your agents become a competitive moat or a compliance disaster.

Stop hiring Prompt Engineers. Start training Operators.

If you are building an agent today, name the Operator before you name the model. Decide what they will see, what they can intervene on, what they must verify, and what they own. Wire the system around them, not around the LLM.

No agent ships without an Operator. No Operator ships without a line.

That is the next factory.

Dark Factory: Man & Machine

Wed, 06 May 2026 04:00:00 +0000

2026 is the age of the software factory. Dark factories where agents run the line at 3am with no humans in the building. Light factories where humans and agents work side by side at the bench. Every ambitious company is racing to build one — and most of them are buying the same fantasy: that once the factory is built, the engineers go away. They won’t. The factory will eat the typist, but it will mint a new role nobody has staffed yet — the Operator.

The Fantasy and the Forklift

Every executive deck this year has the same picture. A serene control room. A blinking dashboard. A green check mark. Software building itself. No engineers, no PMs, no late-night Slack threads. Just output.

That’s not a factory. That’s a screensaver.

Real factories — the ones that actually produce things — never automated their humans away. CnC machining didn’t kill the machinist. It birthed five new jobs: the people who make the CnC machines, the people who sell them, the people who write the toolpath software, the people who integrate them into a line, and — most importantly — the people who operate them. The machinist didn’t disappear. They got promoted into a cyborg. One human, one console, ten machines.

Software factories will play out the same way. Anyone who thinks “build the factory and the engineers go away” has never stood next to a CnC mill at 2am while the spindle screams and the part is two thousandths off and someone has to decide what to do.

The New Roles the Factory Creates

The software factory is not one product. It’s a stack. And like every real industrial stack, each layer creates its own discipline:

Factory Architects — engineers who design the pipeline itself. They pick the agents, the eval harnesses, the queues, the guardrails. They build the line.
Factory Builders — the people writing the actual platform: the orchestrators, the tool registries, the sandboxing, the observability. They build the machines that build the software.
Factory Sellers — yes, these will be everywhere. Templates, marketplaces, reference factories, vertical kits. The “Shopify for software factories” companies are already pitching.
Factory Pipeline Engineers — the equivalent of CAM programmers. They write the specs, the prompts, the toolpaths the agents follow.
Factory Operators — the humans who run the line, every day, on every job.

Every layer matters. But only one layer gets stronger as the factory gets better. The Operator.

What Operators Actually Do

The Operator is not “a person who supervises the AI.” That framing is lazy and wrong. The Operator is the only role in the entire factory that does five things no agent can do reliably:

Load the inputs correctly. Specs, constraints, references, examples, the customer’s actual ask. Garbage in is still garbage out, even at 1,000 tokens per second.
Watch the line. Not stare at logs — read the line. Detect drift. Smell wrongness. Notice the part that’s coming out subtly off.
Intervene on errors. Step in when the agent loops, hallucinates, picks the wrong tool, or starts producing something nobody asked for. Resume the line in a clean state.
Verify the output. Run it. Use it. Stress it. Decide whether it ships. The factory does not get to declare its own work done.
Take ownership. Sign their name to the result. Carry the on-call pager. Eat the consequences when it breaks.

No current agent — including the best ones — does all five. They do the typing. The Operator does the judgment. The factory is the muscle. The Operator is the nervous system.

The Cyborg Technician

The Operator role is not a downgrade from “engineer.” It’s a different alloy. Half engineer, half pilot, half product manager — fused with the factory through tools, dashboards, and trained reflexes. A Cyborg Technician.

A good Operator in 2026 has:

A spec mindset: can compress fuzzy intent into a tight, executable brief.
A line sense: can tell from logs, traces, and partial output whether the run is healthy.
A toolbelt: tail commands, replay tools, eval suites, manual override switches.
An ownership posture: the run’s output is theirs, even though they didn’t type it.

This isn’t future-tense. The best engineers I work with already operate this way. They’re not coding more — they’re running more lines, supervising more agents, shipping more units of work per week than any 10x engineer ever did. They’ve already become Cyborg Technicians; they just don’t have a business card for it yet.

The Lights Go Out, the Console Stays Lit

The dark factory dream is real. Most of the typing will be automated. Most of the boilerplate will be generated. Most of the routine will be on rails.

But the lights never fully go out. Somewhere in every dark factory, one console stays lit, one Operator stays on the line, and one human takes the call when the machine builds the wrong thing perfectly.

You don’t automate the Operator. You arm them.

If you’re building a software factory, hire architects, hire builders, buy tools — but staff the Operators first. They are the only role that scales the factory’s value instead of its risk. And if you’re an engineer wondering what your job looks like in five years, stop training to be replaced by the factory. Train to run it.

The age of the software factory needs the man and the machine. Build both.