firehose/app/priv/blog/engineering/2026/03-17-why-firehose.md

%{ title: "Why Firehose", author: "Willem van den Ende", tags: ~w(meta ai), description: "Why I built a separate personal blog, and what it has to do with drinking from the firehose.", published: true }

I wrote about publishing short posts on the QWAN blog last year. Giving myself license to write shorter, rougher pieces. That worked for a while. But some things don't belong on a consultancy blog.

When I prototype with a coding agent at 11pm, the thing I learn is not a polished QWAN insight. It's a half-formed observation about evals, or a trick for keeping the human in the loop, or just "I built this and here's what surprised me." The QWAN blog has a certain standard. This stuff needs somewhere scruffier to land.

Hence Firehose — named after what it feels like to work with AI coding agents. You're drinking from a firehose of generated code, suggestions, and decisions. The interesting question is not "how do I generate more" but "how do I stay in control of what's coming out."

That's also what this site is built with, by the way. The homepage, the blog engine, the layout — all built in conversation with Claude Code. I wanted to experience what our clients experience: shipping something real with an AI agent, and noticing where the friction is.

A few things I noticed, building this:

• Layout inheritance is a design decision. The blog engine rendered pages outside Phoenix's layout pipeline. Getting navbar and CSS onto blog pages meant rethinking how the pieces fit together — not just adding a wrapper div.
• Warm aesthetics take intention. The default Phoenix boilerplate is fine, but it says nothing about who you are. Choosing fonts and colours forced me to think about what "personal but professional" looks like.
• It's fast when it works, and confusing when it doesn't. When the agent understands your stack, you move at extraordinary speed. When it doesn't (say, the difference between @inner_block and @inner_content in Phoenix layouts), you can burn time on a misunderstanding that a human would catch in seconds.

This is the space I want to write in. Shorter than a conference talk, longer than a LinkedIn post. Honest about what works and what doesn't.

If you're a CTO or engineering lead wondering what "AI-native development" actually looks like day to day — not the vendor pitch, the lived experience — that's what I'll be writing about here.