The Old Complaint

For teams with a genuine choice, the knock on strongly typed compiled languages like Go, Rust, Java, and C# always came down to two very human gripes.

First, the overhead of defining types up front. Requirements are fuzzy, everything is changing, and you just want to see if the idea works. Defining types on half-baked code feels like ironing your shirt before you’ve decided if you’re going out.

Second, the compile step. Dynamic language developers had a beautiful, frictionless feedback loop: save the file, refresh the browser, see the result. Compiled language developers had: save the file, wait, fix the error, wait again, refresh, see the result. Across a full day of iteration that friction compounds. It’s not one paper cut — it’s a thousand of them.

Both were legitimate complaints. They’re also both largely gone now.

AI Took Away Those Excuses

AI can handle the type definitions you didn’t want to write. You describe what you want, the AI writes the struct, the interface, the function signatures. Your AI doesn’t cut corners and has never once thought “I’ll just use any here and fix it later.”

The compile step problem is subtler but real. When AI is generating your code, a meaningful chunk of iteration happens in the conversation before you ever hit compile. You’re not in a write-compile-fix loop anymore. You’re in a describe-generate-review loop, and then you compile once you’re reasonably confident. You can even get AI to compile the code first before it declares the job done.

So if both reasons engineers reached for dynamic languages have been largely addressed, what are you left with? All the benefits of a compiler — and right now those benefits matter more than ever.

The Compiler Is a Tireless Reviewer

Here’s the thing about AI generated code: it’s fast, it is occasionally, confidently wrong in ways that look completely right at first glance. AI hallucinates. It passes the wrong type into a function, references a variable that doesn’t exist, writes a function signature that almost matches what you need but not quite.

A compiler catches that whole class of bugs before they ever leave your laptop. Wrong types, mismatched signatures, undefined variables — dead on arrival at build time. The compiler doesn’t care that it’s 4pm on a Friday.

One thing the compiler can’t do: save you from bad business logic. If your discount function is calculating the wrong percentage, it’ll happily ship that bug to production with a smile. But eliminating an entire layer of preventable, AI-hallucination-class bugs before they touch production? That’s a free guardrail you’d be crazy to leave on the table.

“But Dynamic Languages Have Typing Now”

You’re thinking about TypeScript. PHP’s declare(strict_types=1). These are real and genuinely useful — I’m not here to dismiss them.

But optional typing is a cultural enforcement problem, not a technical one. And culture, as any engineering manager who has survived a deadline crunch knows, is the hardest thing to hold together under pressure. The moment a sprint gets hairy, someone skips the type annotation. Then someone else does. Then it’s a pattern. Then you look up six months later and half your codebase is untyped.

Optional typing is like a gym with an optional cardio policy. Sure, technically everyone could do cardio. A compiled strongly typed language has no optional cardio policy. The compiler is the policy.

So What Should You Actually Do?

First choice: Pick a strongly typed compiled language your team can hire for and live with. Go, Rust, Java, C#, Kotlin — pick your fighter. AI will help your engineers write it, and the compiler will help you not regret it at 2am six months from now.

Locked into a dynamically typed ecosystem? Enforce strict typing across every file from day one, at the CI level, no exceptions blessed by anyone including you. Do not plan to “add types later.” Later is a lie you tell yourself before a deadline and forget about immediately after.

The Tradeoff No Longer Holds

This isn’t an argument that dynamic languages are bad — they built the internet and will outlive this post. This isn’t an argument that AI is untrustworthy — it’s excellent most of the time and getting better every month.

This is a narrower argument for teams with a real choice in front of them. The two things that made strongly typed compiled languages feel expensive — type overhead and compile friction — have both been largely addressed by AI. What you’re left with is a choice between a codebase with a compiler watching your back and one without.

The cost disappeared. The benefit didn’t.

Why would you choose without?

As always, ship it.

Matthew

This is why software design, architecture, and good engineering discipline matter more in the AI era, not less. Readable code, testable modules, sensible abstractions — these aren’t just hygiene anymore. They’re load-bearing walls. AI will keep building on top of them, whether they can hold the weight or not.

Taste

