Building Standards for Human–AI Development Teams

The following is an excerpt from the book Vibe Coding: Building Production-Grade Software With GenAI, Chat, Agents, and Beyond by Gene Kim and Steve Yegge.

In this chapter, we’ll discuss a challenge that emerges after vibe coding moves from an intriguing solo activity to a full-team endeavor: Ensuring everyone—human and AI—can work using the same high standards, using a shared recipe book.

Consistency doesn’t happen by accident. We’ll help you define clear, actionable rules for your AI helpers to follow and keep these standards manageable enough that everyone in your kitchen uses them. We’ll introduce you to a tiered approach—organization-wide guidelines, team conventions, and project-specific best practices—that mirrors how culinary pros keep their crews aligned, efficient, and consistent.

Through examples ranging from Google’s legendary internal coding practices to the disciplined process of “standard work” at Toyota, you’ll learn how to create living documentation that captures the wisdom and discoveries your team uncovers day-to-day. We’ll talk about how and why we need to invest in writing great guidelines, both for humans and AIs.

By the conclusion of this chapter, you’ll have a practical blueprint for building your own collaborative cookbook—one that ensures any AI chef stepping into your kitchen knows where things live, what approach is expected, and how to sidestep common problems. More importantly, you’ll be ready to embed a culture of continuous improvement. You’ll be able to empower everyone in your vibe coding team to learn, share, and collaboratively elevate recipes, standards, and techniques across all your projects.

The Collaborative Cookbook: Building Shared AI Rules and Standards

If you want constant improvement from your team, you need to define what “great” means in your kitchen. First, you need a clear set of long-standing, general kitchen rules that everyone follows. For instance, always use temperature testers on chicken, always wash hands when moving between stations. This has to be a well-curated list, since it should be thorough, but if it’s too long nobody will be able to follow it all.

Conscientious organizations set foundational engineering standards—things like always sanitizing user inputs, never committing secrets to repositories, ensuring all database queries are parameterized. In Part 3, we discussed the challenge of how to make the list comprehensive yet concise enough that both humans and AI can follow it.

You also need living documentation that captures your current development context—which APIs you’re using, what architectural patterns you’ve adopted, how you’re structuring your components. Think of these as your project standards. When a developer discovers that wrapping API calls in a retry pattern eliminates 90% of transient failures, that becomes part of your shared knowledge. Or a prompt that is unusually effective at getting AI to run tests after each small change. In the Toyota Production System, they call this “standard work”—the current best way to perform a task, refined through experience. This guidance becomes the mechanism to share local discoveries and greatness everywhere.

This is one of the benefits of Google’s monolithic internal shared code repository, in which most of their developers work. Whenever a developer wonders how to use a certain library, they merely need to search the repository for how others have used it and copy/paste that usage example into their code.

In a vibe-coding kitchen, your prompts, global rules and AGENTS.md files, and/or shared memory can all play this role. Now everyone can tap into the wisdom of veteran vibe coders who’ve found great tips and approaches. Instead of stumbling through trial‑and‑error, you stand on their shoulders from day one.

Only a few rules will be of the true set‑and‑forget variety. As your project progresses, rules drift and get out of date. A guideline here becomes obsolete; a new best practice emerges there. We suggest carving out time—and we mean setting aside a significant portion of your time every day—to curate your prompt and rules files, Markdown plans, and other daily context for your agents. 

Let AI help with this. Feed it your current Markdown or database, ask for a leaner, up‑to‑date version, and then do a final pass to prune any extraneous content. This housekeeping keeps your static context razor‑sharp and token‑efficient.

These rules live in a hierarchy that matches your organization. Your organization‑wide rules sit at the foundation (e.g., never introduce security vulnerabilities, always run static analysis, run tests before commits). On top of that are team‑level conventions (e.g., naming schemes, test frameworks). Finally, you’ll have project‑specific prompts (e.g., use Vitest for unit tests, indent with tabs in build scripts).

These rules help onboard every AI and team member working on your project. Your AI assistant knows where to find things, and team members get better results using agents and chat assistants. And when a developer discovers a new trick, they integrate it into the rules. These rules files can help with onboarding new human team members as well; a new teammate can scan through the rules files to figure out how their new team uses AI.

We recommend storing these rules in your repo as Markdown files under a clear directory structure (say, /ai‑rules/org, /ai‑rules/team, /ai‑rules/project). In your kitchen, you want everyone using the same equipment. Individual configurations might feel cozy, but they fragment your kitchen. When everything is in version control, everyone can start cooking from the same cookbook.

Mind-Melds and AI Sous Chefs: Reducing Coordination Costs

In software development, imagine if you could collapse your software organization into a single person who could handle front-end, back-end, database design, and deployment as needed. No more waiting for the back-end engineer to finish their API, waiting for the database engineer to approve your stored procedure change, no more miscommunication about GraphQL schemas…It’s not too difficult to imagine scenarios where you could deliver certain tasks faster.

Why does this speed things up? Two invisible taxes vanish: connection setup time (between people) and bandwidth mismatch. Whenever you connect with a new Wi-Fi network, you sometimes have to wait seconds (or minutes, if you don’t have the password) to connect. Your Wi-Fi adapter has to talk with the base station to negotiate a frequency and protocol. Humans have to do the same thing: we greet, align vocabulary, clarify goals, and only then start transmitting real information, decide whether we trust each other, etc. 

