A different way
to do the work.
AI has changed how I build software. I can explore more ideas, move through implementation faster, and spend more time on the decisions that need experience.
The tools changed.
The responsibility didn’t.
I use Codex, Claude Code, and Cursor across planning, architecture, implementation, debugging, testing, and documentation. Sometimes that means a small edit. Sometimes it means directing agents through a larger piece of work.
My part is to understand the problem, set the boundaries, examine the result, and decide whether it’s ready. Being able to explain the code and its tradeoffs matters just as much as being able to produce it.
How I approach it.
Start with the problem
Before I let agents loose in the code, I write down what we are trying to do, what cannot break, and what good looks like.
Give agents clear jobs
Codex, Claude Code, and Cursor each get specific work: implement this, check that, explain the tradeoff, write the test, clean up the edge case.
Make the design argue back
I use AI to challenge the architecture before the team is committed to it. If the design is weak, I want to know early.
Trust the evidence
Tests, diffs, logs, screenshots, and local runs matter more than a confident explanation. If the evidence is weak, the work is not done.
Shape the product faster
Interfaces, flows, copy, data models, and failure states can be explored quickly enough that bad ideas die before they become a roadmap.
Keep the notes honest
Plans, decisions, QA notes, and release context need to move with the code. Otherwise the documentation becomes a fossil.
What’s in the toolkit.
Codex
Repo-wide changes, tests, refactors, documentation updates, and the verification work that turns a draft into a real change.
Claude Code
Deep codebase reasoning, architecture discussion, domain modeling, and long-form work on thornier implementation problems.
Cursor
Fast inline coding, targeted local edits, pairing flow, and focused iteration inside active development work.
Where judgment matters.
“AI can write code. It cannot own the consequences.”
Faster implementation makes it easier to build the wrong thing quickly. Product fit, privacy, architecture, and release quality still need deliberate decisions.
I’m interested in shorter feedback loops and less time lost to coordination. The useful question is whether a way of working produces better software, and whether there’s evidence to support that.
More in my writing