Skip to content
BSWEN
Blog

What Is the Junior Intern Rule for AI Coding? A Developer's Guide to Maintaining Craftsmanship

Cowrie
Cowrie
Dev @ Bswen

My brain was rotting. After three months of letting AI write all my code, I couldn’t explain my own work in a code review. That’s when I knew I had a problem.

I’d been using Claude and Gemini for everything—implementing features, fixing bugs, even writing tests. My velocity was incredible. My PRs were getting approved. But when a senior engineer asked me to walk through a particularly tricky piece of logic I’d “written,” I froze. I had no idea how it worked.

That’s when I made a rule that saved my career: The Junior Intern Rule.

The Problem: AI-Induced Helplessness

Let me show you what my workflow looked like before:

[My Old Workflow]


1. Get a ticket
2. Open Claude/Cursor
3. Describe the feature
4. Copy-paste the output
5. Run tests
6. If tests fail, paste error back to AI
7. Repeat until green
8. Ship it

This worked great until:

  • I couldn’t debug production issues (didn’t know the codebase)
  • I failed technical interviews (couldn’t whiteboard my own architecture)
  • Code reviews became terrifying (what if they asked questions?)

A Reddit thread captured this perfectly:

“noticed that when i let it do everything i cant even explain my own code in interviews which is terrifying as a student”

I realized I wasn’t a developer anymore. I was a professional prompt engineer with an inflated title.

The Solution: Treat AI Like a Junior Intern

The Junior Intern rule is simple: Treat your AI assistant exactly like a junior intern you’re mentoring.

[What a Junior Intern Does]
- Writes boilerplate and repetitive code
- Handles straightforward implementations
- Drafts initial versions of features
- Does the tedious work you don't have time for


[What YOU Keep]
- All architecture decisions
- Core business logic
- Code review and refactoring
- Understanding every line before it ships

This isn’t about being elitist. It’s about maintaining ownership.

The New Workflow

Here’s how my workflow changed:

[My New Workflow]


Phase 1: Planning (ME)
├── Understand the problem deeply
├── Design the architecture
├── Identify what's core vs. boilerplate
└── Decide what to delegate


Phase 2: Implementation (AI + ME)
├── AI: Generate boilerplate, tests, docs
├── ME: Write core logic from scratch
└── ME: Review every line AI produces


Phase 3: Refactoring (ME - ALWAYS)
├── Rewrite messy AI code
├── Apply my coding standards
├── Ensure I can explain every line
└── Make it "mine"

Concrete Example

Last week, I needed to implement a rate limiter. Here’s how the Junior Intern rule played out:

What I delegated to AI:

  • Generating the basic struct/interface scaffolding
  • Writing the test file boilerplate
  • Creating the configuration validation helpers

What I wrote myself:

  • The core sliding window algorithm
  • The thread-safety logic
  • The integration with our existing middleware

The result? I shipped it in 2 days instead of 1, but I can now explain every line of that code in an interview.

The Refactor Step: Non-Negotiable

The most important part of this workflow is what happens after AI generates code:

[The Refactor Ritual]


1. Read every line of AI output
2. Ask: "Do I understand this completely?"
3. If NO → Rewrite it until you do
4. Apply your naming conventions
5. Add your comments where they matter
6. Delete clever one-liners you can't read
7. Ensure it matches your codebase style

As one developer put it:

“I let the AI write the messy first draft, and then I go in and manually refactor every single line to make it mine.”

This is slower. Sometimes much slower. But it’s the difference between “I wrote this” and “I generated this.”

The Trade-offs (Be Honest)

Let’s not pretend this approach doesn’t have costs:

[Costs of the Junior Intern Rule]


✗ Velocity drops significantly
✗ You write more code yourself
✗ Less time for other work
✗ Might feel "inefficient"


[Benefits of the Junior Intern Rule]


✓ You understand every line you ship
✓ You can debug production issues
✓ You pass technical interviews
✓ Code reviews become opportunities, not threats
✓ You maintain craftsmanship pride

I’ve accepted that my velocity metrics look worse on paper. But my value to the team has actually increased because I’m not dependent on an AI to understand my own codebase.

When to Break the Rule

There are legitimate exceptions where you might let AI do more:

[Acceptable AI-Heavy Situations]


- Prototyping / throwaway code
- Learning a new language (with review)
- Documentation generation
- Test generation (you wrote the logic)
- Emergency hotfixes (understand it later)

The key is intentionality. If you’re choosing to let AI take over, you’re still in control. If it’s happening by default, you’ve lost the plot.

The Interview Test

Here’s the ultimate litmus test for whether you’re following the Junior Intern rule effectively:

Could you whiteboard your last feature in an interview?

Not the implementation details—the architecture, the core logic, the trade-offs. If you can’t, you let the AI go too far.

One student’s experience:

“noticed that when i let it do everything i cant even explain my own code in interviews which is terrifying as a student”

Don’t be that person.

If you’re struggling with AI-assisted development balance, check out:

Summary

The Junior Intern rule isn’t about rejecting AI—it’s about using it strategically. Let AI handle the grunt work while you maintain ownership of:

  1. All architecture decisions
  2. Core business logic
  3. Final code quality
  4. Deep understanding of what ships

Your velocity will drop. Your craftsmanship will survive. And when you’re standing in front of a whiteboard in an interview, you’ll actually be able to explain the code you wrote.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!

Comments

Tags: