If you are an early-stage founder, you have probably had the moment. You describe a feature to Claude Code or Cursor, step away to refill your coffee, and come back to a working branch. The thing that used to take your team a sprint took twenty minutes.
Then you spend the next three days figuring out whether you can trust it.
That gap, between how quickly agents produce code and how slowly everything around the code moves, is the real problem for small teams right now. Anthropic's AI-Native SDLC Playbook lays out how to rebuild software development around agents. It is thoughtful and useful, but it is written for regulated enterprises with platform teams, managed laptops, and change-management committees.
You have a laptop, a GitHub organization, an AWS bill, and maybe two other people. This is the startup-sized version: a practical AI-native software development lifecycle you can start this month.
The one idea worth stealing
The traditional SDLC was designed for a world where writing code was the slowest, most expensive step. PRDs, estimates, review gates, and sign-offs existed to create alignment before weeks of engineering work began. When agents collapse the build phase from weeks to hours, the bottleneck moves to planning, review, and deployment. Line-by-line human review stops being realistic, while governance costs grow because exceptions still route through humans who meet once a week.
The fix is not simply to add more AI. The fix is to make every stage end by committing a small, readable artifact to git, and to make the next stage start by reading it. The chain is:
intent.md -> spec.md -> plan.md -> code and tests -> PR review -> release or incident record
Both a human and an agent can read each artifact. Your git log becomes an audit trail: who asked for what, what the agent produced, and who approved it. For a startup, that is mature engineering discipline without hiring a mature engineering organization.
What to skip when you're three people
Skip managed settings pushed through MDM, private plugin marketplaces, a dedicated intent repository, and duplicate linkage to Jira or ServiceNow. These solve coordination problems you do not have yet. Anthropic's own guidance says that for a single product, an intent/ folder in the product repository is the simplest home.
Skip the committee, too. A product owner approves intent, a tech lead sets review thresholds, and a release manager authorizes production in the enterprise playbook. At your stage, those three people are you, or you and your co-founder. That is fine. The important part is that a named human makes the call and the decision is recorded in git.
The six stages, startup edition
1. Plan: write intent.md instead of a Notion doc
Every time you would normally open Notion and write, "we should build X," open your agent instead. Talk it through for ten minutes, then have it write intent/2026-09-feature-name.md. Correct what it got wrong. Commit it.
Your intent should cover the problem, the proposed outcome, affected users and systems, constraints, and open questions. The point is not ceremony. In three months, when a customer asks why an export behaves the way it does, you will have the answer in git. The next stage also reads this file, so the quality of your spec depends on the quality of this conversation.
This week: create intent/ and write one intent file for the next thing on your roadmap. Use the sections above and do not overthink the format.
2. Design: three skill files replace your design review
You do not have a brand policy owner, security team, or compliance department. Write three short skill files yourself:
stack.md: language, framework, database, auth provider, hosting, and the two or three architectural rules you never break.security.md: no secrets in code, every endpoint authenticated, no PII in logs, input validated at the boundary.ux.md: component library, empty-state and error-state conventions, and whether the product is mobile-first.
Then ask the agent to read the intent and produce spec.md that conforms to these skills. It should call out anywhere the rules conflict or cannot be satisfied. Commit the spec next to the intent.
A useful measurement is the time between the intent.md commit and the spec.md commit. For a small team, it should be under an hour. If it is not, your skills are probably too vague.
3. Build: plan mode, CLAUDE.md, and the twice-wrong rule
Start in plan mode. Give the agent intent.md and spec.md, then ask for an implementation plan that names the files that change, the order of work, the risks, and the tests that prove it works. Ask what could break, which step is riskiest, and what it chose not to do. Iterate until an engineer who never saw the conversation could implement it from the plan alone, then commit plan.md.
Plan mode gives you design review before code exists, when changing course is still just editing a document.
CLAUDE.md should contain the context a new joiner needs: commands, conventions, architecture, and the mistakes the team sees most often. Keep it under a page. The agent reads it at the start of every session, and stale content is wasted context.
The rule worth keeping is simple: when the agent makes a mistake twice, put the correction into CLAUDE.md. For a founder, this file is also your onboarding document. Your first engineer and your agent should learn the same operating rules.
On parallel work, start with two sessions in separate git worktrees. Your ceiling is not how much code agents can produce; it is how much change you can actually review.
Start anywhere, but make the next artifact visible. Image: SAMO Technologies.
4. Test: the feedback loop is the whole game
Always give the agent a way to verify its own work. That means one command, such as npm test or make test, that exits non-zero on failure. Put that command in CLAUDE.md with an example of healthy output. State a quantifiable target: all tests in a file pass, an endpoint returns 200 with the new field, or a checkout flow completes with a known fixture.
For a bug fix, reproduce the bug as a failing test first. Confirm it fails for the right reason, commit that test, and only then ask for the fix without allowing the test to change. A test that predates the fix and that the agent could not rewrite is evidence the bug is actually gone.
For UI work, give the agent a screenshot tool and the mock, then let it iterate. Two or three visual rounds are normal.
Defer continuous evals in CI until you have enough representative tasks. Start an evals/ folder and add a task whenever something goes wrong. That folder will become your suite by the time you need one.
5. Deploy: branch protection and one hook
First, turn on branch protection so nothing, human or agent, pushes directly to main. The agent can work up to the production gate; it cannot pass the gate. A human approves through branch protection.
Second, write a REVIEW.md with three passes: bugs, security, and compliance with spec.md and plan.md. Define what counts as Important versus a nit, and cap the number of nits. Run an AI reviewer on every PR, but preserve separation of duties: the agent that wrote the code must not approve it.
Third, add one production hook. A short shell script can block commands containing both deploy and production unless a release approval variable is set. The agent can prepare a release and run it in staging, then stop while you make the last call.
Finally, rehearse rollback. Make it one command, run it in staging regularly, and never let the first real rollback be the first time anyone has tried it.
6. Maintain: pick one metric
You do not need a fully autonomous production loop yet. Pick one metric with a stable baseline; post-deploy 5xx rate is the obvious choice. Write a deterministic script that logs when it drifts. Keep detection free of model judgment.
When the signal is trustworthy, add a read-only diagnosis tier. Later, add a proposal tier that opens a PR or triggers a pre-approved runbook. The important habit is that every finding becomes a new intent that can restart the loop.
Set up scheduled security scanning early, too. A scan is a point-in-time statement about a codebase under a particular model, and both halves go stale. Run it weekly for actively developed services and route findings through the same PR gate as any other change.
Governance for people who can't afford governance
Founders often treat governance as a later-stage problem. A disciplined AI-native SDLC quietly gives you much of it now, which matters the first time a customer's procurement team sends a security questionnaire or you start a SOC 2 readiness effort.
- An audit trail: every intent, spec, plan, review, and approval is a commit with an author and timestamp.
- Separation of duties: the agent writes code and opens a PR; a human approves through branch protection.
- Policy as code: skills advise the agent, while deterministic hooks enforce the few rules that must always hold.
You are not doing this for an auditor. You are doing it because it is the cheapest way to ship fast without shipping garbage. The audit story is a side effect.
A 30-day rollout
Week 1: run /init, reduce the generated CLAUDE.md to one page, and commit it. Create a test target that exits non-zero on failure. Turn on branch protection.
Week 2: write the three skill files. Write your first intent and have the agent produce a spec from it. Fix what is missing from the skills.
Week 3: build the feature in plan mode and commit plan.md. Write REVIEW.md, turn on AI PR review, and add the production hook.
Week 4: set up a weekly security scan, write the one-metric drift script, start evals/, and count the artifacts in your git log.
By the end of the month, you will have a process that most Series B companies would envy, built without slowing down.
The mistakes we keep seeing
Skipping plan mode because the task looks small. Small tasks without a plan are how you end up with a 400-line diff you do not understand.
Letting the agent edit tests during a fix. If the test can be rewritten to pass, it is not a test. Block it with a hook or reject it in review.
A bloated CLAUDE.md. If it is three pages, the agent is spending every session reading conventions that no longer apply. Prune it monthly.
Adding parallel sessions faster than you can review. More output is only a win if review keeps up. Two streams reviewed well beat five streams merged blind.
Treating artifacts as ceremony. If you write intent.md and then ignore it, you have recreated the PRD nobody reads. Each stage must actually read the one before it.
Where SAMO fits
At SAMO Technologies, this is how we work with founders and how our nearshore engineering teams operate day to day. When we take on an MVP or step in as a fractional CTO, the first week looks a lot like the rollout above: a lean CLAUDE.md, a real test target, branch protection, skills that encode non-negotiables, and a review policy the agent enforces on every PR.
It is how a small, distributed team keeps velocity high and quality predictable, which is what remote teams done right means in practice. Read more about the fractional CTO advantage or nearshore engineering for startups.
The bottom line
You need less process than you fear and more than you are doing. Start with the feedback loop and CLAUDE.md. Add the artifacts. Let the git log do the rest.
The source playbook is written for enterprise teams, but its central insight belongs to every founder shipping software with AI: when agents make code abundant, clarity becomes the scarce resource.
If you want a team that already works this way to build alongside you, talk to SAMO.
Source
This founder-focused adaptation is based on The AI-Native SDLC Playbook, published by Anthropic on August 21, 2026. The stage structure, artifact chain, and individual plays referenced throughout are drawn from that guide. The startup recommendations, 30-day rollout, and common-mistakes section are SAMO's own.