From Engineer to AI Engineer
The Field Kit · the prompt guide

How to talk to the machine

You do not need to know everything about AI to start using it well. You need a few good habits, and the patience to make it teach you. Here they are.

6 min readKhurram Saleem

If you are early in your career, the AI conversation can feel like it is happening in a language you were never taught. Everyone has an opinion, half the words are new, and it is not obvious what is worth learning and what is noise. So this page does one plain thing, and does it well. It is a field guide to prompting that turns the model into a patient teacher rather than a crutch you lean on and never grow past.

Take it slowly. You are not behind. Most of what looks like fluency in others is just familiarity, and familiarity is exactly what a little practice will give you.

// The Kit

How to talk to the machine

A prompt is not a magic spell. It is a brief, the kind you would give a sharp new colleague who knows everything and nothing about your problem. Here is the shape of a good one, the secret that makes it work, and prompts that make you better instead of lazier.

The shape of a prompt

Role

Who it should be. "A patient senior engineer."

Context

What it needs to know. The code, the goal, the constraints.

Task

The one clear thing to do. Not five things at once.

Format

How you want the answer. Steps? A table? Commented code?

Limits

What not to do. "Do not change behaviour. Do not guess."

Example

Show one, if you can. One good example beats a paragraph of rules.

Assembled, that looks like this:

[Role] You are a patient senior engineer teaching a junior. [Context] Here is my function and what it is supposed to do: ... [Task] Find why it returns the wrong total for empty carts. [Format] Explain the cause first in plain words, then the fix. [Limits] Do not rewrite the whole file. Do not guess; reason it out. [Example] A good answer starts: "The bug is X, because Y..."
The one secret

These shapes are templates, not prompts. Your context is what makes them work. The model cannot read your mind or your repository. Tell it everything a new teammate would need on their first day, and it answers like a teammate. Tell it nothing, and it answers like a search engine that is occasionally making things up.

Five prompts that make you better

Copy these, swap in your own context, and notice what they all have in common: every one asks the model to teach you, not just hand you an answer.

Prompt 01

Explain this like I just joined

Walk me through this code as if I just joined the team. What does it do, why is it built this way, and what would I break if I changed it? Use plain language, and end with the one thing I should understand before I touch it.
Why it works: it turns the model into a patient onboarding guide. You understand the code before you edit it, which is the whole difference between learning and copy-pasting.
Prompt 02

Review me like a kind senior

Review my code like a senior engineer who wants me to grow, not feel small. Point out what is wrong, what is risky, and what is genuinely good. For each one, tell me the principle behind it, so I learn the rule and not just this fix.
Why it works: feedback plus the reasoning behind it. You leave with a rule you can apply next time, which is how a single review turns into a hundred better lines later.
Prompt 03

Debug with me, not for me

Help me find the root cause of this bug. Do not just hand me a fix. First explain what the code actually does, then trace the failure step by step, then give me your hypothesis and how to test it. Do not guess. Think it through.
Why it works: "do not guess, think it through" is borrowed from how senior engineers run a real incident. You learn to debug, instead of pasting a patch you could not have written and will not understand next time.
Prompt 04

Be the teacher, then the quiz

Teach me [topic] in plain language, building from what a working engineer already knows. Use one concrete example. Then ask me three questions to check whether I actually understood it, wait for my answers, and correct me.
Why it works: being quizzed forces active recall, which sticks far better than nodding along. The model becomes a tutor with infinite patience and no judgement.
Prompt 05

Challenge my plan

Here is my plan for [task]. Before you agree with it, challenge it. What am I missing, what is the simplest version that would still work, and what would a senior engineer do differently? Then give me your honest recommendation.
Why it works: by default the model is agreeable. "Challenge it before you agree" flips that, and catches the mistake while it is still cheap, on a plan, instead of expensive, in code.
The rule that matters most
Use the machine to learn, not to skip learning.

The fastest way to stay junior forever is to ship answers you do not understand. The fastest way to grow is to make the model explain until you could have written it yourself. AI can draft the code. It cannot hold the understanding for you, and it cannot answer for the result. Those stay yours, and they are what make you an engineer.

When you outgrow these, the same habits scale up. Two prompts worth keeping for the years ahead are the production-debugging brief ("trace the root cause, do not guess") and technical-lead mode ("challenge my decisions before you write any code"), the grown-up versions of prompts 03 and 05 above. The shape never changes: give context, ask it to think, make it teach you.

// Where this goes next

From prompting to a path

These habits are the start. When you want the bigger picture, or to turn it into a direction, here is where it goes.

The foundations

What to learn in 2026

The map of what is actually worth understanding, walked one layer at a time, and why the fundamentals still win.
The guide

From Engineer to AI Engineer

The mindset, the skills, and the map of how a working engineer actually becomes an AI engineer.
2-minute quiz

Which AI role are you?

Nine AI-lifecycle roles, one short quiz. Find where your instincts already point before you commit.