I spent most of the last decade as a product manager. Before that I wrote code, led an engineering team, co-founded something that failed and something that didn't. At some point I became the person who writes documents and runs meetings, and I accepted that as a natural career sequence.
This past year I went back to building. Not as a weekend hobby — building what the operation actually uses.
It wasn't a plan. It was the consequence of the cost of trying falling so far that the genuinely expensive decision became not trying.
Here's what I learned, including what I learned by getting it wrong.
1. The bottleneck moved and it took me too long to see it
For years, the queue was: idea → spec → prioritization → engineering → delivery. The expensive step was the last one, and the whole process existed to protect it. That's what prioritization is: a way of deciding what deserves a scarce resource.
When the resource stops being scarce, the process keeps running out of inertia — and becomes the bottleneck. I sat on ideas in a backlog for three months because "we don't have dev capacity", during a period when I could have prototyped them in two afternoons and found out that two of them were bad.
The lesson isn't "everything is fast now". It's that the question changed. It used to be "is it worth the cost to build?". Now it's "is it worth the cost to maintain?". Those are very different questions, and the second is harder, because maintenance cost shows up slowly.
2. Specifying got more important, not less
With an agent writing code, I assumed the spec would matter less. It's the opposite.
When I show up vague, the agent delivers something plausible and wrong, fast. Then I review the wrong thing, correct it, and it delivers another wrong thing. Two hours later I have working code that solves a problem I didn't have.
When I show up with the problem well defined — what goes in, what comes out, what must never happen, how I'll know it worked — things flow.
Which is to say: the PM years didn't become past tense, they became a tool. Turning a vague complaint into a verifiable requirement is exactly the input that's missing from most agent work. Someone who only knows how to write code is as limited as someone who only knows how to write documents.
3. Review is the work, not the afterthought
My most expensive mistake of the year was accepting code I didn't understand because the tests passed.
It was a processing pipeline with subtly wrong error handling. It passed everything. It ran in production for three weeks silently swallowing an edge case that was, of course, the case the client cared about most.
Nobody had lied to me. I had delegated understanding along with authorship, and those two don't get delegated together.
Since then I work with a simple rule: if I can't explain what the code does without opening the file, it doesn't ship. It makes me slower and it has already saved me from two versions of the same mistake.
4. A knowledge system is infrastructure
That's where Credence came from. The pattern kept repeating: the agent knew a lot and couldn't say where any of it came from, so you couldn't trust what it knew or properly fix it when it was wrong.
The generalization that stuck: in agent systems, provenance isn't a feature, it's foundation. If you don't know where information came from, you don't have a system — you have a friendly oracle. Oracles are great in demos and terrible in audits.
5. Usage-based infra changed my behavior, not just my bill
I wrote about this in the Modal post, but the point holds outside the technical context.
When a resource is expensive and fixed, you treat it with ceremony. When it's on demand, you experiment. Saving money was nice; the behavior change was better. We swapped models twice in two months because comparing got cheap — not because we got smarter.
High fixed cost is conservatism dressed up as discipline. That's true for GPUs and for plenty of other decisions.
6. Fixing the prompt doesn't fix the process
One of our internal agents kept misclassifying a certain document type. I spent two weeks improving prompts, examples, few-shot, reranking. I gained a few points and a fair amount of fatigue.
The real problem was that two teams had been filling the same field with different conventions for two years. No prompt was going to fix that. We aligned the convention in a forty-minute conversation and the error disappeared.
A lot of what looks like an AI problem is a process problem that became visible. AI didn't create the mess, it just stopped tolerating it quietly — which is, honestly, the most useful service it has provided here.
7. Running long taught me something no meeting did
I'm training for an ultra and the thing that transferred to work wasn't discipline. It was pacing.
In a long race, whoever starts fast doesn't finish. The body collects later, always, and the price exceeds the gain. The urge to speed up is strongest exactly when you're feeling good.
Software projects work the same way and I'd known that in theory for years. Running made me feel it, which is different. A week of heroic sprinting produces two weeks of debt. The gain is visible and immediate; the bill arrives later, quietly, and nobody connects the two.
What I'm taking into next year
Three things, short:
Build early, decide later. A prototype became an instrument of investigation, not a commitment. Throwing work away got cheap enough to be a strategy.
Record everything the system asserts. If an agent says something, you need to be able to trace where it came from. That pays off in debugging, in audits, and in sleep.
Distrust things that work too fast. Not all speed is progress. Sometimes it's just the easy part getting done before the part that matters.
Going back to building was the best professional decision I've made in years. Not because I missed the code — because the distance between understanding a problem and touching it shrank, and that distance was where good ideas used to die.