Vibe engineering

>> Your slower to produce, higher quality code puts a boundary on the duration of a single feedback loop iteration. The code you produce can perfectly solve the problem as you understand it within an iteration, but cannot guarantee that your understanding of the problem is not wrong. In that sense, many lower quality iterations produces better software quality as the number of iterations approaches infinity.

I'll reply just to that as it being the tldr. First of all tech debt is a thing and it's the thing that accumulates mostly thanks to fast feedback iterations. And in my experience the better the comunication, to get the implementation right, and the better the implementation and it happens that you can have solid features that you'll unlikely ever touch again, user base habit is also a thing, continuing on interating on something a user knows how to use and changing it is a bad thing. I'd also argue it's bad product/project management. But my whole original argument was why we'd need to have a greater speed in the first place, better tooling doesn't necessarily means faster output, productivity as well isn't measured as just faster output. Let me make a concrete example, if you ask an LLM X to produce a UI with some features, most of them will default to using React, why? Why can't we question the current state of web instead of continue to pile up abstractions over abstractions? Even if I ask the LLM to create a vanilla web app with HTML, why can't we have better tooling for sharing apps over the internet? The web is stagnant and instead of fixing it we're building castles over castles over it

I wonder if we are more like accountants at the advent of spreadsheets, who have thrived and just changed tools, or farriers at the advent of automobiles?

Willison has an impressive record for coining terms. But feel like he may have missed it here. In the context, 'engineering' doesn't feel that different to 'coding'. The sloppy sounding part is 'vibe' and that's not been removed.

"Signups are open [1], and will remain so until October 20th."

Recently on HN [2].

[1]: https://solve.it.com/

[2]: https://news.ycombinator.com/item?id=45455719

Is "vibe engineering" a correct term for this? It's not vibe based when you scaffold constraints around the agent: automated testing, planning in advance, comprehensive documentation, automated formatting and linting, and manual QA.

Don't get me wrong, I started vibe coding after reading Karpathy's post. I got the memo - don't review every line of code, don't stop it when it stumbles, let it recover on its own, trust the process.

But after some experience I realised I need to Constrain the model, it is like a karting track, those tires put around it keep the carts inside and safe. It's our job to set the constraints. So maybe it's "constrained agent work" not "vibe coding".

I go as far as saying the constraint harness around the agent is the new code, we can remove the code and regen it from the constraint harness and docs. What matters now is to build tests and constraints around AI work.