About the author
Nikša Demović
Business Development Manager
TL;DR: AI-native software development is the software development lifecycle updated for a world where AI agents take the majority of research, planning, and execution. Engineers shift from doing the work to governing it. The process looks familiar at the phase level. The collaboration model, the quality standards, and the tooling underneath are different.
Introduction
Most software teams are somewhere in the middle of figuring this out. They have AI tools. Engineers are using them. Output is higher. But the process around those tools is still the same one that existed before they arrived.
That mismatch between tooling and process is where value gets left behind. Speed is one part of it. Quality is another. The bigger opportunity is freeing senior engineers to spend time on the decisions that actually require them. That’s what AI-native software delivery addresses.
What AI-Native Software Delivery Means
AI-native software delivery is a model where AI agents handle the majority of research, planning, and execution across the lifecycle, while engineers own architecture, domain logic, and accountability for the output.
The phases of the software delivery lifecycle (SDLC) stay the same. What changes is how the work inside each phase gets done, and who does which part of it.
In a traditional model, an engineer takes a ticket, writes the implementation, runs the tests, and opens a pull request. But in an AI-native model, an agent handles the implementation and test pass. The engineer defines the goal, reviews the output, and makes the calls that require judgment.
That’s a different collaboration model. And it requires a different process to support it.
Three Models Worth Distinguishing
A lot of teams use these terms interchangeably. They’re not the same thing.
Traditional development: Engineers own every step. Planning, coding, testing, review, deployment. No AI in the loop.
AI-assisted development: Engineers still own every step. AI tools accelerate execution, such as with autocomplete, code generation on request, suggestions. The engineer remains in control of every decision. The output is faster, not different in kind.
AI-native / agentic development: Agents handle multi-step execution toward a defined goal. The engineer specifies the intent, sets the constraints, and reviews the result. Between those two points, the agent reads the codebase, makes implementation decisions, runs tests, handles failures, and surfaces a result.
The meaningful difference between AI-assisted and agentic is task ownership. In AI-assisted, the task is yours. In agentic, you hand the task to the agent with a clear brief and defined boundaries.
The Spectrum: How Much Do Agents Own?
AI-native development isn’t a binary switch. It sits on a spectrum defined by two variables: how much agents do, and how much humans review.
At one end, agents assist. Engineers direct every step and agents help execute. At the other end, agents research, plan, implement, and test with engineers reviewing defined outputs at defined gates.
Notch operates toward the higher-autonomy end of that spectrum. Agents take the majority of research, planning, and execution. Engineers own the architecture decisions, the domain logic, and the review gates. The ratio is intentional. Notch engineers defined the boundaries of that operating model. And it’s documented so teams don’t have to figure it out from scratch in an enterprise context where most available guidance doesn’t apply.
Where a team sits on that spectrum also determines how dark code risk is managed.
Dark Code: The Problem With Ungoverned Agent Output
Dark code is AI-generated code that works but that no human has laid eyes on. It passes tests. It ships. And then six months later nobody can safely modify it because the reasoning behind it was never captured.
This is the central risk of AI-native development done without governance. Agents produce output at a rate and volume that human review can’t keep pace with if the process doesn’t have the right structure. Code accumulates. Comprehension debt accumulates with it.
At Notch, the hard rule is simple: we only commit code we fully understand and can defend. AI proposes. Engineers decide. That principle is built into how the harness works.
How the Collaboration Actually Changes
AI-native development changes who can work with the codebase, not just how engineers use it.
In a traditional software development lifecycle, code is something engineers write and everyone else waits for. In an AI-native SDLC, code becomes a shared artifact that every role can query and work with directly. An analyst can ask AI what a module does. A tester can ask it to explain a failure. A PM can ask it to map a feature to the relevant code paths. The codebase becomes readable and useful to everyone involved in delivery, not just the people who wrote it.
That’s a different kind of collaboration that goes across roles, not just between engineers and their tools.
The Harness: How Agents Are Structured
In an agentic SDLC, agents don’t operate as free-form assistants. They operate within a defined structure called the harness.
The harness for a coding agent typically includes:
A main agent that coordinates the task by breaking it down, delegating to subagents, and assembling the output.
Subagents that handle specific parts of the work. An agent scoped to test generation doesn’t touch implementation. An agent scoped to refactoring doesn’t modify business logic. Scope boundaries prevent agents from drifting into areas where their judgment shouldn’t apply.
Skills, which are reusable capabilities the agent can invoke for specific tasks.
Reference materials including documentation, architecture notes, and codebase context that the agent should load. Agents manage their own context, but guidance on what to load and what to leave out is valuable. Good documentation in the codebase itself helps significantly here.
Tools, i.e. what the agent can call. Narrow, composable tool sets produce predictable behavior and make governance tractable. Broad tool access does the opposite.
Memory, as in what context persists across tasks and what doesn’t.
The harness is version-controlled. Engineers define it. Agents operate within it.
What Changes in Each Phase
Research
Before planning starts, agents run a Q&A pass across the codebase, mapping functionality, tagging what’s relevant to the task and what isn’t, and gathering the information planning needs.
Planning
Agents analyze requirements, map affected areas of the codebase, and surface ambiguities before implementation starts. Engineers review the breakdown and confirm scope. The goal is to catch misunderstandings before they’re built into the code.
Development
Agents implement within the harness. The harness is version-controlled and reviewed like code, because that’s what it is. A change to the harness is a change to agent behavior. That needs to be tracked and understood before it ships.
Testing
Validation runs continuously rather than as a phase-end gate. Agents generate tests and run them in loops. Engineers set quality thresholds and review failures. The focus shifts from coverage of known execution paths to behavioral coverage across realistic scenarios.
Review
Agents surface changes for human approval. Engineers review at the decision level (architecture, business logic, security). The review gate is always human. Good harness design upstream makes this manageable at volume.
Deploy and operate
Issues within the system are detected and fixed much faster, thanks to agents. Agents correlate signals across sources, investigate and form hypotheses, check them against logs and traces, and propose what to do. Engineers own the escalation decisions.
Verification Debt and Why Governance Matters
When agents produce code at volume, subtle issues can accumulate inside pull requests that are difficult to review at the same depth as smaller, human-written changes. Architectural drift. Security gaps. Dependencies that weren’t intentional. The speed is real. So is the risk when governance doesn’t keep pace.
The answer is governance built into the process from the start – not added when something surfaces.
At Notch, that governance is NotchForge™.
NotchForge™
NotchForge™ is Notch’s engineering and delivery framework – one standard across AI-native software delivery, agentic systems, and custom model development. It defines how the harness is structured and managed, how tools are scoped, how escalations are handled, and how accountability remains with engineers regardless of who wrote the code.
The point isn’t to constrain agents. It’s to make their output trustworthy and maintainable.
How ADLC and SDLC work together
There’s a distinction worth making explicit, but it isn’t a choice between frameworks.
AI-native SDLC governs how software is delivered when agents are part of the team. The agent development lifecycle (ADLC) governs the development of agentic systems specifically: the phases, evaluation, and governance required when agents reason and act as core product behavior rather than delivery tools.
The two aren’t alternatives. Agents are always integrated into surrounding software. When you’re building an agentic system, ADLC sits inside the broader SDLC, governing the agentic parts while the SDLC governs delivery as a whole. At Notch, both run under NotchForge™, which is what keeps them coherent together.
Agentic systems introduce specific requirements the standard SDLC doesn’t account for: non-deterministic runtime behavior, evaluation of reasoning quality rather than just output, human-in-the-loop (HITL) as an architectural decision rather than a fallback, and post-deployment monitoring that feeds back into the build phase continuously. ADLC addresses those within the delivery context the SDLC provides.
What This Looks Like at Notch
Every engineer on every engagement uses coding agents as the default. Agents handle implementation, scaffolding, and test generation. Engineers handle architecture, domain logic, and the calls that shape the system.
The result is that senior engineers spend more time on work that requires senior engineers. Architecture gets more attention. Domain logic gets encoded with more care. Systems are built with the trade-offs understood and documented from day one.
That’s the value of AI-native delivery done well. Not faster for its own sake. Better because the right people are focused on the right problems.
FAQs
What is AI-native software development?
A delivery model where AI agents take the majority of research, planning, and execution while engineers own architecture, domain logic, and accountability. The SDLC is rebuilt around agents as participants, not retrofitted with AI tools.
What is the difference between AI-assisted and agentic development?
Task ownership. AI-assisted: engineers direct every step, tools help execute. Agentic: the agent owns execution toward a defined goal within a defined harness. The engineer owns the brief and the review.
What is dark code?
AI-generated code that works but that no human fully understands or can explain. It accumulates when agent output isn’t properly governed. At Notch, engineers only commit code they fully understand and can defend. The harness and version control of prompts are what make that possible at scale.
What is a harness in agentic development?
The structure that governs how a coding agent operates. It includes the main agent, subagents, skills, reference material, tools, and memory. Engineers define the harness. Agents operate within it. The harness is version-controlled.
What is NotchForge™?
Notch’s engineering and delivery framework. One governance standard across AI-native software delivery, agentic systems, and AI model development.
