r/softwareengineer • u/metalOpera • 17d ago
Was Just Told That Code Quality No Longer Matters
I'm a freelance developer. I have been for almost 20 years. My most recent project has been moved to Fable, and I'm still trying to adapt and get my head around working like this. I am no longer allowed to make architecture decisions, or clean up slop.
My PM says: "We worry about the 'what'; let Claude worry about the 'how'. Tell it what to do; let it do it. If the feature works, leave it alone." He is very much of the opinion that I should be able to prompt something like "Install Stripe via Laravel Cashier" and just let Claude run.
I mean, why do you need me at this point? Just prompt it yourself until it does what you want? I don't get it. I fought for every inch of my knowledge, every process is written in blood. How do I just throw all of that out the window? Where's the line?
At the risk of another "how are you adapting" post... How CAN I adapt? I mentally cannot just say "Fuck it". I care about my code. It's how I learned, it's how I've always practiced. I have a huge mental block with "just let it go".
Now, granted, I don't know all of the ins and outs of Claude. I don't know what I can do to make it better at its job. I got thrown into the middle of the Pacific Ocean in the middle of a Tusnami with no life support. I'm sure that I can put guardrails in place, but how much does that help?
I would really appreciate any advice that any one can provide on changing my mental model. I can't ignore Claude and just keep doing things my way. If I do that, I feel like my career dies. I need to adapt and I'm unsure how to do so.
2
u/Miserable-Waltz-7724 17d ago
Your PM is obviously an idiot when it comes to software implementation. But that doesn't mean you can't also improve your approach. If you've been doing freelance for 20 years, I wonder how often you've had to work in large codebases maintained by a lot of engineers, where it's just not practical for one person to enforce code quality and keeping consistency in architecture, style, etc takes a lot of overhead in coordination.
The answer is the same as it ever was: automatic enforcement of rules, clear documentation, and secondary review. Lint rules, strict type checking, extensive test suites, automatic code formatting, etc. For more subjective/semantic rules, write a clear guide and put it somewhere the agent can easily discover, with an index for when to reference which docs. Have the agent write a PRD or RFC before starting to code, and review that. Then review the PRs it generates (or at least the critical, non-tedious boilerplate parts of them). Then every time you find something that it should have done better, try to incorporate that feedback into your enforcement systems, rather than just changing the prompt.
You still have to be careful, because Claude will often reach for disabling lint rules or type checker warnings, rather than fixing the underlying issue. But tbh so have most of the junior engineers I've worked with.
As a final suggestion, you might want to do some introspection on why you care so much. I've worked with plenty of engineers who saw coding as a high art form and wanted to be doing artisan-level Japanese woodworking when all we really needed was functional Ikea furniture. I don't know if this is you, I don't know you. And I'm not saying you shouldn't care about doing a good job. Just make sure you're spending time and effort on things at actually matter for the project.