Engineering on houdeshell.dev

Software that I

Mon, 01 Jun 2026 00:00:00 +0000

I bounce between Mac, Windows, and Linux daily. Honestly, the tools matter more than the OS at this point. Great software is great software, and I’ve been lucky enough to build a career on top of things other people built well.

This is the stuff I actually reach for. Not a “best of” list, not sponsored, not comprehensive. Just software that makes me better at what I do. Or at least makes the work more fun.

Software Development #

IDE

JetBrains Rider #

Cross-platform .NET IDE. Fast, smart, and doesn’t need Visual Studio’s weight to get the job done.

IDE

Visual Studio #

The OG. Heavy, but when you need the full .NET debugging experience, nothing else comes close.

editor

VS Code #

Extension ecosystem is unmatched. Somehow Electron done right.

editor

Neovim #

Vim reborn. Lua config, LSP native, and a plugin ecosystem that won’t quit. :wq is a lifestyle.

version control

Git #

The version control system that won. Love it or hate it, you can’t ship without it.

version control

lazygit #

Terminal UI for git that makes interactive rebases feel like cheating.

JSON

jq #

sed for JSON. Once you learn the syntax, you’ll pipe everything through it.

database

JetBrains DataGrip #

SQL IDE that actually understands your schema. Autocomplete that works across joins.

database

DBeaver #

Universal database tool that actually works. Connect to anything, query everything.

database

SSMS #

Microsoft SQL Management Studio. If you’re in SQL Server land, you already know.

database

PostgreSQL #

The database that keeps getting better. Extensions, JSON support, and rock-solid reliability.

containers

Docker #

“Works on my machine” became “works on every machine.” Changed how we ship software.

AI #

agent

Claude Code #

AI pair programmer in your terminal. It’s writing this page right now.

agent

VS Code Agents #

Native agent mode inside the editor. Let the assistant plan, edit files, and run commands without leaving VS Code or babysitting a separate CLI.

agent

Codex #

OpenAI’s open-source coding agent. Terminal-native, sandboxed by default, and you can swap the model behind it whenever.

platform

Azure AI Foundry #

Microsoft’s AI app stack. Build agents, point them at your data, ship them on Azure. The enterprise wrapper for everything you’d otherwise glue together yourself.

Infrastructure #

orchestration

Kubernetes #

Container orchestration that makes you mass produce YAML for a living.

orchestration

K3s #

All of Kubernetes in a single binary. Perfect for homelab, edge, and production deployments.

IaC

Terraform / OpenTofu #

Infrastructure as code. OpenTofu if you prefer the open-source fork without the license drama.

networking

Tailscale #

WireGuard-based mesh VPN that just works. Connect everything without opening a single port.

observability

Grafana #

Dashboards for everything. Pairs with Prometheus, Loki, and Tempo for the whole observability stack.

Kubernetes

k9s #

Terminal UI for Kubernetes. Makes cluster management feel like a video game. Way faster than raw kubectl.

Kubernetes

Lens #

The Kubernetes IDE. When you want to point and click your way through a cluster without shame.

it's complicated

Cloudflare #

You love them. You hate them. Your DNS is already there. Their edge network is everywhere, their pricing is unbeatable, and their product sprawl is terrifying. Stockholm syndrome as a service.

Shell & Terminal #

shell

Bash #

The shell that’s been there since before you were born. Simple, portable, everywhere.

shell

Zsh #

Bash’s cooler sibling. Tab completion, globbing, and plugin support that actually makes the terminal enjoyable.

prompt

Starship #

Cross-shell prompt written in Rust. Fast, pretty, and infinitely configurable.

multiplexer

tmux #

Terminal multiplexer. SSH into a box, detach, come back tomorrow. Your session is still there.

coreutils

eza #

Modern replacement for ls. Colors, git status, and tree view out of the box. Written in Rust, obviously.

Utilities / Apps #

macOS

AltTab #

Why does macOS think a minimized window is an inactive window and not let you switch to it? This fixes that.

About

Sat, 11 Apr 2026 00:00:00 +0000

// bit herder. pointer wrecker. yaml apologist.

I’m a bit herder, a pointer wrecker, and HTTP is my best friend. 0xA3 & 0x7C are also my friends, but not 0x08.

I spend my days somewhere between writing code and making sure other people can write better code. I love distributed systems, low-level embedded devices, and anything that has a content-type. I also have an unhealthy relationship with YAML, but that’s a Kubernetes problem.

The day job #

During the day, I lead engineering and operations at EnergyCAP, a SaaS platform that helps organizations track utility spend, energy consumption, and sustainability goals across massive building portfolios. We’re talking $100B+ in utility bill spend tracked across 350,000+ sites. Government, education, healthcare, commercial real estate. If it has a meter, we probably manage it.

I started here as a developer in 2009 and have been building ever since: through senior roles, into leadership, and eventually into the VP seat where I get to shape both the tech and the teams behind it. Some days that means architecture decisions. Most days it means removing blockers so smart people can do their best work. And yes, sometimes it’s just meetings about meetings.

My philosophy is simple: technology should serve people. Build teams where people feel safe to be wrong, give them the tools to be great, and get out of the way.

Things I geek out about #

