unicolet.org

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

Readwise just launched global ghostreader (their AI integration) which allows you to chat with your library. So I though I'd give it a try and I have to say the interaction was genuinely useful, and in line with what I feel is Readwise true value: rediscovering things you already know. See below what it had to say:

In Atomic Habits James Clear writes: “You do not rise to the level of your goals. You fall to the level of your systems.” For individuals, systems are habits and for an organization, systems are the processes and behaviors put in place and displayed (or tolerated) by leadership. If you ever wondered how leaders shape (directly or indirectly) organizations, now you know.

Via  The Pulse: What can we learn from Bun’s rapid Rust rewrite with AI? : To a sceptic, spending $165K to migrate Bun from Zig to Rust sounds very expensive. But to a realist, shortening a 1-2 year migration down to 11 days opens amazing new opportunities for devs . (*) this ultimately boils down to how good is your CI/CD? If you're still relying on manual steps then this kind on breakthrough is still inaccessible. Once again, the organizations that were in a good position before, are poised to benefit the most from industry advancements like AI. (*) emphasys mine

The story of Uber depleting its entire 2026 AI budge in just 4 months has been making the rounds and while there are certainly some distinctions to be made (speed vs efficiency, output vs outcomes) I guess he moral of the story, at least for me, is that you should never roll out a usage-based priced SaaS without any cost monitoring. With monitoring in place, you can tolerate inefficiency (acceptable) while keeping an eye on runaway costs (unacceptable) and you figure out how to connect usage to outcomes.

Interesting take on how one of the most regarded teams in the world (US Navy SEALs) use a dynamic hierarchy depending on the desired outcome: The US Navy SEALs offer a compelling example of how teams can dynamically shift their hierarchy. In the field, SEAL leaders employ strict, hierarchical, top-down command and control to ensure a unified front and clear delivery of their objectives. However, in after-action reviews on base, those same SEALs will deliberately flatten their team’s hierarchy, even going so far as to remove their stripes and insignia, to encourage open discussion and reflection uninfluenced by rank. Original article:  https://www.forbes.com/sites/londonschoolofeconomics/2026/03/12/the-most-successful-teams-dont-stay-flat-or-hierarchical-for-long/

Via Farnam Street :

News broke recently that Claude Code found a 23yo old vulnerability in the Linux Kernel NFS driver . If, for one second, we stop with the fear mongering we can realize that this opens up lots of interesting opportunities for a better (more effective) approach to security testing. Instead of relying on outdated models like pentesting, we could "just" feed the application source code to an LLM and have it find vulnerabilities. This is enabled by the fact that understanding a large code base (or any code base for that matter) is more difficult (and practically impossible) than applying known attacks to the external surface area. LLM suddenly make the former convenient enough and actually cheaper than a pentest. Cyber Security consultancies need to update their business model. 

 More proof that we're stuck in the past: https://www.reddit.com/r/embedded/comments/1s1agqo/why_is_bom_management_still_stuck_in_excel_in_2026/ every hardware team I’ve worked with ends up with the same setup… some giant excel or google sheet for the BOM everyone complains about it, but no one really replaces it you get random versions, people overwriting stuff, no idea who changed what, etc but at the same time whenever I look at “proper” tools they feel heavy or just not worth the switch so yeah genuinely curious, what are you all actually using day to day? My latest talk about Continuous Compliance is about moving on from xls (to lower cognitive load): https://www.incontrodevops.it/talk/continuous-compliance/

After a 7 year break, I returned to  IDI - Incontro DevOps Italia  and it was a blast. Here are my first impressions: AI dominated conversations. It is clear that team or organization-level guidance is important and software development and operational best practices like small PRs, and low MTTR are crucial. Sprints could/should be made shorter (1w or less). Question is: how to keep a healthy ceremony-to-work ratio with shorter sprints? Spec-driven development helps capture the details of the work being done, which is also useful for later rework/inspection but might also be important for compliance reasons 🤔 Finally someone using Backstage (to build self-service ops). List of sessions I attended: Leveraging the edge for observability GitOps, Observability e AI: come chiudere il ciclo dell’AIOps Don’t fear the bot: mastering AI tools before they master you (most fun and engaging) Scaling DevOps Without Scaling Ops: Our Platform Engineering Journey sshlogin: securely authentic...

I wish, one day, to have the dedication to pursue designs like the former Apple Sleep Indicator Light: the animation was designed to mimic human breathing at 12 breaths per minute  Just amazing. Via:  https://unsung.aresluna.org/just-a-little-detail-that-wouldnt-sell-anything/

I've been following Martin Stellar for some time and I find his material has made me a much better Product person. His writing is simple, clear and engaging, especially his free academy material . I thoroughly recommend you follow Martin Stellar on LinkedIn and read his materials.

I recently came across " Things I’ve learned in my 10 years as an engineering manager " by Jampa Uchoa and I loved it so much I wish I wrote it. Here are my favorite parts:  Everyone needs to care about the product : the most evident symptom of this is not happening is when we decide to hire QA or UX because we think they have the knowledge to fix the problem. Instead, the problem stays the same, and the flow of work breaks down. 60% of your job is being the cheerleader: the author mentions being the cheerleader for the team, and I would argue that we should also be the cheerleaders for the product. Your goal is for your team to thrive without you : I don't recall who said that leaders should be evaluated on their team's performance after they've left. It was probably former Navy captain David Marquet in "Turn the ship around! "

Via https://www.anildash.com/2025/09/09/how-tim-cook-sold-out-steve-jobs/ There's no point in having fuck-you money in the bank if you never say "fuck you"!

I'm kind of surprised Slack hasn't yet put out an AI feature. The potential is immense, imagine how many times the same question is asked and answered in a workspace...