We Built Our AI Engineering Platform Using Our Own AI. Here's the Human Experiment That Broke Our Process.

What happens when you force a software team to use the AI tool they are building? Chaos, unlearning, and eventually, a completely new way of working.

There’s a trap most software teams fall into without realising it: the people building the product never actually use it.

This creates blind spots that are almost impossible to catch from the inside. Our CTO was determined we wouldn’t make that mistake. We are building an AI-native platform for software delivery, and I wanted us to be our own Patient Zero. The mandate was simple: the Brunelly team uses Brunelly to build Brunelly.

It sounded like a great idea. A true human experiment. But getting there took a journey of its own, and it broke almost everything about how we worked.

A few weeks into building Brunelly, our business analyst started writing user stories in ChatGPT and pasting them into the platform, which on the surface looked like a sensible shortcut. The stories had the right shape, with acceptance criteria, edge cases and the usual structure, so the AI agents picked them up, generated code against them, and the team kept moving.

The output was unusable. ChatGPT didn’t have the context it needed, the stories were too focused to capture the full feature, and quality collapsed as a result. We had to abandon the code and start over.

That wasn’t Brunelly’s fault, and it wasn’t the BA’s fault either. It was the most natural mistake in the world, and it’s the same one most engineering teams adopting AI are making right now: treating AI as something you bolt onto an existing process rather than understanding that it fundamentally changes the process itself.

I’m writing this because almost nobody talks honestly about what the first three months of running an AI-augmented engineering team actually looks like. We’re a dev team of four engineers, a PO, a UX designer, and me, building an AI-native platform for software delivery while using it on ourselves.

Here’s what we’ve learnt.

The Setup Before We Went All-In
Before we started building Brunelly with Brunelly, we ran a fairly standard delivery model. Scrum, two-week sprints, Azure DevOps for the Kanban board, refinement → planning → build → review. We didn’t have a full-time BA at the time, so requirements quality was inconsistent, which meant features regularly took months to land and we shipped more bugs and rework than we wanted to.

In other words: normal. Not broken, but not flying.

Then we turned it on ourselves.

Mistake One: Bolting AI onto the Existing Process
The ChatGPT-stories incident was the first sign that something needed to change. But the lesson wasn’t “police what tools the BA uses.” It was deeper than that. A lesson we learnt very quickly is that AI doesn’t fix bad inputs, it amplifies them (a common realisation to most).

A vague story written by a human and reviewed by a human will be caught in refinement, in the friction of someone going “wait, what does this mean?” A vague story handed to an AI agent gets executed at speed and with absolute confidence. Why? Because without the wider context, it accepts what’s been given and makes up information for the gaps adding more friction than lessening it. And the friction that used to highlight ambiguity is now suddenly gone.

This aligns directly to what McKinsey’s State of Organisations 2026 found: 88% of organisations are now experimenting with AI, but 81% report no meaningful bottom-line impact. The reason for that is that most teams are running fragmented use cases on top of unchanged workflows. McKinsey put it bluntly: for every $1 spent on the technology, $5 should be spent on the people and process changes around it.

We did exactly that. We thought we could just plug it in.

Mistake Two: Sprints Stopped Making Sense, So We Abandoned Them
Once we got the team using Brunelly properly, things moved fast. Our main navigation panel alone, which included a fully context-aware nav with multi-tenant switching, role-based menu rendering, route guards for tenant isolation and feature gating, WebSocket-driven notification badges, and mobile-responsive collapse, would have been a four-to-six week build in our previous setup.

We did it in about two weeks. The AI generated the navigation service, the route guard chain, the Angular components, and the permission-based rendering logic.

That kind of speed broke our sprint rhythm because the AI was moving so fast. Pulling stories one-by-one through a two-week sprint stopped making sense when Brunelly could code faster than the cadence. So, we stopped sprinting.

That was the right diagnosis, but it led to the wrong cure.

At first, dropping sprints felt like liberation. No ceremonies, no artificial cadence, no pulling stories one-by-one when the AI could ship faster than we could groom the backlog. But within a couple of weeks, the cracks showed. Without a sprint goal anchoring us, everything became a priority which meant nothing was. Our actual delivery slowed down, time to value stretched out, and context-switching ate the gains Brunelly was generating.

