Shellsharks Blogroll - BlogFlock

Book Review: Under Fire - Black Britain in Wartime by Stephen Bourne ★★★★☆ - Terence Eden’s Blog

2026-03-01T12:34:27.000Z

Everyone knows that Black people didn't exist in the UK until recently, right? Despite mountains of evidence of everything from Black Tudors and Victorian actors, some myths perniciously persist.

What was the experience for Black Britons during the second world war?

I find it fascinating how the US cultural hegemony rewrites history. I've heard people in the UK talk about "Jim Crow laws" as though that was a thing that happened in the UK. It wasn't. While there were barriers and racism (as the book makes clear) the experience of Black people in the UK was vastly different than it was for African Americans. To the point that white American GIs were routinely castigated for trying to impose their vile racism onto our country.

What makes this book special is the contemporary reports and modern interviews. There are some amazing stories to be told and it is fascinating to hear first-hand accounts. The book also contains a list of prominent Black people living in the UK (including their addresses) which feels a little like padding - but then this is fleshed out with mini-biographies of most of them. What is astounding is, given the range of people living in Britain, you occasionally get little revelations like this:

Only one black evacuee has ever been interviewed for a television documentary.

Some people profiled are, for want of a better word, ordinary. People who had normal lives, kept the home fires burning, and took part in ordinary civic life. And then there are guys like Ras Prince Monolulu who were bona-fide celebrities.

It is fair to say that modern Britain's relationship with the notion of "Empire" is complicated. When the call to arms came, people from the farthest colonies rushed to aide the "motherland". In many cases, they were initially rejected due to formal or informal colour-bars. The social acceptability of and legal ramifications of these practices is evidenced in Constantine v Imperial Hotels Ltd.

But for every story of casual and institutional racism towards people who came to help, there are stories of love and acceptance.

The English people opened their homes to us, we were invited out for dinners, teas, no problems at all. There were problems with the American forces, but it didn’t hinder us.

As with any history book, some of the language used can feel a little shocking or distasteful. History is never easy to engage with, but this book presents an even handed look at a turbulent period. It ends a little abruptly, but it is an excellent overview of the literature. Recommended for anyone who wants to understand our history.

IndieWeb Carnival March 2026: Museum memories - James' Coffee Blog

2026-03-01T08:14:54.000Z

Museums and galleries are places we can go to learn about the past, think about the present, and consider the future. Museums are places we can connect: with times, people, and place. We can have conversations in museums. We learn in museums. We can explore.

The topic I have chosen for this month’s IndieWeb Carnival is “Museum memories”.

This month, I invite you to write a blog post about a memory that you have of a museum. It can be any museum: your local art gallery, a museum you visit often, a museum you visited on holiday, a museum dedicated to one of your interests (the sea, video games, transportation, your favourite football team), or a museum at a historic site you have visited.

To get you thinking about this month’s topic, I have a few questions that you can use as starting points:

What is your favourite museum? When did you realise it became your favourite?
Do you recall a time when an object in a museum or an art gallery made you feel something? What was the feeling?
Do you remember when you first stumbled upon a new kind of history or art that you hadn’t thought or known about before?
Have you met anyone interesting at a museum? A new friend? A tour guide that got you thinking about something in a new way?
Is there a museum you loved as a child? What made it so interesting to you?
How does/did the physical space of a museum you visit or have visited affect you? Do you feel a certain way when you enter?

This month’s IndieWeb Carnival runs from March 1st to March 31st. To participate, write a blog post on the topic of “Museum memories” on our website. Then, send me an email at readers@jamesg.blog with a link to your submission.

I will curate all of the submissions I receive on this page as I receive them. At the beginning of April, I will write a round-up that summarises all of the submissions I have received.

Entries are listed below in reverse chronological order of submission. This means that the most recently received posts are at the top of the list.

Entries

No entries have been received yet.

Finished reading Dead Beat - Molly White's activity feed

2026-03-01T01:59:02.000Z

Finished reading:

The Dresden Files series, book 7.

Dead Beat

by Jim Butcher.

Published 2006. 528 pages.

Started February 23, 2026; completed February 28, 2026.

Read "A Nationwide Book Ban Bill Has Been Introduced in the House of Representatives" - Molly White's activity feed

2026-02-28T13:53:09.000Z

Read:

“A Nationwide Book Ban Bill Has Been Introduced in the House of Representatives”.

Kelly Jensen in Book Riot. Published February 26, 2026.

Hours after the State of the Union address, House republicans introduced legislation banning LGBTQ+ books from public schools nationwide.

30 months to 3MWh - some more home battery stats - Terence Eden’s Blog

2026-02-28T12:34:19.000Z

Back in August 2023, we installed a Moixa 4.8kWh Solar Battery to pair with our solar panels. For the last year and a half it has chugged away slurping up electrons and sending them back as needed. Its little fan whirrs and the lights on its Ethernet port flicker happily as it does its duty.

I estimate that it has saved us around 3 MegaWatt hours since it was commissioned. In monetary terms, that's roughly £1,000 taken off our electricity bills.

How did I work that out? Well, maths is hard, as Barbie knows, so take all this with a pinch of monosodium glutamate.

Here's a typical month - October 2025:

Yikes! What's going on here?

We use a variable electricity tariff. Prices fluctuate every 30 minutes. At peak times our electricity prices can shoot up to 60p per Kwh. Overnight or when the wind is high, prices can drop to zero. Yes, free electricity! Sometimes the excess in the grid means that prices go negative and we are paid to use electricity. Hurrah!

Our battery knows this. Its Internet connection allows it to download the tariff for the day ahead and plan accordingly. If the electricity prices are cheap, the battery fills up. The battery can decide to discharge when we're using more electricity than solar provides, or it can wait until prices are more expensive after the sun has gone down.

Here's an example, again from October:

In October, about a third of the power stored in the battery came from the sun. About 92% was used by our house with the remainder being sold back to the grid if it was profitable to do so.

By contrast, here's June 2025 - a sunny month in the Northern Hemisphere:

Here, only 12% of the battery charging was done by the grid. 88% was done for free by solar power. But because solar was so plentiful, about 15% of the battery was sold back to the grid.

Maths. Is. HARD!

I've been playing around with various charts, graphs, spreadsheets, modellers, and a bit of calculus. I basically came to the conclusion that the easiest way was to assume I was saving the energy price capped value of a kWh.

That varies from 25p to 35p. If I fudge the numbers just right, it rounds off at an even grand.

It's Payback Time

No-one ever asks what the payback period is of buying a car vs taking public transport. You never see anyone amortising an engagement ring over the length of a marriage. Still, here we are.

We paid £2,700 for the supply, install, and commissioning of our battery.

That means the payback time for the battery will be between 6 and 7 years. If energy prices go up, the payback time goes down. Its capacity is showing no degradation yet and I hope it will provide us with many years of savings before it needs to be repaired or upgraded.

Solar batteries are getting cheaper and their capacity is getting bigger - although not big enough to store all my home's electricity.

If you can afford the upfront costs, it's like pre-paying for a chunk of your energy usage and can help protect you against sudden price rises.

You can sign up to Octopus and get a £50 bill credit if you want to switch to a variable tariff.

Resident Evil 2 (1998) - Joel's Log Files

2026-02-28T03:40:00.000Z

A few days ago I wrote about how I recently decide to just poke away at games without actually feeling any rush to focus on a single game completely. But of course, sometimes a game just grips me from beginning to end, and I have to commit, because it’s just that cool.

I have lots of memories of watching speedruns, challenges, reviews and retrospectives of the Resident Evil games, I have to say I’m just not sure where the interest for the series came from, I never had a friend with a console who played them, and they never figured in the list of games I’d emulate when I got introduced to that world.

It wasn’t until I had my PSP and realized that I could play PS1 games on it, that an interest on the franchise developed, so I got them for the system. This was the case for Resident Evil 2, a game that I actually tried out years ago, even mentioning it as one of the many games I just left abandoned when I tried playing it on my PSP, as other titles simply stole my attention from it.

I was seriously kind of enamoured with the lore of the franchise, and I had an interest on Zombie movies, like George Romero’s Night of the Living Dead films, I think Parasite Eve played a role as well at the time, since I even read the novel back in 2020.

The point is, despite it all, I never gave the games a fair shot until now.

Resident Evil 2 was picked for February in the Low Key Game Club from the TWG Discord—which is also the reason I played Jet Lancer and Soul Reaver—and for some reason it just felt like the perfect time to actually play this title and survive through Raccoon City myself.

Story

The story of this game is presented in a great way, letting you experience two different points of view and two alternate stories. While playing as two different characters in the game.

Leon Kennedy is a rookie cop who got a job to work in Raccoon City’s Police Department, where as Claire Redfield is currently looking for his brother, Chris—one of the protagonists from the first game—who is currently missing, but worked as an agent in the STARS division of the police.

Each character will see different moments of a single narrative, and there are moments where you’ll encounter and see the effects of what the other character did on their side.

These characters meet while trying to survive the zombies running rampant in the city. However, they end up separated in the chaos, and the game lets you choose who to play as. The characters planned to meet at the Police Station, so now you have to find your way there, where the adventure truly begins.

As the story progresses, you will find reports and documents detailing the events prior to the game, unlock doors, solve puzzles and survive against enemies that want to eat your brains. You will also meet new characters as you venture deeper into the police station, and even meet companions during certain parts of the story that you’ll get to control as well, slowly uncovering the truth behind the virus spreading through Raccoon City.

Leon makes it to the Police Station, the main location of the game.

Gameplay

