I already enjoyed his absolute masterpiece "The Creative Act," (which I highly recommend - get the hardcover, the binding is great) and am very much looking forward to his work on AI and engineering. Check it out here: www.thewayofcode.com

Embedding a deep understanding within organizations about the fact that architecture, organizational structure, and (human) communication are interlinked.

I like how you show services as enablers for team autonomy. I often think of "teams that own them can work independently" as a north star for improving flow, since full independence is hard to reach (there will always be _some_ things stream-aligned teams need to work together on and collaborate).

From the article: "everybody tests in production, whether they admit it or not; good teams are aware of this and build tools to do it safely"

When I vibe code, I often intervene in the process with something like "hey, you might try X instead of Y."

For me, the process of coding with AI is a very active one. Like Pardis said in her post, reviewing code is essential. Use the tools to reason about the code and utilize the gain in iteration speed to actively contrast different approaches to solve the problem.

I myself have experienced accelerated learning, but on a different level. Instead of reasoning about code details, I am able to focus much more on architectural concepts and ideas as well as iterate on them much faster and compare different approaches.

What I found to be particularly interesting is the question about learning: "When I vibe code, especially in a domain I’m not familiar with, am I actually learning anything? This is where I’d recommend reviewing every change before every commit."

I myself have experienced accelerated learning, but on a different level. Instead of reasoning about code details, I am able to focus much more on architectural concepts and ideas as well as iterate on them much faster and compare different approaches.

What I found to be particularly interesting is the question about learning: "When I vibe code, especially in a domain I’m not familiar with, am I actually learning anything? This is where I’d recommend reviewing every change before every commit."

Check out the full interview here: www.youtube.com/watch?v=2oq_...

He also mentioned some independent services that have different scaling needs from the platform itself, such as the Copilot API and Actions. This is pragmatic. Use deployment boundaries where they really matter: supporting varying load patterns or improving team independence.

I'm also wondering: what about generated code? Does it have the same effect on teams and their perceived ownership of their (generated) artifacts? Might be an interesting area for research.