A Startup Charges $10K a Week to Delete AI-Generated Code

In 2025, Andrej Karpathy proposed the concept of "Vibe Coding."

Developers no longer write code line by line; instead, they tell AI what they want using natural language, and tools like Claude Code, Codex, and Gemini CLI handle the implementation.

It has made software development unprecedentedly fast.

Products that used to require a team several months to develop can now be completed by one person working with a few AI agents in just a few weeks.

But while everyone is discussing "how much code AI can write in a day," a completely opposite business has emerged:

Deleting AI-generated code.

A startup team called Slopfix publicly stated:

We charge $10,000 a week to do just one thing: delete code written by AI.

They even completed a project that sounds quite exaggerated:

While keeping functionality largely unchanged, they reduced a 100,000-line codebase to 35,000 lines.

After the news reached Hacker News and Reddit, the developer community immediately erupted in debate.

Some believe this is an inevitable new demand in the era of AI programming.

Others directly mocked it:

People who truly know how to Vibe Code, who would pay you to clean up the mess?

But what's more worth discussing than whether this company can make money is:

When writing code gets cheaper and cheaper, will maintaining code become more and more expensive?

The faster AI writes, the easier the codebase spirals out of control

Many people who use AI Coding Agents to develop products may have experienced a similar process.

At the start of a project, AI seems almost omnipotent.

You say "help me add a login page," and a few minutes later the page is running; you say "integrate payment functionality," and it immediately starts creating interfaces, database tables, and frontend components.

New features keep appearing, and the amount of code grows rapidly.

However, when a project grows from a few thousand lines to tens of thousands or over a hundred thousand lines, the situation begins to change.

Previously, adding a feature took only ten minutes; later, it might require days of repeated debugging. Previously, modifying a component only affected the current page; later, changing one part causes anomalies in two other modules.

The reason is not complicated.

AI is very good at solving immediate problems but does not necessarily truly understand the entire system.

When context is insufficient and engineering standards are unclear, AI usually chooses the easiest way to complete the current task:

• If it can't find an existing utility function, it writes a new one;
• If it's unsure whether a module can be reused, it copies and modifies it;
• If it encounters legacy code it dares not adjust, it adds a layer of compatibility logic on top;
• If tests fail, it adds more conditionals and special branches.

Each modification seems reasonable on its own, but accumulated over time, the codebase becomes increasingly bloated.

It's like a room where every time you can't find something, you buy a new one. In the short term, it's very efficient, but over time, there's no space left to even walk.

The truly dangerous part of Vibe Coding is not that AI writes wrong code, but that AI can continuously add code at an extremely low cost.

What they sell isn't code deletion, but restored development speed

The service Slopfix provides looks very simple: help clients reduce the amount of code.

But deleting code is just the surface; the real goal is to restore the project's maintainability.

Before formally modifying the code, they first work with the client to map out the entire application:

• What pages exist;
• What API endpoints exist;
• What core business processes exist;
• Which features must be retained;
• Which behaviors are for historical compatibility;
• Which modules are no longer used by anyone.

This feature list serves as both an acceptance criteria and a safety net during the refactoring process.

Next, they begin processing the code:

Merging a dozen date formatting logics into one utility; extracting repeated business code into common modules; replacing a rudimentary framework maintained by the team with a mature open-source solution; deleting abandoned pages, invalid interfaces, and logic branches that will never be entered.

For modules that are already unmaintainable, they re-implement them while preserving the core requirements.

So, what the client is buying for $10,000 is not "how many lines of code were reduced," but:

In the future, when adding new features, they won't need to keep searching for a foothold within a hundred thousand lines of chaotic code.

The reduction in lines of code is just the most visible result of decreased engineering complexity.

"Charging by deletion volume" is a clever but dangerous model

Slopfix's pricing model is very topical.

Three senior engineers work continuously for a week, with a standard price of $10,000. But the final amount the client pays is tied to how much of the deletion target the team achieves.

Suppose both parties agree to reduce the code by 50%, but ultimately only a 20% reduction is achieved. The goal completion rate is 40%, so the client only needs to pay $4,000.