The gameplay that makes the original trilogy so special—and controversial among new players who want to get into them—are the tank controls and the fixed camera angles. These two features limit both movement and vision, and while they can be hard to get used to at first, they are essential to the original experience, and they don’t really take much effort to understand, after half and hour or so of playtime.

This is the franchise that coined the term survival horror, and these limitations and lack of agency challenge the player as they try to survive and explore the environments of the game. The limited ammo and items you can carry with you, means you’ll have to be strategic about the path you follow as you try to make progress.

Of course, multiple rooms will be overrun by zombies, and other enemies like the lickers, or worse. However, enemies don’t respawn, which makes killing them worth it to make traversal and backtracking easier.

When it comes to horror, it really isn’t that scary, yes, the atmosphere is amazing, but it’s kinda campy and other than some jump scares, it really won’t mess with your mind that much.

All of the Police Station is a giant escape room, and it is where the game shines most, as it is basically a sort of Metroidvania.

The game features no interface during gameplay, something that heightens the cinematic camera angles. You can know your health based on the character animation while standing and walking. You can find herbs, ammo and other items scattered in the game to help you out. There’s a menu you can access to see your items, combine them, and check them for clues, there is a section to access files and documents you’ve collected, as well as a map screen, which shows the doors available to you and the color of the key needed to unlock them.

Saving your progress is limited too. You can only save in specific rooms with a typewriter, and you need ink ribbons to use it, occupying an extra item slot too. Save too often and you’ll run out of ribbons, putting your progress in danger until you find more of them. You can also find item boxes in some save rooms where you can store items and access them in other item boxes in the game, very handy to free up your storage.

I honestly think this game is designed masterfully. It makes you feel powerless at first, and you are scared of the dangers around each turn of the camera, but if you explore more and take risks here and there, you can be rewarded with more resources and weapon upgrades, which are useful against stronger enemies and bosses later in the game.

There are bosses, but they just sponges that require you to shoot them with your strongest weapon and nothing more, making them kinda meh, and unfortunately they will deal tons of damage, so a lot of healing items are required as well. The bosses go through different transformations and are definitely cool to see the first time, but the boss battle design isn’t great.

The game is also very replayable, thanks to the different scenarios you can play, and the unlockable modes it features. The game featurs the zapping system. A fantastic mechanic that let’s you perform actions that affect the other character’s scenario, for example, you can take a weapon as Leon which will become unavailable on Claire’s side.

Each scenario changes the route, features very different puzzles and also exclusive bosses and characters you meet on them, it’s really amazing stuff that expands the game while reusing some assets.

In my case, I only went through the Leon A and Claire B scenario, but the story plays out differently if you do Claire first. I will probably replay this game at some point starting with her, just because it is that fun.

The environment is done with prerrendered backgrounds, which allow greater detail, and more complex character models

Art & Music

The amount of work that went into these games is just incredible. As stated before, the game features fixed camera angles, making use of incredibly detailed prerrendered backgrounds that allow for the game to look extremely nice. The areas of the game, especially in the police station, really feel like a place that went through a lot, as everything looks messy and real, with most rooms being rather memorable, even if they can feel a bit croweded sometimes. Everything blends in perfectly.

It is important to note, that these graphics were made for the PS1, at a 240p resolution, and they don’t look nearly as well as they would on a proper CRT display, like was common at the time, and that often blended things together, smoothing out the pixels beautifully. The images shown in this review are edited with some blur and a filter to mimmick the effect.

There are some great fan projects out there that upscale those backgrounds for the bigger displays, such as RESHDP, but I think they all look way too smooth and shiny compared to the gritty look of the original art. I feel like using a CRT filter is the best way to play these if you don’t have a proper display.

I played the game on my Anbernic RG35XX SP, which features a 480p 3.5 inch display, and given the display size and pixel density, I had a fantastic time enjoying the game on the go without complains.

Besides the backgrounds, the character models of the playable characters and enemies alike feature a ton of detail, we see faces, although not many expressions, and the model textures change as the story continues.

The music of course is also amazing, I played most of the game wearing earphones, and the atmosphere was awesome and very terrifying. There are many tracks in the game that fit very well, like the beautiful yet melancholic melody that plays when reaching a safe room, or a character theme playing when you meet them . Other themes build up the tension or get you hyped up during a boss fight or action sequences, and everything just works.

Audio is actually a core part of the gameplay, as it often signals enemies that can’t be seen on screen due to the camera angle, so staying alert is very helpful to avoid getting scared by a zombie popping up around the corner. Gunshots, steps sounds varying due to the floor surface and the like are very well done, so much detail has gone into this, it’s unreal for the time.

This game also features voice acting for everything, there’s actually no subtitles for them, which is a little annoying at least on the PS1 version. Still, the voices are iconic at this point, even if the delivery is cheesy and a bit over the top, it works really well and I found it really enjoyable and it kept me invested on these characters quite a lot. Don’t expect something on the level of Soul Reaver, but it fits the vibes of watching an old campy horror film and it’s perfect from that perspective.

Leon and Claire find each other inside the police station

Overall thoughts

The good

The background art and character models look amazing.
The map design for the police station is very good.
Cinematic camera angles and sounds that keep you on your toes.
Scattered in files and documents that is intersesting to read and find clues.
More than enough resources to complete the game if you manage items well.
Short playtime and lots of replayability.
Great side characters

The bad

Bosses are average bullet sponges and not cleverly designed.
Sometimes the camera angle will be messy, when hit by enemies or due to weapon recoil.
Item management is part of the deal, but backtracking to organize it can be annoying.
The game gets more linear as it goes on, this is good for me but maybe not you.
Poison status is a thing that exists, although it’s not common.
The puzzles are not as complex as other classic RE games, I didn’t mind though.
Turning around completely with tank controls is a pain, fixed until Resident Evil 3
It’s not really that scary, don’t expect to be traumatized or anything, just jumpscared.

Some tips and reminders

There is more ammo and healing items that you may expect, just explore and clear out rooms with zombies freely, you’ll get all you need.
Since the backgrounds are prerrendered, most interactable objects stand out quite a bit, keep an eye on things out of place.
Overall you can just inspect every corner of a room and there can be a variety of messages or at least fun texts to describe things
You can usually find the big weapons at least twice, so if you can’t carry (or decide not to) carry a certain weapon, you can often find it later, or you can do without it anyway.
It’s great to feel the weight of your own actions, don’t just reload a save if you feel like you did bad, try to keep going and you may surprise yourself.
Or you can just be lazy like me and use save states because you worry too much, you’ll end up with plenty of extra ammo in the end, by the way.

Finishing words

The game is currently on sale until March 3, 2026, excusively available for PC on GOG, you can even get the whole original trilogy there, in case you want to give them a go! I’ll stick with my emulation handhelds though.

Everything this game tries to do, is done perfectly well. Maybe the difficulty is not as high if you have already played other survival horror games like Signalis, as the item and ammo is actually plenty, but what makes it difficult is not being familiar with how these games should be played—exploring every nook and cranny to trigger as many checks as possible.

Also, yes, the bosses are not great. After experiencing the immaculate boss design of Soul Reaver, these bullet sponges that deal a bunch of damage and can make you lose a bunch of progress really didn’t do it for me, they were just a matter of healing items and ammo rather than actual skill.

Other than that, I really loved everything about this game. I played it on my commutes to work, like 20 or 40 minutes at a time, and I always managed to do some good progress and find something new to explore in those sessions. Even if it was not a game with portability in mind, it really lends itself well to it perfectly, at least thanks to the autosave and resume feature of my device when closing its lid.

The game holds up and is perfectly playable today, and very close to taking a position in my personal Top 25 Games, something I didn’t expect to happen so quickly, especially with a title I had abandoned before. Highly recommended!

This is day 23 of #100DaysToOffload

Reply to this post via email | Reply on Fediverse

Book Review: Weird Things Customers Say in Bookshops by Jen Campbell ★★☆☆☆ - Terence Eden’s Blog

2026-02-27T12:34:11.000Z

Remember back in the early 2010s when any moderately popular Twitter account could become a book (or even a TV series)?

This is a collection of Tweet-sized "overheard in" stories. All set in book shops.

Isn't it funny that some people don't know how books work! ROFL!

Aren't the general public strange? LOLOL!

That's a bit harsh of me. It only rarely becomes mean-spirited. But in a book this short, it rather contaminates the joy.

That said, this one will live rent-free in my head for a while:

Did Beatrix Potter ever write a book about dinosaurs?

It's the sort of stocking-filler book which is reasonable for perusing on the loo. Light-hearted but ultimately disposable.

Still, at least Neil Gaiman found it funny enough to leave a blurb…

Firefox AI Killswitch - Kev Quirk

2026-02-27T12:07:00.000Z

Nice to see that the Firefox team have actually implemented their "AI killswitch" in the way that they said they would. Here's a screenshot from my copy of Firefox 148:

Very happy to see this land, and it means I can end my hunt for a new browser for the time being.

Thanks for reading this post via RSS. RSS is ace, and so are you. ❤️

You can reply to this post by email, or leave a comment.

Quick Clarification on Pure Comments - Kev Quirk

2026-02-27T09:26:00.000Z

A couple of people have reached out to me asking if I can offer a version of Pure Comments for their site, as they don't run Pure Blog.

I obviously didn't make this clear in the announcement, or on the (now updated) Pure Comments site.

Pure Comments can be used on ANY website.

It's just an embed script, just like Disqus (only with no bloat or tracking). So you just have to upload the files to wherever you want to host Pure Comments, then add the following embed code wherever you want comments to display (replacing the example domain):

<div id="comments"></div>
<script src="https://comments.example.com/public/embed.js" defer></script>

