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

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.

> 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".

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.

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.

"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’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.

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.

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.

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.

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.

[dead]