The Task at Hand

Herrington Darkholme built ast-grep to get out of migration work. At his big-tech job the infrastructure changed every few weeks, application code had to follow, and every tool he tried made him walk a syntax tree by hand to find something as small as a console.log. With ast-grep you write a pattern that looks like the code you want to find, and every Taskless rule runs on that engine.

Herrington is the creator of ast-grep and a contributor to tree-sitter. He writes ast-grep in Rust because he didn't trust himself to manage memory by hand in C++ or Zig, and it's a project he builds for fun.

They start with why ast-grep sits on tree-sitter: a community that already maintains a parser for every language, and one uniform node API that works across all of them. From there they compare notes on AI code that's technically correct and practically wrong, the Taskless warning that got Claude to go clean up its own premature abstractions, and what Herrington calls just-in-time prompting.

Herrington also walks through porting tree-sitter's C core to Rust with ChatGPT, which only worked because tree-sitter's test suite already held every bug the project had fixed. He dropped incremental parsing on the way, because agents rewrite whole files at once and a fast full parse matters more to them, and he dropped Wasm grammar loading because Wasmtime runs on fewer platforms than ast-grep ships for.

Plus: why custom languages are opt-in as of ast-grep 0.50.0, checking agent-written YAML rules against ast-grep's JSON schema, how AI rule writing went from a DSPy pipeline whose best step passed 6% of the time to rules Herrington says beat his own, and where AI belongs in creative work.

Herrington's links:

ast-grep ➡️ ast-grep.github.io

ast-grep on GitHub ➡️ github.com/ast-grep/ast-grep

ast-grep's Journey to AI Generated Rules ➡️ ast-grep.github.io/blog/ast-grep-agent.html

Mastering ast-grep (book) ➡️ leanpub.com/ast-grep

tree-sitter ➡️ tree-sitter.github.io

Herrington on GitHub ➡️ github.com/HerringtonDarkholme

Herrington on X ➡️ x.com/hd_nvim

Herrington on Bluesky ➡️ bsky.app/profile/hd-nvim.bsky.social

Herrington on YouTube ➡️ youtube.com/@MikuTeachTech

Herrington on Medium ➡️ medium.com/@hchan_nvim

Taskless links:

Taskless ➡️ taskless.io

Topics covered:

The migration work that started ast-grep

Patterns that look like the code you're searching for

Meta variables and the dollar sign

One rule engine for a polyglot monorepo

Why tree-sitter, and its uniform node API

Syntactic rules vs semantic checks

AI code that's technically correct and practically wrong

A warning written as an instruction for the agent

Just-in-time prompting

Why Rust errors work so well for agents

Porting tree-sitter's C core to Rust with ChatGPT

tree-sitter's test suite as the oracle

Dropping incremental parsing in an agentic world

Error recovery and incremental parsing are different things

Dropping Wasm grammar loading

Adding a language to ast-grep

Why custom languages are now opt-in

Validating agent-written YAML rules against a JSON schema

AI writing ast-grep rules, from 2024 to today

Canonical failing and passing examples

Is AI hype?

AI for the menial parts of creative work

Timestamps:

00:00 Welcome to The Task at Hand

01:28 Why Herrington built ast-grep

04:26 How ast-grep works

06:52 Why tree-sitter

09:26 Syntactic vs semantic rules

11:59 Technically correct, practically wrong

14:50 Just-in-time prompting

16:30 Porting tree-sitter to Rust

20:25 Dropping incremental parsing

23:52 Dropping Wasm grammar loading

26:25 New languages and custom language security

30:44 YAML rules and JSON schema

32:34 Teaching AI to write ast-grep rules

39:21 Is AI hype?

40:39 AI in creative work

43:02 Where to find Herrington

Chris Griffing builds everything live. Five days a week on Twitch, scuffed and all, with chat watching every prompt and every fix. His project, Messijo, was already in flight when agent output got good, so the whole shift happened on camera.

