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