Welbi: an AI coding practice, built on a number they could trust

What they asked for

Welbi builds the platform senior-living communities run on — the software that takes process off staff so they can spend the time with residents instead. The ask was not a rebuild. They wanted to establish an AI coding practice: understand where the opportunities actually were inside their engineering team, adopt the tools properly, improve the software development lifecycle around them, and coach and develop the talent they already had. That last clause is the one most companies leave off, and it is usually the one that decides whether any of it survives.

Why they called me

The VP of Product had hired me before, at another company, as a fractional CTO. That is the part of this engagement I am most pleased about, and it is worth being precise: the person came back, not the company. Someone who has already seen how you work through one hard problem does not need to be sold on the second one — they call you because they know what they are getting. Most of my work arrives this way.

First, a number that meant something

You cannot claim AI made a team faster if you never knew how fast the team was. That is my strongest opinion about this whole category, and it is where we started. By the end of the engagement, in the client's own words, their velocity had gone from an unknown to a known and stable count — which is what made predictable software delivery possible. Note the order: the measurement came first and the tools came second. Stability was not the victory lap. It was the instrument that let everything after it be judged honestly instead of argued about.

Then the tools — and when not to reach for them

We put Claude Code into the team's hands for AI-assisted development, alongside the process changes to make it stick. But the coaching that mattered was not the demo. It was the judgment call underneath: which work these tools genuinely accelerate, and which work they quietly make worse. The client's summary of that is better than mine — velocity increased meaningfully on adopting AI tools because we coached them on when to use them and when not to. A team that has been taught only the enthusiasm learns the limits the expensive way, in review, six weeks later.

The half that was not tooling at all

Alongside the practice itself we reworked the software development lifecycle, defined team roles and responsibilities, and I coached individual contributors and newly promoted managers directly. This is the unglamorous half, and it is where AI adoption usually dies — not on model quality, but on nobody being sure who owns a decision. New managers in particular are handed a title and very little else; an outsider who has done the job and has no stake in the internal politics is a genuinely useful person for them to think out loud with.

What changed

By the client's account: development velocity and team satisfaction both up, AI tools actually adopted rather than merely purchased, and product delivered on time. I want to flag the one people skip — satisfaction. AI programs imposed on an engineering team from above tend to move a delivery metric and quietly cost you the team's goodwill; this one moved both in the same direction, because the team was coached rather than instructed. The engagement ran March to August 2026 and ended where it should have: with the practice belonging to them.

Where I think AI actually pays for itself →All selected work →