I just graduated again. Thanks, Claude.

Through school, I was a math kid. A friend and I ran a chapter ahead of the class, solving problems for fun — and, when that got boring, inventing new ones. But the sciences never grabbed me the way numbers did. So when the time came to pick a stream — in India, that happens absurdly early, in grade 11 — I chose Economics and Accounting. “Commerce,” we call it. My friend went off to engineering. I was persuaded to join him, but I knew I’d be miserable the moment physics and chemistry showed up.

I never regretted it. I was good at Commerce, and I loved it — the perfect balance of mathematics, problem-solving, rules, frameworks, and creativity. I never once wished I’d been an engineer.

Never, that is, until the start of 2011, when I landed in San Francisco and realized there’s a forty-mile stretch of the planet that’s absolute heaven for computer engineers — a place that, a little unfairly, gives them the power to change the world. That itch lasted fifteen years, far longer than I’d have liked. I tried to scratch it by founding my own SaaS company, Krayo. It never reached escape velocity, for a long list of reasons — the most honest of which was my own (in)competence as an engineer.

Then came 2026, and the good folks at Anthropic shipped Opus 4.6 and gave Claude Code wings. I typed my first prompt, built a website for my wife’s art studio, and, by the time it was live, finally knew the thing I’d half-suspected for fifteen years: you don’t have to be an engineer to be a builder.

This site is the proof. I designed, wrote, and coded all of Strategy of Finance myself, with Claude Code, in twenty-two days — toying with layouts, reformatting pages more times than I’ll admit, cutting and adding and re-cutting. That any of it is possible in twenty-two days still blows my mind, and it made the lesson real.

It also gave me a word for what I’d become. I’m not a financial engineer — that’s a quant, pricing derivatives. I’m something newer, and frankly more fun: a finance person who engineers. A fingineer.

Here’s what I didn’t expect: finance turned out to be an unfair advantage. The instincts that make you good with a P&L are the same ones that make you good at directing a coding agent — scoping a problem before you touch it, breaking it into phases with deliverables, thinking in systems, and, above all, knowing when something looks right but is quietly wrong. I wasn’t writing the code. I was doing what I’ve always done: framing the problem, pressure-testing the output, and bringing taste.

I’m sharing a few things I learned along the way — lessons that came from doing, not theorizing. I’m no expert — this is just lived experience.

1. Design before you delegate. Before I open Claude Code, I hash out the plan with a chat model — Claude or ChatGPT — as a sparring partner. The catch: they slip into yes-man mode fast, so you have to keep demanding they argue the other side. By the time I start building, I know the product, the scope, the phases, and the stack — I’m not leaving the load-bearing decisions to the coding agent. That stack choice for this site came straight out of one of those arguments, not from whatever the agent would have defaulted to. The better you frame the problem, the better the agent can execute. Bad delegation is still bad delegation, even when the delegate is a machine.

2. Keep your judgement. These tools are powerful and get better every month. But they’re tools. Don’t blindly accept what they recommend — understand your product and bring your own taste to it. They’re extraordinary at doing a thing repeatedly and well; it’s on you to prompt them to improvise, and to know when “good enough” isn’t.

3. Always run a judge pass. This one’s been a genuine game-changer. Before any major commit, I have the work reviewed adversarially — a fresh pass whose only job is to find what’s wrong. AI is brilliant at producing code that’s plausible and wrong in the same breath; a judge pass is how you catch the gap before it ships. (One logo on this very page once rendered as an invisible, zero-width element and quietly disappeared — looked perfect, was broken. The eye misses that; a review doesn’t.) Where I could, I went further and had the build itself refuse to ship on certain mistakes — a broken internal link, two “featured” essays at once — so the machine catches the errors my eye can’t.

4. Turn mistakes into memory. Everyone’s losing their minds over skills, and rightly so. But as a non-engineer, I suspect my biggest edge is duller and more durable: I keep a running gotchas.md of every trap we hit — and next to it a CLAUDE.md the agent reads at the start of every session, holding the stack, the conventions, and the design rules. The agent never has to relearn what already bit me. Do this across ten projects a year and you accumulate a private engineering guardrail that’s genuinely hard for anyone to beat — a compounding network effect of your own.

5. Turn the repeats into playbooks. The gotchas file keeps me from repeating mistakes; this is the other half — never doing the same job by hand twice. The recurring work on a site like this is adding things: an essay, a podcast episode, a tool. So I had the agent write itself a playbook for each — the inputs only I can supply, what it should generate and wire on its own, and exactly where it must stop and show me before anything goes live. Now publishing an essay is mostly this: I hand over the writing, and it drafts the summary, picks the topics, finds the related episode, generates the social card, and threads the piece into every page that should point to it — then hands me a one-screen summary to approve. I went from doing the chore to signing off on it. That feels like leverage.

6. Trust the tool. As an investment banker, my weapon was Excel. Over the years it’s become so deep that knowing all of it is impossible — and what made it powerful for me wasn’t knowing every function, it was trusting that whatever I needed to model, there was a way, and I’d find it. AI coding is the same, only easier: you just ask, and it tells you how. So don’t let your ignorance limit your imagination.

As a non-engineer founder, I used to be quietly baffled that my dev team couldn’t ship faster. Having now built this thing by hand, I get it — I see how much they had to write, and get exactly right, by hand. (There’s an apology in there somewhere.)

It’s the era of builders, not just consumers. Even thirty to sixty minutes a day with these tools will sharpen how you see the products around you — and your own business. I’m hooked, and I’ll keep adding the models and little apps I build to this site for anyone to play with. Finally, this feels like my kind of engineering.

Take a peek around. Tell me what’s broken, what’s good, what you’d do differently.