Faster Software Doesn’t Automatically Mean Better Software

11 hours ago

5 min read

Software development has spent the last decade getting faster. Release cycles that once took months can now happen continuously, infrastructure can be provisioned in minutes, testing and deployment can be automated, and AI coding assistants can produce working implementations before a developer has finished describing the problem.

That progress is real, but it has also changed where the difficult part of software development sits. Writing code faster does not automatically mean delivering better software faster, because every new service, dependency, environment and tool eventually becomes something that has to be tested, monitored, understood and maintained.

That was one of the ideas that surfaced throughout Eric Deandrea’s session at Bucharest Tech Week 2026. The Java Champion and Senior Principal Software Engineer at IBM used microservices as the starting point, but the conversation quickly moved into a broader engineering problem: what happens when architectures designed to increase speed also increase the number of things teams need to operate reliably.

It is a shift Eric has also seen in his own work across nearly three decades in software engineering. In the written interview he gave us ahead of the event, he described the biggest change in his approach this way: “Honestly, the biggest shift has been moving from just writing code to really thinking about who's going to use it, how easy it is to test, and how maintainable it's going to be.”

Faster delivery creates a different kind of complexity

The original case for microservices was closely tied to speed. Large applications made teams dependent on one another, releases required coordination across entire organizations, and shipping a relatively small change could mean waiting for the next major deployment window.

Breaking those systems into smaller services offered a way out. Teams could own different pieces of functionality, deploy independently and move at different speeds, while the business could release new functionality more frequently.

Eric described that pressure directly on stage, explaining how expectations shifted from long release cycles to businesses asking engineering teams to deliver every few weeks.

https://www.youtube.com/watch?v=8FeYhhvtnA0

The trade-off appears once those smaller pieces begin multiplying. A service that can be deployed independently also needs to be tested independently, monitored independently and understood in relation to every other service it communicates with. As Eric put it later in the session, “The more things you create, the more things you have to maintain.”

The same tension is beginning to show up around AI-assisted development. Google Cloud’s 2024 DORA research found that greater AI adoption was associated with improvements in documentation quality, code quality and code review speed, but those gains did not automatically translate into better delivery performance. In the same dataset, increased AI adoption was associated with lower delivery throughput and stability.

The point is not that faster coding is undesirable. It is that the performance of one part of the development process cannot be separated from the system around it.

The work users never see

This becomes especially visible in the distance between an MVP and software that is expected to operate reliably at scale.

A user sees the interface and the features that work. Engineering teams see everything underneath them: security, infrastructure, deployment pipelines, monitoring, resilience, dependencies, testing and the technical debt that accumulates when any of those areas are postponed.

Eric described that gap in our pre-event interview: “The UI is just the tip of the iceberg. There is a significant gap between an MVP and enterprise-ready software. The hidden 90% is where the real work happens: architecting for security, scalability, and long-term resilience.”

That hidden work is also where many of the productivity gains promised by new development tools can disappear. Atlassian’s 2025 State of Developer Experience research, based on 3,500 developers and managers across six countries, found that 68% of developers reported saving more than ten hours per week through AI, while 50% were still losing more than ten hours each week to friction elsewhere in the so ftware development lifecycle, including finding information, adapting to new technology and switching between tools.

A team can therefore become much faster at producing code without becoming equally faster at delivering reliable software.

This is where automation becomes less about convenience and more about keeping complexity manageable. In his session, Eric described the maintenance burden that appears as systems grow and why building automation early changes what teams are able to focus on later.

https://www.youtube.com/watch?v=JOmJ8xtQBfw

When speed starts to replace understanding

AI raises the same question from a different direction because it can dramatically reduce the time required to produce a first version of the code.

A 2025 METR study tested 16 experienced open-source developers across 246 real tasks in repositories they already knew. Before the experiment, the participants expected AI tools to make them 24% faster, and after completing the tasks they still believed they had worked around 20% faster.

The measured result, in that particular early-2025 setting, was the opposite: developers took 19% longer when AI tools were available.

The study is limited to a specific group of developers, tasks and generation of AI tools, and METR has since noted that newer systems are likely producing stronger productivity gains. What makes the result interesting here is not whether AI makes developers faster in every situation, but how easily perceived speed and actual productivity can diverge.

Eric makes a similar distinction between using AI as a useful development tool and allowing speed to replace understanding. In our written interview, he described how dramatically the tooling has changed across his career, from writing Java in a basic text editor to using assistants capable of generating working code almost immediately, but argued that the responsibility around that code has not moved with it: “The real skill hasn't changed though: you still have to understand what the code is actually doing, whether it's solving the right problem, and whether it'll still make sense to a human being three years from now. That judgment is still on us.”

The same principle shapes where he believes AI belongs in a system. In his view, it is particularly useful when inputs are unstructured, answers are ambiguous or value comes from synthesizing information across multiple sources, but when a problem can be solved deterministically, adding AI can introduce additional cost, latency and testing complexity without necessarily improving the outcome.

What should teams optimize for?

The history of software engineering suggests that every major increase in speed tends to move complexity rather than eliminate it. Microservices made independent deployment easier and increased the importance of observability and distributed systems. Cloud infrastructure made provisioning easier and increased the importance of operating that infrastructure reliably. AI is making code easier to produce, which may make architecture, testing and maintainability even more important.

That does not make speed the wrong goal. It means speed needs a wider definition.

The useful measure is not simply how quickly a team can produce the next piece of code, but how quickly it can move from an idea to software that remains secure, understandable and maintainable after the first release.

And that is probably the more interesting question for engineering teams now: as the tools around software development keep getting faster, which part of your own delivery process is still slowing everything else down?

Writing the code, testing it, deploying it, understanding dependencies, maintaining it afterwards, or something else?