Keeping up with AI

AI agents that write, test and ship code with no humans involved sounds like the future of engineering. But what happens when nobody reads the code?

In this episode, I look at whether "software factories" really deliver the automation they promise with no human oversight. I cover the difference between a lights-on factory and a dark factory, why review has become the bottleneck (with data from Faros AI, IDC and Gergely Orosz), and why code quality decays so quickly when nobody is reading it, including what Dex Horthy learned from his own experiment and what the SlopCodeBench research shows.

Then I compare where StrongDM, Dex Horthy, Geoffrey Litt and Lauren Tan each think the human should stand, and why I think they agree more than it first appears. I close with the rule I'm going to try on my own team: the amount of review a change needs should depend on how much automated proof surrounds it, built from three layers of structure, enforcement and evidence.

This is the first of three episodes on software factories. Thisepisode is for developers and engineering leaders deciding how much AI-generated code to trust. If you're a product manager or AI-curious, I explain the terms along the way.

SHOW NOTES

• Lauren Tan, "How I Shipped 2000 PRs Last Month, Trusting AI Agents":https://www.youtube.com/watch?v=NjoZoUm85x0

• Dex Horthy, "Why Software Factories Fail" (AI Engineer): https://www.youtube.com/watch?v=Ib5GBkD555M

• Dex Horthy, "Fighting Code Slop: The State of Software Factories" (Agentic AI Foundation): https://www.youtube.com/watch?v=ix1qQK1IvmA

• Geoffrey Litt, "Understanding is the new bottleneck" (AI Engineer): https://www.youtube.com/watch?v=WkBPX-oDMnA

• Gergely Orosz, "The state of the tech industry in 2026" (LDX3 New York): http://www.youtube.com/watch?v=Ru99FGJ_yuE

• StrongDM's software factory page: https://factory.strongdm.ai/

• Simon Willison on StrongDM's software factory: https://simonwillison.net/2026/Feb/7/software-factory

• Faros AI, "AI Acceleration Whiplash" research: https://faros.ai/research/ai-acceleration-whiplash

• SlopCodeBench paper: https://arxiv.org/html/2603.24755

• IDC survey figures, as reported by TechTarget: https://www.techtarget.com/it-infrastructure/news/366651847/Vendors-build-safeguards-for-autonomous-software-factories

A new kind of AI model called Jev launched on September 15. Within about two weeks, Amazon, OpenAI, Cloudflare, and a long list of open-source projects had shipped rivals. Jev is a decision model, which means it picks an answer instead of writing one. The answer can be a choice, a score, or a yes or no with a confidence number attached.

In this episode, I step back from the question of which model is best, because any answer would be outdated before you finish listening. Instead, I focus on how to choose one for a real production pipeline. I start with why vendor benchmarks deserve some skepticism, and what the independent DecideBench results show about accuracy and cost. Then I walk through six questions to ask before you commit: where the model runs, what input it accepts, how fast it needs to be, whether its confidence scores hold up on your own data, what it costs at your volume, and how hard it would be to switch later.

I also apply those questions to two very different scenarios, support ticket triage and a latency-sensitive trading or game loop, and I close with my prediction for where this category goes next.

This episode is for developers, product managers, and engineering leaders. The full written post and all the links are in the show notes.

---- SHOW NOTES ----

Written post: https://swapniltalekar.substack.com/p/the-decision-model-gold-rush

Earlier post on Jev (previous week): https://swapniltalekar.substack.com/p/jev-and-the-return-of-the-classifiers?r=1v4ea

Models mentioned: Jev (TypeSafe), Strands Decider 2B (Amazon), Decisions API (OpenAI), Clef (Cloudflare), GLiDE and GLiNER2.5-Decide (Fastino), Imajev-4B, Laya, OpenJev, JevK5, von

Benchmarks mentioned: DecideBench (Cho Yin Yong), JevBench

Comparison table (first week of October 2026): see the written post

TypeSafe's new model Jev has been billed everywhere as the end of hallucinations, and that framing is misleading. In this episode, I dig into what Jev actually is: a System One model that returns a structured decision instead of open-ended text, paired with a training method called RLCD that's built for calibration rather than raw accuracy.

I walk through why this feels like a swing back to the classifiers we used before LLMs ate every decision-making task, why that framing alone undersells what's new here, and why calibration, not the absence of hallucination, is the real breakthrough. I also get into why Jev needs frontier-level text comprehension even though it never produces a word of output, why that makes it hard to benchmark, and why its calibration claims are still essentially a promise from TypeSafe until it's been tested at scale. Finally, I cover the practical limits worth knowing before you reach for it.

