Guardrails for AI-written code: what 1,156 merged PRs taught a non-developer

Saygin Celen — Tue, 13 Oct 2026 14:48:59 +0000

I don't write code. Between February and October 2026, Claude Code wrote the code for my product, SiteNeuro, and I reviewed it: 3,215 commits and 1,156 merged pull requests over 175 working days. The platform has been live for two months and has built more than 1,000 websites.

Developers reviewing AI output have an advantage I didn't have: you can read the diff. But the failure modes I hit are the same ones you'll hit on any AI-assisted project that outgrows a single chat. Here are the guardrails that fixed them, with the templates.

The failure mode

Pure chat-driven building ("vibe coding") breaks in a predictable way once a project gets big:

Decisions live in the chat, and the chat forgets.

Fixes collide, because nothing states the rules a fix must respect.

Every session starts with re-explaining context.

The answer isn't a better model. It's moving the memory out of the chat and into the repo.

1. A constitution in the repo

A short file of non-negotiables that the agent reads at the start of every session (Claude Code loads a project memory file automatically).

Mine is grouped by concern. A shortened version:

QUALITY
Every screen is designed for a phone first.
Every page loads in under 2 seconds on a mobile connection.

SAFETY AND PRIVACY
We never store card numbers.
Users can delete their account and data in one step.

MONEY
AI spending is limited per day, per month and per customer.
Anything that costs real money needs the founder's written OK first.

HOW WE WORK
No feature is built without a spec. When something changes, the spec changes first.
"Done" means checked on the live product.

The rule that matters most is the last section. It makes documents, not chats, the source of truth.

2. A one-page spec per feature

Before any code: a spec written from the user's side. The skeleton:

Summary          · what it is and why it matters
Who it's for     · the person and their situation
User stories     · As a [person], I want [x], so that [benefit]
Acceptance       · When [this happens], then [that happens]
Edge cases       · no internet / bad input / empty state / limit reached → behaviour
Out of scope     · what it deliberately doesn't do
Open questions   · NEEDS DECISION: anything not decided yet

The agent proposes the plan from this. "Out of scope" and "Open questions" do the most work: they stop the agent from inventing requirements, and they force decisions to be made by a person.

If you want tooling for this, GitHub's open-source Spec Kit gives you the constitution → specify → plan → tasks → implement flow as commands inside your AI tool.

3. One small PR per task

Plans get cut into tasks small enough to verify in minutes, and each meaningful change ships as a pull request with CI. As a non-developer, my review checklist was:

Does the change match the spec?

Do the checks pass?

Does it work when I use it like a customer?

Small PRs are what made that review possible. They also make every change reversible.

4. Every bug becomes a rule, then a test

This is the compounding part. When something broke, the workflow was:

Ask for causes before fixes.

Write the lesson down as a rule next to the feature's spec, where the agent reads it on every build.

For rules that must never break, add a test, so CI stops the build instead of relying on the agent remembering.

A rule in English protects you when the agent reads it. A rule as a test protects you even when it doesn't.

Example, as a pattern: a small bug looped and burned a day's AI budget. The lasting fix wasn't the loop. It was a spending limit on every AI call, plus a test that fails if anyone breaks it.

5. Four prompts

Plan before you build (every task, idea or bug):

[Describe the task.] What is your understanding, concisely, in bullets?
What is your implementation plan? After proposing the plan, stop and ask
for my approval.

Hand off a heavy session (long sessions degrade; fresh ones with a good handoff don't):

This session is getting context-heavy. Provide me the self-contained
prompt for a new session to implement [task] seamlessly: the goal, the
files to read, the decisions already made, what's done, what's next,
and the branch and pull request.

Fix the cause, not the symptom:

What I did: … What I expected: … What happened: … Where: … Every time?
Find the cause before changing anything: give me three possible causes
and how to test each one.

Turn other models' reviews into a plan. Ask two or three other assistants to review a plan honestly, then give Claude all of it:

Here's feedback from [other assistants]. For each suggestion, agree or
disagree and why, against our spec and constitution. Then turn what
survives into a prioritized action plan: now, next and later. Stop and
ask for my approval.

What changed

The early months were full of repeat bugs. Once the memory lived in the repo (constitution, specs, rules, tests), the later months weren't. The codebase got easier to change each week instead of harder.

I wrote the full method up for people who don't code, with the complete templates, three builds and a 30-day challenge:
Build Your AI Platform.

Chapter 1 is free on the page. There's also a shorter, beginner-friendly guide on the blog: How to Build an AI App Without Coding.

What guardrails have you added to your own AI-assisted projects? I'd like to learn what I'm missing.

DEV Community: Saygin Celen