Engineering Principles for the Agentic Era

AI is not magic, and it is not a force of nature. It is an engineering tool. Like every powerful engineering tool, its outcomes depend heavily on the systems, incentives, constraints, and people around it.

That sounds obvious, but much of the public conversation about AI seems to forget it. We swing between two unhelpful extremes: treating models as if they will autonomously solve every problem, or treating them as if they are inherently uncontrollable. Neither view is useful to someone who actually has to build production systems.

The more I work with software agents, the more convinced I become that the important questions are engineering questions. What context does the agent have? What is it allowed to do? How is its work checked? What happens when it is wrong? How do we measure whether it is improving the system? How do we preserve human judgment without forcing humans to manually perform work that machines can now do well?

My view is optimistic, but not because I assume models are reliable. I am optimistic because reliability can be engineered. The opportunity is not to trust agents blindly. It is to build systems in which we do not have to.

The right response to a powerful technology is neither complacency nor panic. It is better engineering.

1. AI is leverage, not magic

AI amplifies the competence of the people and systems around it. A strong engineer with a clear objective, good context, useful tools, and fast feedback can now operate with dramatically more implementation capacity. A weak process can produce weak output just as quickly.

This is not unique to AI. Better build systems made productive teams faster. Better cloud platforms increased the scale at which good and bad architectures could operate. Better automation magnified whatever process it automated. Agents are another step in that progression, except the leverage is much larger because they can participate directly in reasoning, implementation, testing, investigation, and iteration.

The practical implication is that organizations should stop asking whether AI is “good at coding” as if coding were one indivisible task. The better question is: what combination of people, models, tools, context, architecture, and validation consistently produces good outcomes? That is a system-design problem.

2. AI slop is an engineering failure mode

The phrase “AI slop” is useful only if we are precise about what causes it. Give an agent a vague request, incomplete context, no acceptance criteria, no architectural constraints, and no meaningful validation, and mediocre output should not be surprising. We created bad software under those conditions long before large language models existed.

The mistake is treating generation as the end of the engineering process. It is the beginning of a validation loop.

Good engineering with agents still requires intent, decomposition, architecture, executable feedback, tests, static analysis, observability, review, and judgment. In many cases those things matter more than before, because an agent can produce changes faster than a human can inspect them line by line.

So I reject the idea that low-quality AI-generated software is inevitable. Low-quality software is inevitable when quality is not engineered. Agents simply make it easier to scale whatever standard already exists.

3. The quality ceiling has gone up

Most discussion about AI productivity focuses on doing the same work faster or with fewer people. That is the least interesting consequence.

The more important change is that previously expensive engineering work is becoming cheap enough to do routinely. We can test more alternatives. We can generate broader test coverage. We can refactor code that would previously have been left alone because the business case was weak. We can improve documentation, investigate edge cases, migrate old systems, reproduce failures, explore competing designs, and repeatedly challenge an implementation before it reaches production.

That changes the quality frontier. If an agent can cheaply implement three approaches, benchmark them, run the full test suite, analyze failure modes, and revise the best candidate, the rational response should not be to accept lower quality because code is cheap. It should be to demand more.

AI lowers the cost of implementation, but it also raises the quality ceiling. Organizations that use it only for headcount reduction will leave much of the value on the table.

4. Humans move up the abstraction stack

As implementation becomes cheaper, human value shifts toward the parts of engineering that determine what should exist and why: intent, architecture, constraints, tradeoffs, prioritization, risk, and judgment.

That does not make implementation irrelevant. Deep implementation knowledge is often what makes good judgment possible. But manually producing every line of code is no longer a useful definition of engineering competence.

The best engineers will increasingly manage larger amounts of productive capacity. They will define the problem clearly, shape the environment in which agents work, establish feedback loops, recognize when an approach is wrong, and know when to intervene. They will spend less time mechanically executing known steps and more time deciding which steps matter.

This is not the disappearance of engineering. It is engineering operating at a higher level of leverage.

5. Autonomy should increase with verifiability

Arguments about whether agents should be autonomous are often framed as philosophical questions. I think autonomy should be an engineering decision.

If a task has clear boundaries, strong automated validation, limited permissions, observable execution, reversible changes, and reliable escalation paths, then high autonomy can be entirely rational. If a task is ambiguous, difficult to validate, irreversible, or capable of causing broad harm, human involvement should increase.