Vibe coding can drastically upgrade the connection—turning your respective thoughts into shared understanding and goals, and maybe even code, in record time.

In the past, to help with the process, we’ve had large, static, slow-moving shared artifacts to make coordination easier. We had the product requirements documents (PRD) to help product owners communicate with developers. We had test plans to help developers talk with QA staff. 

These all now feel bloated and inadequate. A product owner can now ask the repo itself, via AI, “Show me where you calculate monthly churn and add an experiment flag.” The resulting prototype is the new PRD, executable and inspectable by everyone, including finance and design, because natural‑language queries replaced tribal jargon.

As we mentioned in Part 1, economist Dr. Daniel Rock from The Wharton School calls this phenomenon “the Drift,” from the movie Pacific Rim. “The Drift” is a technology connecting two pilots by melding minds to jointly pilot a Jaeger, a gargantuan mech for fighting “Kaiju monsters,” which requires superhuman concentration to operate.

One Tuesday morning, Dr. Rock stumbled onto the concept of GitHub Apps through a Google search and opened a blank Markdown document. He added his goal and gave it to the Claude chatbot, telling it, “Ask me whatever you need to draft a real spec.” Eight probing questions later, the outline sprang to life. By Wednesday his chief-of-staff, a designer by training, was in the same document sketching UI flows, while Claude kept tightening the spec with every answer they typed.

On Thursday morning, his senior developer joined “the Drift.” He pulled the evolving text into Cursor, started building automated tests, logging, and the scaffolding needed to plug it in. No part of the spec was “handed off” to someone else. Ideas, code, and clarifications appeared in the document the instant someone thought of them.

They had created shared goals and mental models. Instead of the typical slow process where you throw specs over a wall and wait anxiously for developers to get something wrong, they were all collaborating directly, prompting and nudging AI together. The Markdown file became a living cockpit—part chat log, part design doc, part code review transcript.

Forty-eight hours after Rock’s first Google search, they had a working GitHub App that reliably extracted customer repository data. No one had “waited for the developer” because all three were writing prompts, code, and tests in real time—effectively tripling the developer capacity of the team. It was FAAFO: fast (completing in two days what otherwise would have taken weeks), ambitious (they built something with unfamiliar technology), functionally autonomous (three people working as a coherent team), fun (it felt like play), and creating optionality (every time Claude suggested yet another improvement or alternative approach).

The urge to work solo or more autonomously is driven by simple economics. Robotic surgery shows us the pattern. As we mentioned earlier in the book, Dr. Matt Beane’s studies showed that once surgical robots let senior surgeons operate without juniors, the apprenticeship model evaporated. Experts chose independence because every additional human introduced friction (and hospitals chose it because juniors took 10x longer to complete procedures and had more accidents).

Software follows the same curve: As soon as AI makes full‑stack competence feasible, waiting for the “CSS person” would feel like tying an anvil around everyone’s feet. This phenomenon also puts ever more responsibility on leaders to make sure there is a path for junior developers to become senior developers.

Dr. Daniel Rock shared with us a historical parallel of what AI is enabling right now similar to “the Drift”: when factories moved from mechanical drive shafts to electrified power. Before electrification, every machine had to be positioned along a single rotating shaft, coupling every work center to that driveshaft. Electrification decoupled that dependency: Now any machine could go anywhere, driven by wires instead of gears.¹ It was a Layer 2 innovation that unlocked radical new Layer 3 layouts—more autonomous teams, more flexible processes, more innovation. 

In the same way, vibe coding is our electrification moment. It decouples work from the rigid dependency chains that once dictated handoffs between front end and back end, product and engineering, design and QA. 

Autonomous doesn’t mean isolated. It means unblocked—free to be fast, to chase ambitious ideas, and to cultivate fun without negotiating every step. And let optionality bloom.

For more insights on effective AI-assisted development, check out Kim and Yegge’s new book Vibe Coding and their podcast Vibe Coding with Steve and Gene on YouTube.

- About The Authors

Gene Kim

Gene Kim has been studying high-performing technology organizations since 1999. He was the founder and CTO of Tripwire, Inc., an enterprise security software company, where he served for 13 years. His books have sold over 1 million copies—he is the WSJ bestselling author of Wiring the Winning Organization, The Unicorn Project, and co-author of The Phoenix Project, The DevOps Handbook, and the Shingo Publication Award-winning Accelerate. Since 2014, he has been the organizer of DevOps Enterprise Summit (now Enterprise Technology Leadership Summit), studying the technology transformations of large, complex organizations.

Follow Gene on Social Media

• 
• 

Steve Yegge

Steve Yegge is an American computer programmer and blogger known for writing about programming languages, productivity, and software culture for two decades. He has spent over thirty years in the industry, split evenly between dev and leadership roles, including nineteen years combined at Google and Amazon. Steve has written over a million lines of production code in a dozen languages, has helped build and launch many large production systems at big tech companies, has led multiple teams of up to 150 people, and has spent much of his career relentlessly focused on making himself and other developers faster and better. He is currently an Engineer at Sourcegraph working on AI coding assistants.

Follow Steve on Social Media

•