This model ties the team's interests to the client's goals, making it more attractive than traditional hourly billing.

But it also has an obvious problem:

Lines of code do not equal software quality.

Some duplicated code should indeed be deleted, but some logic that looks similar might represent different business rules. A 30,000-line project that is highly coupled is not necessarily easier to maintain than a clearly structured 80,000-line project.

If "how many lines were deleted" becomes the sole metric, it could induce engineers to optimize for the number.

Therefore, truly reasonable acceptance criteria cannot rely solely on lines of code; they should also include:

• Whether core functionality remains consistent;
• Whether automated test coverage has increased;
• Whether builds and deployments are stable;
• Whether the development time for new features has shortened;
• Whether dependencies between modules are clearer;
• Whether security audits and troubleshooting are easier.

Writing less code is a means; reducing system complexity is the goal.

If you can Vibe Code, why do you still need human engineers?

Facing skepticism, Slopfix's answer is very pragmatic:

Their clients are typically not individual developers just learning to program, but startup teams using AI to quickly validate products.

These teams already have real users and may even be generating revenue.

During the product validation phase, their primary concern is speed. As long as the feature runs, whether the code is elegant doesn't matter.

But when the project is ready to move to the next stage, problems arise:

New engineers are afraid to modify the code; a small change might cause an online outage; security audits cannot be passed; when investors conduct technical due diligence, the codebase cannot withstand scrutiny.

At this point, telling Claude Code "help me refactor the entire project" often no longer solves the problem.

Because refactoring is not simply modifying code.

It requires answering a series of questions that AI struggles to decide independently:

Which duplications are technical debt, and which are business isolation? Which features are abandoned, and which just temporarily lack an entry point? Which parts should be abstracted, and which should remain independent?

These questions have no standard answers and cannot be answered solely from the code.

They require engineers who understand the business, users, historical context, and future plans, and who take responsibility for the final outcome.

AI can generate solutions, but it cannot bear the consequences of decisions for the team.

The most scarce ability for future engineers might be "knowing what not to write"

In the past, we often measured an engineer's work by code output.

How many features were written, how much code was committed, how many requirements were solved.

AI is rapidly changing this evaluation method.

When generating a thousand lines of code takes only a few minutes, code itself is no longer scarce. What is truly scarce is judgment:

• Does this requirement really need to be developed?
• Can existing capabilities solve the problem?
• Should a new module be added, or should the existing design be modified?
• Which code is worth keeping?
• Which abstractions are creating extra complexity?
• Where should boundaries be established in the system?

The value of an excellent future engineer may not be reflected in how much code they can write, but perhaps in:

How much unnecessary code they can prevent from entering the system.

A junior engineer sees a requirement and thinks about "how to implement it."

A mature engineer sees a requirement and first thinks about "whether it should be implemented."

An architect sees ten similar features and considers not how to generate ten copies of code faster, but whether ten problems can be solved through one stable model.

AI hasn't eliminated technical debt, it has only accelerated its production speed

Whether Slopfix's business model will ultimately succeed is hard to conclude right now.

$10,000 a week is too expensive for individual developers, but for a startup that already has users and is preparing for fundraising or security audits, it might just be a routine engineering investment.

However, the trend this company reveals is worth every developer's attention:

AI has lowered the production cost of software, but it has not automatically lowered the maintenance cost of software.

AI can help a project go from 0 to 1 faster, and it can also help a codebase lacking standards go from 1 to out of control faster.

Therefore, truly mature Vibe Coding is not about letting AI generate code endlessly, but about establishing an engineering system that constrains AI:

Clear architectural boundaries, reliable automated testing, unified code standards, continuous integration checks, and the habit of regularly deleting invalid code.

Engineers who cannot use AI may be eliminated by those who can.

But engineers who only know how to make AI continuously generate code may also be replaced by those who know how to review, constrain, and delete code.

When "writing code" becomes increasingly cheap, "taking responsibility for code" will become increasingly expensive.

And this, perhaps, is the business Slopfix is truly betting on.