unicolet.org

 🏎️ (Another) Great piece by Luca Rossi  on AI, this time about AI governance. At the beginning Luca mentions brakes, which immediately reminds of a great quote I got from Matthew Skelton : why do cars have brakes? to go faster! Almost counterintuitive at first, but when you think about it, cars can only go as fast as their stopping power allows. It's a balance, really. High performing teams know it, that to go fast you need more "brakes": linters, sast, coding guidelines, reviews, documentation, tests of all kinds and assorted automation. Beautiful piece, highly recommended: https://refactoring.fm/p/getting-started-with-ai-governance

Great trick I just learned from Aviv Ben-Yosef : as the saying goes "a rudder only works when you're moving", Ben-Yosef suggests ditching the search for a "perfect" solution that usually leads to paralysis and instead fully embracing the concept of "experimenting". By framing changes as time-boxed experiments, I can protect egos and at the same time create the safety for my team to speak up while we test our educated guesses. This iterative approach helps us embrace uncertainty and move forward without letting the fear of commitment freeze our progress. Just when I needed it!

This bit from Sean Goedecke hurt a lot because of the guilt it triggers when I compare my teen years to my chidren's: True or not, my sense is that Millennials and later generations think that worrying about “selling out” is a sign that you had it too good. Consider the endless anecdotes of Boomers and GenX-ers living in a van surfing until their mid-thirties and then walking into a good office job because they had a firm handshake: they could afford to be authentic because they didn’t have to hustle.  ouch

In business, a cost center (e.g., IT, HR, Legal) is a team that does not directly generate revenue, regardless of how well it is perceived. Within that category, there can be teams that end up being seen as a low-value cost center. In this writing, I am intentionally conflating the two, and even push for the logic that a cost center team (from a business point of view) can be perceived as a profit center when it increases business efficiency. My explanation is that this shift into negative happens when these teams' output does not meet the required business outcomes. For example, a software team could be constantly merging code but never ship anything useful or shipping too late: output is high, business outcomes are low. ( Read this excellent paper for more details ). Any attempt on the team's part to disprove this negative perception with facts or hard numbers is doomed to fail unless it is about business outcomes. Depending on the organizational maturity, understanding how a...

The narrative around AI keeps bouncing from it's slop and it kills software engineering to it has allowed to clear 2 years of backlog in two weeks . I think both are true, and ultimately the difference is made by how AI is deployed by Leadership. So what's different? Durable Teams and Domain Context:  while AI makes individual implementation much cheaper and faster, high-judgment individuals and agents still hit limits when they lack deep domain context. Durable, high-ownership teams remain the fundamental building block of engineering. AI can accelerate the writing of code, but teams must still possess the proprietary context to know what should be built—and what production metrics or instrumentation are actually required. Structural Improvements Over Haphazard AI Adoption:  clearing a multi-year backlog isn't just a matter of telling engineers to use AI; it requires leadership to focus on structural improvements and clear architectural patterns. When teams use AI to migr...

I've long been convinced that AI focus needs to be balanced and look at the processes upstream of sw development. There's incredible potential to improve product and strategy work and very little evidence of any effort going into it. This isn't entirely OpenAI or Anthropic's fault. Product work requires crossing organizational boundaries, querying fragmented tooling, talking to people, and continuously defining and refining strategy. None of this context is readily structured for an AI model to consume; it remains siloed, undocumented, or locked inside people's heads. Melissa Perri talks about this (and other topics) in the latest episode of her Product Thinking podcast. The most interesting part is just 3 minutes into the episode (emphasis mine): [...] "Delivery of designs and code got very fast. Delivery of good decisions became the new bottleneck." Now, I don't think this bottleneck is new. It's exactly what I talk about in the build trap. Wh...