Transcript — Stop Maintaining, Start Evolving (Katie Roberts, AI Native DevCon, 2 June 2026)

Speaker-label warning. The source transcript has no per-speaker labels — it is one continuous block produced by speech-to-text. The vast majority of the content is delivered by Katie Roberts (the presenter). The opening lines are spoken by Simon Maple (MC / host) introducing her; the closing Q&A includes one or more unnamed audience members and Simon wrapping up. Several names appear to be speech-to-text artifacts and have been preserved verbatim:

• "Alan Hills, Your Code as a Crime Scene" — canonical author is Adam Tornhill.
• "Mark and Fowler" — canonical attribution for the strangler fig pattern is Martin Fowler.
• "Hannah foxton" — a prior conference speaker referenced by Katie.
• "Don" — a previous-talk speaker Katie attributes the "safety safety safety" line to.
• "son up queue" — almost certainly SonarQube.
• "Baroos" / "Brook" — referenced in Simon's intro about a videographer's internet connection.

Do not silently correct these — quote them as they appear and flag the likely intended reference.

---

§ 1 — Intro by Simon Maple

Sorry. So the final session before lunch. And I'm told by Tom, our videographer, he's hijacked. Baroos high-speed internet connection. Brook has come into this country and brought the internet with him. And then how he's done that. But he has, which means that Tom's been able to accelerate the unknown of some of the videos. So as they get uploaded, I'll pop you out the app. And so if any of you missed talks, you can watch those later. Not now, obviously, because Katie's about to. Change. Again. Right, let's crack on. Katie Roberts from Nearform. I'm super excited to hear about this. Because I'm one of those people who basically uses AI to create new things. And then abandon them. So what I'm interested to hear as well, Katie from Nearform has to say about brownfield co-bases please big round of applause, Katie.

§ 2 — Who Katie is / Who Nearform is

Yes, I'm Katie Roberts. You might recognize me from such tracks as the latent space where I've been MC for the last day and a half. And I'm here to talk to you about how you can stop maintaining and start evolving, applying AI, native engineering in brownfield code bases. So a little bit about who I am. I am a technical director at Nearform, where I've been for the last six years. Prior to that, I was at the BBC where I worked across a variety of projects on the digital platform. A little bit about who Nearform are because we are one of the sponsors of the event. So we are a consultant services organization. We support our clients in solving difficult software problems. We are hiring in case you're interested. And we've got a birth downstairs. So please do come and chat to the people down there if. You're interested. To learn more about us.

§ 3 — Why greenfield AI works

So Alan native engineering works, and I know this because I've seen the numbers. And on greenfield code bases, the benefits of using AI. Engineering are completely undeniable. It's a perfect place for match made in heaven. We can do things right from the start being to design the product and the architectural decisions. They're all kept together in one spec and we can use this as a basis for our build. We define what systems should do. We get our agents to handle the implementation. And this means that product managers can have more input in the development process. We get to prototypes earlier, we get ux feedback quicker. Development teams can move faster. We start building and testing and observability much, much earlier in the process. And a lot of the talks I've seen at this conference, and to be fair, other conferences as well. Tend to focus on this. And that's also where a lot of the metrics that get reported in the press seem to come from these cycle bills.

§ 4 — Greenfield metrics from Nearform

And yeah, we've seen the same at Nearform and we're saying the same things as well. So yeah, 80% faster kickoff. We are able to go through our product and design process in a much more slick, rapid and realistic way. We've reduced our sprint zero times because we're getting our artifacts from our discovery process, which then is bootstrapping our spread zero. So the timelines for that have shrunk were 50% faster to MVP. We've seen four times development philosophy. And all of this, that means that there is much more time to focus in on some of the things that can get lost when you're trying to build [an] MVP very quickly. So the non-functional considerations are brought in from day one. Things like accessibility, security, performance. And as Hannah foxton said yesterday, the velocity problem is not really the development problem anymore. It's, we can all move a lot faster.

§ 5 — Brownfield reality

