Your Platforms Matter More Than Ever With AI

AI-powered software development is here to stay, and it has been evolving very fast in the last few months. If you talk to someone and they tell you, like, last year we did X, that is already outdated. And it's hard to stay up to speed and it's hard to stay on top of what is happening, to have a shared understanding within an organization. The pressure is coming from all directions. Externally, you need to keep your market share, you need to stay competitive against other people in the business trying to surpass you with their services. And internally, you probably have a CEO that says, like, do something about AI. We need to do AI, more AI. And in addition to that, you also have your developers that go ahead and do shadow AI because they feel like you are not moving fast enough with your decisions and with your policy and telling them how to work. So they use their own code or their own copilot or whatever tooling that they want to use. In addition, security team is starting to get really upset because suddenly they can't control anything. If you are also working in some sort of compliance sort of business, like finance, defense or whatever or healthcare, then you probably also have all those things to consider. And suddenly AI is affecting and changing all of that.

We are already doing more things. From the GitHub Octaverse report, where they look at all the public repositories and they try to summarize and do an average monthly summary of the developer activity, and they're looking at issues closed, pull request merged and code pushes. And what we can see is that across it all, it's roughly 25% increase on a monthly average between 2024 and 2025. We're already doing so much more. So we're at risk of failing at machine speed because it's moving fast and we are not reacting fast enough. And the risk is that we have unintentional fragmentation. And the solution is that we do intentional strategy and we invest into internal developer platforms.

When I say your platform matters more than ever, I mean with agentic AI because we moved past code completion, we moved past the chat suggestions and we moved past the explain this code part of things. If you are still there, I feel for you, but that's not what I'm talking about in this session. In the last seven months, it has changed a lot. We're moving from writing code to orchestrating change. If you are the type developer or if you're working with the type of developer that got the refined task, and then they sit down and implemented it, and then they dropped it off to someone else, that is disappearing because AI can do that now. You need to adapt and you need to change and you need to focus on how you can drive that change rather than just implementing the code.

The trend is that output is increasing. I'm not saying value. Mind you, not value. Output is increasing. This means that every developer has more code that they manage or that they are responsible and accountable for. If we look at the Git pushes on GitHub, once again, part of the public dataset, summarized by quarter since 2020, we can see a fairly clear increasing trend. And some numbers if you can't read it because I know it's very small is that in Q4 2024, we had 168 million. And in Q4 2025, a year later, it was 247 million pushes. In Q1 2023, the AI first IDEs were launched such as Cursor. In Q1 2025, the first more like multi-step agentic behavior type of model was released in 3.7 Sonnet. In Q4 2025, it's already Q4 2025, six plus months back. Opus 4.5 was released. The reason why I mention it is that when 4.5 was released, a lot of companies were starting talking about, I'm not working in the IDE anymore. I'm just integrating with cloud code or whatever. So this is basically when developers stop caring about the code itself.

I'm just integrating with cloud code or whatever. So this is basically when developers stop caring about the code itself. The reason why this matters is because Q4 2025 is six months ago, and that was the last public data point I could find when I was looking. Research is looking back, but the future is unknown. And we need to take and work with this situation because if we base our decisions on what other people were doing six months ago, we will be lagging behind six months against our competition. So when we are building a strategy, we need to address the unknown. But we can also figure out what do we actually know? Because not everything is unknown. We have a few things that we actually can know for sure. And we can know that each developer will be responsible for more code as we're writing more code.

I hear a lot of stories about, oh, we built that thing that would previously take us two months, now take us two days to write code for. And so we are pushing the bottlenecks. Previously the code was the long term part where you spent a lot of time. But we're pushing that both upstream and downstream right now. So suddenly we are pulling more things from the planning and refinements and design cycles, and we are not doing those activities fast enough in order to sustain an active development flow. So we're also pushing the bottleneck further down. I hear a lot of people talking about code reviews, how merging your code is actually something that goes very slowly. And I heard about increased load in CICD pipelines and how they can't really keep up and how suddenly you are like it explodes in the amount of money you're spending and CPU resources you're spending on just building and maintaining software.

