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