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.

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

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.

$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

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.

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

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.

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.

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