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.
> 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 think that's true but it's a special case. AI is here to stay and with AI coding IS faster and quality is better than ever before. Ideally you want your luddite fired along with the slop generators and keep the ones who are using AI and taking their time to deliver a maintainable code.
> ... with AI coding IS faster and quality is better than ever before.
Is this claim based on something?
I'm not against or "for" AI (whatever that means), I try to use it as effectively I can, but for me it's not at all obvious that quality is better than ever before.
Speed I can buy, especially in new projects and utilities, but quality? At least I haven't seen this in practice, if anything I'm just seeing more code, issues, PR's and pressure ==> more slop, more bugs, less quality.
You can always say "skill issue" and "process issue", but that's partly my point here, AI doesn't magically solve this.
Presumably it is based on that person's personal experiences, like your own comment and all the other comments here?
Speaking for myself, based on my own personal experiences, quality is by far the bigger advantage of these tools. It has never ever been easier to write automated tests and to automate tedious manual validation. I'm running my code through like 10x more paces than I ever did before, because I can just say "hey try running this in these twenty different ways" (including with browser automation, if that's relevant), without needing to either do the tedious steps to run all that or to take the time to write a script to do it, and to compile and attach the findings to the PR. This saves me hours to days of work on validation, but the reality is that I just wouldn't have spent that time in the past, I just stopped at a lower bar for quality, because I couldn't justify the ROI for spending all that time on it. But now the ROI is huge, so it's a no brainer.
If people are not taking advantage of this, then yes, that is literally a skill issue.
> If people are not taking advantage of this, then yes, that is literally a skill issue.
...or domain. You said "including with browser automation", so you do web or web-adjacent development.
Not all of us are doing that. What I work on doesn't have any UI or output besides a log file most of the time, but it connects to many places and does many things like an octopus, but nobody sees that, but feels that it's there because their environment keeps on working.
I said "if that's relevant" and you jumped to "this guy just makes websites". I do many things.
The octopus you just described sounds to me like an excellent example of what having the ability to more easily do tedious validation is most useful for. If you know that the "environment keeps on working", there must be some way for you to observe that fact. And if it is an octopus, it is likely difficult and/or to change the conditions and observe the correctness with respect to those changes. I find it so much easier to do this exact kind of thing now. Or, "easier" really isn't the right word. It's that the activation energy is low enough now that I'm able to do a lot of things up front that I used to rely on runtime monitoring to validate.
I guess YMMV, and it's not magic, but for me it totally changes the calculation on when it makes sense to automate something (like that chart from the old xkcd about how many times you'll do the thing and how long it takes to automate) in a way that means I'm doing a bunch of things that are useful for quality that just would never have passed the bar in the past.
> I said "if that's relevant" and you jumped to "this guy just makes websites". I do many things.
I didn't. I made a guess. I might be wrong, that's OK. I love to be wrong, because I learn things by being wrong. Also no offense was intended, and I don't consider webdev inferior anything. What I tried to mean is, if AI has more training data for a domain, it does better. If you fire the same model on a niche domain, it falls flat.
> If you know that the "environment keeps on working", there must be some way for you to observe that fact.
Yes.
> And if it is an octopus, it is likely difficult and/or to change the conditions and observe the correctness with respect to those changes.
Nope. On the contrary, because there's so much innate knowledge that is required to know what to do, simulating in mind, deploying and testing on real world is much easier and faster than letting loose an ML model on it. You need real data, real data comes in slow, but you can catch problems early and easily.
Considering it's a niche area, AI also doesn't have much training on that domain, so it's doubly inapplicable for what we do.
> but for me it totally changes the calculation on when it makes sense to automate something ... (snipped for brevity)
It's great that if it works for you, but YMMV part is way more correct than people want to accept and want to learn. AI is a pneumatic hammer, but not everything is a nail which can be driven in with that.
When it works, it works. When it doesn't, well people still pretend it does or insists it shall. We must accept the limitations.
> deploying and testing on real world is much easier and faster than letting loose an ML model on it.
No this is what you're not getting. It is "doing the things I would do to deploy and test in the real world, but faster and in the background while I do other things", it is not "letting loose an ML model on it". This is the new capability. If you have any process like "do {action}, wait until {something}, check {something}, determine if it matches expectation", it is now possible to run that loop way more times in way more variants without either spending the time on it synchronously oneself or writing a script to do it. (If you do that specific action loop often enough, it's probably worth writing the script anyway, but that's also much quicker to do now.)
The AI doesn't need training on the domain, it just needs to be told "these are the things I would do, please do them for me and report back".
I'm sympathetic to not everything being nail-like, but I really think you're leaving a lot of chips on the table if you can't imagine any of this kind of action-check-evaluate loop you have that you could offload.
I'm saying you could do more things. Instead of waiting until a new thing is merged so that it can be deployed and waiting for monitoring to catch issues, you could be deploying pre-merge to testbeds, using different variants of the code or different configurations of the whole system or different inputs to exercise edge and corner cases. Maybe it's too complex of a system to set up that kind of testbed or simulation? Well, it's easier to do that now too! I can spin up and down environments, either with containers on my workstation, or in cloud deployments, that I would have not attempted in the past, because it would have taken me too long to set them up. But now it doesn't take that long, and I find it super valuable to be able to try more things out. (Cost is still a real constraint, I'm not saying that constraints magically no longer exist.)
Obviously I have no idea what your work looks like! But what I'm saying is that time savings are not just time savings. There can be a point at which the time savings bring you under an "activation energy" such that it unlocks a new capability, not just a speedup. And some of those unlocked capabilities can be directed toward improving the quality of software. And I think that's awesome and useful, is my prevailing point here. I won't claim that it will usher in an industry wide improvement in quality or anything, but for me personally, I'm making better software more quickly now, and I'm very pleased that I can do that.
For some reason this reminds me A LOT of past discussions about microservices, most wonderful on paper, but I've never seen it work out perfectly in practice, for me it's mostly been a cluster F in most companies that adopted them.
Currently I see AI similarly, in theory perfect, in practice I don't see the claimed effects. So yes, skill issue, but skills are relevant and your company probably can't hire a rockstar team (if that matters in the future).
But your comment on personal experiences was very good! Spot on, we are all biased, easy to forget. Thank you for that.
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.
abroszka33 · · focus · HN ↗
I think that's true but it's a special case. AI is here to stay and with AI coding IS faster and quality is better than ever before. Ideally you want your luddite fired along with the slop generators and keep the ones who are using AI and taking their time to deliver a maintainable code.
tripledry · · focus · HN ↗
Is this claim based on something?
I'm not against or "for" AI (whatever that means), I try to use it as effectively I can, but for me it's not at all obvious that quality is better than ever before.
Speed I can buy, especially in new projects and utilities, but quality? At least I haven't seen this in practice, if anything I'm just seeing more code, issues, PR's and pressure ==> more slop, more bugs, less quality.
You can always say "skill issue" and "process issue", but that's partly my point here, AI doesn't magically solve this.
sanderjd · · focus · HN ↗
Speaking for myself, based on my own personal experiences, quality is by far the bigger advantage of these tools. It has never ever been easier to write automated tests and to automate tedious manual validation. I'm running my code through like 10x more paces than I ever did before, because I can just say "hey try running this in these twenty different ways" (including with browser automation, if that's relevant), without needing to either do the tedious steps to run all that or to take the time to write a script to do it, and to compile and attach the findings to the PR. This saves me hours to days of work on validation, but the reality is that I just wouldn't have spent that time in the past, I just stopped at a lower bar for quality, because I couldn't justify the ROI for spending all that time on it. But now the ROI is huge, so it's a no brainer.
If people are not taking advantage of this, then yes, that is literally a skill issue.
bayindirh · · focus · HN ↗
...or domain. You said "including with browser automation", so you do web or web-adjacent development.
Not all of us are doing that. What I work on doesn't have any UI or output besides a log file most of the time, but it connects to many places and does many things like an octopus, but nobody sees that, but feels that it's there because their environment keeps on working.
sanderjd · · focus · HN ↗
The octopus you just described sounds to me like an excellent example of what having the ability to more easily do tedious validation is most useful for. If you know that the "environment keeps on working", there must be some way for you to observe that fact. And if it is an octopus, it is likely difficult and/or to change the conditions and observe the correctness with respect to those changes. I find it so much easier to do this exact kind of thing now. Or, "easier" really isn't the right word. It's that the activation energy is low enough now that I'm able to do a lot of things up front that I used to rely on runtime monitoring to validate.
I guess YMMV, and it's not magic, but for me it totally changes the calculation on when it makes sense to automate something (like that chart from the old xkcd about how many times you'll do the thing and how long it takes to automate) in a way that means I'm doing a bunch of things that are useful for quality that just would never have passed the bar in the past.
bayindirh · · focus · HN ↗
I didn't. I made a guess. I might be wrong, that's OK. I love to be wrong, because I learn things by being wrong. Also no offense was intended, and I don't consider webdev inferior anything. What I tried to mean is, if AI has more training data for a domain, it does better. If you fire the same model on a niche domain, it falls flat.
> If you know that the "environment keeps on working", there must be some way for you to observe that fact.
Yes.
> And if it is an octopus, it is likely difficult and/or to change the conditions and observe the correctness with respect to those changes.
Nope. On the contrary, because there's so much innate knowledge that is required to know what to do, simulating in mind, deploying and testing on real world is much easier and faster than letting loose an ML model on it. You need real data, real data comes in slow, but you can catch problems early and easily.
Considering it's a niche area, AI also doesn't have much training on that domain, so it's doubly inapplicable for what we do.
> but for me it totally changes the calculation on when it makes sense to automate something ... (snipped for brevity)
It's great that if it works for you, but YMMV part is way more correct than people want to accept and want to learn. AI is a pneumatic hammer, but not everything is a nail which can be driven in with that.
When it works, it works. When it doesn't, well people still pretend it does or insists it shall. We must accept the limitations.
sanderjd · · focus · HN ↗
No this is what you're not getting. It is "doing the things I would do to deploy and test in the real world, but faster and in the background while I do other things", it is not "letting loose an ML model on it". This is the new capability. If you have any process like "do {action}, wait until {something}, check {something}, determine if it matches expectation", it is now possible to run that loop way more times in way more variants without either spending the time on it synchronously oneself or writing a script to do it. (If you do that specific action loop often enough, it's probably worth writing the script anyway, but that's also much quicker to do now.)
The AI doesn't need training on the domain, it just needs to be told "these are the things I would do, please do them for me and report back".
I'm sympathetic to not everything being nail-like, but I really think you're leaving a lot of chips on the table if you can't imagine any of this kind of action-check-evaluate loop you have that you could offload.
bayindirh · · focus · HN ↗
Everything is already at the background. That thing doesn’t need a CI, not the classical or AI enabled kind.
Maybe I was not clear about that part of what I do. Three minutes of something not working correctly doesn’t burn our world down.
sanderjd · · focus · HN ↗
Obviously I have no idea what your work looks like! But what I'm saying is that time savings are not just time savings. There can be a point at which the time savings bring you under an "activation energy" such that it unlocks a new capability, not just a speedup. And some of those unlocked capabilities can be directed toward improving the quality of software. And I think that's awesome and useful, is my prevailing point here. I won't claim that it will usher in an industry wide improvement in quality or anything, but for me personally, I'm making better software more quickly now, and I'm very pleased that I can do that.
tripledry · · focus · HN ↗
For some reason this reminds me A LOT of past discussions about microservices, most wonderful on paper, but I've never seen it work out perfectly in practice, for me it's mostly been a cluster F in most companies that adopted them.
Currently I see AI similarly, in theory perfect, in practice I don't see the claimed effects. So yes, skill issue, but skills are relevant and your company probably can't hire a rockstar team (if that matters in the future).
But your comment on personal experiences was very good! Spot on, we are all biased, easy to forget. Thank you for that.
sanderjd · · focus · HN ↗