Distributed systems, container orchestration, database performance tuning, developer tooling, process dumps, leadership that doesn’t suck, making engineers’ lives better, and the eternal quest for a perfect terminal setup.

I also talk at things #

I like getting on stage and nerding out about the things I’ve learned the hard way. My talks tend to fall into a few buckets, and yes, I have strong opinions about all of them.

AI & the developer experience #

The AI wave hit and I leaned in. I’ve talked about using LLMs as debugging partners, building RAG pipelines that actually know your business context, and the ethical lines we should be drawing as we hand more work to machines.

My Rubber Duck is a Large Language Model
Unleashing the Power of the AI Wizards: Retrieval-Augmented Generation Spells

Kubernetes & cloud native #

I was late to the Kubernetes party, and I’ll tell you all about it. From lightweight K3s workshops to navigating the 900+ services in the CNCF landscape, to making the case that cloud-native principles work even when you’re not in the cloud.

Kubernetes Chronicles: Late to the Party, Big on Adventure!
K3s: Half the Size, Twice as Awesome (workshop)
Orchestrating Machine Learning Workloads with Kubernetes
Exploring the Cloud Native Landscape
Cloud Native is Only for the Cloud, Right?
Nomad: Orchestration Doesn't Start with a K

Performance & databases #

I’ve spent an unreasonable amount of time staring at query plans. These talks cover squeezing performance out of SQL Server, using DMVs like cheat codes, and that one time we took a 10-hour process down to 10 minutes.

ReArchitecting Data: 10 Hours to 10 Minutes
Mastering SQL Server Performance Optimization (workshop)
SQL Server DMVs That Give Me Superpowers
Achieving Continuous High Performance with Query Store
Practical High Performance: C# Edition
Intrinsics in .NET: Start Somewhere

Production war stories & leadership #

Production breaks. Systems fail. The interesting part is what you do next. I also talk about the human side: what I’ve learned (and gotten wrong) leading engineering teams.

Bug Squashing with Process Dumps
Recovery by Design: A Postmortem Adventure
Joining the Cloud: Our Journey
TIL as a CTO

The wildcard #

Sometimes you just want to build something fun with your hands.

Paper Circuits: Origami for a New Generation

Let’s talk #

I drink a bit too much coffee while rambling on about technology. If you’re willing to have a conversation, I’m ready to buy you a cup.

email: chris@houdeshell.dev
github: choudeshell
linkedin: choudeshell
bluesky: @choudeshell.bsky.social

Now

Mon, 01 Jun 2026 00:00:00 +0000

Focus #

AI at /\$DAYJOB/. Production agents on real customer data. Compliance edges, evals, on-call playbooks.
Upgrading Azure infrastructure. Modernizing the stack we run customer workloads on.

Thinking #

AI. Where it pays off and where it just adds latency.
Team. Shape, growth, what each person’s pulling toward.
The price of the cloud. Watching cluster spend while AI workloads scale up unpredictably.

Reading #

TODO — drop in current books, longreads, or RSS finds here. The shelf changes monthly.

You're the Typist

Wed, 27 May 2026 10:00:00 -0400

There’s a question I ask engineers when they hand me an AI generated PR: “walk me through what this does.”

If they can, the PR is usually fine. If they can’t, the PR is almost always broken. Not visibly broken. Not the kind of broken that fails a test. The kind of broken that ships, sits in production for six months, and then takes down a service at 2am because nobody knew the cache invalidation only ran on the leader.

AI doesn’t fix that. AI makes it worse.

AI is a multiplier. It multiplies whatever you bring to it. If you understand the problem, AI gets you to a working solution faster than any tool we’ve ever had. If you don’t, it gets you to something that looks like a working solution faster than any tool we’ve ever had. Those are very different things, and the difference doesn’t show up until later.

The engineers I see thriving with AI right now read every line. They push back when the model takes a shortcut they don’t like. They ask “why” three times. They notice when the generated code uses a pattern they’ve never seen, and they stop to learn it before they accept it. AI doubles their throughput because they were already good. It also doubles their learning rate, because every prompt is a chance to see how an experienced engineer (which is what the model is impersonating) would have approached the same problem.

The engineers I see drowning treat the model like an oracle. They accept the diff. They run the tests. The tests pass, so they ship. They have no mental model of what they just merged. Six months in, they’ve shipped a hundred PRs and learned nothing. The codebase has grown faster than their understanding of it, and the gap is widening.

Here’s the test I’d give anyone using AI heavily. Pick a PR from last week. Open it without the model. Explain every block out loud. Why this data structure? Why this error path? What happens if this call times out? What does this loop do on the empty case? If you can’t answer those questions about your own merged code, AI isn’t helping you. It’s helping the model, and you’re the typist.

This isn’t just an engineering problem. Engineering managers and product managers fall into the same trap, one rung up. If you used AI to write a JIRA ticket and you can’t explain it five minutes later, your problem is different than you think. The ticket isn’t the artifact. The thinking behind the ticket is. If the model did the thinking and you hit save, you’ve handed your team a task that nobody on your side actually owns. The first time an engineer pushes back with a real question, the whole thing falls apart, and the engineer figures out fast that there’s no one home behind the requirements.