When I say taste, I mean the accumulated judgment that comes from having personally broken things and lived with the consequences. Experienced engineers have battle scars. They skipped tests because they were in a hurry and paid for it in a production incident. They built something that wasn't modular enough and had to rewrite half the system when the business requirements changed. They operated a service through a traffic spike and learned — viscerally, at 2am — exactly where the seams were.

Those experiences load something into a senior engineer’s brain that I can only describe as a latent roadmap. It’s not written down anywhere. It’s a slow-burning awareness that runs quietly in the background. They’re implementing a feature and somewhere in the back of their mind a voice goes: “this data model is going to hurt us when we need multi-tenancy” or “we’re going to regret this tight coupling.” It’s there, running — and it wakes up at exactly the right moment, when a decision is about to get made that’s going to have consequences eighteen months from now. They also know when not to act on it. They can see the right long-term solution and still choose to defer it, because right now the business needs to ship. That’s years of calibration compressed into a gut feeling.

Let me give you a personal example. At one company I worked at, we had business logic hardcoded across web and mobile that should have been driven by a backend API. The team had been living with it for a while and nobody flagged it as a problem. To them, it was just how it worked. When I came in, something felt off immediately — built from years of seeing what happens when business logic lives in the client. One change in one place, reflected everywhere. Simple fix, but nobody saw it as a problem that needed solving. Had I not stepped in, the AI assistant would have kept right on hardcoding that business logic — efficiently, consistently, confidently — every time a ticket came in. It was doing exactly what it was asked to do. The problem is nobody was asking the right question.

That’s the crux of it. Junior engineers don’t know they’re perpetuating a bad pattern because from where they’re standing, there is no bad pattern. The problem is invisible to them — and AI has no way to surface it, because it’s pattern-matching against the same codebase they’re looking at.

AI-native engineers, through no fault of their own, simply haven’t had the time to load that latent roadmap yet. This matters more now because AI removes the natural friction that used to slow bad decisions down. A problematic abstraction can now be replicated across a codebase in an afternoon. Tech debt doesn’t just accumulate — it compounds, silently, until refactoring isn’t a sprint task anymore but a quarter-long initiative that requires everyone to stop shipping and fix the foundation.

What Do You Do?

Get the latent roadmap out of people’s heads. Encourage senior engineers to name it out loud — in planning, in design reviews, in passing. “Heads up, this is the kind of decision that tends to bite us in eighteen months.” Over time, junior engineers absorb the reasoning, not just the rule — which is how they eventually build their own version of it.

Pair the people who have the scars with the people who are fast, as I’ve written about in The New Power Duo of Pair Programming. AI-native engineers bring speed and tool fluency. Experienced engineers bring the latent roadmap and pattern recognition. The pairing isn’t about supervision — it’s about cross-pollination.

AI isn’t going anywhere. The teams that get the most out of it are the ones who pair it with strong engineering culture, not the ones who use it as a substitute for one.

Taste still matters. Maybe now more than ever.

As always, ship it.

Matthew

At what point in your career did you start smelling problems rather than just seeing them? How do you actively develop taste in your junior engineers? Let’s discuss in the comments below.

The incentive math was lopsided. The junior walked away with a month’s worth of lessons packed into a single afternoon. The senior walked away slightly behind on their sprint commitments and with a mild headache. Some companies quietly did the math and stopped hiring juniors.

Then AI showed up and flipped the whole equation.

The AI-Native Junior Is a Different Animal

A new kind of engineer has entered the chat — literally. They grew up prompting. They can spin up a working prototype before you’ve finished writing the ticket. They iterate fast, they ship fast, and they are genuinely, almost aggressively, unintimidated by a blank file.

Their gap? They have no intuition for what “good” looks like at scale. Think of them like a race car driver who’s never changed a tire — thrilling to watch, right up until something breaks on the highway.

They’re not bad engineers. They just haven’t been burned enough times yet.

The Senior’s Blind Spot

On the other side of the table, you’ve got your experienced architects and senior+ engineers. Deep knowledge. Strong opinions. Battle scars from that one migration in 2019 that nobody talks about anymore.

Many of them are slow to adopt AI. Not because they’re lazy — they’re often the hardest working people in the room — but because they built their credibility on knowing things deeply. There’s a subtle identity threat in a tool that can approximate three years of accumulated knowledge in a single prompt. It feels like it’s cheapening something that was hard-won.

