A Daily AI Coding Setup for an Indie Hacker
The terminal opens at 6:40 a.m. and the first thing it shows is a diff. Somewhere between the previous evening and this one, a scheduled agent has opened three pull requests against a side project: one to bump a dependency, one to add a test that was missing, and one that rewrites a chunk of the billing module. Two of those are fine. The third will take twenty minutes to read. That is the whole shape of a modern indie coding day: a person does not sit down to a blank file anymore. The person sits down to a queue of someone else's work, half of it generated, and the job is triage, taste, and the stubborn parts the machine got wrong.
A daily setup for this kind of work looks less like a clever prompt and more like a small operating system. The tools matter, but the rhythm matters more. What follows is one working configuration, assembled by trial and error, not a product list. It assumes a solo developer shipping a real product with real users and a real budget that does not include a team.
The editor is a thin layer over a thick context
The center of the setup is an editor with an inline assistant that can read the repository, not just the open file. That distinction is the whole game. A model that sees only the cursor and the surrounding lines will suggest plausible nonsense. A model that can grep the project, read the schema, and follow an import chain will suggest something a person can actually merge. The editor itself is whatever feels comfortable; the configuration inside it is what earns the morning.
Three things get wired up before any code is written. First, a project rules file at the repository root, short enough to read in ninety seconds, that states the language version, the test runner, the naming conventions, and the two or three architectural decisions that keep getting violated. Second, an ignore file that keeps generated code, fixtures, and vendored libraries out of the assistant's context. Third, a set of saved snippets for the tasks that repeat: a new endpoint, a migration, a background job. Each snippet is a paragraph of instruction and a skeleton, nothing more.
The rules file is the piece most people skip and the one that pays best. It should read like a note to a new contractor, not a manifesto. Six lines about how the codebase works will outperform six pages of aspirational standards, because the model reads it every single time and the human reads it once.
A morning that starts with a diff review, not a prompt
The first thirty minutes never involve asking the model to build anything. They involve reading what it built overnight and deciding what survives. The rule is blunt: anything merged before coffee gets reverted by lunch. A generated pull request gets read line by line, and about a third of them get closed without comment. That ratio is fine. The point of the overnight agent is to surface options, and three options where one is usable beats zero.
What makes this review fast is a checklist kept in a plain text file, open in a side pane. Does the change touch the billing path? Does it add a dependency? Does it change a public route? Does the test actually assert something, or does it just call the function and check that nothing exploded? Four questions, answered in under a minute each.
After the queue is cleared, the day's real work begins. The prompt for that work is written as a specification, not a wish. A paragraph describing the behavior, the inputs, the failure modes, and the one file the change should live in. That last constraint matters more than any other. Left alone, an assistant will scatter a feature across nine files and three new abstractions. Told where the work belongs, it stays contained, and the eventual review is short.
The test suite as the contract between human and model
Tests do double duty in this setup. They catch regressions, obviously. More usefully, they are the mechanism that lets a generated change be trusted without a full read. When a feature request goes to the model, it goes with a companion request: write the failing test first, run it, confirm it fails for the right reason, then implement. The sequence is old and unglamorous and it is the single highest-leverage habit in the whole day.
There is a failure mode worth naming. The model will happily write a test that passes against the broken implementation, because the test was written after the fix and encodes whatever the code happens to do. The fix is mechanical: the test gets written and run before the implementation exists, and the failure message gets pasted into the conversation. That one paste changes the quality of everything that follows.
Coverage numbers get ignored in this setup. A hundred lines of assertion-light tests that all pass tell a person nothing. Twelve tests that pin down the behaviors a customer would notice tell a person almost everything. The assistant is good at producing the first kind by volume; the human's job is to insist on the second.
Where the model is not allowed to go
Every working configuration needs fences, and the fences are more personal than the tools. In this one, three areas are off limits to generated code: the authentication layer, the database migration history, and anything that touches money. Not because the model cannot write them, but because the cost of a subtle error in those places is measured in trust and refunds, and the review burden exceeds the speed gained. Those files get written by hand, slowly, with the assistant reduced to a rubber duck that answers questions.
The fence list is worth writing down and keeping next to the rules file. It changes over time. A year ago, background jobs were on the list; now they are not, because the pattern got familiar and the tests got good. The list shrinking is a sign of progress. The list growing is a sign that something got merged too fast.
The afternoon belongs to the parts that resist automation
By early afternoon the queue is empty and the feature work has hit its natural limit. What remains is the work that a model handles badly: a performance problem that needs a profiler and a hypothesis, a customer bug that only reproduces with a specific data shape, a UI decision that requires looking at the actual screen and squinting. This is where the day earns its keep, and it is the part most vulnerable to being eaten by the temptation to keep prompting.
The discipline here is a hard stop on generation after a certain hour. Past that point, the assistant is a search engine and a documentation reader. It answers questions. It does not write code. The reason is not philosophical. Late-day generated code tends to get merged without the same scrutiny, and the bugs that ship on a Tuesday evening are the ones that wake a person up on Wednesday.
Cost, latency, and the model that is good enough
A solo budget does not stretch to the largest model for every task, and it does not need to. The working split is roughly this: the fast, cheap model handles autocomplete, rename suggestions, and commit messages. The mid-tier model handles feature scaffolding and test generation. The expensive model gets called maybe five times a day, for the problems that have already defeated the cheaper ones. Escalation is deliberate and rare, which keeps the monthly bill in the range of a streaming subscription rather than a car payment.
Latency shapes behavior more than price. A model that answers in two seconds gets used constantly; a model that takes twenty gets used for big asks only. That is why the editor's inline assistant and the chat window are different tools with different jobs, and why configuring both is worth an afternoon. The chat window is for planning and hard problems. The inline assistant is for the next ten lines.
The end-of-day note that makes tomorrow cheaper
The last act of the working day takes four minutes. A short note gets appended to a file: what got merged, what got reverted and why, which prompts produced usable output, which produced garbage. The note is not a journal. It is training data for the human, and over a month it reveals patterns no single day would show. The prompt that worked on Monday rarely works on Friday, and the note is how that gets noticed before it wastes a morning.
There is a second benefit, quieter. The note records the reverts, and the reverts are where the real lessons live. A generated change that looked fine and broke something in production is worth more study than ten that sailed through. Writing down what went wrong, in plain language, is the only reliable way to keep the fence list honest and the rules file current.
What the setup actually buys
The honest accounting is this: the tools do not make a person a better engineer. They make the boring parts of the job disappear, and they make the interesting parts arrive faster. A dependency bump that used to eat forty minutes now takes four. A test scaffold that used to be skipped now exists. The hours saved go into the profiler, the customer call, the screen that looks wrong and needs a second opinion.
That trade is the whole argument. A daily setup built around generated code works when the human stays the bottleneck on judgment and the machine absorbs the tedium. The moment the ratio flips, when review gets skipped and the queue grows faster than it drains, the setup stops being a tool and becomes a liability. The fences, the tests, the note, the hard stop on generation, all of it exists to keep that ratio on the right side of the line.
Tomorrow morning the terminal will open at 6:40 and there will be a diff waiting. The job is the same as it was today: read it, decide, and get back to the part only a person can do.
