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.
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")
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.)
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.
> 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.
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 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.
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.
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.
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.
> 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.
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
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.
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.
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.
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.
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.
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.
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.
- 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.
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.
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")
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.)
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.
> 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.
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 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.
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.
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’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.
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
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.
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.
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.
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.
At least you're avoiding the late night or early morning phone calls when people outsourced to distant humans instead.
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.
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.
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.
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.