Use AI. Lean into it. Just don’t outsource the part of the job that was ever actually yours.

KQL Reads Like a Sentence

Sat, 23 May 2026 10:00:00 -0400

Watch a smart, curious person try to learn SQL. They get through SELECT * FROM x WHERE y and they’re fine. Then they hit JOIN, or GROUP BY, or a correlated subquery, and the floor opens up. Most never come back.

KQL is the opposite. It reads left to right, the way the human brain wants to think about data.

kustoPageViews
| where TimeGenerated > ago(7d)
| where ClientCountryOrRegion == "United States"
| summarize count() by bin(TimeGenerated, 1d), Page
| top 10 by count_

Read it out loud. “Take page views, where time is in the last seven days, where the country is the US, summarize by day and page, give me the top ten.” That sentence is the query. Nothing is hidden, nothing is out of order.

The verbs are English. where. summarize. project. extend. take. top. There’s no CROSS APPLY lurking three chapters in.

You can do useful work on day one without ever learning a join. That matters more than engineers remember. Every join is a cliff for a non-engineer, and SQL puts that cliff in front of trivial questions. KQL puts the cliff somewhere on chapter five.

Add to that:

Sane defaults — take 100 to peek, results are always tabular
Time-series operators baked in — ago, bin, series_decompose
Autocomplete that actually understands your schema
A query pane that gives you instant feedback the moment you stop typing

KQL isn’t the right tool for everything. I’d never reach for it to build a transactional system. But for letting smart, curious people answer their own questions about their own data, I haven’t seen anything better.

Take all that with a grain of salt — I wrote a KQL-to-SQL parser and generator, so I’m clearly not sure what any of this means.

Inverse AI Consulting

Fri, 15 May 2026 15:00:00 -0400

Mitchell Hashimoto wrote a post on X that I haven’t stopped thinking about.

It’s frightening, because the psychosis folks operate under an almost absolute “MTTR is all you need” mentality: “its fine to ship bugs because the agents will fix them so quickly and at a scale humans can’t do!” We learned in infrastructure that MTTR is great but you can’t yeet resilient systems entirely.

I love AI. I lean into it harder than most people I work with and know. Engineering is genuinely better because of AI. Daily and categorically.

Purely AI written systems will scale to a point of complexity no human can ever understand. For a while it looks fine. Defects close, bug reports trend down, dashboards stay green. Then the defect close rate tapers. Token burn per defect climbs. Eventually, AI changes cause on average more defects than they close, and the whole system becomes unstable. The decay.

AI amplifies good thinking. AI amplifies good engineering. AI also amplifies bad thinking and bad engineering.

When that happens, I expect a new type of consulting to emerge. Call it Inverse AI. An involution. The same specialists who get called for an active breach, or when production data is gone and the backups failed. People who walk into a doomed AI generated codebase, distill out the core design principles nobody bothered to write down, and rebuild from scratch with good thinking and good engineering – using AI.

This time with with humans in the seat where it counts.

The decay isn’t a reason to be against AI. It’s a reason to be honest about what comes next.

How I Run 1:1s

Tue, 05 May 2026 09:00:00 -0400

I’ve been running 1:1s for years and I still get them wrong. The version of “wrong” has changed. Early on, my 1:1s were status meetings with the lights off. Manager asks what you’re working on. Engineer recites their pile. Manager says “anything blocking you?”. Engineer says no, even when they mean yes. Forty-five minutes evaporate.

That isn’t a 1:1. It’s a standup with a longer time slot.

I figured out it was wrong because of one engineer. Smart, quiet, on a team I’d inherited. We’d had eight or nine “great” 1:1s in a row. He left to go work somewhere else and on his way out told me, in different words, that he didn’t think I knew anything about him. He was right. I knew what he was working on, what his blockers were, what he’d shipped that quarter. I didn’t know what he wanted out of his career, what he was sick of, what his last manager had broken in him that I was busy perpetuating. Everything I knew about him was project-shaped.

That cost me an engineer, and it cost me about three months of figuring out how to run these meetings differently.

The frame #

This is your meeting. You set the agenda. If you want to talk through a tricky design problem, talk it through. If you want to vent about a teammate, vent. If you want to plan the next two years of your career, plan. If you want to talk about your kid’s soccer team, fine. I have a notes doc I never make you open.

I do bring things. Three or four every week. Coaching I want to give, feedback I owe, context you’d want, a decision I want your read on. Mine goes after yours. If we run out of time and I never got to my list, that’s okay. My list keeps. Yours might not.

One question that does most of the work #

I used to have a list. Three questions, same every week, the kind of thing that lands in a leadership newsletter. They worked, mostly. They also made me predictable, which made the answers predictable.

Now I mostly ask one thing and let it breathe:

“What’s draining you right now?”

The honest answer is rarely the project. It’s a person, a process, or something they don’t want to admit they’re avoiding. Half the time the first answer is “nothing, I’m good,” and then five minutes later something real comes out because the question planted a seed. Naming the drain doesn’t fix it. It just lets us start.

If they bring me energy instead, fine. I roll with it. The point of the question is to give them permission to say something they probably haven’t said out loud yet.

What I stopped doing #

I’d love to write you a clean bullet list of antipatterns. The truth is messier, and most of them are mistakes I made before I learned to stop.

