Living on the Edge

I tried to hold myself back with writing about AI. It felt like I didn't have enough insight. Besides, everything related to AI changed so fast in the last 2 years that I didn't feel that anything I could write down will still be valid tomorrow. So I didn't, until now.

After struggling through several mind shifts, discussions and sleepless nights about how to best deal with the incoming flood of code, I think I see a pattern now, and I wanted to share it.

In an attempt to stay true to my own voice, I didn't use AI writing this, just a dictionary and spell checker.

Part 1: Die ich rief, die Geister #

In software engineering, a critical part of the job is to manage complexity.

Our tools evolve, allowing us to handle more complex systems over time. When we switched from writing assembly to compiled languages, this allowed us to create larger systems safely. Building protocols and frameworks on top gave us the power to create globally distributed systems communicating through encrypted streams of data without understanding cryptographic algorithms, encoding, or routing.

But at any point in time, you had the possibility to stick more complexity in a single system than you could handle, and build features faster than you could keep track of unwanted side-effects.

If you did, this would result in a buggy product, a bad user experience, security issues, downtime.

With the AI coding tools created in the past years, the speed at which we can build more complex systems has undeniably changed. The complexity you can reasonably pump out today is already much higher than 6 months ago, and it is not clear to me how this will continue to evolve. If someone claims to do, they probably want to sell you something.

But despite all those changes, how much complexity we can handle in a system has always been and still is the limiting factor for what we can build, maintain, and evolve, without it collapsing. John Ousterhout wrote in A Philosophy of Software Design that cognitive capacity and system complexity are the true limiting factors. I am positive that this hasn't changed, even if we're not writing the code ourselves anymore. The frontier of complexity just shifted by a lot.

The good news about it: The profession of software engineering will most likely not go away.

The bad news: It will continue to be a struggle. Because we're living on the edge of complexity. Balancing between what is possible to manage, and where the systems get so complex that they break down. Delivering the most sought after software as quickly as possible, because if we don't, someone else will.

Part 2: Werd’ ich nun nicht los #

To ensure the complexity doesn't grow faster than we can keep it in check, we committed to certain principles in software engineering. Paradigms limiting the expressiveness of our languages, style guides and patterns giving us a shared vocabulary and familiarity, automation of checks and repetitive tasks, redundancy where processes and systems can fail.

But the tools to produce complexity that are accessible today are outrunning many of the checks we have put in place.

One thing I can clearly see in many services, software products, and in my own job: the processes we have relied on to ensure quality in software for the past 20 years are failing.

Writing automated tests meant that you have to express the same thing you want in multiple ways. If you vibe-code both your tests and your code, you don't. If you ask a peer to review 5000 lines of code every day (just being conservative), you can't expect them to find a lot of flaws in it, let alone keep control over abstractions, conciseness, and beauty. How do your users keep track of the changes you roll out after you 10x the number of features in each release? And how do you keep track of the bugs in it? If you relied on documentation and tests as a signal for high quality and well thought out code, you're long lost.

If we want to keep control over what we ship, slowing down is one option. But more importantly, we will have to find new ways how to deal with rapidly evolving complexity. Ways that are true to the new constraints in which we build systems, and that can deal with higher speed. The principles probably haven't changed, but the tools and processes have to.

I don't have an answer yet to how those new ways might look like, but there is a looming pile of complexity, and if we don't adapt quickly, it will come down on us. Many of the things you used to do might not be good enough anymore. Take a step back and think about why you're really doing something in your software development cycle. Come up with new ideas how to accommodate it to our new world. It might save your uptime, your data, your job. Keep your eyes open how others do it, share your ideas, and stay human.