I think looking at AI usage for code and development from an engineering perspective is going to be an exercise in frustration. I'm a software engineer for 20+ years and I've pivoted to using AI for my code 100%. I find it invaluable about the only way to stay relevant and run a business nowadays. Happy for anyone to disagree with me, because I don't want to be right for the first time in my life.
That said, my experience tells me that enterprise and business coding has rarely ever been about stable or robust codebases. We engineers and a fraction of competent engineering managers and a vanishing small number of directors fought against business interests to ensure quality was priority when it came to code, but it was always an uphill battle and we were oftentimes disciplined for spending too much time on quality and design.
A timed cadence of release is anathema to quality code because you can't timebox it.
So, AI is just the extension of that. Do I try to ensure my agents design code I would consider to be good? Yes, absolutely! But I've fully outsourced it and I find it's also fully capable of fixing it's own mistakes. I've gone far beyond anything I individually or even with a team was ever capable of with AI assistance, so I believe I just have to apply my experience and skills into management and architecture rather than actual lines of code.
Time only will tell how this plays out.
Wallaahu aʿlam.
basilgohar
This reads like a piece of content written a year ago. Things have radically changed since then.
"AI writes shallow tests" - used to be true, not true anymore since Astra and Fable 5.1 / Opus 5.5.
"AI writes overly complex ccode" - only if you let it. A "do not overengineer it" or "Pareto, 80% result with 20% of effort" go a long long way.
"Reliance on AI decreases human understanding" - human understanding does not decrease, it just moves up a level or two. The same way you do not really understand how the Linux kernel works, nor do you know how assembly really works (with probably a bunch of exceptions here given this is the HN crowd!). And then there is hardware and physics too.
Understanding code, algorithms and data structures becomes a rarer need than it used to be.
"AI moves too quickly to maintain a high quality bar" - if you are stuck with the mantra that humans must review the code today, then obviously that statement becomes true. The problem is the assumption, not the observation. The good news about AI progressing fast is that coding AND reviewing get better and better with each release.
I know it is tough to let go. But as a software engineer, the sooner you do it, the quicker you will learn to yield a much, much more powerful weapon.
iagooar
Code quality is not an issue.....until it is. Everyone will be happy if things seem to be working and moving fast, it's only until you start seeing symptoms like not being able to change things without breaking existing features or even seeing an increase in tokens burned for reading complex code bases that you will start caring about code quality (which i imagine now people will just have AI try to fix it's own mess).
monjerry
I'm not sure that "AI generates..." articles are going to age well.
My immediate question would be what kind of adversarial reviews and deterministic gates did the author write to capture the dimensions of maintainability (lack of DRY, cyclomatic complexity, unclear naming, poorly architected flows, etc) that they cared about.
Don't get me wrong. When I was speeding along at 200 PRs a day (personal projects - I would not have inflicted them on others) I pretty quickly slopped together a big ball of mud, but as I'm re-generating my estate (a) the models are a little better but (b) I'm adding a lot more rigor around verification (correctness, performance, security, operational costs and maintainability). It's not an easy problem to solve, but it feels to me like an engineering endeavor, not speculative rocket science.
I fully understand that many AI generated code bases do indeed suffer from more incidents and less maintainability, but I think it's important to distinguish between what is common and what is possible as the fix for one is improving the rigor of your verification whereas the fix for the other would be either accepting crappy code or giving up on LLMs.
peterbell_nyc
I don't disagree with the article but it may give some readers the impression that pre-AI hand-written code wasn't fragile.
Every big company codebase with millions of lines devolves into a similar state. The small codebase starts with clean conceptual integrity. It then inevitably decays into incomprehensible spaghetti code as more people are added to it. Various reasons for it including the later devs caring less about the code than the initial team of devs, deadlines, avoiding refactoring because of fear about breaking things, etc.
If you don't want AI to create fragile code, you have to apply the same quality gates that would have been applied to pre-AI hand-written code to keep everything clean. Most companies don't do that.
jasode
I don't think this matters anymore. Software is becoming a black box and agents make it works, as long as you can provide some reasonable spec of what you want to do, and a bit of supervising and directions.
Right now, they're not great at following good software engineering principles. They do the job, with verbose code, lots of duplication, abstraction leaks, useless unit tests and so on.
Is it an issue? you could think that in the long term it'll be, that AI won't be able to handle the complexity it introduced, but I'm not really worried about it. Most software isn't that big, and agents are getting better by the day. And if you really care about design, it's not too hard to instruct your agent to follow your standards.
I wish it wasn't the case and that I could justify my experience and expertise for a few more years, but the facts are there.
yodsanklai
The term "injection molded coding" has been bouncing around my head lately. I empathize and have personally experienced the fragility and opaqueness the OP describes. But I wonder if we're like master carpenters, grieving as we inspect a warm plastic chair leg, fresh from the injection mold, wondering what the future of furniture making will look like when each chair leg is mass-produced, and not lovingly carved by hand.
momojo
I've been saying this for a while. Programming has been unbelievably underestimated, almost as much as art (i.e. everyone thinks they are an artist when having opinions but rarely understand anything about it).
Programming is about engaging with high level mathematical abstractions.
To the extent AI can do this high level thinking, it is going to be able to do absolutely everything else humans can. Programming (when not underestimated) is as hard as the hardest cognitive task humans can do.
proc0
One of the things AI reduces is curious engineers futzing around in the codebase, which is a great way to find dead code, suboptimal structures, etc. With AI that's all gone.
a34729t
I think we're going to see more efforts made in static analysis / linters.
> For instance, I saw one of the best programmers on my team try to merge code that used javascript events for mouseover CSS effects rather than using the :hover selector, which is a totally unscalable way of writing mouseovers.
Alright, can static analysis find the mouseover JS events and fail a linter as a result? Maybe in the past this would have been overkill or would have triggered very rarely if ever, but in an AI-written codebase, this helps catch it and point the agent harness to rewrite it.
comments (10)
That said, my experience tells me that enterprise and business coding has rarely ever been about stable or robust codebases. We engineers and a fraction of competent engineering managers and a vanishing small number of directors fought against business interests to ensure quality was priority when it came to code, but it was always an uphill battle and we were oftentimes disciplined for spending too much time on quality and design.
A timed cadence of release is anathema to quality code because you can't timebox it.
So, AI is just the extension of that. Do I try to ensure my agents design code I would consider to be good? Yes, absolutely! But I've fully outsourced it and I find it's also fully capable of fixing it's own mistakes. I've gone far beyond anything I individually or even with a team was ever capable of with AI assistance, so I believe I just have to apply my experience and skills into management and architecture rather than actual lines of code.
Time only will tell how this plays out.
Wallaahu aʿlam.
basilgohar
"AI writes shallow tests" - used to be true, not true anymore since Astra and Fable 5.1 / Opus 5.5.
"AI writes overly complex ccode" - only if you let it. A "do not overengineer it" or "Pareto, 80% result with 20% of effort" go a long long way.
"Reliance on AI decreases human understanding" - human understanding does not decrease, it just moves up a level or two. The same way you do not really understand how the Linux kernel works, nor do you know how assembly really works (with probably a bunch of exceptions here given this is the HN crowd!). And then there is hardware and physics too.
Understanding code, algorithms and data structures becomes a rarer need than it used to be.
"AI moves too quickly to maintain a high quality bar" - if you are stuck with the mantra that humans must review the code today, then obviously that statement becomes true. The problem is the assumption, not the observation. The good news about AI progressing fast is that coding AND reviewing get better and better with each release.
I know it is tough to let go. But as a software engineer, the sooner you do it, the quicker you will learn to yield a much, much more powerful weapon.
iagooar
monjerry
My immediate question would be what kind of adversarial reviews and deterministic gates did the author write to capture the dimensions of maintainability (lack of DRY, cyclomatic complexity, unclear naming, poorly architected flows, etc) that they cared about.
Don't get me wrong. When I was speeding along at 200 PRs a day (personal projects - I would not have inflicted them on others) I pretty quickly slopped together a big ball of mud, but as I'm re-generating my estate (a) the models are a little better but (b) I'm adding a lot more rigor around verification (correctness, performance, security, operational costs and maintainability). It's not an easy problem to solve, but it feels to me like an engineering endeavor, not speculative rocket science.
I fully understand that many AI generated code bases do indeed suffer from more incidents and less maintainability, but I think it's important to distinguish between what is common and what is possible as the fix for one is improving the rigor of your verification whereas the fix for the other would be either accepting crappy code or giving up on LLMs.
peterbell_nyc
Here's the famous commentary about Oracle RDBMS codebase of 25 million lines: https://news.ycombinator.com/item?id=18442941
Every big company codebase with millions of lines devolves into a similar state. The small codebase starts with clean conceptual integrity. It then inevitably decays into incomprehensible spaghetti code as more people are added to it. Various reasons for it including the later devs caring less about the code than the initial team of devs, deadlines, avoiding refactoring because of fear about breaking things, etc.
If you don't want AI to create fragile code, you have to apply the same quality gates that would have been applied to pre-AI hand-written code to keep everything clean. Most companies don't do that.
jasode
Right now, they're not great at following good software engineering principles. They do the job, with verbose code, lots of duplication, abstraction leaks, useless unit tests and so on.
Is it an issue? you could think that in the long term it'll be, that AI won't be able to handle the complexity it introduced, but I'm not really worried about it. Most software isn't that big, and agents are getting better by the day. And if you really care about design, it's not too hard to instruct your agent to follow your standards.
I wish it wasn't the case and that I could justify my experience and expertise for a few more years, but the facts are there.
yodsanklai
momojo
Programming is about engaging with high level mathematical abstractions.
To the extent AI can do this high level thinking, it is going to be able to do absolutely everything else humans can. Programming (when not underestimated) is as hard as the hardest cognitive task humans can do.
proc0
a34729t
> For instance, I saw one of the best programmers on my team try to merge code that used javascript events for mouseover CSS effects rather than using the :hover selector, which is a totally unscalable way of writing mouseovers.
Alright, can static analysis find the mouseover JS events and fail a linter as a result? Maybe in the past this would have been overkill or would have triggered very rarely if ever, but in an AI-written codebase, this helps catch it and point the agent harness to rewrite it.
solatic