Except not all of us can because in the brownfield, the reality is very different. [Brownfield] code bases. Account for an estimated 60 to 70% of enterprise software. And they are very successful. They're hugely successful. That's why they've been around for 5, 10, 15 years. But with that comes accumulated technical debt. Tribal knowledge. Have you ever worked on a code base where something was developed by somebody who's long left the organization? And really the only documentation was in their head and they meant to write it down before they left. Dependency rot. You may be falling behind with a couple of dependencies and suddenly upgrading to the latest version of nose. It's going to take two months rather than two days. Fear driven development places in the code base where people just don't want to go. They don't want to touch it because it's so fragile. Test [rot]. This may be an unpopular thing to do. It tests didn't always get written. When you're under a lot of pressure tests are some of those things that can get left behind. Or they become so brittle that they're meaningless. So integration tests and user tests with Cypress. We've seen them just die off. And then people ignore them and then this point is having them there. Interdependent systems that are tightly coupled invisible contracts that you just can't see. And that results in high maintenance costs. Developers spend more time to cipher in the code fixing bugs or resolving issues, then implementing new features and improvements. Small updates become really difficult. Change becomes hard. Future development starts to crawl. Anyone who's stuck in this space as well becomes very demotivated. And it's nobody's fault because every decision on this code base was made with the best possible intentions. Nobody wants the code to get like this.

§ 6 — Ball of mud vs city metaphor

And it's sometimes referred to as the ball of mud pa[ttern]. I don't think of brownfield code bases as a ball of mud though. I think of them much more like a [city]. A city is very successful and it's something that's evolved over time. And brownfield systems tend to work like this. They work incredibly well. They have huge numbers of customers working on them. And that is why that they've been around for 5, 10, 15 years. Whilst maintaining complex user demands and all the time. Working through problems like performance, security and scaling that come with that. And like the city they've evolved as a response to the needs. And there are areas in that functioning city. So this is actually London. I [took] this last weekend from one of the top of the skyscrapers. I'm very pleased with this picture. It's lovely. But you can see on this you've got paths through the city which are very, very clear. These are the well trodden [paths], the ones that we all know where it's going. And then there are less well-maintained spaces. Dead ends and the places that you really wouldn't want to get caught in [a]larm late at night. So this is like your code base and you want to evolve it into something that is easier to build on, that's more understood and you get that high level view so you can start working through.

§ 7 — Three methodologies — overview

So I want to talk to you about how to evolve your architectures on br[ownfield] co-base[s] and I've got three different methodologies that you can have. That you can start thinking about. [if] you're wanting to move your brown[field] code base onto its next steps.

§ 8 — Pseudo-greenfield development

First up is the pseudo greenfield development and I think this one, I've seen this happen quite a lot. It's really great when your legacy code base is really comp[lex] or fragile and developing inside it has become very slow. Velocity is starting to crawl. And effectively what you do is you branch out and say right this new feature I'm going to develop it. I'm going to treat it like a greenfield code base. Now when you do this you tend to see a really fast iteration at the beginning. You can move very very quickly. But then you get to the point where you're starting to merge [the] branch back in and things start to slow down. It's really, really fantastic. And people are doing this, the developers who are working on it start to become kind of tourist[s]. They never learn about the inline problems of the code base. You can end up with duplication of shared concerns. So things like authentication, logging error handling. You may end up on your pseudo greenfield branch duplicating things that the legacy system has already solved which means that you end up with twice the amount of complexity because you've got diverging approaches. The longer your greenfield branch runs in isolation, the more the branch diverges, the more expensive it is to do reintegration without discipline as well. This temporary isolation strategy can become permanent fo[rk], which is another problem. And you don't really get to test how the code is integrating well together. Until you get to that last point [where] merging it back into the code base and that means that you can end up with a huge amount of bugs and test and refactoring as a result of that reintegration. But it is one [methodology] and it can lead to the next one which is the strangler f[i]g pattern.

§ 9 — Strangler fig pattern

So what is a strangle[r] fi[g]? This is always worth talking about strangler fig pattern was defined by Mark and Fowler, I think back in the 2000s. And the idea is that it's based on a strangler fig. So the vine drops a seed and it's part of a tree and it drops this [seed]. It sends down a route [— op]posite to what this diagram is doing — and then it builds up [it]self around it slowly strangling out the nutrients from the tree until it remains [and the] [tree] itself is removed. So like that the strangle[r] [fi]g pattern takes away the responsibility from the old area of co[de] one slice at a time and it's really great when you need to do an entire system replacement alongside the original with no downtime. This is a pattern that's been used by uber, netflix and bbc when they were evolving to move to microservices. And it's great because it doesn't really require down time[]. If you've got a legacy system that's poorly understood you can intercept at the edge and I've used it on systems before where you've had so much dependence in your op[s] that you just can't build the code on your machine anymore. It's the only way that you can then take the responsibility away from something which may still be running in production, but you actually need to evolve. Massive advantages. Yeah, the code that you're writing is effectively greenfield, but it's based on the legacy functionality. Oops, sorry. You can leave behind the bad patterns which is always good as well. There's no need to touch the legacy code base[] before you create a facade which makes a boundary so you're keeping the old system frozen. You're routing the rou[t]ing layer provides a natural place for feature flags. You can do AB testing, you can do canary testing. You can do traffic [splits] and progress is visible so you can start seeing the [traffic] hitting the old systems. You can test it very well. The disadvantages with this system is that it requires effectively setting up and running [two] systems and it's not trivial cost in the boundary, especially for like you've got to maintain two infrastructures effectively. It does take some time to work out where the points of abstraction should be where you can break these things apart. And it requires a commitment to completion. There's an awful lot of half [strang]l[ed] patterns out there where you've got some of the process has been started, some of the responsibility has been taken away and then the [appetite] [is no longer there for] continuing with it and it's been lost which means that you're then left with the double maintenance headache which can be cause a lot more stress and a lot more complexity for the teams.

§ 10 — Branch by abstraction

So a third option is the bran[ch] by [a]xtraction [— branch by abstraction]. So with bra[nc]h by abstraction you are working from inside the code base rather than around it. You put an interface within the code and you can then branch out to a new implementation. So something behind a feature [flag] so that you then can route the traffic through to your new feature flag. It's great when you've got a ton of improvements [in] the code that needs from the area so you can get rid of bad patterns or [r]o[t] that they may have crept into your code base. When you need to remove a deeply embedded component this is one way to do it. It keeps trying to release f[lo]w at all times. The abstraction layer makes the s[ea]m explicit and you can [it's] easier to reason about what's old versus new. Both implementations are active at once so you can compare behavior on production. So you just switch on your feature flight check how it's working. That means you're testing as you're going and that means that you're getting that constant feedback and it actually naturally surfaces a lot of hidden dependencies and coupling that maybe other refactors might miss. The abstraction itself, the disadvantages is that it is another piece of code that you have to write and maintain and eventually delete. There's some code bases which are littered with these abstractions that haven't been completely deleted, which again adds to the cognitive complexity of the code base. And teams can lose their motivation and leave these things half finished if you don't have a drive[r to see things] completed. It's also quite tedious to find these things in a large [b]ro[wn]field code base which is where AI can come in to help you and the [orchestrate] you know the routing logic does add cognitive load overhead like I've mentioned. It is much more like a, if you imagine a body right and you had to replace a kidney. If you go in there and you slice it and you remove the kidney and replace the kidney it's much more like that sort of methodology. What [a] horrible metaphor. But you all know what I mean don't you?

§ 11 — How NOT to use AI in brownfield

Right so how do we use AI to apply these methodologies? It's tempting to think that you could just let AI loose on your code but AI will confidently hallucinate about your code. When autonomous agents are deployed into established brownfield code bases without strict guide rails they don't really go rogue in a malicious way but they typically cause havoc through over optimization generating dark code which passes all your tests. And undermines the implicit architectural constraints and then creating more hidden technical [debt]. I know this because as soon as I got given access to cursor first thing I did was like oh I wonder if I can refactor everything. I did not push anything to the code base because I saw the sort of mess it was making. And of course it's 2026 and everybody knows that that would be a bad idea surely. It's still happening. People are letting agents loose without [bound]ed scopes and it will do refactors that aren't tested, aren't maintainable, aren't grounded in what the code actually did. And as Don said in the previous talk what you need is safety safety safety.

§ 12 — The crime-scene approach

So what do I do instead? So when I'm looking at a brownfield [code] base I don't start necessarily just with the code. I start with listening to the developers who are working on the code. They're the ones who are dealing with the problems that we're facing every day and everybody who has worked on this code base will have a view [of] what is wrong with it, how it could be improved and some areas where it maybe shouldn't be improved. And this kind of harps back to Alan Hills, it's quite an old book now called your code as a crime scene. And he talks about forensic investigations and looking at how you can do forensics across your code base. And this is just one piece of evidence your developers are excellent eyewitnesses. We d[o] [the] work fully remote so we did it as a mir[]o[] exercise. Everybody had an opinion. We created a graph of value versus complexity and we allowed everybody to bring to the table as we think these are areas where there could be opportunities for us to technically improve [the] code base.

§ 13 — Focused AI investigations

And then from there. We started focusing AI around those problems and we started to rather than do it as one big process we focused down based on where the areas that we knew were problems. So for example we knew that there was a significant amount of dead code within our backend code base. We focused [our forensic] investigations to look at those. We looked for dead code paths. We looked for duplication. We looked for patterning consistencies and we looked for complexity hotspots. We even did some [O]wasp [-]style scanning but we wou[l]d say that['s] not to replace doing proper security scanning. It just gave us a sort of high level these are areas of where your code base has got a bit smelly over time. And we started generating some dependency graphs. We started generating some maps of what the code is doing now not what our documentation said the code was doing because documentation has always been something that every developer loves to update regularly. So yeah it does [doc rot] over time and we know that.

§ 14 — The objectivity halo effect

And the one thing that we found is that this process was made significantly faster. It still needs to be human review because [A]I will confidently hallucinate about a code base but it did mean that something very very interesting happened. We had some objective data and we found that when we had that data that people would look at it [— it] wasn't written by. The cleverest person on the team. It was written by AI. So we had more people [— ]more people were willing to put in a view on this is right, this is wrong. I have observed something. Whereas previously you might have seen the principal engineer on the team would say I think this is right and everyone would just follow what they were saying. It was a really good [for]u[m]. It also helped to break the bike [shed]ing bottleneck. So where everybody goes this is what I think is wrong. This is what I think is wrong and then there's just a fight about what is the best thing to work on first. We now had some objective data that we can say we can actually see we've got metrics that we can start looking at. We know where our coverage gaps are and it gave us a way to prioritize the work that we needed to do and it gave us a destination we wanted to work towards.

§ 15 — Core principles for brownfield AI development

So yeah core principles for working in the brownfield development don't trust the AI input b[]l[i]ndly work in small scopes trying to keep it focused down. Yeah remembering that you want people to read this afterwards. Version control everything. I mean you don't want to be pushing anything up to your co-bases without version control creat[ing] findings back[]log and then prioritize your findings backlog. You can work through that as time goes on. Create human readable docs. This needs to be reviewed and understood by the team and the whole team. So make sure that you've got something that you can go back to and understand and then put your guardrails in place. Tests. Logs, static code analysis. We spent a lot of time before we did any of the actual implementation work making sure that things like our son[ar] [q]ueue [SonarQube] was up running working and reporting as we expect it to do not what I [— we] made sure that we had confidence in the test suites that we had. And then once we did that we decided to focus on one area at a time. So we used [—] you can either do that by specific feature requirement or specific technical requirement. And we made sure that we called out things that we found as we went as well. So we have rules that make sure that our skills don't repeat bad patterns that we have in the code base. It's very very easy to go oh I see it's done it like this. I'll just do it like that again. We make sure that there's clear definition of we want to see more like this pattern less like that pattern and we keep those skills alongside our code.

§ 16 — Case study: pseudo-greenfield ("six months in eight weeks")

Now. Some examples. This is a pseudo greenfield approach and it just gives you an idea of what we've actually done at Nearform and how powerful this can be. So yes it feels like six months worth of scope was shipped in eight weeks. This is [—] it's an amazing statistic. We used to have s[printed] development on this and we [—] the parts that were really useful on this is there was a huge amount of product requirements that have been produced but never actually implemented. So we used the AI to go through those and then create the PRDs to do this. First engineering [—] product reverse engineered the product requirements from that documentation reduce the time the[re] from months to a week. We did a detailed code base mapping reverse engineered the documentation from the existing code base [in]to the AI context that reduced from two weeks to hours. And automated the story mapping. From the PRD creation. Creating the [Ji]r[a] ticket and this is something that is always worth putting a little bit of time into creating a skill that [c]r[e]a[t]es really good. [Ji]r[a] t[ickets] gives that anyone can pick up because it just means you can paralyze your work so much better. And the impact was that the faster time to market six months were [shipped] in eight weeks four times faster than the one of our competitors had estimated so that's nice. But like I said, it isn't right for every project. It was right for this one.

§ 17 — Case study: branch by abstraction — AG Grid upgrade

Branch by abstraction. So this is a code base that I'm a little bit closer to and it's 5,000 lines, oh sorry 500,000 lines of code. So half a million lines of code. It's tightly coupled distributed monolith. It's a large legacy brownfield architecture that we inherited from another supplier. Again this is the kind of thing that happens all the time in the enterprise. The whole of the old development team may have disappeared. So you don't have that story of why it has been built up like this. There wasn't architectural decision records. There was a limited number of tests on it. And this sounds really simple but all we wanted to do was update the version of [AG g]ri[d] for the use of the latest features. And what we discovered when we tried to do this the first time was that the [g]ri[d]s had been implemented individually without inheritance pattern and no shared abstraction. So this meant that when we tried to do the very first time we upgraded AGrid it took us. A significant amount of time. I don't actually have the metrics. I think it was about a month. You know you think that's just upgrading from one version to another. And then because of that you then have a problem of well how do we then move forward with this? How do we get better? You can't have that's a complete time sink. We can't keep having that time [sink] because all of these things like ag[g]rid they're rapidly evolving now especially with AI on their side too. So we don't want to be left behind. We don't want to [be stuck] in this space. We want to be able to use this.

So what we did was we created a plan. And this is I think another difference between green and brownfield co-bases in a greenfield build a discovery process is kind of expected. We expect to do a bit of discovery. We expect to do a bit of planning. We expect to have to think about what we're building before we actually build it. In a brown field it's often let's all just dive in and just get this done mentality and that can mean that the planning stage is forgotten. And something that whilst we've been starting to move towards a more AI native way of working, the plan phase has extended and we are putting more time into our planning because we want to do the proper archaeology on the code base because we want to make sure that we're calling out the good path[]s and because we want to make sure we've got structured ro[]l[]back. And from that we then created something called a plan s[k]i[ll] which is all the technical and product considerations captured and then the work was broken down by [AG] [g]rid component skill that we created. And then this is then handed off to our developer skill.

§ 18 — The multi-agent developer skill flow

The developer skill. Has [—] it's a multi agent flow. So the orchestrator agent analyzes the requirements and then it sends off various different agents to do a[n A]D[R] check built test scaffolding another agent does that it looks at what's the implementation it does static analysis and quality gates and then it uses another agent to do a [pre]-r[]eview of its own work before pushing it to the developer to do a human review of the work before pushing it to a full human in the loop sign off to go through to the main development pipeline. And then once it's done that it then goes back and updates the master plan. So if you think we've got to do 80 of these you want to [—] you want to do this right a few times and then we've got a process now.

§ 19 — Flywheel + skills library

So it starts out relatively [—] it was relatively slow to start out. So the first couple of these took a decent amount of time so that as we work through the skill getting it right making sure it was robust. But we're seeing a flywheel effect with velocity improvements. We're starting to start push[ing] these things through much much quicker and it's easier for the developers to run these almost in the background. They can just keep going. And another halo effect from this is that we are starting to build up a library of skills within our code base that we can then refer back to this is what good looks like for a skill development. This is how you, the process that we're using for the s[ki]l[l]. This is how you want to work and that is then leveraging other areas of the code base that we can then start moving into improving and we're starting to get like I say flywheel effect of velocity improvement as we go.

§ 20 — Practical takeaways

This is my practical takeaway slide because I think that it's always good to be able to just remember what's good about [—] doing this is start with a [path] not migration always start with thinking about what you need to do. [Spec]s be the contract making sure that you're thinking about what it is you want to build up front. That planning phase is so important making sure that you're building the right thing. Thin[] slices and not rewrites do things in small chunks because if you're chunking down the work it's much much easier for you to get through it and you'll get to the point of yeah that's done let's move on to the next. And complexity is the opportunity. It's [—] it's something where I think we can really really lean into in the brown field. It does take a little bit longer. But once you're working in this way you can start seeing results very very quickly. So there you go that's how you can use AI to start paying down your technical debts. Any questions at all? Question. Where is. Knowledge? Yeah, I know I'm just telling you between you and food. Especially as a kitchen just here and I can smell it. So thank you all thank you again Katie big round of applause.

§ 21 — Q&A — slicing skills across feature teams

One final question you're not moving. Any. Really great present[]ation. One thing that I. Want to know is. How do you divide the skills with the different feature teams?

How do we divide the skills within the different feature team? Especially if like a monolith. So we do it [—] we slice it at the epic level so what you normally have is an epic [—] we then slice that and give those to our feature teams and then it might be our feature teams are very much smaller to work through those so instead of being like four or five people we can now do that with one or two people so that they are working through with their agents and that seems to be working quite well at the moment. There is always [—] you've got to be careful that you don't end up with [skills] diverging as well so there has to be some. Collaboration. Making sure that across the feature teams you're doing them in the same way and that people are reviewing still what's going on so we're not building silos of skills. Thank you. Thanks very much.

[Simon Maple, closing]

Okay class dismissed see you back again after lunch. All of the first day videos from this room are now available to you. Now you've seen these before so you know these processes. I haven't. Seen in the box yet no you're not allowed I've tried to not.