The Problem

Part I: Foundation · Chapter 1

8 min read

A senior engineer opens their AI coding assistant and types: "Add user authentication to the app." Thirty seconds later, they have 400 lines of code. It uses Passport.js — but the team standardized on Auth0. It stores sessions in Redis — but the project uses PostgreSQL for everything. It creates a new middleware pattern — but the codebase already has one. The code works. It's also wrong in every way that matters to the team that has to maintain it.

The Power Without Direction

AI coding assistants are the most significant productivity tool software engineering has seen in decades. They can generate working code in seconds, refactor entire modules, write comprehensive test suites, and explain complex systems with clarity. The capability is real.

The problem is not capability. The problem is direction.

Without structure, AI coding assistants operate in a vacuum. They have no knowledge of your team's architectural decisions, no awareness of your project's conventions, no understanding of why certain patterns exist in your codebase. They fill this void with assumptions — reasonable assumptions, drawn from training data, but assumptions nonetheless.

The Vibe Coding Problem

There's a seductive workflow that emerges when AI coding tools are fast enough: describe what you want in natural language, accept whatever comes back, fix the obvious errors, ship it. This is sometimes called "vibe coding" — you vibe with the AI, it vibes with your prompt, and hopefully the output vibes with your codebase.

For prototypes and throwaway scripts, this works fine. For production software maintained by a team, it introduces a specific class of problems that compound over time:

• Assumptions multiply silently — Each AI interaction makes dozens of micro-decisions: which pattern to use, how to name variables, where to put files, what error handling strategy to follow. Without explicit constraints, these decisions are arbitrary. Across a hundred interactions, you get a hundred different implicit design philosophies embedded in your codebase.
• Context gets lost between sessions — Your chat history is not your project's memory. Close the window, and every decision, every clarification, every "actually, we do it this way" disappears. The next session starts from zero.
• Code doesn't match architecture — The AI doesn't know about your team's module boundaries, your data flow conventions, or your dependency rules. It generates code that works in isolation but violates the structural integrity of the system.
• No accountability trail — When something breaks in production, there's no document that says "we decided to do X because of Y." There's just code that appeared in a commit, generated by a conversation no one can search.

Real-World Failure Modes

These are not hypothetical scenarios. They are patterns that teams encounter repeatedly when using AI coding tools without structure:

Wrong Framework, Right Code

The AI generates a perfectly functional authentication system using JWT with local storage. The code is clean, well-tested, and handles edge cases. But the team uses HTTP-only cookies with server-side sessions because of a security audit six months ago. The AI had no way to know this. The entire implementation must be discarded.

Convention Violations

The project follows a repository pattern for data access. The AI generates a new feature that queries the database directly from the controller. The code works, passes the tests the AI also wrote, and gets merged. Three months later, when the team needs to add caching at the repository layer, this feature doesn't benefit because it bypassed the layer entirely. Now someone has to refactor it.

Security Vulnerabilities

The AI generates an admin endpoint without the authorization middleware that every other admin endpoint uses. Or it adds a file upload handler without the size limits and content-type validation that the team's security guardrails require. The AI doesn't know these guardrails exist because they're institutional knowledge, not code.

Untestable Architecture

The AI creates a feature that works but tightly couples business logic to the HTTP layer, makes direct database calls from utility functions, or introduces global state. The feature passes its own tests because the AI wrote the tests to match the implementation. But it's impossible to unit test in isolation, and it makes the surrounding code harder to test too.

The Cost

The cost of undirected AI coding is not immediately visible. The code works. The tests pass. The feature ships. The cost arrives later:

• Rework — Code that doesn't match architecture must be rewritten. The time saved by AI generation is consumed by human refactoring.
• Technical debt — Inconsistent patterns accumulate. Each one is small. Together, they make the codebase harder to understand, harder to modify, and harder to onboard new developers onto.
• Team friction — Code reviews become adversarial. "Why did you use this pattern?" "The AI suggested it." "But we don't do it that way." This conversation repeats across every PR that was AI-generated without context.
• Production incidents — Security vulnerabilities, missing error handling, violated invariants — these surface in production, not in development. The AI didn't know about the invariant. The developer trusted the AI. The system broke.

The Chat Problem

Traditional AI chat interfaces have fundamental limitations that make them unsuitable as a development methodology:

• Context windows fill up — Long conversations exhaust token limits. The AI loses early context, including the most important architectural decisions made at the start of the session.
• Hallucination scales with context — More tokens in the window means more potential for confusion. The AI conflates instructions from turn 3 with corrections from turn 47.
• No persistent memory — Close the chat, lose the context. Every session starts from scratch.
• Unsearchable history — "Where did we discuss the caching strategy?" Good luck finding it in a chat log.
• No team visibility — Your conversation with the AI is invisible to your colleagues. Decisions made in chat can't be reviewed, approved, or challenged.
• Repeated context loading — Every session begins by re-explaining the project. This wastes tokens and introduces inconsistency as you describe the same system differently each time.

The Gap

Here is the core observation: human development teams have natural constraint systems that AI lacks.

When a human developer joins a team, they go through onboarding. They learn the architecture, the conventions, the patterns. They attend design reviews. They read architecture decision records. They get feedback in code reviews that shapes their understanding of "how we do things here." Over weeks and months, they internalize the constraint system that makes their code consistent with the team's.

AI has none of this. Every interaction is its first day on the job. It has the skills of a senior engineer but the context of someone who just walked in the door.

The Solution Space

The instinctive response is "write better prompts." Add more detail to your instructions. Paste in your coding standards. Remind the AI about your conventions. This helps — but it doesn't solve the problem, for three reasons:

1. Prompts are ephemeral — They exist in chat sessions that disappear. The same prompt must be re-written, re-remembered, re-applied every time.
2. Prompts don't scale — A team of ten developers will write ten different versions of "use our conventions." Consistency requires a shared artifact, not individual prompts.
3. Prompts are verbal, not structural — Telling an AI "follow the repository pattern" is weaker than giving it a document that defines every module, its boundaries, and its interaction contracts. Structure constrains behavior more reliably than instructions.

What if, instead of telling AI what to do in natural language, you gave it the same structural constraints that make human developers effective? Architecture documents. Specifications. Phased plans with verification steps. Explicit acceptance criteria. A persistent, versioned, reviewable context that survives across sessions and team members.

That is what Draft provides. The next chapter explains how.