Imagine you can double your speed with a push of a button. A magic button shows up at work, you are the boss, you press it and magic, twice as much gets done on the day.

AI as an amplifier

This is the promise of AI: do more, do it faster, like magic. I read books, papers, blog posts about how you can just do speed up. They all seem to come from some wonderland in which stability is not a problem, there is no tech debt, and none gets introduced at double the speed. There are also no system problems. It makes me wonder where those amazing organisations exist.

Capacity is always a constraint and you need to decide what to do with it. Let’s for a moment assume that there are no new unexpected problems coming from just speeding up just one area of work. Just an unconstrained “times two”. What does it even mean?

Velocity

Getting 100% capacity in and 200% output out is what I would refer to as amplifying velocity. You operate in whatever operating system your organisation has picked, you address no observed problems. There are definitely organisations where the greatest bottleneck is the capacity to make things. They will feel the wind in their sails.

But there are places where it was never the bottleneck, and in many ways that fact was the saving grace for the organisation. If work in progress piles up it creates different problems. If the direction used to be worked out while iterating on the code, current faster outputs might increase the drift. If writing code was where understanding was built, who understands what the system does, and how?

More output doesn’t mean better output. There will be new bugs, and if there are costly patterns in the code, they will become even more entrenched. New bottlenecks will be identified in the process where they weren’t visible before.

So while increasing velocity can create more output, this is not the only thing you can do. What if you instead save some of the capacity to do something else?

Acceleration

Let’s say that we preserve some of the capacity and look around. There’s a flaky test. The primary CI pipeline takes 90 minutes to complete (and flakes). Nobody knows how to troubleshoot the flakes except for the two QAs that are on parental leave. They would dig into logs, recreate the problem in their heads. One flake is a stale element in the end to end test, another is typical to the test environment only, and only when the tests run in a specific order, the last one is a genuine failure that happens 15% of the time. These are usually things that are not considered as important as the product features that we never have enough time to deliver.

Removing friction in the existing system may seem like low value work that gives a one-off benefit and then it’s done. In reality however it unlocks something significant. Allen Helton described it really well when he wrote about the Valkey project ^[2]. Tiny improvements delivered over a longer period of time were invisible on their own until they started to compound. They aren’t as attractive as the big features internally, and you will likely not have a press release talking about them.

Most examples I shared were internal problems but they don’t have to be tech debt. A customer might complain once about some mildly annoying behaviour, or a different way the same information is visible in two places. This category of issues will not be a significant unlocker, and it will not increase your margins, but fixing tiny pains around the edges might make your users so happy about being seen and heard that they may be much more patient when waiting on the big things.

I see this type of work as the acceleration: you eliminate waste, you change the perception, you replace the friction with gliding. The effects are always delayed, but instead of a one-off jump you unlock recurring benefits. You may not get twice as much done immediately, but you might then see three times as much, and more.

And we’re not even done yet.

Time derivative of acceleration

Acceleration changes your velocity from a flat line to a slope. Its derivative makes the velocity line steeper (when it’s positive) or flatter (when it’s negative).

There are limits of what you can improve within the existing system, you can pretty much have a perfect operation within the current limitations. The attention can instead turn to the system itself. How does it work? Can it be changed? Will change unlock new rules and capabilities?

Dig deeper. Perhaps the issue is not with the time to build but with all services in the system relying on one database schema, and the owning team will not prioritise versioning it, so everybody needs to work off the latest commit in the monorepo? Perhaps your release process forces all the changes of the month in bulk into a deployment, and your engineers need to wait two months for their change in front of a customer, and this means they lose interest in the results the second their PR gets merged into main? Perhaps resilience is understood as rewarding the firefighting, so nobody tries preventing the fire?

Or maybe everything is just fine. Not fast, but known and stable. Who would want to change it to make things faster? Competition is slower than us. Customers think changes once a quarter are breakneck speed. It’s already so much faster!

The second velocity is even more delayed in impact than the acceleration. But just like acceleration keeps increasing the velocity, here the acceleration increases. When you change the system, some friction vanishes but previously desirable behaviour may now become friction. Some of the acceleration will have to be sacrificed to solve that. It requires a lot of energy to set in motion, and intent, and readiness to solve the new inefficiencies.

