Human-Directed vs AI-Directed Software Development

Two Operating Models

"AI-assisted development" is an umbrella term, and it hides two very different ways of working. The distinction is not how much code the model writes — in both models it can write most of it. The distinction is who decides, and who is accountable.

AI-directed development starts with the model. You describe the product in a prompt, ask it to pick a structure, and let it generate whatever it thinks the system should look like. Architecture emerges from the model's output rather than from a decision a person made. The feedback loop is fast, the first demo can be impressive, and the moment a second feature arrives you discover that nothing is consistent because nothing was ever decided.

Human-directed development starts with a person. A human owns the architecture, the specification, and the review. The AI executes inside boundaries the human set: a declared entity model, a fixed file structure, a rules file, and reference implementations to imitate. The model still does the bulk of the typing, but every artifact it produces has an owner who is answerable for it.

Neither model is about how capable the model is. Both use the same models. They differ in where the responsibility sits.

What AI-Directed Gets Wrong

The failure mode of AI-directed development is not that the code does not compile. Modern models produce code that runs. The failure mode is that the code is unjustifiable, and the cost shows up later.

• Undefined architecture. When you never declare how features are organized, the model improvises a different structure for each one. There is no consistent place to find a handler, no naming convention to follow, and no way to predict where the next feature will land.
• Silent assumptions. The model fills every gap in your prompt with a plausible guess. It assumes a status field is a string, that deletion is physical, that a lookup is optional. None of these assumptions is written down, so none of them can be reviewed or corrected until they cause a bug.
• No acceptance criteria. If the requirement is "add asset management," there is no definition of done. You cannot tell whether the output is complete because you never said what complete means.
• Unreviewable diffs. A change that touches forty files with no stated conventions is not reviewable by a person. It is either accepted on faith or rejected wholesale, and neither outcome is engineering.

These problems compound. The first feature seems fine because there is nothing to compare it to. The second feature uses a slightly different shape. By the fifth, the codebase contains five interpretations of the same idea, and the model — which learns from whatever it can see — faithfully imitates the inconsistency. That is the hidden cost of AI-directed development: it does not merely produce inconsistent code, it reproduces that inconsistency in everything generated afterward.

The common thread is the absence of a contract. AI-directed development replaces a contract with a conversation, and conversations do not leave the internals auditable.

What Human-Directed Gets Right

Human-directed development keeps the human in the two roles that matter most and delegates the rest. The human decides what is being built and how it is structured; the model decides the mechanical details of writing it.

In practice that means a person writes the data dictionary that defines the application, approves the feature requirements derived from it, and reviews the diff before it is merged. The AI generates the eighteen-plus files that a single entity implies — controller, handlers, endpoints, views, collocated JavaScript — and the human checks that the result matches the declaration. The division of labor is explicit, and so is the accountability.

An example makes the difference concrete. Ask an AI-directed agent to build asset tracking and you will get something that compiles: tables, forms, and routes chosen by the model. A human-directed team building the same thing produces a written decision first — the entities (Asset, AssetModel, Branch, Department, Vendor), the taxonomy that groups them, and the lifecycle an asset moves through, from ReadyToAssigned to Assigned to Repair, Quarantine, or Missing. Only then does the model generate code, and every file it produces can be checked against that decision. Asset Manager, the example application used throughout this workflow, is exactly this kind of declared system.

Constraints Make AI Output Reliable

If there is one idea that separates the two models, it is this: reliability comes from constraints, not from better prompts. A model given fewer choices produces more predictable code. Human-directed development supplies those constraints deliberately.

Three constraints do most of the work:

1. A rules file. SKILL-SOFTWARE-ENGINEERING.md is the authoritative technical standard. It fixes the naming, the validation library, the endpoint shape, the soft-delete rule, and the mandatory CancellationToken on every handler and endpoint. When a generated file and the rules disagree, the rules win.
2. A data dictionary. .ai-assisted/DATA-DICTIONARY.md is the one file a human writes. It declares the application, the personas (Admin, Main, Guest), and each feature with its Group and SubGroup taxonomy and Stage enum. Nothing that is not declared here gets built.
3. Reference implementations. The model reads Country (Pure Master), Currency (Master with Lookup), and Todo (Master-Detail) in full before writing a new slice. The reference implementations turn an abstract rule like "generate eighteen files from one entity" into a concrete pattern to copy.

Notice that all three constraints are artifacts a person creates and a model consumes. None of them requires the model to be smarter or the prompt to be longer. They work by removing decisions the model would otherwise improvise, which is the opposite of how AI-directed development operates. A constraint is not a restriction on capability; it is a pre-made decision that keeps every future generation consistent with the ones before it.

This Is Why AI-Ready Architecture Matters

Constraints only work if the codebase is shaped to accept them. If a feature is scattered across five projects, no rules file can give the model the context it needs in one pass, and the human ends up re-assembling context for every prompt. The architecture itself has to be AI-ready.

Feature folders are the practical form of that idea. When one folder contains a feature's controller, handlers, validator, endpoints, views, and scripts, a complete feature fits inside a single context window. The model can read everything it needs in one read, and a person can review the whole change in one place. This is the core argument for Vertical Slice Architecture as the best architecture for AI-assisted development: it makes the unit of context and the unit of review the same thing.

Put the two ideas together and the operating model becomes clear. Human-directed development says a person owns architecture and specification. AI-ready architecture makes those decisions cheap to enforce, because each feature is self-contained and each change is bounded. The model gets a small, complete slice; the human gets a diff they can actually read.

Key Takeaways

• The split is about accountability, not about how much code the AI writes.
• AI-directed development improvises architecture and hides assumptions; its diffs are not reviewable.
• Human-directed development keeps a person accountable for architecture, requirements, and review.
• Explicit constraints — rules file, data dictionary, reference implementations — are what make AI output reliable.
• AI-ready, feature-folder architecture makes those constraints enforceable within one context window.