I used to ask for a status update at the top of every 1:1. I told myself I was “checking in.” I was filling silence. Now if I’m asking what they shipped, it’s because I genuinely don’t know, which means I’m not paying attention to the team. JIRA exists. Standups exist. The 1:1 isn’t where that goes.

I used to ambush. The “by the way, we’re concerned about your output” drop, slipped into a 1:1 because I didn’t have the spine to schedule it as its own meeting. Every time I did it, I blew up trust for a quarter. Performance feedback gets its own slot, its own framing, its own heads-up. Not a sneak attack between “how was your weekend” and “what’s on your mind?”.

I used to solve for them. They’d bring me a problem and I’d hand them the answer thirty seconds later because it felt helpful and made me feel useful. It made them dependent. “What would you do?” is the better question, even when I already know what I’d do. Especially then.

Cadence #

Weekly, 30 minutes, on the calendar. Not “ad-hoc when we both have time.” Ad-hoc never happens. Ad-hoc is what people say when they don’t actually want the meeting.

I cancel mine more than I’d like. Sprint demo collides, customer call drops in, an outage at 2am. I always reschedule. I never delete. The person sees that a 1:1 with me is a slot that survives the rest of the calendar. That matters more than they’ll ever tell me.

Skip one, fine. Skip two in a row, that’s a signal you’re sending whether you mean to or not. Skip three and you’ve made the problem for yourself.

The unsexy part #

Nobody puts this on a leadership thread because it doesn’t tweet well. The actual work of 1:1s is being there, in this meeting, every week, for years. Not the clever question. Not the great coaching moment that lives rent-free in their head five years later, though those happen and you’ll remember them. The week-after-week of showing up, paying attention, and remembering the things they told you last month so you can ask about them this month.

Most of it is just that. Show up. Pay attention. Remember.

The engineer who left taught me one more thing on his way out, without meaning to. He’d told me about his daughter’s blights in passing about six weeks earlier, and I never asked about it again. Not because I didn’t care. Because I forgot, and he noticed.

I write things down now.

Flue, Part 3: Self-Hosting Agents with Knative

Sat, 02 May 2026 18:00:00 -0400

Part 1 was the framework pitch. Part 2 was the agent I wanted to build. This one is for the people who can’t (or won’t) ship that agent to Cloudflare Workers.

The reasons vary. Compliance says all customer data stays in our VPC. Security says no third-party serverless on the data path. Procurement won’t sign another vendor contract this fiscal year. We already run Kubernetes for everything else, so why are we paying someone to schedule containers for us? All valid.

Self-hosting a Flue agent on Kubernetes is straightforward. The trick is doing it without rebuilding the things managed serverless gives you for free: HTTP routing, autoscaling, scale-to-zero, ingress, TLS. That’s where Knative earns its keep.

Why Knative #

Knative is the K8s-native answer to serverless. You hand it a container image and a port. It hands you back a public URL, request-based autoscaling, scale-to-zero when nothing is calling, and TLS through cert-manager. The whole “deploy a webhook handler” thing collapses into a single Kubernetes resource.

For a Flue agent specifically:

The agent boots in a few hundred milliseconds. Cold start is fine.
Webhook traffic is bursty. Scale-to-zero saves real money.
Inbound traffic is HTTP only. No need for a service mesh.

OpenFAAS works too. So does spinning up a Deployment plus Service plus Ingress plus HPA by hand. I keep coming back to Knative because the Service resource is one file and the operational story (events, observability, autoscaling) is built in.

The Dockerfile #

Flue ships as a Node CLI plus a function bundle. For deployment, build a small image with the function code and the SDK’s HTTP server in front:

dockerfileFROM node:22-alpine AS deps
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci --omit=dev

FROM node:22-alpine
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY agent.ts jira.ts ./
COPY skills ./skills
ENV NODE_ENV=production
EXPOSE 8080
CMD ["npx", "flue", "serve", "--host", "0.0.0.0", "--port", "8080", "agent.ts"]

Two-stage build to keep the runtime image small. The skills directory comes along since the agent reads context files at runtime. flue serve is the SDK’s HTTP entrypoint that turns export default into a webhook handler at /.

If you’re running a Bun-flavored Flue agent, swap the base image for oven/bun:1-alpine and the CMD for bun run agent.ts. Same shape, fewer layers.

Push to whatever registry you’re using:

bashdocker build -t registry.internal/agents/jira-triage:0.1.0 .
docker push registry.internal/agents/jira-triage:0.1.0

The Knative Service #

The Service resource is the whole thing.

yamlapiVersion: serving.knative.dev/v1
kind: Service
metadata:
 name: jira-triage
 namespace: agents
spec:
 template:
 metadata:
 annotations:
 autoscaling.knative.dev/min-scale: "0"
 autoscaling.knative.dev/max-scale: "10"
 autoscaling.knative.dev/target: "5"
 spec:
 timeoutSeconds: 90
 containerConcurrency: 1
 containers:
 - image: registry.internal/agents/jira-triage:0.1.0
 ports:
 - containerPort: 8080
 envFrom:
 - secretRef:
 name: jira-triage-secrets
 resources:
 requests:
 cpu: 100m
 memory: 256Mi
 limits:
 cpu: 1000m
 memory: 1Gi

