Intro

Lots more AI stuff this week I read and watched. I went to a few talks too around AI and again some of the same themes came up. I’m really not sure what this all means but reading around change is the only real guarantee.

Highlights of the Week

He Was a Supreme Court Lawyer. Then His Double Life Caught Up With Him.

https://www.nytimes.com/2025/12/28/magazine/thomas-goldstein-supreme-court-gambling.html

During this run he won a total of about $50 million, and even though he had sold roughly 75 percent of his stakes to investors, he still personally cleared about $12 million. Flush with his success against Gores, Goldstein sat down to a heads-up match with a real estate magnate named Bob Safai — and this time he didn’t spread the risk by taking on backers. “I just have convinced myself, because I won $50 million in heads-up poker, that I am a savant at heads-up poker,” Goldstein told me. He promptly lost $14 million to Safai, all out of his own pocket.

Nothing really to take away from this more just a really good story. Well bad if you’re him or someone close to him, but a good story all the same. Warning sign about getting too caught up in gambling or thinking you’re way better than all others. He believed in himself, and still does by all accounts, but often that is not enough. Hedge your bets too I guess, or at least don’t bet everything you have without hedging.

The Bitter Lesson

http://www.incompleteideas.net/IncIdeas/BitterLesson.html

One thing that should be learned from the

Overall it is a slight shift in skills and about knowing how to use the new tools effectively. At the minute for example, reviewing code is as much about making sure it is nice and readable, long term that we can come back and understand it. That the names are good, not too large functions, tests exist. However AI code looks good right out of the bat. But that does not mean good. The heuristic of nice readable code is good code doesn’t work anymore. It might be nice looking but bad code. It might not do the right job or the tests don’t test for the actual thing we want. Does it follow requirements.

We move on from being ones that write code to orchestrating agents. Its not the same work but its not boring work either. There’s still a lot going on. It probably will also involve another layer of abstraction where engineers are up a level, closer to architects, strategists and product managers operate.

What can we do about this then? One option is to focus on improving skills. Before you could specialise narrowly in a specific niche. That is no longer enough on its own. Now you need to be able to tie that in with other things so you can at the very least operate the agents working on adjacent things, rather than just shipping that off to another team

Takeaway

Nothing here is all that groundbreaking. Go through all the big shifts the last decade and you’d find the same stuff. Focus on

At some point, or multiple points, anyone working with or using AI tools has an oh shit moment where it does something magical or amazing that makes you stop and think for a minute. Here’s one of mine I had recently

The Backstory

We’ve a microservices setup where there’s a few different services running all together, talking to each other on a kubernetes cluster. Standard fare for a lot of software companies these days. Recently we’ve been adding a new one which is deployed to production but hidden behind feature flags so is internal use only for now. It is actively being developed so there’s lots of churn with loads of changes going on and the full pipelines and checks haven’t yet been set up. Some things are still yet to be done but we’ll get there.

We also run this locally for local dev. There’s not many services, not yet anyway, so it’s not too much of a burden to run the three or four services on the local machine. All this could and should be improved but it is what it is for now. We’ll get there.

The Problem

Anyway this story begins when someone deployed a change which broke the service without anyone noticing for a day or two. Because those checks are not done yet. Again I said this is a new thing so nothing unexpected for this stage of the project. After some initial debugging and looking at logs nothing was showing up, the pod just failed immediately after a deploy and was

Intro

I’ve started trying to take up this week notes habit for a while anyway. Inspired by Simon Willison’s now defunct habit, I’m going to try keep this up for a while. I’ll try out a few different ways of doing it but for now the main will be to take what I’ve read in Readwise Reader, highlighted in Readwise, and noted down in Obsidian and try collate them all to one post. Rough and ready is what they’ll be until I can figure out what I’m doing.

Other than that I’ve read lots of the roundup posts this week which cover a lot of AI stuff. I don’t understand a lot of the technical details of it all but going forward I’m going to rely more on Anki to help get an understanding of some of these technical topics so I can maybe start understanding and be able to read the more technical ones. Of course understanding is nothing without using so more doing things is on the cards. I see a few using tools repos where they’ve created repos with loads of random tools for random things and that is probably one of the best ways of using AI. Get it to do what it is good at which is a small defined tool and scale linearly rather than a monolith that grows over and over. I want to think more about that though

Highlights of the Week

The Great Engineering Divergence

https://x.com/pauldix/status/2006423514446749965

