I'm the author of Python Crash Course, and I got this exact same email this week. I was thinking of writing a public response as well, because any attempt to sincerely answer these questions takes something along the lines of a full post. It's also worth a public response because many people who are getting into programming for the first time right now are asking variations of these same questions.
> Do I think that AI enables people to develop faster than they can keep up?
Absolutely. That's the core of this person's email, and everyone else who asks similar questions. Just five years ago, the only way to build a working project of moderate complexity was to learn the basic to intermediate concepts required to make an MVP. Now, if you can steer an LLM reasonably well, you can quickly build an MVP that goes well beyond your own understanding of the implementation.
I don't think anyone has clear answers to all the questions brought up in this email. I think people can learn faster than they used to, because they can make connections between different areas faster than they used to. But it requires skill and discipline in how you learn, and how you work. You have to intentionally build your understanding as you build your projects.
> Just five years ago, the only way to build a working project of moderate complexity was to learn the basic to intermediate concepts required to make an MVP.
> Now, if you can steer an LLM reasonably well, you can quickly build an MVP that goes well beyond your own understanding of the implementation.
Somewhat agree. Five years ago you could build an MVP without understanding how to open TCP sockets or how to parse HTTP headers. You didn't need to understand relational databases, let alone B-trees or cache locality. You didn't need to know how to install Linux.
Now you don't need to understand the details of connecting to Stripe or Auth0 or setting up a Kubernetes cluster.
> You have to intentionally build your understanding as you build your projects.
Some things you need to understand-others, not so much. Depends on what you're doing, the scale, risks, etc, but that's always been the case.
> Some things you need to understand-others, not so much.
This is the core of the matter though, knowing what you need to understand and what you can ignore is the actual programmer's skill. It requires you to have a clear mental picture of both what you are trying to build and what the underlying machine will do when you are finished.
You need to understand the abstractions, but also where they leak, when they won't match reality, and how. This is why knowing computer architecture and assembly helps you to optimize your code even if you are coding in a high level language.
The problem with coding agents is that they are tuned to work on all contexts so they always fill an underspecified request by optimizing the average case and often without stating all the assumptions that they make. So you still need to understand what you specified and what got filled in automagically by the agent. My experience is that they (even the paid frontier models) are poor judges of the most important assumptions they make, which will might be corrected by a prompt or a tool output in which case it is fine. Otherwise it will be ignored and steer the model into a weird loop. It then tries to fix things but can not do so since its mental model is totally broken now.
Do not get me wrong, I am so happy to let the agent handle tool building (especially those that involve a web UI) and fill in the CLI command line argument parser. But every time I trust the agent by relying on it to drive the mental model of what we are doing, I got seriously bitten. Well, maybe that should not be surprise me, but I can understand the confusion of less experienced programmers and non-coders. It must really be frustrating to be able to build so much, but also not to be able to fix seemingly small issues.
Fixing stuff by driving an LLM to do it seems like a distinct skill unto itself. It’s kind of this blend of your normal debugging skills, carefully managing what goes into the LLM and carefully constructing your requests.
For me at least it’s the one thing that feels like a novel new skill to learn more than anything else. Normal LLM prompting feels like just an extension of the mental process I’d use when coding and designing in a way that trying to get the LLM to fix things kind of doesn’t.
I agree that it is a bit weird, kind of coding in natural language but also not exactly like that. Maybe as the agents stabilize and there are proper new tools for this new process we can relax a bit and it will become the new normal. For now it feels like surfing over an ever changing seascape, exciting but tiring at the same time.
japhyr · · focus · HN ↗
> Do I think that AI enables people to develop faster than they can keep up?
Absolutely. That's the core of this person's email, and everyone else who asks similar questions. Just five years ago, the only way to build a working project of moderate complexity was to learn the basic to intermediate concepts required to make an MVP. Now, if you can steer an LLM reasonably well, you can quickly build an MVP that goes well beyond your own understanding of the implementation.
I don't think anyone has clear answers to all the questions brought up in this email. I think people can learn faster than they used to, because they can make connections between different areas faster than they used to. But it requires skill and discipline in how you learn, and how you work. You have to intentionally build your understanding as you build your projects.
senko · · focus · HN ↗
> Now, if you can steer an LLM reasonably well, you can quickly build an MVP that goes well beyond your own understanding of the implementation.
Somewhat agree. Five years ago you could build an MVP without understanding how to open TCP sockets or how to parse HTTP headers. You didn't need to understand relational databases, let alone B-trees or cache locality. You didn't need to know how to install Linux.
Now you don't need to understand the details of connecting to Stripe or Auth0 or setting up a Kubernetes cluster.
> You have to intentionally build your understanding as you build your projects.
Some things you need to understand-others, not so much. Depends on what you're doing, the scale, risks, etc, but that's always been the case.
musebox35 · · focus · HN ↗
This is the core of the matter though, knowing what you need to understand and what you can ignore is the actual programmer's skill. It requires you to have a clear mental picture of both what you are trying to build and what the underlying machine will do when you are finished.
You need to understand the abstractions, but also where they leak, when they won't match reality, and how. This is why knowing computer architecture and assembly helps you to optimize your code even if you are coding in a high level language.
The problem with coding agents is that they are tuned to work on all contexts so they always fill an underspecified request by optimizing the average case and often without stating all the assumptions that they make. So you still need to understand what you specified and what got filled in automagically by the agent. My experience is that they (even the paid frontier models) are poor judges of the most important assumptions they make, which will might be corrected by a prompt or a tool output in which case it is fine. Otherwise it will be ignored and steer the model into a weird loop. It then tries to fix things but can not do so since its mental model is totally broken now.
Do not get me wrong, I am so happy to let the agent handle tool building (especially those that involve a web UI) and fill in the CLI command line argument parser. But every time I trust the agent by relying on it to drive the mental model of what we are doing, I got seriously bitten. Well, maybe that should not be surprise me, but I can understand the confusion of less experienced programmers and non-coders. It must really be frustrating to be able to build so much, but also not to be able to fix seemingly small issues.
Fr0styMatt88 · · focus · HN ↗
For me at least it’s the one thing that feels like a novel new skill to learn more than anything else. Normal LLM prompting feels like just an extension of the mental process I’d use when coding and designing in a way that trying to get the LLM to fix things kind of doesn’t.
musebox35 · · focus · HN ↗