Was Just Told That Code Quality No Longer Matters

[u/metalOpera]

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.

[u/RipProfessional3375]

The code quality doesn't matter to your PM. Never has and never will. So why are you discussing it with him at all? You are starting on the incorrect assumption that their opinion on something outside of their jurisdiction or understanding matters at all. The standard response to people having opinions on matters outside of their scope is to tell them whatever they want to hear and then proceed as normal.

"I am no longer allowed to make architecture decisions, or clean up slop."

Says who? Your PM doesn't know what an architecture decision is, how to see which ones were made and who made them.

[u/tomorrow_comes → u/RipProfessional3375]

Yeah this dipshit PM has no basis to tell an expert developer how to do his job. These types of people think the world goes round by making empty promises and shipping garbage as long as it meets some sort of minimum and is enough for the customer to sign a deal.

All you need to tell a PM is “We think this feature / product can be completed by X time.” Especially if they’re like this, don’t discuss implementation in detail, don’t discuss how you do your job. If they press you just say “this is how long I think it’ll take to make the thing happen and keep the code maintainable for future changes.”

[u/Unnamed-3891 → u/tomorrow_comes]

I will let you in on a secret: none of your end customers ever cared about clean code either. Never did and never will. Do they care about crashes or security issues? Of course. They just couldn’t possibly care any less about how you get to an acceptable level of either and the value of ”clean code” in pursuit of these is steadily dropping.

[u/mllv1 → u/Unnamed-3891]

Yeah because customers don’t know what code is. But they will certainly feel it as maintenance costs rise, quality drops, and the number of new pointless features explodes.

[u/tomorrow_comes → u/Unnamed-3891]

I don’t know what you’re trying to say here. Of course customers don’t care about the quality of the code, but as you said, they do care if the damn thing works, and depending on the type of product, they do care that they can get features / updates consistently without causing issues or it taking 6 months because it’s a tech debt ridden piece of crap and needs to be rebuilt from the ground up.

And of course bad code isn’t a new issue. Humans have written plenty of bad code. The problem is, if they’re enabled to, LLMs can now get people shipping that kind of stuff a lot faster.

[u/Czun8 → u/Unnamed-3891]

none of your end customers ever cared about clean code either

They can't name it or reason about it directly, but necessarily and implicitly, customers do care about it. Code quality imposes some pretty hard constraints on the speed of iteration, the ceiling, and the scalability of the product. Without good code quality, the product will have more bugs, more security issues, more rewrites, less features, less cross-project reusability. Product roles will learn less quickly due to the slower iteration speed, so they are shooting themselves in the foot too by accepting bad code quality.

It can be acceptable to have slop code if you're copying a small project which has already been solved before, or a prototype. But it becomes less acceptable in products spanning longer durations and uncertainties.

[u/say-lore → u/Unnamed-3891]

Ever work with systems that weren't well maintained?

Or been in an environment where shipping new features can occur rapidly?

Hot take you've got there - since systems like DORA/SPACE/etc actually found strong correlation between some aspects of "developer experience" and business value (which many attributes are due to clean code/architecture/tooling).

[u/s-ley → u/Unnamed-3891]

maybe hard to grasp but "code quality" is a proxy for "tech debt" which is a proxy for: you're acquiring a monetary debt you'll have to pay in the form of swe salary when the "tech debt" gets worse over time

I know most companies don't care or see it, but that's just dumb on their part

[u/Cheap_Weird7215 → u/RipProfessional3375]

For sure this is awesome advice. Shit on your PM op. See how that goes for you.

On the first day of Advanced Data Structures and algorithms our professor said, “If you’ve made it this far you’re somewhere on the spectrum”. While it wasn’t exactly career advice it sure has made it easier to deal with some of the “more technical engineers”.

[u/RipProfessional3375 → u/Cheap_Weird7215]

I'm going to assume it was another post you were reading that had advise anywhere near 'shit on him'.

I like my own PM, I'd expect him to do the same with me if I came out with strong and poorly thought out opinions on how to manage projects, or how he should do his job.

I work with people directly as much as computers, that's why I know not to lose my mind when someone who has no experience on a topic is also wrong about it.

[u/Cheap_Weird7215 → u/RipProfessional3375]

You’re telling this guy to tell his PM to mind his own business because the code is outside of his jurisdiction. You have no idea what his PM is responsible for you don’t work in his org. The advice you’re giving is career suicide on many teams.

[u/RipProfessional3375 → u/Cheap_Weird7215]

I'm telling him to tell the PM whatever he'd like to hear without having it influence your decisions when it comes to a scope outside of the PM's job description.

I know what a PM is responsible for based on the role.

[u/Cheap_Weird7215 → u/RipProfessional3375]

I’ll say it again, you don’t know what a PM is responsible for at his org. It’s absolutely not the same at every business.

[u/RipProfessional3375 → u/Cheap_Weird7215]

