When Code Gets Cheap, Judgment Becomes Leverage

Code used to be the expensive part of turning an idea into software. Expensive in money, but also in attention, calendar time, and coordination. With tools like Codex, that cost can drop dramatically. This issue is about what happened when I used it on a private project, and why cheaper execution did not make judgment less important. It made judgment the bottleneck.

I am probably building more working software now, as a product manager who does not code seriously day to day, than I could have built in the same time at my peak as a software engineer.

You might think that would make my old engineering experience less important.
For me, it has done the opposite.

The reason is not that Codex simply writes code for me. It can read the project, make a plan, edit files, run automated checks, inspect the result, and keep going. The speed is what everyone notices first: the slightly uncanny feeling of watching changes appear while you are still mentally preparing for the work.

But speed changes the job. It does not remove the job.

The more Codex can do, the more clearly I need to know what should be done. The more it can produce, the more carefully I need to judge. The more it can verify, the more precisely I need to define what would count as proof.

Codex did not replace my engineering judgment. It put it to work.

This matters beyond code.

The change is not only that one role gets faster. More of what I have learned across roles becomes useful in the same loop: product mode, design mode, engineering mode, testing mode, operator mode.

The job titles do not disappear. But the handoff changes. I can arrive with better pre-work, clearer artifacts, and sharper questions.

My example happens to be software, but I do not think the lesson is limited to people who write code. The same pattern shows up wherever a tool lets different parts of your experience meet in the same piece of work.

The Old Feeling

I got into programming about 20 years ago because of an open-source RPG.

I was not trying to become a software engineer. I was trying to make an idea in my head show up in a place I could interact with.

At first, I mostly guessed. I opened files. I changed things. I refreshed the page. I broke something. I changed it back. Eventually, guessing was not enough. I bought a book on PHP and started learning what the code was actually doing. That was the turn: I could think through a problem, write down the logic, and make the machine do something new.

That feeling hooked me.

Software made ideas unusually close to reality. A thought could become a button, a rule, a screen, a system, something another person could use.

Later, software became my work. I spent years as an engineer, mostly in enterprise environments, where the romance of making things quickly runs into customers, data, integrations, release processes, security reviews, and all the reasons serious software moves more slowly than side projects.

That slowness is easy to mock from the outside. From the inside, it often makes sense. If a system touches real users and real consequences, moving fast is not a complete philosophy. Sometimes going slow to go fast is not an empty phrase. I have enough scars to appreciate the sentiment.

Over time, the part of the work I cared about most changed. I still liked making things work, but I became more interested in the questions around the code. What should we build? Why this version? What happens when it fails? What is the smallest thing that still solves the real problem?

That path led me through architecture and into product management. I did not miss typing code all day. Not really. But I did miss the short distance between an idea and something visible.

This year, that distance got shorter again.

The Bottleneck Moved

There is a tempting story about coding agents: the AI writes the code, so the human matters less. I understand why that story is tempting. It is not what I am seeing.

I have used several tools for this kind of work, including Claude Code. I do not think the interesting question is which tool wins the internet argument of the week. These tools are becoming work environments, and the workflow matters: how they hold context, let you inspect results, and fit the way you think.

For my private projects, Codex has become the environment I reach for most because it helps me stay inside the loop: decide what should happen, make it real, inspect it, revise it, prove it.

The other surprise is how little ceremony I needed to get started.

When I first looked around, I found plenty of elaborate setups for agents, workflows, memory, roles, and rules. Some of them are useful. But for my own work, the bigger lesson was almost the opposite: start plain, then leave traces. Reading every best practice before beginning can become a very sophisticated way to avoid the blank page.

Software work has always had more than one layer. You decide what should exist, build it, then deliver it in a way people can trust. Coding agents compress the middle layer most visibly. The deciding and delivering parts do not vanish. They become more exposed.

If my direction is vague, Codex can build a vague thing very quickly. If my boundary is wrong, it can confidently work on the wrong slice of the problem. If I cannot review the result, I have not gained leverage. I have gained a faster way to produce risk.

More output is not the same as more value. Sometimes it is just more things to inspect. The better question is what became clear enough, safe enough, and useful enough to ship.

The code got cheaper. The bottleneck moved to judgment.

The Project That Changed My Mind

I have been learning this the practical way: in spare hours, using Codex, through a private side project that started as a personal experiment.