The annotations are doing real work:

min-scale: 0 lets the agent drop to zero replicas when nothing is calling it. That is the entire point of running this on Knative instead of a plain Deployment.
max-scale: 10 caps blast radius. If a JIRA automation rule misfires and floods the webhook, it won’t take down the cluster.
target: 5 plus containerConcurrency: 1 tell Knative each pod handles one in-flight request at a time, and to scale up once five concurrent requests are queued.

timeoutSeconds: 90 is the upper bound for a single request. Most agent runs finish in 10 to 30 seconds. Ninety gives a comfortable cushion for the slow case where the model is grinding through a long classification context. If you regularly need longer than that, you’ve left “webhook handler” territory and want a workflow runner like Argo or a queue.

containerConcurrency: 1 is the safe default. Flue agents tend to hold an open session and a model connection per request. Sharing one Node process across multiple in-flight model calls works, but the concurrency math gets complicated and you trade simplicity for a small CPU win. Start at 1, tune later if cost matters.

Secrets #

Secrets stay out of the Service manifest. Drop them in a Secret and envFrom them in:

yamlapiVersion: v1
kind: Secret
metadata:
 name: jira-triage-secrets
 namespace: agents
type: Opaque
stringData:
 ANTHROPIC_API_KEY: "sk-ant-..."
 JIRA_HOST: "yourorg.atlassian.net"
 JIRA_EMAIL: "triage-bot@yourorg.com"
 JIRA_TOKEN: "..."

If you’re running External Secrets Operator or Vault Secrets Operator, point at the upstream store instead of stuffing keys into a YAML you’ll commit by accident. The Flue agent doesn’t care where the env vars come from. It just reads them.

The webhook URL #

Knative gives the Service a public URL on whatever domain your cluster operator has configured. You’ll see it in kubectl get ksvc -n agents:

bashkubectl get ksvc jira-triage -n agents

NAME URL READY
jira-triage https://jira-triage.agents.example.internal True

Point your JIRA automation rule at that URL with whatever auth you want on it. Knative supports request authentication through the standard ingress controllers, so if you want HMAC verification, JWT, or a static bearer token, the Service is just an HTTP server and you wire it in upstream.

For HMAC (JIRA can sign webhooks), I add a small middleware layer in the Flue handler itself rather than at the ingress. That way the Service stays portable and the auth lives next to the agent code.

Scaling, the operator’s view #

Knative does its own pod scaling, but the autoscaler still has to live somewhere. The defaults are reasonable, and if your team is already running KPA (the Knative Pod Autoscaler), you don’t need to do anything. If you’d rather use HPA, swap the annotation:

yamlautoscaling.knative.dev/class: "hpa.autoscaling.knative.dev"

KPA reacts faster to bursts (sub-second). HPA is steadier and integrates with your existing custom metrics pipeline. For agent workloads I’d default to KPA: bursts of webhook traffic show up first as concurrency, which KPA scales on natively.

What you give up #

Cold starts. The first request after a quiet period will pay 1 to 3 seconds for the Node process to come up. That’s fine for JIRA webhooks. It would be painful for a chatbot facing humans. If you can’t tolerate cold starts, set min-scale: 1 and pay for one always-warm pod.

Operational ownership. Cloudflare hands you “the function ran, here’s the log, here’s the trace.” With Knative you own the autoscaler tuning, the ingress, the cert rotation, the registry, and the K8s upgrade cycle. If your team already runs that, the marginal cost is small. If not, you might be reaching for the wrong tool.

Egress quotas. Knative defaults to no egress filtering. If you’re in a regulated environment, you’ll want NetworkPolicies in front of the agent’s namespace so it can only reach the model API and your JIRA host. The default is “open egress,” which is probably fine for the prototype and definitely not fine for prod.

Observability #

The agent already returns structured JSON for each invocation (the action it took, the reasoning summary, the issue key). On Knative, every request shows up in kubectl logs and the queue-proxy sidecar exposes Prometheus metrics:

revision_request_count per Service revision
request_latency histogram
concurrent_requests gauge

Pair that with a ServiceMonitor and you get a dashboard for free. Add a structured logger inside the agent (pino, console.log of structured objects, whatever your cluster’s log pipeline can parse) and you’ve got correlated logs and metrics without any custom infra.

For traces: enable Knative’s OpenTelemetry support, or bolt on the OpenTelemetry SDK inside the Flue handler. Whichever your tracing stack already prefers.

When this is the right tool #

Self-host the Flue agent on Knative when:

Your data plane has to stay in your VPC.
You already run Kubernetes and have an SRE team that knows it.
You have multiple agents and want a uniform deployment story across them all.
Webhook traffic is bursty enough that “always running on a VM” is overkill, but consistent enough that you’d rather not pay per-request to a third party.

Reach for managed serverless when:

You don’t have a K8s team, or you have one and they’re already at capacity.
You want one less thing to babysit.
The data is fine to leave the building.

Both shapes work. Both are real. The Flue agent code doesn’t change between them, which is the part I keep finding satisfying: you can develop on Workers, prove the agent out in the small, and self-host the same code in your cluster the day someone in security says “no, that data stays put.”

