I'm 15 and have been teaching myself programming for about two years. I started by writing everything manually, working through courses, debugging constantly, and learning fundamentals without AI. I also benefited from conversations with experienced developers, which helped me understand architecture, security, Linux, networking, and common engineering mistakes.
More recently, I've started doing paid automation and software work. I've earned some money from it and am maintaining a system that real employees use, which has taught me that software is never truly finished once users and changing requirements are involved.
For serious projects, I now use coding agents heavily. I define the requirements, architecture, boundaries, security rules, acceptance criteria, and tests, while the agents handle much of the implementation. I review diffs, run tests and CI, investigate failures, reject bad abstractions, and make substantial corrections when the generated code is wrong or difficult to maintain.
The concern is that my ability to ship complex systems may be growing faster than my actual engineering depth. I don't think I would be unable to program if the tools disappeared, but I would become much slower and would probably expose gaps in areas where I lack experience. I've worked on projects involving Linux, networking, backend systems, security, and an educational x86-64 kernel, while currently studying C++, hardware, and electronics more manually.
My biggest technical weakness is probably breadth without enough depth. I also tend to start too many projects, move too quickly, and worry about problems far in the future. I want to become a strong engineer without letting programming consume my entire life.
How can I objectively test whether my judgment and fundamentals are keeping up with what I can ship using AI? What should I deliberately do less of? If you had two years of experience and modern coding agents available, how would you use them without skipping the difficult parts that create real understanding?
3 Answers
Your biggest concern should probably be sustainability rather than whether you are progressing fast enough. Ten- or fourteen-hour days, many simultaneous projects, and trying to solve distant problems can produce impressive short-term results while damaging your health, school performance, and relationships. Keep building real things, but narrow your focus, finish and maintain fewer projects, and leave room for friends, rest, and nontechnical interests. Those years are not something you can simply recover later.
A practical evaluation is to take one of your systems and perform an adversarial review without AI: map the data flow, identify trust boundaries, predict failure cases, write tests for them, and explain the tradeoffs to another engineer. Then ask an agent to critique your work and compare the results. Repeat this with networking, operating systems, databases, concurrency, and security. That will reveal gaps much more accurately than counting lines of code or measuring how advanced the final project looks.
The main risk isn’t using AI; it’s confusing shipped output with personal mastery. Keep a deliberate split between delivery work and learning work. For learning projects, write the implementation manually, read the documentation and source material, and avoid asking the tool for solutions until you’ve struggled with the problem yourself. For production work, use the agent as leverage, but keep ownership of requirements, architecture, security, tests, and maintenance.
That distinction between delivery work and learning work is useful. I’m already trying to keep C++ and hardware projects mostly manual for exactly that reason.