If you've seen the hype and want the honest read on what Jev is actually good for, this one's for you.

Ever wonder why your AI agent burns through thousands of tokens just to say "hi"? In this episode, I break down what I learned after three months of running my own personal Hermes agent, and why I ended up completely rethinking how I run models for it.

We dive deep into how agent frameworks actually use an LLM's context window, and why a single "hi" message can costanywhere from 10,000 to over 40,000 tokens. It's not a bug; it's what makes an agent an agent.

From there, I walk through why local models and even frontiermodels like Claude and GPT became impractical for a hobby budget, a sneaky Hermes config bug that cost me weeks, and how I eventually landed on OpenRouter, a model gateway that turned out to be super useful. I cover automatic failover, multi-level caching, and why sticky sessions matter so much for agent workloads specifically.

If you're building or running your own AI agent, this one willsave you some expensive trial and error.

Show Notes

• Full article: "Should you be running LLM models locally for your agents?" — Swapnil Talekar's Substack
• Hermes config fix for the encrypted content error: set include_encrypted_content: false in ~/.hermes/config.yaml
• Models mentioned: Qwen-3.6-35B-A3B, DeepSeek-v4-Flash, NVIDIA Nemotron (free tier)
• Inference providers referenced: Together AI, Fireworks AI
• Gateway discussed: OpenRouter

Three months ago, I gave up on OpenClaw and switched to Hermes for running my own personal AI agents, and I've been living with it since. In this episode, I walk through what actually changed. Everything that I learnt and everything that surprised me. I talk about some of the Hermes internals and what makes it so powerful: profiles that isolate memory, workspace, and even the messaging gateway per agent, which is the single feature that makes Hermes feel more like actually distinct agents.

I get into the three agents I use daily: a personal accountantthat watches my investments, a health coach that logs my meals and workouts over Telegram, and a Montessori teacher for my four-year-old, plus how I picked cheap, capable models through OpenRouter instead of running anything locally.

I also cover what hasn't gone smoothly: agents that mark work done without checking it, a genuinely strange recurring date bug that hit two unrelated agents, and one agent that looped a hundred and fifty times fixing a bug that turned out to be one missing HTML tag.

This one's for anyone experimenting with personal AI agents, or thinking about it- developers and tinkerers especially- or anyone curious what living with an always-on AI assistant is actually like.

Full Substack article -https://swapniltalekar.substack.com/p/three-months-of-running-personal?r=1v4ea

Everyone on AI Twitter seems to be running a twelve-agent swarm that ships products while they sleep. Meanwhile, most real workflows still look like three chat tabs and a lot of copy-pasting.

In this episode, I dig into whether multi-agent workflows are real or mostly marketing. I break down how Claude, Cursor, and Codex each approach running multiple agents at once: Claude's Agent Teams, with a team lead, a shared task list, and file locking; Cursor's orchestration workspace, including Best of N and Build in Parallel; and Codex as a specialist agent that other systems orchestrate around. I walk through the five patterns that actually show up in practice, plan-build-review, parallel research, role specialization, best-of-N comparison, and long-task splitting, and explain why splitting work across agents still beats one super-agent, even as models get smarter.

This episode is for developers, engineering leaders, and product managers working with AI tools day to day. If you're AI-curious but non-technical, it's a good listen for thinking about how these patterns might apply to your own work eventually.

Substack article link - https://swapniltalekar.substack.com/p/are-managers-really-becoming-better?r=1v4ea

This episode is part of my loop engineering series, and it's about the piece that decides whether a loop actually gets better over time: memory.

I talk about what memory actually is, since it gets confused with two other things constantly: the context window, which disappears the moment a session ends, and a project knowledge file, which stays static across runs. Memory is neither. It's the dynamic record of what a loop decided, what failed, and what's still open.

From there I walk through three memory patterns, starting with the flat text file, through task trackers, to structured stores for when semantic search actually earns its complexity. I cover how to wire memory updates into hooks so they happen automatically, and four specific ways memory setups break in practice. Hope you find it useful.

Show Notes

Full article: Substack link

Related episodes:

• Loop Engineering: Putting agents on Autopilot

• The missing guide for AI Agent Skills – Part I

• The missing guide for AI Agent Skills – Part II

• Coming soon: Parallel agents — worktrees, sub-agents, and Agent Teams