Flue, Part 2: Stop Triaging JIRA By Hand

Sat, 02 May 2026 15:00:00 -0400

Part 1 was the framework pitch. This is the agent I actually wanted to build with it.

The setup is something I keep seeing across teams: JIRA triage is brutal. Tickets pile up in the new-issues queue. An EM or tech lead spends an hour every morning sorting them. Someone classifies, someone re-classifies, someone routes, someone re-routes. Half of them get assigned to the wrong team and bounce around for two days before landing.

The agent I’m going to walk through does that triage work. It reads each new ticket, classifies it, picks a team and a person, and either assigns it or comments on the ticket asking for human eyes. It never guesses. If it isn’t confident, the human gets a structured handoff instead of a wrong assignee.

The plan #

Two skills:

classify-ticket: reads the ticket and picks a category, domain, and priority. Self-reports confidence.
route-ticket: given that classification, picks a team and a specific assignee. Also self-reports confidence.

Then a tiny piece of glue:

If both skills come back high-confidence, assign + label, log, done.
Otherwise, comment on the ticket with the agent’s reasoning, label needs-triage, leave the assignee blank.

The whole thing runs on a JIRA webhook. New issue created? Webhook fires, Flue runs, two API calls back to JIRA, response sent. Total wall-clock time: a few seconds.

The agent #

typescriptimport type { FlueContext } from '@flue/sdk/client';
import * as v from 'valibot';
import * as jira from './jira';

export const triggers = { webhook: true };

const Confidence = v.picklist(['high', 'medium', 'low']);

const Classification = v.object({
 category: v.picklist([
 'bug',
 'feature-request',
 'support',
 'security',
 'infra',
 'docs',
 'duplicate',
 'spam',
 ]),
 domain: v.picklist([
 'frontend',
 'backend',
 'database',
 'auth',
 'billing',
 'reporting',
 'kubernetes',
 'unknown',
 ]),
 priority: v.picklist(['low', 'medium', 'high', 'critical']),
 reasoning: v.string(),
 confidence: Confidence,
});

const Routing = v.object({
 team: v.string(),
 assignee: v.union([v.string(), v.null()]),
 reasoning: v.string(),
 confidence: Confidence,
});

export default async function ({ init, payload, env }: FlueContext) {
 const { issue } = payload;

 const agent = await init({ model: 'anthropic/claude-opus-4-7' });
 const session = await agent.session();

 const classification = await session.skill('classify-ticket', {
 args: {
 summary: issue.fields.summary,
 description: issue.fields.description,
 reporter: issue.fields.reporter.displayName,
 labels: issue.fields.labels ?? [],
 },
 result: Classification,
 });

 const routing = await session.skill('route-ticket', {
 args: {
 classification,
 summary: issue.fields.summary,
 description: issue.fields.description,
 },
 result: Routing,
 });

 const confident =
 classification.confidence === 'high' &&
 routing.confidence === 'high' &&
 routing.assignee != null;

 if (confident) {
 await jira.assignIssue(env, issue.key, routing.assignee!);
 await jira.applyLabels(env, issue.key, [
 `category/${classification.category}`,
 `domain/${classification.domain}`,
 `priority/${classification.priority}`,
 `team/${routing.team}`,
 ]);
 return { action: 'assigned', issue: issue.key, ...routing };
 }

 return await escalate(env, issue.key, classification, routing);
}

async function escalate(
 env: any,
 key: string,
 c: v.InferOutput<typeof Classification>,
 r: v.InferOutput<typeof Routing>,
) {
 const body = [
 `Triage agent escalated this ticket for human review.`,
 ``,
 `*Classification (${c.confidence}):*`,
 `- Category: ${c.category}`,
 `- Domain: ${c.domain}`,
 `- Priority: ${c.priority}`,
 `- Reasoning: ${c.reasoning}`,
 ``,
 `*Suggested routing (${r.confidence}):*`,
 `- Team: ${r.team}`,
 `- Assignee: ${r.assignee ?? 'unsure'}`,
 `- Reasoning: ${r.reasoning}`,
 ].join('\n');

 await jira.addComment(env, key, body);
 await jira.applyLabels(env, key, ['needs-triage']);
 return { action: 'escalated', issue: key };
}

Two skill calls, one branch. The whole file fits on a single screen.

The JIRA helper is small enough to inline. Three calls: assign, comment, label.

typescript// jira.ts
const base = (env: any) => `https://${env.JIRA_HOST}/rest/api/3`;
const headers = (env: any) => ({
 Authorization: `Basic ${btoa(`${env.JIRA_EMAIL}:${env.JIRA_TOKEN}`)}`,
 'Content-Type': 'application/json',
});

export async function assignIssue(env: any, key: string, accountId: string) {
 await fetch(`${base(env)}/issue/${key}/assignee`, {
 method: 'PUT',
 headers: headers(env),
 body: JSON.stringify({ accountId }),
 });
}

export async function addComment(env: any, key: string, text: string) {
 await fetch(`${base(env)}/issue/${key}/comment`, {
 method: 'POST',
 headers: headers(env),
 body: JSON.stringify({
 body: {
 type: 'doc',
 version: 1,
 content: [
 { type: 'paragraph', content: [{ type: 'text', text }] },
 ],
 },
 }),
 });
}

