Ask HN: Client took over development by vibe coding. What to do?

Here's one way to approach this: Imagine you work for a giant company where humans would push 10k lines of code per week. In a codebase like that there's no expectation that you'd understand everything. However, there is an expectation that teams contributing code will "own" it.

So if the client is contributing you should ask them if they are okay for long term maintenance and fixes of new code they are adding. If not, then maybe you should discuss pricing changes because now you are effectively maintaining code written by them which requires different set of skills and arguably higher cognitive overhead.

Correct. And also hiving off areas that they own, vs you own. Who has decision right and controls the burn down of the kanban board? Basically treat yourself like an API that they consume. You build the good stuff that you know is right. They are responsible for making their crap works right. (Understandably there is some obvious tension around the interfaces.)

Agree. "Owning" in this context should mean: understanding the domain, working on new capabilities and handling fallout if anything goes wrong. Whether AI or human ownership transfer this ends with the new owner just handling new work, while the other two remain with previous owner (who might emotionally provide support for it due to attachment of "I've built it")

This is likely the best answer so far. It would be the same as if they had subcontracted some software factory where many junior devs produced and shipped low quality code that “works”.

Prepare to make absolute bank on maintenance charges when they can't debug what they built? That's what I'd be thinking!

That aside, there's an awful lot of unprofessional comments in this thread. Guys, this is just business: people are paying you money for your talent. Sometimes you just have to wallow in the muck, but at least you're paid to do it.

This is what I thought, too. Watch them dig a hole for themselves while you take a vacation. And then when they fail to debug the mess, charge them by the day for your expertise, because it’ll be necessary for untangling that mess.

They will definitely not be able to debug what they built at a certain point. I think their strategy will be to delete parts of the application, and rebuild them, but this will not be sustainable. This comment (and similar ones) helped me to detach from the project's quality and code, and see the business opportunities that may arise in the near future. I think there will be a lot of maintenance, and someone has to make sure the infrastructure and integrations with other systems and platforms won't collapse.

> Are there more people whose work on a project has been taken away by AI bots?

Of course, what worked me and what allows me to keep my sanity in my case of project owner coming in and remodeling half of the codebase over the weekend with CC is that I mentally ceded "ownership" of the project code, that is, I'm no longer feeling that I'm responsible for what is there and how it is structured. And there are tests.

Apart from that I can say that I empathize with you because I know that initially it feels awful, like loosing some part of agency and also to some degree humiliating when looking that something carefully and meticulously designed is restructured, replaced or thrown away so quickly and carelessly. What also helps is changing mental model and perceiving oneself as controller who overviews process of "shaping" code as whole, in its big mass, to behave in certain way instead of keeping mentally attached to some part of it because "I designed it".

>when looking that something carefully and meticulously designed is restructured, replaced or thrown away so quickly and carelessly.

That’s just a trend that has been accelerating for a while now. Make things quick, quality and longevity are qualities of the past. Is better to give a bad solution quickly than having to stop to think.

"Are there more people whose work on a project has been taken away by AI bots?"

Yes. I've had 2 clients do similar to what you described, so I have stopped working with them completely (one of them subsequently deleted their production database).

Another agreed for me to do an audit where I found severe vulnerabilities, including anyone having admin access, being able to set their own price during checkout, leaking PII etc.

Another is doing an AI in business course and wants to recreate their app using "N8N and ChatGBT". Thankfully, they have heeded my warnings - for now.

I've worked for some of these clients for over a decade, so I have a very low tolerance if they chose not to trust my professional opinion.