You can use Pure Comments on WordPress, Bear Blog, Jekyll, 11ty, Hugo, Micro.blog, Kirby, Grav, and even Pure Blog! Anywhere you can inject the little snippet of code above, Pure Comments will work.

Thanks for reading this post via RSS. RSS is ace, and so are you. ❤️

You can reply to this post by email, or leave a comment.

Published on Citation Needed: "Issue 101 – Bought and paid for" - Molly White's activity feed

2026-02-26T22:02:10.000Z

Published an issue of Citation Needed:

Issue 101 – Bought and paid for

Bitcoin is down 50%, several prominent industry figures have been uncovered in the Epstein files, Trump’s facing a probe into his family’s $500M deal with the UAE, and crypto super PACs spend their first $6 million in the midterms.

A Sunday of chaos and quiet - Joel's Log Files

2026-02-26T17:00:00.000Z

I woke up early, turned on my laptop and opened the presentation for today’s sermon, the preacher sent it overnight and I was revising it. It took longer than expected, but it was bound to happen—AI generated graphics were used.

Helping with the media and worship presentations during service at my local church is a common task of mine. I probably should have done more to prevent this and set some guidelines beforehand, but now that it happened, I wouldn’t let it fly. After a short explanation of why, I saved the day, and educated one more person about the horrors of AI slop. I wish that had been the biggest mess of the day…

The morning kept going, I finished the presentation, song lyrics, the usual stuff. I have no breakfast on Sundays, I dressed up—more formal than usual, I was feeling fancy—and headed out with my family!

After the service was over—with AI nowhere to be seen—everyone stayed to have lunch together.

My church has been collecting money for a new building, so each week a different family prepares and sells a meal for everyone—we are a rather small group—to acquire funds and enjoy the time together.

I get in line for my serving—some great tacos de bistec that I couldn’t stop eating—and I sat on a different spot than normal, since most of my friend group helped prepare the orders, or handle cash. I was enjoying myself, listening to the chatter without saying much. I start to hear about violence going on in the streets, about drones flying above some areas, things start to get a little tense.

As much as I hate it, I install Facebook again—still the most popular social network in Mexico. I read the headlines, I read posts from the government in my state and my city. I hear the people around me, sharing their own thoughts and updates on the situation.

Some people with friends or contacts elsewhere start to get phone calls, people checking up on each other, people making sure everyone is safe. A few leave early, but things keep going pretty well.

I talk about it on the fediverse, in some group chats. I check up and see this is news worldwide. Flights are delayed, roads are blocked, hotels closed their doors— nobody in, nobody out.

The leader of the biggest drug cartel in Mexico died.

After this military operation, the narco is acting in retaliation with terrorist acts all over the country. The posts online from the local government are clear: go home and stay inside.

Things were going fine. People left at a rather slow pace, those who stayed finished their meal, and things went on as usual—the kids played and ran around outside. We were all rather calm, it was no big deal.

Perhaps is in moments like these where faith shines through, and being together brought a sense of peace amidst the chaos. Maybe it’s naive, maybe we are oblivious to reality. But we rest assured, beyond any despair this world may bring.

And the day went on, we returned home, and enjoyed a quiet evening. My mom decided to catch up on her current TV show of choice, my grandma joined her, even my dad. They made some popcorn too.

I wasn’t feeling like watchting TV, and I stopped reading the news. It had been a while since we had popcorn, so I got my own bowl and went to my bedroom to ~~watch Resident Evil retrospective videos and essays~~ clean up and get it tidy.

Later I returned to my playthrough of Resident Evil 2. It has been such an enjoyable experience, and it felt a bit surreal this time, I couldn’t help but think about the fact that I’m surviving a zombie apocalypse while there are vehicles on fire and buildings closed all over my state. At least I don’t think Zombies stand a chance in Mexico, I admit I chuckled at the intrusive thought.

Checking my emails, I realize I won’t have to work on Monday, and that my gym would be closed too. Not much to worry about, just an unexpected day off, a welcome development despite the circumstances.

A bit later, my church did an online call, where we prayed together about the whole situation going on, everyone arrived home well, and even though shops and the like were closed, we all had our needs covered. We prayed for the authorities, forgiveness for those committing these acts and their repentance, for the people who suffered a loss, and those who struggled because of it all.

My dad prepared some migas con huevo for dinner—probably my favorite way to eat eggs. I was happy that I wouldn’t have to wake up early tomorrow, and things went as normal, then it was time to go to sleep.

The thought about how I could have realized absolutely nothing if I hadn’t been with other people is also weird, I really am completely unaware of the news most of the time, but when stuff like this could happen all of a sudden, I see now why some folks are often very worried on what’s going on around them.

I guess I should try to find a balance. It’s easy to ignore that which doesn’t affect you, I guess, but then it does, and now what? I do hope that I’ll remain calm even then, maybe I can say it because nothing really affected me much, just the tension in the moment. I don’t know, I’ll figure something out.

I’d also like to thank those who checked up on me! I’m writing this last couple paragraphs a few days later now, and it really does feel kinda melancholic. I thought about writing about my day off too, but it really was just a normal time staying at home and playing videogames. That Sunday though, that was a day full of mixed emotions, but it kind of got me to see so some things differently, it was an interesting experience.

This is day 22 of #100DaysToOffload

Reply to this post via email | Reply on Fediverse

This time is different - Terence Eden’s Blog

2026-02-26T12:34:39.000Z

3D TV, AMP, Augmented Reality, Beanie Babies, Blockchain, Cartoon Avatars, Curved TVs, Frogans, Hoverboards, iBeacons, Jetpacks, Metaverse, NFTs, Physical Web, Quantum Computing, Quibi, Small and Safe Nuclear Reactors, Smart Glasses, Stadia, WiMAX.

The problem is, the same dudes (and it was nearly always dudes) who were pumped for all of that bollocks now won't stop wanging on about Artificial Fucking Intelligence.

"It's gonna be the future bro, just trust me!"

"I dunno, man. Seems like you say that about every passing fancy - and they all end up being utterly underwhelming."

"This time is different!"

*sigh*

The investor who says, “This time is different,” when in fact it’s virtually a repeat of an earlier situation, has uttered among the four most costly words in the annals of investing.

16 rules for investment success - Sir John Templeton

All of the above technologies are still chugging along in some form or other (well, OK, not Quibi). Some are vaguely useful and others are propped up by weirdo cultists. I don't doubt that AI will be a part of the future - but it is obviously just going to be one of many technology which are in use.

No enemies had ever taken Ankh-Morpork. Well technically they had, quite often; the city welcomed free-spending barbarian invaders, but somehow the puzzled raiders found, after a few days, that they didn't own their horses any more, and within a couple of months they were just another minority group with its own graffiti and food shops.

Terry Pratchet's ~~Faust~~ Eric

The ideology of "winner takes all" is unsustainable and not supported by reality.

Making fLaMEd fury Glow Everywhere With an Eleventy Transform - The Weblog of fLaMEd

2026-02-26T12:00:00.000Z

What’s going on, Internet? I originally added a .gradient-text CSS class as a fun way to make my name (fLaMEd) and site name (fLaMEd fury) pop on the homepage. shellsharks gave me a shoutout for it, which inspired me to take it further and apply the effect site-wide. Site wide was the original intent and the problem was it was only being applied manually in a handful of places, and I kept forgetting to add it whenever I wrote a new post or created a new page. Classic.

Instead of hunting through templates and markdown files, I’ve added an Eleventy HTML transform that automatically applies the glow up.

The effect itself is a simple utility class using background-clip: text:

.gradient-text {
  color: transparent;
  background-image: var(--gradient-flames);
  padding: 0.6rem 0;
  background-size: 50%;
  background-clip: text;
}

Swap --gradient-flames for whatever gradient custom property you have defined. The background-size: 50% repeats the gradient across the text for a more dynamic flame effect.

The transform lives in its own plugin file and gets registered in eleventy.config.js. It runs after Eleventy has rendered each .html page, tokenises the HTML by splitting on tags, tracks a skip-tag stack, and only replaces text in text nodes.

export const glowUp = eleventyConfig => {
  eleventyConfig.addTransform('glow-up', (content, outputPath) => {
    if (!outputPath?.endsWith('.html')) return content;

    const skipTags = new Set(['a', 'code', 'h1', 'h1', 'h3', 'pre', 'script', 'style', 'textarea', 'title']);
    const skipStack = [];
    let result = '';

    for (const token of content.split(/(<[^>]*>)/)) {
      if (token.startsWith('<')) {
        const isClosing = token.startsWith('</');
        const isSelfClosing = token.endsWith('/>');
        const tagMatch = token.match(/^<\/?([a-zA-Z][a-zA-Z0-9-]*)/);

        if (tagMatch && !isSelfClosing) {
          const tag = tagMatch[1].toLowerCase();
          if (!isClosing) {
            if (skipTags.has(tag)) skipStack.push(tag);
            else if (tag === 'span' && token.includes('gradient-text')) skipStack.push('gradient-text-span');
          } else {
            for (let i = skipStack.length - 1; i >= 0; i--) {
              if (skipStack[i] === tag || (tag === 'span' && skipStack[i] === 'gradient-text-span')) {
                skipStack.splice(i, 1);
                break;
              }
            }
          }
        }
        result += token;
      } else if (skipStack.length === 0 && token) {
        result += token.replace(/flamed( fury)?/gi, match => `<span class="gradient-text">${match}</span>`);
      } else {
        result += token;
      }
    }
    return result;
  });
};