Mistake Three: I Told Them to Throw Everything In
I have decades of experience in project delivery and operational experience under my belt. I know better, yet I still made this mistake.

If sprints are too slow, the obvious fix is to push more work through at once, right? We decided to go all in: feature by feature, multiple in parallel, devs pulling whatever was next in the queue. Brunelly churned out an immense amount of code in a very short space of time.

And then the merge conflicts started. Stories overlapping. Branches stepping on each other. The board so busy it became impossible to see what was actually happening and what the team needed to focus on.

The fundamentals of iterative development didn’t go away just because AI made it feel like they had. They got more important, because the natural friction that would slow things down just enough for a human eye to catch, had been removed by the AI.

Speed without rhythm is just chaos with better tooling.

Mistake Four: The Trust Pendulum
Underneath all of this was a quieter problem. The team didn’t trust Brunelly at first.

Naturally, they used it in hybrid mode: AI for some things, but still doing PR reviews manually, sticking to of doing code reviews the same way, and defaulting to other tools when Brunelly felt unfamiliar. The platform’s value depreciated when humans were re-doing the work it was meant to absorb.

I had to push the team to commit fully. Use Brunelly properly. Trust it.

And then they swung the other way. The team started over-trusting it to the point where PRs were waved through and local validation got skipped, and the thinking that should sit between AI output and merge quietly disappeared because everyone assumed someone, or something, else was doing it. The human in the loop was removed.

The right balance is somewhere in the middle, where you’re working alongside Brunelly rather than bypassing it or surrendering to it entirely. Getting the team to that middle point took longer than any of the technical changes.

What We Actually Changed
After about three weeks of these overcorrections, we sat down and rebuilt the entire operating model. We knew small tweaks here and there weren’t enough, we needed to do a proper rewrite of how the team works.

Tracking moved from stories to features. Stories were moving so fast through the pipeline that story-level tracking became noise. The meaningful unit of progress is now the flow and health of the feature as a whole. This directly contradicts Scrum orthodoxy, and I think it’s correct anyway.

Refinement followed the same shift. Rather than the PO spending entire afternoons clarifying individual stories in 3-amigo sessions, they now provide feature-level context: how the whole project comes together, what the user journey actually is, and what the constraints are. That feeds Brunelly more accurately, and the per-story detail emerges from there.

Technical planning shifted from human-to-human to human-to-AI-with-human-oversight. Pre-planning used to be an hour or two of devs and the tech lead working out how to build something. Now it’s a thirty-minute check-in between the developer and Brunelly’s technical expert, with tech expert providing guidance of how to sequence development with the rest of the team and the human approving. Planning in=s now done faster, more focused, with people who actually need to be involved.

Definition of Ready and Definition of Done came back with teeth. When AI is doing the grunt work, these aren’t bureaucratic gates anymore. They’re the only thing stopping the team from accidentally shipping plausible-looking nonsense at speed. Every story entering code generation has to clear DoR, and every PR requires a self-validation comment from the developer covering what they tested, what edge cases they checked, and what they’re still unsure about. If there’s no comment, the reviewer pushes it back.

Roles got clearer rather than flatter. Responsibilities were sitting with the correct person. The PO and the developer owns story quality, the Scrum Master role has changed to overall delivery lead works with Brunelly’s tech expert to pinpoint issues on process and now just uses Brunelly to advise on progress and monitor actual production — readiness rather than day to day. The tech lead owns the technical bar, and developers own execution and self-validation. We wrote this down explicitly because in the chaos of fast AI output, overlapping ownership means nothing gets owned at all. Getting the dev teams to take more ownership by leveraging Brunelly to troubleshoot and resolve themselves has taken a significant weight off our CTO. Essentially, everyone’s roles were elevated more to deliver a feature level, rather than at a task level. An important shift more businesses will encounter.

Meetings collapsed. We said goodbye to 3-amigos sessions, refinement happens bi-weekly at a feature-level, standup is fifteen minutes and focused on flow rather than status, and we do a short daily demo where the dev walks the PO through what they built at feature-level every few days. If a meeting isn’t producing it’s named output, we cancel it.

