The AI Is a Very Fast Junior Engineer

AI in The Wild | Part V

Field notes from real enterprise projects. No theory. Just what actually happened.

Imagine hiring an engineer who can write code, generate reports, convert files, summarize documentation, refactor components, and draft test cases in seconds.

They never complain about scope changes. They never get tired. They are available whenever you are. They can move faster than anyone on the team.

There is one catch.

They do exactly what they understood you to want.

Not what you meant. Not what would have been architecturally cleaner. Not what someone with ten years of context would have inferred. What they understood from what you gave them.

That is the best mental model I have found for working with AI.

The AI is a very fast junior engineer.

That is not an insult. A good junior engineer is valuable. They are capable, motivated, and often incredibly productive when the task is clear. But they need good inputs, clear boundaries, explicit rules, and someone senior enough to know when “completed the task” and “solved the problem” are not the same thing.

AI is the same.

If you treat it like magic, the results feel random. One session it nails the work. The next session it produces something technically correct that solves the wrong problem with absolute confidence, like a golden retriever driving a forklift.

If you treat it like a fast junior engineer, the failure modes become easier to predict. You stop asking, “Why did the model do that?” and start asking a better question:

What did I give it enough information to do?

That question changes everything.

The “very fast junior engineer” frame works because it keeps expectations grounded.

Junior engineers are not bad engineers. They are just still building context. They can execute quickly, but they usually need the problem framed correctly. They need to know what matters, what does not matter, where the boundaries are, and when to stop.

That is exactly how AI-assisted work behaves.

The model can generate a clean implementation, but it does not automatically know whether the implementation belongs in the architecture. It can follow a rule, but only if the rule is present and strong enough to matter. It can solve the example you gave it, but it does not know whether the example represents one case or fifty. It can keep working inside a long session, but that does not mean the session still has the right context.

This series has really been about one idea from five angles:

AI is powerful, but it is not self-managing.

You still own the architecture. You still own the context. You still own the rules. You still own the scope. You still own the difference between a passing result and the right result.

The AI can help you move fast.

But you are still responsible for where it is moving.

Every article in this series maps to one management practice.

Not prompt tricks. Not magic phrases. Just the same basic discipline you would use with any capable but context-limited teammate.

1. Define the Scope Before the Work Starts

Undefined scope becomes interpreted scope.

And interpreted scope is where the wheels start making noises the brochure did not mention.

If you ask the agent to “clean this up,” it will decide what cleanup means. If you ask it to “fix the bug,” it will decide how far the fix should go. If you show it one example without explaining the larger pattern, it will solve for one example.

That is not the agent being lazy. That is the agent working with the contract you gave it.

Before consequential work, define three things clearly:

Goal:
In scope:
Out of scope:

That little block saves a shocking amount of pain. It tells the agent where to aim, where not to wander, and what success actually means.

A new engineer with a vague brief will still do something.

It just may not be the thing you wanted.

2. Give It the Current Inputs, Not the Inputs You Remember

AI solves from what it sees, not what you meant.

That means stale screenshots, old file paths, outdated docs, and “I’m pretty sure this is still true” context are all dangerous. The agent cannot reliably know that the file path you pasted was correct two weeks ago but wrong today. It cannot know that your screenshot is stale. It cannot know that the repo moved unless you tell it.

This is where a lot of AI work creates fake progress. The agent produces a clean fix against a bad input. Everything looks reasonable. The explanation makes sense. The code may even be good.

It is just aimed at the wrong target.

Before each session, confirm the current state:

Current path confirmed:
Current environment:
Current source of truth:

Do not make the agent renovate the wrong house.

It will do a beautiful job.

That is the problem.

3. Enforce Rules Instead of Hoping They Are Remembered

Rules without enforcement are just suggestions.

If a rule lives only in a README, wiki page, or side document, the agent might use it. It also might not. Documentation is useful, but it is not the same thing as enforcement.

If something must be true every session, move it into the primary instruction channel. If something is critical, back it with tests, permissions, hooks, validation, or CI.

There is a hierarchy here:

Suggestions
  ↓
Documentation
  ↓
Primary Instructions
  ↓
Technical Enforcement

The higher the rule sits, the less it depends on memory.

This matters because AI agents optimize inside the system you give them. If the fastest path to success violates a rule that is only documented somewhere, do not be shocked when the agent takes the shortcut.

That is not rebellion.

That is bad system design.

A good manager does not just tell a junior engineer the rule once and hope it survives every future assignment. They build the rule into the workflow.

4. Keep Sessions Small Enough to Manage

Long sessions feel productive until they become haunted.

The context window fills up. Earlier assumptions linger. The model starts pattern-matching against its own prior work. You keep adding “one more thing,” and suddenly the session has become an eight-hour meeting with a keyboard.

Nothing good happens in that room.

AI works best when the unit of work is small, explicit, and bounded. One session should have one job. Not one entire project. Not one sprawling cleanup. One job.

Define the task. Generate the output. Save it. Test it. Close the loop.

If the next task depends on the first, start fresh with the current state and the specific artifact you want to continue from. That sounds slower, but it is usually faster than trying to debug why step nine got weird because of something the model half-remembered from step three.

An eight-hour meeting does not produce eight hours of good thinking.

Same principle.

5. Know What the AI Should Not Own

The most important management skill is knowing what not to delegate.

AI is useful for ambiguity, translation, drafting, exploration, summarization, pattern recognition, and edge cases. It is much less trustworthy as the owner of deterministic business logic, final system-of-record decisions, or architecture boundaries that need to behave the same way every time.

If something has a correct answer, put it in code.

If something requires judgment, the AI may have a role.

That distinction is the difference between using AI as leverage and using AI as a slot machine with a sprint board.

You would not ask a junior engineer in week one to redesign the whole platform architecture, define the governance model, and decide which business rules should be deterministic.

You would give them structure.

Then you would let them move fast inside it.

Do the same with AI.

The lesson across this whole series is not “write better prompts.”

That is part of it, but it is not the center.

The real lesson is that AI-assisted work is still engineering work. It needs precise inputs, clear scope, enforced constraints, small units of work, and deterministic systems where correctness matters.

The agent can move fast, but speed does not remove your responsibility. It amplifies it.

A bad instruction becomes bad output faster. A stale path becomes fake progress faster. A missing rule becomes drift faster. A vague scope becomes a wrong solution faster.

That is the trade.

AI compresses time.

It does not remove judgment.

The failure modes are predictable once you know what to look for. That is good news. Predictable failure modes can be designed around. They can be checked, constrained, tested, and managed.

That is the job.

A very fast junior engineer is one of the best hires you can make.

But only if you manage them well.

Give them the right problem. Give them the current inputs. Give them the rules that matter. Keep the work bounded. Do not hand them ownership of decisions that belong in the architecture.

Do that, and AI becomes leverage.

Skip that, and AI becomes a very confident machine for producing expensive confusion at industrial speed.

The AI is ready to work.

The question is whether you have set it up to succeed.

The AI is a very fast junior engineer.

Manage it like one.