Tags in the skipTags set, along with any span already carrying the gradient-text class, push onto the stack. No replacement happens while the stack is non-empty, so link text, code examples, the page <title>, and already-wrapped instances are all left alone. HTML attributes like alt and href are never touched because they sit inside tag tokens, not text nodes.

A single regex /flamed( fury)?/gi handles everything in one pass. The optional group greedily matches " fury" when present, so “fLaMEd fury” is always wrapped as a unit rather than just “fLaMEd”. The i flag covers every capitalisation variant (“fLaMEd fury”, “Flamed Fury”, “FLAMED FURY”) with the original casing preserved in the output. This helps because I can be inconsistent with the styling at times.

Export the plugin from wherever you manage your Eleventy plugins:

import { glowUp } from './plugins/glow-up.js';

export default {
  // ...other plugins
  glowUp,
};

Then register it in eleventy.config.js. Register it before any HTML prettify transform so the spans are in place before reformatting runs:

eleventyConfig.addPlugin(plugins.glowUp);
eleventyConfig.addPlugin(plugins.htmlConfig); // html prettify

That’s it. Any mention of the site name (fLaMEd fury) in body text gets the gradient automatically, in posts, templates, data-driven content, wherever.

Look out for the easter egg I’ve dropped in. Later.

Hey, thanks for reading this post in your feed reader! Want to chat? Reply by email or add me on XMPP, or send a webmention. Check out the posts archive on the website.

Four More Years - The Weblog of fLaMEd

2026-02-26T11:21:43.000Z

What’s going on, Internet? I’ve been using my iPhone 13 Pro for a little over four years now, since September 2021 and I want to keep using it for a couple more.

Keyboard lag. Apps taking a second to think before opening. Battery health sitting at 80%.

I had a quick look at the iPhone 17 and couldn’t justify it when everything else about this phone is still good. Storage is only half full. Camera is fine. It’s fast when it wants to be.

So I tried the logical fix first: a $90 battery replacement from a local repair shop.

This is where it had been sitting for a while. Still usable, but clearly the reason iOS had started throttling performance.

Straight after the swap I got a warning about the battery not being genuine which I was only made aware of right before pulling the trigger on this after reading a comment on the iPhone 13 Battery page on iFixit.

I made peace with myself and I was prepared to live with it. For $90 and being done in 30 minutes without having to schedule with an authorised repair dealer and being without the phone for up to four days. I just wanted the speed back.

But apparently because I’m on a newer version of iOS, I had the option to run Apple’s verification process. So I did… and it passed.

Battery health back to 100%, full stats restored, and the warning moved to Parts & Service History where it belongs.

That’s basically the authorised-repair end result for third-party-repair money.

I followed the usual calibration cycle: charge to 100%, leave it on the charger for a couple more hours, run it down until it turns off, charge back to 100%. Mostly to give iOS a clean read on the new battery.

The battery fixes the hardware bottleneck. The other half is software. Years of installed apps, background processes, cached junk. So I’m preparing for a full wipe and setting the phone up as new. No restoring from backup, sign into iCloud and let the data sync back, reinstall apps one at a time. Only the things I actually use get to come back. It’s the closest you get to a new phone without buying one.

This whole reset cost less than a case for a new phone. If the lag disappears, that’s another couple of years out of a device that’s still more than good enough. If it doesn’t, then I look at upgrading. But it makes more sense to solve the worn-out-battery problem before spending thousands to avoid it.

I’ll report back once the clean install is done and I’ve lived with it for a few days.

Hey, thanks for reading this post in your feed reader! Want to chat? Reply by email or add me on XMPP, or send a webmention. Check out the posts archive on the website.

Members Only: Your anonymity set has collapsed and you don't know it yet - Westenberg

2026-02-26T01:41:29.000Z

Introducing Pure Comments (and Pure Commons) - Kev Quirk

2026-02-25T15:04:00.000Z

A few weeks ago I introduced Pure Blog a simple PHP based blogging platform that I've since moved to and I'm very happy. Once Pure Blog was done, I shifted my focus to start improving my commenting system. I ended that post by saying:

At this point it's battle tested and working great. However, there's still some rough edges in the code, and security could definitely be improved. So over the next few weeks I'll be doing that, at which point I'll probably release it to the public so you too can have comments on your blog, if you want them.

I've now finished that work and I'm ready to release Pure Comments to the world. 🎉

I'm really happy with how Pure Comments has turned out; it slots in perfectly with Pure Blog, which got me thinking about creating a broader suite of apps under the Pure umbrella.

Enter Pure Commons

I've had Simple.css since 2022, and now I've added Pure Blog and Pure Comments to the fold. So I decided I needed an umbrella to house these disparate projects. That's where Pure Commons comes in.

My vision for Pure Commons is to build it into a suite of simple, privacy focussed tools that are easy to self-host, and have just what you need and no more.

What's next for Pure Commons?

Well, concurrent to working on Pure Comments, I've also started building a fully managed version that people will be able to use for a small monthly fee. That's about 60% done at this point, so I should be releasing that over the next few weeks.

In the future I plan to add a managed version of Pure Blog too, but that will be far more complex than a managed version of Pure Comments. So I think that will take some time.

I'm also looking at creating Pure Guestbook, which will obviously be a simple, self-hosted guestbook along the same vein as the other Pure apps. This should be relatively simple to build, as a guestbook is basically a simplified commenting system, so most of the code is already exists in Pure Comments.

Looking beyond Pure Guestbook I have some other ideas, but you will have to wait and see...

In the meantime, please take a look as Pure Comments - download the source code, take it for a spin, and provide any feedback/bugs you find.

If you have any ideas for apps I could add to the Pure Commons family, please get in touch.

Thanks for reading this post via RSS. RSS is ace, and so are you. ❤️

You can reply to this post by email, or leave a comment.

Book Review: Of Monsters and Mainframes - Barbara Truelove ★★★⯪☆ - Terence Eden’s Blog

2026-02-25T12:34:02.000Z

This is fun, silly, charming, and much better than The Murderbot Diaries despite being superficially similar.

Imagine you are an interstellar ship and, of course, your AI is conscious. What would you do if your passengers were killed - not by a terrifying alien, but by Count Dracula???

What if, on the return journey, another set of your passengers were similarly slaughtered. Except, this time, by a Werewolf? How would that make you feel? Would it drive you mad? Could you cope with the bullying from other starships? Or would you feel the need… the need for REVENGE!

As I said, silly and campy fun. It is episodic adventure with just the right amount of Hammer-style horror and not too much technobabble. All the classic monsters are here - depression, intrusive thoughts, envy, fear.

Oh, and Frankenstein’s spider.

As an ebook, it makes great use of fonts - which give it a delightfully retrofuturistic feel. There are some fun binary Easter-Eggs as well.

mquire: Linux memory forensics without external dependencies - Trail of Bits Blog

2026-02-25T12:00:00.000Z

If you’ve ever done Linux memory forensics, you know the frustration: without debug symbols that match the exact kernel version, you’re stuck. These symbols aren’t typically installed on production systems and must be sourced from external repositories, which quickly become outdated when systems receive updates. If you’ve ever tried to analyze a memory dump only to discover that no one has published symbols for that specific kernel build, you know the frustration.

Today, we’re open-sourcing mquire, a tool that eliminates this dependency entirely. mquire analyzes Linux memory dumps without requiring any external debug information. It works by extracting everything it needs directly from the memory dump itself. This means you can analyze unknown kernels, custom builds, or any Linux distribution, without preparation and without hunting for symbol files.

For forensic analysts and incident responders, this is a significant shift: mquire delivers reliable memory analysis even when traditional tools can’t.

The problem with traditional memory forensics

Memory forensics tools like Volatility are essential for security researchers and incident responders. However, these tools require debug symbols (or “profiles”) specific to the exact kernel version in the memory dump. Without matching symbols, analysis options are limited or impossible.

In practice, this creates real obstacles. You need to either source symbols from third-party repositories that may not have your specific kernel version, generate symbols yourself (which requires access to the original system, often unavailable during incident response), or hope that someone has already created a profile for that distribution and kernel combination.

mquire takes a different approach: it extracts both type information and symbol addresses directly from the memory dump, making analysis possible without any external dependencies.

How mquire works

mquire combines two sources of information that modern Linux kernels embed within themselves:

Type information from BTF: BPF Type Format is a compact format for type and debug information originally designed for eBPF’s “compile once, run everywhere” architecture. BTF provides structural information about the kernel, including type definitions for kernel structures, field offsets and sizes, and type relationships. We’ve repurposed this for memory forensics.

Symbol addresses from Kallsyms: This is the same data that populates /proc/kallsyms on a running system—the memory locations of kernel symbols. By scanning the memory dump for Kallsyms data, mquire can locate the exact addresses of kernel structures without external symbol files.

By combining type information with symbol locations, mquire can find and parse complex kernel data structures like process lists, memory mappings, open file handles, and cached file data.

Kernel requirements

BTF support: Kernel 4.18 or newer with BTF enabled (most modern distributions enable it by default)
Kallsyms support: Kernel 6.4 or newer (due to format changes in scripts/kallsyms.c)

These features have been consistently enabled on major distributions since they’re requirements for modern BPF tooling.

Built for exploration

After initialization, mquire provides an interactive SQL interface, an approach directly inspired by osquery. This is something I’ve wanted to build ever since my first Querycon, where I discussed forensics capabilities with other osquery maintainers. The idea of bringing osquery’s intuitive, SQL-based exploration model to memory forensics has been on my mind for years, and mquire is the realization of that vision.

You can run one-off queries from the command line or explore interactively:

