Live data from Hacker News

An AI coding agent, used to write code, needs to reduce your maintenance costs

jamesshore.com

61–70 of 126 posts

Re: An AI coding agent, used to write code, needs to reduce your maintenance costs

#61
Then use AI for maintenance. It's AI all the way down. AI is taking over. AI is going to win and there's no stopping it. You're going to be left behind forever if you don't use AI right now. In fact, you may be too far behind already to start.

Did I do that right? ;)

Anyway, AI maintenance can be a time saver if the maintenance is easy. Like upgrading a dependency and all you really need to do is fix imports on five hundred files and modify a method or two. That would have been time consuming, but it's not hard. I think the OP has hit a good point though. Writing code is the fun part, not the bottleneck. The pain is the maintenance, so let's apply the AI there and keep having the fun to ourselves.

Re: An AI coding agent, used to write code, needs to reduce your maintenance costs

#62
I really like this question:

If you could wish for a codebase, which codebase would you wish for?

If you think a second on that question, you’ll realize you probably not wishing for a super feature-rich one, but an easy to understand one, quite close to what you have now. One that is easily to maintain and extend, depending on the upcoming business challenges.

Re: An AI coding agent, used to write code, needs to reduce your maintenance costs

#65
The strongest signal I have seen for whether AI actually reduces maintenance cost is whether the developer treats AI output as a first draft or a final artifact.

When I use AI tools on existing codebases - understanding unfamiliar modules, generating targeted refactors, writing migration scripts - the maintenance burden genuinely drops. The AI is working on code I already understand architecturally, so I can evaluate its output quickly.

The problem shows up when AI generates greenfield code that nobody deeply understands. That code still has to be maintained by humans who did not write it AND did not design it. At least with code another human wrote, you can reason about their intent from naming, structure, and commit history. AI-generated code often lacks that legibility because the "author" had no persistent intent across files.

The article is right that we need to measure maintenance cost, not just velocity. In practice that means tracking time-to-understand and change-failure-rate on AI-assisted code vs. human-written code over months, not days.

Re: An AI coding agent, used to write code, needs to reduce your maintenance costs

#66

I feel like the exponential growth of the models will make this a non-issue in the future. So the tweaks we might make right now might not be even more with when even more powerful models in the future come.

exponential what? Marketing aside in day-to-day use models get worse, not better.

Re: An AI coding agent, used to write code, needs to reduce your maintenance costs

#67
post #62

I really like this question: If you could wish for a codebase, which codebase would you wish for? If you think a second on that question, you’ll realize you probably not wishing for a super feature-rich one, but an easy to understand one, quite close to what you have now. One that is easily to maintain and extend, depending on the upcoming business challenges.

Code doesn't exist in a vacuum though.

Code bases that you "work in" (maintain, etc) solve real world problems, and solving those problems should trump cleanliness every time

Codebases that are clean are typically showcase examples that sit on a shelf to be admired and appreciated.

Re: An AI coding agent, used to write code, needs to reduce your maintenance costs

#68
post #40

Insightful. Agree with this take. Unfortunately, maintainability is simply bucketed as a "non-functional" requirement. Maintainability (and similar NFRs) should actually be considered what preserves and enables the delivery of future functional requirements -- in contrast to framing non-functional requirements as simply "how" the software must do what it does vs. the "what"/functional requirements that "actually matt…

I've found the first, and most important, step for any team or organisation to eliminate concerns with NFRs, "tech debt", and whatever else it may be called, is to stop giving it a name. I'm being completely serious. By giving it some kind of distinct name, you are giving license to it being ring-fenced and de-prioritised by someone who doesn't (but, arguably, probably should) know better. Quality matters. It hits yo…

This is so important. This is your job as a software engineer. It shouldn't exist on a roadmap or get added to tickets. It should just be done in the course of your work.

If it does end up as a ticket that means you did something wrong in the implementation of a feature and that lack of quality got noticed. A business person is not qualified to weigh in on the importance of these things. All they know is "The page needs to load in $time", "The data should stay consistent", ...

You are the one who determines the how and quality maintenance is on you.

Re: An AI coding agent, used to write code, needs to reduce your maintenance costs

#69
In my Dconf'24 talk "Software as investment" I proposed a basic framework based upon a value function (compositional) for each piece of software. This framework doesn't really need an update due to AI, apart from the (unrelated!) cost model being updated depending on how good AI is at maintenance. Apparently it would do 1.7x the number of bugs, but perhaps it fixes them faster too? I don't know.

Seeing software as investment avoids speaking about "technical debt" by speaking about "value", a liability just being an asset with < 0 value. When software exits the high-margin world of yesterday it needs to develop a precise definition of what software deserves to exist, economically.

Re: An AI coding agent, used to write code, needs to reduce your maintenance costs

#70

Earlier quoted context omitted.

No kidding. AI does all the interesting problem solving and humans... Write tests. The most boring activity on the planet

I wasn’t talking about unit tests. Was talking about tests that accelerate development, where you can setup everything and test a feature by just pressing enter vs clicking around or whatever. The tests are how you build features, so I don’t consider that boring There is problem solving in coding, but the bigger problems exist at a higher level and that’s still on you to solve. Also I’ve been messing with “ai-only” f…

I'm aware that I'm probably an outlier, but implementing the solution is the actual rewarding part for me

AI does nothing for me there. Coming up with the hypothetical solution and having AI build it does nothing for me

I like to build

Post reply on HN