Another thing that we can know for sure is that models are stochastic by design. There will be randomness. It's by design how they work. They will try to statistically predict what is a good next step after the thing that I've done here. That means that without any sort of assistance, sorry, without any sort of added pressure, we will create fragmentation, and it will start diverge because if you run the same prompt twice, you will get two different answers. And like multiply this with all your developers and all the work they're doing, suddenly you can get something that is looking quite different from each other's. And we know that the codebase will start to be fragmented unless we actually do something about it. We can know, or at least I can claim, and you can reason about it, that a fragmentation codebase will push and explode that fragmentation across your whole systems. Because as someone that has worked a long time in platform engineering, one does not simply introduce a new programming language into your systems. Because suddenly you have to fix libraries, you have to fix binaries and runtime, and oh, by the way, all these nice runbooks that RSRE has helped us write, they're no longer valid because these things work differently. And the systems, if you're on prem, you bought CPU and Rome and stuff, and now suddenly you're not using the same type of capabilities that you were using before because suddenly everything changed. And so, with a more complex fragmentation in your codebase, we can deduct that the rest of your underlying systems will also be more fragmented and a much more complex system. So, to summarize, we know output will increase.

Output, not value. We know that fragmentation is the default of LLMs unless you do something about it. And we know that fragmentation will increase complexity in your systems. The good thing, we already addressed this with IDPs or internal developer platforms. Back in the days when the internal developer platforms were introduced, it was introduced as, I would say, a continuation on DevOps. We knew that we wanted people to take more responsibility and be more involved in the full application lifecycle. But we also knew that there was a lot of things to know about. There was a huge cognitive load for developers and we wanted to reduce that. So, we introduced internal developer platforms in order to solve the common needs that developers had.

If it were, once again, in a compliant heavy organization, maybe we also wanted to codify constraints that we knew that we needed to have on our systems, maybe make it easier for an audit review, whatever it might have been. All those things we made happen into internal developer platforms. Another important part about it is, I'm not sure what organizations you've been in, but I've been in this type of organization where, if you were a developer and you wanted to do something new, maybe you wanted to launch a new application or get a new DNS registered or whatever, you had to file a ticket, send it up to whatever team was responsible and wait for them to do it. Part of doing internal developer platforms is the idea of making sure that it is self-served, so that you are non-blocking. You don't have the manual human steps in between. That is something that we are talking about a lot and a lot we're designing for when we're talking about internal developer platforms.

So, to some extent, it is the same problems, but it's a bigger blast radius because, as we talked about before, the output has increased. So we're doing more, we're making more changes, and it creates a load on the systems that we already have. If you have some of those manual steps still in your organization, you would probably feel a lot of pain about that right now. If you automated a lot of it before, congratulations, you're in a good position. Something that I really think you should take away from this slide that is not as well highlighted as it should have been is the mirror effect. And that is AI amplifies what is already in place. If you have something in place, be it a shitty architecture with a lot of different tool sets and a lot of different ways of solving the same problem, that is what is going to be amplified. If you have a clear paved road and a clear single way of doing things, that is what's going to be amplified. So, take that in mind and bring that back home. I think another important thing is that when we build internal developer platforms, we did it for the developers to reduce their cognitive load, but now we're also building developer platforms for agents. So it needs to work both with humans and both for agents. Because whenever someone breaks your agent workflow, you still want your human to be able to do the thing that they need to do in order to fix it. So you can't lock out humans just because you're catering for agents. It needs to work for both. And so, as tech leaders, what you need to do is that you need to define a technical strategy that is adaptable.

Because as I said, we are in an era with a lot of unknowns, so you need to design your strategy to handle those and cater for those unknowns and be able to change when you learn something new. So it's important that you are able to have a strategy that is not locked down to what the models look like today. Because two days ago, Anthropic released a new model that is game-changing to a large extent, and it's moving very fast. So if you lock down something, like a strategy, to how you think you're doing today, you will have to change that very fast.

