Great points! 😄You're making really good use of AI. Your experience helps you lead AI agents efficiently. You know how to plan, how to verify, and what safety issues to watch out for. In that sense, AI makes a great implementor.
To be honest, my software-engineering experience is limited. When I have an idea, I tell an AI agent to build it out. What I can do is verify it as a user and read the code afterwards to understand how it works. At my level, I rely on AI to do the coding rather than telling it what I want and checking the result. So we can see that in AI coding, experience and taste (or intuition) make all the difference.
A CLI is totally fine. 😄I once asked an AI agent to convert my Kindle notes into an HTML file, with the notes displayed in an organized way. It wrote a Python script, which I now run from the command line whenever I want to view the organized notes. A GUI would take much more time.
Full-stack dev sharing practical guides on WordPress, n8n automation, AI tools, Docker & self-hosting. Always experimenting with new tech to make life easier.
Yes — and I think you've just highlighted an important difference between us. 😄
You can start with an idea and let the agent turn it into something concrete, then evaluate the result as a user. I tend to work one step earlier: before asking the AI to build anything, I spend quite a lot of time figuring out what the thing actually is — what problem I'm solving, what the concepts are, how they relate to each other, and roughly how the solution should be structured.
So I don't think the difference is simply "knowing how to code". It's also about being able to picture the system before it exists. Experience certainly helps, but I suspect taste and intuition matter just as much — perhaps even more as implementation becomes increasingly automated.
And your Kindle example is actually a great illustration of why I don't think everything needs a GUI. 😄 If a Python script does exactly what you need and you can run it from the CLI whenever you want, building a graphical interface would just add another layer to maintain.
That's also something I like about AI coding: it makes it much cheaper to build these small, very specific tools that would probably never have been worth building before.
In a way, we're both doing the same thing, just at different points in the process: you start with an idea and let AI help discover the implementation; I start by conceptualizing the solution and let AI take care of more of the implementation. Both approaches are becoming possible because the cost of turning an idea into code has dropped so dramatically.
It strikes me that you are the "architect" type that Paul Graham described — the kind programmers should strive to become in the age of AI coding.
I agree that AI coding lowers the cost of building small, specific tools. Now I find myself thinking about building more things. In the past, a lot held me back: where should I start? Should I learn more frontend and backend before diving in? Now AI coding can put together a project in minutes, and I can study the code afterwards. In that sense, it's really nice.
But sometimes I feel like I'm losing control over the projects, because I'm not writing the code myself and have no idea what exactly each line of code does. As I've seen online, many people have shared a similar feeling. Perhaps people like me still need some time to adjust — learn to use tests to ensure code quality rather than reviewing the code line by line. What about you?
Full-stack dev sharing practical guides on WordPress, n8n automation, AI tools, Docker & self-hosting. Always experimenting with new tech to make life easier.
I think you've put your finger on something really important here. 😄
And yes, I probably am the "architect" type Paul Graham had in mind — although I don't think that means I want to stop being involved in the implementation.
What has changed for me is where I exercise control. I don't need to know what every single line does. I need to understand the concepts, the architecture, the important decisions and the constraints well enough to recognize when the implementation is going in the wrong direction.
That's also why I'm a little cautious about the idea of replacing code review entirely with tests. Tests are extremely useful, of course, but they can only tell you whether the system behaves correctly for the things you've thought of testing. They don't necessarily tell you whether you built the right thing in the first place. 😄
I actually don't feel that I'm losing control when AI writes the code. Quite the opposite: I feel that I can spend more time thinking about the system instead of spending hours translating my thoughts into syntax.
But there is a condition: I have to remain able to reason about what the AI has built. I don't need to understand every implementation detail, but if the agent gives me a 500-line solution and I can't explain why the architecture makes sense, then I wouldn't consider that a success.
And I think that's probably where experience makes a big difference. You can look at a piece of generated code and sometimes immediately feel that something is wrong — even before you can point to the exact line. That's the "taste" or intuition you mentioned earlier. Then you investigate and find out why.
Your approach of building things first and studying the code afterwards is actually a really good way to learn too. You're getting something concrete to explore instead of spending months learning technologies before you've even found a problem you want to solve.
And I think that's one of the genuinely exciting things about AI coding: it changes the cost of experimentation. An idea that would previously have remained "maybe I'll build this someday" can now become a working prototype in an afternoon.
The challenge is probably learning where to trust the agent, where to verify it, and where to stop and think for yourself. I suspect that's going to be one of the most important skills in AI-assisted development.
Thank you very much, Pascal! 😄Your reply gave me some inspiration about my own situation.
I used to think that as AI does the coding, without deliberate practice, my coding skills would be hard to improve. You said, "I feel that I can spend more time thinking about the system instead of spending hours translating my thoughts into syntax." This leads me to think about what the really important thing is — the core of coding skills. Architecture and system design matter more.
Your point about reviewing code and writing tests is onto something. Since AI agents produce code so quickly, code review has become the new bottleneck. So developers are turning to comprehensive tests to handle code review, as AI writes tests fairly well too. It seems testing only solves part of the problem, and code review is still necessary. I think testing is like looking at a box from the outside, while code review is like opening the box and looking inside — time consuming, but much clearer.
Yes, experience is a precious career asset. Simon Willison made a similar point: with your experience, you know which techniques work and which don't, and you can write clearer prompts.
I totally agree with you that AI makes experimentation easier. Now I have fewer excuses to put off a project. People have shared online how they do vibe coding. Setting up a coding environment used to be the biggest roadblock for beginners. Many people stopped there before even writing a single line of code. Now they just ask AI agents to install the software and set up the environment for them. It's a magical change!
Thank you again. Our discussions give me more motivation to keep coding.
Full-stack dev sharing practical guides on WordPress, n8n automation, AI tools, Docker & self-hosting. Always experimenting with new tech to make life easier.
Thank you, Julie! 😄 I'm really glad our conversation gave you some inspiration.
I think you've actually made an important distinction: coding skills aren't necessarily the same thing as being good at writing code. Syntax, frameworks and implementation techniques can increasingly be delegated. Understanding a problem, designing a system, making trade-offs and knowing what a good solution looks like are much harder to delegate.
And I really like your "box" analogy. I'd add one more question to it: before opening the box, we should probably ask whether we built the right box in the first place. 😄
That's where I think the human role becomes particularly important. Tests can tell us whether the implementation behaves correctly for the cases we've considered. Code review lets us look inside and understand how it works. But neither necessarily tells us whether the original conceptualization was right.
And yes, experience is becoming even more valuable for exactly the reasons you mention. It's not just about knowing more technologies. It's knowing which questions to ask, which shortcuts are dangerous, which architectures tend to age badly, and sometimes simply recognizing that something doesn't look right.
Your point about the environment setup is also very true. I remember how much friction there used to be between "I have an idea" and "I have a development environment where I can start experimenting." If an AI agent can remove most of that friction, that's a huge change — especially for people who are curious but don't yet have a strong technical background.
So maybe don't worry too much about not improving your coding skills in the traditional sense. Keep building things. Read what the AI produces. Break it, fix it, question it, and gradually learn why some approaches work and others don't.
And most importantly: keep having ideas. 😄
That's probably the skill AI is least likely to automate.
Great points! 😄You're making really good use of AI. Your experience helps you lead AI agents efficiently. You know how to plan, how to verify, and what safety issues to watch out for. In that sense, AI makes a great implementor.
To be honest, my software-engineering experience is limited. When I have an idea, I tell an AI agent to build it out. What I can do is verify it as a user and read the code afterwards to understand how it works. At my level, I rely on AI to do the coding rather than telling it what I want and checking the result. So we can see that in AI coding, experience and taste (or intuition) make all the difference.
A CLI is totally fine. 😄I once asked an AI agent to convert my Kindle notes into an HTML file, with the notes displayed in an organized way. It wrote a Python script, which I now run from the command line whenever I want to view the organized notes. A GUI would take much more time.
Yes — and I think you've just highlighted an important difference between us. 😄
You can start with an idea and let the agent turn it into something concrete, then evaluate the result as a user. I tend to work one step earlier: before asking the AI to build anything, I spend quite a lot of time figuring out what the thing actually is — what problem I'm solving, what the concepts are, how they relate to each other, and roughly how the solution should be structured.
So I don't think the difference is simply "knowing how to code". It's also about being able to picture the system before it exists. Experience certainly helps, but I suspect taste and intuition matter just as much — perhaps even more as implementation becomes increasingly automated.
And your Kindle example is actually a great illustration of why I don't think everything needs a GUI. 😄 If a Python script does exactly what you need and you can run it from the CLI whenever you want, building a graphical interface would just add another layer to maintain.
That's also something I like about AI coding: it makes it much cheaper to build these small, very specific tools that would probably never have been worth building before.
In a way, we're both doing the same thing, just at different points in the process: you start with an idea and let AI help discover the implementation; I start by conceptualizing the solution and let AI take care of more of the implementation. Both approaches are becoming possible because the cost of turning an idea into code has dropped so dramatically.
It strikes me that you are the "architect" type that Paul Graham described — the kind programmers should strive to become in the age of AI coding.
I agree that AI coding lowers the cost of building small, specific tools. Now I find myself thinking about building more things. In the past, a lot held me back: where should I start? Should I learn more frontend and backend before diving in? Now AI coding can put together a project in minutes, and I can study the code afterwards. In that sense, it's really nice.
But sometimes I feel like I'm losing control over the projects, because I'm not writing the code myself and have no idea what exactly each line of code does. As I've seen online, many people have shared a similar feeling. Perhaps people like me still need some time to adjust — learn to use tests to ensure code quality rather than reviewing the code line by line. What about you?
I think you've put your finger on something really important here. 😄
And yes, I probably am the "architect" type Paul Graham had in mind — although I don't think that means I want to stop being involved in the implementation.
What has changed for me is where I exercise control. I don't need to know what every single line does. I need to understand the concepts, the architecture, the important decisions and the constraints well enough to recognize when the implementation is going in the wrong direction.
That's also why I'm a little cautious about the idea of replacing code review entirely with tests. Tests are extremely useful, of course, but they can only tell you whether the system behaves correctly for the things you've thought of testing. They don't necessarily tell you whether you built the right thing in the first place. 😄
I actually don't feel that I'm losing control when AI writes the code. Quite the opposite: I feel that I can spend more time thinking about the system instead of spending hours translating my thoughts into syntax.
But there is a condition: I have to remain able to reason about what the AI has built. I don't need to understand every implementation detail, but if the agent gives me a 500-line solution and I can't explain why the architecture makes sense, then I wouldn't consider that a success.
And I think that's probably where experience makes a big difference. You can look at a piece of generated code and sometimes immediately feel that something is wrong — even before you can point to the exact line. That's the "taste" or intuition you mentioned earlier. Then you investigate and find out why.
Your approach of building things first and studying the code afterwards is actually a really good way to learn too. You're getting something concrete to explore instead of spending months learning technologies before you've even found a problem you want to solve.
And I think that's one of the genuinely exciting things about AI coding: it changes the cost of experimentation. An idea that would previously have remained "maybe I'll build this someday" can now become a working prototype in an afternoon.
The challenge is probably learning where to trust the agent, where to verify it, and where to stop and think for yourself. I suspect that's going to be one of the most important skills in AI-assisted development.
Thank you very much, Pascal! 😄Your reply gave me some inspiration about my own situation.
I used to think that as AI does the coding, without deliberate practice, my coding skills would be hard to improve. You said, "I feel that I can spend more time thinking about the system instead of spending hours translating my thoughts into syntax." This leads me to think about what the really important thing is — the core of coding skills. Architecture and system design matter more.
Your point about reviewing code and writing tests is onto something. Since AI agents produce code so quickly, code review has become the new bottleneck. So developers are turning to comprehensive tests to handle code review, as AI writes tests fairly well too. It seems testing only solves part of the problem, and code review is still necessary. I think testing is like looking at a box from the outside, while code review is like opening the box and looking inside — time consuming, but much clearer.
Yes, experience is a precious career asset. Simon Willison made a similar point: with your experience, you know which techniques work and which don't, and you can write clearer prompts.
I totally agree with you that AI makes experimentation easier. Now I have fewer excuses to put off a project. People have shared online how they do vibe coding. Setting up a coding environment used to be the biggest roadblock for beginners. Many people stopped there before even writing a single line of code. Now they just ask AI agents to install the software and set up the environment for them. It's a magical change!
Thank you again. Our discussions give me more motivation to keep coding.
Thank you, Julie! 😄 I'm really glad our conversation gave you some inspiration.
I think you've actually made an important distinction: coding skills aren't necessarily the same thing as being good at writing code. Syntax, frameworks and implementation techniques can increasingly be delegated. Understanding a problem, designing a system, making trade-offs and knowing what a good solution looks like are much harder to delegate.
And I really like your "box" analogy. I'd add one more question to it: before opening the box, we should probably ask whether we built the right box in the first place. 😄
That's where I think the human role becomes particularly important. Tests can tell us whether the implementation behaves correctly for the cases we've considered. Code review lets us look inside and understand how it works. But neither necessarily tells us whether the original conceptualization was right.
And yes, experience is becoming even more valuable for exactly the reasons you mention. It's not just about knowing more technologies. It's knowing which questions to ask, which shortcuts are dangerous, which architectures tend to age badly, and sometimes simply recognizing that something doesn't look right.
Your point about the environment setup is also very true. I remember how much friction there used to be between "I have an idea" and "I have a development environment where I can start experimenting." If an AI agent can remove most of that friction, that's a huge change — especially for people who are curious but don't yet have a strong technical background.
So maybe don't worry too much about not improving your coding skills in the traditional sense. Keep building things. Read what the AI produces. Break it, fix it, question it, and gradually learn why some approaches work and others don't.
And most importantly: keep having ideas. 😄
That's probably the skill AI is least likely to automate.
Thank you, Pascal! 😄Keep coming up with ideas. Keep building things and studying how they are built. Great advice — I'll take these to heart.