The SWE Intern's Dilemma

Written with Swiftly

I got the internship. Now what?

AI tools can write code faster than I can, so the question I feel like we’re all grappling with is: how do I actually learn when the tools can just do it for me?

I’m joining Cloudflare this summer on the core SRE team, and I’ve been thinking about this a lot. I’ve compiled a framework for how I’m preparing for the role, and hopefully it’s helpful for you!

Learning the Stack Before Day 1

The goal of preparing isn’t to become an expert, but to be literate enough to follow conversations, read the code without getting lost, and stay in the loop with your team.

For me, that means Go and Kubernetes. Whatever languages it is for you, the specifics don’t matter! The framework does:

Pick 2-3 core technologies and go just deep enough. You want to understand the syntax, the mental model, and the basic vocabulary. Not mastery. Just fluency. Just enough that you’re able to search things up to recall as you go.

For Go, I’m working through A Tour of Go, then probably building a small CLI tool. Something practical rather than reading tutorials. Building a small project, like a log parser, is the key differentiator between “I read about it” vs “I can use it.” Just write some code!

For Kubernetes, I’m learning pods, workloads, nodes, and deployments. If I understand those four concepts I can follow most SRE conversations without pretending. And because this is SRE, I’m also learning the reliability framework: SLOs, error budgets, monitoring signals, toil. Every team has its own domain language. Figure out what yours is and learn enough to not be lost when people start throwing acronyms around (but I’ve been told not to be hesitaant about asking as many questions as you can, which I also will be doing!)

The point is to not be starting from zero on day 1.

Using AI Without Losing the Learning

This is my burning question. We know that experience software engineers are able to build and ship faster with AI, especially because they’re able to understand the code being written and can differentiate what’s effective, and what will break the codebase. But as an intern, how can we get to that point while still maintaining the performance that AI tools can give you?

Claude Code, Copilot, ChatGPT. They can write functions, debug errors, explain concepts. The temptation to let them do the heavy lifting is real, especially when you’re new and everything feels hard. But if you let AI write your code, you’ll ship things you can’t explain. And when your manager asks you to walk through your PR, that’s a bad place to be.

Write first, then ask AI to review. I write the first draft of everything. Then I ask Claude to poke holes in it. Find edge cases, catch what I missed, suggest improvements. But I’m always driving. The code is mine. The AI is a second pair of eyes, not the author. The feedback Claude gives here is also a learning opportunity to figure out the best approach to problems.

However, from experience building with Claude as a pair programmer, sometimes it’s much better to write the naive solution that’s easier to walk through, than it is to write up the most efficient solution. Except this time, I’ll have to actually weigh the cost and benefits of doing so, since we’re dealing with code at a massive scale now.

If you can’t explain a suggestion, you haven’t learned it. This is the hardest rule to follow. When AI suggests a change, don’t just accept it. Understand why it works. If you can explain it to a non-technical person, you’ve learned something. If you can’t, you’re just copy-pasting with extra steps. I know engineers do this at every level, but the point is to really learn!

Ask AI to explain errors, not just fix them. When something breaks, it can be tempting to ask Claude to fix it. Debug it yourself… okay, at least be able to pinpoint where the problem is coming from!

Use the built-in friction. One thing I really like about Claude Code is the permissions model. It asks for approval before writing files or running commands, and that built-in pause forces me to review what’s actually happening instead of blindly accepting everything. It’s like a mini code review on every action. Taking that bit of time to intervene and check on the tool’s suggestions can really help your code comprehension!

Speed without comprehension is just technical debt. Not good if you’re going to do this as a career.

What You Can Only Learn by Struggling

Some skills don’t have shortcuts. AI can’t give them to you.

Codebase intuition. The intuition for how a codebase fits together only comes from grappling with it yourself. AI can help you understand a specific function, but it can’t give you the map of how everything connects. To me, that’s where the value of software engineer is in the era of AI agents.

Start a learning journal. Every day, I plan to write down what I’ve learned, what confused me, and what I debugged. By the end of my three months, these debugging notes will become my reference. A year from now, they’re proof of how far I’ve come. The best engineers I’ve talked to all have some version of this habit.

Operating as a Teammate

I plan on communicating with my teammates and manager often, but concisely.

Some things I’ve gathered from my research (Compiled with Claude):

Ask what success looks like. First week, sit down with your manager and ask: what does success look like for this role? It would serve you well to know the target on day one than figure it out in month three. This one question saves you from spending weeks optimizing for the wrong thing.

Make your work visible. Send weekly updates on what you shipped, what’s blocked, and what’s next. Keep PRs small and well-described. Demo your work in retros when you can. Nobody can appreciate work they don’t know about. This isn’t self-promotion. It’s communication, and it’s part of the job.

Ask questions, but do your homework first. Google it. Check the docs. Read the code. Then ask, and when you do, show your work: “I tried X, I’m stuck at Y, here’s what I think is happening.” This shows your team you respect their time while still being willing to ask for help. Nobody expects you to know everything. They expect you to try.

Talk to people. I’m planning to schedule a couple coffee chats a week once I’m there. Engineers, SREs, managers. Anyone willing to talk. I want to understand how people got to where they are and what they’d tell someone starting out. The relationships you build during your internship will outlast any code you write.

About impostor syndrome: you’re going to feel it. Every intern does. You’ll sit in a meeting and wonder if you’re the only one who doesn’t understand what’s going on. You’re not. You were hired for a reason. Don’t let the discomfort stop you from asking questions or sharing your ideas. The feeling fades. Showing up doesn’t.

The Real Prep

The best preparation for an internship isn’t mastering everything beforehand. It’s building the habits that let you learn fast once you’re there.

Learn enough of the stack to not be lost. Use AI as a tool, not a crutch. Sit with the hard problems long enough to actually understand them. Communicate like a teammate, not a student waiting for instructions.

Let’s do it!