Agentic Engineering: How to Work With AI Like It's Your New Junior Developer

Picture an eager junior developer who never gets tired, works faster than you can type, and will happily build whatever you ask. The catch: they don't yet have the judgment to know when "whatever you asked" is a bad idea. That's what working with AI feels like right now. And the people who win with it aren't the ones with the fanciest tools — they're the ones who learned how to manage that junior developer.

Quick translation before we start, because I want this to land whether or not you write code for a living. "Agentic engineering" just means working with AI that can take actions on its own — not just suggest the next word, but actually go do a multi-step job — and learning how to direct it well. Think less "spell-checker" and more "new hire." That one shift changes everything about how you should use it.

Why this matters

Most people use AI the lazy way. They treat it like a smarter autocomplete — that thing on your phone that finishes your sentence — and they accept whatever it hands back. It feels productive. It usually isn't.

Here's the gap I keep seeing: there's a big difference between using an AI tool and working with it. Using it is passive — you poke it, it spits something out, you paste it in. Working with it is a partnership — you set it up to succeed, you check its work, you correct it. Same tool, completely different results. If you're an engineer drowning in work, that difference is the whole game.

What actually changed

A couple of years ago, AI coding tools mostly finished your sentences. You'd start typing and it would guess the rest of the line. Helpful, but small.

Today's AI can do the whole job. It can read through a project, change multiple files, run the tests (the automated checks that confirm the code still works), and even open a pull request — that's just the formal "here's my finished work, please review it before we ship it" step that teams use. In plain terms: it went from finishing your sentence to handing you a finished draft of the whole document.

That's the leap. The AI stopped being a tool you use and became a teammate you direct. Takeaway: if you're still treating it like autocomplete, you're using a forklift to carry one box.

The mental model that fixes everything: treat it like a junior developer

This is the single most useful frame I've found. The AI is a fast, incredibly well-read junior developer. It has read more code and documentation than any human ever could, and it writes with total confidence.

But — just like a real junior hire — it doesn't know your situation. It doesn't know why your team does things a certain way, what the customer actually needs, or which "clever" solution will blow up six months from now. So it produces work that is technically correct and contextually wrong. The code runs; it just solves the wrong problem.

You wouldn't hand a brand-new hire a vague request and ship their first attempt straight to customers without looking. Same rule here. Takeaway: the AI supplies speed and knowledge. You supply judgment and context. Neither one is optional.

Context is king — and it's expensive

"Context" is just the information you give the AI to work with — the background, the rules, the relevant files. Common sense says more context = better answers. Common sense is wrong here.

Every AI has a context window — think of it as the size of its desk. You can only fit so much on the desk at once. Pile on outdated notes, irrelevant files, and three old conversations, and the important stuff gets buried. The AI gets confused and the quality drops. I've watched a model give a worse answer because I gave it more, not less.

The skill isn't dumping everything in. It's curating — handing it exactly what matters and nothing else. Like briefing a new employee: you don't photocopy the entire company handbook and drop it on their desk. You tell them the three things they need for this task. Takeaway: feed the AI a clean, focused desk, not a junk drawer.

Stop coding first. Research, then plan, then build

The most expensive mistake is letting the AI (or yourself) jump straight to writing code. You get something fast, and it's usually wrong in a way that takes longer to untangle than doing it right would have.

The loop I use, and the one I'd teach anyone:

1. Research first. Understand the problem completely before touching anything. What are we really solving? What could break? What are the edge cases — the weird, rare situations that trip everything up?
2. Plan second. Write down the actual steps. Which files change, how you'll test it, where the boundaries are. A real plan, not a vibe.
3. Build third. Now you let the AI write code — against a clear plan, in small pieces.

Same idea as a construction site: you don't pour the foundation before there's a blueprint. The research and planning are the blueprint, and they're exactly the part people skip. Takeaway: the thinking you do up front is what makes the AI's speed actually pay off.

Give it one job at a time

You can steer the AI by putting it in a specific "mode" — basically telling it which hat to wear:

• An ask mode for research — "help me understand this, poke holes in my thinking."
• An architect mode for planning — "help me design the steps."
• A code mode for building — "now write it, and only that."

