Building an app with AI: what to keep from the SDLC playbook

If you’re making an app with AI, the difficult part is often knowing what to ask next. Your preview looks good, but is the booking saved? Will a fresh visitor be able to sign in? What happens if you change your mind about an update? These are useful questions even if you’ve never written code. SDLC means the software development lifecycle: the steps from an idea to an app people can use. You can borrow the helpful parts without adopting a whole engineering process.

The part of the playbook I would keep

Anthropic’s SDLC playbook puts AI to work around coding as well as inside it. It emphasizes reusable project knowledge, reviewable artifacts, tests and operational follow-through. Those are useful starting points. Our view is that a small team should adopt the relevant job first, rather than automate the entire chain immediately.

A useful handoff answers a practical question: what changed, what evidence supports it, and what should the next person or assistant check? You can put that in an existing ticket, a pull request or a short file. Creating another document that nobody reads is not an improvement.

Start with the delay you can name

These are checks you can make in your own work, not claimed results from a customer study. Pick one and compare a few similar changes before deciding to expand the workflow.

A fictional export feature

Suppose customers cannot tell whether their file export finished. A rushed assistant might build a new dashboard, introduce notifications and choose a queue service. The actual first change could be much smaller: expose the existing job status and make failure recovery understandable.

The brief should name that behavior. The design comparison should inspect the worker the app already has. The review should ask whether a repeated callback creates duplicate files and whether another customer can retrieve the result. The release record should check old and new status values if the storage contract changes.

None of those decisions requires a particular framework. A Rails app, a Java service or a small Python worker needs different commands, but the customer behavior and ownership questions still matter. Build Brief is a free place to start; Build Choices helps when a real technical decision follows.

What I would not copy wholesale

I would not require a full specification and a second approval meeting for a spelling correction. I would not add parallel agents before someone can review the resulting changes. I would not connect a production-writing agent simply because a demo successfully drafted a fix.

There is also a distinction between guidance and enforcement. A skill can tell an assistant to respect an ownership rule. It cannot make a missing server check appear. The code, tests, identity permissions and deployment controls must actually enforce the boundary. A keyword-matching shell guard is not a complete security policy: aliases, wrappers and changed command forms can escape a simplistic match. Review the tool’s real permissions and your CI security configuration.

For a small team, the next useful step is usually a repeatable check around one customer task. Automation becomes more attractive once the inputs, permission boundary and failure handling are understood. It should remove known work, not hide unknown behavior.

Copy a starting brief

Change I am working on:
Customer problem and supplied evidence:
Smallest useful version:
What is outside this version:
Existing system and constraints:
Behavior we will check:
What is still unknown:
Use our current tools and conventions. Do not add infrastructure or approval steps just to complete a generic lifecycle.

Bring a real change rather than a request to transform the whole engineering process. If the sticking point is project context, use Project Memory. If it is a review, start with Code Check. The Build with AI collection lets you choose the task you need without adopting every stage.