AI is changing software development, but not by creating one fixed way to build everything. The AI-native software development life cycle will not be one process. It will be a set of working patterns shaped by the problem, the code, and the parts of development that people want to handle themselves.
A discussion that began on Jul 1, 2024, offers a clear example. Lord Crappington described using GitHub Copilot to assist with firmware development, from planning and breaking down tasks to writing tests and checking the results. The experience shows how an AI assistant can take part in the work before coding starts, then continue through testing.
Planning Became a Conversation
The process began with a planning session. Instead of only producing an answer, the AI asked questions that helped solidify the design. That detail matters because planning was not treated as a single instruction followed by automatic code generation. The design became clearer through questions and responses.
After the planning session, the AI created about 25 work items. Those items gave the project a structure, but they were too large to test with unit tests. Lord Crappington explained the problem this way:
“It came up with like 25 work items, but the problem was they were all huge items that weren’t really testable with unit test. So I had Luna break all the items down and there were like 150 afterwards, haha.”
Luna was the AI tool used to break down the work. The change from 25 larger items to approximately 150 smaller ones turned a broad plan into tasks that could be tested. The numbers also show a limit of AI-generated planning: a useful first plan may still need another pass before the work fits a testable development process.
Different Jobs for the Person and the Agent
The user then created a custom agent with a focused set of jobs. It could find unmarked items, write tests, run test benches, and mark items complete. This gave the agent responsibility for a repeatable loop that connected the task list with testing.
That setup did not remove the user from the project. Instead, it divided the work between problem solving and repeated test activity. The agent handled the steps that could be described as a sequence, while the user stayed connected to what the firmware development produced.
Lord Crappington described that balance directly: “What it has taught me is that I really like the problem solving part of programming and this way I’m still connected to what gets built.”
That comment points to a central feature of AI-assisted development. The value is not only measured by how many tasks an AI can complete. It also depends on whether the process leaves people engaged with the decisions and results that matter to them.
Automation Works Best Where the Work Repeats
Testing became the clearest place for the custom agent to help. Tests include boilerplate code, and the agent can replicate that code again and again. The user finds that useful because repeated setup does not need the same attention as solving a new programming problem.
Lord Crappington put the contrast plainly: “Tests have a lot of boilerplate code that the agent doesn’t mind replicating over and over, while that would get old quickly for me.”
The division is simple but important. The user values the problem-solving part of programming and the connection to what gets built. The agent takes on work that involves finding unmarked items, repeating test patterns, running test benches, and updating completion marks.
That does not describe one universal AI-native SDLC. It describes one process built around firmware development, planning questions, task breakdown, custom automation, and testing. Another project could use the same pieces in a different order, or place the person and the AI in different roles.
The shift is less about handing software development to an AI and more about choosing where an AI assistant fits. GitHub Copilot helped with planning, task breakdown, and testing, while Luna handled the move from 25 broad work items to about 150 smaller ones. A custom agent then connected those items to tests and test benches.
For this user, the result kept programming’s problem-solving core intact while moving repetitive work to an agent. That is why the AI-native SDLC will not be one process. It will depend on which parts of development need judgment, which parts need repetition, and how the person wants to stay connected to the final build.
Based on
