ZH version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
69% Positive
Analyzed from 2098 words in the discussion.
Trending Topics
#code#more#claude#software#feature#engineers#don#using#client#lot

Discussion (55 Comments)Read Original on HackerNews
Both have been replaced by "vibe" coding. It works well. Everyone's happy. People are having fun with it. We get feature requests, improvements, ideas, feedback. JIRA tickets get created, and we ask AI to reference that ticket, code to it, and create a PR.
We have senior engineers review the actual functionality and none of them have read any more than a few lines of code.
Every person who builds like this has the same DX (developer experience): "Wow, I've been wanting to build this thing for years now. I just never had the time to do the things I wanted to do to help me and the teams that depend on us"
Total cost of AI subscription per month: Less than $1000. Preference is Claude Opus and Codex whatever the latest model is. Effort is a personal preference since it does not seem to matter.
> none of them have read any more than a few lines of code
So what do you / your team do?
> We get feature requests, improvements, ideas, feedback
So maybe I misunderstood, but it sounded like the design was external (and based on an existing product to begin with).
Also, my understanding was that "vibe coding" meant more of "make it do X" as opposed to "here's a design for X, implement it."
AI is an imprecise "programming" language, full of ambiguity (English) trying to produce precise relationships between different concepts.
It certainly works great on small scale, building block type of things, but the more a project grows in complexity, components, interfacing with other heterogenous systems in other languages or APIs, understanding wtf is going on top to bottom.... it fails miserably.
Reminds me of how xUML was going to be the panacea to replace coding. AI is failing for the same reasons. At least with xUML you have a precise definition - with AI, you're vibing your way into one.
This is a fun webpage, and it feeds a certain bias, but there really isn't a "niche" beyond getting people to upvote it for the lulz. I would be extremely surprised if they find a single paying customer. And to be fair, lots of grifters have done the fake it till you make it act on HN, so someone saying "Oh I'm totally going to give them my corps code" convince no one.
>It certainly works great on small scale .... it fails miserably.
If your large system isn't the interactions of a lot of "small scale" projects, you are doing it wrong.
No seriously, it's bizarre how people keep using this as their defence against AI, and at this point it's basically saying "Sure AI works on good projects, but it doesn't work on our giant spaghetti code monstrosity cludged together in a million terrible ways"
I've had tremendous productivity using AI on some enormous and extremely complex projects, courtesy of modularization, separation of concerns, explicit APIs, and so on.
The problem I've had with AI systems is that they eventually realize it's possible to solve a problem by linking together two separate systems in subtle ways that result in spaghettification of good code. It takes active effort to get them to follow strict separation of concerns and modularization.
I understand that it’s probably impossible to sell non-AI-assisted solutions to AI-pilled companies (even when their headaches are AI-induced), but my gut reaction to “take an AI-inflated codebase and apply AI deflation to it” is something like “that’s akin to applying two rounds of lossy transcoding; the errors don’t cancel out, they cross-multiply”.
So workflow for a full web app is make e2e tests for all use cases. Then add a very strict duplication checker, and linter, and then just tell the ai to hit a certain duplication limit like 3%, check the linter, and add unit tests to ~95% or greater of the code.
With the right CI and other checks that are deterministic you can really do a lot with a codebase.
There is a new kind of task for software engineers these days. A client calls, asks for a "small refactor," and sends you 100k lines of AI-generated spaghetti.
And this is great! This is something we can work with.
Any experienced engineer can look at a codebase like that and quickly see what to refactor, where a library replaces a few thousand hand-rolled lines, and what smells bad. Removing the first 30% is easy. The next 30% is harder, and that is exactly what the price should be on: doing what others can't. We use coding agents too, of course, but as a tool, not as the driving force.
That is why we started Slopfix, a software house focused entirely on refactoring AI-generated codebases. We commit to a reduction target up front, and the client pays in proportion to how much of it we hit. We get paid to delete code.
I am sharing this because cleaning up after agents with 1M token context is a real business for engineers. Curious what HN thinks.
A common way to market to these firms is to be very easy to find when their software starts to have serious issues.
[1] https://www.laputan.org/mud/
Well but something really is something totally new. Github went from x commits per year in 2025 (when AI-slop was already being pushed to Github) to the same number of commits in four weeks in 2026. 2025 compared to 2024 was already something like 15x.
It's never happened in the history of computing that so much new code was produced so quickly.
My bet is we'll see much more of this. And these aren't going to be 100% AI-pilled companies solving these issues but companies like the one in TFA: experienced devs using the help of LLMs to fix slop.
My other bet: slop shall outlive COBOL and dwarf COBOL's legacy big times.
> we distil what it does
FYI, "distill".
Its the same as it ever was. Cleaning up after cloud migrations, cleaning up after crypto integrations, cleaning up after LLM tokenmaxxing. I think people are deluded if they tell you LLMs will replace humans.
90% of my work is to run code review workflows and steer his CLAUDE.md into the correct architecture choices and away from past mistakes.
So far it's working pretty well -- I'm able to unslopify the code and maintain the agent's performance. And the CEO is happy, he's able to develop his product pretty fast and not hit any walls.
What your markup on their salaries? For the level of work you're promising, it sounds like they may be at market or below.
A salary like this is only a big compromise if you live in a very high cost of life area.
Honestly, the code we write with AI is cleaner, better documented, better factored, more maintainable, and less bugs than back in old days before code assistant agents. I think people must be just yoloing it, because it seems a lot like a holding it wrong type problem.
Documentation driven development is your friend.
Previously, I would need to do the trade-off calculation. How urgently does this need to ship, and do we have time to rework this? What are the deal breakers that need to be addressed, versus what things are best practice/ideal for maintainability? How did their last code review go and do they need a small win right now?
There's no more "nit" comments tagged as nits: just things to fix. It's de-personalized in the sense that we can both at least pretend/have plausible deniability and blame the model for being dumb, as opposed to the person making mistakes. I flat out told someone that a PR was not solving the right problem earlier, and neither of us thought it was a big deal. I could give the technical guidance and suggest a path forward to "help Claude understand better".
I had an interesting conversation with a junior engineer who made this observation. She shipped a feature, we gathered data, and based on data we pivoted to a different design. She called out that she wasn’t attached to the code because AI wrote it. Not that she didn’t care about quality or effectiveness of the product, but the personal emotional attachment to the code itself was not there. Probably a healthy thing. I’ve seen senior engineers defend mediocre code because they wrote it and changing it was an ego hit.
Problem is that you can't do a FOMO-fueled hype IPO that gets a trillion dollars if your argument is "this is a tool that can improve the quality of work your employees output".
It needs to be a "we are building a doomsday weapon here, give me money" argument. Even if it is false. Especially if it is false.
You always have to remember to tell the barber "No mistakes", just like you have to tell Claude.
Commitment ain't what it used to be.
Sounds like you forgot to have the agents use red/green TDD and build a robust test suite while they were shipping all of those features.
something's off here
> Then we [perform the act of] cut[ting]: [thereby,] the fourteen date formatters become (i.e. are replaced with) one,
If the client hasn't invested in setting that up, the resulting situation is the clients' responsibility.
And let’s say you’ve been hired, what happens after that? You think Claude.md file is sufficient to progress from that point?
The problem is real, but the solution is a fantasy.
> No cookies. No tracking. No JavaScript. Real people.
haha
But the true cost of minds, not AI assisted minds, is probably higher. They may have found a pricepoint which scales.
Imagine a future, where people get jobs to .. "write code" (in hand quotes) based on specifications "written" by machines..