AI Code Consistency:One Pattern, 633 Services
AI code consistency comes from boring repetition: one 305-line master pattern became 633 identical AI-built services. Not clever prompting. Here is how.
AI code consistency comes from building one master pattern and making AI copy it — never letting it invent a new approach twice. One real platform proved it at scale: 633 services, every single one an identical copy of a single 305-line foundation, every single one built by AI. Repetition, not novelty, is the superpower.
If you are non-technical, this might be the most counterintuitive lesson in AI-assisted building. We are trained to think creativity is the valuable part. In software, the opposite is true: the most valuable codebases are the most boring ones. Here is the story, with the concepts lifted above the code.
The mistake that almost happened
January 2025. The database for FIKR Space is designed — 964 tables, multi-tenant from day one. Now it needs services. Lots of services.
AI builds the first one. It works. Great. AI builds the second one — and it uses a different pattern. Different error handling, different way of querying the database. The third service? Yet another pattern.
Full stop. Because the math of that trajectory is brutal: keep going like this and 100 services in, you have 100 different patterns. Every bug gets fixed 100 different ways. Refactoring becomes impossible. Consistency becomes a dream.
This is not AI misbehaving. Ask AI to build something from scratch and it will generate a perfectly reasonable, internet-average solution — a different perfectly reasonable solution every time. AI is a brilliant improviser, and improvisation is exactly what a codebase cannot survive. Left unmanaged, this is how you drift into the vibe coding trap.
What a service actually is (no code required)
A quick translation for non-technical readers. A service is the layer between your database and your screens. When a user clicks “save,” a service checks that they are allowed to, writes the data to the right place, records who did it, and reports back — success or a helpful error.
If the database is your product’s foundation and the screens are its face, services are the nervous system: every signal passes through them. Each feature of your product needs one — which is how a serious platform ends up needing hundreds. And every service must answer the same five questions: Is this user allowed to do this? Which customer’s data is this? What happens when something fails? Should this action be logged? Is the input safe?
Five questions, hundreds of services. That repetition is either your biggest risk or your biggest asset — depending on one decision.
AI code consistency: the master-pattern move
The decision: stop building services and build the pattern first. One foundation — 305 lines of code — that answers all five questions once. Error handling. Multi-tenancy filtering, so each customer only ever sees their own data. Permission checking. Audit logging. Input sanitisation. Every hard-won answer, encoded a single time.
Then, one rule written into every feature blueprint handed to AI: every service extends the foundation. No exceptions. (Those blueprints are PRPs — the mechanics are in the PRP method.)
From that moment, AI stopped improvising and started replicating. Ask for a new service and it copies the proven skeleton, fills in the specifics, and inherits every safety property for free. The first service took about 2 hours — the time to build the foundation properly. Each of the next 632 took 15–30 minutes. Across the platform, that is roughly 800 hours saved versus building each one from scratch.
The bookThe Solopreneur RevolutionLuis Gonçalves on building a solopreneur business with AI while employed.Get the book →One change, 633 updates
The compounding payoff arrives later. When audit logging was added to the foundation, all 633 services got it — instantly. When error messages were sanitised for security, all 633 services got it. When query handling improved, all 633 services got it. One change, 633 updates, zero manual edits.
That suggests a simple test for whether your architecture is working. Call it the scale test: if you can add a capability to your foundation and every service inherits it immediately, you have succeeded. If you would have to update 633 files by hand, you have failed. The test works just as well at 6 services as at 633 — the only difference is how much it hurts to discover the answer late.
Why repetition is the superpower
The numbers behind the boring-is-beautiful argument:
| Metric | Number |
|---|---|
| Services built on one pattern | 633 |
| Database tables they sit on | 964 |
| Categories they organise into | 47 |
| Size of the master foundation | 305 lines |
| Smallest service / largest service | 87 lines / 2,214 lines |
| First service vs each one after | 2 hours vs 15–30 minutes |
| Consistency across all 633 | 100% |
Look at that smallest/largest row. The simplest service is 87 lines; the most complex handles an entire investment-deal workflow across 2,214 lines. Wildly different jobs — identical skeleton. Complexity varies; the pattern never does.
Here is the concept to take away: AI is a perfect replicator. Whatever you hand it as a reference, it will reproduce faithfully and tirelessly — which means the leverage is entirely in what you make worth replicating. Get one pattern right, once, and AI will stamp it out hundreds of times without fatigue, ego, or shortcuts. Get nothing right first, and AI will happily replicate chaos instead. The same logic drives production prompt anatomy: point AI at your best existing work and let it copy.
Creativity belongs in your product, your positioning, your offer. Your codebase should be the least creative thing you own.
12 weeksYour corporate career was never the planApply to the Solopreneur Accelerator.Apply now →Frequently asked questions
What is a service layer, in plain English?
It is the middle layer of your product: the code that sits between the database (where data lives) and the interface (what users see). Every meaningful action — saving, fetching, deleting, checking permissions — flows through a service. That is why consistency there matters more than anywhere else.
Do I need 633 services?
No — that number reflects a large multi-product platform. But the principle applies from your fifth service onward. The trap of a-different-pattern-every-time starts on service two, and the cost of fixing inconsistency grows with every service you add. Build the foundation before you build the crowd.
How do I make AI follow my pattern every time?
Two moves. First, create the foundation as a real file in your product, not as an idea in your head. Second, reference it explicitly in every feature blueprint with a no-exceptions rule. AI follows examples far better than descriptions — the mechanics of pointing AI at reference files are covered in production prompt anatomy.
What happens if I skip the master pattern?
Ten services in, you will have ten different patterns: ten error-handling styles, ten security approaches, ten ways of talking to the database. Every fix must be rediscovered per service, and a proper cleanup eventually means rewriting most of your product. It is the structural version of the vibe coding trap — fast progress now, paid for with interest later.
How trapped are you, really?
Take the Corporate Suffocation Index, the free solopreneur readiness assessment.