https://housecat.com/docs/editorial/why-housecat

The ideas I’m thinking about is: what’s old is new.

We’re seeing a massive influx of people writing software and administering servers for the first time ever. But so many people are jumping (or being pushed) into the deep end without basic training.

Lots of opportunities for us older admin folks to build, teach and help all the new folks.

- user and home directory for data

- crontab for scheduled jobs

- cgi for serving user space apps

- rsync for backups

We even rediscovered email patches but with agent to agent help making and applying them.

It’s simpler for us to operate and the agent to figure out.

The best thing I’ve done so far is put GitHub behind an API proxy and reject pushes and pull requests that don’t meet a criteria, plus a descriptive error.

I find it forgets to read or follow skills a lot of the time, but it does always try to route around HTTP 400s when pushing up its work.

I’ve been developing and working on dev tools for more than 15 years. I’ve never seen things evolve so rapidly.

Experiment, have fun and get things done, but don’t get too sure or attached to your patches.

It’s very likely the models and harnesses will keep improving around the gaps you see.

I’ve seen most of my AGENTS.md directives and custom tools fade away too, as the agents get better and better at reading the code and running the tests and feeding back on themselves.

Great docs help you, your agents, your team and your customers.

If you’re confused and the agent can’t figure it out reliably how can anyone?

Easier said than done of course. And harder now than ever if the products are rapidly changing from agentic coding too.

One of my only universal AGENTS.md rules is:

> Write the pull request title and description as customer facing release notes.

I’m looking for feedback, testing and possible security engineering contracts for the approach we are taking at Housecat.com.

The agent accesses everything through a centralized connections proxy. No direct API tokens or access.

This means we can apply additional policies and approval workflows and audit all access.

https://housecat.com/docs/v2/features/connection-hub

Some obvious ones are only grant read and draft permissions at all, and review and send drafts manually.

Some more clever ones are to only allow sending 5 messages a day, or enforcing soft delete patterns. This prevents accidentally spamming everyone or deleting things.

Next up is giving the agent “wrapped” and down scoped tokens you do want to equip it with the ability to do direct API calls. But these still go through the proxy that enforces the policies too.

UNIX solved this with files and pipes for data, and processes for compute.

AI agents are solving this this with sub-agents for data, and "code execution" for compute.

The UNIX approach is both technically correct and elegant, and what I strongly favor too.

The agent + MCP approach is getting there. But not every harness has sub-agents, or their invocation is non-deterministic, which is where "MCP context bloat" happens.

Source: building an small business agent at https://housecat.com/.

We do have APIs wrapped in MCP. But we only give the agent BASH, an CLI wrapper for the MCPs, and the ability to write code, and works great.

"It's a UNIX system! I know this!"

The OpenClaw stuff is awesome but it’s too raw for a lot of professionals and small teams. We’re trying to bring more guardrails to the concept and more of a Ruby on Rails philosophy to how it works.

Experience level: very senior, programming for 25 years, have managed platform teams at Heroku and Segment.

Project type: new startup started Jan ‘26 at https://housecat.com. Pitch is “dev tools for non developers”

Team size: currently 2.

Stack: Go, vanilla HTML/CSS/JS, Postgres, SQLite, GCP and exe.dev.

Claude code and other coding harnesses fully replaced typing code in an IDE over the past year for me.

I’ve tried so many tools. Cursor, Claude and Codex, open source coding agents, Conductor, building my own CLIs and online dev environments. Tool churn is a challenge but it pays dividends to keep trying things as there have been major step functions in productivity and multi tasking. I value the HN community for helping me discover and cut through the space.

Multiple VMs available over with SSH with an LLM pre-configured has been the latest level up.

Coding is still hard work designing tests, steering agents, reviewing code, and splitting up PRs. I still use every bit of my experience every day and feel tired at end of day.

My non-programmer co-founder, more of a product manager and biz ops person, has challenges all the time. He generally can only write functional prototypes. We solve this by embracing the functional prototype and doing a lot of pair programming. It is much more productive than design docs or Figma wireframes.

In general the game changer is how much a couple of people can get done. We’re able to prototype ideas, build the real app, manage SOC2 infra, marketing and go to market better than ever thanks to the “willing interns” we have. I’ve done all this before and the AI helps with so much of the boilerplate and busywork.

I’m looking for beta testers and security researchers for the product, as well as a full time engineer if anyone is interested in seeing what a “greenfield” product, engineering culture and business looks like in 2026. Contact info in my profile.

> Want to keep LLM .md files in a separate overlay, only make them visible on request? Also easy. CRDT gives the freedom in splitting and joining along all the axes.

I now have a bunch of layers of text / markdown: system prompts, AGENTS.md, SKILL.md, plus user tweaks or full out replacements to these on every repo or subproject.

Then we want to do things like update the "root" system prompt and have that applied everywhere.

There are analogies in git, CMS templating systems, software package interfaces and versioning. Doing it all with plain text doesn't feel right to me.

Any other approaches to this problem? Or is Beagle and ASTs and CDRTs really onto something here?

“Vibe” with vanilla HTML/CSS/JS. Surprisingly good at making the first version functional. No build step is great for iteration speed.

“Serious” with Go, server side template rendering and handlers, with go-rod (Chrome Devtools Protocol driver) testing components and taking screenshots. With a a skill and some existing examples it crunches and makes good tested components. Single compiled language is great for correctness and maintenance.

We have `go run main.go` as the convention to boot every apps dev environment, with support for multiple work trees, central config management, a pre-migrated database and more. Makes it easy and fast to dev and test many versions of an app at once.

See https://github.com/housecat-inc/cheetah for the shared tool for this.

Then of course `go generate`, `go build`, `go test` and `go vet` are always part of the fast dev and test loop. Excited to add `go fix` into the mix.

- E2E testing of browser components

- Taking screenshots before and after and having Claude look at them to double check things

- Driving it with an API and CLI as a headless browser

Will definitely give Rodney a look.

High velocity teams also observe production system telemetry and use error rates, tracing and more to maintain high SLAs for customers.

They set a "budget" and use feature flagging to release risky code and roll back or roll forward based on metrics.

So agentic coding can feed back on observed behaviors in production too.

- https://quicktype.io/

- https://github.com/danielgtaylor/huma then OpenAPI -> TS

- https://github.com/gzuidhof/tygo

- https://github.com/coder/guts

guts also does some AST stuff.

It seems like this project could help with this and then some.

My favorite Markdown creation was "GistDeck", a bookmarklet that turned a GitHub Gist of Markdown content into a slide show.

So much easier to make and share than a PowerPoint deck.

https://github.com/nzoschke/gistdeck

I'm instructing my agents to doing old school boring form POST, SSR templates, and vanilla JS / CSS.

I previously shifted away from this to abstractions because typing all the boilerplate was tedious.

But now that I'm not typing, the tedious but simple approach is great for the agent writing the code, and great for the the people doing code reviews.

That ~1000 drivers on the road are all better trained on what to do in the next power outage is incredible.

There will always be unexpected events and mistakes made on the roads. Continual improvement that is locked in algorithmically across the entire fleet is way better than any individual driver's learning / training / behaviorior changes.