export async function applyLabels(env: any, key: string, labels: string[]) {
 await fetch(`${base(env)}/issue/${key}`, {
 method: 'PUT',
 headers: headers(env),
 body: JSON.stringify({
 update: { labels: labels.map((l) => ({ add: l })) },
 }),
 });
}

The skills #

A Flue skill is a directory. It has a prompt template and zero or more context files the model reads before answering. That’s where the “advanced reasoning” actually lives, in the context the model gets to look at before it commits to a structured output.

Here is skills/classify-ticket/prompt.md:

textYou are a triage assistant for our engineering org. Classify the JIRA ticket
below.

Use these context files to understand the categories, domains, and our
priority rubric:

- /context/categories.md
- /context/domains.md
- /context/priority.md
- /context/historical-examples.md

Process:

1. Read the ticket and the context files.
2. Pick the single most accurate category and domain.
3. Pick a priority based on /context/priority.md, not based on how loudly
 the reporter complains.
4. Set confidence based on how clean the match is. If you have to choose
 between two domains, that is "medium" at best. If the ticket is too
 vague to map confidently, that is "low".
5. In `reasoning`, write 2 to 3 sentences explaining the call. This is
 what a human will read if you escalate.

Never guess. We would rather have a human triage an ambiguous ticket than
auto-assign a wrong one.

The ticket:
- Summary: {{ args.summary }}
- Description: {{ args.description }}
- Reporter: {{ args.reporter }}
- Labels: {{ args.labels }}

Three things matter in that prompt. The structured output schema enforces that the model picks from a finite set of categories. The “never guess” instruction backed by the confidence field gives it permission to bail out. The context files give it the org-specific knowledge that the base model can’t have.

skills/route-ticket/ is the same shape. Its own prompt, its own context:

/context/teams.md: what each team owns, with examples.
/context/people.md: who’s on each team, what they specialize in, and who’s currently OOO.
/context/ownership-by-domain.md: table of domain to primary team, with edge cases.

The OOO file is the under-rated piece. If the model’s first pick is on vacation, it should fall back to the team’s secondary, not barrel through with a stale assignment that nobody picks up for a week.

What “confident” actually means here #

The confidence field isn’t magic. It’s the model self-reporting after reading the prompt and the context files. It’s wrong sometimes. Two things make it less wrong:

Two paths, one decision. I run both skills before deciding. A “high” on classification but “medium” on routing means we ask a human, even though the model thinks it has half the answer. In practice, “the routing is shaky” is the most common reason to escalate, and I want that signal preserved instead of averaged away.

No null assignees on the happy path. If the routing skill returns assignee: null (it knows the team but not the person), I treat that as not-confident even if the model self-reports “high”. The shape of the result is doing some of the gating work for me.

You could tighten this further. Numeric confidence with explicit thresholds, an explicit “needs more info” exit code from the skill, retries with deeper context. I haven’t needed those yet. The two-skill, two-confidence pattern catches the bulk of bad routings before they happen.

The escalation comment is the product #

When the agent isn’t sure, the JIRA comment is where it earns its keep. Look at what it writes:

textTriage agent escalated this ticket for human review.

*Classification (medium):*
- Category: support
- Domain: billing
- Priority: medium
- Reasoning: Customer reports a charge they don't recognize. Could be
 a duplicate from the recent retry storm or a real billing bug. Treating
 as support until billing confirms which one.

*Suggested routing (low):*
- Team: billing
- Assignee: unsure
- Reasoning: Billing team owns this domain, but they're rotating an
 on-call this week and I can't tell from /context/people.md who is
 actually picking things up today. Recommend an EM eyeball this and
 route.

A human reading that has all the work pre-loaded. The category guess. The domain guess. The reasoning. The reason it stopped short. They’re not triaging from scratch. They’re auditing a draft.

That’s the actual UX win. Even when the agent fails, it fails in a way that saves the human time.

Deploying it #

Flue runs in a few places. For something this small I’d put it on Cloudflare Workers. The request flow is “JIRA webhook, 30 seconds of model calls, JIRA REST API.” No long-running compute, no filesystem, just a function that eats a webhook.

Point JIRA’s automation rule at your worker URL, configure secrets in Cloudflare for the JIRA token and the Anthropic key, push with wrangler deploy. The whole thing has fewer moving parts than the legacy “triage Slack channel” my team used to run.

Where this stops working #

It is not a replacement for an EM. It is not a replacement for a tech lead with context. The agent is good at the volume case: routine tickets, clear ownership, well-documented domains. It will struggle at the long tail:

Cross-team tickets that legitimately span two domains.
Tickets where the customer is using the wrong vocabulary for the system.
Anything political. Reorgs, ownership disputes, “you broke our launch.”

The escalation path is what catches those. As long as the agent is willing to stop and ask, the long tail goes to a human anyway. The agent’s job isn’t to be right about everything. It’s to clear the boring 70% so humans can focus on the interesting 30%.

That’s the same pattern I keep finding for these harness-based agents in general. They don’t replace the senior person. They eat the toil that the senior person hates doing, and they hand back the genuinely hard cases with a useful first draft. On net, an excellent trade.

