How we work · 2026
Published · 4 min read
I'll never read most of the code tunyt runs on. Here's how I sleep anyway.
Four engineers, a mobile app, a web app, a CRM, AI infrastructure and design, all at once, with coding agents writing a lot of the code. Reviewing everything was never going to scale. Writing my judgment down did. The decisions behind that system and why each one exists.
At some point I had to accept something uncomfortable. I will never read most of the code tunyt runs on.
The tech team is four people, and I lead it. In parallel we build a mobile app, a web app, a CRM, the AI infrastructure and the design, and a lot of our code is written with coding agents in the loop.
The classic way a CTO protects quality is review: read the change, catch the mistake, explain why. That doesn't survive this setup. I can't read everything. The agents don't remember last month's incident. A new engineer doesn't know which shortcuts we already tried and regretted.
So I made a different bet. If I can't be in every decision, my judgment has to be.
Decision 1: write it down, one file per kind of work
We keep a handful of short documents in the repo: performance, debugging, verification, API conventions, web design and security. Each one opens with its triggers, so you know it applies before you start:
Read this BEFORE writing:
- any new list endpoint, Prisma query or raw SQL
- any new cache read or write, or background worker
- any page-level data fetching
- or when investigating slowness
A rule nobody reads at the right moment is a rule that doesn't exist. Triggers turn "we have a doc somewhere" into "you're about to write a cache, so read this now."
Decision 2: the same rules for people and agents
The files are tool-neutral on purpose. A person reads them, and so does whatever coding agent is working in the repo. Same rules, same words.
I didn't want a separate "AI policy". Two sets of rules drift apart, and then you have two definitions of good. One file means one standard, and when a rule improves, it improves for everyone at once.
Decision 3: point at real code, not principles
Every rule points at a place in our codebase that already does it right. Paginate like this repository. Batch like this payment function. Cache like this ticket service, and call this helper at every write.
This matters more than the rules themselves. "Use cache-aside with invalidation" is advice, and advice gets interpreted. "Copy this function and call this helper wherever you write" is an instruction, and instructions get followed, by people and agents alike.
Decision 4: evidence before claims
The verification file has one rule above all the others: don't say "done", "fixed" or "passes" without the command output in front of you. Every app has its own block of commands to run, and the final report has to say what was run and what wasn't.
It matters most with agents, because an agent will cheerfully report that a test passed when it never ran it. The rule makes "I didn't run that" an acceptable answer and "it passes" without proof an unacceptable one. I'd rather have honesty about what wasn't checked than confidence about what was.
Decision 5: some lines aren't up for judgment
Agents never run SQL against our database and never read environment files. When a change needs database evidence, the agent writes the query and hands it to a person, with a note on what to paste back.
I made that absolute because the downside is lopsided. An agent that's too cautious costs a few minutes. An agent that runs the wrong query against production, or leaks a secret into a log, costs more than all the minutes it ever saved.
Some traps are written down because we fell into them. A schema change without a migration file looks finished, passes everything, and silently never reaches production. It's in the document now, with exactly what to do instead.
Decision 6: every budget needs a reason
Connection pools, worker concurrency, cache lifetimes, queue retention and rate limits live in one table. You're allowed to change a number, but the pull request has to say why.
Some of those numbers were set during an incident. The analytics worker's concurrency came down from five to three after our database saturated in July 2026. Without the table, the next person to see "3" would reasonably bump it back to 5, and we'd learn the same lesson twice, the expensive way.
Decision 7: extend, don't rediscover
Open performance and audit findings live in two numbered files. If you find a problem that's already listed, you reference it, and if you fix one, you mark it closed.
A team of four can't afford to discover the same problem twice. Agents are especially good at rediscovering things, confidently, with a fresh explanation each time. The numbered list is how we stop paying for the same insight over and over.
What it costs
Writing this down took real time, and keeping it current takes more. File paths move and line numbers drift every week, so every document carries the date it was last checked.
A CTO's judgment that lives only in their head doesn't scale past the number of pull requests they can read in a day. Written down, it scales to everyone who opens the repo, including the ones that aren't people.
I can't read every line. I can make sure every line was written by someone who read the rules.