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

Picture a junior developer who never gets tired, works faster than you can type, and will happily build whatever you ask. The catch: they don't have the judgment to know when "whatever you asked" is a bad idea. That's what working with AI feels like right now. The people who win with it didn't find a better tool. They learned to manage that junior developer.

Here's the whole post in one line: stop using AI like a vending machine and start directing it like a new hire. That one shift changes everything.

One quick translation first, 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 suggest the next word, but go do a multi-step job — and learning to direct it well. Less spell-checker, more new hire.

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 take whatever it hands back. It feels productive. It usually isn't.

The gap I keep seeing: there's a real 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. And if you're 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 does the whole job. It reads through a project, changes multiple files, runs the tests (the automated checks that confirm the code still works), and opens a pull request — the formal "here's my finished work, review it before we ship" step teams use. It went from finishing your sentence to handing you a 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 frame that fixes everything: treat it like a junior developer

This is the 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 — same as 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 blows up six months out. So it produces work that's 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 brings speed and knowledge. You bring judgment and context. Neither one is optional.

Context is king — and it costs you

"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. Only so much fits 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 whole handbook onto their desk. You tell them the three things they need for this task.

Takeaway: give 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 you touch 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 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 you get all three at half quality. AI's no different.

Takeaway: one clear job beats one big blurry one.

Keep your rules outside the conversation

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 (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 and 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 like 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, review before moving on.	A clean desk every time, and you catch context mistakes early while they're cheap.

From my own bench

I don't manage a team of human developers — the developers I direct are AI agents. And the first time I handed one a half-finished spec, with placeholder text and notes I'd forgotten to strip out, it built exactly that. Faithfully. Comic Sans and all. It wasn't wrong. It did precisely what I gave it. The fault was mine — I handed over messy context and got a messy result right back.

That's a lesson I relearn constantly. An agent runs with whatever you give it, baggage included. It doesn't quietly clean up your sloppy thinking the way a seasoned coworker might — it amplifies it. So now I slow down and tidy up what I'm handing over before I hand it over, because a vague brief doesn't get better on the other side. It just gets bigger.

Where people get burned

• 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: run the research-plan-build loop. The AI multiplies your up-front thinking — and 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.

Worth a look, and a question

• 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 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 — 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 research-plan-build. Treat 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