The Faster & Better Club

Software design in the AI era, the hottest new club in town, and the one rule you must follow to join it.

Oh, hey! Hi! Hello! Welcome to the very first issue of this brand new, still-a-little-warm, and very much rough at the edges newsletter.

It's always a bit awkward to write a first post on a new platform. Should I introduce myself? Is it rude if I don't? I'm quite new to Substack, so I hope you'll forgive me if I'm breaking protocol here.

My name is Maxi, I am a Staff Engineer at Help Scout, and I've been trying, failing, and sometimes succeeding at building software for the past 20 years.

I won’t bore you with my whole life story here, but I do want to share a tiny piece of it to help set the scene for what you can expect from this newsletter. So I hope you brought some snacks and an extra set of clothes, because we’re going to take a trip back to 2006—the year Twitter and the Nintendo Wii came out, James Blunt’s “You’re Beautiful” was blasting through your headphones, and the movie people wouldn’t stop talking about was… High School Musical?

You bet it was. Photo by Disney, I guess.

I started my career in tech working at a number of agencies—some big, some small, all of them messy. My favorite part of the job was hopping between the many projects and teams I was fortunate to have access to. One month I was building a proof of concept for an indie film studio; the next I was writing ActionScript code for an internal analytics tool; and soon after that I was writing PHP and MySQL for a financial app owned by a giant corporation. It was all very chaotic, and I loved it.

Over time, I started to notice something.

Most of the teams I worked with faced the exact same challenge: they were drowning in tech debt and would often get bad performance reviews because they shipped increasingly buggy features at a very slow pace. But a few of the other teams—the ones that got all the praise and everyone wanted to be a part of—somehow managed to do the opposite; they delivered products both quicker and with higher quality.

They shipped faster and better.

This wasn't a greenfield vs. legacy codebase kind of situation. In fact, the common trait among the effective teams was that they all worked on established codebases, and that they've been working on them for years.

Some of the codebases the effective teams worked on were absolutely massive. But somehow, they seemed to be immune to the grip of tech debt and software complexity. It was like every time they had to make a change, the codebase was already prepared for it. Every new feature clicked into place, which made the next one even easier. Quality led to speed. Speed reinforced quality. It was a beautiful loop and it worked like a charm.

At the time, that just didn't seem possible to me. I was told that faster and better sit at opposite ends of the spectrum and that I had to choose between doing things fast and doing them the right way. "You either move fast and break things or take your time and do it right. Pick one."

But my beliefs were completely challenged by these teams who had a consistent track record of shipping fast without compromising quality. It's like they had the secret to managing complexity in large applications that nobody else knew. And I really wanted to know what it was.

What's your secret, super-effective team? *What did you see?*

It wasn't until the second half of my career that I learned the secret, which was, of course, that there was never a secret to begin with. The formula for shipping faster and better was simply a combination of strong tech leadership, good software design practices, discipline, and hard work. Nothing else.

The reason every feature clicked into place was that the codebase was well-designed, following established patterns and using tried-and-tested boring tech. And the reason it was well-designed was that the team had put time and effort into it, and had the discipline to keep the codebase from degrading over time.

From that moment on, I focused my career on learning everything that I could about software design and architecture. I believed—and still believe—that good design and a solid structure is the only sustainable way to ship faster and better.

So, down the software design rabbit hole I went. And I was happy in that hole, if I’m being honest. I spent my time reading lots of books and papers, watching some great talks, and exploring ideas with my own research. I even started a newsletter and made a free course to share what I learned with my fellow frontend engineers. It was a great time.

And then, just when I thought I got things figured out well enough to start making my way out of the hole... AI happened. And it kicked the ladder out from under me.

