Twelve Years of Legacy Code, Nine Months of Change

Last sprint, 100% of EdSmart's code output involved AI assistance. Not a pilot team, not a greenfield feature, the entire engineering function, working this way by default, on a 12-year-old platform that real schools depend on every day.

That last part is the point. It's easy to hit numbers like this on a clean-slate product where mistakes are cheap. EdSmart's platform carries real student data and real duty-of-care obligations. There's no "move fast and break things" here. So the interesting question isn't the number — it's what it means for the people relying on us.

What it means for schools

Faster delivery is the visible outcome, but it's not the reason this matters. The reason is where the team's attention has moved.

AI has absorbed the boilerplate and repetitive implementation work. That's freed the team to spend more time on architecture, trade-offs, and solution design, including whether something should be built at all. More scrutiny is going into the decisions that actually carry risk, not less. The duty-of-care standard didn't get relaxed to hit 100%; it's being applied more deliberately, because less time is spent on the mechanical work that used to crowd it out.

Practically, that means new value landing for schools faster, from a team that's making sharper decisions about what to build and why — not just typing faster.

Why this is a culture shift, not a tooling upgrade

"AI-forward" gets used loosely. For EdSmart, it isn't a licence purchase, it's nine months of culture change.

Nine months ago, adoption was low and scepticism was high, for good reason: early attempts at AI-assisted coding produced genuinely bad output, and the obvious question — "does this mean fewer of us?" — was never going away just because someone said "productivity."

Mandating past that scepticism would have produced compliance, not capability. People running a tool they didn't trust, on a system where trust is the whole job. So instead, the team demonstrated what good use looked like, we gave people room to try it badly, before they tried it well, and let capability spread once a few people saw it click. Guardrails were built internally, drawing on external frameworks where useful and discarding what didn't fit EdSmart's context.

That's the part that doesn't show up in a stat, and the part that's hardest to copy.

A productivity spike from a new tool isn't much on its own. The capability to adopt, evaluate, and govern AI-assisted development — on a genuinely hard, legacy, high-stakes code base — is a different kind of asset.

It compounds, and it isn't something a competitor can stand up overnight, because it was built through lived culture change, not announced.

Where this goes next

We're not treating this as a sprint result to celebrate and move on from. We're building it into how we run engineering permanently, because the thing that got us to 100% wasn't the tools — it was the judgement to use them well. That judgement is what tells us when AI speeds up good decisions and when it would speed up bad ones. On a platform schools depend on, that distinction is the whole job.

So the number isn't really the achievement. The achievement is that our team now makes that call, correctly, by default — and that's exactly what schools have always trusted us to get right. We just do it faster now.

‍

‍