There's a continuum between "vibe coded by someone with no technical knowledge or inclination" and "hand written domain driven design development". You can absolutely use coding agents AND have maintainable code. But yes, the coding agents will not magically make everything maintainable if you don't tell them to.
"Code maintainability and good architecture don’t have good measurements that we can apply"
Who has no wisdom? There are dozens of ways to measure code maintainability. Cyclomatic complexity is just one.
Nothing stops you from wiring up something like SonarQube metrics to your agentic coding workflow.
> You can absolutely use coding agents AND have maintainable code. But yes, the coding agents will not magically make everything maintainable if you don't tell them to.
The trillion dollar question is how you do this, if your employees do not care (they are optimising for salary & time spent not code quality) and you have no way of telling apart AI slop vs. good maintainable code. (If you could you would just train the AI.)
Before AI there was at least some way to tell apart good programmers from bad, because there was some human effort involved in coding. Now with AI and slop generation there is almost now way to do this.
> if your employees do not care (they are optimising for salary & time spent not code quality)...
From what I see is it's mainly managers and higher brass who doesn't care about code quality and sustainability, and aims to drive time to market metrics down aggressively with AI.
Any employee who cares about code quality will become a poor performer with a red luddite label because they dare to change what the AI has emitted for them.
I'd love to be wrong, very wrong about this, actually.
I often have to ask myself if I’m asking for something different because of preference or need. I don’t really know what others are doing but I see this comment a lot about needing to always correct agents. I can’t figure out if it’s an exaggeration or not because once I’ve planned how I want something done I pretty much have zero need to intervene.
Impossible to know without doing a detailed comparison. Are you using the same LLMs? Are your criteria for correcting the output the same? Are you working on similar code? Are your plans and prompts the same?
It's fine to have preferences. The biggest problem with bikeshedding is the time spent (wasted) debating. But you don't have to debate the AI, you just tell it your preferences, and ideally encode them so that they are repeatable.
Of course it's fine to have preferences. I think you missed the nuance. Bikeshedding implies the time is wasted because the topic wasn't important in the first place. The color of the bike shed, as it were, has nothing to do with the storing of the bikes.
I am equating the nerve that develops in people that get lost bikeshedding (wasting time on inconsequential parts of the problem) with fighting an llm on inconsequential implementation details.
We most certainly agree: what matters should always be the actual requirements (functional, security, performance, etc.) You can't bikeshed an important topic. Everything else is implementers decision. In my experience an experienced engineer understands the difference and trusts implementers to make the decisions that they do own.
No I understand the nuance. But it's only bad to have preferences that barely matter if you waste time on them. You don't have to fight the llm, you just tell it what you prefer and it does that, that's what's great about them. (If it is not listening to your directives, then you have other problems.)
You use the intentionally vague word "implementers" to abstract whether you're delegating to a human or to an AI. But the key point is that these are not the same thing. If I'm delegating to a person, that person is the "implementer". If I'm using an AI to generate an implementation, I am still the "implementer", it is merely a computer program working on my behalf.
Directing an AI's work is not "fighting it". You keep characterizing it that way, but it's the wrong characterization. "Implementer" is not blurry at all. Humans are responsible for the things they implement, whether or not they use AI tooling to do that implementation.
Is that my characterization? This subthread is about how it’s so time consuming fixing every little thing the AI does to be just like you would have done. My challenge to that sentiment is “give it some freedom, don’t micromanage it.” That’s all.
I understand the boundaries of ownership and responsibility. That’s why I can tell you if you are spending inordinate amounts of time correcting AI code then you’re doing something wrong. Either write the code yourself or reassess your ownership boundaries. You’re acting as a manager of a team of agents in an agentic coding paradigm. Managers don’t tell me how to write code.
Without going and re reading the whole thread, I'm pretty sure that both of your comments that I replied to included this "fighting the AI" characterization. It's certainly fair that you didn't start the thread about it but were just taking the premise of the sub thread. But I just disagree with that whole premise. I think what's nice about these tools is that I can just write a document that says things like "prefer immutability" and then I neither need to micromanage nor accept code I don't like, and there is no long slack that about whether I'm right about any of the things I've written into those rules, the AIs are happy to do as I've asked.
I think this entire analogy about being a manager of a team of agents that is in vogue is completely misguided. Have I always been the manager of a team of bash scripts? No. These tools are way more capable, but they are still just tools that I'm using to do my own work, they are not people that I'm delegating responsibility to.
> I think what's nice about these tools is that I can just write a document that says things like "prefer immutability" and then I neither need to micromanage nor accept code I don't like
Why are we even arguing then? You and I agree. Did I ever say "don't share a single preference with the AI"? You set the guardrails and preferences and the AI follows them. This is how it's always worked so it's reasonable for me to assume that people "fighting the AI" have already done this and are being overly pedantic about the output. Otherwise it wouldn't be eating up inordinate amounts of time...
> Have I always been the manager of a team of bash scripts? No.
No. You're not even remotely close here. Let's revisit this once you've figure out how to have a team of bash scripts implement 100k lines of code and build entire systems in 2 weeks based on high level instructions and requirements shared in context and prompts. You have responsibility at a different level and scale in an AI native workflow.
I don't know why we're arguing about the first thing :)
But we have a real disagreement about the second thing. You don't "have responsibility at a different level and scale in an AI native workflow", you're still using tools. I understand that what you're saying is that it's such a difference in scale that it is a difference in kind. But I don't agree. I'm fundamentally at odds with this entire framing of ai agents as a team that is being managed. I don't like any of the anthropomorphizing of ai tools. It's fine if it's just an analogy, but people take it way too seriously as a real thing IMO. I fully recognize that I'm out of step with the prevailing discourse on this, but it's a genuine disagreement, I'm not confused about what other people think.
"Hey look I got this brand new tool it can do everything my old tools did and more but I'm scared to use it to do more--might shoot myself in the foot."
I think most people have felt that way before. Only way forward is to practice with the new tool (=
davedx · · focus · HN ↗
"Code maintainability and good architecture don’t have good measurements that we can apply"
Who has no wisdom? There are dozens of ways to measure code maintainability. Cyclomatic complexity is just one.
Nothing stops you from wiring up something like SonarQube metrics to your agentic coding workflow.
abroszka33 · · focus · HN ↗
The trillion dollar question is how you do this, if your employees do not care (they are optimising for salary & time spent not code quality) and you have no way of telling apart AI slop vs. good maintainable code. (If you could you would just train the AI.)
Before AI there was at least some way to tell apart good programmers from bad, because there was some human effort involved in coding. Now with AI and slop generation there is almost now way to do this.
bayindirh · · focus · HN ↗
From what I see is it's mainly managers and higher brass who doesn't care about code quality and sustainability, and aims to drive time to market metrics down aggressively with AI.
Any employee who cares about code quality will become a poor performer with a red luddite label because they dare to change what the AI has emitted for them.
I'd love to be wrong, very wrong about this, actually.
duncan-donuts · · focus · HN ↗
graemep · · focus · HN ↗
dcow · · focus · HN ↗
sanderjd · · focus · HN ↗
dcow · · focus · HN ↗
I am equating the nerve that develops in people that get lost bikeshedding (wasting time on inconsequential parts of the problem) with fighting an llm on inconsequential implementation details.
We most certainly agree: what matters should always be the actual requirements (functional, security, performance, etc.) You can't bikeshed an important topic. Everything else is implementers decision. In my experience an experienced engineer understands the difference and trusts implementers to make the decisions that they do own.
sanderjd · · focus · HN ↗
You use the intentionally vague word "implementers" to abstract whether you're delegating to a human or to an AI. But the key point is that these are not the same thing. If I'm delegating to a person, that person is the "implementer". If I'm using an AI to generate an implementation, I am still the "implementer", it is merely a computer program working on my behalf.
dcow · · focus · HN ↗
sanderjd · · focus · HN ↗
dcow · · focus · HN ↗
I understand the boundaries of ownership and responsibility. That’s why I can tell you if you are spending inordinate amounts of time correcting AI code then you’re doing something wrong. Either write the code yourself or reassess your ownership boundaries. You’re acting as a manager of a team of agents in an agentic coding paradigm. Managers don’t tell me how to write code.
sanderjd · · focus · HN ↗
I think this entire analogy about being a manager of a team of agents that is in vogue is completely misguided. Have I always been the manager of a team of bash scripts? No. These tools are way more capable, but they are still just tools that I'm using to do my own work, they are not people that I'm delegating responsibility to.
dcow · · focus · HN ↗
Why are we even arguing then? You and I agree. Did I ever say "don't share a single preference with the AI"? You set the guardrails and preferences and the AI follows them. This is how it's always worked so it's reasonable for me to assume that people "fighting the AI" have already done this and are being overly pedantic about the output. Otherwise it wouldn't be eating up inordinate amounts of time...
> Have I always been the manager of a team of bash scripts? No.
No. You're not even remotely close here. Let's revisit this once you've figure out how to have a team of bash scripts implement 100k lines of code and build entire systems in 2 weeks based on high level instructions and requirements shared in context and prompts. You have responsibility at a different level and scale in an AI native workflow.
sanderjd · · focus · HN ↗
But we have a real disagreement about the second thing. You don't "have responsibility at a different level and scale in an AI native workflow", you're still using tools. I understand that what you're saying is that it's such a difference in scale that it is a difference in kind. But I don't agree. I'm fundamentally at odds with this entire framing of ai agents as a team that is being managed. I don't like any of the anthropomorphizing of ai tools. It's fine if it's just an analogy, but people take it way too seriously as a real thing IMO. I fully recognize that I'm out of step with the prevailing discourse on this, but it's a genuine disagreement, I'm not confused about what other people think.
dcow · · focus · HN ↗
I think most people have felt that way before. Only way forward is to practice with the new tool (=