Someone posted recently about their company running a leaderboard tracking AI token usage. Top 25 users got called “Champions.” People who barely used it were labelled “Sleepers.” The champions had collectively burned through $850,000 since January first.

It took me a minute to fully absorb that.

The kicker is that the Sleeper who posted about it seemed genuinely worried about being at the bottom of the list. Not because they were less productive. Just because they weren’t spending enough of the company’s money on an AI that may or may not have been doing anything useful.

There’s a thing that happens in the AI space, reliably, almost rhythmically: a new model drops, the benchmarks are suspiciously curated, the blog post reads like it was written by a marketing department that just discovered the word “unprecedented,” and within 48 hours someone on Reddit has found the caveats buried in appendix C. Rinse, repeat.

So when Moonshot AI put out Kimi K2.7 Code this week, I was half-expecting the usual. What I got was something a bit different, and I find myself cautiously impressed, not by the model itself, which I haven’t tested properly, but by the way it was presented.

There’s a concept doing the rounds at the moment called cognitive debt, and it’s been sitting in the back of my head for a few days now.

The idea is straightforward. Tech debt is what happens when you cut corners on code quality to ship faster, and then spend the next year paying for it in maintenance hell. Cognitive debt is what happens when you outsource the thinking itself. You ship the thing, it works, but you don’t actually understand why it works. The understanding got deferred along with the effort.

There’s a story doing the rounds this week that I keep coming back to. A developer built an open source project management tool called Kaneo, stood up a cloud-hosted version so people could try it without wiring up their own database, and then one Thursday morning discovered that a botnet had used his signup flow to send 14,520 phishing emails in a three-hour window. From his verified domain. To real people who had no idea what Kaneo was.

Google’s Antigravity 2.0 apparently used 96 agents running in parallel to write an operating system from scratch in 12 hours for under a thousand US dollars in token costs. And it runs Doom.

That’s the claim, anyway.

The Doom thing has become a genuine benchmark meme at this point. Someone ran Doom on a pregnancy test display a few years back. Doom runs on ESP32 microcontrollers. Doom runs on graphing calculators. If your new piece of technology can’t run Doom, that’s probably the more interesting story. So let’s hold that particular detail lightly.

There’s a screenshot doing the rounds on social media lately — someone flexing a $500-a-day Claude API bill as proof that building your own SaaS with AI is smarter than paying $49 a month for an existing product. The original post frames it as some kind of revolutionary insight. “The End of Software,” they declared. I’ll admit, when I first saw it, my reaction was somewhere between genuine curiosity and mild secondhand embarrassment.

There’s a post doing the rounds that I keep coming back to, written by someone with eleven years of coding experience who had a genuinely unsettling moment last month. They hit an intermittent network timeout bug — the classic kind, only appearing in production, exactly the sort of thing you’d expect a seasoned developer to chew through methodically — and found themselves completely lost without AI to guide them. Not just slower. Actually lost. The internal voice that used to generate hypotheses had gone quiet.

There’s something both beautiful and slightly chaotic about open source AI development that reminds me of my DevOps days. You know that feeling when you push what you swear is the final fix to production, only to find yourself back at your desk three hours later because someone spotted an edge case? Well, the LocalLLaMA community just got a dose of that with the latest Qwen3.5 GGUF update from Unsloth.

There’s something deeply satisfying about tearing apart a black box and figuring out what makes it tick. It’s the same urge that drove me to pull apart computers as a teenager (much to my parents’ horror) and what keeps me engaged in my DevOps work today. But lately, I’ve been watching the AI agent space with a mixture of fascination and frustration.

I came across someone’s journey of learning AI agents from scratch, and it resonated with me on so many levels. They spent months wrestling with frameworks like LangChain and CrewAI, following tutorials that worked but never explained why they worked. When things broke, they were completely lost. Sound familiar?

Someone on Reddit recently announced Wizarr 2025.10.0, and buried in their feature list was this absolutely perfect line: “Overengineering solutions is in the essence of selfhosting and homelabbing!” The comments that followed were gold - people practically queuing up to admit they felt personally attacked by this statement. One user mentioned implementing single sign-on through Authentik for just two users. Another wrote their own log processor because they were fed up with their existing setup not working perfectly.