AI came into the scene with all its fancy LLMs, coding agents, and MCPs—and broke all of my mental models essentially overnight. Not because it made software design irrelevant (in fact, I'd argue that it’s more relevant now than ever), but because it changed the rules of how we build software.

AI kicking the ladder out from under me, according to AI…

I probably don’t need to tell you how chaotic and disconcerting it’s been to navigate the current AI wave. I’m sure you’re feeling it too. But amidst all the chaos that AI brought to the software industry, I've found something to be really excited about—and it's what got me to sit down and write these words you're reading right now.

What excites me the most about AI is that the recipe for building faster and better—which was previously only available to teams lucky enough to have the necessary experience and leadership—is now suddenly available to everyone.

These days, every developer has access to a thought partner who can help them better understand problems and make better decisions. One who’s read every manual, seen every pattern, and knows all the tradeoffs. A partner that is both an experienced architect and an eager intern—that can help come up with a beautiful design and implement it, up to spec, in record time.

Of course, AI also has the potential for the opposite effect, which is why we have to be intentional in how we implement it. Without the right process, coding agents can break havoc in our codebase to the point where it might end up damaged beyond repair.

You're probably familiar with some variation of "The Power of Tiny Gains", popularized by James Clear in his best-selling book Atomic Habits. The difference between getting 1% better and getting 1% worse might look insignificant on a daily basis—but it's orders of magnitude apart over the course of a year.

That's how I think about building with AI. We can use it strategically to make our codebase and designs 1% better every day, or we could use it in YOLO mode, committing the code it produces without even looking at it, at the cost of making our codebase a little bit worse every time.

The 1% better path leads to a codebase that lets us move fast without breaking anything. To a future where shipping both faster and better is not only possible, but inevitable.

The 1% worse path... well, I'm sure you know where that one ends.

So… what is this newsletter, again?

Ah, right! I almost forgot that was the question that started this whole thing. Sorry about that.

I like to think of it as a community… or, as a club. Let's call it The Faster & Better Club. A place to hang out with other nerds who care about building software that lasts.

Every week, we'll bring a new topic to chat about. It could be a design pattern, an architectural style, notes from an interesting book or paper, or a discussion on concepts like abstractions, coupling, and cohesion.

I can see you in the back yawning at that list, but I promise we'll keep it light and practical. More importantly, we'll keep it relevant to if and how these concepts are changing in the age of AI.

There's no application to join the F&B Club, and there's no fee you have to pay. There is, however, one very important rule you must follow. So important, in fact, that I've decided to name the newsletter after it:

You have to code like you mean it.

It doesn't matter if you write code using Cursor, Codex, Claude Code, or the soon-to-be-lost art of typing characters with your keyboard. It doesn't matter if you're writing code for the backend, the frontend, or... whatever the cloud is. You can code fast or slow, and you can use Vim or VSCode. But you have to code with intention. You have to code like you actually mean it.

You have to care about the code you write, and you have to make sure every line is pulling its own weight. AI is an incredible tool for producing source code, and we're going to take advantage of that. But we're not going to delegate our thinking. The part that gives meaning to the code we write—well, that's still on us.

In many ways, coding like you mean it is the complete opposite of vibe coding. Nothing against vibe coding, of course—I do it all the time and have a lot of fun building all those ideas and side-projects that have been collecting dust in my todo list for years.

Heck, I even think vibe coding has an important place in software design in the form of prototyping, which is something I'm excited to explore in a future issue.

But if you want to build software that will let you ship faster and better, you have to leave your vibe coder hat at the door and put your engineer hard hat on. It might not be as sexy or as cool, but when the beams start to fall from the roof (and they will), you'll be glad to be wearing one.

So if any of the things we talked about sound like your cup of tea (and if you agree to following our one rule), I cordially invite you to join The Faster & Better Club by clicking the subscribe button below.

We'll learn together, we'll laugh together, and yes, we might cry together from time to time as well. We'll meet every week in that room over there—coffee and snacks are provided, but please bring your own tissues.

See you soon.

— M

This is what the least cool members of the Faster & Better Club look like, btw. Photo by Antoni Shkraba Studio

---