Previously I had laid out several foundational considerations for how the AI agentic model can be applied within a technology or even more generically a knowledge work context.
Today in part two we will move on to thought experiment the iterative expansion of an AI SDLC as if we are building from zero to one.
We will assume here you are using Cursor and are opting to lean into AI-driven SDLC, even if the token usage should prove a bit costly. Buyer beware on selecting plan limits and models as those reasoning models can get expensive fast, as context accumulates.
What are we even building?
Entrepreneur culture has done its fair share of damage in emptying out startup phases of much of their meaning and sense, or twisting them into odd transmogrifications with minimal resemblance to their original use. (I have written about this in regards to the “agile” buzzword suite.)
This requires us to peel back the LinkedIn platitudes and LLM glitter to rediscover the truth that preceded the cacophany of cliché. Noise, noise, noise.
Something that we can only conduct in broad strokes as part of our larger survey here.
To start, we must ask what is the problem our solution is trying to solve.1
The purpose of a business is to provide a solution to its customers.
But discovering what this problem is is often harder to arrive at than the solution.
No one may even realize that the problem even exists until the business has provided the solution to it.
Here is the first of many important tasks which simply cannot be entrusted to the LLM on its own, unless you hope to wager on a generous glob of blind, dumb luck.
And here is a general principle we will see again and again.
The AI assistant may be helpful in workshopping your own idea for such a product or startup, but in the end some level of input is required from your part in order to identify what this is.
This is the entrepreneurial spark that requires human input and drive. Until we reach AGI, the AI is merely the receptacle and catalyst that engages with what you provide.
More than this, in order to be successful, you must exercise a strong degree of skepticism, caution, self-awareness, and critical distance toward the honeycomb hypnosis of AI brainstorming.
AI platforms are designed to maximize engagement and thus sycophancy is part and parcel of what the major AI providers design for.
They want you to feel like a genius who has discovered something genuinely novel. They will try to trick you into believing this yourself if you indicate that you are susceptible to such manipulation.
The designers of AI interfaces are more interested in retaining you as a fervently, perhaps obsessively engaged token spender trying to make it rich on the slot machine of AI slop startups than to see you actually succeed, make it rich, and check out.
More can be said on AI psychosis in general but these will merely be offered as cautionary reminders to the reader on their AI assistant journey.
Tangent aside, your starting point is to clearly define the problem it is you are hoping to solve.
What is the MVP?
Now that you have arrived at a problem definition you have a cornerstone upon which to build your AI SDLC apparatus.
At the root level of your project directory, you may at this point wish to create a simple Markdown file or Cursor rule .mdc file which contains this problem statement.
Problem: Users are struggling to properly apply the principles of 2026 AI agentic best practices into their personal workflow. Your goal is to pragmatically solve for this problem, using lean hypothesis testing.Or some similar example.
You are now ready to introduce your first stakeholder: the product owner.
The product owner is the role and set of concerns established around solving for the previously defined problem statement, and if necessary revising said problem statement based on new findings.
Given the problem statement, you can on your own or in collaboration with your AI assistant begin hypothesizing solutions to this problem statement. (For all intents and purposes, we will assume your problem statement can be solved through software logic without extra constraints or analogue considerations).
The goal of this brainstorming session is to produce a prospectus for a minimum viable product (MVP).
The MVP is not intended to build for its own sake or to be a catch-all for various utilities, nor even to be a single, defined piece of software logic, but to be a hypothesis offering a solution to the problem.
As in Eric Ries’ The Lean Startup, you will want to identify the cheapest, lightweight, viable path to test out and build the solution to your problem statement.
As with all AI brainstorming it is best to encourage it to (1) provide you with multiple solutions with comparative tradeoffs, (2) review the latest existing patterns and best practices, and (3) split this across different AI conversations leveraging different high-reasoning models so the AI assistants can review and fact-check each other’s work.
With careful attention to detail, review, and reprompting you should be able to arrive at a proposed first path to MVP, whatever that software or application stack is.
Or you may simply discover that existing products already sufficiently meet your problem statement, so you will therefore need to (A) revise your problem statement so that your solution will have a sufficiently unique business value proposition or (B) put this venture on hold and wait until the next entrepreneurial spark strikes.
If after sufficient skeptical prompting it seems that no existing product on the market meets the problem statement you have drafted, and you have a proposed pathway to building out an MVP hypothesis, you can now codify this MVP prospectus as a Cursor rule for your project workspace.
Henceforth, this MVP hypothesis should be safeguarded by an AI assistant expressly tasked with product owner responsibilities. This should be established as a Cursor skill which is scoped for case-by-case usage.
The key principle of AI SDLC is to never mix concerns or functions within a single AI conversation context.
New AI conversations around product review, feature planning, product stakeholder review should be self-contained with their own set of Cursor rules, skills, commands. To minimize hallucinations, you would never ask the product owner AI assistant to write code, just as you would want to avoid a human product owner from writing their own code, even if they could.
Toward MVP
Now that we have established our first stakeholder—the product owner—we can now establish our second: the founding engineer.
The founding engineer is the technical stakeholder responsible at these earliest stages with the initial design, prototyping, and iteration toward MVP.
This should also be codified as a Cursor skill which should point to both the problem statement and MVP prospectus so that it has sufficient conceptual context for the business problem they are hoping to solve.
The founding engineer AI assistant should never directly write to or modify product-level context information or rules, though they can certainly provide feedback prompts you can pass along to your product owner AI assistant to weigh these considerations.
The first step is for the founding engineer AI assistant to propose a lightweight yet architecturally sound technical design for building out an implementation that can minimally validate the MVP hypothesis.
This should include programming languages, managed services, frameworks, etc.
Depending on your level of technical proficiency or affinities, you should be explicitly biased in your selection of these tools based on these considerations:
Services, tools, and frameworks which have seen the greatest success (velocity + adoption) of releasing AI integration features such as MCP servers. It is not simple as releasing a MCP server but user feedback on its usefulness. This will accelerate your AI SDLC.
Failing any AI-specific tooling, the maturity of their CLI or API solutions. AI assistants can still operate headlessly if your provide the proper authentication access to credentials to integrate with providers. What you should avoid in almost all cases are UI-intensive or low-code solutions.
General popularity and adoption of frameworks or tools. LLMs are based on pre-baking an aggregate of the entire Internet. The more resources, Stack Overflow posts, etc. the Internet has to offer on a particular tool versus another, that should be a driving consideration (e.g. Vercel Next.js vs. Python NiceGUI). Weigh this against any personal experience you may have with the less popular too. Also take into account any blazing fresh tools may simply be too new for your AI model which may need supplemented by prompting it to check online results or docs.
How opinionated and structured the tool or framework is. Less opinionated tooling trust in the ability of the software engineer to properly develop their own classes, methods, objects etc. for the purpose of greater flexibility. Flexibility is consistently bad when it comes to AI SDLC as this opens greater risk for hallucination as AI assistants are notoriously incompetent with independent decision making, on the whole. You want your AI coding assistant to make the least number of decisions possible. To be fingers rather than brain. The number of technical problems such as file management or content delivery management you can remove from the concern of your AI software engineer the better.
The minimization of DIY logic. In my experience even with pretty explicit guardrails, AI assistants will attempt to build their own solutions and custom code rather than leveraging existing frameworks, solutions, or libraries. They will often need prompted to first explore these before determining a solution. Any tooling choices that provide the best suite of options for integrating with libraries, third-party services, etc. can remove this scope of concern from your AI SDLC workflow.
Minimal and lean tooling choices. This is more often a human temptation than an AI one, but the fewer tools and frameworks you need to adopt the better. If there is not a driving reason to add in Redis caching for example, forego it. You should only horizontally expand the technical stack when the advantage of adopting the new solution measurably outweighs the simplicity of keeping the technical stack leaner.
Forward-facing solutions. This is most open to interpretation but it is generally best to avoid short-lived tooling that simply does not scale well either from a cost or performance perspective, even if it offers developmental simplicity advantages. This can introduce technical debt or bottlenecks down the line which nearly invariably cost more time, effort, and frustration than simply choosing a different tool earlier in the SDLC process.
This is by no means a comprehensive list but general guidance on thinking through and defining these considerations for your MVP technical design prospectus.
When the lean set of tools (e.g. Next.js Vercel, TypeScript, Docker, SQLite) has been identified, you will want to codify a Cursor rule that will codify (1) the official documented generic best practices and patterns and antipatterns to avoid, (2) reminders to check the docs early and often for implementation patterns or syntax decisions, and (3) somewhat custom-tailored guidance based on docs or GitHub issues around your specific implementaiton solution.
You will not be able to anticipate every hiccup or design flaw in advance, especially if you lean heavily on the AI assistant for technical design, but the extent to which you can persistently exhort your AI assistant to consult tested solutions and logic will save you immensely on future development iterations.
What you produce in this step are the baselines, architecture, guardrails, and constraints for software development.
Depending on any other constraints or considerations around non-public or enterprise internal requirements, you may wish to supplement these baselines with further architectural considerations, but that is contingent upon whether you are building on your own or as part of an existing company.
Build
Now that you have clearly delineated the two foundational (and properly separated) concerns of product and engineering, you can now begin the ping-pong of an AI agentic workflow.
Have your product owner AI assistant use a high reasoning model to break down the MVP prospectus into an epic or series of epics according to Agile best practices while keeping things as concise and succinct as possible.
It is up to you whether you will simply have a mock epic/user story format using directory tree breakdowns locally or if you want to bite the bullet earlier with a basic JIRA plan or some other Agile or Kanban solution like ClickUp or Trello.
One of the biggest issues you will persistently encounter is the voluminous and superfluous bloat produced by your AI assistants will often blow past the context window of downstream models, so you must consistently revise and refine the AI output you are shepherding to keep it as minimal and concise as possible, while ensuring it does not into a broad brush stroke word puddle devoid of any real detail.
Iteratively review and rework these epics until they are sufficiently yet economically detailed. Then do the same at the level of user story by breaking down each epic one at a time, preferably in independent AI conversations that always route back to the grounding problem statement.
You may find it helpful at this stage to add a Cursor command init-po.mdc or some similarly named command you can remember which is basically an initialization prompt for a new AI assistant to basically put on the product owner (PO) hat and think with a product owner brain.
You can do the same with each individual function such as init-developer.mdc.
This reduces the need for you to repetitively prompt the same reference points and “catch you up to speed” details that will be needed each time you instantiate a new AI conversation.
Next, you will want to create a Cursor command intake-ticket.mdc which is geared to the founding engineer or developer role you have created.
The idea is that this prompt should make sure the AI assistant is up to speed on technical design, constraints, tooling choices, etc. and based on that propose a technical implementation for the particular user story ticket it is pointed to, including the development, build, deploy, test stages of the AI SDLC workflow.
Again prompt it for best practices including the stages at which you would like to review as the human in the loop. This works best with Cursor Plan to develop the implementation plan artifact that can then be executed by that AI conversation or another. You can also leverage Cursor’s built-in browser or other developer tooling to run and render your application locally. (Integrating the user story implementation with Git version control is also crucial to avoid AI hallucinations wreaking havoc on your codebase.)
The key is to implement just one user story as defined by your product owner AI assistant.
When that user story is ready for review, you will then open a new conversation window and then properly contextualize the product owner AI assistant to then review-ticket.mdc to ensure that the code implemented by the founding engineer AI assistant meets the acceptance criteria.
This may take a bit of back-and-forth and revisions, but this should primarily be an exchange between the two agents that you as the manager can facilitate, clarify, and oversee, but ideally intervening as minimally as possible.
While it may simply be most convenient to pull up something yourself and work it out if you’ve got the technical chops, this undermines the ability of the AI agents to iterate toward a self-sufficient SDLC workflow.
The more disciplined method is to try at least several times to fine-tune your prompting, Cursor rules, and skills so that he AI agent is itself empowered to carry this work end-to-end, insofar as it is possible. There may of course be exceptions where LLM models will consistently hallucinate around the solution and require your direct intervention.
When the work has been completed, the cherry on top is to then prompt both AI stakeholders to review their own Cursor rules, docs, and skills to see if there were any lessons learned that could be baked into the context knowledge base (according to best practices) so future AI assistants can benefit from this guidance.
This often produces corrections or amendations to your AI documentation which can help correct against any specific hallucination tendencies (such as syntax) which a particular LLM may make over and over again across different conversations.
This is the basic SDLC by which you can iteratively knock out user story by user stories until your epic is completed. Then you can review the epic as the product stakeholder to check it off before proceeding to the next.
Following this self-enclosed AI DevOps/Agile workflow helps to produce not just a MVP or new application but the necessary AI context infrastructure to undergird support, maintenance, or extending this platform iteratively over time.
The key is to have one or more AI agents checking the work of one stakeholder internally as well as the work of the other stakeholders without improperly mixing boundaries.
Conversely, here are some temptations to avoid:
One-shot AI solutions that deviate from established patterns and practices for your project just to get something across the line. Especially tempting after multiple hours of what feels like zero-progress AI SDLC.
Glossing over AI output or questions and telling it to figure it out itself. Like with human management, you should prompt it to do its research and prompt you with multiple choices with clearly tracked tradeoffs.
Mixing product and development work into a single AI context conversation. This can lead to a greater risk of “shortcuts” which introduce tech debt and other risks.
Collapsing multiple efforts or tasks into a single shot AI conversation. As easy as it may sound, this also introduces the risk of mixed concerns and hallucinations that also make rollback or version control more difficult.
Leaning into high reasoning models for every task. This will not only cost a pretty penny but generally can result in overengineered solutions. High reasoning models cna be helpful if after several rounds of debugging the problem is not clear, and you need the AI assistant to take a step back and perform general review.
Skipping any lessons learned or retrospectives. This will prevent you from iteratively improving your AI context knowledge base which honestly can only be effectively improved through empirical feedback with actual implementation. You cannot one-shot AI prompt yourself into a 100% set of Cursor rules and skills for your project. As nice as that would be.
Scale
You will have to decide how involved you will be as reviewer either on the product side speaking for product requirements or UI/UX or on the developer side for technical design and implementation.
It is best to start with as much involvement as you are capable of accomplishing yourself and then iterating from there so that after defining those initial processes you may elevate yourself out of the equation and delegate to your AI agents, much as a founder would in a scaling startup environment.
As your product grows, so too do the sets and types of concerns.
You may reach a point where you will want to separate out UI/UX into its own AI agent with its own context management integrating with Figma’s MCP for example.
Or a QA agent that is well-versed in Playwright and integrates with QA test suite tools or frameworks like Cucumber.
Or a DevOps agent for infrastructure if you move toward a cloud-first model.
As you can probably piece together, the primary flow is not unlike how a normal startup would scale from zero to one as it adds new personnel and talent.
The advantage of AI SDLC for greenfield work is that you can defer the point at which you would previously need to incorporate hiring human talent to further down the chain. This can make prototyping much cheaper and, under the right direction, faster.
There is of course the pipe dream of the one-person unicorn startup built off the backs of hundreds of AI agents, but this is far easier said than done. To scale successfully, you will probably need more humans in the loop.
There of course many other steps in the early life of a start up, and we have not even touched upon multi-environment management such as dev, staging, productoin, but that is not the point here.
What I hope this piece illustrates is how to concretely think through and iterate upon an AI agentic-driven SDLC workflow that can scale with your platform in a sustainable manner, so long as you are committed to the token costs associated with leaning into the AI.
In nearly all considerations it boils down to a question of how a startup founder would do the same for human role management and extrapolate those concerns, responsibilities, and priorities to an AI representative while properly segmenting AI assistant context accordingly.
In Part III, we will run this thought experiment against the IT Service Management (DevOps) function of a startup, thinking from zero to one again, but with an eye to the operational and cloud provider constraints which will provide a distinctive shape to our Cursor strategy as opposed to the specific concerns of software development.
I hope this thought experiment may prove of some use to those curious but serious enough in dabbling with their own MVP.
This is by no means an original insight of my own, though I can recall no single place where I may have encountered it originally. In recent months I have even found it in Software Engineering at Google: Lessons Learned from Programming over Time.