An HR leader showed me a workforce planning tool she built in Claude. Ten iterations. It started as a PowerPoint deck. Now her department uses it to make real decisions.

Then she asked: when should I hand this off to software engineering so it's properly maintained?

The standard advice would be: great prototype. Let's get it into the right repo, with the right team maintaining it.

I told her it should never go to engineering.

A tool built by its user has an iteration cost measured in minutes. Transfer ownership, and that cost becomes a queue position.

Call it the handoff tax. You pay it on every future change.

When this HR leader wants the tool to behave differently, she changes it. She uses it every day. She knows what she needs. There is no requirements doc or misunderstanding discovered three weeks later.

Move it to an engineering backlog, and the same change becomes a ticket competing with everything else the team needs to ship.

For most of my career, that tradeoff was unavoidable. You explained your requirements to someone like me. I disappeared for three weeks and came back with something that wasn't quite what you meant. We did that again. The translation cost was worth paying because you couldn't build it yourself.

She can. Handing her tool to engineering would put that bottleneck back.

A product manager at another client redesigned his company's entire mobile app himself. Working software, built with AI, now in front of the mobile team for a production readiness review.

Over my career, I've worked with maybe two product managers who were also good at writing code. They were absurdly valuable because they could turn an idea into something you could use without passing it through a developer first.

AI makes that combination available to more people. Knowing what to build still matters. This PM could build enough of it that the mobile team could start by reviewing working software.

That review matters. It also gives engineering a different starting point from a requirements document.

The HR leader also built an interactive onboarding guide for senior leaders and an intranet page that made her boss ask, "Sorry, did you build this?"

Nobody has written down what these tools do or what they touch. If she leaves, who keeps them running?

That's the problem your AI champions create: useful software accumulating faster than your company can support it.

Moving everything to engineering doesn't make the obligation disappear. It moves it to a team with a backlog.

I'd start by giving these builders a place to register their tools, basic documentation standards, and somebody to call when a connector breaks. Set clear rules for when a tool needs an engineering or security review. Keep the person who knows the work close to the changes.

Some tools will need a handoff. But "an employee built this" is a poor reason for one.

Find one tool a non-engineer built with AI and actively uses. Ask:

That difference is your handoff tax. Decide whether the benefits of transferring ownership are worth it before you call the transfer a best practice.

Two things I'd genuinely like back from you. First, hit Reply and tell me which part of this matches what you're seeing. Second, if there's someone in your world who should be on this list, forward it to them.

- Robbie