Chris spent 10 years as a snowboard bum before software paid the bills. He came up through the Ember community, led front-end teams for most of his career, and has streamed programming on Twitch since 2018. Today he's a developer advocate at GitKraken and the builder of Messijo, which watches Bluesky, Hacker News and Lobsters for the keywords you care about.

They start with Messijo and why Chris only let models into its codebase a few months ago. When something breaks in a product with an SLA, he needs to know where to look. That leads into taste: a consent form that looked right and only half worked, and why AI output is the newspaper article about a subject you don't know. Front end looks solved to people who don't do front end.

Chris also walks through what running LLMs in production taught him. One provider padded responses with thousands of tokens of whitespace. Putting a JSON instruction in the prompt on top of structured output cut his reasoning tokens. And moving Lenses to Jev took each classification from seconds to milliseconds.

Plus: GitBench and OngoBench, which grade models on the git commands they want to run, an MCP server that strings API calls into tasks, the short version of his Are MCP Servers Dead? talk, and why a human should write anything a human is meant to read.

Sites:

Messijo ➡️ messijo.com

Chris on GitHub ➡️ github.com/cmgriffing

Chris on Bluesky ➡️ bsky.app/profile/cmgriffing.bsky.social

Chris on X ➡️ x.com/cmgriffing

Chris on Twitch ➡️ twitch.tv/cmgriffing

Taskless ➡️ taskless.io

Topics covered:

From snowboard bum to software, by way of GeoCities and MySpace

The Ember years, and a Meteor app still running

Streaming on Mixer and Twitch since 2018

Messijo and Lenses: filtering 3,600 keyword matches down to 14

Building everything live on stream

Why Chris waited to let models into the Messijo codebase

Taste, and the newspaper effect in AI output

Letting AI tune the SQL in small chunks

The rule of three, and the rule of being annoyed three times

Running LLMs in production through OpenRouter

The provider that padded responses with whitespace

Structured output and cutting reasoning tokens

Moving Lenses to Jev: from seconds to milliseconds

DevRel when an agent builds the demo

AI in the video edit

A human wrote the README

Grading models on git with GitBench and OngoBench

Picking the right model for GitKraken's AI features

MCP servers that do tasks

Are MCP servers dead?

Skills, MCP and OAuth

Is AI hype?

What Chris wants to offload onto AI

Timestamps:

00:00 Welcome to The Task at Hand

01:01 From snowboarding to software

03:50 The Ember years

05:53 First streaming attempt at Mixer

07:14 Building a streaming audience

07:49 Messijo and Lenses

09:11 Live coding on Twitch

11:15 Messijo before and after agents got good

13:29 Where models still lack taste

16:01 Letting AI tune the SQL

17:55 The rule of three

19:22 Running LLMs in production

21:49 Structured output and reasoning tokens

23:42 Moving Lenses to Jev

25:02 DevRel when an agent builds the demo

26:43 AI in the video edit

28:20 A human wrote the README

29:31 Grading models with GitBench and OngoBench

33:21 Picking the right model at GitKraken

34:13 MCP servers that do tasks

37:16 Are MCP servers dead?

38:45 Skills, MCP and OAuth

40:15 Is AI hype?

41:12 What Chris wants to offload

43:21 Where to find Chris

Your agent wrote the migration and the diff looks fine. What did it do to the millions of rows it touched, and to every dashboard, finance report and model that reads them downstream? Today's guest has spent years on what correctness means when the thing changing is data, and lately, when the thing making the change is an agent.

CL Kao built SVK, one of the earliest decentralized version control systems, about two years before git. He co-founded g0v, Taiwan's civic tech community, and competed for Taiwan at the International Olympiad in Informatics. Today he's the founder and CEO of Recce, a data review tool for dbt pipelines backed by Heavybit, and the creator of Spacedock, a workflow toolkit for agents with approval gates and review built in.

