In practical coding work, there's an overwhelming amount of code I don't know. To be precise, the only time someone can have a complete view of the architecture is in the early stages of a project. Once the codebase reaches a certain size, it's impossible to understand all of it. So what programmers typically do is start by focusing on small peripheral modules, adding debug logs at points they can understand, tracing the flow, and then modifying what they can.
The problem is that without a full overview or knowledge of the cost of different choices, you can't know if the abstraction you're working with is the right one. But that's how most people start anyway — collecting local evidence without understanding the whole, then finding changeable points. Over time, this naturally leads to technical debt and degradation, creating a need for refactoring. At those points, AI coding doesn't seem to change the workflow much in this bottom-up approach. For someone who can work top-down with a full blueprint, it might be different.
Anyway, reading this article, the question that comes to mind is: if AI handles debugging and code generation, and the system becomes more of a black box, how do we develop the architectural intuition needed to assemble a mental model of the entire system? It took me three years to deliver a working product with my first 40,000 lines of code. During those three years, I went through countless failures and refactorings. Then I wrote another 60,000 lines in just three months. Once the layout is set, at least within the frameworks I've worked with, you start to see where the boundary for what counts as complete lies. But if I'm worried about whether that kind of ability to design a finished layout can be developed through AI, I honestly don't know. On the flip side, if I don't use AI at all, I risk being left behind in the coming AI era. And if I do use AI, my own coding skills may atrophy, and without it, my direct understanding naturally declines. In the end, it comes down to where you strike the balance.
Ultimately, every programmer needs to own their own workflow, their own techniques, and their own mental model. So the end of these debates usually comes down to something like: 'Given your situation, you're right. And given my situation, I'm right.