Autonomy should increase as verifiability increases.

That principle is more useful than either “trust the agent” or “keep a human in the loop.”

6. Safety should be concrete

Production agents introduce real risks. They can expose credentials, make destructive tool calls, leak data, exceed intended permissions, generate incorrect code, create runaway cost, or confidently pursue the wrong objective. Those are serious problems precisely because they are concrete enough to engineer against.

A production system should know which identity is acting, what resources it can access, which operations require approval, where execution occurs, how actions are logged, how outputs are validated, and how work can be stopped or rolled back. Security boundaries should exist independently of whether a model appears well behaved in a demonstration.

This is the same discipline we apply elsewhere in distributed systems and security. We do not assume a service will never fail. We define failure domains, permissions, telemetry, budgets, retries, timeouts, circuit breakers, and recovery mechanisms.

Agents deserve the same seriousness. Safety should become more specific as capability increases, not more mystical.

7. Own the control plane

Models will improve rapidly. Model providers will change. Pricing will change. Capabilities will converge and diverge. New vendors will appear. An enterprise architecture should assume all of that.

The durable parts of an agentic engineering system are not a particular model API. They are the organization’s context, identity, authorization, orchestration, execution environments, policy, telemetry, evaluation, cost controls, auditability, and integration with the software lifecycle.

Those capabilities are strategic infrastructure. Enterprises should own them.

That does not mean building every component internally. It means preserving architectural control. Model providers should compete on model capability; they should not become the unavoidable owners of an organization’s engineering context, workflow, governance, or operational history.

A good agent platform should make it possible to use the best model for a job without redesigning the organization around that vendor.

Own the control plane. Keep models replaceable.

The agentic software engineering architecture shows the lifecycle and enterprise substrate this principle implies in practice.

8. Optimize for expanded capability, not headcount reduction

The narrow economic story for AI is substitution: how many existing tasks can be automated, and how many people can be removed? That framing misses the larger opportunity.

Software has always been constrained by engineering capacity. Valuable projects are deferred because they are too expensive. Internal tools remain mediocre because the return does not justify a dedicated team. Migrations take years. Small customer segments do not receive specialized products. Technical debt survives because fixing it competes with features.

When implementation capacity increases dramatically, the feasible set changes. A small group can attempt projects that previously required a much larger organization. Teams can maintain more variants, run more experiments, build better internal tooling, and solve problems whose economics previously did not work.

The strategic question is therefore not simply, “How many people can this replace?” It is, “What can excellent people accomplish when each of them has far more productive capacity?”

That is a more ambitious use of the technology, and I believe it will create much more value.

9. Evidence beats prophecy

AI produces unusually confident predictions from both enthusiasts and critics. I am skeptical of both when they outrun evidence.

The engineering response is simple: measure. Measure actual task success. Measure failure modes. Measure review burden. Measure cycle time. Measure reliability. Measure security incidents. Measure cost. Measure whether developers are producing better systems or merely producing more changes. Measure whether autonomy improves outcomes in a particular domain before expanding it.

The same standard should apply to claims about the technology itself. Capability and risk should be demonstrated, reproduced, and quantified wherever possible. A compelling story is not a substitute for evidence.

This matters because organizations make worse decisions when they treat predictions as facts. Overconfidence creates reckless deployment. Fear creates unnecessary restrictions and architectural choices that may be difficult to reverse. Evidence lets us move quickly without pretending uncertainty does not exist.

Build the system around the model

The model matters enormously, but the model is not the system.

The system is the combination of human intent, context, tools, permissions, execution, validation, observation, remediation, and learning that surrounds it. As models become more capable, that surrounding system becomes more important because the cost of poor engineering is amplified alongside the benefits of good engineering.

My working assumption is that agents will continue to take on larger portions of the software lifecycle. The organizations that benefit most will not be the ones that either trust them blindly or constrain them reflexively. They will be the ones that learn how to turn autonomy into a dependable engineering capability.

That requires optimism about what the technology can do, skepticism about unsupported claims, and discipline about how production systems are built.

AI gives us more leverage than we have ever had as software engineers. We should use that leverage to build better software, attempt harder problems, and raise the standard for what good engineering looks like.