AI Did Not Remove Engineering Failure

Last December, I was building my first real idea, a Chrome extension called FlyAI, with ChatGPT in one window and VS Code in the other.

It was slow. The code mostly worked, but the work kept drifting. One answer was out of date. The next contradicted a decision made ten messages earlier. Then the chat reached its limit, locked, and took the thread with it.

The failure that finally stopped me was smaller and more revealing. I would ask for one thing. ChatGPT would do it, then ask what else it could build.

I did not want more surface. I wanted the one thing, done, in bounds.

I found Cursor by accident. It was faster, but it was structured in a way I did not yet trust.

More speed, same drift, just quicker.

When I began my next build, RangeSight, I tried strict prompts, tighter rules, and explicit boundaries on every change. It still drifted away from the objective.

That was the moment it clicked. This was not only a prompting problem. It was a scope problem.

I was deep in my Project Management master's program at USC, so I applied what project management teaches about roles, scope, control, verification, and acceptance to the way I build with AI.

The result is BMIT: Blast, Mid, Inner, Test.

BMIT is not a prompt trick. It is an execution decomposition method. Each layer can build, but each has a different objective, boundary, and reason to reject work.

The public method pack is on GitHub as BMIT 1.0.0: prompts for Blast, Mid, Inner, and T1–T3, plus the handoff rules so one layer can name a problem without stealing another layer’s fix. Clone it, point an agent at AGENTS.md, and run the loop:github.com/rlshaw-ml/BMIT/releases/tag.

The goal is not to make AI slower. The goal is to keep speed from hiding drift.

AI compresses the distance between an idea and an executable result. It does not automatically improve the objective, the requirements, the architecture, or the assumptions beneath the code.

A fast agent can still:

A single instruction such as "build, test, and fix this" asks one working context to construct the system, judge its own design, repair its own assumptions, and decide whether the result is good enough.

That is the AI version of asking one person to pour the foundation, wire the building, furnish the rooms, and certify the inspection without ever changing roles.

Speed is a capability. Control is an architecture.

Before Blast begins, the work receives a context lock: the objective, permitted scope, hard constraints, known failure modes, success criteria, and required output.

The context lock is not a fifth BMIT stage. It is the boundary every stage must honor.

Blast is the foundation and structure. It creates the runnable baseline, defines the edges, and establishes the basic path through the system.

Mid is the infrastructure. It handles the wiring, plumbing, framing, connections, data flow, system boundaries, and load paths inside the walls.

Inner is the interior. It is the part people actually live in: the interactions, failure handling, guardrails, and precise behavior.

Test is what happens when people finally move into the building. It inspects the bones, turns everything on, and deliberately looks for weak points.

Each layer is allowed to program inside its scope. None is allowed to silently absorb the authority of another.

Test is not one ceremonial step at the end. It is an ordered routing system.

T1 is Structural. Check the bones, boundaries, placement, and flow. A structural failure returns to Blast, Mid, or Inner, whichever owns the cause.

T2 is Function. Turn everything on. Prove that the routes, services, configuration, infrastructure, and integrations actually work. A bounded functional failure can be corrected locally and verified.

T3 is Adversarial. Push on the railings. Force edge conditions. Attack assumptions. Look for incorrect outputs that still appear credible. Every finding is classified as structural or functional.

The order is strict: T1, then T2, then T3.

Every correction resets the sequence to T1. A repair can change the structure around it, so an earlier pass cannot be inherited as permanent truth.

That repeated reset is the improvement mechanism. The passing frontier advances only when each correction survives every earlier test again.

Patch is the return path. It is not a fifth BMIT layer.

The practical control is not simply four headings inside one large prompt. Each objective needs its own working space and a clear owner.

One space builds the foundation and only the foundation. Another handles the infrastructure. Another handles the interior. Another does nothing but try to break the result.

For a small build, one person can occupy all four seats sequentially. The separation still matters. You move through the roles in order and do not allow the Inner workspace to make an unreviewed Blast decision.

Separate owners become useful when one head can no longer watch the foundation and hang the pictures at the same time.

The roles are not bureaucracy. They are how the objective stays clean.

Consider a simple authentication feature.

Blast creates the form, route, session path, and runnable baseline.

Mid verifies that identity, authorization, storage, and error boundaries are placed correctly.

Inner handles expired tokens, duplicate submission, missing state, recovery, and believable but incorrect results.

Test checks the structure, proves the function, and then tries replay, malformed input, race conditions, and misuse.

If the browser is trusted with a decision that belongs on the server, a local patch is not enough. That is a structural failure. It returns upstream.

The sequence prevents a common AI failure: fixing whatever broke most recently while leaving the original architectural mistake untouched.

Verdict: incomplete.

Clearer instructions help. Persistent project rules, repository guidance, plans, tests, and scoped context also help. Current coding systems increasingly support all of them.

But a detailed prompt can still collapse several kinds of authority into one conversation. More instructions do not automatically create independent objectives, ownership boundaries, failure classification, or a reliable return path.

BMIT adds that operating sequence: lock the objective, separate the work, assign each layer authority, test in order, classify failure, and send the correction to the highest layer capable of addressing the cause.

The prompt tells the system what you want. The operating method determines whether it stays true while building it.

Group these however your stack is shaped, but do not skip any of them:

1. Lock before you build. If the objective can move without being noticed, every later test is measuring the wrong system.

2. Separate the layers. Foundation, infrastructure, interior, and inspection are different objectives, even when one person performs all four.

3. Give correction to the owner. Test can identify structural weakness without having the authority or context to redesign the structure correctly.

4. Preserve the order. T1 must pass before T2. T2 must pass before T3. A later test cannot compensate for an earlier failure.

5. Reset after every correction. A fix changes the system. Earlier passes expire until the corrected system survives them again.

6. Release only on a clean sequence. Working once is not the same as being controlled. Release requires one uninterrupted T1, T2, T3 pass.