Jason Gorman:

The hardest lesson I had to learn as a software developer in the early part of my career was that what felt “productive” to me locally – uninterrupted time, code getting created fast etc – often turned out to be a bad sign for overall team outcomes.

It’s as if the more time you spend being alone, creating solutions alone, and building things alone, the further you drift from your teammates.

there is no individual productivity in software development. There is only the team.

What’s that old proverb? “If you want to go fast, go alone. If you want to go far, go together.”

Well now it’s: If you want to go fast, build with AI. If you want to go far, build with a team (of people, not agents, duh).

Jason Gorman:

am I at all surprised by this revelation that – “with AI” – a team of 6 can deliver more value than a team of 26? No. It’s exactly what I’d expect, with or without AI.

Coordinating humans or agents, it’s still coordination.

The combinatorial explosion in lines of communication required to keep team members in sync applies whether those team members are human or AI.

Jason Gorman:

Computing has a long history of teaching us that there are many things we thought we understood that, when we try to explain it to the computer, it turns out we don’t.

This is true of computing specifically, but also many other intellectual exercises more broadly. To restate it:

There are many thing we think we understand that, when we try to explain it to someone else (in writing or by the spoken word), we realize we don’t understand it nearly as well as we thought we did.

Jason Gorman:

I recommend […] slowing down code generation to the speed of comprehension. When you’re drinking from a firehose, the limit isn’t the firehose.

This implies that we’re not limited by how many tokens/second “AI” coding assistants can predict, but by how many tokens/second we can understand. That’s the thing we need to optimise.

And what’s the best way to understand code?

To write it.

Repeatedly.

Jason Gorman:

I’ve seen so many times how 10 lines of code can end up being worth £millions, and 10,000 ends up being worthless.

some code is worth more than others

Jason Gorman:

I’m always struck by the chasm that can grow between […] developers genuinely believing they’re doing a great job while users just roll their eyes.

The truth cuts deep, eh?

So when a developer tells you that, say, Claude Code has made them 10x more productive, they’re not lying […but they are] usually based on measurements of things the customer doesn’t care about – lines of code, commits, Pull Requests etc.

Who cares if LLMs help you generate more when what people need from you is less: less bugs, less cognitive overload, less bloat, less unreliability, etc.

Jason Gorman says he hears these questions a lot:

“Why should I train my developers? They’ll just leave.”

“Why is it so hard to find developers with the skills I need?”

It’s like asking:

“Why should I plant a tree when I won’t get to enjoy its shade?”

Then immediately asking:

“Why isn’t there any shade around here to enjoy?”

As the old proverb says, “A bit of fragrance always clings to the hand that gives roses.”

Jason Gorman:

Watching team after team after team drop everything to try and tame the code-generating firehose, while real business and real user needs go unaddressed, is quite the spectacle. It’s a hyper-scaled dysfunction.

Why everyone really wants to be an “AI” company:

There’s no credible evidence that “AI” ten-times’s dev team productivity. But there’s plenty of evidence that it can 10x a valuation.

Bill writes a book with about 80,000 words. It takes him 500 hours.

Priti writes a book with about 60,000 words. It takes her 2,000 hours.

Which author is most productive?

It’s a nonsensical question, of course.

Beating a dead productivity horse: lines of code or commits?

If we create a software solution with the aim of reducing the cost of deliveries for our business, and the cost goes up, do we look in the repo to see if it was because we didn’t write enough code or do enough commits?

Also loved this quote by W. Edwards Deming:

If you give a manager a numerical target, he’ll make it even if he has to destroy the company in the process.

Jason Gorman shares five things he believes will make your teams more productive than AI coding agents.

Smaller teams are better value/$ spent

More frequent releases accelerate learning what has real value

Limiting work in progress – solving one problem at a time – increases delivery throughput

Cross-functional teams experience fewer bottlenecks and blockers than specialised teams

Empowered, self-organising teams spend less time waiting for decisions and more time getting sh*t done

Opening your checkbook and buying an AI team subscription is a great way to feel like you’re increasing productivity. But actually increasing productivity is harder than a credit card transaction.

AI is pitched like a pill: an easy fix for something that really requires a lifestyle change.

Jason Gorman:

When programmers get a feeling that they’re getting things done faster, they’re often only considering the part where they write the code – particularly when that’s their part of the process.

What they’re not considering is the whole software development process, and especially downstream activities like testing, code review, merging, deployment and operations.

Software developers are geocentric: the world revolves around them.

“A.I.” code generation’s a local optimisation that can come at the expense of the development system as a whole,

more code faster means bigger bottlenecks later.

Also, this on us programmers:

We, for the most part, do not [have established data interchange standards] probably because that would require enough of us to agree on some stuff, and that isn’t really our strong suit.

Jason Gorman:

Removing duplication is where some of our most popular libraries and frameworks came from.

Great abstractions in libraries came from removing duplication, not anticipating it. Remember this next time you go to make an abstraction.

This is an evidence-based approach to design. We don’t speculate that a function might be reused, we see where it will be reused; we see the need for it in the current code.

We like to think of software as machines, but the complexity of modern software systems is more comparable to biology. We’ve never built machines with that many moving parts.

Nature has a tried and tested way of solving problems of this level of complexity, though: EVOLUTION.

It’s Gall’s Law.

Complexity emerges one small, simple step at a time.

We might think that simpler code will be easier to write, but it turns out that, quite often, simpler is harder.

It takes more thought. It takes more discipline. And it requires us both to let go of preconceived ideas about design, and to let go of our egos.

If I’d had more time, I would’ve written a shorter PR.

Jason Gorman writing about LLMs and “AI”:

An honest marketing slogan for [AI] technology might be “Impressive, but wrong.”

AI & jobs:

If anything, all the low-quality code these tools are churning out is creating a Mount Everest of technical debt that will require even more developers to keep the wheels on their enterprises turning in the future.

Besides, why plant trees? We have lots already!

Businesses who’ve stopped hiring and training entry-level developers because “GitHub Copilot can do what they do” are going to find out what happens when nobody plants tomatoes because “Hey, who needs tomatoes? We’ve already got pasta sauce”.

Maybe, in the end, what we get out of AI is more expensive humans — a banger dose of irony:

[I] wonder if the final destination of all this research, all this fanfare, and all this MONEY [into building AI], might be a world where human experts are both the better and the cheaper option. That would be very funny.

Also: when will we understand this?

More code faster != more value sooner.

—Sigh— vendor studies.

Isn’t it marvellous how vendor-funded studies always seem to back up their claims?

vendors have a very real incentive to want us to believe that the big problems in software development can be solved with their tools.

Your ability to iterate and evolve your software is your advantage:

A typical software system used in business, for example, will have complex rules that are usually not precisely defined up front, but rather discovered through customer feedback. And in that sense, how quickly we converge on a working solution will depend heavily on iterating, and on our ability to evolve the code. This wasn’t part of their exercise.