You also need to communicate, and I can't push this enough. If you want everyone in your organization to be able to deliver on your strategy, everyone needs to be aware of it. And if you think that it's enough to tell someone once and have it written down somewhere, then you're wrong, because that's not how people work. And people are still the people that need to make decisions and drive things forward. Because AI is not intelligent. It's just very productive. So without you humans telling them where to go, it will not work out.

So communicate often and ensure that the information is available for everyone. But also, once you do that option, because you need to adapt your strategy, ensure that you communicate that as well. And it doesn't have to be a failure. Maybe something went wrong, or maybe you learned something new, and you could take a new direction that will help you deliver even more value for your company. So be transparent about the pivot vote, and be transparent of why this is happening, what you learned, and how you will progress from here. And that should be part of your strategy and how you work.

Your internal developer platform should support your strategy. This is where you codify and execute on your strategy. The strategy is like a direction of where you want to go. The platform is what supports and helps people moving in that direction, going in that. And I think there are, in addition to a lot of other things that we already have in internal developer platform. I'm not saying go get rid of your CICD pipeline from internal developer platform. No, you should probably still do that. But in adapting to AI and identity behavior, I think there are three things that is worth highlighting and mentioning, and there's probably more things.

But one of them is the golden path. This is how you build your things. The second one is context. What does the agent need to know in order to be able to deliver value? And the third is agent practices. And this is probably falling more, if you're following the team topologies, it's probably falling more under the enablement than on the platform. But I think it makes sense to put it close to that function at least. So bring that in mind as well.

So the paved road or the golden path is this idea of this is how we build systems in our organization. I've been working in a few different organizations. I've spoken to a lot more people from other organizations, and what I've learned is that no one is doing the same thing in the same way. No one. Everyone has their own flavor. Probably the larger tech gear organization, the more specific flavor it is. I think it's good to kind of try to lean more towards open source and follow open practices and whatnot. But truth be told, you probably have something very specific for you. So know what your golden path is.

Know what you want your blueprint for an application to look like. If you're a technical leader, it's probably not, maybe not you only, but it should be part of what you know when you build these things. A context is what allows your AI to follow the golden path or your paved road. And this is, there's probably other people that have a lot of things, but I try to capture some of them. I think mentioning mentioned earlier today is like closing the feedback loop.

A very concrete example that I've heard of that helped people to really close that feedback loop is a linter. If you codify, we don't write shit in TypeScript and add that to your linter so it just fails whenever it tries to build locally. Great. Now you have a very quick feedback loop to stop your AI from trying to write everything in TypeScript. That's great. That's part of your strategy, maybe. Or it could be Python or whatever you want.

And those quick feedback loops are really good and something that you should try to focus to get into. But also remember that your existing code is part of your context. I go back to once again, if your existing code is not great, that is going to be hard for you. If you have great code, it could be in a monorep, it could be in polyrep, I don't think it matters. Make it available to your AI in some way. Maybe make sure you have it cloned locally and have it available as a live context or make it searchable in some way. And integrate all these things.

But when you're working with context, also make sure that you are not giving the AI too much context. That's why we need to make it intentional as well, because if you just bloat it with everything, it will lose effectiveness. I also think that setting, when it comes to agent practices, we need to set boundaries. I've heard of companies that just said, oh, here's the company card, go buy yourself an AI license. And I heard of other companies that are like too afraid to let loose their developers at all. I think there's some middle ground, but I think a governance where you make sure that you don't leak your internal data to the provider is probably a good thing. So make sure that you're looking at your boundaries. It could be data, it could be access, whatnot. Maybe you don't want to give AI right access to production. Maybe it should have read access, whatever it might be. Have that centralized tiered as a part of your platform.

And make sure that you increase awareness and learning and spread it across the organization, because you might actually have like the 5, 10 people that are super excited and they're trying out so many things. They're failing a lot, but they're also learning so many things. And ensure that you get that learning back to the rest of the organization that might not be as excited, but willing to learn and pick up. And ensure that you bring everyone with you.

