Even if the fantasy that AI will speed coding by 100% or more were true, it would not decrease lead time. Firing half of your people because of an immagined 100% improvement in the other half will also not relieve the bottleneck.
9/10

Work is always relative to what others are doing, using available tools. To be best-in-the industry, you need to have either higher quality output than everyone else, or more output than everyone else.

So if everyone uses better tools: you'd either do better work with them, or work more!

What IS a mistake (in my opinion) is to apply this tried-and-tested approach to software design (i.e., divide-and-conquer, separation-of-concerns, etc.) to the software development/delivery process. Creating silos in the flow (i.e., the value delivery stream) is a terrible idea.

The fact that some problem is complicated often stems from its not being sufficiently broken down. An "if" statement in a user story, for example, tells me that it's actually two stories, one for the "if" branch and one for the "else." Complex problems are often packed with logic of that sort.
2/7

For example, organizations that use mob/ensemble programming 100% of the time do not need standups. (And, just to cut off the comment: no, that is not less efficient. Many ensembles work faster than they did when they were working as individuals.)
6/10

You cannot make even small changes to a system of work without considering the system as a whole and making systemic adjustments.

So, if you want to remove that standup, you need to adjust the overall system to compensate.
5/10

"It’s the loud person who’s wrong getting their way because the quiet person who’s right won’t speak up. [...] The only question is whether you’ll get good at it or keep losing to people who already are."

A bit harsh. It's not that simple. Topic very interesting nevertheless.

10/
And last but not the least: don’t overcommit.

Happy building 🌟

9/
Let your engineers use their expertise and give them time, just as you would with any other way of building software.

8/
Don’t let non-engineers build — unless it’s inside a team that includes software engineers, especially if domain processes are involved.

7/
Prefer small helper apps with no real consequences on domain processes.

6/
Ok, so now what?

First, choose carefully what you’re building. Unless you follow all the guidelines and you’re very confident in your team’s ability to build high-quality software, don’t use LC/NC for core or supportive domain business apps.

And even then I would not recommend.

5/
And 50% of your builders? Not trained at all but are eager to continue.
Not forgetting your apps are NOT portable, at all.
Good luck with that.

4/
That’s when you realize: you need craft and software engineering expertise more than ever.

But here’s the catch: you’ve opened Pandora’s box.
You’re back in the same big ball of mud as you used to — except now everything is worse.

Monitoring is worse.
Testing is worse.
Refactoring is worse.

3/
Refactoring capabilities? Almost nonexistent.
Static analysis? Same.
Not even to mention Security.
Making changes to legacy apps? Painful.

And performance? It keeps going down while errors keep going up. You basicaly build SPAs on top of a much bigger SPA.

2/
Because it was so easy to build and deploy, we made tons of them. Everyone wanted to participate. Great.

But then reality hit.
Apps grew in number and size.

Testing became harder and more expensive.
The tool is like a black box — harder to monitor, harder to search, harder to navigate.

Naturally I asked a LLM what could be the ideal job title:

"The most balanced and professional-sounding option would likely be "Lead Vibe Coded Production-Readiness Engineer".

Sure, why not. 🤷