AI coding assistants now generate thousands of lines of code per day. Engineers ship faster than ever. And the question “do we need unit tests?” has taken on an entirely different dimension — because the entity writing your code isn’t always human anymore.
My answer, seven years later, is more emphatic than before: yes, you need unit tests. And in the AI era, you need them more than ever.
Let me briefly revisit the original case, because the fundamentals haven’t changed.
Consider a system composed of three simple operations:
S(a, b) => mul(sum(a, b), sub(a, b))
where:
sum(a, b) => a + b
sub(a, b) => a - b
mul(a, b) => a * b
High-level tests check the final output:
S(0, 0) == 0 // (0 + 0) * (0 - 0) = 0
S(0, 1) == -1 // (0 + 1) * (0 - 1) = -1
S(1, 1) == 0 // (1 + 1) * (1 - 1) = 0
Now introduce a bug — change sum(a, b) from a + b to a + 1. Every system test still passes:
S(0, 0) == 0 // (0 + 1) * (0 - 0) = 0
S(0, 1) == -1 // (0 + 1) * (0 - 1) = -1
S(1, 1) == 0 // (1 + 1) * (1 - 1) = 0
The bug is invisible at the system level because the test inputs happen to mask it. A unit test for sum would catch it instantly. This principle scales: the more units you have, the more likely a high-level test will miss a localized defect. Real systems have thousands of units. A 1:1000 ratio between system tests and code paths is generous.
This was true in 2019. It’s true in 2026. The math doesn’t care about technology trends.
Here’s what’s fundamentally different now. In 2019, humans wrote both the code and the tests. The common complaint was that writing unit tests doubled the workload. ”I could be shipping features instead of writing test cases for obvious logic.”
That argument is dead.
AI coding assistants — Claude Code, GitHub Copilot, Cursor — generate code at a pace no human can match. They also generate unit tests. The cost of writing tests has dropped to near zero. What used to take an afternoon now takes minutes. You describe the behavior you want, and the AI scaffolds comprehensive test suites that cover happy paths, edge cases, and error conditions.
But here’s the twist that most people miss: the lower cost of generating code makes verification more important, not less.
When a human writes a function, they hold the full context in their head — the business requirement, the edge cases they considered, the trade-offs they made. When an AI generates a function, it’s making statistical predictions about what code should look like given its training data. It’s usually right. But “usually” isn’t a word you want in production.
I’ve seen AI-generated code that looked perfectly clean, passed a code review, and hid a subtle off-by-one error deep in a loop condition. I’ve seen it produce correct logic for 99% of inputs and silently corrupt data for a specific combination of null and empty string. These aren’t hypothetical scenarios — they’re Tuesday.
Unit tests are the verification layer for AI-generated code. They’re the contract that says: regardless of who or what wrote this function, here’s what it must do. Without them, you’re trusting a probabilistic system to be deterministic. That’s not engineering — that’s gambling.
In 2019, I argued that unit tests serve as documentation. That was true but somewhat academic — most teams had developers who knew the codebase intimately enough that reading tests for understanding was optional.
In 2026, the documentation argument is critical. Here’s why.
AI-assisted codebases grow faster than any team’s ability to hold them in their heads. Engineers context-switch between multiple services, often inheriting code that an AI generated in a previous sprint — or that a colleague generated with an AI and didn’t fully review. The codebase is increasingly nobody’s code.
When you pick up a function you’ve never seen and need to understand what it does, what do you reach for? The implementation might be 50 lines of dense logic. The commit message says “Add processing pipeline.” The PR description is AI-generated boilerplate.
But the tests? The tests say:
it('returns empty array when input is null', ...)
it('excludes items with negative quantity', ...)
it('applies discount before tax calculation', ...)
it('throws when discount exceeds item price', ...)
That’s a specification. It tells you exactly what the author intended — edge cases included. In a world where you can’t always ask the original author because the original author was an LLM, tests are the closest thing you have to a source of truth.
I’m not a unit test absolutist. There are situations where they provide little value, and pretending otherwise makes the whole practice feel like cargo cult engineering.
Thin wrappers and pass-through code. If a function does nothing but call another function and return its result, testing it is testing the language runtime. Skip it.
UI layout and styling. Does this button render 20 pixels from the left edge? That’s a visual regression test, not a unit test. Tools like Playwright and Storybook handle this far better.
Glue code in rapidly changing prototypes. If you’re in discovery mode and the code will be rewritten three times in the next two weeks, investing in comprehensive unit tests is waste. Write a few smoke tests, move fast, and add proper tests when the design stabilizes.
Pure integration logic. Sometimes the interesting behavior is the interaction between components — database queries, API calls, message flows. Unit-testing these with mocks can create a false sense of security. If your mock says the database returns [{id: 1}] but the real query returns [{id: 1, deleted_at: null}] with an extra field that breaks your deserializer, the mock won’t save you. This is where integration tests and contract tests earn their keep.
The key insight: unit tests excel at verifying logic — branching, calculations, transformations, state machines. They’re weak at verifying interactions. Know the difference and test accordingly.
The traditional testing pyramid — many unit tests at the base, fewer integration tests in the middle, a handful of E2E tests at the top — was designed for a world where tests were expensive to write and slow to run.
Both constraints have loosened dramatically.
AI generates tests at every level almost equally fast. And modern tooling has made integration tests much faster than they used to be. Testcontainers spins up a real PostgreSQL instance in under two seconds. Playwright runs a full browser flow in milliseconds. The infrastructure excuse for avoiding higher-level tests barely holds anymore.
What’s emerging in practice is more of a diamond shape:
This isn’t a rejection of unit tests. It’s a recognition that not all code benefits equally from them. The business logic layer with complex branching? Unit test it heavily. The CRUD controller that maps an HTTP request to a database query? An integration test is more honest about what can actually go wrong.
Here’s a practice that was niche in 2019 and deserves far more attention in 2026: mutation testing.
The idea is simple. A mutation testing tool takes your code, introduces small changes (mutations) — flipping a > to >=, removing a return statement, replacing true with false — and runs your test suite against each mutant. If your tests still pass after a mutation, they’re not actually testing that code path. The mutant “survived,” and your test suite has a blind spot.
Coverage metrics tell you which lines your tests execute. Mutation testing tells you which lines your tests actually verify. Those are very different things.
Tools like Stryker (JavaScript/TypeScript), mutmut (Python), and pitest (Java) are mature and practical. Running them on your most critical modules — even quarterly — reveals exactly where your test suite is theatrical rather than useful.
This matters especially for AI-generated tests. An LLM will happily produce a test suite with 95% line coverage that catches almost nothing, because it optimizes for the superficial pattern of “code that looks like tests” rather than the deeper pattern of “assertions that constrain behavior.” Mutation testing catches this.
Test-driven development — write the test first, watch it fail, make it pass — was already controversial in 2019. In 2026, it’s been reshaped but not replaced.
The classic TDD cycle assumed a human writing both tests and implementation, alternating in tight loops. With AI, a more effective pattern has emerged: specification-driven generation.
You write the tests first — or more precisely, you write the specifications as tests. What should this function accept? What should it return? What are the error cases? Then you hand those tests to an AI and say: make these pass.
This is TDD on steroids. The AI generates an implementation that satisfies your contracts, and you review it. If the implementation looks wrong despite passing tests, your tests are incomplete — add more. If it looks right, you’ve just built a verified component in minutes instead of hours.
The human remains the designer. The AI is the builder. The tests are the blueprint. This workflow only works if the tests exist before the implementation. Otherwise, you’re back to generating code and then generating tests that confirm what the code already does — which is circular and catches nothing.
Seven years ago, I ended the original article by arguing that unit tests serve as documentation and that TDD helps maintain low coupling. Both still true. But I was too defensive about it. I spent too much energy justifying tests at all, rather than talking about how to test well.
Here’s what I know now that I didn’t know then:
The cost of writing tests is no longer the bottleneck. AI eliminated it. The cost is now in designing the right tests — choosing what to assert, which edge cases matter, where to draw the boundary between unit and integration.
Coverage is a vanity metric. Mutation score is a quality metric. Chase the latter.
Mocking is a design smell, not a testing strategy. If you need to mock ten dependencies to test one function, the function is doing too much. Fix the design, don’t duct-tape the test. The original article was right that coupling matters — but I’d go further now: excessive mocking is a sign you’re testing the wrong way, not that you need more mocks.
The best test suite is the one your team actually runs. Speed matters. Flaky tests get ignored. A fast, reliable suite of 200 tests beats a comprehensive but flaky suite of 2,000 every time.
Write tests for the code that scares you. The function with six nested conditions? Test it. The billing calculation? Test it. The straightforward getter? Don’t.
Unit tests aren’t about proving your code is correct. They never were. They’re about catching the moment it stops being correct — whether the change came from a human, an AI, or a 3 AM hotfix pushed by someone who “just needed to fix one thing.”
In the AI era, that catching matters more than ever. Write the tests. Let the machines write the code.
]]>What follows is how Miri’s compiler actually works: six phases that turn a .mi source file into a native executable. You don’t need a compiler background to follow along. In fact, that’s kind of the point: compilers are less arcane than they seem, and the ideas behind them are elegant in a way that I think every engineer can appreciate.
When you type miri run hello.mi, here’s what actually happens:
Source Code (.mi)
|
v
Lexer -----> Token Stream
|
v
Parser ----> Abstract Syntax Tree (AST)
|
v
Type Checker -> Validated AST + Type Info
|
v
MIR Lowering -> Basic Blocks + Control Flow Graph
|
v
Codegen ----> Native Machine Code (via Cranelift)
|
v
Linker -----> Executable Binary
Each phase has one job: take the output of the previous phase, transform it, and hand it to the next one. The lexer doesn’t know about types. The type checker doesn’t know about machine code. This separation is what makes the whole thing manageable — you can think about one problem at a time, and each layer is independently testable.
Let me take you through each phase.
The lexer is the simplest phase conceptually, and yet it’s where some of the trickiest edge cases live.
Its job is to turn raw characters into tokens — meaningful chunks that the next phase can work with. Think of it like reading a sentence. Your brain doesn’t process individual letters; it recognizes words, punctuation, spacing. The lexer does the same for code.
Source: let x = 42 + 3
Tokens: [Let] [Identifier("x")] [Assign] [Integer(42)] [Plus] [Integer(3)]
Miri’s lexer is built on top of the Logos crate — very fast lexer generator for Rust. Logos handles the boring parts: matching keywords, recognizing operators, parsing number formats. But Miri adds a stateful layer on top that handles things Logos can’t.
The most interesting of those is indentation tracking. Like Python, Miri uses significant whitespace — indentation determines code blocks, not curly braces. This means the lexer has to emit synthetic Indent and Dedent tokens whenever the indentation level changes:
if x > 0 # indent_stack: [0]
println("positive") # indent_stack: [0, 4] -> emit Indent
println("and nonzero")
println("always runs") # indent_stack: [0] -> emit Dedent
The lexer maintains a stack of indentation levels and compares each new line against the top of the stack. More indentation? Push and emit Indent. Less? Pop (possibly multiple times) and emit Dedent for each level unwound. Same? Just a regular statement boundary.
There’s an important exception here: indentation changes are suppressed inside parentheses, brackets, and curly braces. Otherwise, you couldn’t write multi-line function calls or collection literals without the lexer panicking about inconsistent indentation. The lexer tracks bracket nesting depth and simply ignores whitespace changes when any bracket counter is above zero.
Another subtle problem the lexer solves: when it sees 5., that could be the start of a float (5.0), a range operator (5..10), or a method call on an integer (5.method). Logos initially matches this as an ambiguous FloatOrRange token, and then Miri’s stateful layer peeks at the next character to figure out which one it is. These kinds of disambiguation decisions — where one character of lookahead changes the entire meaning — are what make lexers more interesting than they first appear.
The parser takes the flat stream of tokens and builds a tree — the Abstract Syntax Tree, or AST. This is where structure emerges. The AST represents the hierarchical relationships in your code: this expression is the condition of that if statement, this + operator has these two operands, this function has these parameters and this body.
Tokens: [Let] [x] [=] [1] [+] [2] [*] [3]
AST: VariableDeclaration
├── name: "x"
└── init: Binary(+)
├── left: Literal(1)
└── right: Binary(*)
├── left: Literal(2)
└── right: Literal(3)
Notice that * binds tighter than + — the tree correctly represents 1 + (2 * 3), not (1 + 2) * 3. Getting operator precedence right is one of the parser’s core responsibilities.
Miri uses a hybrid parsing strategy. For statements and declarations — if, for, fn, class — it uses recursive descent: each grammar rule is a function, and the functions call each other based on what token they see. This is the most intuitive approach; the code structure mirrors the grammar.
For expressions with operators, Miri uses Pratt parsing (also called precedence climbing). The idea is elegant: each precedence level has a function that parses the operand at the next-higher level, then loops while it sees an operator at its own level, combining left and right into a binary node. Twelve precedence levels — from or at the lowest to primary literals at the highest — chain together naturally, and the whole thing handles complex expressions like a + b * c == d and e or f without any ambiguity.
The parser only needs one token of lookahead to decide what to do. It peeks at the next token without consuming it: see if? Parse an if-statement. See fn? Parse a function declaration. See a number? Start parsing an expression. This simplicity — one token is enough — is a sign that the grammar is well-designed.
One design choice I like about Miri’s parser: every AST node gets a unique sequential ID, generated by an atomic counter. The type checker later uses these IDs to store inferred types in a separate HashMap<NodeId, Type>, without ever modifying the AST. This keeps the AST immutable after construction — a small decision that prevents an entire category of subtle bugs.
The parser validates syntax — is the code structured correctly? — but it doesn’t check whether the code makes logical sense. That’s the type checker’s job.
let x = 42
let y = "hello"
let z = x + y # Type error: can’t add Int and String
Without type checking, this would blow up at runtime. With it, the error is caught before the program ever runs.
Miri’s type checker uses a two-pass architecture, and the reason is simple. Consider this perfectly valid code:
fn main()
greet("Alice") # greet() hasn’t been defined yet!
fn greet(name String)
println(f"Hello, {name}")
In a single pass, the call to greet() would fail because the function hasn’t been seen yet. So Pass 1 walks the entire program and registers all function signatures, class definitions, struct definitions, and type hierarchies. Pass 2 then checks everything else — function bodies, expressions, type compatibility — with full knowledge of what exists.
The type checker supports type inference, which means you don’t have to annotate everything:
let x = 42 # Inferred: Int
let name = "Alice" # Inferred: String
let items = [1, 2, 3] # Inferred: [Int]
For collections, it infers the element type from the first element, then verifies all other elements match. For function calls, it looks up the function’s declared return type. For generics, it infers type parameters from the arguments you pass — identity(42) infers T = Int without you ever specifying it.
Type compatibility in Miri follows a decision tree with about ten steps: exact match, error suppression (to prevent cascading errors), option compatibility (T is compatible with T?), numeric widening (i8 can be used where i64 is expected, but not the reverse), subtype checking (class inheritance), and so on. The order matters — earlier checks are faster and more common, so the system short-circuits quickly.
One detail I’m particularly pleased with: the type checker reports multiple errors in a single pass. If your program has three type errors, you see all three at once, not just the first one. To make this work without drowning you in noise, it uses an Error type as a sentinel — once an expression fails type checking, any operation on that Error value is silently accepted. A single typo produces one error message, not twenty cascading ones.
This is where things get really interesting. The AST is too high-level for code generation — it has nested if/else, for loops, match expressions, classes, all these rich constructs. Machine code understands none of that. It only knows: move a value, add two numbers, jump to an address.
MIR — the Mid-level Intermediate Representation — bridges the gap. It decomposes everything into basic blocks: straight-line sequences of simple instructions, each ending with a “terminator” that says where to go next.
// What you write: // What MIR produces:
if x > 0 bb0:
return x _2 = Gt(_1, 0)
else SwitchInt(_2) -> [true: bb1, else: bb2]
return -x
bb1:
_0 = Copy(_1)
Return
bb2:
_0 = Neg(_1)
Return
A for loop becomes a while-like pattern with an index variable and a bounds check. A match expression becomes a SwitchInt with branches. Method calls become mangled function calls like String_to_upper. Every high-level construct is “desugared” into these primitives.
After the initial lowering, MIR runs through optimization passes — constant propagation (replace 5 + 3 with 8 at compile time), copy propagation (eliminate redundant copies), dead code elimination (remove computations whose results are never used), and control flow simplification (thread chains of empty blocks). These passes iterate until nothing changes, up to ten rounds.
But the most important MIR pass isn’t an optimization in the traditional sense. It’s Perceus — automatic reference counting insertion — and it’s at the heart of how Miri manages memory. More on that in a moment.
Every language has to answer the question: who frees the memory?
In C, you do it manually — and get it wrong constantly. In Java and Go, a garbage collector does it for you — but it runs on its own schedule, introducing latency spikes that are murder for real-time systems. In Rust, the borrow checker enforces ownership rules at compile time — brilliant, but the learning curve is steep and the annotation burden is real.
I spent weeks going back and forth on this. GC would have been the path of least resistance — well-understood, easy to implement, handles cycles for free. And yes, you could run a GC on the CPU to manage GPU memory — it’s not technically impossible. But the more I thought about it, the worse the fit became.
GPU computing demands predictable memory lifetimes. You need to know exactly when a buffer is safe to reuse, when data can be transferred back, when GPU memory can be freed. A GC gives you none of that — it frees things eventually, on its own schedule, after a tracing pass that might pause the CPU and starve the GPU pipeline of work. And if Miri eventually compiles code that runs on the GPU, the kernel side would need a completely different memory strategy anyway — meaning two memory models in one language, which is exactly the kind of complexity I’m trying to avoid.
Reference counting sidesteps all of this. It’s deterministic, it’s per-object, and — critically — it works the same way on both CPU and GPU code paths. One memory model, one set of semantics, no special cases.
So Miri takes that path: automatic reference counting, inserted at compile time by the Perceus algorithm.
The idea is straightforward. Every heap-allocated object — strings, lists, maps, class instances — has a reference count: how many variables point to it. When you assign a list to a new variable, the count goes up. When a variable goes out of scope, the count goes down. When it hits zero, the memory is freed immediately.
let a = [1, 2, 3] # List allocated, RC = 1
let b = a # RC = 2 (b aliases a)
# b goes out of scope # RC = 1
# a goes out of scope # RC = 0 -> freed immediately
What makes Perceus special is that the programmer never writes any of this. The MIR pass analyzes every function and inserts IncRef and DecRef instructions automatically. When a managed value is copied, Perceus adds an IncRef before the copy. When a local goes out of scope, it adds a DecRef. Primitives and small structs (128 bytes or less, all primitive fields) are just copied by value — no reference counting overhead at all.
This gives Miri a distinctive position in the memory management landscape:
malloc/free, no dangling pointers, no double-frees. You write code and the compiler handles cleanup.weak and unowned references to break cycles. Miri’s Perceus approach aims to handle more of this automatically.The deterministic cleanup is particularly important for Miri’s long-term vision. When you’re coordinating memory across CPU and GPU, you need tight control over object lifetimes — not a GC that might pause at the worst possible moment. Reference counting gives you that: each object manages its own lifetime, cleanup is immediate and predictable, and the same IncRef/DecRef semantics work regardless of where the code runs.
MIR’s basic blocks become actual machine instructions. This is where the abstract finally becomes concrete.
Miri uses Cranelift as its code generation backend — a fast, lightweight code generator originally built for WebAssembly. Cranelift isn’t as aggressive at optimization as LLVM (the backend used by Rust, Clang, and Swift), but it compiles much faster. For a language still in alpha, where fast iteration on the compiler itself matters more than squeezing out every last CPU cycle, that’s the right trade-off.
The type mapping is simple by design: integers map to native integer types, floats to native float types, booleans to a single byte. Everything else is a pointer. Strings, lists, maps, structs, class instances — they all live on the heap, and the compiled code manipulates pointers to them.
Every heap-allocated object follows a uniform layout: a reference count stored just before the payload data. String literals are special — their reference count is set to a sentinel “immortal” value (the high bit is set), so they’re never freed. This is a small optimization that eliminates pointless reference counting on data that lives for the entire program.
After Cranelift produces an object file, the system linker (cc) combines it with Miri’s runtime library — a separate Rust crate compiled as a static library. The runtime provides all the functions that compiled Miri code calls at execution time: string operations, collection management (creating lists, pushing elements, growing arrays), memory allocation, I/O.
The runtime is type-erased — it doesn’t know about Int or String, only about byte sizes. List<Int> and List<String> both become the same MiriList struct with a different elem_size field. One implementation handles all element types. This is the opposite of Rust’s monomorphization approach (which generates specialized code for each generic instantiation), and the trade-off is worth it: smaller binaries, simpler runtime, at the cost of losing some type-specific optimizations.
Everything I’ve described so far runs on the CPU. But Miri’s architecture was designed with a bigger ambition in mind: GPU-first computing.
The MIR already tracks an ExecutionModel for each function — Cpu, Async, GpuKernel, or GpuDevice. The type checker already registers GPU-specific built-in types like Dim3 and GpuContext. The reference counting memory model was specifically chosen because it works without a global garbage collector — a requirement for GPU execution where there’s no runtime thread managing memory.
The backend doesn’t support GPU code generation yet. But the foundation is deliberately designed so that when it does, the programmer’s experience will be seamless: write a function, annotate it with gpu, and the compiler handles the rest — memory transfers, kernel launches, synchronization. Not two separate languages stitched together with FFI, but one language that targets both CPU and GPU from the same source.
This is the bet: that the next generation of programming languages needs to treat GPU compute as a first-class citizen, not an afterthought bolted on through libraries.
Building a compiler forces you to make dozens of decisions where reasonable people would disagree. Here are the ones I think about most:
Cranelift over LLVM. LLVM produces better-optimized code, but it’s enormous, slow to compile, and a nightmare to link against. Cranelift trades some code quality for dramatically faster compilation. For a language in active development, where I’m rebuilding the compiler many times a day, that speed matters more. The backend trait abstraction means LLVM can be added later without touching the rest of the pipeline.
Reference counting over garbage collection. This was the biggest decision. GC would have been easier to implement and handles cycles automatically. But it introduces non-determinism (when does the GC run?), latency spikes, and a unified CPU/GPU memory model becomes much harder — you’d need GC on the CPU side and something else entirely for GPU kernels. Perceus-style automatic RC gives me deterministic destruction and one consistent memory model across both targets, at the cost of slightly more compiler complexity and the future challenge of cycle detection.
Significant whitespace over braces. This is a taste decision, but it has real consequences. The lexer is more complex because it has to track indentation and emit synthetic tokens. But the resulting code is cleaner, and — importantly — it parses more naturally for LLM-based tooling. When the code’s structure is visible in its indentation rather than hidden in braces, both humans and AI can read it more reliably.
Two-pass type checking over single-pass. A single pass would be simpler but would require forward declarations or specific ordering. Two passes let you write functions in any order, which is how most programmers think. The cost is an extra walk over the AST, but it’s fast enough that it’s never been a bottleneck.
Type erasure in the runtime over monomorphization. Monomorphization (generating specialized code for each concrete type) produces faster code. Type erasure (one implementation for all types, parameterized by size) produces smaller binaries and a simpler runtime. For a language still finding its feet, simplicity wins. If profiling later shows the type erasure overhead matters, monomorphization can be added for hot paths.
Multiple error reporting over fail-fast. The type checker collects all errors and presents them at once. The parser stops at the first error. I’d like to make the parser more resilient eventually, but error recovery in parsing is genuinely hard — you need heuristics for “where does the next valid statement probably start?” — and getting it wrong produces confusing phantom errors. The type checker’s approach is easier because type errors are more localized.
Every one of these decisions could have gone the other way, and the language would still work. That’s the thing about compiler design — there are very few objectively right answers, just trade-offs that align with your priorities. Miri’s priorities are clear: fast iteration, ergonomic code, GPU readiness, and the kind of simplicity that lets a small team (currently just me) keep the whole system in their head.
Years ago, I thought compilers were dark magic. Now I have one that takes a .mi file and spits out a native binary — and I can trace every step of that journey through code I wrote. The compiler is open source. Next up: making it talk to GPUs :)
What surprised me wasn’t that remote work worked. I’d been doing it for years and knew it could. What surprised me was how many organizations learned the wrong lessons from it. They either declared remote work a failure and mandated return-to-office, or they kept the Zoom-heavy, always-on model that had burned everyone out during the pandemic and called it “remote culture.”
Neither is right. After working as a CTO in a fully-remote company and later managing distributed engineering teams across Germany and Canada at AutoScout24 and Trader Inc., I’ve landed on a set of principles that actually hold up.
Most debates about remote work obsess over the wrong variable: productivity. Managers worry people are slacking off. Employees worry they’re being watched. Both sides produce studies that confirm whatever they already believed.
Here’s what I’ve learned from running distributed platform engineering teams: individual productivity is rarely the problem. Most remote engineers are, if anything, more productive in focused work than their office counterparts. The absence of shoulder-taps, impromptu “quick questions,” and open-plan noise gives them deep work time that offices struggle to provide.
The actual failure modes of remote teams are different and harder to measure:
These are the problems worth solving. And none of them are solved by installing surveillance software or mandating cameras-on during meetings.
The single most impactful shift a remote team can make is going async-first. Not async-only — that’s a different extreme with its own problems. Async-first means the default mode of communication is written and asynchronous, with synchronous meetings reserved for situations that genuinely need them.
Why does this matter so much? Because most remote teams make a critical mistake: they replicate the office experience over video calls. The result is a schedule packed with meetings, with “real work” squeezed into the gaps. Engineers end up in six hours of Zoom calls and then writing code between 7 and 10 PM. That’s not remote work — it’s office work with a shorted commute to the kitchen.
Async-first requires a few things to actually function:
Write things down. This sounds obvious but almost nobody does it well. Decisions need to be documented where people can find them — not buried in Slack threads that scroll into oblivion within hours. At AutoScout24, we use RFCs and ADRs (Architecture Decision Records) for anything that matters. The discipline of writing a decision down forces clarity that verbal discussions often skip. It also creates an artifact that new team members can find six months later, instead of having to reconstruct context from people’s memories.
Make status visible without asking. The old “what did you do yesterday?” standup question is a poor man’s visibility system. Better approaches: project boards that reflect actual state, automated deployment notifications, PR dashboards. If a manager needs to ask an engineer what they’re working on, that’s a systems failure, not a people failure.
Default to the permanent channel. Slack DMs are where information goes to die. Team decisions made in DMs are invisible to everyone who wasn’t in the conversation. Push discussions to public channels, even when it feels slightly awkward. The team member who joins next month will thank you.
Respect time zones ruthlessly. At AutoScout24, our teams span Germany and Canada — a six-hour time difference. That’s manageable, but only if you design for it. Meetings have to fit the overlap window. Everything else has to work asynchronously. This constraint, paradoxically, makes communication better because it forces you to write clearly enough that someone reading your message hours later can act on it without a follow-up call.
My 2019 article talked about “trust by default.” It’s a nice sentiment, but it’s incomplete. Trust isn’t a switch you flip. It’s an emergent property of well-designed systems.
What do I mean by that? Consider two scenarios:
Scenario A: A manager tells their team “I trust you” but has no visibility into what’s happening. When something goes wrong, they panic. Suddenly there are daily check-ins, status reports, and uncomfortable questions. The team feels surveilled. Trust evaporates.
Scenario B: The team uses a transparent project board. Code is reviewed in public PRs. Deployments are automated and visible. Release metrics are shared. The manager doesn’t need to ask what’s happening because the system makes it visible. They can genuinely trust because they’re not operating blind.
Trust-by-default without transparency is just willful ignorance dressed up as leadership philosophy. Real trust comes from systems that make the right information visible to the right people at the right time — so nobody needs to ask, nobody needs to report, and nobody needs to worry.
This is especially important during the first months with a new team member. Instead of vague expectations and a “figure it out” onboarding, build an onboarding path that makes expectations explicit: here’s how we work, here’s where decisions live, here’s what good looks like, here’s how to get help. The faster someone reaches autonomy, the faster trust develops naturally — not because you decided to “trust by default,” but because they’ve demonstrated competence in a system that makes competence visible.
My 2019 take on team building boiled down to: meet your colleagues in person and have a beer. It’s still true, but it’s too simple.
Post-COVID, the question isn’t whether to meet in person but how to make it count. Flying a distributed team to the same city for a week is expensive. If they spend that week in the same meetings they could’ve done on Zoom, you’ve wasted the budget.
In-person time should be optimized for what remote work is bad at:
What doesn’t need in-person time: status updates, sprint planning, retrospectives, code reviews, most decision-making. If your offsite agenda is full of these, you’re not using it well.
At AutoScout24, we bring teams together periodically, and the format has evolved through trial and error. The most successful offsites have minimal formal agenda and maximum shared experience. The work that actually needs to happen in person is usually relationship work, not project work.
Here’s what my 2019 article couldn’t have anticipated: AI coding assistants have fundamentally changed the dynamics of remote engineering work.
When a developer can pair-program with an AI, the cost of being stuck drops dramatically. Questions that used to require interrupting a colleague — ”How does this service handle authentication?” or ”What’s the pattern for error handling here?” — can often be answered by an AI that has context on the codebase. This is a genuine game-changer for distributed teams, where “just asking someone” carries a much higher latency cost than in an office.
But AI introduces new challenges too. When individual developers can move faster, coordination becomes more important, not less. Two engineers working in parallel with AI assistance can diverge rapidly if they’re not aligned on architecture and approach. The speed that AI enables makes shared vision and clear architectural direction more important than ever.
AI also shifts what remote team communication should focus on. Less time explaining how to do things, more time aligning on what and why. The tactical coding questions go to AI. The strategic conversations — what should we build, for whom, and why this approach over that one — still need human discussion. Remote teams that recognize this shift can redesign their communication patterns around it.
Honesty demands acknowledging what remote setups still struggle with, even when done well:
Mentoring junior engineers is harder. The osmotic learning that happens when a junior developer sits near senior engineers — overhearing design discussions, watching how they debug, absorbing judgment and taste — doesn’t transfer well to remote. You can compensate with structured pairing sessions, recorded design reviews, and deliberate teaching moments, but it requires conscious effort that offices provide for free.
Spontaneous collaboration takes a hit. The best ideas sometimes come from accidental collisions — two people from different teams chatting at the coffee machine and realizing they’re solving the same problem. Remote work has no equivalent. You can create “virtual serendipity” through cross-team channels, random coffee chats, and internal tech talks, but it’s a pale imitation.
Reading the room is impossible. In a meeting room, you can see someone’s body language shift when they disagree but don’t want to speak up. On a Zoom call with cameras off — which is most of them, despite policies — you get silence. This makes it harder to surface disagreement, which means decisions get made without genuine buy-in.
Social isolation is real. Some people genuinely need the social structure of an office. Not everyone thrives working alone from their apartment. And while the “just go to a coworking space” advice helps some, it doesn’t recreate the tribal belonging of a team that shares physical space. Leaders need to watch for signs of isolation and not dismiss them as a remote work skill issue.
None of these are dealbreakers. But pretending they don’t exist — which the “remote work is perfect” crowd tends to do — leads to teams that look functional on paper while people quietly burn out or disengage.
After years of iterating on distributed team leadership, here’s what I’d tell someone building a remote engineering team today:
Design for async first, then add synchronous rituals where they genuinely help. Not the other way around. Most teams over-index on meetings and under-invest in documentation, which is exactly backward for remote work.
Build transparency into your tools and processes, not into your management habits. If you need to ask someone what they’re doing, you have a systems problem. Fix the system, don’t add more check-ins.
Invest in in-person time, but make it about relationships, not status updates. Two offsites per year with the right format beats monthly all-hands that nobody wants to attend.
Take the mentoring gap seriously. It won’t fix itself. Junior engineers in remote teams need structured support, not just access to a Slack channel.
And stop debating whether remote work “works.” It does. The interesting question — the one worth your leadership energy — is how to make it work well. That’s a design problem, not a policy decision. And like all design problems, it requires iteration, honesty about what’s failing, and the willingness to keep adjusting.
The organizations that thrive with distributed teams aren’t the ones that found a magic formula. They’re the ones that treat remote work as a craft — something to be studied, practiced, and refined — rather than a perk to be granted or revoked based on the latest headline.
]]>Every slightly unhinged project has an origin story, and Miri’s starts back in 2017. I was between jobs, living mostly off savings, and doing some occasional freelancing. My previous job as a CTO had left me completely burnt out, so I was in absolutely no rush to jump back into the corporate grind.
Instead, I was drifting, floating through a sea of different ideas. At the time, I was a massive fan of Ruby, but its performance left a lot to be desired. I knew Python wasn’t going to win any land speed records either (I actively avoided it back then, though I’d end up using it a lot later).
It got me wondering: Why couldn’t there be a language as ridiculously fast as C++ but as joyfully easy to use as Ruby?
So, I did what any procrastinating developer does. I created an empty GitHub repository and started piling up ideas. If you look at the early commits or closed issues from that era, you will laugh. It was a masterclass in productive procrastination—zero actual code, just a mountain of pipe dreams. Later that year, I moved to Germany, and my focus rightfully shifted to my family’s financial stability. The repo sat there gathering digital dust. I had free time, sure, but it was easily swallowed up by family life, sports, hobbies, and my PlayStation.
Fast forward to 2024 and 2025. On paper, my career was soaring. I had been promoted to Head of Platform Engineering, managing 40 people across Germany and Canada. But behind the scenes, my personal life was fracturing. I went through a divorce, moved into an empty new home, and felt like I was navigating my entire life on autopilot.
I realized I had completely lost myself.
Looking back at my backlog of side projects, most of them felt soulless—purely business-related and money-driven. There was only one idea that still held any real emotional weight: Miri.
But the world of software had fundamentally shifted since 2017. Large Language Models (LLMs) were suddenly writing code. At first, I felt the bitter sting of a missed opportunity. What was the point of writing a new language now?
I started brainstorming with ChatGPT, fully expecting it to tell me to give up. To my surprise, it didn’t. Instead, it helped me reframe the entire vision: Don’t just build a language for humans. Build a language for a world where AI generates most of the code. Existing languages carry decades of baggage, and AI is forced to use these legacy tools. We need a language designed for agentic engineering, where humans define the intent and AI fills in the safe, verifiable, high-performance implementations. Furthermore, even if AI writes the code, humans still need to read and verify it—so it can’t look like alien hieroglyphics.
Along with the AI revolution came the absolute dominance of GPUs. It hit me that bolting GPU support onto a language as an afterthought is a mistake. Miri needed to be a GPU-first language.
Right now, if you want to write serious GPU code, you’re usually stuck wrestling with C++ and CUDA, which is notoriously unforgiving. There are modern alternatives like Triton and Mojo that build on top of Python, and while they are stepping in the right direction, I believed I could do even better by baking GPU constructs natively into a statically-typed, compiled language.
That realization was the spark. I finally had my “why.” I needed to build Miri for myself—to finally close the loop on a decade-old dream, to demystify how compilers and parallel computing actually work, and to build something unapologetically cool. And with the help of modern AI, I knew I could move exponentially faster than I ever could have in 2017. No more excuses.
I always assumed I’d write Miri in C++. It’s the battle-tested standard for building compilers, and I already had experience with it. So, I started dusting off my C++ skills—which was an adventure in itself, considering the language had evolved significantly since I last touched it a decade ago.
I had, of course, heard of Rust. But if I’m being completely honest, I just didn’t like how it looked. The syntax felt noisy to me.
But as I was getting back up to speed with C++, the buzz around Rust became impossible to ignore. I kept reading about its legendary memory safety, its insanely robust tooling, and how massive players like Microsoft were actively adopting it for mission-critical systems. The more I looked into it, the more I realized that if I was going to build a modern, high-performance programming language, I needed to build it on a modern foundation. So, I pivoted. Miri is written entirely in Rust.
I jumped into a Udemy course to learn it. Was it easy? Absolutely not. Rust’s learning curve is famously steep. But here’s the beauty of the modern world: learning a notoriously strict language is exponentially faster when you have an LLM in your corner. Instead of banging my head against the wall trying to decode esoteric compiler errors, I could just ask my AI assistant to explain exactly why the borrow checker was yelling at me, and get a crystal-clear answer instantly.
Today, I think Rust is an absolute masterpiece of engineering. Its ecosystem and tooling (like Cargo) are a breath of fresh air. But did I ever grow to love its syntax? Not exactly.
And honestly, that’s the best part. It gave me the perfect excuse to push forward with Miri. I get to borrow Rust’s brilliant architectural concepts and use it to drive Miri’s standard compiler pipeline (moving from Lexer to Parser, AST, MIR, and finally Native Codegen via Cranelift), all while designing a clean, indentation-sensitive syntax that I actually enjoy looking at. It’s the best of both worlds.
My relationship with AI coding assistants has evolved right alongside Miri.
In the beginning, I used ChatGPT purely as a sounding board to refine the project structure and generate initial boilerplate. I was taking compiler development courses, and I wrote the lexer and parser mostly by hand to ensure I actually understood the fundamentals. When I tried to use early agentic coding tools, the results were messy. Because I was still leveling up my Rust skills and learning compiler theory, I spent more time debugging the AI’s hallucinations than writing features.
But as LLMs evolved, they became very useful. Today, my workflow is heavily augmented:
Every now and then, I ask the LLMs to re-validate Miri’s architecture and feasibility. So far, they still agree it needs to exist. And honestly? So do I.
]]>Platform Engineering has crossed a threshold. It is no longer something only elite tech companies do well. It has become a requirement for any organization operating modern software systems at scale. The reason is straightforward: system complexity has outpaced human coordination. Microservices, multi-cloud setups, regulatory constraints, and AI workloads don’t compose cleanly through local team decisions alone. Without a platform, organizations compensate with process, tickets, and heroics.
DevOps improved autonomy at the team level, but it never fully solved coordination at the organizational level. “You build it, you run it” only works when teams share well-designed primitives to build and run on. Without those, every team reinvents the same solutions, ownership becomes fragile, onboarding slows down, and operational risk accumulates quietly. In practice, the failure mode looks predictable: every new service requires nuanced CI, custom dashboards, manual IAM setup, and implicit ownership that only exists in someone’s head.
Platform Engineering institutionalizes DevOps. It does so by making the right way the default way, not through mandates, but through paved paths that encode what the organization has already learned. A useful mental model is simple. Product teams optimize for delivering features. Platform teams optimize for the system that enables delivery. The platform becomes the control plane for software delivery: abstracting infrastructure, encoding standards, and providing self-service that scales across dozens or hundreds of teams. In practical terms, this is where standards, automation, and ownership metadata live.
This distinction becomes especially visible during acquisitions. Teams that grew up without Platform Engineering often rely on tribal knowledge and manual processes. Onboarding them is rarely about tools first. It’s about aligning operating models. What consistently works is introducing the platform as the default delivery path, reinforcing ownership with clear guardrails, and focusing on enablement rather than enforcement.
At scale, this enablement becomes a capability of its own. Platform advocates or enablement teams help business units adopt the platform effectively and prevent local workarounds from eroding consistency over time. Organizations that delay this investment accumulate organizational debt. Delivery slows despite growing headcount. Incidents increase. Senior engineers become human glue. Cloud and compliance costs rise without clear ownership. By the time leadership reacts, the gap is structural.
Platform Engineering is not about centralization for its own sake. It is a deliberate trade-off: slightly less local freedom in exchange for much higher global throughput and reliability. Teams will still ship software without it — just slower, riskier, and at a higher human cost.
At a certain scale, an Internal Developer Platform stops being optional. Once you operate dozens of teams, hundreds of services, and multiple cloud environments, you need a single system of record for how software is built, owned, operated, and governed.
High-performing platforms are not just deployment portals. They act as authoritative sources of truth for service ownership, lifecycle, environments, operational metadata, and compliance posture. When this data is reliable, it becomes reusable everywhere else: incident management, KPIs, cost attribution, and operational reviews.
At AutoScout24 & Trader, Backstage plays this role. Service ownership defined in the platform flows into incident reports, Core Tech KPIs, and KTLO attribution. That only works if the data stays clean and enforced. An IDP with stale metadata quickly becomes a liability. This pattern is not specific to Backstage. Any service catalog can work if ownership is enforced and reused downstream in incidents, reviews, and cost attribution.
Many organizations underestimate the difference between a portal and a platform. Standing up a UI is easy. Keeping the platform relevant over time is hard. Ownership fields decay, catalog entries go stale, paved paths lag reality, and exceptions quietly become the norm. Once trust erodes, developers stop treating the platform as a source of truth, and recovering that trust is expensive.
Early adopters often built heavily customized platforms. We did too, before moving to Backstage. The industry has become more pragmatic since then. Open-source frameworks provide extensibility, managed solutions reduce undifferentiated effort, and internal investment is focused where the platform encodes company-specific rules. The real question is no longer whether something can be built, but whether it helps developers ship better software faster.
A healthy platform is treated like production software. Ownership is enforced at creation time, unused entries are cleaned up, platform data feeds processes developers care about, and using the platform is always easier than bypassing it. When that balance is right, the platform becomes boring, trusted, and essential — exactly what you want.
Kubernetes itself is no longer the hard part. It is mature and operationally stable in most organizations. What differentiates platforms now is how much of that complexity developers are exposed to.
Kubernetes should not be a developer-facing product. Exposing raw clusters, YAML, and Helm charts to every team increases cognitive load and inconsistency. The emerging pattern is clear: Kubernetes is the compute foundation, the platform is the interface. Developers express intent, the platform translates that intent into resources, policies, and workflows.
At AutoScout24, our paved-path compute is Kubernetes-based. We still support EC2 workloads with standardized AMIs, but Kubernetes is the default and continues to expand. The goal is not forced migration, but making the Kubernetes path clearly superior for most use cases.
GitOps has become the dominant control mechanism in this model. Tools like ArgoCD are foundational for managing desired state, drift detection, and environment promotion. They provide a single source of truth for desired state, automated and auditable deployments, and consistent promotion across environments. Humans own intent. The platform owns reconciliation.
The real leverage comes from layering opinionated workflows on top of Kubernetes: service templates, default security and observability, standardized deployment strategies, and GitOps-driven rollouts. Developers should rarely touch Kubernetes primitives directly. When they do, it should be a conscious exception.
Most organizations run mixed compute models, and that is fine. The mistake is treating them as peers in developer experience. Over time, teams naturally migrate toward the path with the least friction.
What differentiates platforms is not Kubernetes itself, but how invisible it becomes.
AI has rapidly shifted from being just a productivity tool at the edges of development. It is becoming an active participant in the delivery system. That shift forces platforms to treat AI not as a feature, but as a user, with identity, permissions, limits, and accountability.
Early AI adoption was individual and ungoverned. That does not scale. Mature organizations are moving AI capabilities into the platform layer, where they can be governed, audited, integrated into workflows, and bounded by policy and cost controls.
Treating AI as a platform actor means it has explicit identities, scoped roles, quotas, and full observability. AI agents can validate configurations, trigger deployments, or remediate issues — but only within clear boundaries. Unbounded autonomy is operational risk. Platforms exist to contain that risk.
This becomes especially important because AI-generated code often passes syntactic checks while failing operational reality. Platforms increasingly act as safety nets through validation, policy enforcement, and runtime safeguards. Without that layer, AI adoption stalls after the first serious incident.
The next step is multi-agent systems: specialized agents for code generation, security validation, deployment, rollback, and runtime monitoring. Platform Engineering provides the orchestration layer that integrates these agents into CI/CD and GitOps workflows and ensures they act coherently.
A simple rule holds: AI belongs in the platform, not just in the IDE. Centralizing it early creates leverage. Retrofitting guardrails later is far more expensive.
Observability has become a crucial part of the platform contract. Every service created through the platform is observable by default.
High-maturity organizations treat observability as a managed platform capability. Logging, metrics, tracing, dashboards, and incident integration are standardized and inherited automatically through paved paths. This reduces variance and enables meaningful cross-service analysis.
OpenTelemetry has effectively become the baseline. Its value is practical: vendor neutrality, consistent semantics, and easier evolution of the observability stack over time.
As systems scale, manual observability does not. Platforms increasingly apply automation and AI to detect anomalies, correlate signals, surface likely root causes, and reduce alert fatigue. The goal is not to replace engineers, but to compress time to insight.
Cost is now inseparable from observability. Telemetry is expensive, and collecting everything is neither useful nor sustainable. Mature platforms enforce sampling, retention policies, telemetry budgets, and observability-as-code. The trade-off is intentional: enough signal to operate safely, not unlimited data.
Automation has moved beyond scripts and runbooks. The focus is now on systems that adapt themselves without waiting for human intervention.
Basic self-healing is table stakes. Restarting containers, scaling replicas, and rolling back failed deployments are expected. The real shift is toward predictive and intent-based automation.
Instead of specifying how systems should behave, teams specify what they want: reliability targets, performance objectives, cost boundaries. The platform translates intent into action and continuously adjusts within defined guardrails.
AIOps works only when it is deeply integrated with telemetry, deployment context, and policy. In that setup, platforms can forecast demand, detect anomalies, trigger remediation, and optimize cost and performance in real time.
Autonomy requires boundaries. Clear blast-radius limits, policy-defined ceilings, human approval for structural changes, and full audit trails are non-negotiable. The trade-off is clear: more autonomy yields lower toil and faster response, but only if constraints are enforced rigorously.
Platforms should own routine recovery, optimization, and tuning. Humans should own objectives, policy, and system design.
Security and compliance have shifted from process to platform defaults. If a deployment violates policy, it simply does not happen. Manual reviews cannot keep up with continuous delivery and AI-generated changes.
Policy-as-code has become the enforcement layer. Encryption, IAM, network rules, approved dependencies, compliance constraints, and cost limits are encoded, versioned, tested, and enforced automatically. Developers learn constraints through fast feedback, not audits.
AI changes the threat model further. Platforms must control AI access to data, validate AI-generated artifacts, prevent privilege escalation, and track provenance end to end. Supply chain security, SBOMs, and artifact signing are now baseline expectations.
FinOps follows the same pattern. Cost management has moved into engineering workflows. Platforms surface cost at creation time, enforce budgets automatically, and tie spend to service ownership. This is especially critical for AI workloads, where cost spikes can appear within hours.
The goal is not to turn engineers into accountants. It is to make cost-aware decisions the default path.
Platform Engineering only works when the platform is treated as a product. Developers are the customers. Adoption is earned, not mandated.
This requires product discipline: a roadmap, explicit priorities, non-goals, documentation, onboarding, and continuous feedback. It also requires measurement. Time to first production deployment, deployment frequency, failure rates, developer satisfaction, and toil reduction all matter. Platforms that do not measure outcomes struggle to justify investment or improve intentionally.
As scope grows, ownership must become explicit. Platform Product Managers, Developer Experience Leads, and specialized platform engineers are no longer optional roles. They reflect the reality that prioritization and trade-offs matter.
High-maturity platforms reduce tool sprawl through product decisions. Fewer supported tools, opinionated defaults, and clear exception paths reduce cognitive load and long-term maintenance costs, even if they limit short-term freedom.
Platform teams succeed when they are small, senior, and embedded. They enable product teams rather than replacing them. They collaborate early, observe real usage, and evolve abstractions based on friction, not theory.
Platform Engineering is not about control. It is about leverage.
Organizations that succeed accept a small reduction in local freedom to gain a large increase in global throughput, safety, and sustainability. That trade-off is uncomfortable, but unavoidable.
The platforms that win are boring, trusted, and widely adopted. The ones that fail are optional, fragmented, and under-owned. If I were starting or course-correcting today, I would focus on four things first:
The direction of travel is clear. What remains is how deliberately leaders choose to move.
]]>I’ve run that meeting more times than I’d like to admit.
Early in my leadership career, I believed collaboration was almost always the right answer. If I involved the team in every decision, I’d get better outcomes and higher morale. Two birds, one stone. What I actually got was decision paralysis, frustrated senior engineers, and a team that was polite but quietly losing confidence in my leadership. It took me a while — and some direct feedback from a team lead who told me, bluntly, “We need you to just make the call sometimes” — to understand what I was getting wrong.
The problem wasn’t collaboration itself. The problem was that I’d turned it into a default mode instead of a deliberate tool.
There’s an unspoken orthodoxy in modern engineering leadership: collaboration is inherently good, directive leadership is inherently risky. It shows up in management training, leadership books, and conference talks. “Empower your teams.” “Seek diverse perspectives.” “Create psychological safety.” All good advice — until it becomes dogma.
Here’s what nobody tells you: collaboration has a cost. Every person you include in a decision adds latency. Every brainstorming session you run instead of making a call delays execution. Every “let’s get alignment” meeting is time not spent building. And past a certain point, the returns diminish sharply.
I manage multiple teams across Germany and Canada at AutoScout24 and Trader Inc. At that scale, the cost of unnecessary collaboration is not abstract — it’s measurable in weeks of delayed delivery, in engineers sitting in meetings instead of writing code, in decisions that get relitigated because the last discussion didn’t produce a clear outcome.
The uncomfortable truth is that overcollaboration is at least as common a failure mode as micromanagement. It’s just less visible, because nobody complains about being asked for their opinion. They just quietly disengage when they realize their input doesn’t actually change anything — that the meeting was performative, a ritual of inclusion rather than a genuine decision-making process.
Not all decisions benefit from group input. Recognizing which ones do — and which ones don’t — is one of the most important judgment calls an engineering leader makes.
Decisions with clear ownership shouldn’t be collaborative. If someone owns a system, a domain, or a deliverable, they should make the calls within it. Asking the whole team to weigh in on a database schema that one engineer owns isn’t empowerment — it’s diffusion of responsibility. The owner loses agency, the team loses time, and the decision often gets worse because it becomes a compromise between people with unequal context.
Urgent decisions shouldn’t be collaborative. During a production incident, a critical escalation, or a hard deadline, the team needs direction, not a brainstorming session. I’ve seen leaders try to run democratic processes during crises — “What does everyone think we should do?” — and the result is always the same: slower response, confused teams, and escalating damage. In those moments, the team is looking for someone to say, “Here’s what we’re doing. Here’s your role. Go.”
Reversible decisions shouldn’t be collaborative. Jeff Bezos called these “two-way doors” — decisions you can easily undo. If the cost of being wrong is low and the cost of deliberation is high, just decide. Pick the monitoring tool. Choose the sprint cadence. Name the service. Move on. You can always change it later.
Where collaboration genuinely adds value is in decisions that are irreversible, high-stakes, and require expertise you don’t have. Architecture decisions that will shape the system for years. Organizational changes that affect people’s careers. Strategic bets that commit significant resources. These deserve real input from people with relevant context — but even here, “collaboration” doesn’t mean “consensus.”
Consensus is collaboration’s most dangerous byproduct. It feels democratic and fair, but it optimizes for the wrong thing: agreement rather than quality.
When a group of smart people tries to reach consensus, the result is usually a lowest-common-denominator solution — something everyone can live with but nobody is excited about. The boldest ideas get sanded down. The strongest opinions get diluted. And the person with the most conviction often stays quiet because pushing too hard feels socially risky.
At AutoScout24, we ran into this during a planning session for a major platform initiative. We had strong engineers with legitimate but conflicting perspectives on the architecture. After two hours of discussion, we’d converged on an approach that was… fine. Safe. And, I realized later, worse than any of the individual proposals it was trying to synthesize.
What we do now is different. When we can’t reach agreement — and this happens regularly with a large engineering organization — we use a simple rule: we vote, the majority wins, and we document the minority’s concerns. Not to dismiss them, but to acknowledge the trade-off explicitly. If the minority turns out to be right, we have a record of what they were worried about and can course-correct faster.
This approach does something important: it makes disagreement productive rather than something to be smoothed over. Engineers learn that it’s safe to advocate strongly for their position, because even if they lose the vote, their reasoning is captured and respected. That’s a healthier dynamic than the false harmony of consensus, where disagreement gets buried and resurfaces later as passive resistance or disengagement.
The leader’s job in these moments isn’t to build consensus. It’s to ensure the best arguments get heard, make a decision (or delegate the decision to someone with the right context), and then commit fully — including supporting the outcome publicly, even if it wasn’t your preferred option.
The opposite failure mode — too much direction — is well-documented and easier to spot. Micromanagement kills initiative, erodes trust, and drives your best people to update their LinkedIn profiles. But there’s a subtler version of over-direction that often goes unrecognized: being directive about the how when you should only be directive about the what.
I once worked with a leader who had a strong software engineering background and couldn’t resist making suggestions on database table structure, optimization strategies, and testing approaches. Their intentions were good — they genuinely had relevant expertise. But the effect on the team was corrosive. Engineers stopped proposing their own solutions because they knew the leader would override them anyway. Innovation dried up. The team’s senior engineers, the ones you most want to retain, were the first to lose motivation.
The framework I use now — and the one I enforce with my own engineering managers — comes from how we structure OKRs at AutoScout24. I own the what and the why: the objectives we’re pursuing, the key results that define success, and the reasoning behind them. The teams own the how: the initiatives, the technical approach, the implementation details. Initiative owners identify milestones and are free to pivot whenever they see their approach isn’t moving us toward a Key Result.
This isn’t a loose “figure it out” delegation. It’s structured autonomy. The boundaries are clear. The expectations are measurable. And within those boundaries, teams have genuine freedom — including the freedom to make choices I wouldn’t have made myself.
The hardest part of this, honestly, is shutting up. When a team chooses an approach I think is suboptimal, my instinct is to intervene. But I’ve learned that the cost of occasionally letting a team take a longer path is far lower than the cost of teaching them that their technical judgment doesn’t matter. People learn by doing — including by making mistakes that their boss could have prevented but wisely didn’t.
There are exceptions. If a decision creates significant technical debt that other teams will inherit, or if it violates a security or compliance constraint, I intervene. But I do it by explaining the constraint, not by dictating the solution. “This approach doesn’t align with our platform vision” is direction. “Use Fargate instead of ECS” is micromanagement — even if Fargate is the right answer.
Knowing when to switch between collaborative and directive modes is the real skill. And it’s mostly pattern recognition built over years of getting it wrong.
There are reliable signals for each mode.
Your team needs more direction when:
Your team needs more collaboration when:
The transitions between modes matter as much as the modes themselves. When I shift from a collaborative phase to a directive one — say, when a brainstorming discussion needs to become a decision — I make the shift explicit. “We’ve heard the options. Here’s what we’re going with, and here’s why.” No ambiguity. No pretending it’s still collaborative when it isn’t.
Similarly, when I deliberately step back and ask for input, I clarify what kind of input I’m looking for. “I want to hear alternatives” is different from “I want to hear concerns about this plan,” which is different from “I want the team to decide this.” Vague invitations to collaborate produce vague results.
Everything I’ve described gets harder as organizations grow. With five engineers, you can operate almost entirely on informal collaboration and gut-feel direction. With forty, you can’t.
At scale, the collaboration-direction balance gets encoded into process whether you design it deliberately or not. Undesigned process is worse — it means the loudest voices drive collaboration, the most senior person’s opinion becomes direction, and the rest of the team oscillates between the two without a clear framework.
What works at AutoScout24 is an explicit structure at multiple levels. Strategic direction — OKRs, platform vision, organizational priorities — flows from leadership. Tactical collaboration — how to solve a specific problem, which approach to take, what trade-offs to accept — lives within teams. And in between, there are mechanisms for cross-team alignment: shared backlogs, regular demo sessions where teams show what they’ve built, and Slack channels where platform decisions get discussed openly before they’re finalized.
The critical insight is that collaboration and direction aren’t opposing forces you balance on a scale. They operate at different levels of abstraction. You can be highly directive about outcomes and highly collaborative about implementation at the same time. In fact, that combination is what the best engineering organizations do — clear alignment on where we’re going, genuine autonomy on how we get there.
When we recently communicated a 54% reduction in high-severity incidents, the outcome was the result of clear direction — this was a priority, these were the metrics, this was the timeline — combined with deep collaboration on the technical solutions. I didn’t tell teams how to reduce incidents. I told them it mattered, gave them the tools and platform support, and got out of the way.
The balance between collaboration and direction isn’t something you solve once. It shifts with every new team, every new project, every phase of organizational growth. What worked when you managed eight engineers won’t work when you manage forty. What works for a team that’s been together for two years won’t work for a team formed last month from an acquisition.
The job isn’t to find the perfect ratio and lock it in. It’s to develop the judgment to read each situation accurately and the flexibility to adjust — sometimes within the same meeting. To be the person who says, “Let’s discuss this” and also the person who says, “I’ve heard enough, here’s what we’re doing.” And to know which moment calls for which.
That judgment comes from experience, from failure, and from paying attention. It comes from the team lead who told me to stop asking and start deciding. It comes from watching a brilliant engineer disengage because their leader never let them own anything. It comes from seeing a team deliver their best work because their leader gave them a clear objective and then genuinely trusted them to figure it out.
Collaboration and direction aren’t competing values. They’re complementary tools. The skill is knowing which one to pick up — and when to put it down.
]]>As Head of Platform Engineering at AutoScout24 and Trader Inc., I’ve written platform visions that worked and ones that didn’t. The difference was never eloquence. It was specificity — whether the vision could resolve a real disagreement between two teams, guide a prioritization call, or tell a new hire what we do and don’t build. A vision that can’t do those things is decoration.
This piece covers how to build a platform engineering vision that actually shapes decisions, earns stakeholder trust, and survives contact with organizational reality.
This distinction matters more than it seems.
A vision describes the future state you’re building toward — what the world looks like when your platform succeeds. A strategy describes how you’ll get there. Mixing them up is the most common mistake, and it produces documents that are simultaneously too abstract to guide daily work and too detailed to inspire alignment.
A good platform engineering vision answers one question: What will be true about how this organization builds and operates software in two to three years that isn’t true today?
At AutoScout24, our platform vision centers on a specific outcome: any team can go from idea to production without waiting on another team, without reinventing shared infrastructure, and without sacrificing security or compliance in the process. That’s it. It doesn’t mention Kubernetes, Backstage, ArgoCD, or GitHub Actions — those are strategy. The vision is about the developer experience and organizational capability we’re building toward.
This separation is practical, not philosophical. Strategies change. We migrated from Jenkins to GitHub Actions. We adopted Backstage after building a custom service catalog. If the vision had been “standardize on Jenkins,” it would have expired in a year. Because the vision describes the outcome — self-service delivery with guardrails — it survived every strategic pivot underneath it.
When writing your vision, resist the temptation to include implementation details. If it mentions a specific tool, it’s probably strategy. If it describes a capability or organizational property, it’s probably vision.
I’ve seen platform visions fail in predictable ways. Recognizing these anti-patterns early saves months of misalignment.
The consensus trap. The vision was workshopped so extensively that every stakeholder’s pet priority got included. The result is a bloated document that tries to be everything — developer productivity, cost reduction, compliance automation, AI enablement, multi-cloud portability — without ranking any of them. When everything is a priority, nothing is. A strong vision makes explicit trade-offs. Ours at AutoScout24 prioritizes developer self-service over maximum flexibility. That means some teams can’t run their preferred exotic stack through the paved path. That’s intentional, and stating it upfront prevents months of renegotiation later.
The abstraction vacuum. The vision is so high-level it can’t be falsified. “Enable engineering excellence” — what would you have to observe to know you’d failed? If you can’t describe what failure looks like, the vision isn’t specific enough to be useful.
The technology declaration. The vision is actually a technology roadmap disguised as strategy. “Adopt a service mesh, implement GitOps, migrate to Kubernetes.” These are decisions, not direction. They expire when the technology landscape shifts, and they fail to explain why to anyone outside the platform team.
The borrowed vision. Lifted from a conference talk or a blog post by a company with a fundamentally different scale, culture, or constraint set. What works for a 5,000-engineer FAANG company doesn’t necessarily apply to a 200-person organization. Your vision must be rooted in your actual pain points, your actual teams, and your actual business context.
The test I use: can a staff engineer on a product team read the vision and immediately understand what it means for their daily work? If the answer is no, it’s not done yet.
Crafting a useful platform engineering vision is less about writing and more about listening — then making hard choices about what you heard.
The worst visions start with “Where do we want to be?” The best start with “What’s broken today, and for whom?”
Before writing anything at AutoScout24, I spent weeks in one-on-ones with engineering managers, tech leads, and individual developers across product teams. Not surveys — conversations. Surveys give you aggregated sentiment. Conversations give you stories, and stories reveal the structural problems that surveys miss.
What I heard consistently: teams were spending disproportionate time on infrastructure setup for new services. Each team had slightly different CI configurations, different monitoring setups, different deployment approaches. Onboarding a new engineer to a team meant learning that team’s specific tooling quirks. And when we acquired companies through Trader Inc., the gap widened further — acquired teams had entirely different operating models, and aligning them was a multi-quarter effort driven by tribal knowledge rather than shared infrastructure.
These pain points became the foundation of the vision. Not “build a great platform” but “eliminate the infrastructure tax on product teams and make the right way the default way.”
A vision gains credibility through its boundaries. At AutoScout24, our platform vision explicitly excludes certain things: we don’t build bespoke solutions for individual teams, we don’t optimize for maximum technology choice, and we don’t own application-level concerns like business logic testing. These exclusions matter because they prevent scope creep — the silent killer of platform teams.
Every platform organization faces pressure to absorb adjacent responsibilities. “Can the platform team also own our data pipeline tooling? What about our ML infrastructure?” Without a clear vision that defines boundaries, the answer is always “maybe,” and “maybe” eventually becomes “yes” through accumulated precedent.
The best visions have a built-in test for failure. Ours implies measurable conditions: if teams still can’t go from idea to production without filing tickets to another team, we’ve failed. If the paved path is harder to use than the workaround, we’ve failed. If acquired companies take more than two quarters to onboard onto the platform, we’ve failed.
You don’t need to embed OKRs into the vision statement itself, but the vision should point clearly enough at reality that you can construct metrics from it. More on this later.
Team alignment is one of the most overused phrases in engineering leadership. It usually means “we had a meeting where everyone nodded.” Real alignment — where teams actually change their behavior because they share a common understanding — is harder and rarer.
Running an offsite where everyone agrees on the vision isn’t alignment. Alignment is when a team independently makes a decision that’s consistent with the vision without being told to. That requires the vision to be concrete enough to guide decisions and repeated often enough to be internalized.
At AutoScout24, alignment manifests in daily work through a few mechanisms. Our OKR structure connects platform goals to broader organizational outcomes. Each Key Result maps to something the vision promises — reduced time-to-production, increased paved-path adoption, lower incident rates. Teams own initiatives that contribute to these KRs, and they have autonomy over implementation. The vision provides direction; the teams provide execution.
The hard part of alignment isn’t getting people to agree in principle. It’s handling the moment when two reasonable interpretations of the vision conflict.
For example: should the platform team invest in supporting a legacy compute model (EC2-based workloads) or push teams toward Kubernetes migration? Both are defensible. The vision alone doesn’t answer this — but it provides the framework for the conversation. If the vision prioritizes self-service and consistency, then supporting two equally good paths is better than forcing migration and creating resistance. If it prioritizes reducing operational surface area, then a migration timeline with support might be the right call.
We chose to support both — Kubernetes as the default paved path, EC2 with standardized AMIs for teams that aren’t ready to migrate. The vision guided the decision: we optimized for developer autonomy over platform simplicity. We accepted the operational cost of maintaining two paths because forcing migration would have violated the self-service principle the vision is built on.
Document these decisions and their reasoning. They become precedent that teams can reference when similar questions arise later.
“Foster collaboration” is easy to say and hard to operationalize. In practice, cross-team collaboration on platform work requires specific mechanisms:
A shared backlog or roadmap that product teams can see and influence. At AutoScout24, we use a GitHub Project dashboard that’s visible to all engineering teams. They can see what the platform team is working on, what’s coming next, and where their feedback shaped priorities.
Regular demo sessions where platform teams show what they’ve built and product teams share how they’re using it — or not using it. The “not using it” feedback is the most valuable. It reveals where the platform’s mental model diverges from how developers actually work.
Explicit feedback channels. We use Slack and regular demo meetings, but the mechanism matters less than the norm: platform teams actively seek out friction reports and treat them as product feedback, not complaints.
Stakeholders don’t resist platform investments because they’re unreasonable. They resist because platform work is often communicated in a language they don’t speak.
A CTO doesn’t care about your service mesh. They care that deployment failures have dropped by 40% since you introduced standardized rollout strategies. An engineering director doesn’t care about your internal developer portal. They care that new hire onboarding time went from three weeks to five days because every team uses the same development workflow.
When I present platform progress to stakeholders at AutoScout24, I never lead with technology choices. I lead with outcomes: we reduced high-severity incidents by 54%. Time to first production deployment for new services dropped from weeks to days. Paved-path adoption reached a specific percentage across teams. These numbers translate directly into business impact — faster delivery, fewer outages, lower operational cost.
Different stakeholders hear different things in the same vision. The Head of Security hears “guardrails and compliance by default.” The CTO hears “faster delivery with fewer incidents.” Engineering managers hear “my team spends less time on infrastructure.” Product leaders hear “features ship faster.”
This isn’t manipulation — it’s accurate translation. A good platform vision genuinely serves all these interests. Your job is to make that connection explicit for each audience. I schedule one-on-one conversations with key stakeholders — CTO, Head of Security, engineering directors — before any formal presentation. I learn what they’re measured on, what keeps them up at night, and how the platform connects to their goals. The same vision, communicated through different lenses.
Skeptical stakeholders don’t convert through arguments. They convert through evidence.
During a reliability initiative at AutoScout24, several engineering managers were concerned that platform standardization would slow down feature delivery. Rather than debating the point, we focused on one team as a pilot. We onboarded them onto the paved path, measured the before and after, and shared the results: deployment frequency increased, incidents decreased, and developer satisfaction improved. That single data point was more persuasive than any slide deck.
Identify your most skeptical stakeholder and solve their most visible problem first. The resulting goodwill funds the rest of the roadmap.
A vision without measurement is just an opinion. You need feedback loops that tell you whether the organization is actually moving toward the future state you described.
Not all metrics are created equal. The ones that matter most for a platform engineering vision are those that measure whether the platform is fulfilling its promise to developers.
Paved-path adoption rate. What percentage of teams are using the standardized platform path versus custom solutions? This is the single most important leading indicator. If adoption is low, either the paved path doesn’t solve real problems or it’s harder to use than the alternative. Both are fixable — but only if you’re measuring.
Time to first production deployment. How long does it take a new service to go from creation to running in production? This measures whether the platform actually removes friction. At AutoScout24, we track this and treat regressions as platform bugs.
Developer satisfaction. Surveys have limitations, but directional trends matter. We run periodic developer experience surveys that specifically ask about platform tooling. A satisfaction score that’s declining despite feature launches tells you something important.
DORA metrics — with context. Deployment frequency, lead time, change failure rate, and mean time to recovery are useful but insufficient alone. They measure delivery performance, not platform effectiveness specifically. Track them, but pair them with platform-specific metrics that isolate the platform’s contribution.
Toil reduction. How much time are developers spending on infrastructure work versus product work? This is hard to measure precisely, but even rough estimates — through time tracking, ticket analysis, or interview data — reveal whether the platform is delivering on its core promise.
The vision describes a destination. The metrics tell you whether you’re getting closer. The gap between the two is your backlog.
At AutoScout24, we review platform metrics quarterly and adjust priorities based on what the data shows. If paved-path adoption is high but satisfaction is dropping, we know we’re creating compliance without delight — the platform works but it’s painful. If adoption is low but satisfaction among adopters is high, we know we have a distribution problem, not a product problem.
Treat the vision as a living document. Not in the corporate sense of “we’ll update the PowerPoint annually,” but in the operational sense: the vision shapes decisions, decisions produce outcomes, outcomes inform whether the vision needs refinement. At some point, you’ll achieve parts of the vision and need to extend it. That’s a sign of success, not instability.
Here’s what I’ve learned after years of leading platform organizations: the vision is not a document you write and distribute. It’s an argument you make and defend — in roadmap reviews, in prioritization discussions, in architecture decisions, in hiring conversations, and in stakeholder updates.
A strong platform engineering vision does three things. It tells product teams why the platform exists and what it will do for them. It tells stakeholders what outcomes to expect and how to measure them. And it tells the platform team itself what to build, what to skip, and how to make trade-offs when resources are finite.
The platforms that succeed are the ones where the vision is specific enough to be useful, honest enough to acknowledge trade-offs, and embedded deeply enough in daily work that it shapes behavior — not just slides.
Build your vision around the pain your organization actually has. Define it by what you won’t do as much as what you will. Measure it relentlessly. And defend it when the pressure to be everything to everyone inevitably arrives.
The direction of travel for Platform Engineering is clear. What matters now is whether your vision is specific enough to guide the journey.
]]>It generates revenue, customers depend on it, and nobody wants to touch the payment module that Dave wrote in 2017 before he left. Every feature request takes three times longer than it should. New hires stare at the codebase for weeks before making their first meaningful commit. And somewhere in a Slack channel, an engineer is typing the word “rewrite” for the hundredth time.
I’ve been in this exact situation at multiple companies. At AutoScout24, we inherited systems from acquisitions that were built with completely different philosophies, tech stacks, and quality standards. The temptation to burn it all down and start fresh is always there. But after years of leading platform and engineering teams through these transformations, I can tell you: evolution almost always beats revolution.
This article is an updated version of the one I published in 2019. What’s changed since then is how we evolve these systems. AI-assisted development, platform engineering, and modern observability have fundamentally shifted what’s possible. A refactoring effort that would have taken a team months in 2019 can now be measured in weeks — sometimes days.
Before you can fix a legacy system, you need to understand how broken it actually is. “It feels slow” and “the code is messy” aren’t arguments that will get you budget. You need data.
The metrics that matter haven’t changed much, but the tools have gotten dramatically better:
Code health: Static analysis tools like SonarQube or CodeClimate can quantify your technical debt in hours. AI-powered code analysis — through tools like GitHub Copilot, Sourcegraph Cody, or even a well-prompted Claude session — can now identify architectural smells that static analysis misses entirely. Feed your codebase to an LLM and ask it to map coupling between modules. The results might surprise you.
Deployment pipeline: How long from merge to production? If the answer is “days” or “it depends on who’s deploying,” you have infrastructure debt. DORA metrics (deployment frequency, lead time, change failure rate, mean time to recovery) remain the gold standard here.
Test coverage and runtime: Coverage below 60% in critical paths means you’re flying blind during refactoring. And if your test suite takes hours, forget about fast iteration — tests should enable speed, not slow it down.
Incidents and error rates: Track severity, frequency, and — critically — which components cause the most incidents. In one of the companies I worked at, this data alone revealed that 80% of our production issues came from 15% of the codebase. That’s where we focused first.
Team velocity trends: A gradual decline in velocity despite a stable team size is one of the clearest signals of compounding technical debt. Don’t just track it — make it visible to stakeholders who control the budget.
The goal isn’t to create a dashboard for the sake of dashboards. It’s to build a case. When you can show leadership that a specific component causes 40% of your incidents and slows feature delivery by 3x, the conversation shifts from “can we afford to modernize?” to “can we afford not to?”
The rewrite pitch is seductive: throw away the mess, start clean, do it right this time. I’ve seen it proposed at every company I’ve worked at. I’ve also seen it fail spectacularly.
A mid-sized company I consulted with decided to rewrite their customer management system — a core product that had grown unwieldy over ten years. The plan was eighteen months. It took three years. During that time, the old system still needed maintenance, splitting the team’s focus and budget. By the time the rewrite shipped, business requirements had evolved so much that the new system already felt outdated.
The fundamental problem with rewrites hasn’t changed: you’re recreating every feature, every edge case, every hard-won piece of domain knowledge — while the world keeps moving. What has changed is that the alternative — incremental evolution — is now significantly more powerful thanks to AI tooling and platform engineering practices.
Here’s the question I always ask teams proposing a rewrite: If the same engineers who built the legacy system are building the replacement, what exactly will be different this time? Unless the answer involves fundamentally better practices and skills, you’re just creating next decade’s legacy system.
Here’s something that wasn’t part of the conversation in 2019: platform engineering has emerged as one of the most effective ways to evolve legacy systems at scale.
Instead of asking each team to independently modernize their corner of the codebase, you build paved paths — standardized, well-supported ways of doing things that make the modern approach easier than the legacy approach.
At AutoScout24, this means our platform team provides golden paths for compute (Kubernetes-based), observability, CI/CD, and security. When a team needs to modernize a service, they don’t start from scratch. They migrate to the paved path, which comes with built-in best practices, automated compliance checks, and operational support.
The magic of this approach is that it makes evolution the path of least resistance. Teams aren’t “paying down tech debt” — they’re adopting a better developer experience. The framing matters enormously for organizational buy-in.
Practically, this looks like:
Internal Developer Platforms (IDPs) that abstract infrastructure complexity. Tools like Backstage or Port provide a unified interface where teams can provision environments, deploy services, and access documentation — without needing to understand the underlying infrastructure evolution happening beneath them.
Standardized templates and scaffolding. When spinning up a new service (or migrating an old one), teams start from a template that already includes logging, monitoring, CI/CD configuration, and security baselines. This eliminates an entire category of infrastructure debt.
Automated compliance and governance. Instead of manual reviews and checklists, policy-as-code tools (OPA, Kyverno) ensure that every deployment meets your standards automatically. Legacy services that can’t pass these checks become visible candidates for modernization.
The platform engineering approach works because it acknowledges a hard truth: you can’t force teams to modernize. But you can make modernization so much easier than the alternative that it becomes the obvious choice.
This is where things have changed the most since 2019 — and even since the early GenAI hype of 2023-2024. AI tooling has matured from “interesting toy” to “genuine force multiplier” for legacy system evolution.
Understanding legacy code. This is where AI shines brightest. Drop a poorly documented module into Claude, Copilot, or Cursor and ask for an explanation of the business logic, data flow, and hidden assumptions. What used to take a new team member weeks of archaeology now takes hours. I’ve seen engineers use AI to reverse-engineer undocumented APIs, map implicit dependencies, and generate documentation that didn’t exist before.
Refactoring at scale. AI-assisted refactoring tools can now handle transformations that would have been prohibitively tedious by hand: extracting interfaces, breaking up god classes, converting callback-heavy code to async/await patterns, even migrating between frameworks. The key is treating AI output as a first draft — always review, always test. But that first draft saves enormous time.
Test generation for untested code. This is arguably the highest-leverage use of AI in legacy modernization. Michael Feathers defined legacy code as code without tests, and he was right — you can’t safely refactor what you can’t test. AI can now generate meaningful test suites for existing code, covering happy paths, edge cases, and error scenarios. These generated tests aren’t perfect, but they provide a safety net that didn’t exist before, making subsequent refactoring dramatically less risky.
Migration assistance. Moving from one framework, language version, or API to another? AI tools can handle a significant portion of the mechanical translation, freeing engineers to focus on the architectural decisions and business logic that actually require human judgment.
But let’s be honest about the limitations. AI doesn’t understand your business domain deeply. It can’t make architectural trade-off decisions. It hallucinates. It can introduce subtle bugs that look correct at first glance. The teams that get the most value from AI in legacy modernization are the ones that use it as a power tool — wielded by skilled engineers who verify everything — not as an autopilot.
With the foundation in place — visibility into the problem, a platform to build on, and AI tools to accelerate the work — here are the strategies I’ve seen succeed repeatedly.
I keep coming back to this because it’s consistently the highest-ROI first move. Before you refactor anything, write tests for the existing behavior. Use AI to generate the initial test suite, then refine it manually. Once you have tests, every subsequent change becomes safer and faster.
The approach is straightforward:
Wrap legacy components behind clean interfaces. Route traffic gradually from old to new. Kill the old component when traffic hits zero. This pattern works beautifully with platform engineering — the new services live on your paved paths while the legacy components run on their existing infrastructure. Over time, the legacy surface area shrinks until there’s nothing left to strangle.
Not every component needs gentle evolution. Sometimes a module is so outdated — built on a deprecated framework, running an unsupported language version, or simply incomprehensible — that targeted replacement is the right call. The key is targeted: replace one module at a time, not the entire system.
Identify candidates by looking at: incident frequency, maintenance cost, developer pain (survey your teams — they know which parts of the codebase make them dread Monday mornings), and business criticality of upcoming changes that touch that module.
Moving from on-premises to cloud, from VMs to containers, from manual deployments to GitOps — these infrastructure-level modernizations can extend a legacy system’s life by years without touching the application code. Start with non-critical services, prove the pattern, then migrate systematically.
At AutoScout24, containerizing legacy services and moving them onto our Kubernetes-based platform gave teams access to modern observability, auto-scaling, and deployment tooling — even before they touched a line of application code. The operational improvements alone justified the effort.
Tools and strategies are only half the equation. The other half is people.
Why does technical debt accumulate in the first place? Partially because of business pressure, yes. But also because engineers — myself included — don’t always apply what we know. We’ve had decades of accumulated wisdom about clean code, SOLID principles, testing strategies, and system design. The Design Patterns book is over thirty years old. Yet I still see codebases where basic separation of concerns doesn’t exist.
The gap isn’t knowledge — it’s habit. You can name every SOLID principle and still write a 2,000-line controller class because that’s how the existing code looks, and matching the pattern feels easier than fighting it.
Breaking this cycle requires deliberate practice: code reviews that actually discuss design (not just syntax), pair programming on refactoring efforts, internal tech talks where teams share their modernization wins and failures, and — critically — time explicitly allocated for improvement. If every sprint is 100% feature work, technical debt will always grow.
The AI tooling shift makes this even more important, not less. When AI can generate code faster than humans can review it, the ability to evaluate, critique, and improve code becomes the differentiating skill. Engineers who deeply understand design principles will leverage AI to move faster. Engineers who don’t will just produce bad code faster.
If I were starting a legacy system modernization today, here’s the sequence I’d follow:
Month 1: Measure. Instrument everything. Get DORA metrics, incident data, code quality scores, and team velocity on a dashboard that leadership can see. Build the case with data.
Months 2-3: Foundation. Establish your platform — whether that’s a full IDP or just standardized CI/CD pipelines and deployment templates. Define your paved paths. Make the “right way” the easy way.
Months 3-6: Test and strangle. Use AI to generate test suites for critical components. Begin strangler fig migrations for the highest-pain modules. Celebrate early wins publicly — momentum matters.
Ongoing: Incremental evolution. Apply the Boy Scout Rule at scale: every change leaves the codebase better than it was found. New features go on paved paths. Legacy components migrate when they need significant changes. The system gets younger over time, not older.
This isn’t a six-month project. It’s a permanent shift in how your organization builds and maintains software. The companies that get this right don’t have a “modernization initiative” — they have an engineering culture where evolution is continuous.
A legacy system is a business asset that’s accumulated technical debt. It’s not a failure — it’s evidence that your software survived long enough to matter. The question isn’t whether to evolve it, but how deliberately you choose to do so.
]]>