Alexander Belanger

We've started using coding agents more in our development lifecycle and honestly, @hatchet_dev was really difficult to use with them. Engineering teams building with Claude Code and Cursor expect their tools to fit natively into that workflow. So we fixed it.

Checkpointing your AI agents is important. (Sundance hasn't called us back yet.)

If you're building AI in SF, we have a few spots left and would love to see you there. Reach out for the details!

Some of the most interesting conversations I've had recently have been with AI builders on the future of agents. We'll be discussing that and more at the @NangoHQ and @hatchet_dev happy hour next week. There's a few more open spots, DM me if you're interested in joining!

@hatchet_dev New blog on how we did this: hatchet.run/blog/supertoas…

Six months ago, we saw a huge spike in @hatchet_dev usage (which is great) but then we started to see an issue. Our Postgres instances were running out of storage faster than we could resize our database, shooting over our 80% disk usage and creeping up over 90%. We knew it would take over 6 hours to cut over to a larger instance, which meant that our database would crash before the cutover was completed. This is a symptom of the particulars of our infra stack, which needs to balance really fast task execution paths with storing very large amounts of data (over 50TB in just our Oregon region) in the form of task payloads. We use NVMe disks to make our Postgres queries incredibly fast, but these aren't networked disks, so swapping the disk out requires provisioning an entirely new database. Luckily for us, when this usage spike happened, we had already implemented a failsafe: immediate offloads of payloads to S3 so disk space would stop increasing on Postgres. This was implemented on S3 Express One Zone for milli-second level reads and writes. But we knew this wasn't a good long-term solution (limited support for express one zone in regions, regular S3 is far too slow, and S3 PUT requests alone would cost us tens of thousands of dollars per month). So we started building a multi-tier storage architecture, where "hot" payloads stay on our NVMe disks while cold payloads are batched and flushed to S3. Since most of our Postgres payload data exists in TOAST tables, we affectionately call these "supertoast" tables.

Quick Monday morning win: @hatchet_dev had more active users last week than ever before. We've also doubled the number of self-hosted installations compared to 3 months ago. 🤯 Excited for launch week at the end of this month!

Drumroll please. 🥁 We re-wrote our docs! Yes, all of them. Each page written by an actual human for the (human) developers who will read it. Some highlights: 🤖 Coding agent quickstart (Cursor, Claude Code, and more) 🧑‍🍳AI agents cookbook - reasoning loops, routing, multi-agent, parallelization ➰Human-in-the-loop patterns 👷Updated core concepts - tasks, workers, and durable workflows

We've spent 2 years trying to get @hatchet_dev's docs right. We might have just done it. Our philosophy: if we expect humans to read the docs, a human should write them. Nothing is worse than trying to figure out what a product does and being greeted by a mountain of listicle AI slop. Unfortunately, that makes us (the founders + engineers) the bottleneck. We've wanted to use AI to help solve this problem for years but hadn't tried one that really worked. This week, we tried @promptlessai and it finally clicked. We write the content, Promptless ensures it's up-to-date and correct by running against every PR. Congrats @prithviramak on a great product!

nicest gesture from anyone during the batch? warm apple pie handwritten note cmon tyvm <3 @abelanger5 @hatchet_dev

Welcome to the team, Julius!

Here’s what’s new in Hatchet 🪓: 🦀Run tasks in Python significantly faster with improved serialization performance in Rust 👉Access task context from anywhere with new helper

This story at the top of HN over the weekend resonated with me deeply. ... I fundamentally don't understand the value of MCP servers for developer tools at this point. After talking to a bunch of developers over the past few weeks, it's become clear to me that agent skills and pure CLIs are where things are headed. We originally shipped @hatchet_dev's CLI with a docs MCP bundled in, so that Claude Code and Cursor could augment their context by searching our docs page, and could then write code to take action in Hatchet (like getting a workflow run result, replaying and cancelling runs, etc.) But in testing with early users, feedback was pretty much the same. Our users A. just wanted CLI commands and B. wanted to let coding agents figure out which commands to use. So we shipped a beautifully recursive `--help` based CLI, and the feedback was universally the same: people wanted skills. So we shipped skills! And so far the feedback has been really positive. This matches my own experience as well. I don't use MCP servers, use a handful of skills, but mostly I just have Cursor and Claude Code use CLI commands. Is this the end of MCP? Interested in what others think here.

Check out the docs here: docs.hatchet.run/cli

We shipped our new CLI for easier local development and early feedback has been really encouraging.

We've started using coding agents more in our development lifecycle and honestly, @hatchet_dev was really difficult to use with them. Engineering teams building with Claude Code and Cursor expect their tools to fit natively into that workflow. So we fixed it.

More on our new CLI here: #announcing-the-hatchet-cli" target="_blank" rel="nofollow noopener">hatchet.run/announcement/h…

Really excited about this launch. A frequent ask from @hatchet_dev users = better support for coding agents like Claude Code and Cursor, and in particular, support for an MCP integration or skills.

Working on something we're really excited about. Big launch coming soon. 👀

I've been thinking about how Amdahl's law might be useful to claude-pilled developers running 10 parallel tmux sessions. At a certain point, you're constrained by your inherent focus ability and mental bandwidth; even an infinite number of tmux sessions converges on a fixed asymptote of productivity.