How we build with AI, and where we draw the lines

• We use AI to help our engineers write and review code faster. A person plans every change, a person reviews it, and a second person reviews it again before it reaches you.
• We keep AI away from your live site. We run it in isolated development environments. It doesn’t publish content, edit your homepage, or deploy code. We push its output through the same pull request, review, and release process we’ve always used.
• We keep your data out of anyone’s training set. We only use paid, business-tier AI tools that Four Kitchens manages, and we configure them so our work isn’t stored for training or analytics.
• We’re adding more automation, mostly in testing and routine maintenance, and we’ll tell you before anything changes on your project.

That’s the whole picture. The rest is detail for anyone who wants it…

When I think about where AI earns its place in our workflow, it comes down to three things.

Speed where speed is cheap. Researching a new topic, sketching a technical plan, tracing a bug through logs, writing boilerplate, and writing tests. This is where we’ve seen the biggest gains, and it’s where a mistake is easy to catch and cheap to fix.

Judgment where judgment matters. Deciding what to build, how it should behave, whether it’s ready. We don’t hand these to a tool. Every plan is approved by a project lead before we execute it, and every result is reviewed by two engineers before you see it.

More “eyes” on every change, not fewer. We’ve added AI analysis to our peer review process alongside the human reviewer, not instead of them. In practice, a reviewer with an AI analysis beside them catches more than a reviewer alone.

• Specifications and technical plans. We use AI to draft; our team (including you) decides.
• Pair programming. An engineer builds a detailed plan with AI, signs off on it, then directs the AI to carry it out under supervision.
• Code review. A second engineer reviews every change, running their own AI analysis alongside.
• Debugging. We use it to trace bugs and analyze logs faster.
• Notes, research, and drafting. Meeting notetakers, summarizing documentation, exploring options.

Nothing reaches you that fewer than two people have examined. While we use AI in all of these steps, the final decision about whether a new feature is ready rests with humans, just as it always has.

Company policy. Our Responsible AI Use Policy has been public since summer 2024. That might sound like eons ago in AI time, but it still stands up because it’s based on overarching principles rather than specific tactics. It governs which tools we use, how we configure them, what we disclose, and what we refuse to do. The principle underneath all of it: accountability cannot be outsourced to a machine.

Platform rules. We’ve built those policies into the tooling itself, so they apply to every engineer on every project, not just the ones who remember.

Per-codebase rules. Each project repository carries its own AI instruction file with dozens of specific guardrails: things we never permit the AI to do (like discard or overwrite a database) and steps we reserve for people (like testing a single-sign-on login system). If you see a file named AGENTS.md in your codebase, that’s what it is.

The bottleneck in web work has moved. We can build faster than we can test and review, and the answer isn’t more people doing rote checks. So the next wave of automation targets exactly that:

• More automated test coverage
• Visual regression testing that flags unintended changes to how pages look
• Routine maintenance updates drafted with AI, reviewed by people
• Automated accessibility checks
• AI-driven browser testing of new features before human review

Each of these still ends with a person deciding. Si wrote recently about how faster implementation frees up the budget for strategy. That is key. The teams that use that freed-up time for strategy are the ones who will pull ahead. This is the other half of that: It also frees our people for the parts of the job that require them.

But we won’t stop there. We’ll continue to look for the parts of the job that don’t need a person’s judgment, hand those to automation, and put the time we get back into the parts that do.

If you have questions about how any of this applies to your project, ask your project lead, or start a new conversation. I’m really excited about how, if we move forward with the right guardrails, and accompanying strategy, we can be far more effective than ever before.