Chris O'Donnell nails the experience of blogging:

I published a quick how-to […] Documenting it in the blog post took way longer than solving the problem. I threw up the blog post thinking one or two other people might find it interesting. Instead, I got dozens of emails thanking me for solving a problem that was apparently vexing to a lot of other people.

Been. Freaking. There.

1. You experience something.
2. It strikes you that you should write it down and share it.
3. You think, “Nah, it’s such a small, inconsequential thing. It’ll take longer to write about it than it did to do it!”
4. You do it anyway.
5. Turns out, tons of people find it useful.

Blogging is often just stating the obvious

Tom MacWright, after reviewing lots of LLM-generated job applications, which link to LLM-generated websites, which link to LLM-generated GitHub projects, which link to LLM-generated…

putting your art, writing, expression out to be judged by others is an act of bravery as much as talent, and a lot of people lack bravery. Sorry to say it but if you need your work to be polished and beyond reproach, that's a determination and character problem, not a skill problem.

Oh wait, that’s me. I want my work to be polished and beyond reproach. Shoot.

The fear is being found out for being imperfect.

Yup, afraid of that.

That said, I continually try to put stuff online under my name as an exercise against these fears.

Publish your typos and show your struggle

Great, humane advice.

Josh Collinsworth asks whether LLMs really are making us more productive (whatever “productive” means).

Think about it: if LLM code was reliably of higher quality than human code, then LLMs would be making software more accessible, more maintainable, more performant, more usable, and more reliable […]

we could expect [all domain experts] to be elated, if LLMs were actually moving the metrics they care about.

But that’s pretty much the opposite of what’s happening, as far as I can tell.

Instead, everywhere I look, specialized craftspeople are overwhelmingly burned out from fighting a losing fight to get people to care

The journey is the work:

A junior who made a mistake is one step closer to being a senior; a junior who let an LLM make a mistake (and had the LLM fix it for them) has probably learned nothing.

Lots in here that resonates with current, day-to-day experience:

If you’re opening PRs faster than anyone can read through them, you’re not increasing productivity; you’re clogging the bottleneck.

I [used the LLM] mainly [to] just check off a bunch of old to-dos, most of which were unfinished because they never mattered that much in the first place.

The more you take a big-picture, holistic view […] the more gains from LLM usage shrink

Code is not the product:

Building things got cheap, but building the right thing didn’t get any easier.

Even perfect code can still make bad products.

Oof.

The less you understand, the more you trust AI. But the more you trust AI, the less you understand.

John Gruber:

It’s a goddamn privilege for anyone to bestow your article, story, or product page with their attention. The gall, to deliberately interrupt them while they are in the middle of actively reading, to present them with a dickover. It is no different from snatching a physical copy of a book or magazine out of a reader’s hands in order to badger them for something other than the attention they were already granting your work, except that the physical act of snatching a publication from a reader’s hands would subject you to being punched in the face.

Tom & Corissa have a great question we should all ask ourselves.

Are your metrics being used:

as clues to figure out what’s going on, so you can deliver value to customers

Or:

as tools to support a narrative you want to peddle.

Chris Loy:

the industrialisation of production is giving rise to a new class of software artefact, which we might term disposable software: software created with no durable expectation of ownership, maintenance, or long-term understanding.

Not gonna lie, that seems like a pretty good bet.

Industrial systems reliably create economic pressure toward excess, low quality goods. This is not because producers are careless, but because once production is cheap enough, junk is what maximises volume, margin, and reach. The result is not abundance of the best things, but overproduction of the most consumable ones.

Here’s one to ponder:

Technical debt is the pollution of the digital world, invisible until it chokes the systems that depend on it. In an era of mass automation, we may find that the hardest problem is not production, but stewardship. Who maintains the software that no one owns?

Mandy Brown with a reminder about how fuzzy language can be. It’s relative to the speaker and the listener!

When workers talk about increasing their productivity, they often speak of getting more work done in the same amount of time […] But when companies talk about productivity, they are much more likely to be talking about the cost of the work. The descriptions are, at some level, equivalent, but they emerge from very different political standpoints and have entirely different impacts on people’s lives.

When it comes to increasing productivity, one man’s “more work in less time” is another man’s “fewer workers”.

Faros Research names their findings the “acceleration whiplash” because:

AI has flooded a system built around human-paced development and human-quality code with output it was never designed to absorb.

Fascinating findings, such as:

[AI] is now the primary author of code. This did not happen as a deliberate decision by most organizations.

Or:

The business value is real […] more features shipped, more initiatives completed, more code entering the codebase than at any prior point in our dataset. AI productivity gains at the business level are real

And yet, none of that is tied in any meaningful way back to customer success. It feels good to people inside the business because, hey, all that drudgery we’ve created for ourselves — backlogs, KPIs, tasks — it’s all getting completed faster than before. But is it actually helping anyone outside of the business? Who knows. Or, perhaps more frighteningly, who cares?

It’s creating a reliability problem in software:

For every code change merged, the probability of a production incident has more than tripled […] What started as a productivity conversation has become a reliability problem.

And it’s not getting better. It’s getting worse!

The relationship between AI adoption and defect rate is not flattening as organizations mature their AI programs; it’s steepening. More AI-generated code in the codebase correlates with more bugs per developer, and that relationship is strengthening as adoption deepens.

It’s a sad state of affairs:

The engineers with the deepest knowledge of the system are spending their most valuable hours unraveling plausible-looking code that should never have reached them in the state it did.

There’s a lot in this summary that articulates feelings I have, and for that reason I enjoyed it.

Carson Gross:

the LLM can produce code far faster than you, or anyone else, can understand it.

Code is cheap. Understanding code is rare, and thus expensive.

You’ve heard of the “10× engineer” who can produce a mythical amount of code? Well now we’re all 10× engineers who can debase a codebase that took years to build in mere moments.

I have seen prolific coders who lack a proper fear of complexity heap more and more code on top of an existing problem until the whole system collapses into an unmodifiable steady state, where any change creates as many bugs as it fixes.

LLMs are incapable of fear of complexity, and are prolific coders.

Embrace your humanity and show some fear! Fear the complexity.

Carson’s proposal?

To address this danger of LLM-generated code, I propose the subtractive, constraining engineer:

This engineer says no, closely examines LLM output, suggests simplifications and generally retains a firm hand when dealing with LLM-generated code.

Be willing to say no in the face of abundance.

Be afraid to say yes and proud to say no.

more sculptor and less builder

Be as proud of what you didn’t do to the codebase, as what you did do to it.

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).