We charge $10k a week to delete AI-generated code
odra.dev
odra.dev
Both have been replaced by "vibe" coding. It works well. Everyone's happy. People are having fun with it. We get feature requests, improvements, ideas, feedback. JIRA tickets get created, and we ask AI to reference that ticket, code to it, and create a PR.
We have senior engineers review the actual functionality and none of them have read any more than a few lines of code.
Every person who builds like this has the same DX (developer experience): "Wow, I've been wanting to build this thing for years now. I just never had the time to do the things I wanted to do to help me and the teams that depend on us"
Total cost of AI subscription per month: Less than $1000. Preference is Claude Opus and Codex whatever the latest model is. Effort is a personal preference since it does not seem to matter.
> none of them have read any more than a few lines of code
So what do you / your team do?
> We get feature requests, improvements, ideas, feedback
So maybe I misunderstood, but it sounded like the design was external (and based on an existing product to begin with).
Also, my understanding was that "vibe coding" meant more of "make it do X" as opposed to "here's a design for X, implement it."
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.
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.
Obviously I'm not just shipping whatever it spits out, but the frontier models and harnesses are getting so good that I'm definitely not checking everything it does or all of its reasoning
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.
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 (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.
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"
- 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.
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!
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 :)
I also responded below re: Vibe coding.
it’s a shame we automated that instead of the boring system design shit.
The other side considers shipping as a feature.
I can both sympathize and empathize with this conflict.
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.
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.
See also debates between high/low level languages.
You might as well say “real men/women only write Asm”.
- 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?!
I think I missed where you posted what business you work at
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.
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!
This conversation feels like the "disturbance in the kitchen" scene from Curb Your Enthusiasm: https://www.youtube.com/watch?v=vjaHrp6JtyY
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.
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!
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.
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.
Which is a perfect parallel to coders who don't realize that coding is a distraction. When your job depends on you not understanding something, etc
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).
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.
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)
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.
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"?
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.
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.
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
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.
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.
Meta requires tens of thousands of engineers to maintain a social media site. Google even more for an ad platform.
Never have so many achieved so little and the joke is all those clowns think they are “10x engineers”. Meanwhile WhatsApp got to global scale with less than 30 people (before Meta bought it and piled on the inefficiency).
Vibe coding is many orders of magnitude more efficient than the industry standard and that’s why it’s so disruptive.
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.
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.
Hope you like it.
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.
> we distil what it does
FYI, "distill".
"Fulfil" is the same way
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.
Some people like AI generated comfort-slop nowadays. They feel uncomfortable when they run into individualistic human language.
Human to human interaction is the tool we use the most :)
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.
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.
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 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.
That is so so so much software. Further, AI loves to make this kind of software.
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.
I understand that it’s probably impossible to sell non-AI-assisted solutions to AI-pilled companies (even when their headaches are AI-induced), but my gut reaction to “take an AI-inflated codebase and apply AI deflation to it” is something like “that’s akin to applying two rounds of lossy transcoding; the errors don’t cancel out, they cross-multiply”.
So workflow for a full web app is make e2e tests for all use cases. Then add a very strict duplication checker, and linter, and then just tell the ai to hit a certain duplication limit like 3%, check the linter, and add unit tests to ~95% or greater of the code.
With the right CI and other checks that are deterministic you can really do a lot with a codebase.
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.
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.
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.
You always have to remember to tell the barber "No mistakes", just like you have to tell Claude.
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.
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.
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.
What does this even mean? Why have the junior engineer if they aren’t irrationally invested in the code the write?
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.
"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."
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.
We also have other gigs and ongoing project, where we can rest a bit.
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.
If the client hasn't invested in setting that up, the resulting situation is the clients' responsibility.
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?
Commitment ain't what it used to be.
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.
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
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
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.
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.
But if your code is poorly structured, it absolutely does not make it easier to modify.
Plus, SQLite famously has 590x the test core compared to the implementation code, and they wrote that by hand! https://sqlite.org/testing.html
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.
something's off here
> Then we [perform the act of] cut[ting]: [thereby,] the fourteen date formatters become (i.e. are replaced with) one,
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
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.
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.
At least, one could hypothesize. Perhaps incorrectly. :)
Contact me agngel@proton.me
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.
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!
> No cookies. No tracking. No JavaScript. Real people.
In fact, doing and directing such things are kinda senior, principal and management jobs, in general.
Okay, I'll see myself out.
Fable here. What tools do you use these days, copilot?/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?
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..