Narrow the job and the AI focuses. Ask one person to research, design, and build all at once and they'll do all three at half quality — AI's no different. Takeaway: one clear job beats one big blurry one.

Keep your rules outside the conversation

Here's a practical trick. Instead of re-explaining your conventions every single time, you write the important stuff down in plain files that live alongside the project — people commonly call them things like agents.md (the standing instructions for the AI) or skills.md (reusable how-tos). Your naming rules, your common commands, how your systems connect.

The AI reads those when it needs them, so you're not burning desk space repeating yourself. It's the difference between training a new hire from scratch every morning versus handing them a one-page cheat sheet they can glance at. Takeaway: write the rules down once; don't re-explain them every conversation.

Treat AI work the way you'd treat a junior's work — reviewable

You'd never let a new hire push changes straight into the live product with nobody checking. Give the AI the same guardrails.

The tool for this is version control — software (almost always one called Git) that tracks every change and lets you undo anything. Two pieces matter:

• A branch is a safe sandbox copy of the project. The AI works there, so a bad idea never touches the real thing until you say so.
• A commit is a labeled save point. Frequent small commits mean you can always roll back to the last good moment — like saving your game often instead of risking hours of progress.

Work in a branch, save often, review before it merges in. Takeaway: make AI mistakes cheap to undo, and they stop being scary.

Try it today

You don't need to overhaul anything. Run one task through this and feel the difference:

Step	What you do	Why it pays off
1. Define the problem clearly	Write a short brief: what's the issue, what's the context. Use an AI "ask" mode to brainstorm the edge cases you'd miss.	The AI actually understands the job, so it stops solving the wrong thing.
2. Make a precise plan	Lay out the steps — which files change, how you'll test it, what's out of scope. Use "architect" mode to help.	Clear goals and a finish line keep the AI focused instead of wandering.
3. Build in small pieces	Start a fresh AI session just for writing the code, make small save points, and review before moving on.	A clean desk every time, plus you catch context mistakes early while they're cheap.

A story from my own career

Early on, when I was managing developers, I handed a junior team a wireframe — a rough sketch of a screen — as the spec. Except mine was full of placeholder fonts and emojis I hadn't cleaned up. They built exactly that. Comic Sans and all. They weren't wrong; they did precisely what I gave them. The fault was mine — I handed over messy context and got messy results back.

Working with AI taught me the same lesson again, harder. The agent will faithfully run with whatever you give it, baggage included. So now I slow down and clean up what I'm handing over, because a sloppy brief doesn't get cleaned up by the AI — it gets amplified by it.

Where people go wrong

• Too much (or too messy) context. Flooding the AI with every detail backfires. Fix: start fresh sessions often, and summarize the important bits from the last one instead of dragging the whole history along.
• Skipping research and planning. Diving straight into code gets you fast garbage. Fix: do the research-plan-build loop. The AI multiplies your up-front thinking — if there's no thinking, it multiplies zero.
• Accepting everything it says. Confident and correct are not the same thing, with people or with AI. Fix: review its output like a junior's pull request. Keep it in a branch, check it, correct it.

Tools and a question to sit with

• A tool to try: GitHub Copilot — an AI assistant that suggests and writes code right inside your editor. A solid on-ramp if you're starting out.
• A podcast worth your time: The Pragmatic Engineer — especially the episodes on how real teams are folding AI into their daily work.
• A question to actually sit with: What would change about my day if I treated AI as a teammate I direct, instead of a tool I lean on?

The bottom line

Working with AI is like driving a much faster car. The speed only helps if you know where you're going and you're actually steering. Most people have used an AI tool by now (my estimate — adoption is clearly high and climbing), but very few have learned the part that matters: managing context and running a real workflow.

So here's the honest question. Are you letting AI fill in the blanks for you, or are you directing an eager, tireless teammate to take on your hardest problems? Commit to the research-plan-build mindset. Start treating AI less like a vending machine and more like a junior developer who's hungry to learn — and watch both your output and how much you enjoy the work climb.

— Dru Edwards