We replaced a 120,000 USD/year low-code/no-code platform that was running a lot of workflows. And we have another platform that is also similar that we are on track to replace by EOY.
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.
This industry's complete outsourcing of its core business value on a third party proprietary subscription based tool, Claude, made by an unprofitable company, Anthropic, is very concerning. You are all lunatics, sorry.
You seem to be referencing as core business value a combination of (1) the ability to maintain a (2) business criitical resource, but stating it as if catastrophizing from a hasty generalization. Can you clarify?
It's really not that simple. A lot of what's involved is fungible. Of course, the answer to "Was the greatest intelligence harnessed to make the greatest decision?" Is always no.
AIs can be swapped for one another, run locally, and implemented in ways that are less prone to loss of function. Loss of anyone who understands the working code is a type of risk, but that kind of issue tends to bounce between losing skill from lack of foresight due to economic savings, and overhiring / bringing back lost employees as consultants.
I don't follow this line of reasoning. Would it have been meaningfully different if OP had used open-weight models like GLM or DeepSeek? Does it really matter considering we'll have superior models next quarter?
The meaningful difference is that you will not experience EOS if (when) anthropic/openai/etc fails to become profitable and is no longer subsidized by capital funding.
While "vibe-coded" apps do help lots of people who didnt have the time/money/skills to create their projects, you should be aware that currently the compute is being subsidized so that users become reliant/used to the service.
I believe vibe coding in general is a bad business strategy whether you use FOSS models or not because it means your product probably doesn't have any "secret sauce" (leaving code maintainability problems aside). By that I mean a carefully researched innovation that gives the edge to your product. Nevertheless, using FOSS models is clearly better for the reason you mentioned. I believe serious businesses will transition into using AI on-premise in a very restrictive manner (eg: AI only for tests and reviews policy, etc.). We'll once the dust is settled.
Internal business tools are not innovative products. The potential edge comes from things like being better aligned with the business process or eliminating tasks from the process.
You can inject "secret sauce" through your domain knowledge or life experience.
You could vibe code the "tedium" out of your app with little to no care about it using AI while paying close attention to the critical aspects of your product. Of course, the fact that all of your AI code usage is being monitored by the company that provides you the model/harness is also still means they can just steal your product whenever they want
Stricter use would remove the primary benefit while not really giving much upside so I don't think companies will move in this direction
> Of course, the fact that all of your AI code usage is being monitored by the company that provides you the model/harness is also still means they can just steal your product whenever they want
Also anything which isn’t kept private can quickly be cloned. I think it’s going to be hard for a SaaS to stay profitable unless there’s a real-world tie-in to keep someone from pointing a bit at your app and cloning the observable behavior with just enough changes to claim they didn’t.
The question is if your "secret sauce" will stay secret as you use Anthropic's products, considering they've been launching specialised models like Claude Legal and Design. What happened to Figma with Claude Design should be a warning sign.
Put on the hats of a risk manager or supply chain manager. Yes, that would have mattered. What you insource today, you can repeat tomorrow. If you know the price of an input will multiply in the near future, you should at least develop processes that can handle disruption. If you expect dirt cheap LLM’s to remain available, or even better: improve in quality, feel free to make that assumption explicit and keep using the external supply. I don’t know what the future holds, but the vibe your software organizations cannot go back to manual development once LoC has exploded. I hope firms are making these choices deliberately.
You know, that question should trouble us more. But honestly we've all asked ourselves that same question and I think our collective response is too nuanced to try to type properly but I'll try.
Tools are always made out to seem like the human could be replaced. We've seen that every time some new technology comes out that some people claim will replace humans once and for all! But this does not seem to be true.
What AI coding allows us to do is get rid of just 1 or 2 parts of the job: coding and debugging. The rest of our knowledge based job is still there. AI just speeds things up because I can now ask it to code something while I go help plan or design something with a colleague. Most of us at this workplace also have a very good eye for UI design and system design patterns, so when we prompt/query the AI, we can understand what is happening. That isn't a replacement, that's more like getting a team of engineers who can do different things all in service of a larger goal.
Our conclusion was that we should not be concerned what search or queuing algorithm or data structure is being used. And to be perfectly honest, and I know that this will rub some in the wrong way, a lot of development since the 90s have been around object and graph management. For the 1000th time, I just do not (and most engineers I work with) care how an object is serialized and deserialized. Just display it on a table for me, why are we spending weeks coding a list, adapter, transformer, JSON/XML/whatever, networking calls, networking nuances, etc. etc. when I just want to get our customers seeing that list and move on?
I don't know if I did a good job covering the nuance, AMA!
> Our conclusion was that we should not be concerned what search or queuing algorithm or data structure is being used.
Not to be too snide, but if that's your reductionist view of the work of software development, I'm not surprised you're comfortable vibecoding without a human in the loop.
Thank you for the thorough reply! I also appreciate that you recognized my question as good faith (and my apologies, based on other replies I should have been less brief to avoid misinterpretation.)
It seems my definition of "vibe coding" was wrong after all, at least in this case, and that you're still doing design. My initial read was that this was fully AI-powered, and while that sounded interesting, it did leave me wondering what the humans did :)
This is absolutely my experience. And I'm commenting on HN a lot more now too - but in between, I'm doing competitive analysis, trying out a fix I implemented or a feature I added, marketing, talking to friends about their bug reports...
I disagree. Shipping has always been the fun part for me. I have been a DEEP engineer, and I love figuring out creative and deep optimizations, but writing them was never fun, designing them was. Writing the code has always been the least enjoyable part for me.
I love coding, or rather I love what coding allows me to do which is build and ship. That’s not be saying we abdicate any responsibility and yolo all our code but coding was _always_ a means to an end.
See also debates between high/low level languages.
You might as well say “real men/women only write Asm”.
>writing code is the actual fun part of the job though.
You mean typing the actual code into the editor is the fun part for you? For me, the fun part has always been "cause computer to do novel things", and actually typing/compiling/debugging the code is just a speed bump on the way to something fun.
i mean solving a problem with code that came from my own brain.
the act of typing is trivial and second nature, like breathing. but going e2e from brain to keyboard to editor to working product..that’s the thrill. and it’s dead.
- What you do at Initech is you take the specifications from the customer and bring them down to the prompt engineers?
- Yes, yes that's right.
- Well then I just have to ask why can't the customers take them directly to the vibe coding software people?
- Well, I'll tell you why... because... engineers are not good at dealing with customers...
- So you physically take the specs from the customer?
- Well... No. My secretary does that... or they're faxed.
- So then you must physically bring them to the software people?
- Well... No. ah sometimes.
- What would you say you do here?
- Look I already told you, I deal with the @#$% customers so the prompt engineers don't have to. I have people skills! I am good at dealing with people, can't you understand that? WHAT THE HELL IS WRONG WITH YOU PEOPLE?!
My guess is design (features/functionality, not code). When you don't have to write every line of code and you can quickly iterate on features, you have a lot of freedom to dial in what you really want out of an app.
Sorry, I was trying to be glib by putting "vibe" in quotes, because I think that term is used for people who have zero experience in software engineering, but when used by senior engineers, it's something else. But, I don't know if some populations would still call it vibe coding.
The design is external in that the requirements come from external customers or internal customers (since these applications) are used by both. We're not trying to duplicate or replicate any existing system, but I can't confidently say that I'm not drawing from any prior art.
Makes sense! My mistake for assuming it was the former definition, lesson learned.
Hopefully soon our industry will align on some standard terms. I feel like "AI-assisted", "agentic coding", "vibe coding", etc each have a few different meanings already.
YES!!! Very well said and captures what I was trying to convey.
There's also certain features of an application that most of us engineers know how it works or how to do it, but it is just so painful to do it by hand. Or other features that you've always wanted because you saw another app do it and it was beautifully done and you can just "have" that feature in your app too.
The joy is in seeing the feature come alive, not so much in fighting the computer.
This is so funny to me, because I know it's asked in earnest but seems so obvious to me:
They get actual work done.
Programming isn't work. That's just a means to an end. A tool to get the actual job done.
At least in most orgs. Obviously there are exceptions - but the vast economy is not a bunch of software companies. It's companies doing things to build a physical product, and software is a relatively new annoying side quest/cost center.
It's interesting how people view software as a distraction and an annoying side quest/cost center, but never apply that to, say, 90% of what management does. None of that "directly" makes money either!
That tells us a lot more about the leadership and management philosophies at modern companies than anything fundamental about what kind of work actually matters.
Eh it's nothing new. Outsourcing comes from the same spirit.
Perversely I find myself increasingly blaming the growth of product management divorced from engineering as the source of some of this.
Everyone wants to be the next Jobs, but somehow they missed that it was the marriage of high quality design and high quality engineering that got Apple where they are today.
Rather, the lesson they learned is that PMF and UX and yadda yadda yadda are all that matter and coding is just a means to an end.
It'll be interesting to see how many companies discover that you can't achieve those ends if you build on a broken foundation.
Face it - it's because developers are annoying princesses. Just read your comment again.
My entitled friend was whining AI will start monitoring his work and he won't be able to slack as much as he does now. Basically he'll have to work like everyone else. FFS.
I think programming is work, but I get your point :). And yes, of course - I'm mostly just curious how peoples roles at various companies are evolving as they hand off more and more to AI.
I meant - create useful work product. For most companies software is a means to an end. The programmer writing code isn’t useful, it’s the end result. A lot of small to midsize companies employ a couple software guys out of necessity, and the results are usually middling at best. It’s a problem IT in general has really failed to solve very well.
I say this as someone who has picked up and put down “programming” as I needed it. It’s never been something I’ve gotten any satisfaction out of by doing, but I get huge satisfaction out of the resulting product or workflow automation or whatnot.
For my uses, if I could replace my programming and IT time with a robot I would - since me being in that role just slows down delivery to the end user. One of my first hires as a small startup was a programmer - specifically because I knew I rather sucked at it and what a pro could get done in a day took me a week. This is why AI for the low value/less complicated automation tasks is extremely compelling to me.
I’d immediately have 20 other things to work on to soak up the time savings!
It's really quite interesting how there are always posts on HN with people talking about how AI made their life great, did it cheaply, made a great product, and saved the day. But whenever someone asks for specifics, the questions are always dodged or answered very vaguely. It's rare that anyone ever even says what their product does.
To be fair, thraway3837 posted a reply on a sibling comment and offered "AMA" :).
That said, I do see a lot of those posts you're talking about, and I think a lot of AI development is way overhyped. But I also think internal tools like this can be a good use case.
Personally "none of them have read any more than a few lines of code" makes me wary, but if it works for them, then so be it!
I have Claude work on web app testing scripts written in java using JUnit and selenium. The scripts test a vibe maintained flight booking app for an airline I can't mention without doing myself. The app is maintained using copilot by another vender. Claude was given to our team by our employer. We aren't even employees of the airline just contractors under a vendor. Before Claude was adopted everyone secretly used whatever chatbot they preferred. I used opencode with Deepseek v4.
I'm happy to provide specifics, within reason, of course. Ask away. I've since responded to comments with more detail, but if I missed something there, let me know!
“Maintainability” is probably the word you are really looking for. Few devs care whether something adheres to whatever as long as we maintain:
- user experience/expectation (i.e., if feature X worked three years ago, it still works in a consistent way today after a bug fix)
- development cadence (if implementation of feature X took N days, a comparable feature Y should take N days)
- sanity (can we assume that a fix going in Thursday night or Friday morning doesn’t wreck the weekend)
SOLID, DRY, ACID-compliant, linted, formatted, clean, functional, compositional, etc. May be the means (misdirected or otherwise) but they are not the motivator(or at least should not be).
What matters is whether the day two feature requests, bug reports, CVEs, and traffic load that are coming can be met on time.
Not saying it can’t be done without a developer at the helm, Anyone Can Cook™, but I guess it depends on what harness is in use or has created for the org, and whether that consideration is baked into the guidelines for the codebase (which seems to be, at least to some extent, what this service tries to course correct).
And of course, what is done to the process when incident x happens, again and again. Are we only updating code without paying attention to process that enabled it in the first place?
Maybe that’s the story of vibe coded repos: the code devs were removed but we really still need devops personnel. Also maybe new tech will be more readily adopted.
Yes, I'm familiar with these talking points. I didn't mention clean code or solid or frameworks or anything like that.
However, the poster explicitly said they don't do what you said (EDIT: I misinterpreted some of these):
RE "talking to customers"
> 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
RE "figuring out whether it's actually working for people"
> have senior engineers review the actual functionality and none of them have read any more than a few lines of code
RE "figuring out what the heck to actually build"
> replaced by "vibe" coding
Maybe my definition of vibe coding is wrong?
--
In any case, I don't have some ulterior anti- or pro-AI motive. I'm genuinely curious why and how a project run this way has humans in the loop at all.
Sorry for the confusion, we talk to customers both internal and external that drive these feature requests.
We ultimately decided that paying for low code/no code platforms was pointless because that's what AI coding is. 90% of the time, we don't even have VS Code open and just gloss over the diffs in the PR.
I honestly don't know what the trajectory of those low code/no code platforms are going to look like. Are their senior strategists looking at the landscape in the last year and going "oh. no. What is the point of our product anymore because what's the point of people dragging and dropping no-code connectors to build an application when they can get 100% portability and transparency by having code generated by AI"
I used CF Wrkers because I wanted to try serverless(1) - I just needed a tiny https proxy for one of my personal scripts and.... It turned out to be super fun.
And no surprise bills.
(1) after my earlier experience with AWS lambda - almost no traffic (few requests per day), on free trier and YET I had to pay for the add-on they automatically added (and it took me almost 2 hours to find all the rhizomes that were proudly anticipating another few £ for pretty much zero traffic).
We did at my work. We were paying too much for low code orchestration software. Replaced it with vibe coded workflows. Still have some infra costs but it's fantastic, cheaper, more velocity, and everybody is happy.
> A SmartBear study of a Cisco Systems programming team revealed that developers should review no more than 200 to 400 lines of code (LOC) at a time. The brain can only effectively process so much information at a time; beyond 400 LOC, the ability to find defects diminishes.
...
> SmartBear research shows a significant drop in defect density at rates faster than 500 LOC per hour. Code reviews in reasonable quantity, at a slower pace for a limited amount of time results in the most effective code review.
No, I really meant that we don't even read the code anymore. In another comment I wrote: we just CMD+Q VS Code and it's not even in the recents/pin to dock, since what's the point? We can see the diffs in the PR and quickly gloss over it and query/prompt/ask clarifications.
It's easy to believe if it's 5x $200 subscriptions.
Paying by the token is insanely expensive. Only the
5̵ ̵R̵i̵c̵h̵e̵s̵t̵ ̵K̵i̵n̵g̵s̵ ̵o̵f̵ ̵E̵u̵r̵o̵p̵e̵ Biggest Tech Co's can afford that.
But the subscriptions are cheap honestly. Yeah they say it's not for enterprise usage but ok whatever. Not paying $10k when $200 gets you the same value (seriously)
I have always felt that AI will be much like how we all now have a calculator in our pockets (despite our math teachers telling us that would never happen lol). For math yes one could sit and do long division and multiplication and so on but having a calculator as a tool obviously makes things so much faster. But you still need to have the knowledge of how math works like the order of operations for it to be correct in the end.
I picture AI coding being the same. Ya someone with no coding knowledge can probably vibe code a small project and have it work. But more complex projects I picture AI like the calculator speeding up the work but in the end one must still understand programing and be able to ensure that the code is correct for the goal.
The main difference is (simple) calculators are deterministic and monotonic. Meaning it executes a set of instructions in a predetermined way to produce its output. Bringing LLMs to that level is a whole another ball game. But we'll see, perhaps the arithmetic nature of algorithms will be replaced by a whole lot of tensors in the near future.
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.
Our outcome is also AI-generated (or AI-assisted) code. It is not possible to rewrite 100k loc in a week. Where our stills are is refactoring at scale with help of agents. Basically, software engineer knows better what prompt to put, and when to redo the process or go different path.
> I don’t think this is anything new, really: Businesses have been running software that we’d call a “big ball of mud” [1] forever.
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.
Most of the new Github bloat will just be thrown away. Vibe coding scratches an immediate itch and it's easy to do. Once the problem changes nobody is going to update the first project because that's hard, they'll just vibe code an entirely new solution leaving the first to rot until they delete their dead repo clutter or move on from the company and the account and all of its repos are deleted in one fell swoop.
We don't target software developers. Most of the time, they know their craft. We target those who don't have experience and diging into how serwer should be implemented, or best composition of a domain model is not what they would like to sepend hours doing.
The typical client is a 40 years old ex-CTO, that had idea, verified it with Claude Code and got to the point, where the repo is too big. Maybe even rewrote it all from zero, once or twice, but end-up with the same outcome after adding more features.
He can either hire a developer to work on the codebase and refactor it or hire 3party company.
Sometimes the requirement is a security review. And you pay much less if you downsize the repo before handig it over.
The copy on your website itself kind of reads like LLM slop (eg. "One week. Three senior engineers. $10,000"). You may have written it yourself and marketing copy just tends to look like this, but it doesn't inspire confidence that your service will actually improve my code.
No shame in using Fable to help with the grammar and style of text. English is not my native language and while I can use it quite well, LLMs are much better in forming my thoughs into something simple, that sounds great.
My writing workflow is: (1) write what I want to have on the page. (2) /grill-me it should be sound and logical and easy to read. (3) Manually review the text, replace by hand what I don't like.
There is also a flip side of this. I work a lot with AI-generate text and I can also catch it quickly, but most of the time now, it's easier to read AI, than humans with their weird chain of thoughts and compex sentences ;P
Initial AI scan can list most of system usecases. Then we review it with a client and agree on what must stay. We can propse better solutions at this stage. If we remove the code, then we can also remove its unit tests. For intergation, repo-wide tests, we treat it as documentation/requirements that must work on the other side.
Human to human interaction is the tool we use the most :)
>I am sharing this because cleaning up after agents with 1M token context is a real business for engineers. Curious what HN thinks.
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.
I worked with such an "enterprise code" in the past. LLM code is a bit different. For example you don't see code repetition in the same file very often. I'd say it's a next level of slop. Slop at scale!
If unclogging the sewers is a way how the deluge of AI slop can create new work, then more power to you! It's one more element that makes it even harder to write satire that is more absurd than reality.
I guess it was only a matter of time before this niche of business developed.
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.
I can't agree with saying ai is failing, I mean if you work at a company with a lot of software engineers it can be true, but from what I see it's mostly non technical companies that adopt vibe coding to address technical problems. It's just another form of outsourcing
> I guess it was only a matter of time before this niche of business developed.
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.
> 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.
> It takes active effort to get them to follow strict separation of concerns and modularization
100% agreed. AI tools are a multiplier for experienced, conscientious developers who pay attention. Bad developers can still make bad code with any tool, and AI allows them to make more bad code quicker.
This is the gotcha here and the solution is to tell it how it should architect the software and what integration points it should use. But if you clearly define integration boundaries, the success condition, and a few other small details, it generally does a pretty good job.
> courtesy of modularization, separation of concerns, explicit APIs, and so on.
That's great, but a lot of that is knowledge you have to bring in. You need to be careful with the design of the API boundaries, the interfaces, etc.
Lots of people who are using AI to code projects... don't do that.
And once you get to the point that the AI is having trouble keeping up with the project... it's going to take a lot of work to discover what those module boundaries and interfaces should be.
Lots of small moving parts that build up into a large architected platform, which requires careful design, otherwise you get a big ole ball of "it mostly works when we first created it but don't touch it". And yes, bad developers are susceptible to creating the same thing. That's the whole issue with vibe coding, it creates something that works, but is brittle, because there are no strict architecture requirements around the entire design besides vague suggestions like "follow best practices", and as it makes mistakes, it just patches whatever it can to make it work, instead of fixing the root problem with the design.
Ask almost any software developer in big tech about their software and I’m sure they’ll praise it. Using it is a completely different story. I’m sure you think you’re having success vibecoding enormous and extremely complex problems, but I’d bet their either not extremely complex or it’s not working as well as you think.
This is misreading the original reply. An enormously complex problem is different from an enormously complex project. Complex projects can usually be decomposed into tasks of varying complexity, some of which I bet an LLM helps with.
Ahh yes the “you’re holding it wrong defense”. Now i ask what enormous extremely complicated projects…excuse me by projects we mean real production software with real scale.
Sure, it can poke one system or another but even with opus and now fable, it very quickly hits the limit a limit that tracks very closely with context window.
This is to say that no amount of harness tool skill is going to cover that fundamental gap. If your change fits in context, good chance it will work.
Tools have limitations and ideal uses. If you hammer a nail with a chisel, you're probably going to have a bad time. If you build a home and don't level the joists and studs, you're going to have a bad time. If you use an impact wrench on the wrong part you can cause enormous damage. And so on.
Yes, "holding it wrong" is a legitimate thing people can discuss. Similarly it's funny how often people want to talk about "vibe coding", when that is quite simply the opposite of what I am advocating, but it has become a fun slur.
> Now i ask what enormous extremely complicated projects…excuse me by projects we mean real production software with real scale
Every large project on the planet is using AI tooling now, so this sort of gatekeeping has gotten almost sad. Like there's another guy in here leaving some worthless troll comment and they literally created an account on here four months ago purely to run around shrieking and telling everyone that AI is useless and it's all a myth. The desperation is palpable.
Good large projects generally are the combination of hundreds to thousands of small, fairly defined and isolated sub-projects and modules and contained classes with well-defined entry-points, and so on. Using AI on projects like that, where the non-vibe developing, skilled developer is asking for concrete, audited changes on those modules, is hugely useful. It's far more of a crap shoot if you don't understand your own code base and broadly demand that it make cross-cutting changes.
I never said ai was not useful nor that it cannot be used on small parts. The issue is size.
I think you are projecting other people on to me with is counter productive.
Slop and vibe coding are valid. It is specifically for describing crappy ai output.
You still did not give specifics which is usually the case when pushed on. I will give you some, when there are well over 20 languages that span multiple applications which all can depend on one another in same way, bazel builds from hell. Ya ai cant do it.
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”.
NGL I'd argue there's a certain appeal to "use AI to prototype a feature as fast as possible and focus your engineer hours on building a comprehensive testing and fuzzing plan" followed by a "remove and review everything that can be cut without breaking the tests" cleanup pass.
I do see the appeal, it’s easy to imagine that workflow working, and working well - but it’s hard to how it avoids this fate: https://youtu.be/QEzhxP-pdos
You're describing a problem that's plagued corporate software development for decades. You just get to the "unmaintainable ball of mud" stage faster now. Every few days I spent a while on codebase architecture improvements after landing a slew of features.
Thanks for writing this. In my refactoring process I also start with code profiling. Opus is good, at finding hand written code, which sometimes is a good starting point of understand the codebase in general.
Ngl I’m doing this right now for a client. Part of my strategy is to write out e2e tests that get a certain baseline of functionality, and then use that as the check for any change that I make to the codebase to make sure it continues to work.
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.
I have also experimented with mutation testing. But the side effect of this approach is that it keeps public interfaces intact, and most of cases you don't want that.
the claude giveth and the claude taketh away. I could definitely use claude in a tightly directed manner to clean up a slopified codebase (and I would enjoy doing so), you just need to think of it as closer to a power tool than an agent.
My experience as well, I've been developing a native macos app using CC. As a web dev I didn't know much about the stack. Nothing too fancy a kind of folder gallery-player with tags embedded in filenames, a bit like TagSpaces.
Process was - produced a detailed feature spec - multiple iteration of "I want this and that", make it into coherent spec", "this this and that is not correct, change to that". Made it write architecture spec(which I didn't read because too unfamiliar) and split it into tasks. Then it was implementing tasks, after each I did a change/fix those ~10 things iteration and spec corrections.
It was good to a point, but then when I started to hit performance problems I had to step in look at the code, and very often fight with CC, confront its "this is the only way", force it to do web search for proper ways to deal with problems and even explain very simple things about proper DB usage.
At some point it asked me something like "is it ok for schema migration to just fail or we need to implement complicated handling?", I have answered "it just shouldn't leave app locked in schema failure", and guess what was CC solution? - it wrote an error handler which just drops DB and recreates fresh one on ANY schema failure. And if I didn't happen to peek at the code and ask wtf it is doing, that would've been an exiting UX.
I've spent about month's worth of $20 CC subscription tokens using Opus 4.8 on xhigh, AND about 70 hours of my time to get it to a point where it is good.
So "anyone can just code what they want now" is correct only to a point, MVP will work, but beyond that experience will be subpar, and it still needs lots and lots of iterations of explaining what you want. Then because normal user knows very little about how software works they won't be able to ask AI the right questions, confront it and rate of improvement vs token usage will hit rock bottom.
People keep making this analogy not understanding that trades folks will use the right tool for the job, not just whatever is newer / more advanced. Air nailers exist but hammers are still used. Drills can screw in screws but screwdrivers are still used. You wouldn’t use an electric drill for a lot of jobs. People will also try to equate it to an electric saw vs hand saw, but again time and place for both.
I’m not discounting that other tools are to still be used. My reply is to the OP that was saying that quality gets worse applying an AI by an expert to an AI coded project. Time and place for both I agree.
lol looks like they are using a similar methodology to how we use Claude in house.
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.
with AI, documentation driven development is an understatement, if you take the time not just to document but to also provide lots of examples and potentially even data structures for the implementation (including intermediary data structures if you know them) the output is better than anything you would make in reasonable time.
If you have done or are doing all of that, why not just use the code you’ve made inside your docs?
Like, are you using languages where data structures are hard to write and/or work with? Typescript, Kotlin, Python and Ruby (via Sorbet or DryStruct) are all really easy to write all those data structures and code.
what I meant was dictating the data structures for the code (transformations) the LLM is going to write.
"Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowcharts; they'll be obvious."
in my workflow I typically prompt the LLM to carefully consider if the data schema I provided it is not sufficient for whatever task I gave it and to then argue for including additional members, with GPT 5.5 I took notice because of the arguments it provided me, it became clear to me that it's over. they have 130+ IQ. it's just a matter of constructing scaffolds now to have them express the intelligence because due to whatever quirks of training they can do stupid things.
Same here. Honestly, there's also a bunch of human friction that goes away. I can tell a junior that a change needs to be significantly refactored (or even thrown away entirely) without the psychological damage of discarding days/weeks of work from them.
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.
I have to admit that I'm curious why this is the case. I almost wonder if the pseudo-anthropomorphizing of these models is partially what helps here, similar to how I don't take it personally when I give instructions to a junior engineer and they fuck it up (though, I probably should to at least some degree more than I do).
Probably something about the personal time and effort invested in a thing. I would feel much less personally invested if, for example, I created an outline of a story and then paid a ghostwriter to fill it in.
The same reason we had them before? A few juniors can be productive with oversight and guidance. Half the battle is learning what good work looks like, and figuring out what it is that you should even really be building, and those are skills you develop.
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.
Nice domain name! I currently live on the wrong side of the Odra and cross it on my bike. Gorgeous areas and polish food is so much better than German :)
Some (lots of) people will trade a lot of money for general life freedom. If it's well-booked, a service like this can come to around 105k/year for each dev.
A salary like this is only a big compromise if you live in a very high cost of life area.
Being honest, knocking one refactor after another is super intense and we would burn out quickly. To me refactoring/reading/reviewing a code that you have never seen is one of the hardest thing to do for a software developer. If I have 4 such projects a month, I'd just hire more people and allow them to rest. Also invest more into internal tooling to speed things up would be good solution to remove some burden. I think $10,000 for refactor is a fair price.
We also have other gigs and ongoing project, where we can rest a bit.
This seems like a easy way to get into consulting. Once you deliver the code back to the owners they are going to do the vibe coding again on the top whatever refactored code you get back. In other words it can become a perpetual cycle.
The goal is to avoid it and build such a structure and guidlines for the codebase, so it can refactor itself when needed, but based on the architecture defined by us. With good set of docs and new feature definition you can most of the time use /grill-me with good outcomes.
Call me pessimistic or realistic, the code and architecture is just a reflection of the author/organization. The only way it can change/improve is if you either switch the people/organization or invest in their improvement/continuous learning.
I am currently working with a non-dev startup CEO that's fully embraced Claude Code and vibe coding.
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.
One week to both refactor a big code base and also make sure everything works as expected? Not the estimate I would expect from a senior analyst, too optimistic. Fine that you fix the regressions for free, but the last thing I want is a one-week refractory going to production and fire fighting later.
I have 15+ years of experience in software development. The hardest thing I had to learn recently is that paring with AI changes the definition of "what is hard". You can decomposit a refactor into a steps of two kinds:
1. Conceptually hard, which you have to really think about and write code by hand for AI to follow,
2. Time consuming that follows patterns.
Then you do 1. review with AI what are implications on the codebase. Next you crate list of task for 2. and keep reviewing outcomes.
This does still not include any QA. The fact that A.I. tells you the implications of your changes does not take away the effort and time you need to verify the correctness end to end
"Two weeks of warranty" jumped out at me. That's like "you have two weeks to find the thing we broke, or else we aren't responsible for it." In my experience, a good bug can hide for months more than two weeks! My codebases are definitely not in the target demographic for this service, though, and maybe if I were in the target group (bunch of LLM slop, trying to dig out of the hole, presumably no shipping product or existing userbase yet) the proposition would appeal to me.
This is a fair point. But these days bugs are not so scary anymore, so a client can vibecode a fix faster then getting me to fix it. Of course if Opus can't figure it out, I would always try to help. I have never left a client alone, warranty or not. This is just how I was raised.
Bugs can cause user data loss in production, or total system outages, or a slew of other Really Bad Things. How are you planning to vibecode your way out of that after the fact?
If the client has an extensive suite of automated tests assessing if the software is meeting its requirements, it should be possible for them to flush out most regressions within minutes or hours, not weeks.
If the client hasn't invested in setting that up, the resulting situation is the clients' responsibility.
15 years ago it was always fix price for undefined amount of work, 10 years ago it was agile where client was promissed something but paid per day.
I prefer the old way of doing things: do the offer for free, commit to a task, and accept, that it might not be a success after all. I'd just loose a week of work, but probably learn a lot.
> Then we do one week of focused work. Before touching anything, we sit down with you and write out exactly what your app does, screen by screen, endpoint by endpoint
While the whole thing is clearly a bit in jest … one might suggest that if a complete spec takes a negligible fraction of a week, then perhaps neither AI nor consultants were required
This prepartion is on us, but yes, client pays for the time he/she spends with us. You can't cut corners here, as human to human interaction is essential. During the whole process, client might be dragged into the developemnt to clarify things, or decide on some tradeoffs. No free lunch here as well.
But that's not the problem being highlighted in that quote you clipped out and responded to.
The problem that quote (and this entire post and the folks that produced it) is putting a finger on is that vibecoding makes it very easy to build large piles of brittle, entangled code where all those early velocity gains are paid back as evolving the codebase takes more and more time (and, crucially, tokens).
No amount of <insert methodology here> replaces good judgement about architecture/design that ultimately leads to more maintainable, extensible code. That was true before AI and it remains true today.
Now eventually AI may get to the point where it's autonomously generating code that's structurally as good or better than what any experienced human would create.
So far, IME, that is not yet this case and nothing can yet substitute for an experienced human in the loop to steer AI toward better decision-making.
And before it's said, yes, that also means humans made ugly balls of mud in the before time. That term obviously came from somewhere.
But that only proves that AI is as good as prior humans that did a bad job, which on the one hand is impressive, and on the other hand is deeply alarming when you know there's folks out there letting these things loose without any supervision.
Of course if all one is doing is tossing off and walking away from greenfield projects, man, vibecoding is magical. I suspect a lot of the "we never look at code anymore" claims come from this world.
We have been doing this for years now: it is great. We build our products faster and better and we get more money for fixing products vibecoded by others. More money in every way.
it's not about the prose quality, but about the fact that it seems like the service of deleting ai-generated code is also going to be ai-generated, or at least the service is being advertised via ai-generated text, which is…funny
I want it be positive, but it’s a bit hard with this one. Do you expect the client to sit down and explain every detail? If they know how to do that, they wouldn’t be having messy code base as the one the post is describing.
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.
We do the initial code review by ourselves, we try to run test, run the project etc. We compose a list of what we have in the codebase and what we think it does. We also preapre a list of what functionalites we would change.
Example would be removing service implementation that is bash code handling manually PID files, and replacing it with pm2 tool, that has quite different workflow.
I've thought about it and decided the animation wont do.
The page needs a generated video with giant cockroaches, mechs, 3 men in supper hero gear with swords & lab coats and there needs to be a puny human being saved. Then a dark voice narrating how the man created an unmaintainable mess using llms and that after a fierce battle that lasted a week he was saved by team slopfix. Beethoven symphony No. 5
Seems like instead of investing in this, just spend 1k every 4 months and have the latest frontier model rewrite the entire codebase from scratch but maintain things that are non-negotiables (like db tables, apis, etc).
I was waiting for the new spaghetti cowboys to arrive. Good luck guys, but keep in mind that a 1000 cores can do a lot more damage than 3 people can fix.
AI slop? Humans write slop too. We’ve all heard the stories, companies outsource projects to India, only to bring them back to the US for the local team to fix.
I saw it myself at a past job. We hired a consulting firm to convert a project. They outsourced it to India. In the end, we had to hire a US company to rewrite the whole thing from scratch.
I wonder if this is part of what's clever about pitching their consultancy as slop cleanup -- nobody's likely to engage them to work on a pile of logic that's been evolving over a decade with weird load bearing corner cases. The "I just vibe coded a massive tangle" situations are more likely to be newer.
At least, one could hypothesize. Perhaps incorrectly. :)
I wish these guys luck in finding their customer. Really. Because real solution to the problem would be to hire old-style developers to rewrite the whole slop from scratch without AI being involved. Fixing broken slop is Sisyphus's labor.
I mean, not really? The urge to throw all the code out and start over is what ever mid-level software engineer has always wanted to do, and it’s almost never the right choice. The old code worked well enough most of the time, it just didn’t have good or safe practices and those can be retrofit.
In fact, doing and directing such things are kinda senior, principal and management jobs, in general.
It actually is. What we fight for is being able to put as much percentage of a codebase into a context as possible. I'd charge for amount of tokens, but it would be harder to sell.
@zie1ony / OP - how do you make your clients believe you are not planting a crypto-locker or logic bomb or some other 3-letters-agencies "features"? And why would clients replace existing AI slop with your post-another-slop handwritten code? Do you check it for vulns and, most important, have you considered that later clients will sue you for <something their checkbox audit did not like>? Providing there is no major data leak, in which case you may end up proving your innocence from behind bars?
I remember implementing very complex cryptographic scheme in pure C. After a week of hard work, my friend concluded: "Cryptography would be much easier if people just trust each other."
The truth is that it is my reputation on the line, so I also have to make sure dependencies I use don't mess up things as well. There is no good defense against it. In my contracts I undertake to act in a good faith and take the responibilites to the amount of my professional insurance. Honestly, it is different casy by case.
$MY_STARTUP does — something — similar.
I — love — that — you — say — you'll — do — this — in — a — week, — and — then — a — two — week — warranty?
What — are — you.. replacing — an — engine? — Gotta — keep — that — head-gasket sealed — tight.
/s
Isn't this just called a consultancy with a super short contract term? How are you actually going to unscrew anything in one week?
We replaced a 120,000 USD/year low-code/no-code platform that was running a lot of workflows. And we have another platform that is also similar that we are on track to replace by EOY.
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.
This industry's complete outsourcing of its core business value on a third party proprietary subscription based tool, Claude, made by an unprofitable company, Anthropic, is very concerning. You are all lunatics, sorry.
You seem to be referencing as core business value a combination of (1) the ability to maintain a (2) business criitical resource, but stating it as if catastrophizing from a hasty generalization. Can you clarify?
It's really not that simple. A lot of what's involved is fungible. Of course, the answer to "Was the greatest intelligence harnessed to make the greatest decision?" Is always no.
AIs can be swapped for one another, run locally, and implemented in ways that are less prone to loss of function. Loss of anyone who understands the working code is a type of risk, but that kind of issue tends to bounce between losing skill from lack of foresight due to economic savings, and overhiring / bringing back lost employees as consultants.
I don't follow this line of reasoning. Would it have been meaningfully different if OP had used open-weight models like GLM or DeepSeek? Does it really matter considering we'll have superior models next quarter?
The meaningful difference is that you will not experience EOS if (when) anthropic/openai/etc fails to become profitable and is no longer subsidized by capital funding.
While "vibe-coded" apps do help lots of people who didnt have the time/money/skills to create their projects, you should be aware that currently the compute is being subsidized so that users become reliant/used to the service.
I believe vibe coding in general is a bad business strategy whether you use FOSS models or not because it means your product probably doesn't have any "secret sauce" (leaving code maintainability problems aside). By that I mean a carefully researched innovation that gives the edge to your product. Nevertheless, using FOSS models is clearly better for the reason you mentioned. I believe serious businesses will transition into using AI on-premise in a very restrictive manner (eg: AI only for tests and reviews policy, etc.). We'll once the dust is settled.
Internal business tools are not innovative products. The potential edge comes from things like being better aligned with the business process or eliminating tasks from the process.
You can inject "secret sauce" through your domain knowledge or life experience.
You could vibe code the "tedium" out of your app with little to no care about it using AI while paying close attention to the critical aspects of your product. Of course, the fact that all of your AI code usage is being monitored by the company that provides you the model/harness is also still means they can just steal your product whenever they want
Stricter use would remove the primary benefit while not really giving much upside so I don't think companies will move in this direction
> Of course, the fact that all of your AI code usage is being monitored by the company that provides you the model/harness is also still means they can just steal your product whenever they want
Also anything which isn’t kept private can quickly be cloned. I think it’s going to be hard for a SaaS to stay profitable unless there’s a real-world tie-in to keep someone from pointing a bit at your app and cloning the observable behavior with just enough changes to claim they didn’t.
The question is if your "secret sauce" will stay secret as you use Anthropic's products, considering they've been launching specialised models like Claude Legal and Design. What happened to Figma with Claude Design should be a warning sign.
Put on the hats of a risk manager or supply chain manager. Yes, that would have mattered. What you insource today, you can repeat tomorrow. If you know the price of an input will multiply in the near future, you should at least develop processes that can handle disruption. If you expect dirt cheap LLM’s to remain available, or even better: improve in quality, feel free to make that assumption explicit and keep using the external supply. I don’t know what the future holds, but the vibe your software organizations cannot go back to manual development once LoC has exploded. I hope firms are making these choices deliberately.
I think the comment said they were outsourcing it to "whatever".
> we ask AI to reference that ticket, code to it, and create a PR
> none of them have read any more than a few lines of code
So what do you / your team do?
You know, that question should trouble us more. But honestly we've all asked ourselves that same question and I think our collective response is too nuanced to try to type properly but I'll try.
Tools are always made out to seem like the human could be replaced. We've seen that every time some new technology comes out that some people claim will replace humans once and for all! But this does not seem to be true.
What AI coding allows us to do is get rid of just 1 or 2 parts of the job: coding and debugging. The rest of our knowledge based job is still there. AI just speeds things up because I can now ask it to code something while I go help plan or design something with a colleague. Most of us at this workplace also have a very good eye for UI design and system design patterns, so when we prompt/query the AI, we can understand what is happening. That isn't a replacement, that's more like getting a team of engineers who can do different things all in service of a larger goal.
Our conclusion was that we should not be concerned what search or queuing algorithm or data structure is being used. And to be perfectly honest, and I know that this will rub some in the wrong way, a lot of development since the 90s have been around object and graph management. For the 1000th time, I just do not (and most engineers I work with) care how an object is serialized and deserialized. Just display it on a table for me, why are we spending weeks coding a list, adapter, transformer, JSON/XML/whatever, networking calls, networking nuances, etc. etc. when I just want to get our customers seeing that list and move on?
I don't know if I did a good job covering the nuance, AMA!
> Our conclusion was that we should not be concerned what search or queuing algorithm or data structure is being used.
Not to be too snide, but if that's your reductionist view of the work of software development, I'm not surprised you're comfortable vibecoding without a human in the loop.
Thank you for the thorough reply! I also appreciate that you recognized my question as good faith (and my apologies, based on other replies I should have been less brief to avoid misinterpretation.)
It seems my definition of "vibe coding" was wrong after all, at least in this case, and that you're still doing design. My initial read was that this was fully AI-powered, and while that sounded interesting, it did leave me wondering what the humans did :)
No worries at all, I took your question in good faith :)
I also responded below re: Vibe coding.
This is absolutely my experience. And I'm commenting on HN a lot more now too - but in between, I'm doing competitive analysis, trying out a fix I implemented or a feature I added, marketing, talking to friends about their bug reports...
writing code is the actual fun part of the job though.
it’s a shame we automated that instead of the boring system design shit.
I disagree. Shipping has always been the fun part for me. I have been a DEEP engineer, and I love figuring out creative and deep optimizations, but writing them was never fun, designing them was. Writing the code has always been the least enjoyable part for me.
I love coding, or rather I love what coding allows me to do which is build and ship. That’s not be saying we abdicate any responsibility and yolo all our code but coding was _always_ a means to an end.
See also debates between high/low level languages.
You might as well say “real men/women only write Asm”.
This is the conflict we've entered. There is a good portion of the engineering population that considers coding fun.
The other side considers shipping as a feature.
I can both sympathize and empathize with this conflict.
To me the system design shit is fun as well, different strokes for different folks!
All those things (coding / distributing / design / whatever) WAS fan to you / us. It was. "The thrill is gone ..."
>writing code is the actual fun part of the job though.
You mean typing the actual code into the editor is the fun part for you? For me, the fun part has always been "cause computer to do novel things", and actually typing/compiling/debugging the code is just a speed bump on the way to something fun.
It's like doing a jigsaw puzzle. The fun part is the doing. I don't really care what the final picture is, and once it's assembled the fun is over.
i mean solving a problem with code that came from my own brain.
the act of typing is trivial and second nature, like breathing. but going e2e from brain to keyboard to editor to working product..that’s the thrill. and it’s dead.
> AMA!
I think I missed where you posted what business you work at
- What you do at Initech is you take the specifications from the customer and bring them down to the prompt engineers?
- Yes, yes that's right.
- Well then I just have to ask why can't the customers take them directly to the vibe coding software people?
- Well, I'll tell you why... because... engineers are not good at dealing with customers...
- So you physically take the specs from the customer?
- Well... No. My secretary does that... or they're faxed.
- So then you must physically bring them to the software people?
- Well... No. ah sometimes.
- What would you say you do here?
- Look I already told you, I deal with the @#$% customers so the prompt engineers don't have to. I have people skills! I am good at dealing with people, can't you understand that? WHAT THE HELL IS WRONG WITH YOU PEOPLE?!
Mostly post on hacker news.
Haha, I actually laughed out loud, thank you for that :)
Living the dream! Son of Anton provides.
My guess is design (features/functionality, not code). When you don't have to write every line of code and you can quickly iterate on features, you have a lot of freedom to dial in what you really want out of an app.
To be clear, I didn't mean this as an anti-AI gotcha. They also said:
> 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."
Sorry, I was trying to be glib by putting "vibe" in quotes, because I think that term is used for people who have zero experience in software engineering, but when used by senior engineers, it's something else. But, I don't know if some populations would still call it vibe coding.
The design is external in that the requirements come from external customers or internal customers (since these applications) are used by both. We're not trying to duplicate or replicate any existing system, but I can't confidently say that I'm not drawing from any prior art.
Hope that makes sense.
Makes sense! My mistake for assuming it was the former definition, lesson learned.
Hopefully soon our industry will align on some standard terms. I feel like "AI-assisted", "agentic coding", "vibe coding", etc each have a few different meanings already.
YES!!! Very well said and captures what I was trying to convey.
There's also certain features of an application that most of us engineers know how it works or how to do it, but it is just so painful to do it by hand. Or other features that you've always wanted because you saw another app do it and it was beautifully done and you can just "have" that feature in your app too.
The joy is in seeing the feature come alive, not so much in fighting the computer.
> So what do you / your team do?
This is so funny to me, because I know it's asked in earnest but seems so obvious to me:
They get actual work done.
Programming isn't work. That's just a means to an end. A tool to get the actual job done.
At least in most orgs. Obviously there are exceptions - but the vast economy is not a bunch of software companies. It's companies doing things to build a physical product, and software is a relatively new annoying side quest/cost center.
It's interesting how people view software as a distraction and an annoying side quest/cost center, but never apply that to, say, 90% of what management does. None of that "directly" makes money either!
That tells us a lot more about the leadership and management philosophies at modern companies than anything fundamental about what kind of work actually matters.
Eh it's nothing new. Outsourcing comes from the same spirit.
Perversely I find myself increasingly blaming the growth of product management divorced from engineering as the source of some of this.
Everyone wants to be the next Jobs, but somehow they missed that it was the marriage of high quality design and high quality engineering that got Apple where they are today.
Rather, the lesson they learned is that PMF and UX and yadda yadda yadda are all that matter and coding is just a means to an end.
It'll be interesting to see how many companies discover that you can't achieve those ends if you build on a broken foundation.
> annoying side quest
Face it - it's because developers are annoying princesses. Just read your comment again.
My entitled friend was whining AI will start monitoring his work and he won't be able to slack as much as he does now. Basically he'll have to work like everyone else. FFS.
I think programming is work, but I get your point :). And yes, of course - I'm mostly just curious how peoples roles at various companies are evolving as they hand off more and more to AI.
Fair, work was the wrong word to use.
I meant - create useful work product. For most companies software is a means to an end. The programmer writing code isn’t useful, it’s the end result. A lot of small to midsize companies employ a couple software guys out of necessity, and the results are usually middling at best. It’s a problem IT in general has really failed to solve very well.
I say this as someone who has picked up and put down “programming” as I needed it. It’s never been something I’ve gotten any satisfaction out of by doing, but I get huge satisfaction out of the resulting product or workflow automation or whatnot.
For my uses, if I could replace my programming and IT time with a robot I would - since me being in that role just slows down delivery to the end user. One of my first hires as a small startup was a programmer - specifically because I knew I rather sucked at it and what a pro could get done in a day took me a week. This is why AI for the low value/less complicated automation tasks is extremely compelling to me.
I’d immediately have 20 other things to work on to soak up the time savings!
It's really quite interesting how there are always posts on HN with people talking about how AI made their life great, did it cheaply, made a great product, and saved the day. But whenever someone asks for specifics, the questions are always dodged or answered very vaguely. It's rare that anyone ever even says what their product does.
To be fair, thraway3837 posted a reply on a sibling comment and offered "AMA" :).
That said, I do see a lot of those posts you're talking about, and I think a lot of AI development is way overhyped. But I also think internal tools like this can be a good use case.
Personally "none of them have read any more than a few lines of code" makes me wary, but if it works for them, then so be it!
I have Claude work on web app testing scripts written in java using JUnit and selenium. The scripts test a vibe maintained flight booking app for an airline I can't mention without doing myself. The app is maintained using copilot by another vender. Claude was given to our team by our employer. We aren't even employees of the airline just contractors under a vendor. Before Claude was adopted everyone secretly used whatever chatbot they preferred. I used opencode with Deepseek v4.
I'm happy to provide specifics, within reason, of course. Ask away. I've since responded to comments with more detail, but if I missed something there, let me know!
You keep saying you'll provide specifics, but I haven't seen anything. Instead of saying you'll provide them, actually provide them! Be forthcoming.
This conversation feels like the "disturbance in the kitchen" scene from Curb Your Enthusiasm: https://www.youtube.com/watch?v=vjaHrp6JtyY
They read hacker news
Manage and oversee the engineering
You forgot a "vision". /s
>"So what do you / your team do?"
Probably the hard part; figuring out what the heck to actually build, talking to customers, and figuring out whether it's actually working for people.
Nobody cares that your codebase is Clean and SOLID, or uses $whatever_framework of the day with 100% test coverage.
“Maintainability” is probably the word you are really looking for. Few devs care whether something adheres to whatever as long as we maintain:
- user experience/expectation (i.e., if feature X worked three years ago, it still works in a consistent way today after a bug fix) - development cadence (if implementation of feature X took N days, a comparable feature Y should take N days) - sanity (can we assume that a fix going in Thursday night or Friday morning doesn’t wreck the weekend)
SOLID, DRY, ACID-compliant, linted, formatted, clean, functional, compositional, etc. May be the means (misdirected or otherwise) but they are not the motivator(or at least should not be).
What matters is whether the day two feature requests, bug reports, CVEs, and traffic load that are coming can be met on time.
Not saying it can’t be done without a developer at the helm, Anyone Can Cook™, but I guess it depends on what harness is in use or has created for the org, and whether that consideration is baked into the guidelines for the codebase (which seems to be, at least to some extent, what this service tries to course correct).
And of course, what is done to the process when incident x happens, again and again. Are we only updating code without paying attention to process that enabled it in the first place?
Maybe that’s the story of vibe coded repos: the code devs were removed but we really still need devops personnel. Also maybe new tech will be more readily adopted.
Interesting times.
Yes, I'm familiar with these talking points. I didn't mention clean code or solid or frameworks or anything like that.
However, the poster explicitly said they don't do what you said (EDIT: I misinterpreted some of these):
RE "talking to customers"
> 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
RE "figuring out whether it's actually working for people"
> have senior engineers review the actual functionality and none of them have read any more than a few lines of code
RE "figuring out what the heck to actually build"
> replaced by "vibe" coding
Maybe my definition of vibe coding is wrong?
--
In any case, I don't have some ulterior anti- or pro-AI motive. I'm genuinely curious why and how a project run this way has humans in the loop at all.
Sorry for the confusion, we talk to customers both internal and external that drive these feature requests.
We ultimately decided that paying for low code/no code platforms was pointless because that's what AI coding is. 90% of the time, we don't even have VS Code open and just gloss over the diffs in the PR.
I honestly don't know what the trajectory of those low code/no code platforms are going to look like. Are their senior strategists looking at the landscape in the last year and going "oh. no. What is the point of our product anymore because what's the point of people dragging and dropping no-code connectors to build an application when they can get 100% portability and transparency by having code generated by AI"
So wait are you saying you replaced an online tool with a local vibe coded app?
Is it a web app with vibe ops?
What's running all of the workflows now? Are you vibe provisioning new cloud instances? Or does everything run on local machines now?
I used CF Wrkers because I wanted to try serverless(1) - I just needed a tiny https proxy for one of my personal scripts and.... It turned out to be super fun.
And no surprise bills.
(1) after my earlier experience with AWS lambda - almost no traffic (few requests per day), on free trier and YET I had to pay for the add-on they automatically added (and it took me almost 2 hours to find all the rhizomes that were proudly anticipating another few £ for pretty much zero traffic).
We did at my work. We were paying too much for low code orchestration software. Replaced it with vibe coded workflows. Still have some infra costs but it's fantastic, cheaper, more velocity, and everybody is happy.
I highly recommend Workers for Platforms for anyone wanting to deploy vibecoded apps: https://developers.cloudflare.com/cloudflare-for-platforms/w...
> We have senior engineers review the actual functionality and none of them have read any more than a few lines of code.
A senior engineer should be able to efficiently read thousands of lines of code per day. Maybe this is what you meant by "a few"?
Alas no:
https://smartbear.com/lean/code-review/best-practices-for-pe...
> A SmartBear study of a Cisco Systems programming team revealed that developers should review no more than 200 to 400 lines of code (LOC) at a time. The brain can only effectively process so much information at a time; beyond 400 LOC, the ability to find defects diminishes.
...
> SmartBear research shows a significant drop in defect density at rates faster than 500 LOC per hour. Code reviews in reasonable quantity, at a slower pace for a limited amount of time results in the most effective code review.
I doubt the thousands of lines per day claim unless the lines are trivial. It’s quite fatiguing to read hundreds.
No, I really meant that we don't even read the code anymore. In another comment I wrote: we just CMD+Q VS Code and it's not even in the recents/pin to dock, since what's the point? We can see the diffs in the PR and quickly gloss over it and query/prompt/ask clarifications.
Press y to doubt that 1k/m using opus… that cannot be true.
It's easy to believe if it's 5x $200 subscriptions.
Paying by the token is insanely expensive. Only the 5̵ ̵R̵i̵c̵h̵e̵s̵t̵ ̵K̵i̵n̵g̵s̵ ̵o̵f̵ ̵E̵u̵r̵o̵p̵e̵ Biggest Tech Co's can afford that.
But the subscriptions are cheap honestly. Yeah they say it's not for enterprise usage but ok whatever. Not paying $10k when $200 gets you the same value (seriously)
>Yeah they say it's not for enterprise usage but ok whatever.
For now, it's clear that they will likely begin restricting the subs or severely cut back their token allowance.
I could also see Claude looking at source code/repos to try and figure out if it's closed source. If true, demand token payment.
I have always felt that AI will be much like how we all now have a calculator in our pockets (despite our math teachers telling us that would never happen lol). For math yes one could sit and do long division and multiplication and so on but having a calculator as a tool obviously makes things so much faster. But you still need to have the knowledge of how math works like the order of operations for it to be correct in the end.
I picture AI coding being the same. Ya someone with no coding knowledge can probably vibe code a small project and have it work. But more complex projects I picture AI like the calculator speeding up the work but in the end one must still understand programing and be able to ensure that the code is correct for the goal.
The main difference is (simple) calculators are deterministic and monotonic. Meaning it executes a set of instructions in a predetermined way to produce its output. Bringing LLMs to that level is a whole another ball game. But we'll see, perhaps the arithmetic nature of algorithms will be replaced by a whole lot of tensors in the near future.
Creator here,
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.
I don’t think this is anything new, really: Businesses have been running software that we’d call a “big ball of mud” [1] forever.
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/
Our outcome is also AI-generated (or AI-assisted) code. It is not possible to rewrite 100k loc in a week. Where our stills are is refactoring at scale with help of agents. Basically, software engineer knows better what prompt to put, and when to redo the process or go different path.
> I don’t think this is anything new, really: Businesses have been running software that we’d call a “big ball of mud” [1] forever.
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.
Most of the new Github bloat will just be thrown away. Vibe coding scratches an immediate itch and it's easy to do. Once the problem changes nobody is going to update the first project because that's hard, they'll just vibe code an entirely new solution leaving the first to rot until they delete their dead repo clutter or move on from the company and the account and all of its repos are deleted in one fell swoop.
How do you "throw away" the bloat when it becomes embedded through the code base? Is GitHub just going to rollback to some commit from 3 years ago?
And those of us working in the slopfields will probably be employed until the day we die. Love it.
I bet on the loc growing exponentially. I wrote this at the end of 2024: https://codegen.substack.com/p/future-of-software-is-growing...
Hope you like it.
Are clients not interested in learning how to build scalable software themselves? Just curious about it, since it's not mentioned in your services.
We don't target software developers. Most of the time, they know their craft. We target those who don't have experience and diging into how serwer should be implemented, or best composition of a domain model is not what they would like to sepend hours doing.
The typical client is a 40 years old ex-CTO, that had idea, verified it with Claude Code and got to the point, where the repo is too big. Maybe even rewrote it all from zero, once or twice, but end-up with the same outcome after adding more features.
He can either hire a developer to work on the codebase and refactor it or hire 3party company.
Sometimes the requirement is a security review. And you pay much less if you downsize the repo before handig it over.
Those who would wouldn't have mountains of unmaintainable code generated for them.
Software engineer profession soon will be like a plumber. You don't build, you just fix things.
The copy on your website itself kind of reads like LLM slop (eg. "One week. Three senior engineers. $10,000"). You may have written it yourself and marketing copy just tends to look like this, but it doesn't inspire confidence that your service will actually improve my code.
No shame in using Fable to help with the grammar and style of text. English is not my native language and while I can use it quite well, LLMs are much better in forming my thoughs into something simple, that sounds great.
My writing workflow is: (1) write what I want to have on the page. (2) /grill-me it should be sound and logical and easy to read. (3) Manually review the text, replace by hand what I don't like.
I think it is deliberately written to be LLM slop so the folks buying their services will be comforted.
Some people like AI generated comfort-slop nowadays. They feel uncomfortable when they run into individualistic human language.
If you have even the remotest mental slop filter, I assume you are not really part of their target market.
There is also a flip side of this. I work a lot with AI-generate text and I can also catch it quickly, but most of the time now, it's easier to read AI, than humans with their weird chain of thoughts and compex sentences ;P
From the submitted link:
> we distil what it does
FYI, "distill".
https://dictionary.cambridge.org/us/dictionary/english/disti...
"Fulfil" is the same way
Thanks. I double checked for alternate spelling but whichever dictionary I used didn't have the U.K. alternative. Good to know.
fixed
parent commenter may not be american
I wonder how you do it when faced with what are undoubtedly poor functional, regression, and unit test coverages.
Initial AI scan can list most of system usecases. Then we review it with a client and agree on what must stay. We can propse better solutions at this stage. If we remove the code, then we can also remove its unit tests. For intergation, repo-wide tests, we treat it as documentation/requirements that must work on the other side.
Human to human interaction is the tool we use the most :)
>I am sharing this because cleaning up after agents with 1M token context is a real business for engineers. Curious what HN thinks.
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.
With a twist that you also have to use LLM for the job to finish it in time.
its no difference than US team fixing slop written by outsource company from India. where do you think LLMs learn slop code from?
I owe the first decade of my career to shitty outsourced code.
I worked with such an "enterprise code" in the past. LLM code is a bit different. For example you don't see code repetition in the same file very often. I'd say it's a next level of slop. Slop at scale!
If unclogging the sewers is a way how the deluge of AI slop can create new work, then more power to you! It's one more element that makes it even harder to write satire that is more absurd than reality.
Our profession is keep changing. A few years from now, future developers will look at us and say: "2026, what a wild, wild west it was".
I guess it was only a matter of time before this niche of business developed.
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.
I can't agree with saying ai is failing, I mean if you work at a company with a lot of software engineers it can be true, but from what I see it's mostly non technical companies that adopt vibe coding to address technical problems. It's just another form of outsourcing
> I guess it was only a matter of time before this niche of business developed.
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.
> 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.
> It takes active effort to get them to follow strict separation of concerns and modularization
100% agreed. AI tools are a multiplier for experienced, conscientious developers who pay attention. Bad developers can still make bad code with any tool, and AI allows them to make more bad code quicker.
This is the gotcha here and the solution is to tell it how it should architect the software and what integration points it should use. But if you clearly define integration boundaries, the success condition, and a few other small details, it generally does a pretty good job.
> courtesy of modularization, separation of concerns, explicit APIs, and so on.
That's great, but a lot of that is knowledge you have to bring in. You need to be careful with the design of the API boundaries, the interfaces, etc.
Lots of people who are using AI to code projects... don't do that.
And once you get to the point that the AI is having trouble keeping up with the project... it's going to take a lot of work to discover what those module boundaries and interfaces should be.
Lots of small moving parts that build up into a large architected platform, which requires careful design, otherwise you get a big ole ball of "it mostly works when we first created it but don't touch it". And yes, bad developers are susceptible to creating the same thing. That's the whole issue with vibe coding, it creates something that works, but is brittle, because there are no strict architecture requirements around the entire design besides vague suggestions like "follow best practices", and as it makes mistakes, it just patches whatever it can to make it work, instead of fixing the root problem with the design.
> it doesn't work on our giant spaghetti code monstrosity cludged together in a million terrible ways
That is so so so much software. Further, AI loves to make this kind of software.
Ask almost any software developer in big tech about their software and I’m sure they’ll praise it. Using it is a completely different story. I’m sure you think you’re having success vibecoding enormous and extremely complex problems, but I’d bet their either not extremely complex or it’s not working as well as you think.
This is misreading the original reply. An enormously complex problem is different from an enormously complex project. Complex projects can usually be decomposed into tasks of varying complexity, some of which I bet an LLM helps with.
> And to be fair, lots of grifters have done the fake it till you make it act on HN...
Indeed. That is how the entire AI industry exists.
Ahh yes the “you’re holding it wrong defense”. Now i ask what enormous extremely complicated projects…excuse me by projects we mean real production software with real scale.
Sure, it can poke one system or another but even with opus and now fable, it very quickly hits the limit a limit that tracks very closely with context window.
This is to say that no amount of harness tool skill is going to cover that fundamental gap. If your change fits in context, good chance it will work.
> Ahh yes the “you’re holding it wrong defense”
Tools have limitations and ideal uses. If you hammer a nail with a chisel, you're probably going to have a bad time. If you build a home and don't level the joists and studs, you're going to have a bad time. If you use an impact wrench on the wrong part you can cause enormous damage. And so on.
Yes, "holding it wrong" is a legitimate thing people can discuss. Similarly it's funny how often people want to talk about "vibe coding", when that is quite simply the opposite of what I am advocating, but it has become a fun slur.
> Now i ask what enormous extremely complicated projects…excuse me by projects we mean real production software with real scale
Every large project on the planet is using AI tooling now, so this sort of gatekeeping has gotten almost sad. Like there's another guy in here leaving some worthless troll comment and they literally created an account on here four months ago purely to run around shrieking and telling everyone that AI is useless and it's all a myth. The desperation is palpable.
Good large projects generally are the combination of hundreds to thousands of small, fairly defined and isolated sub-projects and modules and contained classes with well-defined entry-points, and so on. Using AI on projects like that, where the non-vibe developing, skilled developer is asking for concrete, audited changes on those modules, is hugely useful. It's far more of a crap shoot if you don't understand your own code base and broadly demand that it make cross-cutting changes.
I never said ai was not useful nor that it cannot be used on small parts. The issue is size.
I think you are projecting other people on to me with is counter productive.
Slop and vibe coding are valid. It is specifically for describing crappy ai output.
You still did not give specifics which is usually the case when pushed on. I will give you some, when there are well over 20 languages that span multiple applications which all can depend on one another in same way, bazel builds from hell. Ya ai cant do it.
“We use Claude Code too”
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”.
NGL I'd argue there's a certain appeal to "use AI to prototype a feature as fast as possible and focus your engineer hours on building a comprehensive testing and fuzzing plan" followed by a "remove and review everything that can be cut without breaking the tests" cleanup pass.
I do see the appeal, it’s easy to imagine that workflow working, and working well - but it’s hard to how it avoids this fate: https://youtu.be/QEzhxP-pdos
The “cleanup pass” never happens, though. It’ll just be new feature on top of new feature until it’s too large to refactor.
You're describing a problem that's plagued corporate software development for decades. You just get to the "unmaintainable ball of mud" stage faster now. Every few days I spent a while on codebase architecture improvements after landing a slew of features.
Except it does. It's not some law of physics. I've done exactly this on multiple projects, both personal and corporate.
I’ve reviewed and worked on a lot of vibe coded apps (I’m an engineer, 20 YOE).
I can basically split it into 3 groups.
1) Pure vibe code. No software experience.
2) AI with someone who knows the software development process and some things about software, but can’t code.
3) Engineers using AI assistance, reading/reviewing code, forcing structure.
If someone can pay to replace #1 with #3 it’s very worth it. The quality between each of these tiers is enormous.
I actually got curious and asked AI to look at each module in a codebase, and tell me about who wrote it without looking at git.
It successfully profiled all 3 of these groups and correctly attached them to the right module.
Thanks for writing this. In my refactoring process I also start with code profiling. Opus is good, at finding hand written code, which sometimes is a good starting point of understand the codebase in general.
Ngl I’m doing this right now for a client. Part of my strategy is to write out e2e tests that get a certain baseline of functionality, and then use that as the check for any change that I make to the codebase to make sure it continues to work.
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.
I have also experimented with mutation testing. But the side effect of this approach is that it keeps public interfaces intact, and most of cases you don't want that.
the claude giveth and the claude taketh away. I could definitely use claude in a tightly directed manner to clean up a slopified codebase (and I would enjoy doing so), you just need to think of it as closer to a power tool than an agent.
The level of "slop" produced by AI is a direct function of skill of the developer and broadness of the prompts.
Broad prompts by unskilled users results in a complete mess. Targeted prompts by a skilled person reviewing the code produces something better.
Quality of application varies widely, and generally agree with the categories mentioned by the sibling post.
My experience as well, I've been developing a native macos app using CC. As a web dev I didn't know much about the stack. Nothing too fancy a kind of folder gallery-player with tags embedded in filenames, a bit like TagSpaces.
Process was - produced a detailed feature spec - multiple iteration of "I want this and that", make it into coherent spec", "this this and that is not correct, change to that". Made it write architecture spec(which I didn't read because too unfamiliar) and split it into tasks. Then it was implementing tasks, after each I did a change/fix those ~10 things iteration and spec corrections.
It was good to a point, but then when I started to hit performance problems I had to step in look at the code, and very often fight with CC, confront its "this is the only way", force it to do web search for proper ways to deal with problems and even explain very simple things about proper DB usage.
At some point it asked me something like "is it ok for schema migration to just fail or we need to implement complicated handling?", I have answered "it just shouldn't leave app locked in schema failure", and guess what was CC solution? - it wrote an error handler which just drops DB and recreates fresh one on ANY schema failure. And if I didn't happen to peek at the code and ask wtf it is doing, that would've been an exiting UX.
I've spent about month's worth of $20 CC subscription tokens using Opus 4.8 on xhigh, AND about 70 hours of my time to get it to a point where it is good.
So "anyone can just code what they want now" is correct only to a point, MVP will work, but beyond that experience will be subpar, and it still needs lots and lots of iterations of explaining what you want. Then because normal user knows very little about how software works they won't be able to ask AI the right questions, confront it and rate of improvement vs token usage will hit rock bottom.
Not exactly. It’s more a kin to giving an electric drill to a tradesman vs a screw driver. The tradesman will use the electric drill effectively.
People keep making this analogy not understanding that trades folks will use the right tool for the job, not just whatever is newer / more advanced. Air nailers exist but hammers are still used. Drills can screw in screws but screwdrivers are still used. You wouldn’t use an electric drill for a lot of jobs. People will also try to equate it to an electric saw vs hand saw, but again time and place for both.
I’m not discounting that other tools are to still be used. My reply is to the OP that was saying that quality gets worse applying an AI by an expert to an AI coded project. Time and place for both I agree.
My barber once told me, "You don't pay me for what I cut, you pay me for what I leave behind". Now I'm bald.
Left behind nothing!
> Now I'm bald.
You always have to remember to tell the barber "No mistakes", just like you have to tell Claude.
lol looks like they are using a similar methodology to how we use Claude in house.
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.
with AI, documentation driven development is an understatement, if you take the time not just to document but to also provide lots of examples and potentially even data structures for the implementation (including intermediary data structures if you know them) the output is better than anything you would make in reasonable time.
If you have done or are doing all of that, why not just use the code you’ve made inside your docs?
Like, are you using languages where data structures are hard to write and/or work with? Typescript, Kotlin, Python and Ruby (via Sorbet or DryStruct) are all really easy to write all those data structures and code.
what I meant was dictating the data structures for the code (transformations) the LLM is going to write.
in my workflow I typically prompt the LLM to carefully consider if the data schema I provided it is not sufficient for whatever task I gave it and to then argue for including additional members, with GPT 5.5 I took notice because of the arguments it provided me, it became clear to me that it's over. they have 130+ IQ. it's just a matter of constructing scaffolds now to have them express the intelligence because due to whatever quirks of training they can do stupid things.Same here. Honestly, there's also a bunch of human friction that goes away. I can tell a junior that a change needs to be significantly refactored (or even thrown away entirely) without the psychological damage of discarding days/weeks of work from them.
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".
> It's de-personalized
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.
I have to admit that I'm curious why this is the case. I almost wonder if the pseudo-anthropomorphizing of these models is partially what helps here, similar to how I don't take it personally when I give instructions to a junior engineer and they fuck it up (though, I probably should to at least some degree more than I do).
Probably something about the personal time and effort invested in a thing. I would feel much less personally invested if, for example, I created an outline of a story and then paid a ghostwriter to fill it in.
So then, why have the junior engineer in the first place?
The same reason we had them before? A few juniors can be productive with oversight and guidance. Half the battle is learning what good work looks like, and figuring out what it is that you should even really be building, and those are skills you develop.
This feels like you just have that retort in your pocket waiting to use it because it didn’t seem relevant here.
What does this even mean? Why have the junior engineer if they aren’t irrationally invested in the code the write?
Yeah, that's how I've been using it.
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.
Nice domain name! I currently live on the wrong side of the Odra and cross it on my bike. Gorgeous areas and polish food is so much better than German :)
> One week. Three senior engineers. $10,000.
What your markup on their salaries? For the level of work you're promising, it sounds like they may be at market or below.
They're all based in Poland, so it's probably fairly generous compared to European market.
true
Some (lots of) people will trade a lot of money for general life freedom. If it's well-booked, a service like this can come to around 105k/year for each dev.
A salary like this is only a big compromise if you live in a very high cost of life area.
Being honest, knocking one refactor after another is super intense and we would burn out quickly. To me refactoring/reading/reviewing a code that you have never seen is one of the hardest thing to do for a software developer. If I have 4 such projects a month, I'd just hire more people and allow them to rest. Also invest more into internal tooling to speed things up would be good solution to remove some burden. I think $10,000 for refactor is a fair price.
We also have other gigs and ongoing project, where we can rest a bit.
This seems like a easy way to get into consulting. Once you deliver the code back to the owners they are going to do the vibe coding again on the top whatever refactored code you get back. In other words it can become a perpetual cycle.
The goal is to avoid it and build such a structure and guidlines for the codebase, so it can refactor itself when needed, but based on the architecture defined by us. With good set of docs and new feature definition you can most of the time use /grill-me with good outcomes.
Call me pessimistic or realistic, the code and architecture is just a reflection of the author/organization. The only way it can change/improve is if you either switch the people/organization or invest in their improvement/continuous learning.
Probably will do a patio11 and keep raising as they get more confident to do so.
I am currently working with a non-dev startup CEO that's fully embraced Claude Code and vibe coding.
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.
I charge $15k a week to fix any AI code that they fix that then needs to be fixed.
I charge $100k to tell them they never needed the code and delete it all.
See this: https://www.reddit.com/r/ClaudeCode/comments/1tb7edc/inherit...
One week to both refactor a big code base and also make sure everything works as expected? Not the estimate I would expect from a senior analyst, too optimistic. Fine that you fix the regressions for free, but the last thing I want is a one-week refractory going to production and fire fighting later.
I have 15+ years of experience in software development. The hardest thing I had to learn recently is that paring with AI changes the definition of "what is hard". You can decomposit a refactor into a steps of two kinds:
1. Conceptually hard, which you have to really think about and write code by hand for AI to follow,
2. Time consuming that follows patterns.
Then you do 1. review with AI what are implications on the codebase. Next you crate list of task for 2. and keep reviewing outcomes.
This does still not include any QA. The fact that A.I. tells you the implications of your changes does not take away the effort and time you need to verify the correctness end to end
"rm -rf ./" can't be that expensive, right?
"Two weeks of warranty" jumped out at me. That's like "you have two weeks to find the thing we broke, or else we aren't responsible for it." In my experience, a good bug can hide for months more than two weeks! My codebases are definitely not in the target demographic for this service, though, and maybe if I were in the target group (bunch of LLM slop, trying to dig out of the hole, presumably no shipping product or existing userbase yet) the proposition would appeal to me.
This is a fair point. But these days bugs are not so scary anymore, so a client can vibecode a fix faster then getting me to fix it. Of course if Opus can't figure it out, I would always try to help. I have never left a client alone, warranty or not. This is just how I was raised.
> bugs are not so scary anymore
Umm, what?
Bugs can cause user data loss in production, or total system outages, or a slew of other Really Bad Things. How are you planning to vibecode your way out of that after the fact?
If the client has an extensive suite of automated tests assessing if the software is meeting its requirements, it should be possible for them to flush out most regressions within minutes or hours, not weeks.
If the client hasn't invested in setting that up, the resulting situation is the clients' responsibility.
If the client has that, they definitely don’t need an external party to ask Claude to do code cleanup for them.
Unless tests are also vibecoded.
> One week. Three senior engineers. $10,000. We commit to a reduction target up front, and you pay in proportion to how much of it we hit.
Commitment ain't what it used to be.
15 years ago it was always fix price for undefined amount of work, 10 years ago it was agile where client was promissed something but paid per day.
I prefer the old way of doing things: do the offer for free, commit to a task, and accept, that it might not be a success after all. I'd just loose a week of work, but probably learn a lot.
> Then we do one week of focused work. Before touching anything, we sit down with you and write out exactly what your app does, screen by screen, endpoint by endpoint
While the whole thing is clearly a bit in jest … one might suggest that if a complete spec takes a negligible fraction of a week, then perhaps neither AI nor consultants were required
This prepartion is on us, but yes, client pays for the time he/she spends with us. You can't cut corners here, as human to human interaction is essential. During the whole process, client might be dragged into the developemnt to clarify things, or decide on some tradeoffs. No free lunch here as well.
> You have an AI-generated codebase that works, but adding a feature now takes days and breaks two other things?
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.
How does either of those practices keep code maintainable?
They solve "adding a feature now takes days and breaks two other things".
No, they solve figuring out if a change breaks your existing code.
But if your code is poorly structured, it absolutely does not make it easier to modify.
It still solves "breaks two other things".
True, but this way you can endup with so much testing code being 10x your core implementation.
That was a problem when testing code was expensive to create and expensive to update. That's no longer the case.
Plus, SQLite famously has 590x the test core compared to the implementation code, and they wrote that by hand! https://sqlite.org/testing.html
But that's not the problem being highlighted in that quote you clipped out and responded to.
The problem that quote (and this entire post and the folks that produced it) is putting a finger on is that vibecoding makes it very easy to build large piles of brittle, entangled code where all those early velocity gains are paid back as evolving the codebase takes more and more time (and, crucially, tokens).
No amount of <insert methodology here> replaces good judgement about architecture/design that ultimately leads to more maintainable, extensible code. That was true before AI and it remains true today.
Now eventually AI may get to the point where it's autonomously generating code that's structurally as good or better than what any experienced human would create.
So far, IME, that is not yet this case and nothing can yet substitute for an experienced human in the loop to steer AI toward better decision-making.
And before it's said, yes, that also means humans made ugly balls of mud in the before time. That term obviously came from somewhere.
But that only proves that AI is as good as prior humans that did a bad job, which on the one hand is impressive, and on the other hand is deeply alarming when you know there's folks out there letting these things loose without any supervision.
Of course if all one is doing is tossing off and walking away from greenfield projects, man, vibecoding is magical. I suspect a lot of the "we never look at code anymore" claims come from this world.
But there's another word for that: slop.
The text here seems AI generated which doesn’t inspire confidence.
We have been doing this for years now: it is great. We build our products faster and better and we get more money for fixing products vibecoded by others. More money in every way.
> Then we cut: the fourteen date formatters become one,
something's off here
Seems fine to me.
> Then we [perform the act of] cut[ting]: [thereby,] the fourteen date formatters become (i.e. are replaced with) one,
It's the AI-generated writing that seems off (I'm assuming that's what OP meant)
essentially, yes
it's not about the prose quality, but about the fact that it seems like the service of deleting ai-generated code is also going to be ai-generated, or at least the service is being advertised via ai-generated text, which is…funny
I want it be positive, but it’s a bit hard with this one. Do you expect the client to sit down and explain every detail? If they know how to do that, they wouldn’t be having messy code base as the one the post is describing.
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.
We do the initial code review by ourselves, we try to run test, run the project etc. We compose a list of what we have in the codebase and what we think it does. We also preapre a list of what functionalites we would change.
Example would be removing service implementation that is bash code handling manually PID files, and replacing it with pm2 tool, that has quite different workflow.
So the client must approve such decisions.
They can request an agent to reduce the amount of code, right? Why do it manually?
You can, and you definitely should do it every few days. We do AI-pair refactor and use our experience and knowledge of tools.
That’s almost enough to tempt me to unretire! Thank you for doing the necessary, grueling, work.
I will do this work for substantially less money, $200 per week.
Contact me agngel@proton.me
Do you charge extra for the "rm -r" option instead of regular rm?
I've thought about it and decided the animation wont do.
The page needs a generated video with giant cockroaches, mechs, 3 men in supper hero gear with swords & lab coats and there needs to be a puny human being saved. Then a dark voice narrating how the man created an unmaintainable mess using llms and that after a fierce battle that lasted a week he was saved by team slopfix. Beethoven symphony No. 5
You should partner with a Cloud repatriation company. Ping me :)
ping
Seems like instead of investing in this, just spend 1k every 4 months and have the latest frontier model rewrite the entire codebase from scratch but maintain things that are non-negotiables (like db tables, apis, etc).
That would require someone who knows what they are doing, hence this service
I was waiting for the new spaghetti cowboys to arrive. Good luck guys, but keep in mind that a 1000 cores can do a lot more damage than 3 people can fix.
Haha "spaghetti cowboys". I love it! https://odra.dev/slopfix/img/spaghetti-cowboy.jpg
AI slop? Humans write slop too. We’ve all heard the stories, companies outsource projects to India, only to bring them back to the US for the local team to fix.
I saw it myself at a past job. We hired a consulting firm to convert a project. They outsourced it to India. In the end, we had to hire a US company to rewrite the whole thing from scratch.
Talk about slop!
So true. Where do people think agents learned to write slop?!
I don't think one week is enough to learn the complex business rules that some software needs to follow.
I wonder if this is part of what's clever about pitching their consultancy as slop cleanup -- nobody's likely to engage them to work on a pile of logic that's been evolving over a decade with weird load bearing corner cases. The "I just vibe coded a massive tangle" situations are more likely to be newer.
At least, one could hypothesize. Perhaps incorrectly. :)
This line made me chuckle. I see what you did there:
> No cookies. No tracking. No JavaScript. Real people.
It's another way of saying "gihub pages" :)
One of the funny lines I heard was: Vibe coders try to debug python code by adding a semicolon. lol.
I wish these guys luck in finding their customer. Really. Because real solution to the problem would be to hire old-style developers to rewrite the whole slop from scratch without AI being involved. Fixing broken slop is Sisyphus's labor.
I mean, not really? The urge to throw all the code out and start over is what ever mid-level software engineer has always wanted to do, and it’s almost never the right choice. The old code worked well enough most of the time, it just didn’t have good or safe practices and those can be retrofit.
In fact, doing and directing such things are kinda senior, principal and management jobs, in general.
Thanks.
Charging by line of code is crazy
It actually is. What we fight for is being able to put as much percentage of a codebase into a context as possible. I'd charge for amount of tokens, but it would be harder to sell.
And we use Claude Code to do it, lol.
I passed your comment to Fable and asked him to replay:
@zie1ony / OP - how do you make your clients believe you are not planting a crypto-locker or logic bomb or some other 3-letters-agencies "features"? And why would clients replace existing AI slop with your post-another-slop handwritten code? Do you check it for vulns and, most important, have you considered that later clients will sue you for <something their checkbox audit did not like>? Providing there is no major data leak, in which case you may end up proving your innocence from behind bars?
I remember implementing very complex cryptographic scheme in pure C. After a week of hard work, my friend concluded: "Cryptography would be much easier if people just trust each other."
The truth is that it is my reputation on the line, so I also have to make sure dependencies I use don't mess up things as well. There is no good defense against it. In my contracts I undertake to act in a good faith and take the responibilites to the amount of my professional insurance. Honestly, it is different casy by case.
You know, AI is really good at this.
Okay, I'll see myself out.
$MY_STARTUP does — something — similar. I — love — that — you — say — you'll — do — this — in — a — week, — and — then — a — two — week — warranty? What — are — you.. replacing — an — engine? — Gotta — keep — that — head-gasket sealed — tight.
/s Isn't this just called a consultancy with a super short contract term? How are you actually going to unscrew anything in one week?
100% supportive of this type of product but I also find the ai-slop text to be a bit ironic.
I take the bullet. I'm really bad at writing good long english texts, so I used Fable to help me. But the essence is mine.
https://www.pangram.com/history/54e401e8-30b0-41f4-96a7-a976...
haha
Yes, I think selling "AI cleanup" branding on "we use AI to make smarter AI changes to your codebase" a little.. disingenuous.
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..
$333/week doesn’t quite seem like enough to live on. How many of these are you planning to run concurrently?
It's $3333/week