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 feel like a good fit for the QWAN blog just yet.
This post was partially written with claude code, see the commit history on our gitea if you want to check the differences.
When I prototype with a coding agent at 11pm (I should go to bed and write a post about sustainable pace the next day ;-) ), the thing I learn is not a polished QWAN insight. It’s a half-formed observation about something that just happened, or a trick for keeping the human in the loop, or just “I built this and here’s what surprised me.”
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.”. And also, currently, how do I generate just enough and focus on interesting feedback loops instead of code?
I wrote this last may as well shallow research tool:
I want to both get better at using LLMs for programming, and also understand how they work. Marc suggested earlier this year that I write a series of blog posts about my use of them, but I have been drinking from a firehose, and it is quite difficult to figure out a good place to start writing.
I have made good progress in learning, and at the same time, practices are still evolving. I see people write patterns. I think it is useful, but too early for that. I am at heuristics (rules of thumb).
That is also why I open sourced the code for this blog firehose repository on our gitea. I think Jekyll, the static site generator we have for QWAN is passable, but I want the option to have a more interactive blog, and since this is going to be a firehose of ideas, give readers the option to subscribe to only what they are interested in, filter posts, like etc. I helped a friend with ‘Ghost’, but it felt clunky. I like writing in plain text and publishing with git push - that works with Jekyll and other static site generators.
I am exploring working in small slices. That does require some initial investment in modularity. If you look at the code, you will notice that some of the blogging functionality is separate from the main site. I want an ‘engineering blog’ and ‘release notes’ as a plugin for Software as a Service applications.
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 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.