LOCKEDIN / FORWARD-DEPLOYED ENGINEERING 101
Understand it.
Then build it.
You can be an experienced engineer and still be new to agents. Start with what each thing is and how it helps a person do useful work. Explore 58 original introductions across software, agents, cloud, security and delivery. Start here without a model key; each topic connects to deeper instruction and practice.
A place to start.
Choose a short reading route, or look up a concept below.
- 101UnderstandPlain language, visual walkthrough, vocabulary
- 102Build with guidanceOriginal lessons, examples and knowledge checks
- 103Practise and explainRunnable labs, failure cases and handover
Connect the software
Separate editable files, selected snapshots and recorded commits. Match the tested content to the change you hand over.
See the 9-concept route
For people who want the software vocabulary behind AI tools, or a refresher before their first local build.
- 01Terminal & CLIBegin with a person issuing a command to a program; the terminal is not itself an agent.
- 02ConfigurationUnderstand how that program receives its settings and why different processes can behave differently.
- 03JSON & schemasRead the messages programs exchange. Separate a field's name, type and meaning before following an API request.
- 04APIsMove from a person using a command to one program requesting something from another.
- 05RESTSee how resource addresses, HTTP methods and status codes organize a web API.
- 06SDKsFollow the library code that turns a convenient method call into an API request.
- 07TestsDecide what observable behavior to check before trusting a change made by a person or an agent.
- 08GitYou are here
- 09Claude CodeBring commands, configuration and checks into a bounded coding-assistant task.
Bookmark this page to return to this concept. The number shows your place in the reading route; it is not an assessment result.
Version control and reviewable changes
What is Git?
Git is a distributed version-control tool. It records selected snapshots of files so you can compare changes, recover earlier versions and collaborate. It runs on your computer; a hosting service such as GitHub can hold another copy of the repository. Git is separate from your editor, coding agent and deployment system.
When you or a coding agent change an application, an FDE must explain what changed and which version was checked. Saving a file, selecting it for a commit and recording that commit are distinct actions. Understanding them keeps unrelated work out of a handoff.
UNDERSTAND THE SYSTEM
Which version are you handing over?
Follow one fictional policy.json change through actual Git states. The diagram explains the local lab; it does not edit your files. Values show max_items in each version.
Read the connections in plain English
- 01Working tree → Index / staging area
Copy the selected file's current bytes into the index.
- 02Index / staging area → Recorded commit
Record the current index in a new local commit.
- 03Working tree → Working-copy check
The fixture check reads the working file, not Git history.
- 04Working-copy check → Handoff evidence
A passing result is useful only for the content it actually checked.
- 05Recorded commit → Handoff evidence
Read the committed file and compare it with the checked candidate.
Check your understanding: An agent says the working-copy check passed. Does that prove the commit contains the checked change?
No. Inspect the selected and committed bytes. In the default lab, the working file contains 3 but the commit contains 2. Match test evidence to the exact candidate; a Git snapshot alone proves no application behavior.
CONNECT IT TO WHAT YOU KNOW
Start with something familiar.
Think of preparing a document for a colleague. You have a draft on your desk, a selected copy ready to send and a previously recorded version. Editing the draft does not silently replace the copy you already selected.
Git stores project snapshots and history, not just three physical documents. Staging can select individual changes, and commit options can change what gets selected. This first exercise models an ordinary commit of one complete file. Recording it establishes no approval or deployment.
Words worth knowing
- Repository
- The stored history and metadata for a project. A local repository lets you inspect and record changes without a hosting account.
- Working tree
- The files you can edit in the checkout. Saving an edit changes these files.
- Index / staging area
- The proposed next snapshot. Staging selects content as it is now; it does not subscribe to later edits.
- Commit
- A recorded snapshot with metadata and links to its history. An ordinary git commit records the index. It does not run tests or deploy by itself.
- Branch / HEAD
- A branch is a movable name pointing to a commit. HEAD normally identifies the checked-out branch; it can also point directly to a commit.
- Remote / push
- A remote names another repository. Pushing sends objects and updates references there. Whether that starts a deployment depends on separate configuration.
Useful foundations
Open a definition and diagram here. Your lesson stays in place.
Interfaces to programsWhat are a terminal, a shell and a CLI?
QUICK REFERENCE / 101
What are a terminal, a shell and a CLI?
A terminal is the window where you type and see text. A shell interprets your commands. A command-line interface (CLI) is how a program accepts those commands. An AI coding agent can use a terminal, but the terminal itself does not reason or decide what to do.
You need to understand what will run, in which folder, and with whose authority before approving a coding agent's action.
Data a program can read and checkWhat are JSON and schemas?
QUICK REFERENCE / 101
What are JSON and schemas?
JSON (JavaScript Object Notation) is a text format for exchanging data between programs. An object pairs field names with values, like a small form with named boxes. JSON Schema describes rules for those values. Neither is an AI model, and JSON works with many programming languages.
An API response, an agent's tool arguments and a model's structured answer often arrive as JSON. Before connecting them, an FDE needs to read the fields, recognize their types and explain why readable data can still be wrong for the task.
ONE EXAMPLE / FICTIONAL CASE
Follow the connections.
A fictional policy file starts with max_items set to 1. You edit it to 2 and stage that version. Then you change the file to 3. Your working file, staging area and latest commit now contain three different values. Which one would the next ordinary commit record?
UNDERSTAND THE SYSTEM
Which version are you handing over?
Follow one fictional policy.json change through actual Git states. The diagram explains the local lab; it does not edit your files. Values show max_items in each version.
See what moves and why.
Read the connections in plain English
- 01Working tree → Index / staging area
Copy the selected file's current bytes into the index.
- 02Index / staging area → Recorded commit
Record the current index in a new local commit.
- 03Working tree → Working-copy check
The fixture check reads the working file, not Git history.
- 04Working-copy check → Handoff evidence
A passing result is useful only for the content it actually checked.
- 05Recorded commit → Handoff evidence
Read the committed file and compare it with the checked candidate.
Check your understanding: An agent says the working-copy check passed. Does that prove the commit contains the checked change?
No. Inspect the selected and committed bytes. In the default lab, the working file contains 3 but the commit contains 2. Match test evidence to the exact candidate; a Git snapshot alone proves no application behavior.
Work through it, step by step.
Change the working file
Edit the policy to 2. The working tree changes, while the index and recorded commit still contain 1. Reading a file in your editor shows the working copy.
What you have now: An editable change, not yet selected for the next commit.
Select what belongs together
Stage only policy.json. Then edit its working value to 3. The index still contains 2. git diff shows working changes relative to the index; git diff --cached shows the index relative to the current commit.
What you have now: Two comparisons: unstaged 2 to 3 and staged 1 to 2.
Record and match the evidence
An ordinary commit records 2. A check of the working file can pass for value 3 without describing that commit. Inspect both versions; if the later change is intended, review it, stage it and record it deliberately.
What you have now: A specific committed version and evidence whose scope you can explain.
See what your commit records.
Change the working file, select a snapshot, then predict what gets recorded. These controls model Git’s behavior in this page; they do not run Git or touch your files.
Try this: set 2 → stage it → set 3 → predict the commit. Keep all three versions in view.
- Working
- 1
- Staged
- 1
- Recorded
- 1
What your editor sees now
{
"max_items": 1
}Saving an edit changes this copy. It leaves the staging area and history alone.
What the next commit will use
{
"max_items": 1
}git add -- policy.jsonSelect the file’s current contents. This is a snapshot, not a live link to later edits.
The starting snapshot
{
"max_items": 1
}No staged changes to record. Edit and stage a value first.
Staging area → working file
Latest commit → staging area
Which version passed?
Our small rule asks only whether max_items = 3. It is a value comparison, not an application test suite.
Run it after your first commit. Does its result describe the recorded version?
FROM RECOGNITION TO REASONING
Make three versions. Predict which one gets recorded.
- 01
Set the working value to 2 and stage it. Then change only the working value to 3.
- 02
Predict what the next ordinary commit will record, and commit the selected snapshot. Check the working value and compare it with the recorded one.
- 03
Stage the later change and commit again. Then run the free local lab to see real Git output, an unrelated file and a branch reference.
An explanation of working 3, staged 2 and committed 1, followed by the commit result and the exact value your check covered.
Compare your reasoning when you are ready
Staging copied 2 at that moment, so the first commit records 2 even though the working file contains 3. A check of the working file only covers 3. Restaging selects the later value; a second commit can record it. That still proves only the value comparison shown here, not application behavior.
Keep notes in your own working copy. Moving through these cards does not record completion.
TURN THE IDEA INTO USEFUL WORK
You can now go deeper.
Git records the content you select. A passing check belongs to the bytes it inspected. Match the candidate, the diff and the evidence before handing work to another engineer.
Academy lessons use your existing training access. Free guides stay open.