HN user
Housecat.com
Previously VPE at GRAX, engineering at Segment, co-founder and CTO of Convox (S15) and platform architect at Heroku.
https://github.com/nzoschke
We're thinking and designing with number of finance / VC / PE types. This is where the durable workflows can really help.
I wouldn't trust a agent chat or SKILL.md for numbers just yet.
But I would trust having a coding agent code the workflow, then have real people review the code, operate the tool, and double check the numbers.
Yes that's a good way to think about it.
We started as a hosted claw of sorts. But the less technical folks wanted something more than chats and markdown to do their work.
We then added a modern todo list interface. Having the agent create and update action items from email and Slack turns out to be genuinely useful, but having another TODO list to check wasn't as useful.
So we landed back on an email inbox. Having your actual email to work on, plus the "inbox" to also home other tasks and chats from the agent, is feeling very productive.
TL;DR we're building a unified UX / API / SDK / VM all around the concept of "inbox". Not just bolting AI on to search / draft / send.
First its a question of the shape of a product. There are a few paradigms:
1. Keep AI far away from my email
2. Side bar chat in email app
3. Chat app that can interact with email
4. Fully autonomous email agents
I don't like 4. At its core, real email is person to person communications, and we want to keep humans in the loop and actually writing thoughtful messages back and forth.
3 is here to stay, but I don't think most people actually want to free form chat or vibe code their day to day communications long term.
We can expect 2 in pretty much every SaaS but so far I'm underwhelmed by many experiences. An agent only truly works when it has great tools, and not many email providers or apps have great APIs or higher level tools and primitives other than "draft" and "send".
So first we're working on great tools for the human. Common templates, dynamic folders and labels, context from your CRM, integrated tools for your other workspace tools, easy ways to code customizations and workflows.
Next we're equipping the agent with the same tools to help you, only when you want it to.
I love Hetzner for some of the cheapest cloud components that can do anything.
One use case is a custom ACME cert broker and DNS server. Another is their storage boxes split up into sub accounts for my and friends backups and music.
I've moved all my web stuff over to exe.dev, but I also turn my Hetzer box into a similar "Agent Computer" by dropping in a binary with `claude` setup and a chat server:
Very interesting!
As a small startup I'd love to ditch Slack, as its a walled garden and both under-featured and over-complicated at the same time. GitHub has been losing my favor too.
Tangentially our startups is combining email, AI agents (chat and coding), and GitHub workflows and it feels really good.
https://housecat.com/blog/gmail-durable-workflows-sandbox-vm
It feels like a renaissance for all workspace tools, where up until recently it was mostly dev tools that got all the really fun power ups.
None of the music videos were great
Glad they acknowledge this.
Curious how much time in addition to tokens this costs. If you have to spend $25 and wait 45 minutes to get a basically unwatchable video, I'm not worried about indie film makers being replaced just yet...
Looks cool. I’m looking for a macro pad with a little LCD that’s Mac and Linux compatible.
This looks like it has LEDs but not a screen.
Any experience with https://www.eezbotfun.com/ or recommendations for something similar?
Could rebrand to the HUGS stack -- HTMX (or hypertext), Unix, Go, SQLite
Love Go + HTMX. I pair it with a-h/templ for a bit more type safety on the template, components and partials.
I just shared my whole toolkit too [1], I call it the "GUS stack" -- Go, Unix, SQLite. Inspired heavily by the exe.dev "GUTS" stack [2] but with HTMX instead of Typescript.
Some other Go components in the kit...
- cockroachdb/errors for errors with stack traces
- templ for type-safe HTML templates (with htmx for reactivity and tailwindcss for CSS)
- fuego for an OpenAPI spec generated from web handlers
- sqlc for type-safe code generated from SQL
- modernc.org/sqlite for a pure Go sqlite library
- goose for SQL and Go migrations
- dbos for durable workflows in SQLite
- rod for Chrome / CDP testing and automation
Feels so productive coding, agentic coding, and building and deploying binaries with this stack.
No question most folks will simply take the path of least resistance.
We need to make it easier (and faster and cheaper) to get a secure cloud agent computer than it is to YOLO it on your own computer.
The home directory is the scariest thing to me. The agent needs the code to code, but it doesn't need your personal files or secrets.
Personally I'm not worried about sharing business code with the model providers. The value of code and IP is decreasing to zero, the only thing that matters is execution on the business front. If they want to steal your business they can do so by rebuilding the idea from scratch.
Another +1 to cloud sandboxes (and exe.dev) vs laptop sandbox.
Runs 24/7 completely air gapped from your laptop.
You also want a service proxy so the sandbox can access GitHub or Stripe without keys accessible to the agent. I haven't seen many of the laptop sandbox tools do this, where exe.dev does it out of the box with their "integrations".
I usually drop my own binary agent coding toolkit inside the sandbox so I have things like a code browsing and review right there in every sandbox too.
https://github.com/housecat-inc/scratch
Like you I also have a Mac Mini I've thought about making into my own 24/7 dev box, but building this vs buying 50 VMs from exe.dev for $20/mo doesn't add up for me.
We all know the dangers of running agents with no permissions on our laptop.
The good news is its now just as easy to spin up a sandbox in the cloud for an experiment or coding session than it is on your laptop. Possibly easier since laptop sandboxes aren't as cut and dry as a new cloud VM.
exe.dev is my sandbox infra of choice. You get a new sandbox in literally a second with SSH and a coding agent (Shelley) built in.
I generally drop in in my own binary with toolkit so I can connect Claude or Codex subscription and use their harness.
https://github.com/housecat-inc/scratch
If I was working with newer agents like Grok I'd absolutely experiment on a cloud sandbox before running on my laptop bypassing permissions.
What AGENTS.md and skills are people relying on these days?
I have little to none and am successful building full stack Go apps Claude Code, Codex, and Shelley which covers the spectrum of crazy black box to simple `bash` clanker.
It makes me think the models are continually improving in knowing what to do on their own.
I do put some major work into the classic "Developer Experience" (DX) of my code base. Standard Go tooling, idiomatic Go, well designed initial test harnesses, GitHub actions that enforce some linting.
I think that works better than any markdown instructions ever will.
Historically, rewrites are a terrible idea.
This changed for me over the last 5 years.
The first scenario was joining a company where a software product barely worked. We did the traditional incremental refactoring / rewriting, but eventually learned how rotten the core was that rewriting from first principles was the best path forward.
The lesson learned here is that the conventional wisdom probably only applies to rewriting complex but working systems.
Then multiple scenarios in the agentic coding age. Between day jobs and hobbies I've reproduced major chunks of complicated software like Salesforce, Gmail, Pioneer Rekordbox with very lean teams.
Much like the blog post, the trick is to get an excellent verification loop with a compiler, linter, and test harness / test suite around the core behaviors.
It's feeling more and more that designing and implementing comprehensive test harnesses is the real work, once you have that let the LLM cook.
Fair feedback and sentiment.
As I build this out there's actually less and less AI in the product and more good old-fashioned UX, writing and data entry tools, and automations.
Some examples...
We're simply bringing a CRM CRUD form into an email thread, populated from email sender / domain, for the end user to review and submit.
You can add your own notes into a thread, and copy / paste from
Similarly good pre-defined templates with variables perform way better than AI generated drafts.
Context is indeed key. The person at their email inbox has most of the context in their head, they need good tools to organize that context down for their future self and their team. AI can help but its really about just building a great tool for the operator.
Genuinely curious how quality is so poor at MS. Tech debt and deadlines and red tape?
This is the company that invented the term dogfooding and forced everyone to use Exchange until all the bugs were worked out.
I’m building a next gen web mail app at work and there are a ton of UX edge cases but the performance of the core UI is not rocket science.
I’m looking for help play testing to squash bugs, improve the last mile of performance, and to add Outlook support.
The incentive is the mail app is “malleable” so you can craft custom workflows and UI widgets to help you get to inbox zero.
Codex just walked me through my first experience with unicorn the other day, emulating / stubbing out subsystems from a Pioneer CDJ-3000 to help understand its music catalog database format and network protocol.
It felt like science fiction watching Codex write unicorn to host binaries and reverse engineer them.
What has worked for me…
Pair programming. I call it pilot / copilot / autopilot. Two real people plus one or two agents working together. Classic XP stuff, the copilot can help remind what we are focusing on, file follow up issues, give instant code reviews.
Bake offs. Do the same task but in two different chats or agents or approaches (TDD vs vibe or legacy app vs next app).
I don’t do these all the time, and they don’t guarantee ROI, but it keeps me focused on one thing to completion intend of getting distracted
My impression too.
Claude Desktop, Cowork, Code, Design all get meaningful new features week over week.
I can’t recall another vendor with such focus and velocity.
Google products are evolving at a glacial pace. OpenAI isn’t as focused on what knowledge workers need.
I do love Postgres and DBOS.
I also recently started experimenting with https://github.com/earendil-works/absurd which is also Postgres and even simpler than DBOS. Their comparison is a great read:
https://earendil-works.github.io/absurd/comparison/
But for operational reasons I've started using sqlite for durable workflows instead. Porting the database concepts from either DBOS or absurd PG to SQLite is remarkably easy these days. A small polling loop instead of notify/listen feels fine for smaller workloads.
Great question and I'd love the answer.
I bet the answer is industry changing even if the token cost is high.
This work was impossibly expensive in terms of people hours and time before. Architectural planning, engineering alignment and politics, phased engineering that gets interrupted by changing priorities.
That it's possible to do R&D, the port, and get 99.X test passing in less than 2 weeks is so much more efficient for the humans.
That’s me with a TI-85 in 7th grade in ‘95 or so.
It was effectively a portable computer that I was allowed to use and play with in most classes.
Started with TI-BASIC, then discovered ticalc.org and the shell and assembly programming hacks, games, and home brew transfer cables.
It effectively started my electrical engineering and computer science career.
I know I’m not alone.
The screenshot in the post demonstrates show-off TUIs.
That git TUI doesn't offer anything over `git` CLI.
The network / battery / performance TUI is redundant with the tools in the window menu bar.
I love the aesthetic of TUIs but their actual day-to-day install base and usage must pale in comparison to CLIs and GUIs.
I'm with you here.
In the "before times" an API and web UI that double times as native via Electron was the biggest bang for your buck.
CLI would be a hacker's side project, TUI would be them showing off more. Native would require hiring a team of specialists which is a total non-starter.
In the "after times" API and CLI are getting more love rebranded as MCP and tools.
To the parent topic, I suspect "build a TUI around my CLI" is a slam dunk for an LLM text in / text out machine which is why there is a resurgence of these too.
Hopefully that is the gateway drug to "build a SwiftUI around this", and an antidote to doing everything in Electron.
I agree, the LLM porting things is a game changer.
Does it also follow that we can have pretty much any shape for valuable apps? API, CLI, TUI, Web, SwiftUI, WinUI...
I have a Hetzner box with Caddy too.
The difference with exe.dev is multiple VMs. I have over 20 now with isolated apps, branches of the same app, etc.
I’ve rediscovered plain old CGI as a great way for users to “vibe code” custom pages on our platform. [1]
The scenario is we have our first party task lists and data viewers, but often users want to highly customize it. Say build a Kanban view or a custom dashboard with data filters and charts.
The box has a coding agent which means the user can code anything vs us building traditional report builder tools.
Go’s stdlib has good support on both the server side and user space. The coding agent makes a page-name/main.go that talks CGI and the server delegates requests to it.
It’s all “person scale” data and page views so no real need to optimize with fast CGI even.
What’s old is new again for agents!
Yes I’m trusting exe.dev disks and persistence.
For many apps the weird experimental version is all there is. Call it vibe coding or experiments or non-critical tools. These may not even have a GitHub repo. I trust local git and the exe.dev disks.
Then for serious apps the above is the same shape for development branches. Spin up a VM in a few seconds with the code checked out and running online and editable over an SSH mount is the magic.
Then that turns into a PR on GitHub and a normal review then CI/CD to staging and prod takes over.
Congrats!
My daily driver is Zed developing on SSH remote servers on exe.dev.
It's crazy to think of all the dev tools I've churned through over the last 18 months but these two feel sticky.
Zed has everything I need in a unified pane. File editor, terminal, agents, SSH remotes. And it's fast and intuitive
exe.dev is the first "dev container" I've ever *loved*. The remote sandbox means `dangerously-skip-permissions` is safe. Being on the internet with good private / shared / public access saves so much time.
I also use https://conductor.build/ and GitHub but this is starting to feel clunky compared hacking directly against online live reloading apps.