And once again, like models will change. Don't overfit. So in short, as output increases, cognitive load must decrease. And we do that through less variability, stronger defaults, and just-in-time context. And the complexity of systems must go down as volume of code goes up. Have an intentional strategy. Utilize your platform to execute on it. And you will accelerate and secure your systems.

Call to action, three things I want you to do on Monday. If you haven't already, maybe update again. What is your AI stance? Communicate it. Ensure it's clear and visible for everyone. Like make your internal context AI accessible. And invest into a quality internal developer platforms, because it will pay off in the long run. Because internal developer platforms are the foundation for succeeding in AI era.

I'm Jessica. I'm a Fractional CTO and Platform Engineering Leader. And this is a QR code with links for the resources I used in this presentation. Thank you so much for having me. First of all, great set of recommendations, examples. And what's really good, for example, if you talk about this apply deterministic context controls, policies, everything that contributes at least two directions, two levels. Agent quality, like what it gives you as output. And also cost. So this is also a huge, huge cost driver. How well you instrument your code base, your project with deterministic controls. Like you mentioned, linters, type checkers, everything. So keep this in mind, folks.

But now, your questions. The first one is, generative AI is increasing engineering speed, but we don't know its long-term impact on code quality. So should leaders optimize for maximum cost reduction or shortest time to production or take more conservative paths towards sustainable software? What are your thoughts? I mean, obviously, it depends. It's the most boring answer ever, but it totally depends. If you're working in defense or maybe like airfield coordination things, maybe you want to go for security or like ensuring that you always maintain same operability. But if you are exploring a new area with something very non-dangerous, then maybe you want to optimize for speed. I personally have been on call and I really don't like being woken up at 2 a.m. So whatever you do, don't page me at 2 a.m. and maybe don't page your developers either. So I think there has to be... It's a new time cost quality triangle thing we need to take into consideration. Maybe not all systems are equal value. Maybe you have some critical systems. Be more careful with those. And then with the less critical systems, try to be a little bit more wild and crazy and see where that takes you. Be adaptive, right? Be adaptive, yes. Don't be fixed. Don't fly.

One rule does not fit all. Fixed mindset that really... What hurts? Gross mindset. That's your target. So let's mark this as none.

And artificial intelligence is great for creativity. User experience for juniors can create the backends or people who are like designers and user experience folks. But they can't code. They can't code backend. And sometimes it looks bad and creates more fragmentation. If not, review overload.

How to address this but still keep the benefits and velocity? Yes. I believe that we could take it more general. What are your thoughts about allowing non-developers to contribute to... Not just one-shot, one-time tools, but to something that could be more prominent, more... And should be scalable and safe and secure. What's your take on that?

Coming back to the paved road and golden paths. If you're already building scalable, secure applications with a clear API-first mindset and whatnot, you probably have that both codified in your existing applications. But you also maybe have your context available. Maybe you have... This is how we do APIs. This is how we do scalable applications. This is how we manage the large-scale workload, whatever.

And that will be part of the context that the AI uses when they write that code. And if that context is available for a non-backend developer, they will also be able to write a good backend service. But you need to have the foundation in place in order to make that happen. And that's where you put your senior developers, senior backend developers. They should be working on making that available for everyone so that you can bring more people into the development. In my opinion.

Yeah. Fair enough. 100%. From my experience, I currently work with two customers that create specific platforms. So we can call it platform engineering in its classic sense for simplifying what happens next with the tools created by non-software engineers. Because they require maybe a bit more attention. And folks, surprise, surprise. This becomes just more generic application platform that is equally relevant both for non-developers and for developers. So in that sense, there is not too big change, too big disruption. This is from my personal experience. And of course, yeah.

Investing in your development platform always pays off. And let's take this one. I want my team to incorporate more AI and our AI deployment product into internal use cases. How do I negotiate with my engineering leaders to dedicate resources to that? Yeah. So there is a kind of resource bandwidth exercise, internal versus external. And in that sense, platform engineering looks like, oh, it's very internal, right? So what's your take on that? How to convince? I mean, it's, in my experience, always hard to convince anyone to invest into your internal developer platforms.

