learning software engineering while using ai coding agents
A practical guide for early career engineers on building real judgment in the age of AI agents
There’s a real anxiety among new engineers: if AI writes the code, how do you actually learn to be a good engineer?
Three archetypes I’ve observed, even amongst my peers:
prompter: pastes problem into an agent, copies the answer, ships it, learns nothing. builds a portfolio of working code they can’t maintain or reason about.
refuser: insists on hand-crafting everything. falls behind peers in shipping speed, builds resentment toward agents, eventually capitulates and becomes a prompter anyway.
half-asser: uses agents but doesn’t think hard about the output. reviews diffs but doesn’t really read them.
None of these are ideal outcomes. I’ll describe a different mode: using AI agents as a multiplier on your judgment, not a replacement for it.
the skill was never “writing code”
When learning math you start with fundamental concepts like addition, multiplication etc. The ability to use these concepts when handed a raw problem (what’s 2 x 2?) has some, limited value. The ability to apply these concepts to (the oft-dreaded) abstract word problems is where the real work began. Similarly in software engineering, the skill being developed was not purely writing code but learning problem solving, building technical judgment, and intuition. You show growth as an engineer by knowing what to build, how to structure it, when something feels wrong, when to push back, when to trust a plan. pre-AI, a lot of this muscle was built through struggle and hours of debugging strife. How can we emulate some of that today?
the core principle
AI agents are great at execution. They are often bad at meta-questions: scope, tradeoffs, “is this the right approach,” “does this paint us into a corner later,” “am I being lazy?”
Your job is to be the meta layer. The agent’s job is to be the execution layer. The handoff between you is where learning happens.
Think of it like working with a very fast, very confident junior engineer who has read the entire internet but has never shipped anything to production. You wouldn’t blindly trust their output. You’d review it, question it, and use it to move faster.
habits that turn execution into learning
1. predict before you read
When an agent proposes a plan, stop before reading it. Think about what you would do. Then read the plan and compare:
Did the agent surprise you? figure out why their approach is different. Ask probing questions about tradeoffs and capabilities; verify the claims yourself. You’ll either build confidence in your judgment or learn something new.
Did you spot something the agent missed? Great, you’re building real judgment.
As an exercise try something like: “create the interface/API” for this functionality (and see what it passes as params). We should have an intuition of what parameters should be needed to implement something.
it’s easier to identify problems at this stage, mainly: why is it passing param X? (ie: we shouldn’t need it). This usually is a consequence of something gone wrong.
This is the single fastest feedback loop available to you. Senior engineers spent years experiencing bugs and incidents to calibrate their instincts. You can do a version of this dozens of times a day now!
2. articulate the lesson
After each task, write one sentence about what you learned, not just what task was done.
Learned that Postgres doesn’t automatically index foreign-key columns, so it’s often worth adding an explicit index to avoid slow joins and to speed up parent-row updates/deletes.
Reading generated code teaches you nothing if you can’t explain it back. Forcing yourself to write the lesson surfaces what you actually understood.
3. read the diff
After an agent completes a task, read the diff. Your goal isn’t only to catch bugs, but to build a mental model of what is now in your codebase.
After reading, ask yourself:
can I explain what each new file does?
can I explain why the agent structured it this way?
is there a pattern here I’d recognize next time?
Sometimes I read the agent’s thought process/decision making and see if it maps to mine or if I can learn something from it. Other times I’m like why would you do/think that? Which leads me to -
4. when something feels off, push back
The single most valuable thing you can do is develop a calibrated sense of when an agent is confidently wrong and challenge it. This is a muscle I used to encourage my new grads to have against more senior engineers on the team; doing it with an agent is far less intimidating.
Common smells:
“this is cosmetic” or “this is fine” without explanation
confident statements about paradigms or API capabilities without citing a source
a solution that conveniently avoids hard work
skipping a step the spec explicitly required
changes that aren’t traceable to the original request
generating plausible-looking code that references APIs or methods that don’t actually exist
When you see one, push back.
“You said the SSL warning is cosmetic. Show me the exact warning text and what’s emitting it before we accept that.”
This skill transfers directly to working with humans. The ability to say “I’m not sure that’s right, let’s verify” is one of the most valuable things you can develop, regardless of who or what is sitting across from you.
5. try to solve it yourself
The struggle is where learning happens. The answer afterward is confirmation, not learning.
This doesn’t mean suffer for days (like I used to). Ten minutes of genuine effort before reaching for the agent means you arrive at the answer with context, not as a passive consumer. You’ll notice things in the agent’s response that you’d completely miss if you hadn’t tried first.
6. periodically rebuild understanding from scratch
Every few weeks, close everything and try to explain your own system out loud.
“Walk me through what happens when a user clicks sign in.”
“How does the auth token get from Google to the database to the API call?”
“What would I change to add a new third party integration?”
7. read code
Learn to understand intent without your own context filling in the gaps. Examples:
your team’s PRs
open source PRs in your stack (electron, ffmpeg, graphQL, etc)
self-review your own PRs
pair with the agent on other PRs or areas of the code base and ask it to teach you patterns, best practices, etc.
8. skip the agent on purpose, sometimes
Once a week, do a small task entirely by hand. Pick something contained: write a test from scratch, debug a tricky issue without asking the agent, refactor a small module. The point isn’t the output, it’s keeping the skills warm enough that you can still operate when the agent is wrong or unavailable.
9. learn to write great prompts and guardrails
This is a genuinely new skill that didn’t exist five years ago and it’s worth getting good at. The engineers who get the best output from agents aren’t the ones who write “build me a login page.” They’re the ones who provide clear constraints, context, and acceptance criteria. I like the principles outlined here too as a reference for how agents should approach writing code https://github.com/forrestchang/andrej-karpathy-skills.
Think of prompting like writing a good ticket or design doc. The clearer your input, the better the output, and the act of writing clear input forces you to think through the problem first. Thinking is becoming software engineering.
what you’re learning
You’re building calibrated judgment. The ability to look at a plan, a PR, a proposal, and feel confident about whether it’s right. Calibrated means your gut feeling matches the actual outcome rate.
This shows up as:
“something about this auth approach feels off, let me dig in” → finds a real bug
“this abstraction seems premature, what’s the simpler version?” → spots overengineering
“the agent is being shady about that warning, let me get specifics” → uncovers a real issue
“this plan looks great, let’s run it” → low friction on the boring stuff
Calibrated judgment is what senior+ engineers have. It’s built by thinking about more code, more decisions, more tradeoffs. Agents help you be exposed to more of this in less time.
antipatterns to watch for in yourself
The signs you’ve drifted into prompter:
approving plans you didn’t read
inability to explain code you “wrote” last week
discomfort opening files in your own repo
defaulting to “ask the agent” before thinking
unable to do small tasks without agent help
copy-pasting error messages directly into the agent without reading them first (and learning to recognize errors you’ve solved in the past).
note for new grads
The career arc has changed. Five years ago, your first 2 years were spent writing tons of code, hitting tons of bugs, building intuition through volume of work over time. Now, you can ship a working app in significantly less time.
You don’t need to struggle in the same ways we did, but you do need to learn to engage with your work in new ways.
invest in fundamentals that don’t change. data structures, scalable systems design, networking basics, how databases actually work. these are the things that let you evaluate whether an agent’s output makes sense.
balance optimizing for shipping speed with learning in your first year. optimize for understanding what you ship. speed comes naturally as understanding compounds.
have a trusted code reviewer be your mentor. the single highest ROI activity for early-career growth. have them review the agent’s code as well as yours. use pairing time for this as well.
build something hard from scratch occasionally. do a small project with no AI help. a CLI tool, a small API, a data pipeline. something that forces you to hold the whole thing in your head.
learn how the system works together. when the agent uses OAuth, learn what cookies and headers actually flow. When it sets up a database connection pool, understand what that means at the TCP level. Follow how the clients interact with the server, and our infrastructure.
push back on confident-sounding claims. both from agents and from humans. the skill of “I’m not sure that’s right, let’s verify” is always going to be valued.
get comfortable with ambiguity. the hardest part of real engineering isn’t writing the code, it’s figuring out what to build when the requirements are vague, contradictory, or incomplete.
note for managing and mentoring new graduates
make code review a learning ritual, not a quality gate. spend more time on “why this approach” than “this line is wrong.”
pair on agent interactions occasionally. watch them work with an agent for an hour. you might learn something too!
ask them to explain the code, decisions, and tradeoffs. if they can’t, that’s the signal, not whether the code builds.
reward judgment, not output. the engineer who pushed back on a bad agent suggestion and prevented a bug deserves more recognition than the one who shipped 3 features that work but introduced technical debt they don’t understand.
create safe spaces to be slow. if every sprint is about velocity, new engineers will optimize for speed and skip learning. build in time for exploration, reading, and understanding.
model the behavior yourself. show what thoughtful agent collaboration looks like.