The reality is that most teams have too many meetings because their productivity is low and the ceremonies exist to compensate for broken flow, so when the flow actually works, they fall away on their own.

What We Measure Now
We had to throw out most of the metrics we instinctively reached for. What we actually track:

Time to value. How long from feature-level requirement to feature-level demo. This is the headline number.

Feature throughput. There should be daily progress. How much each engineer is shipping in a given period, alongside how much of it is sticking.

PO time saved. Hours back in their week that used to go to clarifying stories and chasing context.

Meeting load. Going down is going up.

Flow health. WIP per dev stays at two maximum, demo column is draining rather than accumulating, and the number of stories sent back from demo is decreasing. If it isn’t, the self-validation step isn’t being taken seriously.

The point isn’t the specific metrics. It’s that the measurement stack has three layers now: outcome (time to value), capacity (throughput, time saved), and flow health (WIP, rework rate).

What’s Actually Harder Now
This is the section most articles about AI in engineering skip, so let me be specific. When I expected trade-offs, I expected the obvious ones; onboarding harder, manual fallback impossible, code review degraded, team resistance. Almost none of those turned out to be real.

Onboarding is easier. A new engineer joining the project now has a structured, AI-supported flow to follow rather than a mess of knowledge.

Code review quality went up. Brunelly highlights critical things developers should focus on, minimises risk on the obvious stuff, and lets humans focus on what actually matters. Debugging is faster, not slower.

Documentation is better. The structure of how workflows through the system captures more “how” than our previous docs ever did.

We now can’t go back to a non-Brunelly way of working, everyone loves it now, and going back to our old system would feel like a downgrade. This only came when the team saw the benefits of using Brunelly correctly. Nobody resisted the upskill anymore. They were genuinely interested in what it was like to have an AI co-worker.

This change was harder than any technical challenge we faced. Getting the team to unlearn their old patterns and develop a new working relationship with something that isn’t quite a tool and isn’t quite a colleague took the longest. Despite that, it never showed up in any metric.

The Honest Claim About Quality
When we follow the process properly, output quality is high. Most of the bugs we did get could be traced back to a human shortcut somewhere along the way, whether that was a vague story, a skipped local validation, someone trusting the AI to fill a gap instead of doing the thinking themselves. Sometimes the AI genuinely got it wrong, but when we tracked the root cause it was almost always a missed step rather than a platform failure.

What I want to be clear about is that genuine AI-caused defects, in a well-run flow, are dramatically rarer than defects caused by human shortcuts, and those shortcuts are a process problem worth solving.

Where This Leaves Engineering Leaders
If you’re a CTO or VP of Engineering being asked by your board to “do something with AI,” the worst thing you can do is roll out Copilot, declare transformation, and wait for the productivity gains to show up, because they won’t. McKinsey found that 86% of leaders feel their organisations aren’t prepared to adopt AI in day-to-day operations, and getting the technology in place is the easy part.

The harder questions are the ones nobody is teaching you to ask.

What does ROI actually look like in your business when AI is in the loop? Not the spreadsheet version but the lived version, whether that’s features shipped, customers served per engineer, cost per release, or speed of response to your market. You probably can’t measure it cleanly, and that’s okay, but it does mean you need your own point of view on what “working” looks like rather than waiting for a benchmark report to define it for you.

What does your team need to stop doing? The real gains come from what you let go of, the meetings, the rituals, the metrics and org structures that exist purely to compensate for friction the AI has now removed. And what kind of organisation do you actually want to be in two years? Because the operating model you build around AI now is the one you’ll be living with.

What I didn’t expect when we started this experiment is that Brunelly didn’t break our process, it surfaced what was already broken. The vague stories, the meetings compensating for poor flow, the unclear ownership, the metrics measuring the wrong things: none of that was new, AI just made it impossible to ignore any longer. The forcing function we needed was a co-worker fast enough to make our existing dysfunctions visible.

The teams that win this decade won’t be the ones that adopted AI first. They’ll be the ones who let AI surface what wasn’t working and had the honesty to actually inherently change it. If you’re going through this yourself, I’d genuinely like to compare notes because the teams figuring this out in real time have more to learn from each other than from any framework.