Here’s the honest truth though: if a junior can prototype in two hours what takes you two days, that gap is going to matter. The question isn’t whether AI is coming for your workflow. It’s whether you’re going to be the person who harnesses it or the person who explains to leadership why it doesn’t apply to your particular situation.

The New Pair Programming Duo

What if the lopsided math of traditional pairing finally got fixed?

Pair your AI-native junior with your systems-thinking senior. Not as a mentorship. Not as babysitting. As a genuine, bilateral skill exchange.

The senior brings: architectural instincts, an eye for long-term maintainability, the hard-won wisdom of knowing which shortcuts come back to haunt you six months later, and the ability to ask the uncomfortable “but what happens when this scales by 10x?” question before it becomes someone else’s 3am incident.

The junior brings: fluency in AI tooling, prompting patterns that actually work, an uncanny ability to iterate without ego, and a willingness to try things that a more experienced engineer might dismiss out of habit.

Neither person is the teacher. Both people are the student. That’s new, and actually exciting!

Why This Is a Win-Win-Win

The senior finally gets to harness AI without the steep learning curve of figuring it out alone. Their architectural instincts don’t get replaced — they get multiplied. Suddenly they’re not just the person who knows where the bodies are buried in the codebase. They’re the person who can also move fast enough to matter.

The junior gets something that used to take years: real-time, in-context exposure to systems thinking on actual production problems. Instead of slowly absorbing hard lessons over three years of being quietly corrected in code review, they’re getting the “why” in the room, in the moment, when it’s directly relevant to what they just built.

The company gets juniors who become net positive contributors faster, seniors who are dramatically more productive, and an org that isn’t quietly accumulating AI-induced tech debt because everyone was just prompting their way through things without any architectural guardrails.

It’s the first time in a while where both people in the pairing leave the session smarter than when they walked in.

How to Actually Make It Work

Good intentions don’t make good pairings. Here’s what does:

• Junior drives the keyboard, senior drives the thinking, both asking questions throughout

• Senior’s job is to ask “what happens when...”

• Review the AI’s output together before committing — this is where the most learning actually happens for both sides

• 5-minute retro at the end of every session: one AI thing the senior learned, one architecture thing the junior learned

• Pick the right problems — greenfield features and architectural inflection points, not bug fixes

• Rotate pairs every few months — let seniors pair with different juniors so the AI fluency spreads across the org, not just one relationship

That last one is the most underrated. A single great pairing is a nice anecdote. Rotating it intentionally turns it into an org-wide capability upgrade. The goal isn’t one senior who’s good at AI. It’s a whole engineering culture that knows how to use it without losing the plot on what good software actually looks like.

Every generation of engineers has had its version of "the thing the old guard resisted and the new guard couldn't live without." This is ours. The seniors who embrace it don't just stay relevant — they become the most dangerous people in the room. The juniors who get paired with them don't just grow faster — they skip entire chapters of the slow, painful learning curve that the rest of us had to slog through. That's not a productivity hack. That's a generational transfer of knowledge happening at AI speed.

Have you tried pairing with an AI-native engineer yet? What surprised you? Let’s discuss in the comments below.

As always, ship it.

Matthew

I didn’t stop there. With my team’s blessing and guidance, I started making meaningful changes in codebases I barely knew. I cleaned up years of accumulated tech debt and backfilled missing unit tests that had been on my team’s to-do list forever — work that would have taken weeks — and knocked it out in a few days while juggling my leadership duties.

If you’ve used AI coding tools seriously, you know exactly what I’m talking about. It feels like a cheat code.

But here’s the thing that’s been nagging at me: when code becomes this cheap and fast to produce, something else has to give. I think we haven’t fully reckoned with what that is yet.

The 3-Legged Stool

There’s a concept I’ve always called the 3-legged stool of project management. The three legs are Scope, Time, and Resources. The constraint is that you can only have two out of the three legs. Want to ship fast with a big scope? You’re going to need a lot of resources. Want to ship fast with a small team? You’re cutting scope. Want to do it all with limited resources? You’re going to be slow. Pick two. That’s always been the deal.

Every engineering team lives inside this constraint whether they know it or not.

AI just swapped out a leg.

Resources — specifically the cost and speed of writing code — have been fundamentally disrupted. What used to take a week can take an afternoon. What used to require deep expertise in a framework can now be done by someone willing to have a detailed conversation with an AI tool. The marginal cost of a unit of code is approaching zero.