$ mquire query --format json snapshot.lime 'SELECT comm, command_line FROM
tasks WHERE command_line NOT NULL and comm LIKE "%systemd%" LIMIT 2;'
{
 "column_order": [
 "comm",
 "command_line"
 ],
 "row_list": [
 {
 "comm": {
 "String": "systemd"
 },
 "command_line": {
 "String": "/sbin/init splash"
 }
 },
 {
 "comm": {
 "String": "systemd-oomd"
 },
 "command_line": {
 "String": "/usr/lib/systemd/systemd-oomd"
 }
 }
 ]
}

Figure 1: mquire listing tasks containing systemd

The SQL interface enables relational queries across different data sources. For example, you can join process information with open file handles in a single query:

mquire query --format json snapshot.lime 'SELECT tasks.pid,
task_open_files.path FROM task_open_files JOIN tasks ON tasks.tgid =
task_open_files.tgid WHERE task_open_files.path LIKE "%.sqlite" LIMIT 2;'
{
 "column_order": [
 "pid",
 "path"
 ],
 "row_list": [
 {
 "path": {
 "String": "/home/alessandro/snap/firefox/common/.mozilla/firefox/
 4f1wza57.default/cookies.sqlite"
 },
 "pid": {
 "SignedInteger": 2481
 }
 },
 {
 "path": {
 "String": "/home/alessandro/snap/firefox/common/.mozilla/firefox/
 4f1wza57.default/cookies.sqlite"
 },
 "pid": {
 "SignedInteger": 2846
 }
 }
 ]
}

Figure 2: Finding processes with open SQLite databases

This relational approach lets you reconstruct complete file paths from kernel dentry objects and connect them with their originating processes—context that would require multiple commands with traditional tools.

Current capabilities

mquire currently provides the following tables:

os_version and system_info: Basic system identification
tasks: Running processes with PIDs, command lines, and binary paths
task_open_files: Open files organized by process
memory_mappings: Memory regions mapped by each process
boot_time: System boot timestamp
dmesg: Kernel ring buffer messages
kallsyms: Kernel symbol addresses
kernel_modules: Loaded kernel modules
network_connections: Active network connections
network_interfaces: Network interface information
syslog_file: System logs read directly from the kernel’s file cache (works even if log files have been deleted, as long as they’re still cached in memory)
log_messages: Internal mquire log messages

mquire also includes a .dump command that extracts files from the kernel’s file cache. This can recover files directly from memory, which is useful when files have been deleted from disk but remain in the cache. You can run it from the interactive shell or via the command line:

mquire command snapshot.lime '.dump /output/directory'

For developers building custom analysis tools, the mquire library crate provides a reusable API for kernel memory analysis.

Use cases

mquire is designed for:

Incident response: Analyze memory dumps from compromised systems without needing to source matching debug symbols.
Forensic analysis: Examine what was running and what files were accessed, even on unknown or custom kernels.
Malware analysis: Study process behavior and file operations from memory snapshots.
Security research: Explore kernel internals without specialized setup.

Limitations and future work

mquire can only access kernel-level information; BTF doesn’t provide information about user space data structures. Additionally, the Kallsyms scanner depends on the data format from the kernel’s scripts/kallsyms.c; if future kernel versions change this format, the scanner heuristics may need updates.

We’re considering several enhancements, including expanded table support to provide deeper system insight, improved caching for better performance, and DMA-based external memory acquisition for real-time analysis of physical systems.

Get started

mquire is available on GitHub with prebuilt binaries for Linux.

To acquire a memory dump, you can use LiME:

insmod ./lime-x.x.x-xx-generic.ko 'path=/path/to/dump.raw format=padded'

Then you can run mquire:

# Interactive session
$ mquire shell /path/to/dump.raw

# Single query
$ mquire query /path/to/dump.raw 'SELECT * FROM os_version;'

# Discover available tables
$ mquire query /path/to/dump.raw '.schema'

We welcome contributions and feedback. Try mquire and let us know what you think.

Good vibes, bad vendors - Werd I/O

2026-02-25T10:00:03.000Z

When I was thirteen or fourteen I had a really comfortable sweatshirt that I wore to school all the time — but it did have a few inherent problems. For one thing, it had a great big target on it, and wearing a literal target to high school was just asking for it. For another, on top of that, in Looney Tunes writing, was the confident phrase: “It’s a good vibe!”

I was bullied as mercilessly as one might expect, but I honestly think it might have killed in the AI era. I’d like to think I was just ahead of my time.

Andrej Karpathy, an early OpenAI researcher who now works at his own startup, coined the phrase vibe coding last year. To vibe code is to use an LLM like Claude or ChatGPT to generate source code instead of writing it yourself. He meant it as a way to loosely prototype code or to make progress on a weekend project. LLMs, at least at the time, could not be fully trusted to write well-written, working code. It was an out-there idea.

What a difference a year makes. Today, it’s a mainstream conversation that is rapidly reshaping technology strategy — and informing layoffs across industries.

AI conversations are always fraught, for good reasons that include the underlying power dynamics and the bad behavior of most of the AI vendors. At the same time, the whole AI landscape is changing incredibly rapidly, and it’s become a cliché to point out that any discussion of what LLMs can and can’t do today will probably be invalid two or three months from now. And, of course, millions of words have been written about it at this point. But even despite all that, I still think it’s worth talking about.

If you’re running technology in a small, resource-constrained environment — like a newsroom or a non-profit — how should you think about AI-enhanced software engineering? Come to that, how should I?

Let’s talk about it.

First things first: does it work?

It didn’t, and then it did.

Six months ago, LLMs could generate a certain amount of code, but they would often make inefficient decisions or hallucinate libraries and API endpoints, and you’d need to babysit them a lot. Their use was mostly passive: they would generate code snippets based on immediate user prompts, and engineers would have to spend a bunch of time debugging the output. And in terms of security, it was the Wild West; there were essentially no security considerations. LLMs are famously stochastic (their output is randomly determined, not deterministic) and prone to hallucinations. The result was unreliable code.

A lot has changed since then. In particular, the models released in February, 2026 are a sea change in reliability: given the right prompt, they often genuinely can write decent code in one shot. Tools like Claude Code can go off, spawn multiple agents, investigate a problem, build a reasonable plan, and then execute on it, while working in a safely sandboxed environment.

It’s not just about improved models, although they obviously have a central part to play. An ecosystem is developing around doing AI-assisted software engineering well. Plugins like Jesse Vincent’s Superpowers encourage good decision-making based on principles of excellent software architecture design and product management. Structured frameworks like spec-driven development similarly help lead the agent to sensible outcomes; both are incorporated in all-in-one coding lifecycle toolkits like Metaswarm. A rigorous process is preserved, and throughout, there are far more safety guardrails to prevent security incidents (although it’s easy to overcome them, or they’re sometimes not on by default), and using AI to generate code is much safer than it was.

Claude Code absolutely can write the code, build a plan, and document its work. I have been an AI skeptic, but in my experiments I’ve found that it really can feel like magic. You can reasonably object to AI for any number of reasons, but this is no longer one. It works.

The thing to understand is that this is a tool for engineers — and senior engineers will get the best results. It takes real engineering skill to craft a prompt that will do the right thing and result in a strong architecture.

The process changes the center of gravity from writing source code in a programming language to crafting goals, understanding your user, being crystal clear about the experience and the value you want to convey, and thinking about architectural implications. That probably means talking to people, forming a hypothesis about what they need, testing it with them, and considering the ongoing technical implications of the work.

Those are things that senior engineers already spend much of their time doing — indeed, I’d argue that it’s what separates a great senior engineer from a mid-level one. The core question a senior engineer navigates well comes down to: lots of people can write code, but should they? Why, and for whom? Those questions only become more important in a world where AI is writing the source code. When implementation is faster, problem selection and scoping become the scarce skills.

Friction is training: we learn how to engineer software through our terrible experiences. When things go wrong, we learn. When we have to refactor, we learn. When we talk to our peers about our work, we learn. AI removes most of this friction and hides the complexity away from us: it obscures failure, compresses the process of debugging, and automates refactoring. When these hard-earned skills are the reason we can make good software engineering decisions with AI, but the AI doesn’t offer newcomers the ability to build those skills, who will train the AI once we are gone?

Opinions on that change in center of gravity will be intensely divided. I stand by this New Year’s Day thought about Claude Code:

It has the potential to transform all of tech. I also think we’re going to see a real split in the tech industry (and everywhere code is written) between people who are outcome-driven and are excited to get to the part where they can test their work with users faster, and people who are process-driven and get their meaning from the engineering itself and are upset about having that taken away.

I’m very much an outcome-driven developer, and to me it’s a giant relief. Not everyone will feel the same way.

Resource-constrained environments must be outcome-driven. They can’t spend their time on the process of software engineering; the best way for them to move forward is to start small, release a valuable core that solves a problem for some set of users as early as possible, and then continually iterate around it, using user feedback as a guide.

There’s no alternative to having empathetic, human-centered senior engineers on your team — with or without AI. But AI engineering tools may have an interesting side effect: I can see a world where pushing these product and spec questions to the forefront helps more engineers build those skills more quickly. The first step, after all, is understanding that those answers are needed to begin with.

It’s worth saying that there will be many managers who hope that tools like Claude Code will mean they can do away with engineers or dramatically cut their workforces. Of course there will. They may even see engineers as gatekeepers, and there may be resentment that they’re needed at all — and a hope that this work can be done directly by managers or other key employees. In a newsroom, for example, can’t the journalists produce tools now?

For non-engineers, they can be a useful prototyping tool: for a product manager, for example, it may help assess a user interface or experiment with an idea. But those prototypes are not enduring software; nor are they projects that can be “handed off” to engineers to support.

