Stop Building on Shifting Sand: Lock Your Object Model Before AI Touches It

You start a side project. AI is helping. It feels amazing — you're shipping in hours what used to take days. Then, somewhere around week two, things start to slip.

I was building a Twitter search tool. Nothing crazy — I wanted to stop doom-scrolling and start actually tracking what my friends and a few topics were doing. Lists, categories, alerts when something interesting happened. A small, personal tool.

The coding went great at first. Then I looked at my API layer one day and it was over 10,000 lines in a single file. As a human, I'd never write anything like that. Anything over 200 lines and I'd split it up — partly for sanity, partly because I had to type it and scrolling hurt.

But AI doesn't care about scrolling. It just keeps appending. And once a file gets that big, the AI starts forgetting what it already wrote. I had five duplicate functions doing the same data call. Fix one, and the other four silently kept doing the wrong thing. Every edit broke something else. I wasn't making the project better — I was just running in place, correcting yesterday's slop with today's slop.

Eventually the project got too big and too broken to enjoy working on, so I stopped. That's how these things die. Not from a single catastrophic bug — from the slow accumulation of sand where the foundation should be.

What We Learned

You need a rock-solid foundation. If you're going to build with AI — and you should, it's the most productive way to write software right now — you have to wrestle control back from it.

AI needs to operate in a relatively permissive mode to get real work done. That's fine. But permissive mode with no foundation is a recipe for the exact mess I just described. The answer isn't to slow the AI down. The answer is to put parts of your application off-limits entirely — to define a core that AI cannot touch, and then let it loose on everything built on top of that core.

Discipline first, speed second. Do it in that order and the speed compounds. Skip the discipline and the speed collapses on itself in about two weeks.

What You Can Do About It

Here's the concrete fix. Two files, locked down, human-only.

1. Write a plain-English definition file.

Before you write a single line of code, write a document that answers three questions: what problem are you solving, who are the users, and what are the core objects in the system. For each object, write a few paragraphs in plain English — what it is, what it's intended to do, how it relates to the rest of the system.

If you're building airline reservations, a Seat gets its own section. What it represents. What it knows about itself. What it relates to — a flight, a passenger, a fare class. Keep the whole document short enough that a person can read it in one sitting. Low cognitive load is the point. If it's bloated, nobody reads it — including you, six weeks from now.

2. Lock that definition file down.

This file is human-only. AI cannot edit it without your explicit approval. Configure your tooling — .cursorignore, Claude Code permission settings, whatever your stack uses — so writes to this file are blocked by default. This forces you to stop, read, and think before anything downstream changes. That pause is the whole value.

3. Derive the data model from the definition — object by object.

Now hand the definition to the AI and say: "design the data model for this." For each object, it produces a schema — fields, types, relationships. Seat becomes aisle_number: int, seat_letter: char, is_window: bool, flight_id: FK. You can let the AI draft this part, but you review every field. Every one.

4. Lock the data model down too.

Same rule. Human-only edits, or explicit approval required. Your core object model is now protected on both sides — the English description of what it is, and the SQL schema of how it's stored. AI can build routes, UI, tests, background jobs, whatever it wants on top of that foundation. It just can't quietly change the foundation itself.

5. Layer domain bots on top.

Once the core is locked, the next step is domain-specific bots that know the object model cold and enforce standards as AI writes code on top of it. I'll cover that in a follow-up — for now, just know that the locked foundation is what makes the bots actually work. Without it, they're enforcing rules against a moving target.

Two files. That's it. That's the whole discipline.

Why It Matters

Here's what changes when you do this.

Your object model becomes legible. You can scan two files and know exactly what your system is and what it knows. That's worth a lot on its own — most projects lose this clarity in the first month and never get it back.

You stop building on shifting sand. New objects don't silently appear. Duplicate functions don't proliferate across a 10,000-line file, because the AI is now working against a schema it can't edit and a definition it can't rewrite. It has to conform to the foundation instead of reinventing it every session.

The AI itself gets dramatically better. The written guidance in your definition file gives the model real context — not just the code, but the intent behind the code. It stops guessing at what a Seat is supposed to be and starts building against a clear specification. You'll feel the difference in the first hour.

And the biggest one: as the project grows, it doesn't turn to slop. This is the failure mode that kills AI-assisted projects, and locking the object model is the single most effective thing I've found to prevent it. You move faster as a developer. You ship code that's significantly better than the default AI baseline. And six months in, you still want to open the repo — which, honestly, is the whole game.

At Periscoped, we build on rock, not sand — disciplined foundations are how we help companies move fast with AI without watching their codebase collapse under its own weight.