AI Engineering

In February 2025, Fullscript engineering leadership met in Toronto to discuss our goals for the year. We nearly decided to break up our multi-million line monolith, not because it was failing us, but because AI was.

When we applied frontier models to our codebase, the results were deeply disappointing. Context windows blew up, suggestions were brittle, and hallucinations crept in constantly. It was nowhere near production-ready.

At the same time, we were seeing credible stories from peers who were shipping meaningfully faster with AI embedded in their workflows. This wasn’t just hype. Something real was happening.

So we asked ourselves some uncomfortable questions. Do we restructure the application to fit the model? Do we break the monolith into AI-sized pieces? Do we abandon the architecture that made us successful?

We came close.

Instead, we chose plan B: engineer our way out of the problem.

Here’s what we learned.

You Are Not a SaaS Product Away

Integrating AI into engineering is much closer to a cloud migration than adding a new tool to your stack. The organizations that successfully moved from on-prem to cloud didn’t just lift and shift; they used the transition as an opportunity to rethink how they worked.

We made the classic mistake at first. We bought a fleet of Cursor licenses and layered rules on top of our codebase to make it behave. Acceptance rates improved and usage ticked up, but the gains plateaued quickly. Developers still encountered friction, and the tools required awkward workflow changes to be effective. It helped, but it never became transformative.

The problem wasn’t the model. It was the system around it.

We saw much stronger results once we began building our own harnesses on top of the models and embedding them into our existing processes. Instead of forcing developers to adapt to AI, we shaped AI to operate within our environment. Aligning the tools with how we already worked, and meeting developers where they were, drove adoption and productivity far more than tweaking prompts ever did. (We wrote more about this in our companion post on Nitro.)

Set a Goal and Make It Someone’s Problem

“Use AI more” is not a strategy, and neither is “move 30% faster.” While statements like these can be useful for motivating from the top down, without a more tangible goal it can’t be truly actioned. If you can’t measure it, you can’t drive it. 

We chose a concrete proxy: merge requests per developer. Then we asked for 30% more of it in one year. It’s not a perfect productivity metric, but it’s directionally useful and easy to track.

Just as importantly, we made it someone’s job.

We assembled a small, cross-functional team: a director, a project lead, and three engineers spanning frontend, backend, and infrastructure. Their mandate was simple: move the number. Clear ownership, measurable outcomes, and the autonomy to experiment mattered more than any particular model choice.

In the end we saw a 33% improvement in that metric.  We also saw something unexpected - non-technical users were able to commit directly to the application, and entire changes were being written by the Nitro as well. 

It’s Only as Good as Your Process

Our engineering systems were already reasonably mature. We had strong CI/CD, good test coverage, automated linting, ephemeral environments for branches, and internal tooling that made onboarding relatively smooth. Documentation was decent, if not perfect.

That foundation made a real difference. The team didn’t need to build scaffolding for the LLM to operate safely because it already existed. The models could run tests, follow conventions, and validate changes using infrastructure we had invested in years earlier.

AI will not fix a broken SDLC. In many cases, it will amplify the pain.

Some useful gut checks: 

• How good of a time are your junior developers are having? 
• If your team doubled overnight, would your systems hold? 

If you say no to either of those, AI will surface those weaknesses quickly. AI development does not negate the fundamentals. Even with that solid foundation the velocity of AI is starting to push our systems and processes to the limit. A limit we are quickly working to remove. 

Don’t Underestimate the LLM

Frontier models are now genuinely capable at software development. Context windows are large, latency is reasonable, and cost is no longer prohibitive. Harnesses like Claude Code and OpenCode are effective at steering models through structured workflows.

You don’t need a complex RAG pipeline or a dozen MCP integrations on day one. In our case, a handful of well-written markdown files and some environment YAML delivered more impact than months of prompt experimentation. The bottleneck wasn’t the model’s intelligence; it was whether we had engineered an environment where it could operate productively.

What’s Next

We believe that by the end of next year, a significant majority of our code could be written by AI. If that’s even directionally correct, the velocity gains will be substantial. Doubling output per developer no longer feels implausible.

That’s exciting, but it’s also destabilizing.

For years, one of our biggest bottlenecks has been onboarding new engineers. Soon, a new developer may be little more than a git worktree away. When writing code is no longer the primary constraint, something else becomes scarce: architectural judgment, product clarity, review discipline, operational rigor.

The constraint shifts.

The next bottleneck won’t be typing. It will be deciding what code deserves to exist and maintaining the discipline to keep systems coherent as output accelerates.

We’re no longer asking how to make AI work inside our system. We’re asking what our system needs to become when AI writes most of the code.

That’s the harder problem, and it’s the one we’re focused on now.