I will keep the details tucked away for a little longer. For now, what matters is what the work changed in my own head. It has been the first side project in years that made me feel the old loop again. Idea, change, visible result. But this time with a much heavier layer of judgment around it.

I have created more working product in a short period of time than I could have created alone in the same time, even when I was coding every day. It does not feel like the agent built it while I watched. It feels more like I am doing the thinking that used to sit around the coding, and Codex is making that thinking executable much faster.

It also changes the rhythm of a side project. I can explore an idea, turn it into something usable, clean up the rough edges, and harden the parts that need to be trusted without waiting for each step to become a separate phase of life. The skills do not merge into one vague superpower. They become easier to bring to the same piece of work at the right moment.

The work only became good when I stopped treating Codex as a magic code machine.
The project had to become a system for making judgment repeatable.

The first habit was making intent crisp.

Before I ask for a meaningful change, I try to know the shape of the work: goal, context, scope, and what done should look like. When I skip that step, the agent does not become useless. It becomes dangerously productive.

For fuzzy work, I have learned to slow Codex down before I let it speed me up: plan first, ask questions, name the boundary, then start.

For clearer work, the opposite can be true. If I know the next piece and I know how it should be verified, I can give Codex a larger task and let it work for 20 or 30 minutes. That is one of the biggest changes from last year’s assistant coding. I do not have to cut everything into tiny fragments. I can give it a real slice of work, as long as the slice has a shape and a way to check itself.

The second habit was making context durable.

My setup is still almost vanilla. There is a short orientation note for Codex, called AGENTS.md, that tells it where it is, what matters, which documents to read first, and what should not be broken. It is not trying to contain the whole project. It is more like the map at the front of a building.

The rest grew as the project needed it: design, architecture, testing, operations, and a handover file for the next session.

It means Codex does not have to start each session as a talented stranger. It can start with a map.

One useful habit is asking Codex what would help future Codex. At the end of a slice, I can ask it to update the documentation so we avoid split brain later.

Split brain is a phrase Codex taught me. I had not been using it for my own work, but it was exactly right. It describes what happens when the product, the code, and the plan each tell a slightly different story, and the next session has to guess which one is real.

This is another thing I have learned to watch for. Sometimes Codex does not just help with the work. It gives me a better name for the work. If I pay attention, those little phrases become handles. They make the next instruction clearer. They make the next session smarter.

The third habit was making judgment executable.

One example is interface work: the screens and steps a user moves through. Codex can change a flow, run the product, inspect the result, check whether the right controls are visible, and help turn a concern into a repeatable check.

The vague question of whether it looks okay becomes more concrete: overflow, available actions, disabled actions, first-time user clarity.

The useful move is turning judgment into something the project can run again.
The next session should start smarter because the last one taught me something.

What I Would Take Into Any Team

I do not think everyone needs to become a software engineer now. I do think more people will be able to make their ideas executable: product people, operators, analysts, founders, domain experts who know what should exist.

That is exciting. It is also where the risk is. When execution gets cheap, vague ideas can travel further before anyone notices they are vague. A bad assumption can become a working prototype. A prototype can be mistaken for a product.

If a team asked me how to start, I would begin with the loop.

What kind of work are you doing? Exploring a new idea? Turning something promising into something usable? Cleaning up what became messy? Learning from real users?

Those modes need different standards. Exploration needs speed and variety.
Building needs clear boundaries. Cleanup needs taste. Learning needs feedback.

Start smaller than feels impressive. Give the agent enough context, a bounded task, and a way to prove what changed. Keep accountability with the person or team that understands the consequences. Then make the lesson durable. If the agent repeats a mistake, do not only fix the output. Fix the context.

The Old Feeling, With Better Questions

Twenty years ago, software gave me a way to turn ideas into something real. Enterprise software taught me that real things need more than code. Codex has brought back some of the directness I first loved about programming, but I am not coming back to it as the same person.

I am bringing the architecture scars, the product instincts, the enterprise caution, and the annoying habit of asking what could go wrong.

The old feeling is back. The difference is that now I know how much judgment it takes to make the feeling useful.

I am going to write more about what I am building and what I am learning along the way. I will keep the details tucked away a little longer, but the first version is getting close enough that I want a few thoughtful eyes on it.

If you are curious and enjoy seeing early things while they are still taking shape, reply to this or reach out. I may share a few sneak peeks and early invite codes before I open it more widely.