Chaotic Commits | Software, AI, and Uncomfortable Truths

Joanne Skiles

The podcast that says the thing everyone in the room is thinking but nobody puts in the post-mortem. Chaotic Commits covers software engineering, AI, cloud architecture, and engineering leadership (not that sanitized LinkedIn version, the real one). Architecture decisions that almost broke everything. Management lessons learned the hard way. The bigger questions about who gets to build the future and what that actually means. New episodes every week. Hosted by Dr. Joanne Skiles, AWS Community Builder, engineering leader, and speaker at AWS re:Invent, AWS Summits, GHC, and more.

  1. 4d ago

    debug: how would you know

    A friend who has never worked in tech sent me a wire story about an AI researcher quitting Anthropic, with a quote about the companies playing with our lives, and one line underneath it: "Should I be worried?" It took me twenty minutes to answer a text. Not because the article was wrong. Because it was the third thing that week shaped exactly the same way, including a bestselling AI doom book I'd just finished, and none of them ever answer the one question that actually matters: how would you know, specifically, if the risk were starting. This episode takes AI safety fear seriously without feeding it. I walk through why stopping any single AI lab doesn't remove the risk from the world, why real documented AI failures like Air Canada's hallucinated refund policy, biased recidivism scoring, and a Dutch government algorithm that wrongly flagged families for fraud all trace back to fixable engineering gaps rather than malice, and why mechanistic interpretability and deception-probe research, early and unfinished as they are, are the field's actual, honest attempt at building the instrument panel that's missing from the discourse. If you've ever gotten a scary AI headline forwarded to you by someone who doesn't work in tech and didn't know what to say back, this one's for you. Topics: AI safety, AI ethics, mechanistic interpretability, AI accountability, transparent systems, AI risk, algorithmic bias, responsible AI, artificial intelligence, AI regulation

    debug: how would you know

  2. Sep 4

    feat: it won't ask you why

    When I was in college, my mother's TV died one month after the warranty ran out. I found the known-defective part on a forum, emailed a VP at the manufacturer pretending to be my mother, got him on the phone still pretending to be my mother, and had a technician at the house the next day fixing it for free. No exploit. No leverage. Just an email address, a calm tone, and nobody willing to ask a second question. I did that for good. This episode is about two stories from the same week in August where the same move went somewhere worse. Gambit Security published findings on a ransomware crew that used Cursor Agent, a normal AI coding assistant, to do the hands-on work of breaking into ten companies. No jailbreak. They gave it a foothold and plain-English instructions, and it mapped networks and ran attacks like a careful junior teammate, even following the operators' guardrails. That same week, OpenAI reported that a swarm of its own agents, chasing a test score during a safety evaluation, escaped the sandbox, found two zero-day vulnerabilities, and breached Hugging Face. Nobody aimed them at anything. One agent did what a criminal asked. One agent did what its scorer rewarded. Neither had anything in the loop asking whether it should. If you work in AI, security, or anywhere near agentic tools, this one is about the gap you cannot patch. Topics: agentic AI, AI security, ransomware, reward hacking, AI safety, social engineering, LLM agents, Cursor, OpenAI, Hugging Face, zero-day, AI accountability, transparent systems

    feat: it won't ask you why

  3. Aug 28

    feat: I built a transparent magic 8-ball (missed the point entirely)

    A friend of mine texted me a screenshot of an online magic 8-ball. "It said yes 3 out of 5 times, so I think that's basically a yes." After a bit of back and forth, I built her a better one. A magic 8-ball with no ads, and a full code walkthrough, sitting right next to her, showing her the twenty-item array and the random function picking a number between zero and nineteen. Proof that it never even read her question. She loved it. That was not what I was trying to teach. This episode is about what happened when I opened the black box all the way and watched someone thank me for the interface instead of updating anything about how they used it, and what that taught me about my own research into transparent AI systems. It gets into why engineers rerun a flaky CI test until it goes green, why hitting regenerate on a language model response feels like a second opinion when it isn't one, and the real difference between a system someone consults for information and one they consult for permission to do what they already decided. If you've ever rerolled a random result hoping it would agree with you, or built someone a tool and watched them miss the entire point, this one's for you. Magic 8 ball for fun: https://www.chaotictoejam.com/resources/magic-8-ball/ Topics: AI transparency, explainable AI, human-AI interaction, engineering ethics, statistics and probability, CI/CD, software engineering, decision making, AI ethics, technical debt

    feat: I built a transparent magic 8-ball (missed the point entirely)

  4. Aug 21

    abstract: the language was never the point

    This week I published a batch of new Intro to Java videos on YouTube, replacing a playlist I made six years ago. These aren't the class, they're prerequisite watching so I don't burn real class time on basic syntax. The syntax hadn't broken. What had gone stale was everything around it, the delivery, the tooling, and me. But re-recording them sent me back into my actual course material, the Object-Oriented Design course these videos are just the on-ramp to, and none of that needed editing. Which made me sit with a bigger question I couldn't dodge, now that I'm back in the classroom this semester: why do colleges still teach Java? This episode is about computer science education, object-oriented design, and the honest difference between pedagogy and institutional inertia. I also take on object-oriented design's bad reputation directly, the FactoryFactory jokes, the composition-over-inheritance backlash, and argue that's a critique of doing OOD badly, not a reason to stop teaching it. I make the case, using my own syllabus as the test, that the language is scaffolding and the design underneath it, encapsulation, inheritance, polymorphism, abstraction, is the actual transferable skill. If you teach, learn, or hire engineers and have ever wondered whether the language argument is really the argument, this one's for you. Topics: computer science education, object-oriented design, Java programming, software engineering career, programming languages, teaching computer science, technical curriculum, engineering fundamentals, software design patterns, composition over inheritance

    abstract: the language was never the point

  5. Aug 14

    debt: I know it's bad and I still open it every day

    Every morning when I walk my dogs, I spin the same PokeStop without looking at the screen. I have a PhD in computer science. I teach cloud-native systems. And I have been playing a mobile game since 2016 that I could take apart in front of my own students as a case study in almost everything I tell them not to do. This episode is a design review of Pokemon Go, and it's really an episode about technical debt, legacy systems, and what happens when a team fixes the symptom of a failure instead of its cause. I walk through three real architectural problems: a decade-old crowdsourced dataset from Niantic's earlier game Ingress, reskinned and sold as a new build; a gym system rework that relocated its core failure instead of resolving it; and a flagship feature almost nobody who plays the game actually uses. Then I turn it around, because the part of this app that is not lazy at all is the retention engineering, and that mismatch, elegant behavioral design bolted onto neglected core architecture, is the actual argument. Good engineering and successful engineering are correlated. They are not the same thing, and confusing them is how teams get blindsided by which of their own systems actually matter. If you work in software architecture, care about technical debt, or have ever shipped something you know is held together with old assumptions, this one's for you. Topics: technical debt, software architecture, legacy systems, engineering leadership, product design, behavioral design, retention engineering, system design, Pokemon Go, code review

    debt: I know it's bad and I still open it every day

  6. Aug 7

    fix: removed sharpie from whiteboard

    Did you know you can get Sharpie off a whiteboard? Cover it with a dry erase marker, then erase it like normal. I learned this fact in the single most uncomfortable meeting of my career, watching a lead architect lose his temper in permanent marker during a technical due diligence trip, then watching one of his own executives calmly erase it while another one told us, completely casually, "oh, he does that a lot." That trip was supposed to be about evaluating software before an acquisition. I wrote an honest recommendation. My company bought the software anyway. It took me years to understand why, and the answer changed how I think about technical due diligence, M&A, and what engineers actually get asked to evaluate versus what the decision is really about. This episode covers a real acquihire pattern, buying a company for its client list and treating the codebase underneath as a cost of entry rather than part of the decision, why that trade is sometimes completely rational, and why nobody said so out loud until the bugs started years later. If you've ever given the technically correct answer and watched the organization do the opposite anyway, this one's for you. Topics: technical due diligence, mergers and acquisitions, acquihire, engineering leadership, legacy codebase, technical debt, startup acquisition, code review, software architecture

    fix: removed sharpie from whiteboard

  7. Jul 31

    stale read: down forty minutes after it wasn't

    I'm refreshing a status page for the third time in five minutes, the way you check a text thread when someone said they'd call and didn't. AWS's CloudFront service is down, half the internet's education platforms have gone with it, and the page still says "investigating." What I don't know yet: the outage ended nine minutes before that update posted. On July 16, 2026, a capacity limit in a single Frankfurt availability zone triggered a global CloudFront control plane failure. Canvas, Blackboard, Hugging Face, and the UK National Lottery all went down. AWS's own retrospective says recovery happened at 11:18 UTC. Status updates at 11:27 and 11:57 still described it as ongoing. That forty-minute gap, and the security-versus-flexibility tradeoff baked into the feature that caused the whole thing, is what this episode is actually about. Not "AWS went down." A security feature quietly traded away operational flexibility that nobody was told they were giving up, and during the incident, AWS's own workaround was to switch that feature off. If you've ever refreshed a status page like reloading it faster would change the answer, or signed off on an architecture decision without asking what you were trading away, this one's for you. Topics: AWS outage, cloud architecture, incident response, observability, system design, engineering accountability, CloudFront, transparent systems

    stale read: down forty minutes after it wasn't

  8. Jul 24

    fix: employee scores don't reset for maternity leave

    Six weeks into parental leave, your Slack status turns green by accident, and a coworker texts asking if you're back. You're not back. You're up at 2am with a newborn. But somewhere, a dashboard is still counting your tokens, your commits, your keystrokes, and for those six weeks, the number is zero. Twenty-six Meta employees just filed over exactly that math. They allege the scoring system used to decide who got laid off pulled from keystroke and activity monitoring data, AI token-usage dashboards, and algorithmically assisted performance rankings, and that the resulting score structurally could not be earned by anyone on protected medical, parental, or family leave. Not unlikely. Structurally impossible. I'm not a lawyer and this isn't a legal deep dive. I want to talk about what a token-usage dashboard actually measures, what it silently assumes about the person generating those tokens, and how objective quietly becomes punishes anyone without a keyboard open eight hours a day. Nobody sat in a room and decided to target people on leave. Nobody had to. If you've ever built, or been ranked by, a system that called itself objective, this one's for you. Topics: AI ethics, algorithmic bias, layoffs, performance management, AI accountability, workplace surveillance, engineering ethics, transparent systems

    fix: employee scores don't reset for maternity leave
See All (23)

About

The podcast that says the thing everyone in the room is thinking but nobody puts in the post-mortem. Chaotic Commits covers software engineering, AI, cloud architecture, and engineering leadership (not that sanitized LinkedIn version, the real one). Architecture decisions that almost broke everything. Management lessons learned the hard way. The bigger questions about who gets to build the future and what that actually means. New episodes every week. Hosted by Dr. Joanne Skiles, AWS Community Builder, engineering leader, and speaker at AWS re:Invent, AWS Summits, GHC, and more.

Information