Getting started
You’ve inherited a repo. A friend built budgetcli over a few weekends — a small self-hosted budgeting API for tracking accounts, importing bank statements, and flagging overspend — and now it’s yours to run with your own money in it. It mostly works. It’s lightly documented. And there are places where you already suspect the original author got something subtly wrong. You’re going to spend a week with Codex turning this from someone else’s weekend project into something you trust, and this chapter is the first hour of that week.
The audience here is the engineer who already lives in an editor — VS Code, a JetBrains IDE, an inline completion humming in the gutter — and is eyeing a terminal agent with reasonable suspicion. You don’t have to give any of that up. By the end of the hour Codex is sitting next to your editor, not replacing it, and you’ve used it to fix a real bug in code you didn’t write.
The hour we’ll follow
Section titled “The hour we’ll follow”budgetcli imports transactions from bank CSV exports, and you’ve already noticed it mangles some dates — a statement that clearly says one day lands in the database as another. That’s your warm-up ticket: small, real, and verifiable against a CSV you can read with your own eyes. We’ll go from zero to that fix shipped, in five moves:
- Install it and see what surfaces Codex gives you — Install Codex and see the surfaces
- Authenticate and understand why the sign-in choice matters before you make it — Authenticate with ChatGPT or an API key
- Learn one turn of the loop — read, propose, approve, apply — before you trust it with anything — Understand one turn of the loop
- Hand it the date bug and watch that loop close on a real fix — Ship your first reviewed change
- Wire it into your editor so this becomes a daily habit, not a detour — Connect Codex to your editor
None of it is hard. The point of doing it as one continuous task — on a repo you’ve genuinely just inherited — is that the habits you pick up here are the same ones every later chapter leans on: read before you edit, approve before it writes, and treat every change as a proposal you review rather than a result you accept. On code you didn’t write and don’t fully trust yet, those habits aren’t optional polish. They’re the whole game.