I had a similar experience back when I was a web dev (in the early days of the web's growing popularity) and some clients would cancel a website project because their teen told them they could do it for them much cheaper with DreamWeaver or MS Word.

Several folks here suggest doing exactly what I did back then, and truth be told, it'll likely work today just as well as it did back then. Tell the customer straight up why it's a bad idea (just be honest and forthright here), and make clear that you'll be charging extra for the very much different skill of cleanup and debugging the "tag soup" garbage that DreamWeaver (or in this case "vibe coding") will produce when it inevitably fails to deliver the result they'd hoped for.

Then step back and find other work while you wait for the windfall as your prediction plays out exactly as you warned them it would. If it doesn't, then "good for them". Be happy for them that they're happy, and be happy for yourself that you found other (less stressful) work. Win-win, either way? Either way, you're working, they're happy with (or at least getting) their hoped-for result, and nobody's stuck with something they didn't really want (other than perhaps your inflated rate for blithely altering the scope of your task).

Fact is that they're paying you for your expertise, and if they choose to ignore that expertise when it really matters, it should cost them to access more valuable expertise when it comes time.

Nothing new. Classic joke goes like

$100/hr standard rate

$150/hr if you watch

$175/hr if you help

$250/hr if you tell me how to do my job

Why does the client have pushing rights to the repository? I would suggest working by pull request and approve all changes that they make. That's what you would do if you were working in a team.

If you work in a bigger structure, surely there is a product manager that can limit the scope of the project.

I would suggest to the client to develop their own tools that are to be supported by them exclusively while you continue supporting the "official" tools.

Thanks for the suggestions. I've considered to protect some branches, but in the end decided against it. I was not looking forward to review all their huge amounts of slop code. It would also be different from reviewing code of a "real" developer. Feedback would normally be a way to help each other and improve as a team, and be received with a certain amount of gratitude or at least understanding. In this case, they would not read the feedback, at best they would feed it to a bot. They would see it as a needless obstacle. I agree to scope my parts of the project as much as possible. Then it might still be realistic to continue working on it.

It should be in your contract that you are the sole dev and that the client cannot add code. At best they should be able to send a spec or feature request but not an actual PR.

I don't know how you could word it, but you could tell them to use an LLM to generate specs so that you can understand the needs and implement the features yourself (even if it's also LLM-assisted).

> I’ve worked on a project for one year now

> What I am most concerned about is the maintainability of the project and how we will get this live.

I'm not sure if it's something that got "lost in translation" or whatever, but are you really saying this project has been under development for more than a year, yet no one attempted to deploy this to a live environment yet? If so, it's understandable you're concerned about it. A lot of the times when I jump on projects that got stuck in development hell in order to unblock them, this is a huge thing that gets in the way for teams. My approach usually is to focus on getting the whole "Know we want a change -> Implement change -> Deploy to test -> Testing -> Deploy to Production" process down first, before anything else, together with practicing at least one rollback.

It really ties into everything you do when working on a project, as this process itself basically decides how confident you can be about changes, and how confident you can be about that some bad changes can easily be rolled back even in production.

Besides that, having non-technical people trying to contribute to a technical project, is a great way for those people to unintentionally damage how well technical people can actually work on the project. I think, explaining to them exactly what you said here, that it isn't feasible long-term, that it's hard for you to have a clear mental model if they're just chucking 10K PRs at you and that you need to understand the code you deploy, should be enough to convince them. If it doesn't, you might want to ask yourself if that's the kind of environment you want to work in anyways.

The project is deployed to a test and "live" environment, but since it is a rebuilt of a very old project that is currently running their business, we don't have to build in production. They needed the rebuilt because the project that is currently in production is not maintainable anymore because of (ironically) technical debt. I agree it is still a weakness that it is not in production, and it needs a strong vision from their side to invest for one or two years into a project without seeing any revenue. However, the environment does not feel right now, I've not very often felt such a misalignment when it comes to a software project.

You’re not responsible for code you haven’t pushed. This seems like a bad client that not only wants to push code cheaply but plus wants you to be responsible for it. Charge extra. Your value is not in generating code but the accountability of the code you generate and verify.

In my experience, you are "responsible", regardless. It doesn't matter who wrote the code originally.

Have you worked in a true client services model? Based on your statement, my guess is you have not. This is NOT how things work at a consultancy or in a client services model, regardless of industry, unfortunately.

I enjoyed reading this post, because it's a great little case study. A Large complicated project, a senior dev, and a nieve client. It's their project so they can push all the code they want, but they're responsible for it too. I'd be curious to learn of any updates.

Great to hear this, it is reassuring I am not the only one currently with a similar case, and I will try to give an update when there are significant developments.

Its a job right?

If you think you can get another one, go get it. If you don't think you can get another one, do stuff to fix that. If you can't fix that, grin and bear it.

Non-coders often think all engineers do is write code. They don't realize how much more hours are spent on making sure the code we write is correct, from many angles. Functional bugs? Easy to maintain? Cost optimized? Meets user expectations?

When they have a machine that cranks out code, and honestly pretty good code, they think it's the same thing.

Eventually though I suspect many people will discover what many studies over many decades have shown: the most expensive part of software is maintenance.

This will eventually be the problem for your client. If I were in your shoes, I'd probably start laying the foundation for that. If they're willing to bear the cost, then fine. If not, then ultimately you're set up for a clean exit when you can no longer get the software to run as they want in a timely fashion.

I think this is inevitable, and I'm trying to find ways to set up a controlled environment, in which we build a robust safe and isolated foundation, while clients can mess around and vibe-code their features on top of that. I'm still figuring it out so feel free to share ideas.