To properly architect a system, there’s a lot you need to consider. This includes performance, scalability, and the ongoing overhead of maintaining a project and keeping it safe: nobody wants to rely on software that proves to be slow, insecure, or impossible to update. You also need to assess the technical implications of a project: are there technical standards that the project should be adhering to, or battle-tested best practices that the design should take into consideration? For all these reasons, an engineer must be involved from the beginning.

These tools can’t replace technical staff, and they shouldn’t. Like I said, these tools are for engineers, not a replacement for them.

Okay, but what about those power dynamics?

Consider an individual, indie developer. Over the last few decades, they’ve become more and more empowered: developer tools have become cheaper and more of them are open source. Power and control have been devolved to the individual; you can run the tools you want on your own hardware, configure or recode them to your needs, use them for free, and share any of your changes. Engineering has become more and more of an open collective built on radical collaboration. That allows developers with fewer resources to build more easily, widening the pool of people who can build startups, create useful tools, and learn these skills to begin with.

AI-assisted engineering centralizes power back in the other direction. Claude Code, Codex, and so on are all centralized, proprietary tools that become harder to move away from the longer they’re relied upon. They’re also expensive: while open source tools are decentralized and free, it’s incredibly easy to spend large amounts on Claude. Based on my own experimentation and anecdotes from friends and peer companies, any engineer that relies on Claude Code as part of their daily work is likely to spend hundreds of dollars a week; these are new costs that didn’t previously exist.

Those extra costs could theoretically be offset by significant performance or efficiency gains. The thing is, those gains aren’t as strong as you might expect given the apparent magic of automatically generated code. A study recently published in Harvard Business Review indicated that adding AI actually intensified the workload, putting engineers at risk of burning out:

The changes brought about by enthusiastic AI adoption can be unsustainable, causing problems down the line. Once the excitement of experimenting fades, workers can find that their workload has quietly grown and feel stretched from juggling everything that’s suddenly on their plate. That workload creep can in turn lead to cognitive fatigue, burnout, and weakened decision-making. The productivity surge enjoyed at the beginning can give way to lower quality work, turnover, and other problems.

These can be mitigated by good work hygiene: enforcing breaks and sensible work hours. But the employers who are most enthusiastic about introducing AI may also be the ones that are least enthusiastic about benefits that center employee well-being over productivity.

I’ve already mentioned that some managers may hope that AI can reduce their investment in software engineers. One can easily imagine that the presence of AI — or, rather, the threat of being replaced by it — could be used as a cudgel to depress engineer salaries. It gives managers more leverage beyond money, too: those longer hours and more intense workloads that the HBR study found could burn engineers out might be more likely in a world where engineers fear for their jobs.

The long-term implications are even starker. Consider a world where the recentralization of power from individuals to large, centralized companies continues at the current pace. When AI writes most source code, fewer and fewer engineers will be capable of doing this work themselves, which will lead to even more dependence and lock-in.

It’s been noted in the past that while generative AI robs artists of the interesting work and leaves them with the mundane bits, for outcome-oriented engineers it robs them of the mundane bits and leaves them with the interesting parts. I’d argue that the real value is in the intersection between coding and the higher-level work; they’re inseparable. By improving the way we code, we improve the way we can solve problems for real people. (How can you solve a problem if you don’t really understand how the solution works?) By improving the way we think about solving problems, we improve the way we code. (How can you code something well if you don’t know who it’s for or why it needs to exist?) They aren’t two separate processes; they’re parts of the same thing. Removing one makes the other less effective.

Without concerted effort, an entire industry will be de-skilled and de-valued, their human expertise replaced with software that charges by the token.

So let’s put in the effort

AI isn’t going away, and AI-assisted software engineering is a permanent addition to the way we build software. But that’s not the same thing as saying that the way we use AI today won’t change.

Any policy for AI-assisted engineering has to take into account risks of various kinds. I’d loosely separate them into the following categories:

Employee risk: preventing burnout, staff turnover, and poor morale.
Security risk: preventing data leaks and security incidents that compromise customers, sources, employees, or other members of the community.
Quality risk: preventing low-quality code that impacts the efficiency, experience, or perceived quality of the organization’s work.
Supplier risk: reducing the potential impact of potentially harmful choices made by AI vendors.

While I’m not going to go into a full framework here — that’s part of what I do at my day job — let’s talk about how we might think about addressing them together.

Employee risk

In that Harvard Business School report about AI-driven burnout in engineers, the authors suggested some sensible mitigations. These included creating, as team norms, structured time for quiet reflection on the project at hand, and limiting interruptions; intentional processes for limiting the work that can move forward, to prevent engineers from taking on (or being asked to take on) too many tasks just because they think they can; and creating more space for empathetic human connection as a team.

Those are all things that every team should do, whether or not they use AI! But they become even more important on an AI-accelerated team. If you don’t have any norms about tightly controlling when work moves forward, for example, adding a tool that accelerates the work will result in a higher volume of work getting processed, but not necessarily any strategic selection about the most important work to do.

Perhaps most importantly, engineers are worried that they’ll be replaced at the hands of managers who may not understand what they do. They need to have the emotional safety and security that comes from knowing that they won’t. It needs to be communicated to them that the importance of their skills is understood. They are experts in their fields, and they’ve just gained another tool to help them; they are not interchangeable with the tool.

Security and quality risk

It turns out that you go a long way towards addressing a lot of security, quality, and efficiency issues — as well as some of the morale issues that lead to employee risk — by placing engineers at the center of the process. Some AI processes talk about “human in the loop”. That term was borrowed from more traditional machine learning processes; in the case of anything where AI takes an action in the world on behalf of a user, like engineering, I’d prefer to reframe it as a tool that is always directly under human control.

In that light, all code must have a human owner who will take responsibility for it. It’s their code, just as if they’d written it in an integrated development environment; they just happened to use a different tool. If all generated code must ultimately be owned and reviewed by a human, that person is able to tune the results for safety, efficiency, and quality.

Most well-run engineering teams have a peer review process where code written by an engineer must be officially reviewed by a second engineer before it can be merged into the main codebase. If we assume that generated code is owned by Engineer A, that means there must be a human Engineer B to give it a second pair of eyes. They might also be using automated tools to help their review along, but they’re the ones who ultimately take responsibility for a review.

This isn’t enough. All projects need to have comprehensive automated testing: tests that must run on code that is about to be merged into the main codebase in order to make sure everything still functions. Tests for efficiency, adherence to style guidelines, and security issues can be run here too. What’s kind of fun is that when these are in place, tools like Claude Code will look at the test output, make corrections when something doesn’t pass, and try again — all automatically.

Supplier risk

The centralization that removes power and agency from engineers also introduces a serious business risk. If a core part of an organization’s value comes from software development, inexorably placing a centralized service in the middle of your process makes you heavily dependent on their decision-making. They can increase their prices, make changes to their stack, or change the way they think about keeping your data and source code safe, and there’s very little you can do about it.

The good news is that, right now, no AI vendor can lock you into their services, because your source code itself and your infrastructure stack are independent of your AI tools. Your code is managed, stored, and hosted in different places, and you can think of source code itself as being a kind of open protocol: because it’s plain text, you can use virtually any tool with it. Source code still has the devolved, open, decentralized properties of the open source ecosystem that has put power in engineers’ hands for decades. That provides at least some protection against an AI vendor suddenly increasing their prices or changing their privacy stance: you can always vote with your feet.

If you’re uncomfortable using one of the major model providers, open source alternatives are available. Tools like Aider and Cline can provide agentic coding using any model, including local models that could theoretically be run on an organization’s own infrastructure. In practice, though, this requires more powerful hardware than most smaller organizations can afford; this may become less of an issue over time, as new hardware emerges, but it certainly is one now. Still, local models could help prevent lock-in — and may prevent some security issues, too.

This inherent openness could change as AI vendors look for ways to increase their revenue and reduce churn. We may see AI-specific alternatives to git and GitHub; I can even imagine programming languages that are “optimized for AI” but that just happen to be proprietary and locked in to a vendor. Every company that builds software should watch for these forms of lock-in and reject them.

We should also be wary of marketing that tells us to just let the AI write code autonomously. These are ideas that cement vendors as a full replacement for the software development process, moving a center of expertise that was previously owned by an organization into a centralized technology owned by someone else. It’s a trap: that world is one where the source code can’t be moved between agents and your products are fully locked into their services without a credible exit.

Do we want to invite these companies into our workplaces?

A ton has been written on the issues surrounding AI. Last summer, I wrote a broader guide to navigating AI that I think still holds up. In it, I noted:

A lot of money has been spent to encourage businesses to adopt AI — which means deeply embed services provided by these vendors into their processes. The intention is to make their services integral as quickly as possible. That’s why there’s heavy sponsorship at conferences for various industries, programs to sponsor adoption, and so on. Managers and board members see all this messaging and start asking, “what are we doing with AI?” specifically because this FOMO message has reached them.

My approach to evaluating AI remains through two main lenses: the technology itself and the vendors who make it. The further reading section of that earlier piece is a good place to start.

The thing that I didn’t mention then, but is worth calling out now, is the sheer precarity of these vendors. AI vendors are offering their services for below cost and have struggled to articulate value in a way that could credibly lead to profitability. Apparently feeling this gap, OpenAI is experimenting with ads and porn, while finding itself under scrutiny for putting teen wellbeing at risk through choices it made to boost engagement. Anthropic was sued by Reddit last year for scraping Reddit data for training without authorization, and had to settle a high-profile lawsuit brought by book authors whose work it stole for training data. I’ve mentioned Claude Code a bunch in this piece, because it works really well, but it was trained using stolen work.

