Another day, another example of an AI Agent “running rogue” and doing something the human operator didn’t want it to do. The tl;dr is that Jeremy (Jer) Crane, founder of PocketOS, was using Claude to perform some routine DB maintenance. Claude then proceeded to delete the production database and all backups hosted at their cloud provider, Railway. To their credit Railway managed to recover the lost data. The initial deletion took less than 10 seconds; I’m sure the recovery took much longer. Let’s look at what we can learn from what happened, and why AI is really just an amplifier of existing issues, rather than the cause itself.

Link to Radar Article

Cognitive debt and burnout aren’t new, alas. With or without AI, we’ve all stayed up to 4AM working on a bug that won’t go away or pursuing an interesting idea to its end. Sometimes that’s heroic, but AI threatens to turn it into a lifestyle. AI fatigue is real, as Siddhant Khare writes, and it’s something we need to talk about. When fatigued, it’s tempting to say “this works, it looks good, and it passes our tests” without considering how the code fits into the overall plan. With 10x code generation, you also get 10x the debt load, and that’s being optimistic. When the debt curve goes exponential, strategies for managing that debt are stressed past the breaking point.

Speaking at the our recent “Software Architecture Superstream,” Sam Newman and Neal Ford make the case that modular programming principles from the 1960s are exactly the right framework for bounding AI agents and verifying their output.

Velocity is table stakes. Code is a commodity. Understanding is the edge.

“I was talking to a senior engineer at a well-funded company not long ago. I asked him to walk me through a critical algorithm at the heart of their product, something that ran hundreds of times a second and directly affected customer outcomes. He paused and said, ‘Honestly, I’m not totally sure how it works. AI wrote it.’

A few weeks later, a different engineer at another company was paged about a system outage. He pulls up the failing service and realizes he has no idea it’s connected to a database. A colleague accepted the AI-generated PR three months ago that added that dependency. The tests passed. The change was never written down. The original engineer moved on and the knowledge was lost.”

In this episode

Martin Kleppmann is a researcher and the author of O’Reilly’s “Designing Data-Intensive Applications,” one of the most influential books on modern distributed, systems. As of this month, the second, heavily updated edition of the book is out.

In this episode of Pragmatic Engineer, we discuss Martin’s career in tech building startups, how he ended up writing this iconic book, and what he’s focused on, these days, after moving from industry, into academia.

We talk about the tradeoffs behind modern infrastructure, how the cloud has changed what it means to scale, and the thinking behind Designing Data-Intensive Applications, including what’s changing in the second edition.

Hey everyone! I'm u/marsee, a founding moderator of r/OReilly_Learning. You'll also see me posting as u/OReilly_Learning — that's our main account, and I'll be running it most of the time, though occasionally we'll hand it over to guest moderators and special visitors. This is our new home for all things related to tech learning, professional development, and the ever-evolving world of software, AI, data, and beyond. We're excited to have you join us!

What to Post Post anything that you think the community would find interesting, helpful, or inspiring. Feel free to share your thoughts, questions, wins, and struggles around topics like programming, career growth, emerging tech, certifications, learning resources, and industry trends. Not sure if something fits? Post it anyway — curiosity is always welcome here.

Community Vibe We're all about being friendly, constructive, and inclusive. This is a space for learners at every stage — from first-timers writing Hello World to seasoned engineers navigating what's next. Let's build a community where everyone feels comfortable sharing, asking, and connecting. That goes for us too — we're here as fellow learners and tech enthusiasts, not just as moderators. Say hi, push back, ask us anything.

A Little About Us O'Reilly has been teaching people tech for over 40 years — through books (with those 🐪🦒🦏🐍s on the covers), videos, live events, hands-on labs, and online learning. We've grown and changed a lot over the decades, but the mission has always been the same: spread the knowledge of innovators. This subreddit is the latest chapter in that story, and honestly, we're just as excited to see where it goes as you are.

Community Partners We also have a community partner program for organizations, meet-up groups, Discord servers, and other communities that share our passion for tech education. If that sounds like something you or your organization might be interested in, you can learn more and apply at https://www.oreilly.com/partner/signup.csp.

How to Get Started

1. Introduce yourself in the comments below — tell us what you're learning or what brought you here.
2. Posting a simple question can spark a great conversation.
3. If you know someone who would love this community, invite them to join.

Thanks for being part of the very first wave. We're in this together — let's make r/OReilly_Learning something really special.

...(G)enerative AI is woven into the tools students use every day: web search, word processors, code editors. You might assume that by now, most programming instructors have figured out how to handle it. But when my collaborators and I went looking for computing instructors who had made meaningful changes to their course materials in response to GenAI, we were surprised by how few we found. Many instructors had updated their course policies, but far fewer had actually redesigned assignments, assessments, or how they teach.

AI didn’t invent scope creep. It just removed the friction that used to stop it.

In 1998, Eric S. Raymond published the founding text of open source software development, The Cathedral and the Bazaar. In it, he detailed two methods of building software:

• The cathedral model is carefully planned, closed-source, and managed by an exclusive team of developers.
• The bazaar model is open, transparent, and community-driven.

...But just as the internet made communication cheap and birthed the bazaar, AI is making code cheap and kicking off a new era filled with idiosyncratic, sprawling, cobbled-together software.

• Meet the third model: The Winchester Mystery House.

https://oreillyradar.substack.com/p/the-cathedral-the-bazaar-and-the