I build most of my software with AI coding agents now. They write a lot of the code, draft tests, refactor, and research problems far faster than I could alone. They are one of the main reasons I can take a product from idea to a working v1 in weeks.

They are also fast enough to do real damage if nobody sets limits. So every product I build has a written constitution: a short set of rules the agents work under, written down in the repository where they can read it, and enforced by how the project is set up rather than by hope.

Here are the rules, and why each one exists.

Rule one: no production data

Coding agents never touch production data. They work against seed data and demo workspaces, never against real customer records.

This is not about distrusting the models. It is about blast radius. An agent that misreads an instruction in a demo environment wastes an hour. The same mistake against real records can leak someone's data or delete it. With 50+ security certifications behind me, I treat this one as non-negotiable.

It also forces good habits. If a product can only be tested against production data, the seed data is not good enough, and that is worth fixing anyway.

Rule two: every change goes through a preview first

Nothing an agent writes goes straight to production. Every change is deployed to a preview first, where a person looks at it on a real screen before anything is released.

Previews catch the problems that code review misses: a layout that breaks at one screen size, a flow that technically works but feels wrong, a label that does not make sense. The agent cannot see those. A person can.

This rule is also why I built BlastRocket. When agents can change dozens of screens in an afternoon, the bottleneck moves from writing code to understanding what the code changed from a user's point of view. BlastRocket captures before-and-after evidence across routes, states, roles and screen sizes, so the person approving a release can see every change instead of guessing.

Rule three: public claims need evidence

If something is going to be stated publicly, on a marketing page, in a case study or in a report, it needs evidence behind it. Agents are very good at writing confident sentences. They are not good at knowing whether those sentences are true.

So a number on a page has to trace to a source, a feature described on a site has to exist in the product, and "status" is never dressed up as a metric. On my own case studies, each figure carries a note saying whether it is a design rule, an architecture fact or a status.

Rule four: AI does the heavy lifting, people make the calls

This is the principle underneath the others. The models do the heavy lifting: research, first drafts, code, tests, summaries. People make the decisions: what gets built, what ships, and when it is good enough.

In practice that shows up in the products themselves, not just in how I build them.

In Mentor Intelligence, AI runs server-side and only for staff and admins. It extracts a founder's needs from a pitch video or document and shows them for editing. The in-app assistant acts as the signed-in staff member, and only after they confirm the listed steps. The model never writes to the database on its own. It costs a few more clicks per task, and in return every change traces to a person, which is what a program director needs to be able to say.

In BlastRocket, AI groups related changes, writes the launch briefing and drafts fix briefs for coding agents, showing its rationale, confidence and model. It never approves, merges or deploys. Likely noise is never approved automatically.

The models do the heavy lifting. People make the calls.

Picking the model per task

I do not have a favorite model. I work with the latest models from Anthropic, OpenAI and Google, inside Cursor and Claude Code, and pick the model for each task.

Some are better at careful refactoring across a large codebase. Some are better at research and long documents. Some are faster and cheaper for small, well-defined changes. Picking per task is part of the job, the same way picking the right library is.

What does not change from model to model is the constitution. The rules apply to every agent, whichever lab built it.

Why write it down

You could argue that an experienced engineer just knows these things. Maybe. But agents do not, and neither does the next person who joins the project.

Writing the rules down does three things:

  • The agents can read them. Rules in the repository become part of the context every agent works with.
  • The team can check them. "Did this change go through a preview?" has a yes or no answer.
  • The client can trust them. When I hand over a codebase, the rules come with it, so the team knows how it was built and can keep building the same way.

The trade-off

These rules make me a little slower than someone letting agents push straight to production. I think that is the right trade. Speed you cannot trust is not speed. It is risk you have not discovered yet.

If you are building with AI coding agents and do not yet have rules like these written down, email me. Setting up the workflow, the previews and the guardrails in your repository is one of the most useful things I do with existing teams.