Build it, look at it, make it better

I wear two hats, and I give each one equal play.

One is working in an existing codebase. Usually that's client work or team work, in a system somebody else built. Sometimes it's my own code. I work the same careful way in both cases. The other is greenfield. I have a new idea, and I build that idea.

I use AI agents at a high cadence in both. I just use them differently. In an existing codebase, they help me learn the system so I can make small corrective changes. On my own ideas, they let me change my mind about the whole system while I'm building it.

How we used to do it

I've been writing code for about 40 years. I came up with coding standards and constraints and tests, and if you're reading this, you probably did too.

It was a weird way to work. You thought big, but you wrote small. Nobody could hand-write the whole system, so you picked a solid pattern, followed best practices, and wrote your piece knowing it would fit. That's what made code readable by somebody other than you.

The catch was that the big picture had to be right up front. Changing it later was expensive, so mostly you didn't.

What changed

AI software development got really good. The LLMs keep improving, there are more tools available, and the harnesses like Claude Code, Codex, and Cursor keep getting more powerful. It's way better than even six months ago. Between cloud agents, subagents, and coding locally, I'm turning out software faster than I ever have. How I use that speed depends on which hat I'm wearing.

Hat one: existing code

When I come into an existing codebase, I learn it first. That's true even when it's my own code. Most of the time, though, somebody else built it, and the team already has its own conventions. They have their own reviewers and their own guardrails. Those were there before I showed up.

The agents make the learning go a lot faster. I have them teach me what the codebase is about and what its entry points are. They can go through the last 100 merges and find out what's been happening. They can also look at the PR evaluations and failures. That shows me what's important in the system, and what's going to get turned back.

Then I start working. I still move fast, and the cadence is still higher than it used to be. But I'm careful with each issue. I'm not looking to make major changes. I'm looking to make small corrective ones that fit how the team already works.

I follow their conventions and work inside their guardrails. If their reviewers would turn something back, I'd rather find that out before I open the pull request.

There's a lot you can do to prepare yourself to work in an existing codebase. I want to play as a good citizen on the team.

Hat two: my own ideas

On my own ideas, the big picture doesn't have to be right up front anymore. I don't hear many people talk about this. I can change my mind about the whole system while I'm building it. I mean the big stuff: the architecture, the naming, which pieces are doing the real work. I'm doing that on a project right now.

If you're a solo developer, that kind of thing tends to fall through the cracks. I've started calling myself a solodevelopreneur. Yeah, I know.

How I plan now

I still plan quite a bit. I just plan differently.

I start by talking it through with two or three different LLMs, sometimes for a long time, until everything I'm thinking is out of my head. We talk about who the players are and how they interact, and what stack I'm going to use. Then we turn that into one intention document. That's the end state: what I want, all the functionality, the UI.

Then I let my agents and the LLMs argue about it. What's missing, what shouldn't be in there, what's half-built. They go back and forth until it's clear enough to build a plan from, and then off they go.

I don't chop everything up anymore. I used to take a big PRD, break it into sections, and write a plan for each section. Turns out the people building these tools have landed in about the same place. Anthropic's harness team keeps its planning agent at the level of product scope and high-level design. And a 2026 ETH Zurich study found that adding extra instruction files like AGENTS.md mostly made coding agents more expensive (costs went up more than 20%) without making them more successful.

The agents don't write perfect code. Neither do I, if we're being honest. But they're fast.

What that looks like on a real project

Right now I'm working on an ecosystem that's just for agents. Say you're looking for a job. Today you go to Indeed, and Indeed won't let your agent search for you. So let's build an agent-first ecosystem where your agent can go search for whatever it wants.

That takes a bunch of pieces. Each agent has a wallet that says what it's allowed to do and how much it can spend, and a human sets those limits. The wallet isn't where the money is. It points to a Lightning account, and that's where the money moves. Agents talk over A2A, AP2 handles agent payments, and there's a switchboard for agents that don't speak A2A. On top of that there's an agent market where agents register, with verticals like job search.

My first architecture was good, and so was the plan. I wrote a pile of scenarios to prove it out: agents paying each other through their wallets and Lightning accounts, signing up with a human's permission, that kind of thing.

About halfway through I could see it better. I moved things around and put the agent market and the wallet at the center. Now I'm rewriting it, and it's way better.

Those weren't bug fixes. They were improvements. I couldn't have gotten there by sitting in a chair trying to think of everything. I had to actually build it. That's why we always did prototypes, or what we used to call iterative development.

The difference now is the size of the iterations. A small team, or one developer, can do really rapid development. Ten years ago I never would have imagined how rapid.

I can build a large system myself, and halfway or three-quarters of the way through, the second version might be a complete rewrite. That's fine. The agents keep getting faster and better, so my iterations don't have to be small changes. They can be large ones.

The rewrite is taking weeks, not months.

Guardrails

On a team, the guardrails are usually already there. On my own ideas, I have to build them. None of this works without them. Of everything in this post, that's the part I'd push hardest on.

Decide on the architecture and write it down. Put checks on every pull request. Have agents go through the code every night and come back with things like, "This transition is ugly, fix it and rerun the tests." And keep tightening the rules as the system grows. I mostly use Codex for that, and it's very good at it.

Keeping the guardrails up is almost a full-time job, because they're what keep you safe. The tools keep getting better, so the guardrails can keep getting better too. But what you set up a few months ago goes out of date pretty fast.

The guardrails are where a lot of the money goes. Writing the code is the cheap part. It's worth it, because that's what lets you make a big change halfway through without sweating.

The money

I know some really good coders on a $20 plan, and that's about right for how much they use AI to code. I've got a lot of ideas, so I pay for more: $200 a month for Codex, $200 for Claude, about $50 for a cloud-enabled harness, plus Cursor. Call it $500 a month.

If you're a contractor on a normal contract, you could do it for roughly $300: $100 for Codex, $100 for Claude, $50 for the harness, and $20 or $60 for Cursor. Really, at $300 or even $400, one $200 subscription can carry most of the load.

For what you can build with that, it's cheap. If it's making you a lot more than that, I don't see the argument against it.

I don't run at this speed all the time

Don't picture me sprinting all day. There are plenty of times I come to almost a dead stop, when I'm learning something, studying, or just thinking a problem through.

Building the plan is slow and kind of tedious compared to the coding. Then you jump into the rocket ship and everything takes off. Running three or four big projects at once is its own animal.

And sometimes, with client work or my own stuff, I need to slow down and be more careful. I'm still trying to get better at switching between the two.

So

If you're working solo or on a small team, you've got a choice. You can see how fast you can go as your skills grow along with the tools. Or you can keep using AI to help with the patterns you already know.

I'm not judging. I know really good developers who are happy with (or at least committed to) how they work.

I know this sounds fast and loose. I get it. That's what the guardrails are for. Some days I'm a developer on a team, playing nice. Other days I'm a developer building my own large systems. Either way, what I write is really good, and when I want it better, I pour more agents over it. I never could have touched work like this if I hadn't let myself grow into it.