Morning Brief: Intent Driven Engineering
H1: Morning Brief — September 20, 2026
Today’s three strongest opportunities line up unusually well with what you’ve been working through: the repo becoming an engineering control plane, governed intent-to-PR loops, and resisting unnecessary multi-agent complexity. The interesting part is that several major engineering organizations are independently moving toward those same architectural ideas.
———
H2: The Software Factory Is Real. But the Factory Needs a Specification.
On August 27, Uber published one of the more concrete descriptions I have seen of what an AI software factory looks like when it reaches serious scale.
The numbers are remarkable.
• More than 70% of Uber pull requests are now attributed to local or cloud agents.
• Engineers have created more than 3,600 agent skills, executing more than 30,000 times per day.
• Weekly users of its agentic tools increased sevenfold between February and August 2026, while requests increased 9.4 times.
But the most interesting part isn’t the volume. It is what Uber had to build around the models.
Uber describes specialized agents for code review, CI repair, end-to-end pull requests, incident triage, debugging and maintenance. It benchmarks models against real engineering work, measures cost per completed outcome, routes work between models, manages context and continually improves skills.
That is an important signal.
H3: The AI Software Factory Isn’t Just an LLM
For the last couple of years, much of the industry conversation has centered on which model writes the best code. That increasingly looks like the wrong level of abstraction.
The emerging architecture looks more like:
Intent → Context → Skills → Execution → Validation → Evidence
The model is one component inside that system.
Uber even found that loading large numbers of MCP tool definitions directly into context created substantial overhead. Its solution includes dynamically resolving tools, using CLI-based execution and creating reusable skills for common workflows.
That sounds much less like prompting. It sounds like software engineering.
H3: The Intent-Driven Engineering Perspective
There is one layer I believe becomes increasingly important as these factories grow: what governs the factory?
If thousands of agent executions are modifying software, somebody still needs to define what success means. That is where intent belongs.
• The intent defines the outcome.
• Standards define the boundaries.
• Skills provide reusable capabilities.
• Agents perform work.
• Tests and evidence prove whether the work satisfied the intent.
And much of that can live directly in the repository.
The future software factory may contain thousands of agents and skills. But complexity should not be the goal. The goal should be a system where a human can state an intent, establish boundaries, and receive verifiable evidence that the intended outcome occurred.
Human owns the intent and boundaries. The machine handles more of the execution.
That is a software factory I can trust.
Source: Uber — Running a Software Factory Efficiently at Uber Scale
———
H2: Atlassian Just Described an Intent-Driven Engineering Loop
Something interesting happened this month. Atlassian announced what it calls governed agent loops for the AI-native software development lifecycle.
The terminology is different, but look carefully at the architecture. Atlassian describes the loop this way:
1. Developers establish intent and guardrails.
2. Agents execute work in parallel.
3. Developers and product managers review what will ship.
4. Completed work updates the shared context for the next cycle.
That should sound familiar.
Atlassian says its research found that 94% of engineering leaders use AI, but only 6% have systems capable of scaling it across the software lifecycle. Its response includes shared code context, agent access controls, organizational standards, AI review and autonomous loops capable of moving well-defined backlog items toward pull requests.
The important word here isn’t agent. It is governed.
H3: We Are Moving Beyond the Prompt
The first generation of AI development was essentially conversational. Developer asks. AI answers. Developer asks again. That is useful, but it isn’t an engineering system.
The next generation looks different:
• The system knows the architecture.
• It knows the standards.
• It understands the repository.
• It has controlled access to tools.
• It executes repeatable workflows.
• It can produce evidence showing what happened.
That turns AI from an assistant into part of the software delivery system.
H3: This Is Why Intent Matters
The more autonomous the execution becomes, the more important the specification at the beginning becomes. Poorly defined intent multiplied by autonomous execution does not create productivity. It creates faster ambiguity.
That is why I keep coming back to four simple things:
• Intent
• Inputs
• Outputs
• Success Criteria
Then surround those with standards, contracts, tests and guardrails.
This does not necessarily require a giant enterprise AI transformation. A team can begin inside its existing repository:
1. Create an intent file.
2. Create standards.
3. Add reusable skills.
4. Define contracts.
5. Require evidence.
6. Progressively automate the loop.
That is a much more practical path toward AI-native engineering than simply giving every developer another chatbot.
The industry is beginning to discover that the real breakthrough isn’t autonomous coding. It is governed execution from intent.
Source: Atlassian — Governed Agent Loops for the AI-Native SDLC
———
H2: Stop Calling Everything a Multi-Agent System
Google recently published lessons from thousands of submissions to its AI Agents Challenge.
One observation jumped out immediately. Google said “multi-agent system” was probably the most common claim among submissions, but some supposedly multi-agent systems were really a single model moving through a sequence of prompts with agent names attached.
That may be one of the healthiest observations in agentic software engineering right now. We are in danger of making AI architecture complicated simply because we can.
H3: Architecture Still Matters
Google identified four recurring patterns among stronger implementations:
1. Bidirectional MCP
2. Event-driven concurrency
3. Consistent validation when falling back between models
4. Tiered routing that performs inexpensive deterministic checks before invoking an expensive model
Notice what is missing: there is no rule saying “use as many agents as possible.” Instead, these are familiar engineering ideas applied to AI systems: contracts, events, routing, validation, boundaries.
The technology changed. The responsibility of the architect did not.
H3: Structure the Boundary, Not the Reasoning
This is exactly why I have become cautious about over-orchestrating AI development.
• If one capable model with the correct context, tools and success criteria can accomplish the work, I don’t need five agents debating each other.
• If deterministic code can validate something, I don’t need another LLM call.
• If a reusable skill can perform the operation, I don’t need another orchestration layer.
• And if an intent file can coordinate the work from inside the repository, I may not need an external agent platform at all.
Start simple:
Intent → Skill → Execution → Test → Evidence
Add another agent only when the architecture actually requires another independent capability, context boundary or parallel responsibility.
AI-native architecture should not mean abandoning decades of software-engineering discipline. It should mean applying that discipline to a new execution model.
The engineer of the future may write fewer individual lines of code. But deciding what should happen, what boundaries must hold, and how we prove the result becomes even more important.
That is not less engineering. That may be where the engineering is moving.
Source: Google Developers — Four Engineering Patterns Behind the Strongest AI Agents Challenge Submissions
Wix tips:
• Use Wix’s built-in Heading 1/2/3 styles for the H-labeled lines (drop the “H1:” prefixes).
• Add hyperlinks to each source and to your two site links so they’re clickable.
• The → chains survive paste fine; if you’d rather have a visual, I can turn either chain into a simple graphic.
I can also produce an HTML version for Wix’s embed element, styled to the LTM design system, if you’d like tighter control over the layout.
Comments