The 4 Patterns of AI Native Development

What changes in software development when AI does more than complete the next line of code? The technology has progressed from language models to retrieval-augmented generation (RAG) and codebase indexing, then to functions exposed through the Model Context Protocol (MCP), agents, and emerging teams of agents. But adding those capabilities does not, by itself, establish a new way of working. Like the earlier shift to cloud-native development, the deeper question is which practices change once the technology becomes part of the workflow.

A developer’s job is a bundle of tasks, including collaboration as well as writing code. New technology can replace some tasks, enhance others, and create work that did not exist before. AI-native development changes that bundle of responsibilities. Patrick Debois organizes these changes into four patterns, each moving outward from the developer’s existing role.

Debois approaches this through his background in DevOps and DevSecOps: automation changes how people coordinate and supervise work, not just how quickly individual actions happen. Introducing himself as an independent industry advisor, he also describes his work curating software-engineering stories for the AI Native Dev community.

When agents produce the code, the developer becomes responsible for managing that production. The immediate difficulty is review: Debois observes that less time spent coding can mean more time spent reviewing, with greater cognitive load. While writing a change yourself, you develop an understanding of its decisions as you go. With generated code, you have to reconstruct that thinking afterward.

The review interface therefore matters. A red/green diff exposes edits, but can be clunky to interpret; a chat transcript preserves the interaction, but can be verbose. Debois contrasts these with a What Matters view that distills the material needed for an acceptance decision. For changes spanning multiple files, a guided sequence can give the reviewer a coherent path through the work. Diagrams offer another representation, making relationships, errors, and the impact of a change easier to inspect.

These examples lead to moldable development environments: editors that adapt their presentation to the code, domain, and review task at hand. A structural change may deserve a diagram; another change may need a focused summary or a sequence of smaller reviews. Debois presents this as a possible direction for IDEs, with the aim of reducing the effort required to understand generated work instead of presenting an endless stream of text.

Greater autonomy also changes when review happens. Aider illustrates the inversion: automatically commit generated changes, then let the developer inspect and reject unwanted work, rather than requiring a manual yes before every commit. Automatic committing does not validate or deploy the code. Debois connects the broader move toward auto-acceptance with judgments about risk and impact: which changes are acceptable without stopping the workflow?

Longer-running agents need recovery points as well as acceptance decisions. Checkpoints let a developer return to an intermediate state and regenerate from there. That avoids restarting the entire iteration and reviewing all of it again when only a later portion needs correction.

Delegation also needs explicit boundaries. A file lock expresses that a particular file must not change; agent permissions define which actions are allowed. The displayed editor example puts a Lock file action beside a checklist of permissions. These controls turn a manager’s instructions about what may and may not be touched into limits on the agent’s work.

The unit of attention then expands from an individual prompt to the entire task. Debois’s displayed long-running task example costs almost $10. The workload, duration, model, and billing conditions are not specified, so the useful lesson is to track cost per task as agents work for longer stretches. Supervising their output includes supervising the resources they consume.

Managing generated code leaves an earlier question unanswered: what should the agents build? The second pattern moves attention from directing the implementation toward specifying the intended result. The developer describes the outcome and gives the agent room to work out how to achieve it.

A simple starting point is a reusable Markdown specification included with the prompt. Functional and technical requirements no longer have to be typed again in every conversation. For example, a small specification for an issue-list feature could make the desired behavior explicit:

# Issue list filtering

## Functional requirements
- Let users filter issues by status: open or closed.
- Show all issues when no status is selected.
- Preserve the selected status when the page reloads.

## Technical requirements
- Store the selected status in the URL query string.
- Use the project's existing issue-list component.

The file gives subsequent requests a stable statement of what the feature should do, instead of relying on repeated instructions scattered through chat.

Once intent is written down, AI can help turn it into an execution plan. Debois shows GitHub’s task-oriented approach as an example of translating a requested outcome into steps. The resulting workflow is:

1. Specify the desired behavior and constraints.
2. Plan the tasks needed to satisfy them.
3. Generate code from that plan.

This changes the primary interaction from chat and text completion to defining and supervising tasks.

A specification-centric tool can extend that approach across functional, technical, and security requirements. The specification becomes the organizing surface for the workflow, with less attention devoted to the code itself. Taken further, the developer’s role starts to resemble program management: overseeing the process that turns intent into implementation, without necessarily watching every coding step.

A clear specification can still describe the wrong thing. The third pattern moves another step upstream: discovering which intent is worth pursuing. With production pipelines handling delivery, specifications guiding the work, and developers managing agents, more attention can go toward exploring the problem and deciding what to build.

Rapid prototyping is the first expression of this shift. Debois points to Lovable and Bolt as tools for building prototypes through vibe coding. The value is not limited to producing one design more quickly. Generating several versions gives people alternatives to compare and can suggest possibilities they had not considered.

Discovery then becomes a repeated design-to-code loop: create a design, generate the implementation, reconsider the design, and modify the code. Each iteration helps clarify what the product should become.

Debois extends this into a customer-facing possibility. Imagine customers creating the interface they want on top of an existing product. Rather than choosing only among interfaces the product team supplied, they could adapt the experience to their own needs. He compares the idea to intensified A/B testing: customer-created variations could help expose the friction between the product’s default interface and the way people actually want to use it. This is a proposed use of the workflow, not a demonstrated deployment.

Discovery produces ideas; specifications record intent; managed agents produce code. All of those activities also produce learning. The fourth pattern is to turn that content into reusable knowledge so the team does not keep solving the same problems.

The inputs extend beyond the codebase:

• Production issues: bring what happens in operation back into the code.
• Incident response: retain what failed, what should not be repeated, and which guidelines or technologies need to change.
• Codebase lessons: explain the existing system to help people onboard and preserve understanding when someone leaves.

The codebase-to-lessons example shows a Shoulder.dev dashboard with cards for learning, codebase exploration, dependencies, and contributing. It makes the knowledge goal concrete: existing software can become material people use to understand and work on the system.

One especially useful form of retained knowledge is feature memory. A team tries a feature, dismisses it, and later tries it again because the original decision has disappeared from view. Recording the attempt and its rationale gives the next discussion context. Decisions that would otherwise remain buried in tickets or architecture diagrams become knowledge the team can bring into future work.

Capture can happen inside the development workflow. As a person chats and codes, an agent can identify something potentially worth retaining and propose saving it as knowledge. The proposal is the important intervention: useful context is recognized while it is still available, rather than depending entirely on a separate documentation pass. Debois describes a feedback loop in which both the person and the AI benefit from retaining what they learn.

That retained knowledge has two destinations. It can help answer other people’s questions, and it can inform later coding work. The result of one development cycle becomes context for the next, connecting what the team has already learned with the solutions it generates.

The four patterns widen the developer’s responsibilities into areas that already exist elsewhere on a software team:

Debois connects this broader scope with what good senior developers already do. The change reaches beyond faster typing: it concerns the judgment needed to direct work, choose useful outcomes, and retain understanding across development cycles.

For further exploration, Debois points to the AI Native Dev landscape and its news coverage at the intersection of software engineering and AI. He estimates that the landscape contained roughly 300 tools at the time of the talk. The original site now leads to the Tessl community. The tools provide examples to explore, while the four patterns describe the responsibilities that change as those tools enter everyday development.