AI-native SDLC
"A prompt dies with the session. A rule is still there in the morning."
The shift
I used to describe the change as AI inside the software lifecycle. I don't anymore.
SDLC is a sequence of phases owned by people. AI in SDLC keeps that sequence and puts a copilot in each box. AI-native SDLC throws the sequence out as the thing you design. The artifact is a rule, a skill, and an eval. When those are specific enough to run without you re-explaining the job, they are a functional agent.
SDLC
People own each phase: requirements, design, build, test, release. The handoff is the process. The thing you version is the ticket and the code.
AI in SDLC
The same phases. A copilot in each one. Faster, and still gated by whoever is prompting. The thing you version is a prompt and a diff. The next session does not remember it.
AI-native SDLC
The phase is not the unit of work. A skill is. Rules constrain it, an eval says whether it held, and an agent runs it. A person sets the intent and accepts the result.
What AI in SDLC actually was
In August 2024 our team won the GHC.DHM hackathon by putting an assistant in every phase of the old lifecycle. In 15 minutes we had a working app. I wrote that up as AI in SDLC. The lesson I took home was: AI is a collaborator, and the phases stay.
I wrote the same idea down again as a table. Planning, development, testing, monitoring, governance. Each row had a copilot. The picture of that moment is a wall of tools, more than a hundred of them, one job each.
That model is real, and it is where the idea stops. The phases did not change. Quality depended on who was typing that day. We collected tools. This page used to be a list of them: a whiteboard, an ERD editor, a Swagger UI. Useful instruments. Not a practice.
| SDLC | AI in SDLC | AI-native SDLC | |
|---|---|---|---|
| Unit of work | A phase, done by a person | The same phase, with a copilot | A skill, run by an agent |
| What you version | Tickets and code | Prompts and diffs | Rules, skills, and evals |
| What repeats | The ceremony | The ceremony, faster | The contract |
| Where it fails | The handoff | The next session | A constraint you never wrote down |
| Who accepts | The next role in line | The person who prompted | The person who owns the outcome |
What changed in the work
The jobs after that hackathon were not demos. I designed a health data platform end to end, took it into bids, built the data layer, the AI products, and the application, and led the team in front of the customer. The case study is the Health Intelligent and Interoperability platform.
The bottleneck was not "can a model write this function". It was "can the next run follow the same constraints and leave something I would sign". A prompt cannot hold that across a bid, a review, and a second engineer. A rule can. A skill can. An eval can tell you if they held.
That is the break. AI in SDLC asks how to speed up a phase. AI-native SDLC asks what has to be true for an agent to do the job again tomorrow.
Rules and skills become the agent
This is the part I would standardize. Not another tool.
A rule is always on. It states a constraint: how a healthcare model is shaped, what must not ship, how a proposal is structured. If it only applies to one task, it is not a rule.
A skill is a procedure with a trigger. "When we bid an interoperability platform, take these steps, and leave this artifact." One skill, one job. The inputs and the file it must produce are part of the skill, or it is still a prompt with a title.
An eval sits inside the skill. The old lifecycle put testing after coding, so a run could look finished and be wrong. If the check is a later phase, it will get skipped when the calendar slips.
Those three are the contract. They live in the repo, next to the code, not in a chat I have to paste again. On this site, that is already how a page gets written: the constraints and the procedure are files, and an agent runs them.
Rule
Always on. A constraint the run is not allowed to break.
Skill
A named procedure. One trigger, one job, one artifact left behind.
Eval
The check that the skill held. Part of the run, not a phase after it.
Functional agent
The same contract, specific enough that an agent can run it and a person only has to accept or reject.
The arrow is standardization, not a new product. A skill I can only perform myself is unfinished. The point of writing it down is that another engineer can follow it, and then an agent can. When the eval passes without me in the room, the skill has become a functional agent. The runtime (Cursor, Copilot, whatever is next) is replaceable. The contract is not.
How I split the work:
- I still set the intent, and I still accept the result. On the health platform that is the architecture, the bid, and the customer conversation.
- The agent runs the skill: draft, implement, check against the rule.
- I do not keep a private prompt library. If it has to be true next month, it is a rule or a skill in the repo.
Best practice
Five rules I actually use. They are small on purpose.
- Write the rule before the prompt. A prompt is a one-time instruction. A rule is a constraint that applies on every run. If you are pasting the same paragraph into every chat, it wants to be a file.
- One skill, one job. A skill that "helps with development" is a copilot with extra steps. A skill that names the trigger, the inputs, and the artifact it must leave is something you can hand to an agent.
- Put the eval in the skill. Say what "done" is in a way a run can fail. A green eval is the handoff. A paragraph that says "looks good" is not.
- Standardize until someone else can run it. That someone else is the test. First another person on the team. Then an agent. If the skill only works when I am watching, it is still tribal knowledge.
- Keep the person on intent and acceptance. The agent does not own the customer, the bid, or the decision to ship. I do. The agent owns the repeatable middle.
What will change
- The ticket gets thinner. The durable object is the skill, not a task description that restates the architecture every time.
- Review changes object. Less "why this line", more "which rule fired, and did the eval pass". Line review stays for the parts a rule cannot see.
- Teams will share skills the way they share CI. A skill that works for one person becomes a functional agent the team can call. That is the standardization. It will feel ordinary, the way a pipeline does now.
- Tool choice falls behind the contract. The copilot map above is the previous chapter. The next runtime can host the same rules. Switching tools should not mean rewriting the practice.
- The roles split cleanly. Solution architecture writes the rules of the system. Forward-deployed work writes the skills from the customer engagement. The agent executes. The person accepts.
What I stopped
I stopped maintaining a page of favorite tools. I stopped calling the 2024 hackathon the destination. It proved that a phase can be faster. It did not prove a system you can run twice. I stopped rewriting a long prompt for every task and hoping the next chat remembered the architecture.
The middle chapter, with the phase table, is still in Tech stack standards. Read it as history.
© 2026 Kato (Quan Ngo), Solution Architect at FPT Software