Stop Prompting, Start Pairing: How to Actually Get Better at Code by Working With AI Agents

I've been writing code for more than 20 years: PHP, Drupal, TypeScript, cloud infrastructure, and now LLM serving for an agentic IDE I'm building. Over the last year of working with coding agents every day, I've seen developers split into two groups:

• Developers who got sharper. They understand more languages, make better architecture decisions, and review code faster.
• Developers who got rusty. They ship more code than ever, but they couldn't explain half of it without the agent open. The tool isn't the difference. Both groups use the same agents. The difference is what they delegate.

The trap: delegating the thinking

The default loop looks like this:

prompt → accept → run → "works" → ship

It feels productive, and in the short term it is. But this loop trains you in only one thing: writing prompts. You get output without gaining skill. Six months later, you're faster at producing code and slower at understanding it.

The fix isn't to stop using agents. It's to change the relationship. Treat the agent as three things at once:

1. A senior pair programmer who challenges your decisions
2. A rubber duck that talks back when you need to think out loud
3. A student you have to review and correct Here are the practices that made me better, not just faster.

1. Design first, and make the agent argue with you

Before any code, ask for options instead of an implementation:

I need to add multi-tenant support to this service.
Don't write code yet. Give me 3 architectural approaches
(e.g., shared schema, schema-per-tenant, database-per-tenant),
with trade-offs in cost, isolation, migrations, and operational
complexity. Then ask me which one I'd pick and why.

Then you choose, and you write down why. Now you're practicing the most valuable skill in the job, making architecture decisions under trade-offs, with an expert opponent available 24/7.

Bonus: save that reasoning as an ADR (Architecture Decision Record). Future you, and future agents, will thank you.

2. "Attempt first" for anything you want to learn

For code you just need done, let the agent write it. For code in an area you want to master, write it yourself first, then ask for a review:

Here's my implementation. Review it like a strict senior engineer.
Point out bugs, non-idiomatic code, performance issues, and
edge cases I missed. Don't rewrite it — explain each issue
and let me fix it.

The line "don't rewrite it" matters. If the agent fixes the issue, you learn nothing. If you fix it, you remember it.

3. The "explain it back" rule

My rule before merging any agent-generated code: I must be able to explain every line. If I can't, that's not a reason to trust it. It's a gap in what I know.

When I hit a line I don't fully understand, I flip the roles:

Don't explain this code to me. Quiz me on it.
Ask me 5 questions about what this function does,
why it's written this way, and what breaks if we change it.
Tell me which answers are wrong.

Being quizzed exposes gaps much faster than reading an explanation.

4. Learn new languages by porting code you already know

The fastest way I've found to learn a new language with an agent is to port something you already understand deeply.

Take a small module you wrote in your main language (for me, PHP) and rewrite it yourself in the target language (Go, Rust, whatever). Then ask:

I ported this PHP class to Go. Compare both versions.
Where is my Go code "PHP written in Go syntax"?
Show me the idiomatic Go approach for each case and explain
the language concept behind it (interfaces, error handling,
ownership, concurrency, etc.).

Because you already know the domain logic, all of your attention goes to the language itself: its idioms, its type system, its way of handling errors. You learn the language from your own mistakes instead of tutorial examples.

5. Always ask for the "why" and a source you can verify

Agents are confident even when they're wrong. Turn that into a learning habit:

Why is this the correct approach? Point me to the relevant
documentation section, RFC, or language spec so I can verify it.

Then actually open the source. Half the time you'll learn something the agent didn't mention. The other half, you'll catch it being wrong, and that teaches you even more.

6. Break things on purpose

This is my favorite one. Use the agent to create debugging exercises from your own codebase:

Introduce one subtle bug into this module — something that
passes a quick review but fails in production (race condition,
off-by-one, timezone, null handling). Don't tell me where.
Give me only the symptom a user would report.

Then hunt it down without help. It's like a debugging gym built from your own real code. You can also have the agent write failing tests and make them pass yourself.

7. Architecture katas: let the agent be the chaotic stakeholder

Designs look great until the requirements change. So simulate the change:

Here's my design for an order system. Act as a product manager
who changes requirements every round. Give me one new requirement
at a time (multi-currency, partial refunds, 10x traffic,
GDPR deletion...). After each one, ask me what changes in my design.
Tell me when my design starts to break.

After five rounds, you'll know where your design is fragile, and why patterns like event sourcing, CQRS, or hexagonal architecture exist. You'll understand them from experience, not from a blog post.

8. Review the agent like you'd review a junior, and keep a log

Treat every agent PR as a pull request from a talented junior developer: read it, question it, request changes.

Then keep a simple "agent mistakes log":

Date	Mistake	Why it was wrong	Pattern to remember
09/12	N+1 queries in listing	Lazy loading inside loop	Eager-load relations in list views
09/14	Swallowed exception	Empty catch block	Never catch without logging or rethrowing

After a month, this log becomes your personal list of anti-patterns. The agent's mistakes turn into your expertise.

9. Write your standards down, because it forces you to know them

Most agent tools support a project rules file (for example AGENTS.md, CLAUDE.md, or similar) where you describe conventions, architecture, and boundaries.

Writing that file is a surprisingly hard exercise. You have to spell out things you've only ever "felt":

• Why is the domain layer separate from the infrastructure layer?
• When do we use a queue versus a synchronous call?
• What does "done" mean in this codebase? If you can't write your architecture down clearly, you don't understand it clearly yet. The agent just gave you a reason to find out.

A simple weekly routine

• Daily: Apply the "explain it back" rule to every merged PR.
• Twice a week: Write one feature yourself first, then get an agent review.
• Weekly: Do one bug hunt (practice 6) or one architecture kata (practice 7).
• Monthly: Review your mistakes log and update your rules file. It adds maybe 2 to 3 hours a week. In return, you grow as an engineer instead of just getting faster at typing prompts.

How to know if you're learning or just outsourcing

Ask yourself honestly:

• Could I rebuild last week's feature without the agent, even if it took longer?
• Do I catch the agent's mistakes more often than I did three months ago?
• Can I explain the trade-offs behind our current architecture?
• Am I comfortable reading code in a language I didn't know six months ago? If the answers are "yes," the agent is making you better. If they're "no," you're renting skill instead of building it.

Improve together

Agents aren't going away, and they'll keep getting better. The developers who thrive won't be the ones who write the best prompts. They'll be the ones who use every interaction as a chance to learn, and who can still think clearly when the agent is wrong.

Don't just give the agent instructions. Grow alongside it.

What's one thing an AI agent taught you that actually stuck? Tell me in the comments. I'd love to build a list of learning techniques together.