2 min read

Speed 2.0 vs. Speed 1.0 (or, AI vs. Agile)

Speed 2.0 vs. Speed 1.0 (or, AI vs. Agile)

For the record, I'm pretty fast. At football camp in college, I had the 3rd fastest time in the 40-yard dash on the entire team. In baseball, I loved stealing bases, or taking extra bases when the defense wasn't expecting it.

So it's no surprise that when it came to shipping software in my career, I wanted us to be fast. In the early days, you did this by being focused (including making sure you had good specs before starting), and using the best tooling and tactics available—code completion tools (which were janky to start, but got better fast (see what I did there?), re-use via well-organized snippets and libraries, etc.

Then fast became a culture. The Agile Manifesto came out in 2002, the year after Mike and I started Webapper. This was the crystallization of a long trend towards speed and efficiency. Agile birthed continuous integration and continuous deployment, and a whole host of other tools and processes that made software delivery speedier, especially compared to the past.

We made ourselves agile. Even as a tiny company, we hired agile experts in those early years, to make sure we were doing it well (notice I didn't say "right," which is a common mistake in agile). We were doing DevOps before it even had a name. Every 2 weeks (sometimes faster), we were shipping software—crafted, tested, delivered, done. We won projects because we were faster. We kept clients for longer because we were faster.

AI is different. It's not even accurate to call it Speed 1.0 (Agile) vs. Speed 2.0 (AI). Early in our own AI transformation, we were delivering at Speed 3.0 (3X faster). 5X-10X is entirely realistic, if you know what you're doing. And this ISN'T due to having a bunch of "10X" engineers on your team (which I'm not, by the way). It's because AI systems actually build software that fast. We're now somewhere in the 3X to 5X range, and we're not slowing down until something breaks (and it will; that's a feature, not a bug; it's part of the process). Then we'll just add some guardrails and even better AI orchestration, but we're not slowing down.

It's exhausting. I feel it. I know you feel it. Pretty much everyone who's deep into AI tech is talking about it. We've got a whole new vocabulary growing up around the problem—"AI Brain Fry," AI decision fatigue, etc. This last one is the one I personally experience the most. We are able to generate so much more progress, and faster, and across so many areas of operations in parallel, that the bigger challenge for us now is building enough AI to be able to handle all the information (including code!) that AI generates for us, but while still keeping our humans in the loop.

And as Andre Agassi once said (as told to him by a coach who changed the trajectory of his career)—"Get yourself tired. There are good things waiting for you on the other side of tired." I'll be honest—I'm a little tired. But the speed is thrilling, and especially given that our quality hasn't suffered. There are good things waiting for us on the other side of "AI tired."

This is Sigmund, and thanks for listening.