This is hard. It requires even more capacity to make a difference. Engineers need to pause and think. Engineering managers need to make space. VPs, CTOs, chief architects need to shake things up, teach everyone to learn and to be curious, challenge the system that may not be broken. Change will create resistance, confusion, frustration. The systems will fight back.

The effects are for the long game, and those who play it might not see them during their tenure. The impact is visible in much smaller amounts at first, but they compound, and overtake those who went for the immediate and more limited.

Not making things worse requires effort

As you build a living system, even using best practices, you will accrue technical debt - this is unavoidable. Requirements will change, standards will progress, dependencies will have bugs, reality of your service will shift, people will leave, and new people will join. Culture will evolve.

A colleague I worked with told me how he usually dealt with bugs and issues by offering a work bundle: a quick bleed stopper followed by a proper fix. If an organisation is struggling with capacity, for instance if the pace of work is unsustainable, proper fixes usually aren’t delivered. It may be the smart decision over some period of time but can become a source of degradation of the engineering quality if it stays as a standard. Adrian Hornsby covers this in depth in “Why We Still Suck At Resilience” ^[3] - the organisation may make their tests safer and less likely to fail, it may sacrifice learning for efficiency, and keep doing it over and over again, moving away from resilience and towards theatre. The consequences will not come immediately, and likely will be too far from the change to link the two with each other.

Reducing the discipline can come from making choices as much as from not making them. Regardless of the reason the velocity is not constant over time, and without effort towards maintenance and resilience it’s on a downwards trend.

Why this matters more than ever

We’ve been given tools that amplify our work, and so have our competitors. Code isn’t a business protection, it isn’t a competitive moat anymore. A legacy competitor might have just started investing in steepness of their acceleration. If you don’t strengthen your compounding effect, someone might be preparing to overtake you in a way you won’t be able to easily fix.

Software engineering feels largely like the Wings for Life World Run - instead of a finish line there is a catcher car which starts with a bit of a delay and ends a race for people the moment it catches up with them. You can put all the energy into running fast on the day of the race. Or you can practice before the race and be able to run for longer. Or you can learn better technique, get better shoes, use better nutrition and hydration. The finish line will keep chasing you, you control what you can do about it.

Where you amplify matters more than how hard you amplify. AI can make today’s work faster, remove constraints around that work, or change the system that decides what outcome is possible.

How to view velocity, acceleration and its time derivative

Have some fun with the chart below. You have three sliders to control where the 100% of your capacity goes. The baseline for each of the functions that the sliders control is -5% - if you do not allocate time to it, it will affect your outcome capacity in its own way which may compound. These are deliberately simple models which show the shape of each choice, not a forecast:

1. Amplify velocity. Keep the system unchanged, put capacity into familiar work, don’t address the tech debt or friction. After a short adoption delay, velocity jumps once and settles at a higher constant level.
2. Amplify acceleration. Spend capacity removing friction and unreliability. The return starts later, but velocity keeps changing instead of settling - same capacity leads to increasing outputs over time.
3. Amplify time derivative of acceleration. Pause, look around, name the systems, challenge them. Maybe migrate. Maybe change the approach. System redesign has the most inertia; eventually the rate of improvement also improves at a constantly increasing rate.

You have 100% of your capacity. Move any slider and the other two rebalance so the total remains 100%. I guess I could’ve allowed something like “give the time back to the people” - but that really is the derivative of acceleration. Anyway, allocating 0% creates a −5% drag, 5% is neutral, and 100% produces a +95% effect.

Oh, and there is a line that sums up the remaining three.

(The visualisation has been created using AWS Kiro as the code generator)

Recap

You can put your capacity into three types of buckets:

• immediate delivery
• resolution of problems in a current operating system
• improvement of the operating system

There’s time and place for each one. Be mindful that locking in strictly on short gains may just create an illusion of progress that will be eaten by the costs of neglecting the sustainability and resilience. The promise of AI can sound like the ultimate solution, and maybe one day it will be. Right now however it makes us faster at imperfection, and imperfection accumulates.

Thinking in systems, engineering excellence, and building resilience, are the strategies that help you find a balance that will help you tip the acceleration odds in your favour.