Meanwhile, from a technical standpoint, there has been some research that there are diminishing returns to new LLM development and we’re already past the peak.

There’s no guarantee these companies will make it. If an organization has invested in agentic coding processes that don’t substantially keep humans in the loop and the vendors that power them disappear, they will be left in a bind, with no in-house expertise, and company strategies that depend on AI. That makes it a dangerous gamble. We will have lost internal skill while increasing our dependence on very fragile external suppliers.

So how should you think about it?

AI coding works. It shifts the center of gravity from implementation to judgment, which increases the value of senior engineering skills. It also introduces significant power, labor, and supplier risks. That means that solid guardrails and cultural norms are non-optional.

Even if you haven’t rolled it out yet, your engineers are almost certainly using it. In conversations with my peers, I’ve heard countless stories of organizations that banned it but discovered that its workforce had just taken matters into their own hands. While there are many engineers who refuse to touch it, many more are eager to have it.

You could ban it, but it’d likely be fruitless: those engineers who use their own accounts will probably keep doing so. It’s better to have the tools in a place that’s under your control and observable than used in the shadows in a way that might put your data at risk. Given that, it’s better to roll it out than to not. But you need to do it with your eyes wide open and with a sense of intentionality. Be aware of the risks, and mitigate them in advance with common sense cultural norms like the ones I discussed earlier: pay attention to your employee and supplier risks in particular. Don’t let AI push to production without oversight. And keep humans not just in the loop but fully in control.

I don’t think it’s productive to mandate the use of AI-assisted engineering, which runs the risk of alienating some engineers — the split between AI skeptics and those who are excited about the technology is real — and preventing nuanced discussions about how the technology can be used inside your workplace. What happens in practice when you just let it roll out to anyone who wants to try it is that people do try it; they find that it’s useful for some tasks, and then quickly find its limitations. That’s a healthy exploration.

How should I think about it? I’m still figuring it out. Jesse Vincent compares the process of hating “agentic” development and pushing through it to discover that code was never the most important part of building software to the process of being a manager and asking your team to build things instead of coding them yourself. I agree that these experiences rhyme — but of course, when you lead a team, you’re investing in human beings, working alongside them, and helping them to grow in the process. That’s exponentially more rewarding than leading software agents built to provide value for a megacorporation.

But it doesn’t need to be that way. You can do both. If you treat the technology as a tool, albeit one that has been made by genuinely problematic companies, you can roll it out to a real, human team and continue to build things together. You can invest in and support them while you navigate new kinds of software problems; together, you can figure out how to shape the culture of an engineering team that is undergoing a paradigm shift. You can train the next generation of software engineers, both keeping the long history of software development in mind, and taking into account these new skills. And you can look for the next thing that properly devolves power down the stack to the individual, for the benefit of everyone.

Software development is still human. You can work together towards a shared mission, pick and choose the pieces of this new technology that make sense according to your strategy and values, and build community in the process.

That’s a good vibe.

