I agree with the main thesis, but I think the Socrates image in the blog post is a bit of an error. Because Socrates actually said that writing would atrophy memory. Yet every era faces the same criticism: 'New tools just make people dumber.' (They probably used Socrates to make a point about thinking humans, but still.) When AI-related posts come up on HN, it's usually best to pick the middle ground that fits the tone of the article.
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.
I agree with the main thesis, but I think the Socrates image in the blog post is a bit of an error. Because Socrates actually said that writing would atrophy memory. Yet every era faces the same criticism: 'New tools just make people dumber.' (They probably used Socrates to make a point about thinking humans, but still.) When AI-related posts come up on HN, it's usually best to pick the middle ground that fits the tone of the article.
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.
Pretty sure that isn’t the point of using LLM’s