Looking at software delivery, you could break it down into a number of

This one from 2003 brought back a different time. It was written at a time when Putin almost had to be introduced as to who he was. It was written on how this whole guy is a temporary blip in the system, trying to reach out and grab power, but how the system is fighting back. It talks about Russian elections being contested, or even mattering. The main guy of the tale, Mikhail Khodorkovsky, was once Russia’s richest man after accumulating an oil empire. The story was written after he’d been arrested for corruption and details how he never really feared jail, probably because he never though it’d pass.

Interesting times I guess.

Now the same guy lives in Europe somewhere and the company he founded was broken up for parts. The other guy needs no introduction nor does politics in Russia need a whole lot of words to explain what is going on.

I’ve read a few of these letters now and I’ve been meaning to read the book. It’s all about topics that I’m interested in but are not all that useful to me so I’m never sure how much time I want to put into them. They’re all down to the China-US relations and how that might play out the next few years. Who will win and what is going to happen when all this ends. It is all a bit up in the air now I guess but he does give an interesting perspective from the whole thing given he’s one of the few that write about their experiences living in both of them. I guess he doesn’t know either though but the letter is still interesting to see the both sides of the story.

AI is the main part of the story, as it is for much of the world here too. He’s not overly bullish on the tech but still leaves room for plenty of upside. I mean this in the way that it can do a lot of things but the exponential progress from the current standing point over the next few years he throws plenty of shade on. I guess on this I’m in agreement. I think it has plenty of potential but the likelihood of it completely changing everything in the next few years is very limited. Everywhere I look I see loads of pushback or pessimism on the way it is affecting things already, probably a symptom of how tech

I’m amazed continually at the productivity of these people. I can barely keep up with a few blog posts a week from all the places and here’s these people not only seemingly reading them all but actually putting them into use from local LLMs to the releases from the big labs to building things out of them all the whole time. It seems like such a long continuous effort from it all. It all makes me feeling left behind in that there’s so much to try and do but where does one even start. All this makes me exhausted just reading the thing, nevermind trying to actually do anything with it all.

I guess a lot happened this year in AI and this puts into perspective that some of the biggest movements like vibe code and claude code happened this year, as well as things I’m not familiar with like the explosion in image models

I admire the tools repo he’s got and though I can’t figure out if it would be useful for me it does inspire me to do something similar. I’m not sure how or what I’d use it for but something to start and then work on I guess

This is a bit of a rant piece but I feel like the term devops, though good in its original fundamental meaning, is misused so much to the point of becoming meaningless these days.

I believe the term itself is good in the original sense. It is a concept where the same person is responsible for developing and operating the application. You write the code to create the features, create the monitoring for those features, make sure it is running, and most importantly you fix it if it breaks. If something stops working at 2am, you are woken up to fix it. All the incentives are aligned for you to make reliable software which should be the goal for all software.

The bear case for Devops is that having the same people doing all these things is nowhere near as efficient as having a specialised person for each skill. All the tasks in software engineering are enormous fields of their own and expecting the same person to be as skilled on each level is too much to ask. However in reality with modern platforms and services, they are mostly able to offload enough of these things you should only have to set them up initially and figure out the correct configuration for your app, which only you will know how to do. I mean, who knows better what metrics are important: the expert in the code or the expert in observability? The principle of Devops is the code expert knows best. For some apps CPU might be

This is a book I read recently. I’m not sure what prompted me to start but is is a relatively concise book that doesn’t take too much time to get through. The core premise is that code health is something you should care about and want to improve. It lays out some things you should focus on. The biggest inspirations of the book are philosophy of software design and pragmatic programmer. The author even calls this out so if you’ve internalised those you probably know a lot of what goes on here but seeing the same information in a new light with a new shape around it can help a lot to learn it.

One thing I do want to pick on though is it is not a book about AI, despite being in the subtitle. I didn’t pick it up to learn about AI so wasn’t a big deal, just I think tacking on AI to get more interest in it is not what I like. AI is changing so rapidly that whatever goes in print is going to go stale quickly so it is probably a good thing that the subtitle is almost the only mention of AI in the whole book.

Why care about Code Complexity?

Finally, the worst thing about the codebase complexity is that there is almost no way back. Complexity grows incrementally, making it extremely hard to reverse the damage. At some point, you may decide to win it back—to refactor your code into something reasonably simple, but after multiple weeks