The Engineering OS in the Age of AI

As AI takes on more software development work, engineering leaders need to rethink how architectural decisions are communicated, enforced, and validated.

A note on perspective (October 2026): These are my thoughts and opinions as of October 2026, based on my experience and understanding of AI today. The technology is evolving rapidly, and I expect my perspective to evolve along with it.

Another Layer of Abstraction

Software engineering has always evolved through abstraction.

Compilers eliminated the need to manage individual machine instructions. Frameworks and libraries abstracted away common functionality. AI is introducing another layer.

I recently encountered an observation that resonated with me: we may eventually care about AI-generated source code about as much as we care about the assembly a compiler produces.

There is an important difference, though. Compilers translate well-defined languages. AI agents interpret specifications that may be incomplete, ambiguous, or contradictory.

Historically, engineers filled in those gaps using experience, product knowledge, and architectural understanding. Agents make assumptions too, but those assumptions may conflict with existing decisions.

As implementation becomes less expensive, specifications, architectural constraints, and acceptance criteria become more important.

I expect agents to eventually become capable of making most architectural decisions as well. Whether that’s six months or five years away, I don’t know.

Architecture is a harder problem to train and evaluate. Source code is abundant, and functional correctness can often be tested. Architectural decisions involve competing constraints, undocumented reasoning, and consequences that may not become apparent for years.

In the meantime, agents need access to the architectural knowledge that engineers have traditionally carried in their heads.

Communication Doesn’t Disappear. It Moves.

Conway’s Law describes how software architecture reflects the communication structures of the organizations building it.

AI doesn’t eliminate that relationship. It changes how communication happens.

Multiple agents working independently can produce individually reasonable solutions that conflict with each other. One might introduce a new service where existing infrastructure would suffice. Another might implement functionality already provided by a shared component.

Without coordination, those decisions accumulate into architectural complexity.

I’ve invested considerable effort in documenting repositories so agents can understand the systems they’re modifying. But documentation alone isn’t sufficient. Relevant information needs to reach an agent when it’s making a decision.

This is one reason I’ve been studying transformer models and how LLMs, harnesses, and agents work. I think engineers should understand the technologies they’re using to build products.

Those boundaries are evolving as models and agent platforms incorporate capabilities previously handled externally.

The harness is particularly interesting from an engineering leadership perspective. It can retrieve relevant documentation, identify architectural constraints, supply historical decisions, and initiate validation.

We don’t need to provide every document in every prompt. We need to make the right information available at the right time.

But providing context doesn’t guarantee an agent will follow it. We also need checks and balances.

Making Architecture Enforceable

Our mobile and AirPlay 2 development efforts demonstrated how good engineering practices allow developers to operate independently while maintaining quality.

We invested in automated testing, including isolated functional tests with abstracted backend dependencies and end-to-end functional tests. A relatively small number of manual tests supplemented that coverage.

We also used linters, static analysis, and security analysis tools such as SonarQube.

Everything had to build and pass the required checks before merging into trunk.

These practices provided consistent expectations and immediate feedback. AI agents can benefit from the same approach.

Where I think we need to invest more is architectural validation.

Dependency analysis, interface contracts, layering rules, and architecture fitness functions can enforce many structural constraints.

But not every architectural concern can be expressed as a deterministic rule.

At a minimum, I’d want an architecture review agent examining proposed changes before they merge.

It should have access to architectural documentation, relevant decisions, and the context behind the proposed change.

The reviewer should identify potential architectural problems, request revisions from the submitting agent or engineer, and escalate significant concerns for human review.

This provides another layer of architectural coordination without requiring every change to go through a human architect.

Preserve the Reasoning

Around 2022–2023, I began introducing Architecture Decision Records (ADRs) within my organization.

The engineer closest to the problem authored the decision, gathered feedback, and evaluated alternatives, often through proofs of concept.

I’ve found agents effective at this exploratory work. They can implement PoCs quickly and identify weaknesses in proposed designs.

I haven’t yet had agents commit new ADRs, but I see value in having them propose decisions, evaluate alternatives, and document tradeoffs.

I’d also expect better commit messages from agents. They should capture non-obvious decisions, assumptions, and tradeoffs rather than simply describe which files changed.

Both ADRs and useful commit history preserve context for future engineers and agents.

Rethinking Review and Approval

I’m still working through how much human oversight should remain necessary for AI-generated code.

I’m uncomfortable with large, complex production systems being changed without meaningful review. But agents can produce changes faster than engineers can inspect them, making traditional code review increasingly difficult to scale.

I think we need several complementary controls.

Executable requirements. I’ve been exploring behavior-driven development, where requirements are expressed as testable scenarios. These provide acceptance criteria that can be defined independently of the implementation and enforced automatically.

Architectural review. Deterministic checks should enforce known architectural constraints. A separate architecture review agent can identify potential design problems that aren’t easily expressed as static rules.

Automated quality gates. Builds, functional tests, static analysis, and security checks should remain mandatory. Independent validation matters because tests written by the implementing agent may reinforce its own incorrect assumptions.

Risk-based human approval. Changes affecting security boundaries, critical interfaces, or significant architectural decisions should receive additional scrutiny.

Random human inspection. I like the approach of sampling changes that otherwise passed automated approval. It’s similar to manufacturing quality control: periodically inspecting products from the line to find weaknesses in the process. Those findings should feed back into better tests, architectural rules, and agent instructions.

Supply-chain protection. Agents can introduce dependencies without anyone explicitly requesting them. Dependency scanning, package allowlists, provenance checks, and approval requirements for new libraries should help prevent malicious or unsuitable dependencies from entering the system.

Finally, agents need appropriate permissions. They shouldn’t be able to bypass required checks or deploy high-risk changes simply because they can implement them.

These mechanisms don’t eliminate risk. They create multiple opportunities to detect problems and limit their consequences.

The Engineering Operating System

I’ve already seen the practical value of AI agents in engineering workflows.

Recently, I used agents to triage and resolve five issues in our AV team’s escalation backlog. The agents identified problems and fixed the code. We validated the fixes on our own systems before deploying them to the affected customers’ systems.

That reduced the escalation backlog from five issues to zero.

The experience reinforced a principle I’ve followed throughout my leadership career: engineering effectiveness depends on more than individual capability. It depends on the system surrounding the work.

I describe that system as an Engineering Operating System.

Engineering leadership establishes the organizational structure, development practices, decision-making processes, tooling, and feedback mechanisms that enable engineers to deliver.

AI extends those responsibilities to agents.

We need to provide the appropriate context, architectural guidance, permissions, and validation. We also need engineers who understand these tools well enough to recognize their limitations and use them effectively.

As agents become more capable, I expect them to take on increasing responsibility for both implementation and architecture.

The engineering practices surrounding them will need to evolve accordingly.

Producing software is becoming easier. Coordinating architectural decisions, communicating intent, and establishing confidence in the resulting systems may become the more significant challenges.

Communication doesn’t disappear. It moves. Our engineering practices need to move with it.