I think something that I've said before, the AI era, that I think it can be used as a motivator of why it's worth it, is if we're looking at the DORA metrics, and I'm talking about the Accelerate DORA, so you have, how long does it take to drive out, to get out a change? How long does it take to build a type of software? How often does it fail when we are deploying new software? And how often, how long does it take before we can do a recovery? Using those metrics, you can show that when you invest into your platform, those metrics can improve as well. And that can be your indicator and your motivator for why this is important. But I also think if you invest into your internal developer platform in the AI era, and you can show that you can make it available and safe to use and experiment for non-developers, I think that could be a good motivator as well, because there's a lot of organizations right now that are not looking for AI adoption in their software development departments. They're looking for AI adoption outside of the R&D departments. They're looking to get it into the finance operations, they're getting it into HR and all the other departments to make it more efficient and to utilize that type of tooling. So if your internal developer platforms can support that type of use cases as well, I think you will be able to get more investment from across all the C suites.

Super insightful answer. And I think the keyword here is investment, right? It's not spend. So it should be your profit center, not cost center. And who knows, by the way, folks, there are enough, if not pivots, but at least very public stories about a company built their own developer platform, and it was that nice and that popular, so they just open sourced that and if it didn't become a new revenue stream, at least they get lots of extra attention from the developer crowd. I mean, from a top of mind example, it's backstage from Spotify, right? So it's a classic example here. And yeah, we have time for more questions. That's amazing. And this one got five thumbs up.

Should AI review AI code? Use multiple models or stick with just one? Basically, two questions in one. AI reviewing AI and your take on AI models? I think it comes back to criticality of systems. I think in general, it's not a bad idea to utilize more AI in the feedback loop and ensure that you are getting a new model, a new context reviewing whatever code was written. Maybe with some other requirements. I'm not sure about like, I've heard everything, like you should use the same model, you should use five different models, you should have them with a different mindset and different guidelines, whatnot. I think you have to trial and error. And I guess the best way is to get a few things going, and then I have a human review of the code and then maybe make their own review. Whatnot. This is still a learning phase. When people say that they figured it out, they're probably lying. Yeah, in that sense, we all learn, we all try to accumulate and share best practices and just pieces of knowledge, in that sense. So from my personal perspective, AI might review AI generated code, but for sure, it should not be the last party who is taking decision, right? So we need something a bit more deterministic or human in the loop. Unless it's not important. And that's true.

And yeah, let's let's take maybe last question. And it will be this one, also quite popular among our audience. What components of software development pipeline should we more or less standardize and what part should we keep flexible? I mean, all of them. Like, why not standardized? We like boring technologies, don't we? I mean, joking aside. I'm actually all for standardizing everything as far as you can. But I also believe in leaving room and flexibility for experimentation, because sometimes it's actually worth overhauling something. And you need to have the space and the ability to do that type of experimentation that might mean actually bringing in a new programming language.

But what I do think is before you turn that into something that runs in production and that you fully adopt, you need to really evaluate it and be critical about. Is it worth breaking our standardization in order to do this move? What does it buy us short time and what does it buy us long term? What will be the cost of this move over time? And and so, I mean, I'm super boring. I like standardization. Every time I work with developers and they go like, I came up with something new, I go like, oh, no, oh, no, not again.

And it's sometimes I say it as well. It's not good to say it, but that's what happened. Yeah, exactly. Exactly. And also it might be a bit of a definition juggling, right? Because in the big picture, standardized doesn't mean somehow restricted. Let's say standardized still could be flexible. So it's not obligatory, kind of hard coded. Right. So standard could be, say, we have standard that is flexible standard. It might be like unless you have a really good use case for why not doing this, then you should probably be doing this thing that is the standard. Exactly. Thank you so much, Jessica. Thank you so much for having me. Let's give a big round of applause to Jessica. Thank you.