Should you care about "Good Code" in 2026? | Hacker News Reader

Should you care about "Good Code" in 2026?

blog.dmilicic.com

2 pointsdmilicic4 comments

As a software engineer, I've always cared about writing good code because I wasn't writing it for computers, I was writing it for other people who also work on it. However, since AI took over a few months ago, I've had doubts about whether this is a wasted effort.

I've been back and forth on this, but after working on a few AI-coded apps, I have, for now, confirmed my belief that it still matters whether the codebase is robust.

Firstly, I believed that it does not matter what's under the hood if it works. But I found that I can't make it work without the code being robust, testable, and maintainable to a certain degree.

Therefore, I am linking my article that explores this a bit more and shares what I think are the three most important points that you should still care about writing good code, which are:

1. AI will train on it - the most long-term reason, most people won't care, but it does affect everyone

2. You still need to do the final touches - it's probably not a good idea to prompt for one-line changes, it's like calling an electrician to change the lightbulb

3. Software is never done, and it should be easy to change - AI will struggle with more tokens, and you with more time, if your code is not of good quality

Anyway, I am just sharing my shower thoughts and hopefully will start an interesting discussion.

100% human written with AI used for spelling!

You're right it still matters, but I'd reframe why. Good code used to carry design intent — readable code told the next person why things were structured this way. When AI writes the code, that's gone. The code works but it doesn't explain itself. So where does the "why" live now? Not in the code — that's disposable. Not in the prompt — that's throwaway. It has to live in something upstream that the human owns. Something formal enough that you can regenerate the code from it. Your point 3 is the key one. Software is never done. But "easy to change" requires knowing why it was built this way. That knowledge used to live in the code. Now it needs a new home.

Code quality matters more now, not less — but the definition shifts.

"Good code" used to mean readable, well-structured, maintainable by humans. When AI writes the implementation, those qualities become secondary.

What matters is: was the design clear enough to produce correct code in the first place?

The pattern I keep seeing: teams try to enforce quality after generation — linting, reviews, static analysis. That works for surface-level issues. It doesn't catch architectural drift, because by the time you're reading the code, the design decisions are already baked in and invisible.

Quality has to move upstream.

If you can't make AI-coded apps work without the code being robust and testable, the question is: who's responsible for making it robust and testable? The answer can't be "hope the AI gets it right." It has to be constraints that make wrong output impossible.

Yes you should. Good code means you understand it and can fix it.

Reply on news.ycombinator.com