unicolet.org

A technique I use often with LLMs is  meta-prompting Meta-prompting essentially uses the LLM to generate the prompt for the specific task that I require. This can be one shot or conversational, in any case I always ask for options so I can use the LLM to fully explore the space as opposed to constrain myself to whichever corner the LLM tuck itself into the first time. I might then choose one of the prompt exactly or mix them up. Example of one shot: write 5 prompts to produce a summary of <topic> so that I can gain a broad understanding of it Conversational instead takes more than one turn, for example: my goal is to have a broad understanding of <topic>. I want you to generate 5 prompts that help me achieve this task. I want you to ask me all the questions that you can come up with and use the answers to fine tune the prompts

 🏎️ (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...