Most skills start useful and quietly get worse. Not because the feature is flawed, but because skills encode assumptions, and assumptions go stale: file paths, command sequences, team conventions, tool names. All of that changes, and the skill keeps looking authoritative while describing a world that no longer exists.

In this episode, part two of the Claude Code skills series, I cover how to write skills that resist that decay and how to manage them once you have more than a handful. I get into why avoiding hardcoded paths and writing the reasoning behind an instruction, not just the instruction itself, makes a skill survive the changes that kill brittle ones. I break down the real token cost of a bloated SKILL.md file, including the exact compaction and description budgets Claude Code enforces, and where the practical ceiling on total skills sits before descriptions start getting silently trimmed. I also cover the difference between team skills and personal ones, the review discipline most teams skip, and the quarterly audit habit that keeps a skill library from decaying into noise.

If you're building any kind of skill library, whether shared with a team or just for yourself, this episode is the maintenance manual for keeping it worth trusting.

Show Notes:

Part 1 of Skills podcast - https://spotifycreators-web.app.link/e/xk601uOfJ4b

Substack post - https://open.substack.com/pub/swapniltalekar/p/a-deep-dive-on-skills-part-2?r=1v4ea&utm_campaign=post-expanded-share&utm_medium=web

Loop engineering is having a moment. Boris Cherny and Peter Steinberger have both said the same thing in public: stop prompting your coding agent turn by turn, and start designing systems that prompt it for you. This episode is the implementation guide.

I walk through the five building blocks a real loop needs: automations and hooks, git worktrees for isolating parallel agents, skills for persistent project knowledge, MCP connectors that let a loop touch your actual tools, and sub-agents that separate the agent doing the work from the agent checking it. Then I walk through a complete example, an unattended loop. I also cover what most posts on this topic skip: how many turns to let a loop run before you step in, what a loop actually costs, and the handful of decisions that should never run unattended.

Show Notes

Substack article: https://swapniltalekar.substack.com/p/loop-engineering?r=1v4ea

Tools and references:

• Addy Osmani's original piece on loop engineering— https://addyosmani.com/blog/loop-engineering

• Peter Steinberger's post — https://x.com/steipete/status/2063697162748260627

• /goal and /loop — Claude Code's two core commands for building loops

• --max-turns — flag to cap how many turns a /goal runs

• Hooks: PreToolUse, PostToolUse, configured in .claude/settings.json

• isolation: "worktree" — flag for spawning a sub-agent in an isolated git worktree

• SKILL.md — project knowledge file; see the Skills series below for the full breakdown

• MCP connectors — GitHub, Linear, Slack, database integrations

• Sub-agents — defined as markdown files in .claude/agents/

Related episodes:

• https://open.spotify.com/episode/4TAYFQGxUaY2xwYky3nBTE?si=uq9iB_USTGCb8tz1B3iCTQ

If you've set up a skill in Claude Code and watched Claude ignore it, this episode is about why that happens.

Skills are one of the most useful features in Claude Code, but the way they actually work is different from what most tutorials suggest. They're not always loaded into context. The triggering mechanism is narrower than it looks. And "always do X" in a skill body is a strong default, not a guarantee.

In this episode, I cover the fundamentals: what a skill actually is, how lazy loading works and why it matters, and how skills fit alongside Claude.md and MCP. Then I get into the part most tutorials skip, which is the triggering problem. Why descriptions fail silently, what kills auto-triggering without any error message, and how to diagnose it. I also cover the difference between soft and hard enforcement, and when you should be reaching for hooks instead of skill instructions.

This is part one of two. Part two covers writing skills that stay useful over time, token efficiency, and what a well-maintained skill library looks like for a team.

If you're building with Claude Code or trying to get more out of it, this one is worth your time.

Full article: https://open.substack.com/pub/swapniltalekar/p/a-deep-dive-on-skills-part-i?r=1v4ea&utm_campaign=post&utm_medium=web

Tools and references mentioned:

• AgentSkills open standard - agentskills.io

• Debug flag for YAML parse errors: claude --debug

• disable-model-invocation: true — frontmatter flag that prevents Claude from auto-triggering a skill

• user-invocable: false — frontmatter flag that hides a skill from the slash menu but allows auto-triggering

• skillOverrides: settings option to change skill visibility without editing SKILL.md

• PreToolUse hooks: hard enforcement that runs before every tool call; exit code 2 blocks the action unconditionally

• disallowed-tools — frontmatter field that removes specific tools from Claude's available pool while a skill is active

• Preprocessing syntax: add !before a backtick-wrapped shell command in SKILL.md to run it before the skill loads