unicolet.org

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

This year my xmas gift is the MP3 version of a seminal album of the '90s which is impossible to find on streaming services: Kruder & Dorfmeister's The K&D Sessions TM It does sound great!

Mostly out of curiosity and desire to learn I've tried to run open models locally on both LM studio and ollama, but I quickly realized the limitations intrinsic to my hardware (just a high-spec'd laptop). Curious to try AWS Bedrock I eventually settled on the following setup: litellm exposing Bedrock models (Qwen, atm) locally on an OpenAPI-compatible API (yes it's a mouthful). This works great for any tool that can be configured to use an OpenAPI-compatible API like Quill meetings . Getting VS code to work with this setup was more challenging as it required VS Code Insiders (the bleeding edge, AFAIU) and even in that case VS Code tends to forget settings or use them inconsistently. For example it always uses copilot for the inline code actions. llm  required some tweaking too, in particular the setting suggested in this comment . I am very impressed with litellm which provides accurate usage tracking per team or account. The potential for offering llm access on an interna...

 Perspective is worth 80 IQ points Alan Kay’s line “Perspective is worth 80 IQ points” isn’t about literal intelligence. He’s pointing out that the ability to shift viewpoint, reframe a problem, or see a system from a higher level often produces more insight than raw analytical horsepower. Many problems look hard only because they’re being viewed from a narrow frame. Change the frame, and what looked complex becomes obvious or solvable. Why Perspective Feels Like “+80 IQ” A few mechanisms: Reframing reduces complexity. Seeing the structure of a problem—rather than its surface detail—often collapses the difficulty. It mimics what we associate with “smartness.” Most people get stuck in the default frame. They try to optimize inside an assumption instead of questioning it. Someone who steps outside can leapfrog them without being “smarter.” Systems thinking detects leverage points. Understanding how components interact exposes shortcuts, invariants, and constraints th...

My notes on:  https://jenson.org/games/ which I found via:  https://youtu.be/1fZTOjd_bOQ?si=kCGSE2uNczIJjiQ- Alan Kay quote is hard to understand until an insight from a user test “changed my perspective”. First learning (on the surface, we go deeper and beyond it) pretty soon: Games have the ability to force situations, such as running into a canyon and having nowhere to go but up a ladder. Apps on the other hand, usually have the opposite, offering a broad toolkit of choices. Games, I thought, can exploit narrative to force situations which made their life easier. However this does not mean that games have it easy, on the contrary most games fail: You have to design a great game to get people to have the confidence that practicing is worthwhile. And we start going deeper right away now: Raph convinced me to forgo any quick and easy ‘cookbook of tricks’ approach to this problem and go deeper and understand better how games are built, from the bottom up First bit of wisdom: M...

You can't say you understand today's AI landscape without listening to this massive (4 hours!) Acquired episode on Google, focusing on its AI roots . Over three episodes, Acquired has a little over 12 hours worth of podcast just on Google! Well worth it IMO for  the greatest business in history . Selected highlights: [07:23]   basically every single person of note in AI worked at Google with the one exception of Yann Le Cun who worked at Facebook This is truly mind-bending to think about, especially considering that Google is (at the moment) not the first name that comes to mind when we think about AI (LLMs) today. But the real kicker comes a few minutes in when we learn that did you mean? (launched in 2001!!) and google translate  (2006) are the first practical application of language models to its search business which made it exponentially more effective. About 25 years ago, Google was already running machine learning in production, at fantastic scale (about 15...

Once again , some supremely well-thought and useful content from Oxide:  https://rfd.shared.oxide.computer/rfd/0576 This time it is about the use of LLMs within Oxide , here are my main take aways: start from values ! A phenomenal example of how values can be so much more than the vanity checklist that most companies use them for focus on the receiving end : why should I spend time reading something that the author did not think was worth enough spending the necessary time to write it? Again, goes back to their strongly writing-oriented culture and values corollary of item number 2: self review AI-generated code before asking others to review it!

After the recent npm attacks  there have been many recommendations to leverage dependency cooldown as an additional mitigating factor. Dependency cooldown works by instructing the package manager to ignore releases that are younger than a certain threshold. The reasoning is that a vulnerable package will eventually be detected (and removed) in less time than the threshold, therefore preventing the attack. This, combined with dependency pinning (including transitive dependencies!), is a very powerful tool, but introduces an issue for anyone using internal dependencies. For those the cooldown will have the undesired side-effect of blocking internal dependency updates which might contain urgent fixes. I haven't checked all package managers, but I did check some of the most popular languages. Also, cooldown is not supported everywhere and sometimes is supported with noteworthy exceptions. Nodejs Use or switch to pnpm and use a combination of minimumR...