I'm a computer science undergraduate trying to build strong engineering judgment while using agentic AI tools on personal projects. I want to gain industry-relevant skills without blindly accepting generated code or losing the productivity benefits of AI.
My current plan is to write product requirements, think through the architecture, and document important design decisions before asking AI to implement specific functionality. I would then review the generated code carefully rather than treating a successful build as proof that the solution is good.
I'm unsure how much code I should still write manually for learning purposes. What processes or exercises would help me develop critical thinking, debugging ability, and maintainable design skills while using AI responsibly?
3 Answers
Be careful not to turn documentation into procrastination. A short plan, a few acceptance criteria, and a brief design note are often enough for a small project. Write more detailed documentation when the system is genuinely complex or when you’re making a decision you may need to revisit.
Writing requirements and architecture notes is a solid foundation, because the hardest engineering work is deciding what should be built and why. I’d also review every generated change line by line. Check whether you understand the control flow, error handling, security implications, and maintenance costs—not just whether the tests pass.
Keep a lightweight decision log as well. For each meaningful choice, record the alternatives you considered and why you picked one. Architecture Decision Records work well for this; they’re essentially a structured version of that habit. Don’t make the documents so elaborate that they become a substitute for building, though.
Make sure you deliberately practice the parts AI is most likely to hide from you. Implement some features manually, investigate bugs without immediately asking for a fix, and explain unfamiliar code in your own words. You could also ask the tool for a solution only after attempting one yourself, then compare the approaches and identify the tradeoffs.
Give yourself difficult bugs and edge cases to solve. Debugging, tracing state through a system, and understanding why a seemingly reasonable solution fails are where a lot of practical engineering judgment develops.
That makes sense. I’ll use ADRs for decisions that actually affect the design and keep the rest of the notes lightweight.