I’m not offended — just to clarify the context.
I’m not a native English speaker, so I sometimes use AI to help with phrasing or structure. The ideas, experience, and arguments are mine; AI just helps me express them more clearly for an English‑speaking audience.
I don’t see anything wrong with that. For many non‑native speakers it’s simply a tool that removes friction and lets us focus on the actual content instead of grammar. The engineering work and the analysis in the article are based on real experience, not generated text.
If you disagree with the conclusions, I’m happy to discuss them — that’s why I posted it.
I've always been skeptical of the celebrity engineering managers/software entrepreneurs like Graham, DHH, Atwood, Spolsky [1], etc. Just because you made and marketed one or even two successful products doesn't mean you have any useful generalizable advice.
Today people who made something with AI think they have something profound to say about their experience but they don't.
All the projects I do now have a significant amount of input from AI assistants but I am going to post "Show HN: my heart rate variability biofeedback webapp"
and not add "... that i vibe coded" because the latter one codes me as yet another NPC.
(e.g. if I am more successful as AI-assisted developer than some people it is not because I know anything about AI-assisted development which is interesting or generalizable, but it is because of the toolbox I've been using in a lifetime of software development!)
[1] Carmack is a true genius who is the exception that proves the rule
I’m not trying to present myself as a guru or a celebrity engineer. My background is in product and technical leadership, not in being the “hero coder.” I didn’t build an AI system — I built a real production platform where AI was one of the tools in the workflow.
The article isn’t meant to be profound. It’s just a practical report from someone who pushed AI‑assisted development into a full product environment and saw where it helped and where it broke. I shared it because some of these patterns might be useful to others, and because I’m also interested in learning from people who’ve taken different approaches.
If your experience is different, I’d genuinely like to compare notes — that’s the whole point of posting it here.
it helps to be able to describe something visually with a lot of accuracy (ie, not "a button is 2px off", but "the icon for this button is too close to the text and not vertically centered", etc). it also helps to be able to just step in and correct a design yourself.
thanks for the comment, step in is important but I was thinking about Claude Code - I actually usually don't step in that much. Would it make sense to have human in the loop or it's better to let the Agent decide everything and just show the result?
Funny you mention that—visual automation was actually in my original roadmap!
I held off on building it because I personally really cherish the manual process. The physical effort (even the clicking) helps me settle into the reading.
But I hear you. 100 clicks is a heavy lift for every session. I will likely add that 'visual auto-play' feature in a future update as a middle ground. Thanks for the feedback!
There are some big parts identified for this case, and because it is dependency of 3rd party service, we can not do much about it.
But more importantly, I think it is the product itself, the market is probably does not appreciate that much of "customization / personalization" as I thought, in other words, we are probably haven't figured out the best path to get the ideal users yet.
In the other side, free users do not have this issue. We do have free tier which counts for 1/3 of all active users.
I find a lot of this to also be true with sole engineers managing agents.
I've now seriously approached vibecoding two nontrivial projects, and in each case using "safe tools" was a good way to get to a working stage, faster:
- in one I insisted on typescript early and found it to be more of a hurdle than letting the LLM cobble js learning in and address bugs in a way an engineer might find uncivilized (trial and error over bulletproof typing).
- in another, I found that using react was not offering much benefit to a given project, and asked the llm to rewrite in vanilla. while this mostly worked, it introduced new bugs that were not present when using react. switching BACK to react eliminated these and enabled the LLM to continue writing features at no (current) technical or performance cost!
just want something comparable to next (api layer, ssr ability, nice surface api), for a relatively simple case (oauth with ms, simple api to query other apis).
I'm avoiding Next because deploying it on anything non-vercel sucks.
I still have no idea what benefits having your API serve markup is supposed to confer, but people tell me it's "great".
also, I find your headline misleading. htmx uses javascript, there's no accessing anything "directly from html". you could say that about any framework with directives, ie vue, but we all know better.
you mean via SSE? is any part of that an inherent "htmx only" thing, or even a "markup API only" thing?
a framework using a neat piece of technology isn't really a boon for the framework -- the technology of streaming itself is great, sure, but you can do that with any stack.
Sure, but the browser is fast and rendering HTML so why stream anything else? Why stream javascript + json to build html. You're adding a bunch of marshalling that doesn't need to be there.
Yeah, as I understand it the idea is that instead of making the server-side complex and the frontend code complex, you retain as much complexity server-side as possible and treat the browser as just a hypermedia renderer.
If a part of the page needs to change, the server figures out what it should change to and sends that page fragment.
Right. But, hypermedia systems doesn't go far enough. It can be even simpler then that.
In a video game the "server" doesn't figure out what's changed (that's too much work) it just redraws the frame. So rather than the complexity of working out what has changed you can just send down the whole page again whenever something changes.
This gives you view = f(state) over the wire and has great DX. It's called immediate mode in games.
The main point of hypermedia is the browser, not a gaming platform. Not even the mobile platform. HTMX is not purposed nor it advertises that it should be used outside of the browser scope.
I use Unpoly that replies on the same principles (HTML over the wire) and both of them are very clear about their intentions.
In my mind collaborative apps are a core feature of the web. Streaming hypermedia is a great way to keep all your state on the server and have a solid multiplayer/realtime experience, especially with large datasets.
Here's a basic google sheets clone that does just that:
