Comment by hollowturtle
7 hours ago
I'm pretty you wouldn't want the same for code that runs healthcare, banks or transport. Only useless shitty web projects could embrace what's you're saying. And no there's no "Claude review the code and improve it" magical formula
I work in the health software space and there are tons of internal tools which aren't production code that can benefit massively from throwaway "write-only code". Putting a web UI on top of a management CLI tool so support ops can run things without needing an oncall engineer can be a huge win. I recently built a testing UI that doubles a demo-scenario-setup tool. Is it well-engineered? Who cares - it pokes the right things into the database and runs the right backend tasks, and has helped me catch and fix dozens of real bugs in the UIs that customers see.
There is an enormous untapped market for crappy low-effort apps which previously weren't worth the time - but with the effort so low put together a simple dashboard or one-off tool it becomes much more attractive.
> internal tools which aren't production code that can benefit massively from throwaway "write-only code".
First of all internal tools just prove my point. Second can't wait to hear a story of a health care production database blown away because someone was playing with generated tools that "pokes the right things".
We NEED end user experiences that don't suck, and don't keep getting shittier like now, not being able to use a cli for internal tools, it's a skill issue, not everythint needs a shitty ui that taps into an os system calls and blows away as soon as the cli responds with something unexpected
You still have to do the engineering parts of software engineering, you can't just turn off your brain and vibe. Just like you can't with hand-written code. I've seen what an intern with access to prod DB can do.
For example, the testing tool I built explicitly doesn't work in production environment. That was part of my design spec and I manually verified the code and behavior.