Guide Posts
Working with AI-assisted development has its perks, and I have spent enough posts on those. What I want to put down here are the caveats, the ones that only start to bite once a project grows past the size where you can hold all of it in view at once.
The most useful thing I have learned is that boundaries help. Restrictions, constraints, house rules, whatever you would like to call them — they act as guide posts for the model while it reasons its way toward an implementation. I want to make the case with a thought experiment, because the experiment argues it better than I can.
Start with a blank canvas. An empty directory, nothing in it, no history. Ask your AI friend for a simple function that produces some output from a user's input. Now run that same prompt five times, in five fresh directories, and put the results side by side. You may be surprised to find that at the end of each run the code you get back will not be the same. All five will probably work. All five will probably be defensible. They will still differ.
Your AI friend is very good at solved problems. It has been trained on data containing many solutions to the same problem, and it will confidently hand you one of them. What it cannot know, from an empty directory, is which of those solutions you wanted. You may have a shape in mind. A switch case rather than an if/else parade. A simple object key loop rather than an array of indexed objects. Each carries its own trade-off and its own benefit, and not every approach fits what the codebase around it requires — which the codebase, in this experiment, has no way of telling anyone, because there isn't one.
So run it again, five more times, except this time drop a dummy file into each directory first, something carrying a sample implementation. You will find the model more or less matches what is already sitting there. It is the same effect you see with naming. Start a project from scratch and the model will invent its own semantic variable and function names, perfectly sensible ones, drawn from nowhere in particular. Hand it an existing project and it will reuse the convention it finds in front of it. It reads the room. That dummy file was a guide post, and it did more work than a paragraph of instructions would have.
Why any of this matters takes a short detour back through something I wrote in April, on the difference between a human mind and a one-million-token context window holding an entire codebase (Late to the Game, Changed by It). What that post argued still holds, and I would push its argument further while I am here. You should not need to hold your whole codebase in your mind at all times. You should absolutely be able to reason about it, argue with its architecture, take issue with a decision made in it three months ago and say why. This is the era we are coding in now, and it is fairly clear that more and more of us will be building through assisted tooling. The thing that separates people inside that shift is not the tooling.
The gap between someone who vibe codes and someone who actually builds an implementation with AI assistance sits precisely there, in whether they can reason for the intent as well as the implementation. Vibe coding is "I want this built, build it for me." Assisted programming sounds like something else entirely: this is what we need, these are the constraints, this approach is better than that one and here is why, this language is preferable here, these metrics show us which direction to take, validation on these approaches is essential, now let us spec it, plan it, audit the plan, and then move to implementation. One of those is a request. The other is a design conversation in which someone holds a position and can be talked out of it by a better argument.
It is also why I keep to a rule I have written about before, that I only work this way in languages I actually know. You cannot argue with code you cannot read, and a guide post you are unable to justify is just a preference you have imposed on a system that will quietly route around it.
I have been thinking about all of this because I spent part of the last few weeks comparing code samples for job applications, pulling old repositories up next to current ones. What came out of that was a fairly profound understanding of how much has changed since I found Claude Code earlier in the year. The shape of how I develop is not what it was. Last year, across three projects, I hand-wrote somewhere around twenty thousand lines. In the past six months, across eight projects, I have written a few dozen. And I would defend the recent work far more readily than the older work, because I have reasoned over and argued about every line of it, which is more than I can honestly claim for the twenty thousand.
That is the lesson I take from the comparison, and I think it generalises past me. The twenty thousand lines were never the valuable part. They were the visible part. The guide posts have to come from somewhere, and they come from you — from knowing a codebase well enough to argue with it, from having decided what shape a thing should take before anyone starts typing. A model working without them will hand you five different right answers and let you discover, some months later, which one your architecture could not afford. That has always been the work. It was just buried under all the typing.