They start with data review: what a reviewer actually sees, why diffing two versions of your data gets noisy fast, and the blast radius view that shows every downstream column a change touches. Then they get into Spacedock, which came out of a very specific kind of exhaustion: running five agents at once and becoming the human connector between all of them.

CL also walks through lure fixtures, honeypots in Spacedock that catch an agent over-building. His favorite example is an agent that decided to write a whole terminal emulator to test a markdown reader when tmux was sitting right there. He also explains Behavior Diff, a lightweight way to see how a change to a skill or an AGENTS.md shifts what your agent does before you build a full eval suite.

Plus: the agent that refused to rebase, why every IC is a manager now, borrowing sprint planning for agent teams, and the sandbox he runs his own agents in.

Sites:

Recce ➡️ reccehq.com

Spacedock ➡️ spacedock.md

Agent Safehouse ➡️ agent-safehouse.dev

CL on LinkedIn ➡️ linkedin.com/in/clkao

Taskless ➡️ taskless.io

Topics covered:

From competitive programming to SVK, two years before git

What a data review is, and what it catches that code review misses

What a reviewer actually sees: profiles, value diffs and column-level lineage

Migrations versus intended changes, and why the second kind is harder to verify

What breaks when agents touch your data

The customer who told Recce "you don't have to sell me this"

Blast radius: every downstream column a change touches

Custom rules for how much evidence each model needs

Spacedock and the exhaustion of running 10 agents at once

Deciding when a human should get involved

Lure fixtures and the agent that built a terminal emulator

Behavior Diff: seeing how a skill change shifts agent behavior

Sprints for agent teams, without the capacity cap

Two times AI surprised him, and sandboxing with Agent Safehouse

Timestamps:

00:00 Welcome to The Task at Hand

00:32 CL's background: SVK to data

03:34 What is data review?

07:20 What reviewers actually see

08:56 When AI touches data

11:02 What breaks with agents

12:11 Recce customer stories

14:07 Blast radius visualization

16:32 Custom rules and risk

18:11 Spacedock: agent workflows

20:22 Agent exhaustion and context

25:35 Managing your attention

29:06 Spacedock at Recce

30:50 Lure fixtures and over-engineering

37:27 Productionizing agent ideas

40:30 AI surprises and sandboxing

Your agent shipped the feature. Do you know what it actually did to get there? Session logs are partial. Sub-agents were black boxes until pretty recently. Claude Code keeps your sessions on your machine for 30 days and then deletes them, and most of us never think about it. Today's guest thinks the trail your agents leave behind is the most undervalued asset in your engineering org, and that you find it on the wire.

Brian Douglas was GitHub's first developer advocate and later led its developer advocacy org. He was the third engineer at Netlify, and he founded OpenSauced, the open source contributor analytics project that's now part of the Linux Foundation. These days he's co-founder of Paper Compute with his CTO John McBride, building open source infrastructure for agents running in production. Tapes records everything an agent does at the network level with zero instrumentation. stereOS is a hardened Linux OS that sandboxes agents and keeps them from wandering off. Tapes started as a weekend project answering a much smaller question: what does the same Ralph Loop cost on Haiku versus Opus?

They cover a lot of ground: how we got from Codespaces to Claude doing the job your shell used to do, what the network boundary catches that never makes it into a session log, how sub-agents went from black boxes to something you can tab into, why MCP got over-implemented before the spec settled down, the three problems Brian says production agents actually have (isolation, observability, memory), how an agent will hallucinate a customer list and then quietly treat it as history, and why trust gets lost in buckets and earned back in drops.

Brian also gets into what he's calling dreams. Take a captured session, fork it at a specific point, re-run it against a different model at a different reasoning effort. Sandboxes are cheap enough now that spinning up sixty variations is a reasonable Saturday. You come out with an actual benchmark: this model, this effort, this reasoning setting, go.

