Hacker News new | ask | show | jobs
by lacymorrow 36 days ago
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.

1 comments

There's a third mode that works better: structured phases (scoped to each feature, like humans do). (Plan phase => human reviews plan) => (Implement phase => human reviews diff) => (Test phase => tests run). The current TUI tooling gives you the option to do this type of bite-size scoping but you have to enable plan mode and not auto-accept edits. I've been taking the (enhanced) phased approach out of the default toolchains, having discrete phases (even simple plan=>implement=>test) that loop while capping tool access and edit sizes and that's been really promising in the realm of obtaining better agentic coding quality