From AI-enabled to AI-native: rethinking the engineering organization with AI software factories

A few months ago, Martin Coulombe, our CEO, attended a Pragmatic Engineer conference that shifted how he was thinking about AI in software development.

Like many engineering organizations, we had already been experimenting extensively with AI. Our developers were using new tools. We were building agents. Through Ambrosia, our software factory principles, we were integrating AI directly into real software delivery workflows.

In our recent article, How we use AI agents to help software teams deliver with less friction, we shared what we have been learning through the AI software factories we’ve built with Ambrosia, our approach to integrating specialized AI agents directly into software delivery workflows. Those experiments reinforced something we increasingly see across our work: once AI can participate meaningfully in delivery, improving individual productivity is no longer the most interesting question.

The bigger question becomes: How should the engineering organization itself change?

AI-enabled and AI-native are not the same thing

Most engineering organizations today are becoming AI-enabled. Developers use coding assistants. Project managers experiment with AI to structure tickets. Teams generate documentation or test cases. Each person finds ways to accelerate parts of their work.

The tools change, but the operating model largely stays the same. An AI-native engineering organization goes further. AI participates throughout the software lifecycle, from understanding business needs and exploring architecture to producing code, running tests, supporting deployment and maintaining software.

People and agents coordinate work together. Context becomes shared infrastructure. Controls and evaluations are designed into the workflow. And the delivery model begins to evolve around what this new combination of human and machine capabilities makes possible.

That distinction matters because simply adding AI to an existing process can make individual activities faster without making the overall system faster.

Faster code moves the bottleneck

When code becomes easier to produce, code production becomes less likely to be the constraint. Other parts of delivery start to matter even more.

Is the problem clearly defined? Does the team have the right business context? Are architectural decisions sound? Are requirements specific enough for people and agents to act on? Can generated work be evaluated reliably? Can multiple streams of work happen in parallel without creating integration problems? Are we building the right thing in the first place? In other words, the bottleneck moves.

This is why measuring AI transformation primarily through lines of code, coding speed or individual developer productivity misses much of the point. Producing more software faster only creates value if the organization can turn that increased capacity into better outcomes.

The goal is not to maximize code generation. It's to shorten the distance between a business need and secure, maintainable software that solves it.

Think in systems, not prompts

One of the biggest shifts we are seeing is from prompting AI to designing engineering loops in which AI can operate. A coding assistant helps an individual complete a task. An AI-native delivery system gives agents the context, tools, environments, rules and evaluation mechanisms they need to collaborate with humans across a workflow.

We think of this as an AI software factory: an integrated delivery system where people and agents work together to turn business needs into governed, secure and maintainable software. The important part is not the word “factory.” It's the surrounding system.

An agent needs more than a prompt. It may need access to project documentation, architectural decisions, tickets, repositories, test environments, logs and business rules. It needs to understand what it's allowed to do. Its work needs to be evaluated. Some actions may require human approval. Others may eventually happen automatically.

This is where organizational knowledge becomes particularly valuable. Clear documentation, accessible domain knowledge, engineering conventions and well-structured decisions are no longer useful only for onboarding people. They become inputs into how the entire human-and-agent system performs.

For many organizations, that means some of the work required to benefit from AI will look less like adopting another tool and more like improving the foundations of software delivery itself.

Autonomy should be earned

Giving an agent access to more tools does not automatically make a workflow more mature. The better question is: How much autonomy has the system demonstrated that it can handle reliably? We see autonomy as something that should increase progressively.

An agent might begin as an assistant, recommending changes that a human reviews every time. As reliability improves, it can become a contributor that produces work within a controlled environment. For low-risk and well-understood tasks, humans may eventually review exceptions rather than every individual action. In more mature workflows, an agent can complete clearly defined processes while people monitor outcomes.

The objective is not full autonomy for its own sake. It's the right level of autonomy for the task, risk and evidence available.

That requires evaluations, measurable success criteria, clear permissions and human approval points. Governance cannot arrive after adoption. It has to be part of the architecture.

This principle also gives organizations a more practical path forward. You do not need to redesign the entire engineering organization at once. Start with a workflow where the outcome is clear, the risk is manageable and performance can be measured. Then expand autonomy based on demonstrated results.

The developer role moves upstream

As AI becomes capable of doing more execution work, the value of experienced engineers does not disappear. Their leverage changes. Routine code production, information retrieval, repetitive changes and parts of manual verification can increasingly be supported by agents.

That puts more emphasis on the work around execution: Framing the right problem. Curating the right context. Making architectural decisions. Designing systems. Supervising agent execution. Creating effective evaluations. Recognizing when an output is technically correct but still wrong for the business.

These are not secondary skills. In an AI-native environment, they become central engineering skills. We are already seeing this through Ambrosia. When an agent can implement a ticket or prepare a pull request, the quality of the ticket matters more. When an agent can consume project documentation, keeping that knowledge structured and current matters more. When work can happen in parallel, architecture and coordination matter more.

The engineer increasingly becomes responsible not only for producing an output, but for designing and supervising the system that produces it.

That can create significant leverage. Smaller teams may be able to coordinate more work in parallel, while engineers spend more of their time on decisions that require judgment, experience and business understanding. But that leverage only appears when the surrounding operating model supports it.

Building an AI-native organization is an operating-model challenge

This is why we believe the next stage of AI adoption in software engineering will be less about which coding assistant an organization selects and more about how it redesigns delivery.

Several questions become important:

• How does context move between people, agents and tools?
• Which work should happen autonomously, and which decisions should remain firmly human?
• How do we evaluate AI-generated work consistently?
• What happens to team structures when more work can happen in parallel?
• How do engineering leaders measure progress when traditional productivity metrics no longer tell the full story?
• How do we make organizational knowledge reusable across projects instead of rebuilding context every time?

There will not be one operating model that works everywhere. The right answer depends on the organization, its systems, regulatory environment, engineering maturity and tolerance for risk.

But waiting for the technology to stabilize before addressing these questions is unlikely to work either. The technology is evolving quickly, and the organizational learning takes time.

Start with one workflow

Becoming AI-native does not require a big-bang transformation. A more useful approach is to build capability progressively:

• Assess. Understand the current delivery process, tools, constraints and baseline performance.
• Focus. Choose one valuable workflow with a clear outcome and manageable risk.
• Build. Connect agents to the context, engineering tools and controls required to perform the work.
• Validate. Establish evaluations, human approval points and measurable success criteria.
• Scale. Expand the workflow and level of autonomy as performance is demonstrated.

This creates a feedback loop between technical capability and organizational learning. It also shifts the conversation away from “How do we deploy AI everywhere?” toward a much more useful question: Where can AI meaningfully improve how work moves through our organization?

The opportunity is bigger than faster development

The first wave of AI in software engineering helped people perform individual tasks faster. The next one changes how the work itself is organized.

Done well, AI-native engineering can shorten the path from idea to working software, allow more work to happen in parallel, make engineering practices more consistent, reuse organizational knowledge across projects and create more capacity for experimentation and modernization.

Most importantly, it can give engineers more time for the parts of software development where human judgment matters most.

Using AI is quickly becoming a given. The real work now is building the systems, practices and organizations that can turn that capability into meaningful business value.

Where should you start?

If your teams are already experimenting with AI but you are asking what comes next, that is exactly the kind of problem we are exploring with our clients.

We can help you look at your software delivery process, identify where AI and agents can create the most meaningful leverage, and design the workflows, controls and operating model needed to make it work in practice.

Contact us to discuss about where AI-native engineering could create value in your organization.