Plus: why tapes was almost called Stenographer, the intranet-for-agents idea sitting underneath it, dropping into a coworker's session before you go bother them in Slack, and why test-driven development turned out to be the thing quietly saving the vibe coders in Brian's life.

Sites:

Brian's company ➡️ papercompute.com

The open source project ➡️ tapes.dev

Everything else Brian ➡️ b.dougie.dev

Taskless ➡️ taskless.io

Topics covered:

How dev environments got from in-browser editors to agents in the cloud

Tapes: agent telemetry at the network layer with zero instrumentation

What session logs miss, including tool calls, skill usage, and sub-agent decisions

Sub-agents as black boxes, and why the wire sees through them

MCP bloat, and the retreat to plugins and connectors

Isolation, observability, and memory as the three hard problems

Mining dead sessions for roadmap, docs, and skills

Trust, data sharing, and how fast goodwill evaporates

When agents hallucinate a roadmap and then believe it

Enforcement and knowledge: where Taskless and Tapes meet

Single player to multiplayer, and an intranet for agents

Dreams: forking and replaying sessions across models and effort levels

What stays durable once the hype burns off

Timestamps:

00:00 Welcome to The Task at Hand

01:22 How dev environments evolved

04:09 Origins of Tapes

08:14 Network as source of truth

09:59 Sub-agents and black boxes

12:29 MCP evolution and bloat

14:59 Three hard problems for agents

17:30 Mining session data for memory

19:59 Trust, security, and data sharing

22:00 When agents hallucinate

27:59 Single player to multiplayer agents

29:59 Durable sessions and dreaming

32:59 Testing models in parallel

36:59 Hype vs durable reality

39:59 Beyond coding and TDD

Craig Campbell (Pastmaps) on Building the Google Maps of History | The Task at Hand Ep. 4

What if you could slide back in time and see exactly what used to be where you're standing? That's the magic behind Pastmaps — and in this episode, Jakob Heuser sits down with Craig Campbell, the solo founder behind it. Craig started the project as a hobby tool for his metal detecting obsession, posted about it on Reddit, and watched the response make it clear this was something much bigger. From navigating 459,000+ historical maps and public domain licensing to building a client-side tiling engine that GIS experts told him was crazy, Craig shares an unfiltered look at what it really takes to build something people love — metrics reviews, AI agents, barbecues with retired USGS directors, and all.

________________________________________

0:00 – Intro & Welcome

1:00 – What is Pastmaps?

4:53 – From Embarrassment to Passion

7:13 – The Reddit Aha Moment

14:09 – Building the MVP

16:06 – Sourcing Maps at Scale

17:59 – The USGS Barbecue Story

22:07 – Tech Deep Dive: No Tiling

26:45 – LiDAR on the Client Side

36:29 – AI as Your Engineering Team

38:25 – The Dev Tooling Gap

44:22 – Learning & Building in Public

50:02 – The Facebook Metric Culture

51:11 – Public Metrics Reviews

1:02:42 – Where to Find Craig

Links & Resources:

Pastmaps: https://pastmaps.com

Craig on Threads: https://threads.net/@that.map.guy.craig

________________________________________

Taskless - Tell your AI Once. https://www.taskless.io

Interview with Greg Pstrucha on Practical AI - Episode 3

===============

🔗 Links

===============

Taskless - tell AI Once https://www.taskless.io

Greg Pstrucha - https://gricha.dev/

Dangerous Skills - https://github.com/gricha/dangerous-skills

dotagents - https://github.com/getsentry/dotagents

===============

⏭️ Markers

===============

00:00 Introduction

00:37 Greg's Background

04:58 The AI Aha Moment

05:57 AI's Impact on Coding

07:18 Introducing Sentry Seer

09:39 Building Agents on Live Production Data

14:30 Dangerous Skills: Attack Vectors Explained

15:21 PNG Exif & Shebang Exploits

18:10 Introducing dotagents

21:37 Security Features in dotagents

29:50 Supply Chain Attacks in NPM Ecosystems