So if Resources are no longer the binding constraint, something has to take its place. I’d argue that something is Quality. The stool still has three legs. They’re just not the same three legs anymore: Scope, Time, and Quality.

The biggest threat to that new Quality leg? Scope. Left unchecked, Scope is what will squeeze Quality out of the picture entirely.

Why Scope Creep is the New Bottleneck

Here’s what happens when code gets cheap: everyone suddenly has more ideas. The PM wants two more features. The CEO wants a dashboard. The designer has “one small tweak.” Why not? It’s so easy now, right?

This is the trap. Cheap code doesn’t mean cheaper decisions. Every feature you add still has to be reviewed, tested, integrated, maintained, and understood by your team six months from now. The thinking, the judgment, the tradeoffs — AI doesn’t do any of that for you. Scope creep has always been dangerous. With AI it becomes supercharged, because the usual forcing function — “we don’t have the bandwidth” — is suddenly a lot harder to say with a straight face.

This is exactly where Quality gets squeezed. AI-generated code can be fast, voluminous, and subtly wrong all at the same time. I believe AI will get much better in short order, but the reality now is that the more scope you allow in, the more surface area you create for things to go sideways.

So What Do You Actually Do With This?

A few things I am telling my team right now:

Be more ruthless about scope than ever before. The temptation to pile on is real and it will kill you. Define what you’re building, lock it, and defend it like your quality depends on it — because it does.

Keep your PRs as tight as they were before. Just because AI makes it easy to write or update a lot of code at once doesn’t mean you should cram it all into one PR. Keep the same discipline you had before — focused, contained, reviewable. Your teammates still have to read that code. Split up your PRs the way you always did. If your review bar is already high (raise it if not), then it doesn’t need to change much. Keep your PRs tight and your review process should stay as smooth as it always was.

Recognize where the real constraint moved. It’s not code anymore. It’s judgment — yours, your team’s, your senior engineers’. That’s the scarce resource now. Protect it accordingly.

AI swapped out a leg of the stool. Resources is out. Quality is in. Scope is the thing that will topple it if you're not watching.

How is AI changing how you think about scope and quality on your team? I’d love to hear what you’re seeing in the trenches.

As always, ship it.

Matthew

I’m Matthew Chan. Here’s the quick version of my story: I started as engineer #3 at Wattpad, where I helped scale the platform from 2 million to 60 million monthly active users. That experience was a masterclass in what happens when growth outruns your architecture — and how to stay ahead of it. From there I moved into engineering management, led teams at Muse and League, and eventually became CTO of Blackcart, where I built and led the product and engineering orgs that powered try-before-you-buy for leading Shopify merchants. These days I’m Head of Funding Engineering at Gemini, leading an org that powers fiat movement across the global crypto exchange.

I’m all in on AI. I use it every day and it’s changing how I lead, how my teams ship, and how I think about managing people and systems. You’ll hear a lot about that here — the wins, the pitfalls, and many open questions.

Also, I’m an angel investor, fractional CTO, and startup advisor. If you’re an early-stage founder trying to figure out your technical strategy, hiring your first engineers, or just need a seasoned sounding board — I’d love to connect.

Along the way I founded a STEM education company — seven locations, 1,700+ students a year, 30+ instructors — because apparently I don’t like having free time.

Outside of work, I’m a dad of two boys, which has honestly taught me more about patience, negotiation, and managing chaos than any leadership course ever could. A few years ago my family and I packed up our life in Toronto and moved to New York — a transition that was equal parts exciting and terrifying, kind of like every major engineering decision I’ve ever made.

But none of those wins came easy. They came from hard conversations, bad calls, late-night outages, and a whole lot of trial and error. And that’s exactly what this blog is about.

Whether you’re a new engineering manager trying to figure out how to give your first piece of tough feedback, a startup CTO holding together a product that’s scaling faster than your team can handle, or a Director of Engineering trying to keep 200 people rowing in the same direction — this blog / newsletter is for you.

Every post is going to be practical, real, and a little bit battle-scarred. No theory for theory’s sake. No fluff. Just nuggets from the weeds — real talk for engineers who lead.

Let’s get into it!

— Matthew