Flue vs Mastra: TypeScript Agents in 2026

Sat, 02 May 2026 09:00:00 -0400

I’ve been on a kick lately, building small agents in TypeScript instead of Python. Two frameworks keep showing up in my browser tabs: Flue and Mastra. They’re both betting on the same thing: TypeScript is the right language to ship AI in. They just disagree about almost everything else.

That disagreement is the interesting part.

The harness vs the workflow #

Flue’s pitch is one line: Agent = Model + Harness. The framework gives you a programmable harness. Sandbox, filesystem, bash, sessions, skills with structured output. You drop in a model. You get something that looks a lot like Claude Code or Codex, except you wrote it and you deploy it.

Here’s a Flue agent that triages a GitHub issue:

typescriptimport type { FlueContext } from '@flue/sdk/client';
import * as v from 'valibot';

export default async function ({ init, payload }: FlueContext) {
 const agent = await init({ model: 'anthropic/claude-opus-4-7' });
 const session = await agent.session();

 const triage = await session.skill('triage', {
 args: { issueNumber: payload.issueNumber },
 result: v.object({
 severity: v.picklist(['low', 'medium', 'high', 'critical']),
 reproducible: v.boolean(),
 summary: v.string(),
 }),
 });

 return triage;
}

The whole shape is: init the agent, open a session, call a skill, get a typed result back. The skill is a directory of prompts and tools that the harness orchestrates. Your code never has to babysit a tool-call loop. The framework is doing it.

Mastra goes the other way. The core abstractions are agents, workflows, and RAG. You compose them, evaluate them, and deploy them as APIs next to your Next.js or Hono app.

A roughly equivalent Mastra agent:

typescriptimport { Agent } from '@mastra/core';
import { z } from 'zod';

export const triageAgent = new Agent({
 name: 'issue-triage',
 instructions: 'You triage GitHub issues. Be concise.',
 model: { provider: 'ANTHROPIC', name: 'claude-opus-4-7' },
});

export async function triage(issueNumber: number) {
 const result = await triageAgent.generate(
 `Triage issue #${issueNumber}`,
 {
 output: z.object({
 severity: z.enum(['low', 'medium', 'high', 'critical']),
 reproducible: z.boolean(),
 summary: z.string(),
 }),
 },
 );

 return result.object;
}

Different shape entirely. You declare the agent up front, you call .generate() with a structured output schema, you get an object back. There’s no harness loop driving sessions and skills. There’s just a model with tools, and you wire it into your app like any other service.

Where they diverge #

	Flue	Mastra
Mental model	Agent = Model + Harness	Agent = LLM with tools
Primitives	Sessions, skills, sandboxes	Agents, workflows, RAG
What you bring	Skill prompts and tools	Instructions, tools, eval suites
Deploy targets	Node, Cloudflare Workers, GitHub Actions	Anywhere TypeScript runs, plus Mastra Cloud
Replaces	Dosu, Greptile, CodeRabbit	Honestly, half of LangChain
Tagline	“Stop renting someone else’s agent”	“Python trains, TypeScript ships”

If you’re building something that acts (writes files, runs commands, reads a repo, works through a task across many tool calls), Flue’s harness model is doing more for you. If you’re embedding an agent into an existing app and the bigger problem is glue, eval, and observability, Mastra has more of the production scaffolding ready to go.

I don’t think one is winning yet. They might both be right for different jobs.

The thing nobody’s saying out loud #

Both of these projects assume something I would have laughed at five years ago: that TypeScript is a serious language for building AI infrastructure. Not a frontend duct tape. Not a glue layer. The actual substrate.

A couple weeks back, Microsoft shipped the TypeScript 7.0 beta, and the punchline is that the compiler is no longer written in TypeScript. It’s written in Go. Native code, shared memory parallelism, the whole thing. They’re claiming about 10x faster than 6.0 on real codebases. The language server, too. The editing experience is reportedly night and day.

Read that twice. The TypeScript team looked at the language they invented, decided it wasn’t fast enough to compile itself, and rewrote the toolchain in Go. That’s a remarkable thing to do.

It also reframes everything. If tsc is fast enough that incremental compiles feel like Go’s build times, the cost-of-iteration argument against TypeScript for serious systems work mostly evaporates. The other arguments (no real concurrency, GC pauses, V8 quirks) are runtime arguments, and most agent code is I/O bound on a model API anyway.

So you get a typed, npm-friendly, JIT’d runtime with a now-fast toolchain, and the LLM ecosystem has decided to publish first-class SDKs for it. That’s a pretty good place for a framework to land.

Flue and Mastra are both betting on it. They might both be right.

What I’d actually pick #

For a coding agent, an issue triage bot, anything that needs to do work in a sandbox: Flue. The harness model is the right level of abstraction for that kind of work, and “drop your code in a Cloudflare Worker, point a webhook at it” is a stupidly nice deployment story.

For a chat-shaped assistant living inside a real product, with eval suites and traces and the whole observability story: Mastra. The framework gets out of your way and the tooling around it is more mature.

For everything else: keep an eye on both. The TypeScript-as-AI-substrate bet is going to play out fast, and a 10x faster compiler landing the same year is not a coincidence I would have predicted.