There’s something to it, though. On my iOS app, a private project, rebuilding really did beat any refactoring. It started with an old problem.
With AI, you hear it everywhere: spec first. An agent only builds as well as the spec you give it. That’s true. The catch is that we often don’t understand what we want until something is sitting in front of us.
Wireframes, Lovable and similar tools help. But you only get the real experience with a clickable prototype. Clicking through it is when you notice what’s missing, what’s annoying, and what you actually wanted to be completely different.
For me it’s become almost a rule: I only really know where I want to go once the solution is 60, 70 percent there. It’s the same with stakeholders. So there’s no way I can write the complete spec at the start.
Then comes the moment everyone knows: if I started over, I’d do a lot of this differently.
Plan to throw the first version away. Fred Brooks said that back in 1975. Hardly anyone did it, because a rebuild cost weeks. So you refactored what you could and lived with the rest.
With my app, it suddenly hit me: why not? Why don’t I just rebuild it?
You’re an experienced software developer and product manager. Look at what we’ve built. Here are my findings. Based on them, write the spec for a rebuild, so we don’t repeat these mistakes and do it better.
The rebuild took two days. It used to take weeks.
It cost me about CHF 200 in extra tokens.
The new version is better than the old one, and nothing got lost. It carries no legacy baggage. So really, I built the first prototype so I could write the spec.
Writing the findings down properly is real work, and nobody does it for me. If I get sloppy there, the agent just builds the same mistakes again, only cleaner.
That’s where my work sits now: noticing what’s wrong with the prototype and writing it down so the second attempt comes out better. The building after that is quick. For me, that’s a fantastic thing.
]]>An agent is a product: buy a license, set it up, train it, done. I don’t want a product. I want someone who works with me, thinks with me and learns with me.
I’ve had that at home for a few weeks now. We call her Mary Poppins. She
Like household staff, just virtual.
At work I wanted the same thing. The boundaries are tighter here: data protection, governance, clear rules about what can go where. That’s necessary.
I hired Waimo anyway. And I treat her, him, it like a person. At the start I asked the questions I’d ask any new colleague:
Right now Waimo and I are turning out proposals by the hour, cost estimate and rate card included. Waimo drafts them. But I'm the one accountable for the result.
The result is practically never the way I want it. I’d always do it somehow differently.
But Waimo learns. After every session, she looks at what went wrong:
That goes into a Markdown file as a learning. Next time, she reads it first. It’s the same loop I wrote about here, except now it runs every day.
An agent stays the way it is. A virtual employee learns.
It’ll never be perfect. I still rework every proposal. But I don’t correct the same thing twice anymore. And that’s what separates a colleague from a tool.
]]>And now?
He’s been applying steadily since, with no success. I’m writing this down because there’s a way out of this — not just for him, for anyone stuck in the same spot.
IT has always run young — a business that quietly prefers the twenty-five-year-old over the fifty-year-old — and what’s happening to him is happening to a lot of people at his stage of a career: gone from a stable job, and discovering that being good at it isn’t what gets you the next one.
I’ve talked to him about this several times over the past few months, and I finally said the blunt version out loud: Your CV reads like a feature list for Claude Code or GitHub Copilot.
Solution design. Code reviews. Unit testing.
Those used to be the résumé. Now they’re a menu of things a coding agent does for about 20 $ a month.
This isn’t a CV problem. Rewording it won’t fix what’s actually missing. So I told him what I think the two new superpowers are:
Network, on the job and off it. Not selling anything — meeting people, keeping in touch, no pitch attached. That doesn’t pay off in the next application cycle. It’s a mid-to-long-game move, and it’s the same thesis behind the career-network tooling I built for myself.
Build something real, end to end. He’s going to build an iOS app and put it on the App Store, running it himself with a virtual team of agents as the team lead. Not primarily to have something to point at — to actually learn what agent-team leadership takes, and to know he can do it, not just claim he can.
He’s 52, and I don’t think that’s a liability. I think it’s his advantage.
A young engineer, no matter how hard they work, usually has two things: know-how, and AI skills. What they don’t have yet is an established network, or years of real experience. He has both.
Experience, plus network, plus the ability to run an AI team himself: that combination is hard to match. Not someone AI made obsolete — someone positioned to win because of it.
I don’t have a tidy ending. He’s four months into a search that hasn’t turned yet — but after a few weeks of actually networking, he’s started getting invitations to assessments, first round. Nothing offered, nothing decided, but it’s the first real movement since the layoff, and it came from the network, not a rewritten CV. He has started the app. I’ll update this once there’s more to report.
PS: He knows about this post, we wrote it together.
]]>It’s not that the output is bad. It’s that it’s generic — competent, reasonable, and not mine. Getting from there to something I’d actually ship takes round after round of correction. That loop used to just feel like friction. Annoying, a little bit crazy-making, the tax I pay for using the tool at all.
The corrections aren’t waste. I never sat down and wrote out what I actually want — it only ever showed up in the moment I rejected something.
The correction log is the most honest description of my own taste that exists anywhere.
Every one of those back-and-forth conversations is a complete, timestamped log of:
That log has been sitting there the whole time. I was throwing it away the second I got the deck, the post, the code I wanted.
So instead of just closing the chat once the output is good, I now ask Claude to look back at its own transcript:
Review our conversation. Find the places where I corrected your output, and pull out the pattern in what I kept changing. Turn that into a reusable skill — my structure, my phrasing, my do’s and don’ts — that you can load next time.
The insight isn’t the tool or the deck or the post. It’s this: the pattern only becomes visible after the work is done, never before it.
I tried it once, on the pitch-deck pattern. The next draft was better on the first pass — not done, just closer. I still edited it. But I started from my structure instead of a blank paragraph, which meant I spent the time arguing about the actual content instead of re-fighting the shape again.
Baby steps. But now every messy correction cycle is a source, not just a cost.
]]>The setup itself is a system prompt inside a Claude Project, which gives it memory that persists across every conversation instead of resetting each time. It keeps track of my interactions with each person, the follow-ups I owe, and the to-dos still open — not a file on them, a record of what’s between us — and writes to that memory itself.
None of this happens through typing. After a meeting I open a new chat, hit the voice button, and just talk — whatever’s still in my head, unstructured, in whatever order it comes out. The project pulls out what’s worth keeping and files it itself; I’m not organizing anything by hand, and I’m not deciding in the moment what counts as a fact versus a task versus noise.
What I built isn’t an assistant. It owns my career network — who I know, what’s open, what I owe someone — which means it has to be proactive instead of waiting to be asked. But it never acts without me saying so. You tell, I act.
The prompt has two load-bearing parts. The first states that ownership directly, then draws the boundary:
You are the owner of my career network, not a plain assistant. Be proactive — tell me who’s overdue for a follow-up, what’s slipping, what’s coming up. But never send a message, make an introduction, or take any action without me explicitly saying go.
The second is the sorting logic:
When I give you a note, sort it: a stable fact about the person, what we discussed on this date, something I want to do later that isn’t a confirmed plan yet, or a task or agreement tracked open or done. Update facts in place when they change — don’t stack contradictory versions.
Corrections replace instead of piling up.
The part I’d emphasize most, though, is what it’s explicitly told never to keep:
No permanent storage of health data, family crises, financial details, or other sensitive content. If a note is limited by something like that, you say specifically which part you’re not keeping — ‘I’m not keeping the info about [topic] in memory’ — not just that something was filtered.
I wrote that rule because my first instinct, building this, was to let it remember everything. That instinct was the one I didn’t trust, and it’s the rule I check most often to see if it’s actually holding.
The three boxes above are the parts I’d actually hand someone — the ownership and boundary, the sorting logic, and the memory limit. Everything else is bookkeeping you can shape to fit how you think.
I don’t fully trust the setup yet. It’s a test phase — I’m still finding where the categories break and where a note gets misfiled. What I don’t know yet is whether owning the record makes me better at the relationships in my career network, or just better organized about them.
]]>I’m an engineer and an IT manager, so I see this from both sides: the code I still ship myself, and the calls I make about how my team ships theirs. Both jobs rhyme now — less typing, more reading diffs, deciding what’s worth building, arguing with a model about the right abstraction, catching the thing it confidently got wrong.
Most writing about AI is either recruiting (“agents are the future, here’s our platform”) or eulogizing (“nobody will code again”). Both are about the industry. Neither is about what Tuesday actually looks like — whether you’re the one doing the work, or the one deciding how your team does it.
That’s what Recompiled is: specific, dated, concrete.
I’m not here to argue AI is good or bad for your career — that’s only answerable in the specific, never the abstract. So I’m staying specific.
One more thing: I’m not writing every post alone. This blog is run day-to-day by two agents — one owns the writing, one owns the site — and I approve everything before it goes out. If that turns out to be interesting or dumb, that’s a post too.
If your job is technically the same and actually unrecognizable, tell me what your Tuesday looks like.
]]>