31:08 The Future of Agent Security

33:22 The AI Bubble & Productivity Loops

38:46 Guardrails for AI Code Quality

46:14 Greg's Projects & Wrap-Up

Context is the missing primitive in the AI stack. Most teams are underestimating it. In this episode, Jakob sits down with JP, founder of Wire, to explore why context engineering is the foundational layer that makes agents actually work.

JP has spent over a decade in product and growth at companies like Upwork and Cook Unity. His builder instincts go back further, to the early internet days when he taught himself to code to avoid cold calling. Now he's applying that same DIY energy to one of the most important unsolved problems in AI: where does an agent's knowledge live, and how does it stay accurate over time?

They cover a lot of ground: why copy-pasting context into every chat is a workflow smell, why GitHub is a great context store for engineers but nothing like it exists for everyone else, how MCP is quietly becoming the enforcement layer for agent permissions, and why the single-vendor AI future probably won't happen.

JP also introduces Wire's epistemic graph. It tracks how knowledge evolves: what contradicts what, and what's been superseded. That's a fundamentally different approach to memory than what the frontier model providers are building.

Plus: JP's actual daily stack (no VS Code), how he assigns tech debt tickets to Claude overnight, and his one-sentence takeaway that might end up on a shirt.

Sites:

JP's project ➡️ usewire.io

Topics covered:

- Why context engineering is undervalued

- Wire: composable context containers for AI agents

- GitHub as a context store, and why nothing like it exists outside engineering

- MCP as an enforcement and permission layer

- Single-vendor risk in the AI stack

- The epistemic graph: tracking the evolution of knowledge

- Will Claude just absorb the context layer?

- Building without an IDE

- Async AI work: assigning tickets overnight

Timestamps:

00:00 Introduction

01:12 JP's Background: Builder from the Start

02:39 Early Website & First Sale

03:16 Career Path: Startups, PM Work & AI

06:58 The Friction People Feel with AI Tools

08:37 Treat AI Like a New Hire

09:33 What Wire Does: Persistent Context for Agents

10:19 GitHub for Engineers — But Nothing Else

13:39 Wire vs. Knowledge Management Tools

20:09 MCP, Taskless & the Context-Execution Stack

21:03 Single-Vendor Risk & the Multi-Model Future

24:38 Will Claude Just Absorb This?

29:59 Wire's Epistemic Graph: Tracking Knowledge Over Time

36:33 JP's Daily Stack (No VS Code)

38:57 Tech Debt as a Linear Ticket

40:53 One Sentence Takeaway

Taskless’s Pivot: Deterministic Rules to Wrangle AI Code Slop

Jakob interviews Vy Nguyen, CEO and co-founder of Taskless, about her operations and manufacturing background, her interest in the people problems of technology adoption, and Taskless’s pivot from a telemetry product after learning customers wouldn’t pay for it. Through interviews with several hundred developers, especially senior engineers, they identified the acute pain of being overwhelmed by AI-generated pull requests and repetitive code-review feedback, with existing AI review tools failing to enforce team-specific “shop style” and institutional knowledge.

Vy argues probabilistic models can be technically correct yet violate intent, so Taskless focuses on deterministic, enforceable rules to guarantee consistency and reduce repeated issues, aiming to rebuild trust in AI-assisted development. They also discuss AI hype versus durable value, challenges of business transformation and trust in legacy industries (including a John Deere subscription example), and the lesson to prioritize customer development before building.

00:00 Vy Nguyen on Founding Taskless - Episode 1

00:01 Introduction

01:41 Building Taskless

05:58 Too Much Code to Review

09:47 The State of Tools for AIs

12:22 Is it a Bubble?

14:23 Taskless' Future

20:24 Trust in AI Systems

22:20 Why Markdown Wasn't Good Enough

26:01 Taskless' Core Thesis

28:46 Advice For Your New-Founder Self

30:39 Outro

Taskless: https://www.taskless.io