Everything is awesome (why I'm an optimist) - Westenberg

2026-02-25T01:39:00.000Z

February is the month the internet decided we're all going to die.

In the span of about two weeks, Matt Shumer's Something Big is Happening racked up over 80 million views on X with its breathless comparison of AI to the early days of COVID, telling his non-tech friends and family that we're in the "this seems overblown" phase of something much, much bigger than a pandemic. Before anyone had finished arguing about that, Citrini Research published THE 2028 GLOBAL INTELLIGENCE CRISIS (all caps) a fictional dispatch from June 2028 in which unemployment has hit 10.2%, the S&P 500 has crashed 38% from its highs, and the consumer economy has been hollowed out by what they coined "Ghost GDP": output that shows up in the national accounts but never circulates through the real economy, because, as Citrini helpfully observed, machines spend zero dollars on discretionary goods. Michael Burry signal-boosted it. Bloomberg covered it. IBM fell 13%. Software and payments stocks shed over $200 billion in market cap in a single day, apparently because a Substack post called upon them by name and investors decided that constituted news.

The doom loop Citrini described is simple: AI capabilities improve, companies need fewer workers, white-collar layoffs increase, displaced workers spend less, margin pressure pushes firms to invest more in AI, AI capabilities improve. Repeat until civilization unravels. Shumer, meanwhile, told people to get their financial houses in order because the permanent underclass is imminent.

Both pieces went stratospherically viral, and both, I believe, are entirely wrong about where this is heading.

I want to make a case for optimism.

For anyone who read those pieces and felt the dread, whether you're building AI and worrying about what it means, or you've absorbed the pessimist consensus and started treating decline as a foregone conclusion, or you’re in the bucket of people Shumer insists are fucked; I'm going to argue that the pessimists have the best narratives and the worst track record. The doom scenarios require assumptions that don't survive contact with economic history, and the psychological posture you bring to this moment actually matters for how it turns out.

Why the doom loop feels so right

The central mechanism of the Citrini thesis: when you make intelligence abundant and cheap, you destroy the income that 70% of GDP depends on. A single GPU cluster in North Dakota generating the output previously attributed to 10,000 white-collar workers in midtown Manhattan is, in their framing, "more economic pandemic than economic panacea." The velocity of money flatlines. The consumer economy withers. Ghost GDP accumulates in the national accounts while real humans stop being able to pay their mortgages.

Noah Smith, writing on Noahpinion the day after the selloff, called it "a scary bedtime story" and pointed out that Citrini doesn't use an explicit macroeconomic model, so you can't actually see what assumptions are driving the doom spiral. Smith noted that none of the analysts whose job it is to track Visa and Mastercard stock had apparently thought about AI disruption until a blogger spelled it out for them, which tells you more about sentiment-driven trading than it does about macroeconomics. The economist Gerard MacDonell described the entire piece as "allegorical" but pointed out that it ignores a basic economic principle: production generates income.

Ben Thompson, on Stratechery, has been making a version of this counterargument for months, most forcefully in his January piece AI and the Human Condition, where he argued that even if AI does all of the jobs, humans will still want humans, creating an economy for labor precisely because it is labor. Thompson's framing cuts to something the doom narratives consistently miss. They model AI exclusively as labor substitution: the same economy, minus humans. Every section of the Citrini piece is about replacing workers and squeezing margins on existing activity. What they don't model is what the freed-up surplus creates. As Thompson put it in his analysis of the Citrini selloff, this is the real error: a refusal to believe in human choice and markets.

It's an error that has been made, in nearly identical form, about every major technological transformation in modern history. Every single time, the pessimists looked at what was being destroyed and extrapolated catastrophe, while failing to imagine what would be created, because the thing that would be created hadn't been invented yet.

Catastrophists keep being wrong

In 1810, 81% of the American workforce was employed in agriculture. Two hundred years later, it's about 1%. If you had shown someone in 1810 a chart of agricultural employment decline and asked them to model the economic consequences, the only rational projection would have been apocalypse. Where would 80% of the population find work? What would they do? How would anyone eat if the farmers were all displaced by machines?

The answer, of course, is that entirely new categories of work were created that no one in 1810 could have conceived of, and these new jobs paid dramaticaly more than subsistance farming. Factory work, office work, services, knowledge work, the entire apparatus of modernity: none of it was visible from the vantage point of the pre-industrial economy. The transition was brutal and uneven. The handloom weavers of England suffered. Dickens documented the squalor of early industrialization in prose that still makes you flinch. But the trajectory was real, and the people projecting permanent immiseration from the displacement of agricultural labor were, in the fullest sense, catastrophically wrong.

Tom Lee of Fundstrat made this point with a specific example that I find clarifying. The invention of flash-frozen food in the early 1900s disrupted farming, taking agriculture from 30-40% of employment down to its current sliver. The economy didn't collapse. It reallocated value elsewhere, into industries and occupations that the frozen food pioneers couldn't have imagined. And today, I can't name a single family that subsists on frozen TV dinners.

The Citrini scenario expects you to believe that AI will be the first major technological revolution in which this reallocation mechanism fails entirely. Where every previous wave of automation freed up human labor and capital to flow into new, higher-value activities, this time the loop... stops. The surplus accrues to the owners of compute, consumers lose purchasing power, and the negative feedback loop has no natural brake. It's worth sitting with how strong a claim that is. It requires every previous pattern of technological adaptation to be wrong, or at least irrelevant. And when you look at the actual data, there are signs that white-collar job postings have stabilized, layoff mentions on earnings calls remain well below early 2023 peaks, and forward-looking labor indicators show no sign of the displacement spiral that the doom thesis predicts.

Does that mean AI won't disrupt specific industries and jobs? Obviously it will. Some of those disruptions will be painful and dislocating for the people caught in them. But there's an enormous gap between "this technology will cause serious labor market disruption that we need to manage" and "this technology will cause a self-reinforcing economic death spiral from which there is no recovery." Citrini is arguing the latter, while the evidence supports the former.

Why vivid scenarios beat boring probabilities

There's a reason the doom narratives go viral while the measured counterarguments get a polite nod // a fraction of the engagement. It has nothing to do with the quality of the underlying analysis. It has everything to do with how human brains process information.

Daniel Kahneman's work on the availability heuristic showed that we judge the probability of events by how easily we can imagine them. Dystopia is easy to imagine. We have an extraordinarily rich cultural tradition of imagining technological nightmare scenarios in exquisite detail. Orwell did it brilliantly. Every season of Black Mirror does it competently. The Terminator gave us the visual grammar for AI catastrophe decades before anyone had a working language model. When Citrini describes a world where the unemployment rate hits 10.2% and the S&P crashes 38%, you can picture it. You can feel the dread. Hollywood has been training you to feel exactly this dread for your entire life.

Now try to imagine the positive scenarios. Try to picture, in concrete sensory detail, a world where AI helps us solve protein folding problems across thousands of neglected tropical diseases, where it accelerates materials science research by orders of magnitude, where it makes high-quality legal and medical advice accessible to people who currently can't afford it, where it enables forms of creative expression and economic activity that we can't yet name because they don't exist yet. It's fuzzy and abstract. You can state it intellectually, but you can't feel it the way you can feel the unemployment spiral.

This asymmetry isn't trivial. The Ifo Institute has published research showing that investors are willing to pay more for economic narratives than for raw forecasts, and that pessimistic narratives command higher prices among certain investor types. As Joachim Klement put it in his response to the Citrini selloff: investors value narratives more than actual recession forecasts. Stories travel faster than spreadsheets.

Shumer's piece is a narrative construction, and a questionable piece of analysis. He opens with the COVID comparison: remember February 2020, when a few people were talking about a virus and everyone thought it was overblown? He positions himself as the insider who sees what's coming, who's been "giving the polite, cocktail-party version" but can't hold back the truth any longer. Paulo Carvao, writing in Forbes, noted that it reads at times like a sales pitch. It’s a used-car pitch at that. The Guardian pointed out that Shumer "previously excited the internet by announcing the release of the world's 'top open-source model,' which it was not." (To be clear: this is a kinder way of saying it was fraud.)

But criticism doesn't travel like fear does. Fear is a better story. And so the doom narratives accumulate cultural mass while the boring, incremental, statistically-grounded counterarguments remain niche reading for economists and strategists.

We remember disasters, not the ones we dodged

Humans are spectacular at remembering disasters, passed down in every format from the written word to the oral tradition. We are (for obvious reasons) terrible at remembering the disasters that didn't happen. In 1962, during the Cuban Missile Crisis, a Soviet submarine officer named Vasili Arkhipov refused to authorize the launch of a nuclear torpedo, overriding two other officers who wanted to fire. The world didn't end. Most people today have never heard of Arkhipov. Everyone knows about Hiroshima and Nagasaki. The bomb that fell is seared into collective memory. The bomb that didn't fall is a footnote.

The Y2K bug was going to crash civilization; then billions of dollars of engineering work fixed it, and everyone retroactively decided it was never a real threat. The ozone layer was going to disintegrate; then the Montreal Protocol worked better than almost anyone predicted, and ozone depletion feels like a quaint 1990s worry. Acid rain was dissolving the forests of North America; then sulfur dioxide regulations cut emissions drastically, and the whole issue evaporated from public consciousness. Every one of these was a genuine threat. Every one was met by human ingenuity and institutional coordination. Every one was subsequently memory-holed, because success is boring and failure is vivid.

We're running our forecasting models on a dataset that systematically excludes our wins. It should be entirely unsurprising that the forecasts come out somewhat bearish.

Ben Thompson (as usual) gets it right

Thompson's core insight is that humans want humans. He points to the agricultural revolutions: in the pre-Neolithic era, zero percent of humans worked in agriculture. By 1810, 81%. By today, 1%. Machines replaced human agricultural labor entirely, and rather than the economy collapsing, entirely new categories of work were created that paid dramatically more. This cycle played out again with industrialization, with computing, with the internet. Every time, the displacement was real, and every time, new forms of human-valued work emerged that couldn't have been predicted.

Citrini called DoorDash "the poster child" for AI disruption, imagining vibe-coded competitors fragmenting the market overnight. Thompson flips it: DoorDash is the poster child for why the article is absurd. DoorDash didn't always exist. It was built, and it wins through the active choice of customers, restaurants, and drivers. The doom thesis treats it as a static rent-extraction layer sitting on top of human laziness, but DoorDash created its market from scratch and generated new jobs for millions of drivers along the way. What the Citrini analysis lacks, Thompson argued, is any belief in human choice or markets. If your starting assumption is that things are as they are, you can only envision breaking them.

Citrini predicted AI would collapse real estate commissions by eliminating information asymmetry. But the internet already did that. You can look up every house for sale right now, with full history and photos. Real estate agents still exist, which is one of the better arguments that humans are resourceful at giving themselves work to do even in fields where they arguably shouldn't need to.

In a world of AI abundance, the things humans create will become more valuable precisely because they're human. AI art will make human art more desirable, not less, because provenance matters. AI-generated content will make human-generated content worth more, because the imperfections and idiosyncrasies are features.

Is this optimistic? Yes. Could it be wrong? Sure it could. But it's grounded in a real observation about human psychology that the doom models don't account for. Citrini's Ghost GDP thesis assumes that when AI replaces human labor, the value simply evaporates from the consumer economy. Thompson's counterargument is that humans will create new forms of value that are specifically human, and that demand for those forms of value will intensify as machine-generated alternatives become ubiquitous. The history of technological disruption suggests Thompson has the stronger case.

Pessimism as a self-fulfilling prophecy

What actually worries me is the second-order effects of the doom narrative itself.

When the smartest, most technically capable people in a field become convinced that the field is heading toward catastrophe, several things happen. Some leave the field entirely, removing exactly the talent you'd want steering the ship. Some stay but adopt a posture of resigned inevitability, which is functionally identical to apathy. Some decide that since disaster is coming, they might as well accelerate and cash out. And a vocal minority become so consumed by existential risk that they advocate for extreme countermeasures that would concentrate power in ways that create entirely new categories of danger.

Robert Oppenheimer (in the wake of his famous invocation of the Bhagavad Gita) spent the years after the Manhattan Project arguing passionately for international cooperation on nuclear governance. He didn't say "we should never have done this." He said, essentially, "this is incredibly powerful, and we need to build institutions that can handle it." He was an optimist in the meaningful sense: he believed better outcomes were achievable if people worked to achieve them. He was right about that, because we're still here.

The most effective people working on AI safety and governance right now are, almost without exception, optimists. They work on alignment because they believe alignment is solvable. They push for better governance becuase they believe governance can work. The ones who've concluded that the problem is unsolvable tend to stop doing useful work, for obvious reasons.

Gramsci wrote about "pessimism of the intellect, optimism of the will." You look at the world clearly. You see the problems. And then you choose to act as if better outcomes are possible, because that choice is the precondition for achieving them.

Nobody can see the next economy

What both Shumer and Citrini miss is that they're modeling a future economy using the structure of the present economy. They see AI replacing white-collar workers within the existing economic framework and project the consequences of that replacement within that same framework. But every major technological transformation has changed the framework itself, creating entirely new economic structures that were invisible from the vantage point of the old ones.

In 1995, if you told someone that one of the largest employers in America would be a company that let strangers sleep in each other's homes, they would have thought you were insane. If you told them that millions of people would make a living by talking into microphones about their opinions, or recording themselves playing video games, or writing newsletters on the internet, they'd have had you committed. The entire creator economy, the gig economy, the app economy, the SaaS economy that Citrini is now eulogizing: none of it was predictable from the vantage point of 1995. And that's a 30-year window. The agricultural revolutions played out over centuries.

What will people do when AI can handle most current white-collar tasks?

I don't know.

And that's the whole point.

Nobody knew what displaced agricultural workers would do, either, until they did it. The absence of a visible next chapter isn't evidence that there won't be one. It's evidence that we're bad at predicting what humans will invent when constraints shift.

Choosing optimism with open eyes

I'm not saying everything will be fine. I'm not saying the transition will be smooth. I'm not saying that the people displaced by AI won't suffer, or that we don't need better policy frameworks to handle the disruption. The distributional concerns at the heart of the Citrini piece are legitimate. If productivity gains accrue primarily to the owners of compute and capital while labor income stagnates, that's a genuine problem. Labour's share of GDP has been declining for decades. These are real numbers pointing to real challenges.

What I am saying is that the leap from "this will be disruptive and we need to manage it carefully" to "this will cause an irreversible economic death spiral" isn't supported by the evidence, by economic history, or by what we know about how humans respond to technological change. The Citrini scenario requires every adaptive mechanism in the economy to fail simultaneously and completely within roughly two years. That's a very specific left-tail outcome.

If you're building AI systems, if you're founding companies, if you're writing code that will shape how people experience the world, your psychological orientation toward the future is a variable that directly shapes // affects outcomes. Pessimistic builders build defensively. They hoard and hedge and make decisions based on fear. Optimistic builders build with ambition. They invest in safety because they believe safety is achievable. They take on hard problems because they believe hard problems have solutions.

The tech industry is at a hinge point, and the narrative it tells itself will shape what it creates. If the dominant narrative is doom, the best people leave, the remaining people race to extract value before the collapse, and the governance frameworks get built by people who don't understand the technology. If the dominant narrative is cautious optimism, the best people stay, the work is good, and the institutions get built by people who know what they're building for.

Ed Yardeni, the veteran Wall Street strategist, noted in the wake of the Citrini selloff that "the AI story has morphed from a Roaring 2020s productivity booster to an existential threat to our way of life." He found this striking. I find it absurd. The underlying technology hasn't changed, and the capabilities haven't shifted. What changed is the narrative, and narratives are always, always choices.

I choose optimism. I choose it because the alternative is surrender as sophistication. And because every time I look at the historical record, the full record that includes both the disasters and the averted disasters, both the tragedies and the triumphs, the case for human ingenuity and resilience is stronger than the case against it.

The doomers may have the best stories.

I believe the optimists have the best evidence.

I'll take the evidence.

Everything is (going to be) awesome.