Why would a standard git flow not work? They can vide code whatever they want, just review it before it is merged.

Honestly the leverage you have is the parts they can't vibe code. I mean DevOps, architecture decisions, anything that breaks quietly in production. i'd focus there and let them find out the hard way what happens when nobody understands the system they're shipping.

The joy thing is real, though. once a client stops trusting your judgment, the relationship is already broken. sometimes the right move is to document everything clearly, hand it over properly, and walk away before it becomes your reputation on the line. I'd like to know more opinions on this

I would not recommend resigning quietly without an ultimatum. Sometimes ultimatums work, and the worst case scenario is that you end up quitting like you were going to do anyway.

Yes, I lost a client last year because they wanted to start all new feature work by reaching for Claude first, and I refused to participate so our relationship had to end. Very unfortunate, but I'm feeling pretty confident that the AI bubble is already bursting, and this sort of low-cost YOLO slop phenomenon will end shortly. In fact, I've gotten new work from people whose values are aligned with mine. I'm counting on that trend to accelerate.

At least you're avoiding the late night or early morning phone calls when people outsourced to distant humans instead.

Since you'll have to babysit and fix their slop now I would at least 2x my rate.

But realistically this will bring you so much bitterness that, even if the money is good, you might want to search for your next client or a "normal" dev job while working for this client.

I feel for you. Its probably saddening to see quality degrade over time.

I would say this is a values mismatch, if the client does not care about prioritizing technical debt(no matter how it got created) and that is leading to too much mental angst, I would recommend leaving the project. But before you make that decision, think about what you said

"They still want me to participate in the project and work on the most critical parts of the application"

I think in this new world, the job of software engineering is to identify where AI could be used to provide the highest levers to the most important people in the client's team to make decisions. For example, can AI be used to identify problems quickly and troubleshoot them? Can it be used to provide APIs or with better observability(e.g. quantify that the system performance coming down is not sustainable)?

Another thing that is weird about this is the human aspect. Specifically role of the product manager. Ideally he should be someone who is experienced enough and acts as a moderator between what code/features go in and what don't. The client always wants the moon and a good PM's other real job is to manage this friction. Is he not able to push back? He is also the one that is looking at the project timeline and making such decisions. If that role is not being played by someone, then something is obviously wrong with the relationship.

I've had project that tried a similar thing, they tried to replace their team with cheaper coders. They went slower because of code slop and their product failed to launch on time and be successful.

Thanks, yes it is saddening in a way. That was my first reaction combined with disbelief. I am reasonably successful now in letting that feeling go, and I try to look for the best outcome, also from a professional perspective. At the same time I want to respect my integrity when it comes to what I work on. It has to remain reasonable what is expected of me, and how much damage in quality I'm able to digest. A PM could try to manage this, but they fired the last one because they want to manage everything themselves. The relationship and circumstances are definitely not optimal currently. Considering this, the best outcome might be to quit in a smooth way.

Raise your prices when it comes time to clean up the mess that they will invariably make. If they don't want to pay, look elsewhere. And skip the LLMs on your next job.

>They still want me to participate in the project and work on the most critical parts of the application

Don't walk. Run.

You’re collaborating in multiple ways more than you anticipated. What would you do if they brought in another dev to work on it independently?

If you see failure in the projects future due to this, make sure you establish your limits and boundaries and obligations clearly in writing. Don’t get officially saddled with their slop.

If another capable dev was brought in to work on it independently, I think I would help to transfer it to them, and quit afterwards. When the dev would not be capable, I would advise against it. But in this case, it is the decision of the company owners, and they turned out to not be susceptible to any arguments against their decision. They also see themselves as "developers" right now, with the help of the tools they use. Focussing on limits and boundaries in writing is a good point, I will review this where needed if I continue.

Second this.

OP - When it fails (and it will), they will blame you for the failure, not the vibe coded slop. Start looking for a new gig. They're going to fire you eventually anyway.

Wait till the infrastructure starts falling apart and step in with a heavy contract offer to fix the infrastructure and performance

Clients are learning to open doors^W^Wwrite slop themselves. Cheaper, same pile of shit at the end of the process.

- Tell them that Claude selects schools for targets.

- Hope that Anthropic's data center is in Qatar.

- Tell them that the core business code needs to be secret and cannot be leaked to Anthropic.

I mean, what do you expect? I assume that you told them that you used the clanker initially, so they thought: We can do this ourselves, let us slowly get rid of him.

Moral: Do not use clankers.