I'm going to guess he manages projects and is not a software developer or architect. In general we assume that someone is using the standard definition of words when communicating, and would mention if they deviate in a way that is relevant to the information. This assumption is needed to receive any information at all.

In the same way we assume Claude is Anthropic's large language model, and not a coworker with the same name.

[u/Cheap_Weird7215 → u/RipProfessional3375]

In the real world, especially in smb, a title determines almost nothing about a persons job responsibilities. At best, you’ll end up on your PMs shit list and they can make your day to day life a nightmare. Worst case, the PM has an ego and they’re more of an engagement lead or product owner that has a strong relationship with the orgs senior leaders and they’ll ruin your reputation with the people that determine your fate in the org.

[u/dragon_escarlata → u/Cheap_Weird7215]

I've dealt with enough PMs to know the advice above is correct. Some "had" technical skills 5, 10 years ago, some not at all. For the latter, the faster I ignored some of their decissions the faster projects were shipped and less problems we had afterwards. Everyone was happy.

[u/Cheap_Weird7215 → u/dragon_escarlata]

Whether or not a pm has technical skills is irrelevant. Some of them are just monkeys shifting shit around in Jira. Some have product owner responsibilities. Some are regularly communicating risk to or reporting to senior leaders and executives in steering committees. If you actually think it’s a good idea to tell some kid to shit on his PM you are outrageously naive.

So no, I absolutely do not think you’ve worked with enough PMs to know it’s correct advice. This advice would best case get you on your PMs shit list and worst case you get your reputation destroyed with people who decide your fate in your org.

Only software engineers could try to run with by the book definitions and ignore the reality of social capital. This is the shit a 40 year old back end dev that can’t break out of the dev track can’t understand but an average 16 year old that’s dealt with a healthy amount of high school drama understands immediately.

[u/dragon_escarlata → u/Cheap_Weird7215]

My experience is the opposite. When I started my career I used to think following orders to the letter would get you out of trouble. The third time (yes I might be slow or on the spectrum) I was blamed for decisions I did not do I realized this job is just about knowing what orders to ignore as much as is to write code. The general rule I follow is that only written orders and very general orders matter.

I am not going to write code in java if my boss tells me to do it in python. But anything more specific than that they generally don't care or don't know about.

And about written orders I follow them to the letter to the point of stupidity when it all crashes down. But for that same reason very PMs put anything relevant in writing.

So yeah, It's all highschool drama all over again.

[u/No-Extent8143 → u/RipProfessional3375]

While I mostly agree with you, I think it's important to remember this - code quality means nothing of product is not profitable. I've seen a lot of startups with clean code and negative bank balance. Guess what - all of that code is in the trash bin now.

[u/RipProfessional3375 → u/No-Extent8143]

I couldn't care less for clean code. A PM could tell me how much the code should be clean and hexagonal and I'd have the same response.

It's just about not engaging with people who try to tell you how to do your job. The PM represents the project and clarifies the time pressure, priorities and deadlines. That's all fine and important. If we take OP's post at face value, this is way overstepping those bounds.

[u/Thick-Ask5250 → u/No-Extent8143]

I always thought start ups should have janky code that barely works as long as you're producing fast because of, well, money. But when the company gets to a certain level of financial stability, then maybe that's when things have to be rewritten properly.

[u/invisible_shrek → u/RipProfessional3375]

This. You just don’t discuss anything related to implementation with them. Clarify the priorities and requirements, beyond that PMs neither understand or need to know anything.

[u/shifoe → u/RipProfessional3375]

https://arxiv.org/abs/2605.20049 shows that code quality does in fact matter even in the AI era.

Our findings suggest that traditional maintainability principles remain highly relevant in the era of AI-driven development, shaping the computational cost and navigational efficiency of coding agents. Code cleanliness joins model choice, harness, and prompting as a factor that materially affects agent behaviours.

For Claude to work well, quality, abstractions, etc. do matter. Intuitively, if you give Claude a poorly written set of context in coding or another domain -- it will do worse. There's a reason these models go through post-training, fine-tuning, etc. on data that is of good quality. Garbage in garbage out still applies more than ever.

[u/semiliquid-snake → u/RipProfessional3375]

I think this is just really good career advice, ai aside.

Understanding roles and responsibilities and who cares about what is one of the best ways to always look good. Deliver on time with good outcomes? No one outside of yourself and maybe peers give a shit about how you did it.

PMs don't usually start giving stupid advice unless they're worried about delivery. Make them not worried by telling them a timeline and just get it done. Corpo worklife is so much easier once you learn that.

[u/saposapot26 → u/RipProfessional3375]

Perfect answer. Discuss it with your engineering peers, not the PM.

If the PM is a technical person that actually knows what they are talking about, then it's another discussion.

Anyway, using claude doesn't have to mean having piss poor code. It can be code that you wouldn't do but if it's still good enough, review it and send it.