Well, there goes another one. Maybe Finance, the personal finance app that caught my attention with its sleek design and open-source promise, has just announced they’re shutting down their consumer-facing product to pivot to B2B. Their final version 0.6.0 dropped on GitHub with what I’d call a refreshingly honest explanation, but it still stings for anyone who bought into the vision.

This whole situation has me thinking about the fundamental tension between venture capital and open source software. When Maybe first appeared on my radar, something felt off about the setup. Here’s a company that raised VC money, promised an open-source personal finance tool, and then – surprise – discovered that giving away software for free doesn’t generate the returns their investors were expecting. Who could have seen that coming?

The news hit the tech forums this week like a quiet thud rather than a dramatic crash - Readarr, the book automation tool that many of us relied on for managing our digital libraries, has officially been retired. The GitHub repository is now archived, and the developers have thrown in the towel, citing unusable metadata, lack of time, and a stalled community effort to transition to Open Library.

It’s one of those moments that makes you pause and think about the fragility of the open source ecosystem we’ve all come to depend on. Here’s a project that filled a genuine need - automating book downloads and library management in the same way that Sonarr handles TV shows and Radarr manages movies. Yet despite its usefulness, it’s now joining the digital graveyard of abandoned projects.

Been mulling over something that’s been bugging me for weeks now. It started when I stumbled across a discussion from a frontend developer who’s been wrestling with the same concerns I’ve had about AI tools in our industry. The bloke made some pretty sharp observations about how these tools are being marketed and used, and it really struck a chord.

The crux of his argument was simple but powerful: AI tools are being sold as magic bullets that require no expertise, promising fast results and cost savings. But here’s the kicker - if you don’t have the expertise to properly instruct these tools and evaluate their output, you’re going to get garbage. It’s like handing a Formula 1 car to someone who’s never driven anything more complex than a Toyota Camry and expecting them to win races.

The tech world is buzzing with discussions about Amazon’s latest approach to software development, where AI tools are transforming coding into what many engineers describe as an assembly line process. Reading through various comments and perspectives online, this shift feels eerily familiar to what happened during the Industrial Revolution.

Working in tech for over two decades, I’ve witnessed the pendulum swing between valuing creativity and prioritizing efficiency. The current push toward AI-assisted coding at major tech companies raises some serious concerns about the future of software development.

The tech world is buzzing with another bold claim about AI coding assistants. This time, it’s about Cursor apparently churning out a billion lines of “accepted” code daily. Reading this while working on a legacy codebase migration project at my desk in South Melbourne, I had to pause and reflect on what this really means.

Numbers can be deceiving, especially in software development. Back in my early career days, I remember the misguided pride I took in writing hundreds of lines of code daily. Now, with decades of experience under my belt, I take far more satisfaction in deleting unnecessary code than adding new lines.

The self-hosting community has been buzzing lately with discussions about Nextcloud, and it’s fascinating to see how polarised the opinions are. Reading through various forums and discussions, I’m struck by the stark contrast between those who swear by it and others who can barely contain their frustration.

Having run my own home server setup from my study in Brunswick for several years, I’ve experienced firsthand how self-hosted solutions can either be a dream or a nightmare. The Nextcloud situation reminds me of the early days of Linux on the desktop - what works flawlessly for one person might be completely unusable for another.

Recently stumbled upon a fascinating thread discussing open-source alternatives to popular SaaS products. The list was impressive - everything from project management tools to photo storage solutions. But what really caught my attention wasn’t the alternatives themselves, but the complex discussion around what truly constitutes “open source” software.

The conversation particularly heated up around photo management solutions like Immich and Ente.io. While many users praised these alternatives, others raised valid concerns about breaking changes and sustainability models. It reminded me of the countless hours I’ve spent in my home office, tinkering with various self-hosted solutions, only to face the harsh reality of maintenance overhead.