The Agentic Crew: Crew Member's Guide

Rasmus Bornhøft Schlünsen

The Agentic Crew: Crew Member’s Guide

For people who are great with computers — but don’t write code.

Rasmus Bornhoft Schlunsen

March 2026

A Note Before We Start

This book is a companion to The Agentic Crew: Engineering in the Age of AI Agents. That book was written for software engineers — people who write code for a living. This one is for everyone else who’s good with computers.

Maybe you’re a project manager, a designer, a sysadmin, a data analyst, a small business owner, or just the person in your family who fixes the Wi-Fi. You live in spreadsheets, manage inboxes like a general, and right now you have forty-seven browser tabs open. But you’ve never written a line of code — and you don’t need to.

AI agents are changing how software gets built. That affects you, whether you work alongside developers, run a business that depends on software, or just want to understand what’s happening in the world around you. The ideas in this book are real. We’ve simplified the technical details, but we haven’t watered them down.

By the time you finish, you’ll understand what agents actually are, how modern software works under the hood, and — most importantly — how to direct an agent to build something real. No coding required.

Welcome to the Crew

The horizon is wider than you think.

Six months ago, my friend Morten told me he wanted to build an app for his business. Morten installs windows — the glass kind, not the Microsoft kind. He’s been doing it for fifteen years. He knows every window model, every frame type, every trick for getting a perfect seal in an old Danish farmhouse. He runs a crew of four guys, manages quotes on paper, and tracks jobs in a spreadsheet that would make an accountant weep.

Morten is brilliant with computers. He built his own NAS, runs a Plex server, automated half his smart home with scripts he found on Reddit. But he’s never written a line of code.

I told him about AI agents — tools that can write code, build interfaces, set up databases, all from plain language instructions. I showed him the basics. How to describe what you want. How to break a big idea into small tasks. How to check the output and steer when things go sideways.

What happened next surprised both of us. In a weekend, Morten had a working prototype. A quoting tool where he could enter wall measurements, pick a window model, see a 3D preview of what it would look like, and generate a PDF quote to email to the customer. It wasn’t perfect — the 3D preview had a lighting glitch and the PDF formatting needed work. But it was real. It worked. And he built it without writing a single line of code himself.

His clients started commenting on how professional his quotes looked. His crew started using it on tablets at job sites. A competitor asked who built his software.

Morten has zero years of programming experience. He just learned how to direct something that does.

What This Book Is

This is the guide I wish I could have handed Morten before he started. It’s built on the same principles as the engineering edition of The Agentic Crew, but translated for people who work with technology without building it from scratch.

You’ll learn what AI agents actually are — stripped of the marketing language. You’ll learn how modern software works under the hood, so you understand what agents are building when they build. You’ll learn how to communicate with agents clearly enough that they do what you mean, not what you said. And you’ll learn when to trust the output, when to push back, and when to do the job yourself.

This isn’t a book about prompts and tricks. It’s a book about thinking — the kind of thinking that turns a good idea into a working product, whether you’re the one writing the code or not.

Who This Is For

You’re good with computers. Maybe very good. You manage systems, wrangle data, configure tools, and troubleshoot problems that would send most people to the IT help desk. You’re the person your friends call when their printer won’t connect.

But you’ve never opened a code editor and typed function. You’ve never deployed a web server. You’ve never stared at a terminal full of error messages and known, instinctively, which line to fix.

That’s fine. You don’t need to.

What you need is a mental model — a way of understanding what these tools are, what they can do, and how to steer them. Because the person who knows what to build and can clearly describe it is, increasingly, the most important person in the room. More important than the person who can type the code. The code part is getting cheaper by the day. The thinking part never will.

How to Read This Book

This book is a journey, not a reference manual.

We start with what’s changing in the world and why it matters to you. Then we pop the hood on modern software — not to turn you into an engineer, but to give you the vocabulary and mental model to understand what agents are working with. From there, we get into agents themselves: what they are, how to talk to them, how to set boundaries, and how to verify their work.

In the second half, we build something real. Not a toy example. A working application for a real business, directed entirely through conversation with an agent. And we close with the harder questions — when things go wrong, when to step in, and what your role is in a world where code writes itself.

By the end, you won’t be a programmer. But you’ll be something that might matter more: someone who can direct one.

The Nautical Theme

You might notice this book talks a lot about ships, crews, and captains. That’s not an accident. The main edition of The Agentic Crew uses the metaphor of a ship’s crew throughout — the engineer as captain, the agents as crew members. The kids” edition takes it even further, with illustrated characters and adventures at sea.

In this edition, you’re the crew member. Not the captain — that’s the engineer who builds the ship. Not a passenger — you’re not just along for the ride. You’re a vital part of the crew. You know things the captain doesn’t. You see things from the deck that aren’t visible from the helm. And increasingly, you’re the one telling the crew where to sail.

Every great ship needs a captain. But no captain has ever sailed anywhere alone.

The Ground Is Shifting

The line between technical and non-technical is dissolving.

Last month, a friend of mine — a project manager at a mid-sized agency — needed to prepare a competitive analysis report. She’d normally spend two days on it: gathering data, cross-referencing pricing, building comparison tables, writing the summary. It’s the kind of knowledge work that requires judgment but is mostly grinding.

She opened an AI agent, described what she needed, gave it access to the relevant documents and a few web sources, and asked it to draft the report. Forty minutes later, she had a first draft that covered 80% of what she would have produced in two days. She spent another hour refining it — fixing a few inaccuracies, adjusting the tone for her audience, adding context only she knew. Done before lunch.

She didn’t become a programmer. She became something arguably more important: someone who knows how to direct a powerful tool toward a clear goal.

This is happening everywhere. Not just in software companies. Not just with developers. People who never expected to work with AI are discovering that the line between “technical” and “non-technical” is dissolving. Not because everyone’s learning to code — but because the tools are learning to listen.

The Old Line

For decades, there was a clear boundary. On one side: people who could code. They built the software, the websites, the tools. On the other side: everyone else. You used the software, submitted feature requests, and waited.

If you had an idea for an app, you had three options:

Learn to code yourself — a multi-year journey with no guarantee you’d get good enough.

Hire a developer — expensive, slow, and you’d spend most of your time trying to explain what you wanted.

Use a no-code tool — limited, frustrating, and you’d hit a wall the moment you wanted anything custom.

All three options had the same underlying problem: there was a translation gap between your idea and the working software. You knew what you wanted. You just couldn’t tell a computer directly.

That gap is closing.

The New Landscape

AI agents don’t eliminate the need for technical skill. But they dramatically reduce the barrier. The person who used to need a developer to build a custom tool can now describe what they want and have an agent produce it. Not perfectly. Not without iteration. But at all — and that’s the revolution.

Think about what this means:

The sales manager who needs a CRM that works the way her team actually sells — not the way Salesforce thinks everyone sells.

The restaurant owner who wants an ordering system that handles his weird menu structure and local delivery zones.

The window installer who wants a quoting tool with 3D previews.

These people always had the ideas. They always had the domain expertise — the deep knowledge of their own field that no software developer possesses. What they didn’t have was the ability to express that knowledge in a language computers understood.

Agents are becoming that translator.

What Hasn’t Changed

Before you get too excited — and before the engineers reading over your shoulder get too nervous — let me be clear about what hasn’t changed.

Building good software is still hard. An agent can produce code, but producing code isn’t the same as building a reliable system. There’s a reason the engineering edition of this book has chapters on testing, sandboxing, version control, and deployment pipelines. The agent gives you speed. It doesn’t give you judgment.

What this means for you: the things you bring to the table — domain expertise, user empathy, business logic, taste — are now more valuable than ever, not less. The bottleneck is no longer “can we build it.” The bottleneck is “do we know what to build, and will we know if it’s right.” That’s your department.

Why You Need This Book

Because nobody is explaining this transition from your side of the fence.

There are hundreds of books for engineers about working with AI. There are beginner coding courses that promise to teach you Python in thirty days. There are breathless blog posts about how AI will replace everyone.

None of that is useful to you. You don’t need to become an engineer. You don’t need to learn Python. And you’re not being replaced — if anything, your role is expanding.

What you need is enough technical understanding to work alongside these tools and the people who build them. Not to do their job. To do yours — better, faster, and with a seat at the table when the decisions get made.

That’s what this book provides.

What’s Under the Hood

Every app is a restaurant — front of house, kitchen, and pantry.

Your friend tells you they’re building an app. “It’s a Django backend with a React frontend, Postgres for the database, and Redis for caching.” You nod. You smile. You have absolutely no idea what any of that means.

This chapter fixes that.

We’re not going to turn you into an engineer. We’re going to give you the mental model — the map of the territory — so that when you hear these words, you know which part of the machine they’re talking about. And more importantly, when you direct an agent to build something, you’ll understand what it’s actually building.

We’re going to use one example throughout: a project management tool, like a simpler version of Trello. A board with columns, cards you can drag around, and people assigned to tasks. Simple enough to understand, complex enough to be real.

The Restaurant

Every web application is built from a handful of building blocks. Different apps use different specific tools, but the shape is always the same. The easiest way to understand it is to think of a restaurant.

A restaurant has a dining room — the part customers see. It has a kitchen — the part that does the real work. It has a pantry — where ingredients are stored. And it has a prep station — where frequently used ingredients are kept within arm’s reach so the chef doesn’t have to walk to the pantry every thirty seconds.

A web application has the same four parts. They just have different names.

React — The Dining Room

What it is: React is a frontend framework. It’s the part of the application that runs in your web browser — everything you see, touch, and interact with.

In our Trello clone: The board with its columns. The cards you can drag from “To Do” to “In Progress.” The button that says “Add Task.” The little avatar showing who’s assigned. The dropdown menu when you click the three dots. All of that is React.

Why it matters: React doesn’t store any data. It doesn’t make decisions about business rules. It’s the dining room — beautifully laid out, responsive to your every interaction, but it doesn’t cook the food. When you drag a card to a new column, React makes the card move immediately on your screen. But behind the scenes, it’s sending a message to the kitchen saying “the customer wants to move this card.” If the kitchen says no — maybe you don’t have permission — React puts the card back.

What you’ll hear people say: “It’s a React app” means the part you interact with is built using this tool. There are alternatives — Vue, Svelte, Angular — but they all do roughly the same job. React is the most common, like how most restaurants have a dining room regardless of which chairs they chose.

Django — The Kitchen

What it is: Django is a backend framework. It’s the brain of the application — the part that runs on a server, enforces the rules, processes requests, and decides what happens.

In our Trello clone: When you click “Add Task” and type “Buy groceries,” React sends that request to Django. Django checks: Are you logged in? Do you belong to this project? Is the task title valid? Is the project still active? If everything checks out, Django tells the database to store the new task and sends a confirmation back to React.

Why it matters: Django is where the logic lives. The pricing rules. The permission system. The business logic that says “only project admins can delete boards.” It’s the kitchen — it doesn’t care what the dining room looks like, and the dining room doesn’t care what brand of oven the kitchen uses. They communicate through a standardised order slip, which we’ll get to in a moment.

What you’ll hear people say: “The backend is returning an error” means Django (the kitchen) is choking on a request. “We need to add that logic on the backend” means the rule needs to live in Django, not React. There are alternatives — Rails (Ruby), Express (JavaScript), Laravel (PHP), FastAPI (Python, like Django) — but the concept is identical. A kitchen is a kitchen.

Postgres — The Pantry

What it is: Postgres (short for PostgreSQL) is a database. It’s where all the data lives — every user account, every project, every task, every comment, every timestamp.

In our Trello clone: When Django stores that new task, it goes into Postgres. Imagine a massive, meticulously organised filing cabinet. There’s a drawer labelled “Tasks,” and inside it, every task is a row:

ID

Title

Project

Status

Created

247

Fix the nav bar

Project 3

Done

March 12

248

Buy groceries

Project 3

To Do

March 18

249

Call the client

Project 5

In Progress

March 18

When you load your board, Django asks Postgres: “Give me all tasks in Project 3, sorted by status.” Postgres finds them and hands them back. Django passes them to React. React draws the board. The whole trip takes about 200 milliseconds — less time than a blink.

Why it matters: The database is the only part of the system that remembers things. If the server restarts, Django boots back up fresh — but all the data is safe in Postgres, exactly where it was left. Lose the database and you’ve lost everything. That’s why backups matter.

What you’ll hear people say: “It’s in the database” means the information is stored permanently. “We need to query the database” means we need to ask Postgres for specific data. “The database is slow” means Postgres is taking too long to find things — usually because the filing cabinet has gotten enormous and nobody’s built an index (think of an index like tabs on the drawers that let you jump straight to the right section).

Redis — The Prep Station

What it is: Redis is an in-memory cache. It keeps frequently accessed data in fast, temporary storage so the application doesn’t have to hit the database for every single request.

In our Trello clone: Some information gets requested constantly. “How many unread notifications does this user have?” “How many tasks are in Project 3?” Instead of making Postgres dig through the filing cabinet every single time someone loads the page, Django stores the answer in Redis.

Redis keeps everything in memory — think of it as a whiteboard mounted on the kitchen wall. Need the notification count? Glance at the whiteboard. Instant. When the count changes (someone assigns you a new task), Django updates the whiteboard. If the whiteboard gets erased — a server restart, for instance — that’s fine. Django recalculates the numbers from Postgres and writes them on the whiteboard again.

Why it matters: Speed. Postgres is reliable but relatively slow — it stores data on disk, which means physical reading and writing. Redis stores everything in RAM, which is orders of magnitude faster. For data that changes rarely but gets read constantly, this is the difference between a snappy app and one that feels sluggish.

What you’ll hear people say: “It’s cached in Redis” means the data is being served from the whiteboard instead of the filing cabinet. “The cache is stale” means the whiteboard hasn’t been updated and is showing old numbers. “Clear the cache” means erase the whiteboard and let it rebuild from the database.

How They Talk — The Life of a Click

These four pieces aren’t one big program. They’re four separate programs that communicate by sending messages to each other. Here’s what happens when you click “Add Task” and type “Buy groceries”:

React (your browser): You click the button, type the text, hit enter. React sends a message to Django: “New task: Buy groceries, in project #3, from user #42.”

Django (the backend): Receives the message. Checks — is user #42 logged in? Does user #42 belong to project #3? Is the title non-empty and under 500 characters? All good. Tells Postgres to store it.

Postgres (the database): Creates a new row: Task #248, “Buy groceries,” Project #3, created now, status “To Do.” Tells Django: “Done, here’s the new task with its ID.”

Django tells Redis: “Bump the task count for project #3 from 47 to 48.” Redis updates its whiteboard.

Django tells React: “Here’s the new task. It’s been saved. Task #248.” React adds the card to your board.

All of that happens in about 200 milliseconds. Less time than it takes to blink.

If something goes wrong — say Postgres is down — Django sends an error back to React, and React shows you a friendly message: “Something went wrong, please try again.” The kitchen caught fire, but the waiter doesn’t dump smoke into the dining room. They deliver the bad news politely.

The API — The Order Slip

The messages between React and Django follow a specific format. Think of it as a standardised order slip in the restaurant — the waiter writes orders in a format the kitchen can read, and the kitchen sends food back on plates the waiter can carry.

That format is called an API — Application Programming Interface. It’s a contract. React knows exactly how to ask, Django knows exactly how to answer. If React sends a request that doesn’t match the contract — like ordering a dish that’s not on the menu — Django sends back an error.

You’ll hear people say things like “the API is returning a 500.” That number is a status code — a shorthand for what happened:

200 — Everything’s fine. Here’s your food.

401 — You’re not logged in. Who are you?

403 — You’re logged in, but you don’t have permission.

404 — That thing doesn’t exist. (This is the one you’ve seen — “404 Not Found.”)

500 — Something exploded in the kitchen. It’s our fault, not yours.

When your developer friend says “the API is down,” they mean the communication channel between the frontend and backend has stopped working. The dining room is fine. The kitchen is fine. But the door between them is jammed.

Authentication — The Wristband

How does Django know it’s you making the request?

When you log in — type your email and password, or click “Sign in with Google” — Django verifies your identity and gives your browser a token. Think of it as a wristband at a festival. For the rest of your session, every message React sends to Django includes that wristband. Django glances at it and says, “Yep, that’s user #42, they’re allowed to be here.”

If the wristband expires (most tokens last a few hours or days), you get bounced back to the login screen. If someone steals your wristband — that’s a security breach. That’s why “log out on shared computers” isn’t just a suggestion.

When your developer says “the auth is broken,” they mean this wristband system has a problem. Maybe tokens aren’t being issued. Maybe they’re expiring too fast. Maybe they’re not being checked properly, which is much scarier — it means the bouncer isn’t doing their job.

WebSockets — The Walkie-Talkie

Most web communication works like sending letters. React sends a request, waits, and Django sends a response. It’s called request-response, and it’s how most of the internet works.

But what about real-time features? When your teammate adds a card to the board, you want to see it immediately — not the next time you refresh the page. That’s where WebSockets come in.

A WebSocket is like a walkie-talkie. Instead of sending letters back and forth, React and Django open a persistent connection — a line that stays open. The moment something changes on the server, Django broadcasts it to everyone who’s listening. Your board updates in real time. You see the cursor moving as your teammate drags a card.

That’s how chat apps work. That’s why you can see “Sarah is typing…” in real time. It’s a WebSocket — an open line between your browser and the server, constantly listening.

Git — The Undo Button for Everything

Every experiment gets its own safe copy.

Before we go further into infrastructure, you need to know about Git. Not because you’ll use it directly every day — but because it’s the single most important reason you can let agents work on your code without losing sleep.

Imagine you’re writing a long document in Google Docs. You know that little “Version history” feature? Where you can see every change anyone ever made, and restore any previous version? Git is that — but much, much more powerful. It’s how virtually every piece of software in the world is built.

The Core Concepts

Repository (repo): A project folder that remembers everything. Every file, every change, every version — all the way back to day one. Your Trello clone lives in a repo.

Commit: A snapshot. Like saving your game. “Here’s what everything looked like at 3pm on Tuesday.” Each commit has a short message describing what changed: “Added price calculator” or “Fixed the glass transparency.” You can go back to any snapshot, any time.

Branch: A parallel universe. You say, “I want to try adding a 3D preview, but I’m not sure it’ll work.” You create a branch — a copy of your project where you can experiment freely. If it works, you merge it back into the main project. If it doesn’t, you delete the branch. The original is untouched.

Think of it as drafting on tracing paper over your blueprint. Experiment all you want. The blueprint underneath doesn’t change until you decide to make it permanent.

Merge: Taking the tracing paper and pressing it onto the blueprint. The experiment worked, so you fold those changes into the main project.

Pull Request (PR): Before you merge, you can ask someone to review your tracing paper. “Hey, look at what I changed — does this seem right?” That review step is a pull request. It’s where teammates — or you, reviewing an agent’s work — look at the changes before they become official.

GitHub: The place where repos live online. Think of it as Google Drive for code. Your repo is stored there, backed up, and shareable. It’s also where pull requests and code reviews happen.

Why Git Matters for Working with Agents

Here’s why this is so important. When you tell an agent to “add a 3D preview using Three.js,” the agent might change fifteen files. Maybe it works beautifully. Maybe it breaks everything. Without Git, you’d be stuck — Ctrl+Z doesn’t work across fifteen files.

With Git, you tell the agent: work on a branch. Now all its changes are contained in that parallel universe. You test it. If the 3D preview looks great — merge. If the agent went haywire and rewrote your entire pricing logic for no reason — delete the branch. Five seconds. No damage done.

The flow looks like this:

main (your stable app)
  |
  |-- branch: "add-3d-preview"
  |     |-- Agent makes changes (commit: "Add Three.js scene")
  |     |-- Agent fixes a bug  (commit: "Fix camera angle")
  |     |-- You review it -- looks good!
  |     +-- Merge back into main
  |
  |-- main now has the 3D preview
  |
  |-- branch: "pdf-generation"
  |     |-- Agent tries something (commit: "Add PDF export")
  |     |-- It's a mess -- the PDFs are blank
  |     +-- Delete branch. Main is untouched.
  |
  +-- main is still safe. Try again.

Every experiment is safe. Every mistake is reversible. That branch diagram is your safety net, drawn out. Engineers live in this flow every single day. Now you understand why.

Git means you can always go back. That means you can be bold.

DNS — The Internet’s Phone Book

The internet’s phone book connects names to numbers.

You type trello.com into your browser. But computers don’t understand names — they understand numbers. Somewhere, there’s a giant lookup system that translates trello.com into 104.192.141.1 — the actual address of the server where Trello lives.

That system is DNS — the Domain Name System. It works exactly like the contacts on your phone. You tap “Mom,” your phone knows that means +45 12 34 56 78. You never think about the number. But without it, the call doesn’t connect.

When your developer friend says “the DNS isn’t propagated yet,” they mean: we changed the phone number, but not everyone’s phone book has updated yet. DNS changes can take minutes to hours to spread across the internet. That’s why after launching a new site, some people can see it and others can’t — their phone book is still showing the old address.

Every website you’ve ever visited started with a DNS lookup. You just never noticed, because it takes about 20 milliseconds.

VPS — The Apartment Where Your App Lives

Your Django backend, your Postgres database, your Redis cache — they need a computer to run on. Not your laptop. A computer that’s on 24 hours a day, 7 days a week, connected to the internet, sitting in a building with backup power and serious air conditioning.

A VPS — Virtual Private Server — is renting a slice of one of those computers. You don’t get the whole machine. You get a walled-off section of it, with your own operating system, your own storage, your own memory. Like renting an apartment instead of buying a house — the building is shared, but your apartment is yours.

Common names you’ll hear: DigitalOcean, Hetzner, Linode, AWS, Google Cloud. The first three are like renting a straightforward apartment — here’s your server, here’s the key, good luck. AWS and Google Cloud are more like entire cities — thousands of services, overwhelming if you just need somewhere to run your app, but powerful if you need to scale to millions of users.

When someone says “the server is down,” they mean this computer — the VPS — has stopped responding. When they say “we need to scale up,” they mean the apartment is too small and they need a bigger one, or several.

React is a bit different from the others: it gets downloaded to your browser and runs on your computer. Django, Postgres, and Redis all live on the server. React is the only part that travels to the customer.

Migrations — Reshaping the Database

What happens when you want to add a “due date” field to tasks? You can’t just scribble a new column onto the filing cabinet. Postgres needs a formal instruction: “Add a new column called due_date to the tasks drawer.”

That instruction is called a migration. Django generates it automatically when you change your data model, and it reshapes the database without losing any existing data. Every row in the Tasks drawer gets a new, empty “due date” slot, and from now on, new tasks can include a due date.

Migrations can also remove columns, rename them, or change their type. They’re applied in order, like a changelog — migration 001, 002, 003. You can see the entire history of how your database evolved from a single table to a hundred.

When your developer says “we need to write a migration for that,” they mean the database structure needs to change to support a new feature. It sounds scary, but it’s routine — most apps run dozens or hundreds of migrations over their lifetime.

CI — The Automated Checklist

A developer finishes a change. Maybe they fixed a bug. Maybe they added a new feature. Now what? They can’t just paste it onto the live server and hope for the best. (They can. Engineers have a saying: never deploy on Friday.)

CI — Continuous Integration — is an automated checklist that runs every time someone proposes a change. Think of it as a factory quality check before the product leaves the building:

Does the code even run without errors? Sometimes a change breaks something obvious — a typo, a missing file, an incompatible version.

Do all the tests pass? The app has hundreds of automated tests — little scripts that verify things like “log in as a user, create a task, mark it done, verify it shows in the Done column.” If any of those scenarios break, CI catches it.

Does it match the team’s style rules? Consistent formatting, naming conventions, no leftover debugging code.

Does it introduce security problems? Known vulnerabilities in dependencies, exposed credentials, unsafe patterns.

If anything fails, the change gets rejected with a red mark and a message explaining what broke. The developer fixes it and tries again.

If everything passes — green checkmark. Now a teammate reviews the change in a pull request, and if they approve it, CI can automatically deploy it — push the new version to the VPS. The next time someone loads the app, they get the updated version.

The whole thing takes minutes, runs without any human touching it, and catches problems that humans miss. It’s the reason apps update constantly without you noticing — behind the scenes, changes are flowing through this pipeline dozens of times a day.

Common tools you’ll hear about: GitHub Actions, GitLab CI, Jenkins. They all do roughly the same thing — run the checklist, report the result.

Keeping Your Finger on the Pulse

You don’t need to write code to stay current with what’s happening in the software world. The best non-technical people I’ve worked with have one thing in common: they know what’s out there. They read about a new tool on Hacker News three weeks before the engineering team brings it up. They spot a trending open-source project on GitHub that solves exactly the problem the team has been complaining about. They’re not experts in these tools — but they know they exist, and that’s half the battle.

Three places worth visiting a few times a week:

Hacker News (news.ycombinator.com) — A link aggregator run by Y Combinator, the startup incubator behind Airbnb, Dropbox, and Stripe. Engineers post and discuss articles about technology, tools, and industry shifts. The comment sections are gold — you’ll see real engineers arguing about whether a new tool is actually good or just hype. Skim the top five stories a few times a week and you’ll be ahead of most people in any meeting.

GitHub Trending (github.com/trending) — A daily and weekly list of open-source projects gaining traction. You won’t understand all the code — you don’t need to. Read the project descriptions. “A faster alternative to Elasticsearch.” “Self-hosted Notion clone.” “AI agent framework for Python.” You start seeing patterns: what problems people are solving, what’s gaining momentum, what your team might adopt next quarter.

Reddit (r/programming, r/webdev, r/selfhosted, r/artificial) — Community discussions, more casual than Hacker News, often more practical. People share what they’re building, what broke, what they learned. Great for the “how do real people actually feel about this?” perspective. When a new AI tool drops, Reddit will tell you within 24 hours whether it’s genuinely useful or just marketing.

The habit is simple. Ten minutes with your morning coffee, three times a week. Skim the front page. Read one article that catches your eye. Within a month, you’ll start recognising names — frameworks, libraries, companies. Within three months, you’ll overhear your developer friend talking about something and think, “Oh, I read about that last week.”

That moment — when you stop being the person who nods along in meetings and start being the person who asks the question that changes the direction of the conversation — that’s when this chapter has done its job.

Now You Know

That’s it. Four building blocks. A dining room (React), a kitchen (Django), a pantry (Postgres), and a prep station (Redis). Plus the infrastructure that holds it all together: Git for version control, DNS for finding the app, a VPS for running it, and CI for making sure nothing breaks when changes roll out.

Almost every web application you use daily — your bank, your streaming service, your project management tools — is some variation of this pattern. The specific names change. The shape doesn’t.

Now when your developer friend says “the API is returning a 500” or “we need to add a Redis cache for that” or “I’m writing a migration,” you’ll know which part of the restaurant is having a bad day. And when you sit down with an agent and say “build me a quoting tool” — you’ll understand what it’s actually building.

That understanding is your boarding pass for the rest of this book.

What Is an Agent, Really?

Observe, plan, act, check — repeat.

You’ve been using agents for years. You just didn’t know it.

When your email app moves a newsletter to your Promotions tab, that’s an agent — a tiny one, with a narrow job. When your phone suggests “You usually leave for work at 8:15, traffic is heavy, leave now” — that’s an agent. When Spotify builds you a playlist based on what you’ve been listening to — agent.

These are small agents. Single-task. Narrow. They observe something (your email, your location, your listening history), they decide something (this is a promotion, traffic is bad, you’d like this song), and they act (move the email, send a notification, queue the song).

The agents this book is about are the same idea, but much, much bigger. They don’t just categorise your email — they can read your entire codebase, plan a series of changes, write the code, run the tests, and iterate on failures. They’re not doing one clever thing. They’re doing many things, in sequence, adapting as they go.

The Loop

Every agent, from the simplest email filter to the most sophisticated code-writing tool, runs the same basic loop:

Observe. Take in information. Read the files. See the error message. Look at the current state of things.

Plan. Decide what to do. “The test is failing because this function returns the wrong value. I need to change line 47.”

Act. Do the thing. Write the code. Move the file. Send the message.

Check. Did it work? Run the test. Read the output. See if the error is gone.

Repeat. If it worked, move to the next task. If it didn’t, go back to step 1 with new information.

That’s it. Observe, plan, act, check, repeat. The loop is the same whether the agent is sorting your inbox or building a web application. What differs is the scope — how much the agent can see, how many tools it has, and how much autonomy you’ve given it.

A simple agent runs this loop once. A powerful agent runs it dozens of times, adjusting its approach each time, building on what it learned from previous attempts.

Tools Define Capability

An agent without tools is just a chatbot. It can think and respond, but it can’t do anything. The tools you give an agent define what it’s capable of.

An agent with access to your filesystem can read and write code. An agent with a web browser can research documentation. An agent with a terminal can run commands, execute tests, and start servers. An agent with access to your Git repository can create branches, make commits, and open pull requests.

Think of it like a new employee. A smart person with no access to any systems is just someone sitting at an empty desk. Give them a login to the project management tool and they can track work. Give them access to the code repository and they can make changes. Give them deployment credentials and they can ship to production.

The tools are the access. The agent is the person. You decide what access to grant based on what you trust them to do — which is exactly what the Trust Gradient chapter is about.

What an Agent Is Not

An agent is not a person. It doesn’t have goals, desires, or feelings. It’s not “trying” to help you in any meaningful sense. It’s running a very sophisticated pattern-matching process — predicting the most likely useful next action given everything it can see.

This distinction matters because it changes how you work with it. You don’t motivate an agent. You don’t need to be polite (though it doesn’t hurt). What you need to be is clear. An agent responds to clarity the way a person responds to motivation. The better you describe what you want, the better the output. Every time.

An agent is also not infallible. It will confidently produce wrong answers. It will hallucinate libraries that don’t exist. It will solve the wrong problem with beautiful precision. It will work tirelessly in the wrong direction unless you check its course.

That’s your job. Not writing the code — steering.

The Spectrum

Not all agents are equal. There’s a spectrum from simple to sophisticated:

Autocomplete — The simplest form. You start typing and the tool predicts what comes next. GitHub Copilot does this for code. Your phone keyboard does it for text. Low autonomy, low risk, constantly supervised.

Chat assistants — You ask a question, you get an answer. ChatGPT, Claude, Gemini. More capable, but still reactive — they do what you ask, one exchange at a time. No tools, no memory between sessions (usually), no ability to act on the world.

Tool-equipped agents — The same intelligence, but with hands. They can read files, run commands, search the web, interact with APIs. This is where things get powerful — and where the rest of this book lives. Claude Code, Cursor, Windsurf — these are agents with access to your project, your terminal, your tools.

Autonomous agents — Agents that run unsupervised for extended periods. You give them a goal, they figure out the steps, execute them, handle errors, and come back with results. The most powerful and the most dangerous. Most of the guardrails in this book exist because of this category.

Where you are on this spectrum depends on your comfort level, your use case, and how much you trust the output. Most people reading this book will work primarily with tool-equipped agents — powerful enough to build real things, supervised enough to catch mistakes.

Why This Matters for You

You don’t need to understand how the language model works internally. You don’t need to know about transformers, attention heads, or token prediction. That’s the engine. You need to know how to drive.

What you do need to understand:

Agents work in a loop: observe, plan, act, check.

Tools define what they can do. More tools means more capability, but also more risk.

They’re confidently wrong as often as they’re confidently right. Verification is not optional.

Clarity is your superpower. The better you communicate, the better the output.

If you’ve ever managed people, you already have the core skill. You’re about to learn how to apply it to a very fast, very literal, very tireless team member who never needs coffee but also never asks clarifying questions.

How to Give Good Instructions

The difference between a good instruction and a bad one.

This is the most important chapter in this book.

Everything else — understanding the tech stack, knowing what agents are, setting up guardrails — supports this one skill. Because an agent is only as good as the instructions you give it. Not sometimes. Always.

If you take nothing else from this book, take this: how you explain the job is more important than the tool doing the job.

Two Captains

Let me tell you about two people who both wanted the same thing: a simple dashboard showing their team’s weekly sales numbers.

Alex opened an agent and typed: “Make me a sales dashboard.”

The agent built something. It looked like a dashboard. It had charts. But the data was mocked — fake numbers, not connected to anything real. The charts showed monthly totals, not weekly. There was no way to filter by team member. And it used a JavaScript charting library Alex had never heard of, which didn’t match the React app they were supposedly building.

Alex spent an hour trying to explain what was wrong. Each fix introduced a new misunderstanding. After two hours, they gave up and started over.

Maya opened the same agent and typed something different:

“Build a sales dashboard page for our React app. It should:

Connect to our existing Django API endpoint at /api/sales/

Show a bar chart of sales totals for each of the last 8 weeks

Each bar should be broken down by team member (stacked bar chart)

Use the Recharts library, which we already have installed

Include a dropdown to filter by individual team member, or show all

The page should match our existing app’s styling — blue header, white cards, grey background

Put it at the route /dashboard”

The agent built exactly that. First try. Thirty minutes including a small fix to the date formatting.

Same agent. Same task. Same goal. The difference was entirely in the instructions.

The Three Parts of a Good Instruction

Every good instruction has three components: what you want, why it matters, and how you’ll know it worked.

What You Want

Be specific. Not “make a dashboard” but “make a bar chart showing weekly sales totals.” Not “fix the layout” but “the sidebar overlaps the main content on screens narrower than 768 pixels — make the sidebar collapse into a hamburger menu.”

The more concrete your description, the less the agent has to guess. And when agents guess, they guess confidently. They won’t ask “did you mean weekly or monthly?” They’ll just pick one and build it.

Why It Matters

Context changes everything. “Add a loading spinner” is fine. “Add a loading spinner — our users on slow rural connections are seeing a blank screen for 3-4 seconds and think the app is broken” is better. Now the agent understands the problem, not just the feature. It might suggest additional solutions you hadn’t considered, like skeleton screens or optimistic loading.

How You’ll Know It Worked

This is the one most people skip. “Build a login page” gives the agent no way to verify its own work. “Build a login page — I should be able to enter an email and password, click Log In, and be redirected to the dashboard. If I enter a wrong password, I should see an error message that says ‘Invalid credentials.” The login button should be disabled while the request is in progress.”

Now the agent has acceptance criteria. It can check its own work against your expectations. This is the same concept engineers use when writing tests — define what success looks like before you build it.

Constraints Are Half the Job

Telling an agent what to do is only half the work. Telling it what not to do is equally important.

Agents are eager. They optimise for solving the problem you described, and they’ll happily redesign your entire interface to do it. That’s not malice — it’s an optimiser doing what optimisers do. Your job is to set the boundaries.

Good constraints:

“Don’t change any existing pages — only add the new dashboard page.”

“Use the existing colour scheme. Don’t introduce new colours.”

“Don’t add new dependencies. Use libraries we already have.”

“Keep the file structure the same. Put the new component in src/pages/.”

“Don’t modify the API. The dashboard should work with the data the API already returns.”

Think of constraints as lane markers on a road. The agent can drive freely within the lanes, but it can’t cross the lines. Without lane markers, you get creative solutions that technically work but create chaos. With them, you get solutions that fit naturally into what already exists.

The more experienced you get, the more your instructions are defined by their constraints. You learn which freedoms lead to good outcomes and which lead to an agent rewriting your entire component library because you asked it to fix a button colour.

The Levels of Instruction

There’s a spectrum from vague to precise, and knowing where to land is a skill you develop over time:

Level 0 — The Wish: “Make the app better.” This gives the agent nothing to work with. It will either do nothing useful or change everything.

Level 1 — The Goal: “Add a way for users to export their data.” Better — there’s a clear objective. But the agent has to decide the format, the interface, the scope. You might get a CSV export. You might get a full API endpoint. You might get a “Download All” button that exports the entire database.

Level 2 — The Specification: “Add a button labelled ‘Export to CSV” on the settings page. When clicked, it should download a CSV file containing all tasks for the current project, with columns: Task Name, Status, Assignee, Due Date, Created Date. The file should be named project-name-export-2026-03-18.csv.” This is where you want to be for most tasks. Specific enough that the agent can’t misunderstand, flexible enough that it can handle implementation details.

Level 3 — The Blueprint: Full implementation spec with exact file paths, function names, and code patterns to follow. Usually unnecessary unless you’re working on a large, complex codebase with strict conventions. Your developer might write prompts at this level. You probably won’t need to.

For most people reading this book, Level 2 is the sweet spot. Specific about the what and the outcome, flexible about the how.

Iteration Is Normal

Nobody writes a perfect instruction on the first try. Not beginners. Not experts. The key difference is that experienced people iterate faster because they’ve learned what kinds of vagueness cause what kinds of problems.

A healthy workflow looks like this:

Give the agent a clear instruction.

Review what it produced.

Identify what’s wrong or missing.

Give a targeted follow-up instruction.

Repeat until it’s right.

The follow-up is where most people struggle. They see something wrong and say “that’s not right, fix it.” That’s Captain Alex again. Instead:

“The bar chart is showing monthly totals. Change it to weekly — group by ISO week number.”

“The export is missing the Assignee column. Add it between Status and Due Date.”

“The loading spinner is too small. Make it 48 pixels and centre it vertically in the card.”

Each follow-up is a miniature instruction with the same structure: what’s wrong, what you want instead, how to verify it.

Practice

This is a skill, which means it improves with practice. Start small. Ask an agent to draft an email and see how specific you need to be about tone and content. Ask it to reorganise a spreadsheet and notice how precisely you need to describe the desired layout. Ask it to plan a trip and watch where it makes assumptions.

Every time the agent produces something that’s not what you wanted, ask yourself: “What could I have said differently?” The answer is always the same — be more specific about what you wanted, more explicit about what you didn’t want, and more concrete about what success looks like.

The people who get the most out of agents aren’t the ones with the most technical knowledge. They’re the ones who’ve learned to communicate with precision. And that’s a skill that transfers to every conversation you’ll ever have — with agents, with colleagues, and with anyone who needs to understand what you actually want.

What the Agent Can See

An agent can only work with what’s on the bench.

The single most important thing about working with agents isn’t how you prompt them. It’s what you put in front of them before you ask the question.

An agent is only as good as what it can see. Give it a vague description and a blank slate, and it will hallucinate confidently. Give it the right files, the right constraints, the right view of the problem — and it will do things that feel like magic. The difference isn’t the model. It’s you.

The Workbench

Think of the agent’s view as a physical workbench. It has limited space. You can’t dump your entire life onto it and expect good results. Instead, you lay out the pieces that matter for this task: the relevant documents, the specific error message, the screenshot, the example of what you want.

Good workbench management:

Working on a quoting tool? Put the current version in front of the agent, plus an example of what a finished quote should look like.

Trying to fix a bug? Don’t describe the bug — paste the actual error message. Show the screenshot. Include the steps that triggered it.

Designing a new feature? Provide a sketch, a competitor’s example, or a detailed description of the user flow.

Bad workbench management:

Pasting your entire project and saying “something’s broken.”

Describing a problem from memory instead of sharing the actual error.

Giving the agent information about ten different tasks and asking it to figure out which one you mean.

The workbench principle applies to everything — not just code. If you’re asking an agent to draft a report, give it the raw data, the audience, the format you want, and an example of a good report. If you’re asking it to plan an event, give it the constraints (budget, date, venue size) rather than just “plan a team event.”

Raw Materials vs. Descriptions

There’s a crucial difference between describing something and showing it.

Description: “The sales numbers are in a spreadsheet. The totals seem wrong for Q2.”

Raw material: Paste the actual spreadsheet data. Or better — give the agent access to the file. Now it can see the formulas, find the error, and fix it. You described the symptom. The raw material shows the cause.

This is the single biggest upgrade most people can make: stop describing, start showing. Paste the error message. Attach the screenshot. Upload the document. Give the agent the same information you’d give a colleague sitting next to you.

Every time you paraphrase, you lose signal. You compress the actual problem through the narrow pipe of your interpretation, and the agent has to decompress it — badly — on the other side. It’s like describing a painting over the phone and asking someone to reproduce it.

Context Quality Levels

There’s a useful way to think about how good your context is:

Level 0 — Vague description: “The report looks wrong.” The agent guesses what report, guesses what’s wrong, and guesses how to fix it. Three guesses deep, the odds of getting it right are low.

Level 1 — Specific description: “The Q2 revenue in the quarterly report shows $2.3M but it should be $2.1M. I think the formula is including refunded transactions.” Much better. The agent knows the symptom and your theory about the cause.

Level 2 — Raw data: You paste the relevant section of the spreadsheet, the formula, and the list of transactions. Now the agent can verify your theory or discover the real cause. Maybe the formula is fine but two transactions were duplicated. You wouldn’t have caught that by describing the problem.

Level 3 — Access: The agent can open the spreadsheet itself, run the formulas, check the data source, and investigate independently. You provide the intent (“find out why Q2 revenue is overstated”) and the agent does the detective work.

Most people live at Level 0 or 1. The goal is to get to Level 2 as your default, and Level 3 when the tools support it.

Less Is More (Sometimes)

This isn’t about giving the agent everything. It’s about giving it the right things.

Too little context and the agent guesses. Too much context and the agent gets buried. Imagine handing someone a stack of a thousand pages and saying “the answer is in there somewhere.” Good luck.

For each task, ask yourself:

What does the agent need to see to understand this task?

What will confuse it if I include it?

Is the information I’m providing current, or am I feeding it stale data?

A focused workbench beats a cluttered one. Three relevant files are better than thirty irrelevant ones. The specific error message is better than the entire log file.

The Compound Effect

Every time you give an agent good context, the output is better. Better output means less time spent correcting. Less correcting means more time for the next task. Over a week, the difference between someone who dumps vague descriptions and someone who provides clean, focused context is enormous — not because they’re smarter, but because they’ve learned to set the agent up for success.

This skill compounds. And it’s the exact same skill that makes you better at delegating to humans, writing clearer emails, and filing better bug reports. The agent just gives you faster feedback on whether your communication was clear enough.

The Trust Gradient

Start tight. Loosen with evidence.

Would you let a new intern send emails to your clients on their first day? Probably not. Would you let them draft emails for you to review? Sure. Would you let them send routine replies after they’ve been around for a month and you’ve seen their work? Likely.

That escalation — from “I’ll do it myself” to “do it, but I’ll check” to “go ahead, I trust you” — is exactly how you should think about working with agents. It’s called the trust gradient, and getting it right is the difference between an agent that helps you and one that creates a mess you spend the afternoon cleaning up.

The Mixing Board

Think of your trust level as a mixing board — the kind with sliding controls. Each type of task has its own slider:

Reading files and data — Low risk. The agent is just looking. Slide it up.

Writing and editing documents — Medium risk. The agent might change something you care about. Keep it at “review before saving.”

Sending messages or emails — Higher risk. Once it’s sent, it’s sent. Keep it at “draft for my approval.”

Making purchases or financial decisions — High risk. Keep it at “suggest, don’t act.”

Deleting or overwriting data — High risk. Keep it at “ask me first.”

You don’t set all the sliders the same way, and you don’t set them once and forget them. They move over time as you build confidence in specific areas.

The Ratchet

Day one with an agent, everything gets reviewed. Every output gets checked. You don’t know yet where it’s brilliant and where it’s brittle, so you watch everything. This is normal. This is smart.

After a few days, patterns emerge. The agent is excellent at drafting reports. It’s solid at data analysis. It occasionally makes questionable choices about tone in customer-facing emails. Now your sliders reflect that: reports and analysis run with minimal review, customer emails get a careful read before sending.

After a few weeks, you’ve seen dozens of tasks complete successfully. You trust the agent more in the areas where it’s proven itself. The guardrails are still there, but they’re invisible for the 90% of work that’s routine. They only kick in for unusual situations.

This is the ratchet: slow, evidence-based tightening and loosening. The people who never loosen the guardrails end up abandoning agents because it’s “too much work to check everything.” The people who loosen too fast get the email that shouldn’t have been sent, or the data that shouldn’t have been deleted.

Guardrails in Practice

For software projects — the kind you might build with an agent — guardrails have a very concrete form, and you already learned about it: Git branches.

When an agent works on a branch, all its changes are isolated. You can review them in a pull request before they touch the main project. That’s a guardrail. The agent has freedom to experiment, but the results go through your approval before they become real.

For non-code tasks, guardrails look different:

Drafts, not sends. The agent writes the email. You send it.

Suggestions, not decisions. The agent recommends the budget allocation. You approve it.

Summaries with sources. The agent summarises the report and shows you where each claim came from. You verify.

Staged rollouts. Try the agent’s output on a small, low-stakes task before trusting it with the big one.

The principle is always the same: keep the human in the loop for anything that can’t be easily undone.

The Two Mistakes

There are exactly two ways to get the trust gradient wrong:

Too tight: You review every single output, re-check every fact, rewrite every sentence. The agent becomes a slow, expensive way to produce a rough draft you were going to rewrite anyway. You burn out on supervision and conclude that “agents aren’t worth it.” They are — you just never let the ratchet move.

Too loose: You let the agent run unsupervised because the first few results were good. The agent sends an email with a factual error. It publishes a report with a hallucinated statistic. It deletes a file that wasn’t backed up. You conclude that “agents can’t be trusted.” They can — you just skipped the part where you verify before promoting to autonomy.

The sweet spot is neither. It’s a gradual, evidence-based shift — checking everything early, loosening as confidence builds, but keeping hard boundaries on the things that truly matter.

Your Role

This might be the most empowering idea in the book: the trust gradient means you are always in control. Not the agent. Not the technology. You.

You decide what the agent can see. You decide what it can do. You decide when to review and when to trust. You can tighten the guardrails at any time. You can delete a branch. You can reject a draft. You can say “actually, I’ll handle this one myself.”

An agent is a tool with a trust dial. You hold the dial. That’s not a limitation — it’s the design.

Extending the Crew’s Reach

Connecting the agent to the world beyond its window.

An agent that can only read and write text is useful. An agent that can connect to your tools — your calendar, your spreadsheets, your project management app, your email — is transformative.

This chapter is about giving your agent hands. Not the technical plumbing (your developer can handle that) but the concept of what becomes possible when an agent can reach beyond the conversation window and interact with the systems you already use.

The Empty Desk vs. The Connected Workstation

Remember the new employee metaphor? A smart person with no access to any systems is just someone sitting at an empty desk. Give them access to your calendar and they can schedule meetings. Give them access to your CRM and they can update client records. Give them access to your document storage and they can research answers to your questions.

Agents work the same way. Each connection you add — each integration — expands what the agent can do:

Connected to your file system: The agent can read your documents, analyse spreadsheets, organise folders.

Connected to the web: The agent can research competitors, check documentation, look up current information.

Connected to your email: The agent can draft replies, summarise threads, flag urgent messages.

Connected to your project management tool: The agent can create tasks, update statuses, generate reports.

Connected to your database: The agent can query data, generate reports, and find patterns you’d miss in a spreadsheet.

Each of these is a tool in the agent’s hands. More tools means more capability — but also more responsibility, which is why the trust gradient exists.

No-Code Plumbing

You don’t need to be a developer to connect things together. A growing ecosystem of tools exists to wire up systems without writing code:

Zapier, Make (formerly Integromat), n8n — These are automation platforms. They let you create “if this, then that” workflows: “When a new row appears in my spreadsheet, create a task in my project management tool.” “When I receive an email from a specific client, summarise it and post the summary to Slack.”

These aren’t agents — they’re pipelines. But they can work with agents. An agent drafts a quote, and a Zapier workflow sends it to the client and logs it in the CRM. The agent does the thinking. The pipeline does the plumbing.

Apple Shortcuts, Power Automate — Lighter versions for personal workflows. “Every morning, have an agent summarise my unread emails and put the summary in my Notes app.” These are small, but they compound.

MCP (Model Context Protocol) — This is a newer standard that lets agents connect directly to external tools in a standardised way. It’s technical under the hood, but the result is simple: instead of you copying data into the agent, the agent can go get data from your tools. Your developer will set it up. You’ll enjoy the results.

The Multiplier Effect

Each tool integration doesn’t just add — it multiplies. An agent that can read your sales data and access your email and check your calendar can do things none of those connections could do alone:

“Check my sales data for Q2, find the three biggest accounts that haven’t been contacted in over 30 days, draft follow-up emails for each, and suggest meeting times based on my calendar availability next week.”

That’s one prompt. Four tools. A task that would have taken you ninety minutes, done in five.

This is the compound effect of tool integration. Each new connection opens up combinations that weren’t possible before. The people who get the most from agents are rarely the ones with the most powerful model — they’re the ones with the most connected workspace.

The Privacy Question

Every tool you connect to an agent is a door you’re opening. Before you connect something, ask:

What data will the agent be able to see? Connecting your email means the agent can read all your email, not just the thread you’re working on.

What can the agent do with it? Read-only access is very different from read-write access. Can the agent just view your calendar, or can it create and delete events?

Where does the data go? When the agent reads your spreadsheet, that data is sent to the AI provider’s servers. Is that acceptable for this data? Would it be acceptable for your client’s data?

What would happen if this went wrong? An agent with delete access to your file system can accidentally delete files. An agent with send access to your email can accidentally send an email. Think about the worst case.

This isn’t a reason to avoid tool integration. It’s a reason to be intentional about it. Connect what you need. Grant the minimum access required. And apply the trust gradient: start read-only, upgrade to read-write after you’ve built confidence.

Reading the Output Like a Pro

Trust, but verify.

An agent will never tell you it’s wrong. It doesn’t know it’s wrong. It produces output with the same confidence whether it’s perfectly accurate or completely fabricated. Your job — the skill that separates a productive agent user from a dangerous one — is learning to read the output with healthy scepticism.

This isn’t about distrust. It’s about calibrated trust. A good editor trusts their writers but still checks the facts. A good manager trusts their team but still reviews the deliverables. You’re the editor. You’re the manager. The agent is a very fast, very confident team member who occasionally makes things up.

Hallucinations

The technical term is “hallucination” — when an agent produces information that sounds plausible but is factually wrong. It’s the most important failure mode to understand because it’s the hardest to catch.

A hallucination isn’t a random error. It’s a plausible error. The agent doesn’t say “the revenue was purple.” It says “Q2 revenue was $2.3 million” when the actual number is $2.1 million. It doesn’t cite a source that obviously doesn’t exist — it cites one that sounds like it should exist. It doesn’t invent a bizarre claim — it states something that fits neatly into the narrative, just happens to be wrong.

This is why hallucinations are dangerous: they pass the sniff test. You read the output, it sounds reasonable, and you move on. The error propagates into your report, your presentation, your decision.

The Verification Checklist

For any agent output that matters, run through this:

Numbers: Where did they come from? Can you trace them back to the source data? If the agent says “sales grew 15%,” check the actual data. Don’t trust percentages, totals, or statistics without verification.

Names and dates: Agents frequently get details slightly wrong. The right person but the wrong date. The right company but the wrong product. The right statistic but from the wrong year. Spot-check specifics.

Claims and facts: If the agent states something as fact, ask yourself — is this something I already know to be true, or am I learning it from the agent? If you’re learning it from the agent, verify it. A quick web search, a check against your own records, a sanity check with a colleague.

Sources and citations: If the agent cites a source, check that the source exists and actually says what the agent claims it says. Agents are notorious for citing real-sounding publications with fabricated content, or citing real publications but misrepresenting what they say.

Completeness: Is the output missing anything obvious? Agents tend to produce plausible-looking work that covers 80% of what you asked for. The missing 20% is often the part that would have revealed a problem.

The Confidence Trap

Agents express everything with the same level of confidence. “The meeting is at 3pm” and “the meeting is at 3pm” look identical whether the agent is reading it from your calendar or guessing based on your usual schedule.

There’s no italic font for uncertainty. No “I think” or “I’m not sure.” The output arrives as if it’s fact, every time.

This means you can’t rely on the agent’s tone to gauge accuracy. You have to develop your own sense for which types of output are likely to be accurate and which need checking:

High confidence (usually reliable):

Formatting and restructuring existing data you provided

Following explicit instructions (“sort this list alphabetically”)

Performing calculations on data you gave it

Summarising a document you provided

Lower confidence (always verify):

Factual claims about the world (dates, statistics, current events)

Anything involving recent events (the model’s training has a cutoff date)

Specific numbers it didn’t calculate from data you provided

Legal, medical, or financial advice

Claims about what’s in a document it hasn’t actually read

Building the Habit

Verification shouldn’t feel like a burden. It should feel like proofreading — a natural, quick pass over the output before you use it.

For low-stakes tasks (drafting an internal message, organising notes), a quick skim is enough. Did it capture the key points? Does the tone feel right? Good enough.

For medium-stakes tasks (a client report, a data analysis), check the numbers and key claims. Trace at least one or two facts back to their source. Read the whole thing as if someone else wrote it and you’re the reviewer.

For high-stakes tasks (a board presentation, a financial projection, a legal document), verify everything. Treat the agent’s output as a first draft that needs fact-checking, not a finished product. If you wouldn’t publish it without checking when a human wrote it, don’t publish it without checking when an agent wrote it.

The goal isn’t to never trust the agent. The goal is to trust it appropriately — eagerly for what it does well, cautiously for what it does less well, and never blindly.

Building Something Real

From idea to working prototype in a weekend.

This is the chapter where everything comes together. We’re going to walk through building an actual application — from idea to working product — using an agent. No code. No programming experience. Just clear thinking, good instructions, and everything you’ve learned so far.

The app is real. The industry is real. The process is exactly what it looks like when someone who knows their domain sits down with an agent and builds something.

The Idea

Your uncle installs windows for a living. Not the Microsoft kind — the glass kind. Good business, steady work. He’s been doing it for fifteen years and knows every window model, every frame type, every trick for getting a perfect seal in a crooked old house.

But his quoting process is stuck in 2005. He measures the wall, picks a window from a paper catalogue, calculates the price on a calculator, types it all into a Word document, saves it as a PDF, and emails it to the customer. Half the time, the customer can’t picture what the window will actually look like in their wall. The other half, they lose the PDF and call back asking for another one.

You’re going to build him something better. An app where he enters the measurements, picks a window model, sees a 3D preview of what it’ll look like, and generates a professional quote — all in one place, accessible from his tablet at the job site.

You’re going to build it this weekend.

Before You Touch the Agent

The biggest mistake people make is opening the agent and immediately typing “build me a window quoting app.” That’s Captain Alex. We’re going to be Captain Maya.

Before you write a single prompt, you need to think like a product person. Ask yourself:

Who uses this? Window installers, on a laptop or tablet at the customer’s home. It needs to be simple, fast, and work on a tablet screen.

What’s the core action? Enter measurements, see the preview, send the quote. That’s the flow. Everything else is secondary.

What data do we need to store? Customers (name, address, phone). Window models (name, dimensions, price per square metre). Quotes (customer, window model, measurements, total price, date).

What’s the “wow” moment? The 3D preview. The customer stands in their living room and sees, on a tablet, exactly what the new window will look like in their wall. That’s what makes this better than a Word document.

You just designed an app. No code. No technical degree. Just clear thinking about who needs what.

Breaking It Into Jobs

Now we break the project into pieces. Each piece is a self-contained job you’ll give to the agent. The key principle: each job should make sense on its own, produce a testable result, and build on the previous one.

Job 1: Set Up the Project

This is the foundation. You’re telling the agent to build the empty building before you start furnishing rooms.

“Create a new project with a Django backend and a React frontend. Set up a Postgres database with three models: Customer (name, email, phone, address), WindowModel (name, width range, height range, glass type, price per square metre), and Quote (linked to a customer and window model, wall width, wall height, window width, window height, window position x, window position y, total price, date created). Create a Django admin panel so I can add window models manually. Make sure the React app can talk to the Django backend through an API.”

That’s one prompt. It sets up the entire stack from Chapter 3 — the dining room, the kitchen, and the pantry. The agent will create dozens of files, configure the database, set up the API, and wire everything together.

When it’s done, you should be able to open the Django admin panel in your browser, add a window model, and see it returned from the API. That’s your verification. If that works, the foundation is solid.

Job 2: The Quote Form

Now we build the interface where the installer enters information.

“Build a page in the React app with a form for creating a new quote. The form should have: a dropdown to select an existing customer or a button to add a new one, a dropdown to select a window model, number inputs for wall width, wall height, window width, window height, and window position (horizontal and vertical, measured from the bottom-left corner of the wall). All measurements should be in centimetres. When the user fills in the measurements and selects a model, show the calculated price below the form: window area in square metres multiplied by the model’s price per square metre, plus a fixed installation fee of 1,500 DKK. Add a Save Quote button that sends the data to Django.”

Notice the level of detail. You’ve specified the fields, the unit, the pricing formula, and the interaction. The agent doesn’t have to guess anything.

Job 3: The 3D Preview

This is the showpiece — and the part that sounds scariest for a non-programmer. It’s not. You’re not writing Three.js code. You’re describing a scene.

“Using the Three.js library, add a 3D preview panel next to the quote form. The preview should show:

A wall, rendered as a flat beige rectangle, using the wall width and height from the form

A rectangular cutout in the wall where the window goes, positioned based on the form’s window position and size values

A glass pane in the cutout — slightly transparent, with a light blue tint

A simple window frame around the glass, dark grey, 5 centimetres thick

The camera should start at a slight angle so you can see the wall has a little depth (make the wall 20cm thick)

The user should be able to rotate the view by dragging with their mouse (use OrbitControls)

Add soft ambient lighting and one directional light from the upper right so the glass has a subtle reflection

The scene should update live as the user changes measurements in the form

Put the form on the left side of the screen and the 3D preview on the right. On tablet screens, stack them vertically with the preview on top.”

You’ve just described a 3D scene. Like telling a set designer what you want on stage. The agent knows Three.js. Your job is knowing what a window installation should look like — and that, your uncle can tell you in his sleep.

Job 4: The PDF Quote

“When the user clicks Save Quote, generate a PDF with: a header with the company name ‘Hansen Vinduer” and logo (I’ll provide the logo file later), the customer’s name and address, a table with the window specifications (model, dimensions, glass type), the 3D preview rendered as a static image, the price breakdown (window area, price per square metre, installation fee, total), and a footer with the company’s contact information and CVR number. Use the WeasyPrint library for PDF generation on the Django side. After saving, show a ‘Download PDF” button and an ‘Email to Customer” button.”

Job 5: Quote History

“Add a page that lists all past quotes. Show them in a table with columns: date, customer name, window model, total price, and status (draft or sent). The user should be able to click any row to open the full quote. Add a search box that filters by customer name. Sort by date, newest first.”

Job 6: Polish

“Style the entire app to look clean and professional. Use a colour scheme of navy blue (hex 1a365d) for the header and buttons, white for card backgrounds, light grey (hex f7f7f7) for the page background. Make all buttons and form inputs large enough to tap easily on a tablet. Add the company name ‘Hansen Vinduer” in the header. Make sure everything works on an iPad in landscape orientation.”

The Three.js Moment

Let’s zoom in on Job 3, because it illustrates the most important lesson in this chapter: you can direct an agent to use technology you’ve never heard of.

Three.js is a library that draws 3D graphics in a web browser. You’ve never used it. You’ve probably never heard of it. And you don’t need to learn it. You need to learn how to describe what you want in 3D.

The agent knows the library. You know the domain. That combination is more powerful than either alone.

When the first version comes back, it won’t be perfect. Maybe the wall is inside-out — you’re looking at the interior face instead of the exterior. Maybe the glass is too opaque. Maybe the camera starts inside the wall, looking out.

This is normal. You iterate:

“The wall is showing the back side. Flip it so we see the exterior face.”

“The glass is too dark. Make it 80% transparent with just a hint of blue.”

“The camera starts too close. Move it back so I can see the whole wall.”

“When I change the window width, the frame doesn’t resize. Make the frame update in real time as I type.”

Each fix takes the agent about thirty seconds. You’re directing, not debugging. You’re the client sitting with the architect, saying “move that window a bit to the left.” The architect does the drawing.

What You’ll Hit Along the Way

Let’s be honest about the bumps, because they’re part of the process:

The agent will make assumptions. In Job 1, it might set up the database differently than you expected. Maybe it puts the price on the Quote instead of calculating it. Review the output. If something’s off, say so.

Things will break between jobs. Job 2 might not connect properly to what Job 1 created. The API endpoint might have a different name than the frontend expects. This is normal in software development — it’s called integration. Tell the agent: “The form is trying to send data to /api/quotes/ but the API endpoint is at /api/quote/create/. Fix the frontend to use the correct endpoint.”

The 3D preview will look weird at first. 3D graphics are fiddly. Lighting, camera angles, material properties — they all need tuning. This is the most iterative part of the project. Budget extra time here.

The PDF won’t look professional immediately. PDF generation is notoriously finicky. The spacing will be off. The logo will be the wrong size. The table won’t align. Iterate. Each fix is specific and quick.

The Weekend Timeline

Here’s a realistic schedule:

Saturday morning: Jobs 1 and 2. Set up the project and build the form. By lunch, you can enter quote data and save it.

Saturday afternoon: Job 3. The 3D preview. This takes the most iteration. By dinner, you have a rotating 3D wall with a window in it that updates as you change the form.

Sunday morning: Job 4. PDF generation. By mid-morning, you can generate a professional quote document.

Sunday afternoon: Jobs 5 and 6. Quote history and polish. By evening, the app looks and works like a real product.

Seven jobs. Two days. An app that makes your uncle look like a company ten times his size.

The Bigger Lesson

You never wrote a line of code. But you made every decision that mattered. You decided the data model. You decided the user flow. You decided what the 3D preview should look like. You decided the pricing formula. You decided the visual design.

The agent typed the code. You did the thinking. And the thinking — the understanding of the domain, the taste for what looks professional, the judgment about what the user needs — that’s the part no agent can do.

This is what it means to be a crew member who directs. Not a passenger. Not a captain. Someone who knows the waters, sees the currents, and tells the crew which way to sail.

When Things Go Wrong

The mistakes are inevitable. The recovery is a skill.

Every person who works with agents long enough has a collection of these stories. The moments where you lean back, stare at the screen, and say something your mother wouldn’t approve of. They’re humbling. They’re educational. And they’re inevitable.

This chapter is a collection of things that actually go wrong when you hand real work to an agent. Not hypotheticals. Not worst-case fantasies. The kind of mistakes that cost you an afternoon or your confidence. Each one comes with a lesson that maps back to something from earlier in this book.

Read these before you make the same mistakes. Or read them after, and feel less alone.

The Email That Wasn’t Ready

You asked the agent to draft a follow-up email to a client. The agent produced a perfectly reasonable draft. You skimmed it, thought “looks good,” and hit send.

Two hours later, the client called. The email referenced a meeting that hadn’t happened yet — the agent had confused the calendar event for next Tuesday with notes from last Tuesday. It also quoted a price that was from an old proposal, not the current one. The email was coherent, professional, and wrong in two places that mattered.

The lesson: Never send agent-generated communication without reading it like a human wrote it. The agent doesn’t know what’s current and what’s stale. It doesn’t know that the meeting hasn’t happened yet. It assembled plausible-sounding content from the context it had, and some of that context was outdated. This is the verification chapter in action — and the reason the trust gradient puts “sending emails” high on the review slider.

The Confident Statistic

You asked the agent to prepare a competitive analysis. It produced a beautiful report: market sizes, growth rates, competitor revenue figures, market share percentages. Impressive. Detailed. You used three of those numbers in a board presentation.

During the Q&A, a board member pulled up the actual industry report the agent appeared to be citing. Two of the three numbers were wrong. Not wildly wrong — close enough to be plausible, different enough to be embarrassing. The agent hadn’t found those numbers. It had generated them — plausible figures that fit the narrative, presented with the same confidence as the one number it got right.

The lesson: This is the hallucination problem from Chapter 9, playing out in the highest-stakes setting possible. Numbers from agents must be verified against source data. Always. If the agent cites a report, find the report and check the citation. If the agent produces a percentage, trace it back to the data. The agent doesn’t know the difference between a fact it found and a fact it invented.

The Overzealous Redesign

You asked the agent to change the colour of a button on your website from blue to green. A quick task. Five minutes.

The agent changed the button colour. It also noticed the button’s style was “inconsistent with modern design practices” and updated it. Then it updated the other buttons to match. Then the navigation bar. Then the footer. Then it restructured the CSS to use a “more maintainable approach.”

The button was green. Everything else was unrecognisable. Eighty-seven files had changed. The agent had done a full redesign you didn’t ask for, and rolling it back meant figuring out which of those eighty-seven files contained the one change you actually wanted.

The lesson: Constraints. “Change the button colour on the homepage from blue (hex 3b82f6) to green (hex 22c55e). Don’t change anything else.” That’s all it takes. Agents are eager optimisers — they see opportunities for improvement and take them unless you explicitly tell them not to. The chapter on instructions exists for this exact reason. Also: Git branches. If the agent had been working on a branch, you’d delete the branch and start over. Five seconds. No damage.

The Data That Wasn’t Backed Up

You built a small app with an agent. It was working great. Then you asked the agent to “clean up the database” — you meant remove some test data you’d entered while experimenting.

The agent interpreted “clean up” as “reset to a fresh state.” It dropped every table and recreated them empty. Six weeks of real customer data — quotes, measurements, contact information — gone.

The lesson: Two lessons, actually. First: be terrifyingly specific when the task involves data. “Delete all quotes where the customer name contains ‘test” or ‘asdf’” is very different from “clean up the database.” Second: backups. If you’re building something real — something with data that matters — regular database backups are not optional. Ask your agent to set them up. It’s one of the first things you should do after the app starts holding real data.

The Feature Nobody Wanted

You asked the agent to add a dark mode to the quoting app. The agent added it beautifully. Toggle switch in the header, smooth transition, all colours adapted. Looked great.

Your uncle hated it. “Why is there a switch in my header? I use this on job sites in daylight. Dark mode is useless. And the switch confused my new guy — he thought it was an on/off button for the whole app.”

You’d spent two hours on a feature driven by your own preference, not your user’s needs. The agent executed perfectly. The problem was the instruction, not the execution.

The lesson: An agent will build exactly what you ask for. It won’t tell you whether you should be asking. The question “should we build this?” is always yours. Talk to the actual user before you build. Your uncle would have told you in ten seconds that dark mode was pointless for his workflow — and he might have mentioned three things he actually needs.

The Recovery Pattern

Every war story above has the same recovery pattern:

Stop. Don’t let the agent keep going. If it’s in the wrong direction, more work makes it worse.

Assess. What actually happened? What changed? What was lost?

Restore. Git branch? Delete it. Database? Restore from backup. Email? Send a correction.

Learn. What instruction or guardrail would have prevented this? Add it to your process.

Try again. With better instructions, better constraints, and better verification.

The mistakes are inevitable. The recovery is a skill. And the prevention — clear instructions, proper constraints, verification, backups — is what this whole book is teaching you.

When to Do It Yourself

Sometimes the right tool is your own hands.

The most important skill in working with agents isn’t knowing how to use them. It’s knowing when not to.

An agent is a power tool. A circular saw cuts faster than a handsaw. But you don’t use a circular saw to trim a bonsai tree. Some jobs require a human touch — not because the tool is bad, but because the job demands something the tool can’t provide.

The Judgment Zone

There are tasks where the agent’s speed is the point and tasks where it’s actually the problem. The distinction usually comes down to one word: judgment.

An agent can draft an email. But should it draft the email telling a long-time client you’re raising prices? Probably not — at least not without heavy editing. The tone, the relationship, the careful balance between honesty and diplomacy — that’s human territory.

An agent can analyse data. But should it decide whether to lay off an employee based on that analysis? Obviously not. The data informs the decision. The decision is yours.

An agent can write a report. But should it write the performance review for someone on your team? The words might be fine. The weight of those words — coming from a tool rather than a person — changes everything.

The pattern: agents are excellent at producing things. They’re unreliable at deciding things that affect people. Use them for the former. Keep the latter for yourself.

When Context Is Everything

Some tasks require context that doesn’t fit in a prompt. The history of a relationship. The political dynamics of a team. The unspoken reason a decision was made three years ago. The fact that your client’s CEO hates bullet points.

An agent works with what you give it. If the most important information is the kind you can’t easily articulate — feelings, instincts, relationships — the agent will miss it. And it won’t know it’s missing it.

These are the tasks where your experience, your judgment, and your humanity are the whole point. No prompt can capture “I’ve worked with this client for seven years and I know exactly how they’ll react to this.” That knowledge is yours. Use it.

When Speed Is the Enemy

Sometimes the value of a task is the time it takes. Writing a heartfelt thank-you note. Thinking through a strategic decision. Sketching an idea on paper to see if it feels right. Reading a document slowly to understand the nuance.

An agent can do all of these things faster. But faster isn’t always better. Some thinking needs to happen at human speed — the kind of slow, deliberate processing where insights emerge from the act of doing, not from the output.

If you find yourself using an agent for everything and feeling oddly disconnected from your own work — that’s the signal. Step back. Do something by hand. The efficiency loss is worth the understanding you gain.

When the Stakes Are Too High

There are domains where the cost of an error is catastrophic and the ability to verify is limited:

Legal documents where a wrong clause creates liability

Medical information where a wrong fact creates danger

Financial calculations where a wrong number creates loss

Security configurations where a wrong setting creates exposure

An agent can assist in all of these areas. It can draft, calculate, suggest, and check. But the final review, the final sign-off, the final “yes, this is correct and I’m responsible for it” — that must be human. Specifically, a human with the relevant expertise.

Using an agent to draft a contract is fine. Sending that contract without a lawyer reviewing it is not. The agent doesn’t know what it doesn’t know. Neither does a non-expert reviewing its output.

The Decision Framework

When you’re deciding whether to use an agent for a task, ask yourself three questions:

Can I verify the output? If yes, the agent is probably safe to use. If you can’t tell whether the output is correct — because you lack the expertise, or the verification would take as long as doing it yourself — think twice.

What happens if it’s wrong? If a mistake is easy to catch and cheap to fix, let the agent run. If a mistake is hard to detect and expensive to recover from, keep a human in the loop — or do it yourself.

Is the human element the point? If the value of the task comes from you doing it — the relationship, the judgment, the creative expression — then doing it faster with an agent actually destroys value.

An agent is a tool. Like every tool ever invented, the master isn’t the one who uses it the most — it’s the one who knows precisely when to put it down.

Being the Human in the Loop

You are the quality control.

There’s a phrase you’ll hear more and more in the coming years: “human in the loop.” It means exactly what it sounds like — a system where an AI does the work, but a human reviews, approves, or redirects at key points.

You are that human.

This chapter is about what that role actually looks like — not in theory, but in daily practice. What it means to be the person who checks the agent’s work, catches its mistakes, and provides the judgment it can’t.

You Are Not Being Replaced

Let’s get this out of the way, because it’s the anxiety underneath everything.

Agents are getting better. They write code, draft reports, analyse data, generate designs. It’s natural to look at that and think: “What’s left for me?”

Everything that matters.

An agent can produce a financial report. You know whether the numbers tell the right story. An agent can draft a client email. You know whether the tone will land. An agent can design a user interface. You know whether it will make sense to the person using it at 7am on a construction site with gloved hands and no patience.

Domain knowledge, taste, judgment, relationships, empathy, context, politics, timing — these are not features you can add to a language model. They’re the things that make work work. They’re what you bring.

The agent multiplies your output. It doesn’t replace your input.

The Review Rhythm

In practice, being the human in the loop means building a rhythm:

For short tasks (minutes): The agent produces output, you review it immediately. Draft an email — read it, adjust, send. Generate a chart — check the data, tweak the labels, export. Quick loop.

For medium tasks (hours): The agent works in stages, and you check in between stages. Build the form — review. Add the 3D preview — review. Generate the PDF — review. Each checkpoint is a chance to steer before the agent goes further in the wrong direction.

For long tasks (days): The agent works on branches, and you review pull requests. This is the Git workflow from Chapter 3. The agent proposes changes, you review the changes, and you decide what gets merged. If something’s wrong, you reject it and provide better instructions.

The rhythm adapts to the stakes. Low-stakes work gets a quick glance. High-stakes work gets careful review. But the rhythm never stops — because the moment you stop checking is the moment the agent drifts.

What You’re Actually Checking

When you review agent output, you’re not checking whether the code compiles or the grammar is correct. The agent handles that. You’re checking for things the agent can’t check:

Does this solve the right problem? The agent solves the problem you described. You’re checking whether the problem you described is the problem that actually exists.

Does this fit the context? The agent doesn’t know your client’s history, your team’s culture, your company’s unwritten rules. You do. Does the output fit that context?

Is this appropriate? Appropriate in tone, in scope, in ambition. The agent doesn’t know that this quarter’s priority is stability, not new features. It doesn’t know that this client appreciates brevity. It doesn’t know that your boss is skeptical of AI-generated content.

Would I put my name on this? The ultimate test. If this output goes out with your name attached — your quote, your report, your email — are you comfortable with it? If not, it’s not done.

The Taste Gap

There’s a concept in creative work called the “taste gap” — the distance between what you can recognise as good and what you can produce. When you’re starting out in any field, your taste exceeds your ability. You know what good looks like, but you can’t make it yet.

Agents close this gap dramatically. Your taste — your sense of what’s right, what’s professional, what works — is the guide. The agent provides the execution speed. You provide the direction.

This is why someone like Morten, the window installer, could build a professional-looking quoting app in a weekend. He’s spent fifteen years developing taste for what a good quote looks like, what information a customer needs, how a professional interaction should feel. He couldn’t write the code. But he could recognise whether the output was right — and steer it until it was.

Your taste is your superpower. The agent is just the amplifier.

When to Override

Sometimes the agent does something that’s technically correct but wrong for reasons it can’t understand. These are the moments that define the human in the loop:

The report is accurate but the tone is wrong for this audience.

The feature works but the user flow is confusing.

The analysis is sound but the conclusion misses political context.

The email is polite but it needs to be warmer — this client just lost a family member.

In each case, the agent can’t know what you know. Override it. Change it. These are the moments where you earn your place in the loop — not because the agent is broken, but because some things require a human.

The Long Game

Being the human in the loop isn’t a temporary role until agents get better. It’s the permanent role. The specific tasks will change. The tools will improve. But the need for human judgment, human taste, and human accountability isn’t going anywhere.

The question isn’t whether you’ll be in the loop. It’s whether you’ll be good at it. And being good at it means developing exactly the skills this book teaches: clear communication, healthy scepticism, domain expertise, and the confidence to override a machine when your judgment says otherwise.

You’re not the person who types. You’re the person who decides. That’s the most important job on any crew.

Talking to Your Tech Team

You speak two languages now.

You’ve just spent thirteen chapters learning how software works, what agents are, and how to direct them. You now have something most non-technical people don’t: a shared vocabulary with your developers.

This chapter is about using it. Not to pretend you’re an engineer — but to close the gap between “I don’t understand what you’re building” and “I understand enough to help you build the right thing.”

The Vocabulary

Here’s a reference for the terms you’ve learned, framed as they come up in real conversations:

When your developer says “the API is returning a 500” — the kitchen (Django) is broken. Something exploded on the server side. The dining room (React) is fine. The problem is behind the scenes.

When they say “we need to write a migration” — the database (Postgres) structure needs to change to support a new feature. Like adding a new drawer to the filing cabinet.

When they say “it’s cached in Redis” — the data is being served from the fast whiteboard instead of the big filing cabinet. If the data seems stale, the whiteboard might need updating.

When they say “I’ll put it on a branch” — they’re working in a parallel universe (Git branch) so the main app isn’t affected. The experiment is safe.

When they say “the PR needs review” — there’s a pull request ready. Someone has proposed changes and wants a second pair of eyes before merging.

When they say “CI is failing” — the automated checklist caught a problem. The change broke a test or violated a rule. It needs fixing before it can ship.

When they say “DNS isn’t propagated” — the internet’s phone book hasn’t updated everywhere yet. Some people can see the change, others can’t. Wait.

When they say “we should add a WebSocket for that” — instead of the page checking for updates by refreshing, they want to add a live connection so updates appear instantly.

When they say “the context window” — the agent’s workbench. How much information it can hold at once.

When they say “it hallucinated” — the agent made something up. Confidently. It looks real but isn’t.

Questions Worth Asking

The most valuable thing you can do in a technical conversation isn’t understanding every detail. It’s asking the right questions. Here are some that will earn you respect:

“What does the user actually see when that happens?” — This grounds any technical discussion in reality. Developers sometimes get lost in implementation details. This question brings them back to the experience.

“What’s the risk if this goes wrong?” — This is the trust gradient applied to conversation. It separates the things worth worrying about from the things that sound scary but aren’t.

“Can we try it on a branch first?” — You know what a branch is now. Suggesting this shows you understand that experiments can be safe.

“Is this something an agent could handle?” — Not to replace your developer — but to suggest that maybe the tedious migration script or the repetitive styling task could be delegated. Developers sometimes forget to use their own tools.

“What would make this easier to test?” — This shows you understand that verification matters. It’s one of the most engineering-fluent questions a non-engineer can ask.

“What does the data model look like?” — You know what a database is now. You know about tables and rows. Asking about the data model shows you’re thinking about structure, not just features.

Being Useful in Planning

The biggest contribution you can make to a technical team isn’t writing code or reviewing pull requests. It’s defining the problem correctly.

Engineers are optimised for building solutions. They’re often less good at questioning whether it’s the right solution. That’s where you come in — especially if you’re closer to the users:

“We’re building a notification system” — you can ask: “Have we talked to users about whether they want notifications? What kind? How often? The last three apps I used have a ‘notification fatigue” problem.”

“We’re adding a dark mode” — you can ask: “Who asked for this? Our users are window installers on bright job sites. Maybe we should do a high-contrast light mode instead.”

“The agent will handle customer onboarding” — you can ask: “What happens when the agent gets it wrong? Is there a handoff to a human? How will the customer know they’re talking to an agent?”

These aren’t technical questions. They’re product questions. And they’re often more valuable than any technical decision being made in the same meeting.

The Bridge

You’re a bridge. You speak two languages now — not fluently in the technical one, but well enough to translate between the people building the product and the people using it.

That bridge didn’t exist before you read this book. The developers spoke in APIs and migrations and CI pipelines. The users spoke in frustrations and wishes and “it would be nice if.” The gap between those two conversations is where products fail.

You’re standing in that gap now. Not as an engineer. Not as a user. As someone who understands enough of both sides to make sure they’re building the same thing.

That’s not a small role. That’s the role that determines whether the ship reaches the right island.

Keeping Your Finger on the Pulse

Ten minutes, three times a week.

Technology moves fast. The tools in this book will evolve. New agents will appear. Better models will launch. The specific names — Claude, React, Django — might look different in three years.

But the patterns won’t change. Agents will still need clear instructions. Software will still have frontends and backends. Verification will still matter. What changes is the landscape around those patterns — and staying current with that landscape is a skill worth developing.

You don’t need to become a tech news junkie. You need ten minutes, three times a week.

The Three Watering Holes

There are three places where the tech world congregates to share what’s new, what’s working, and what’s broken. Each has a different flavour.

Hacker News

URL: news.ycombinator.com

Run by Y Combinator — the startup incubator behind Airbnb, Dropbox, Stripe, and hundreds of others. Engineers, founders, and researchers post links and discuss them. The front page is a curated list of what the tech world is paying attention to today.

Why it matters for you: The comment sections. You’ll see real engineers arguing about whether a new tool is actually good or just hype. Someone launches a new AI agent framework — the top comment explains what’s genuinely new and the second comment explains why it’ll fail. This kind of honest, expert discussion is almost impossible to find anywhere else.

How to use it: Skim the front page. Read the titles. Click on one or two that interest you. Read the top three comments. Five minutes. You’ll learn more about what the tech industry is thinking than from any newsletter.

GitHub Trending

URL: github.com/trending

A daily and weekly list of open-source projects that are gaining traction. These are actual tools and libraries that developers are starring and cloning — a real-time signal of what’s becoming popular.

Why it matters for you: You won’t understand the code. You don’t need to. Read the project descriptions and READMEs. “A self-hosted alternative to Notion.” “AI agent framework for building autonomous workflows.” “Fast Postgres client for Python.” You start recognising patterns: what problems keep getting solved, what categories keep trending, what your team might be evaluating next quarter.

How to use it: Check it once a week. Look at the top ten. Read the one-line descriptions. If something looks relevant to your work or your team, bookmark it and mention it next time you’re in a planning meeting. “I saw a project on GitHub Trending that does exactly what we’ve been talking about.”

Reddit

Subreddits: r/programming, r/webdev, r/selfhosted, r/artificial, r/LocalLLaMA

More casual than Hacker News, more opinionated, and often more practical. People share what they’re actually building, what actually broke, and what they actually think about the latest tools — without the professional veneer.

Why it matters for you: It’s the “street-level” view of technology. When a new AI model drops, Reddit tells you within hours whether it’s genuinely better or just marketing. When a tool has a critical flaw, Reddit surfaces it before the tech press does. And r/selfhosted is a goldmine for discovering tools you can run yourself.

How to use it: Subscribe to two or three relevant subreddits. Scroll through when you have a few minutes. The signal-to-noise ratio is lower than Hacker News, but the practical insights are often sharper.

The Compound Effect of Awareness

This isn’t about becoming a tech expert. It’s about pattern recognition.

After a month of casual reading, you’ll start recognising names. “Oh, that’s the framework my team was evaluating.” “That’s the company that makes the agent I use.” “I’ve seen three projects this week doing the same thing — that must be a trend.”

After three months, you’ll develop opinions. “Our team should look at this.” “That approach seems overhyped.” “This is solving a problem we actually have.”

After six months, you’ll be the non-technical person in the room who makes the technical people pause and listen. Not because you can code. Because you’ve been paying attention.

That awareness — the understanding of what’s happening, what’s coming, and what matters — is the difference between someone who uses technology and someone who navigates it. And navigating it is exactly what a good crew member does.

Building Your Filter

You’ll quickly notice that most tech news falls into a few categories:

Signal: New tools or approaches that solve real problems. Worth reading.

Hype: Marketing disguised as news. A company launched something and wants you to be excited. Skim the Reddit comments to see if the excitement is real.

Drama: Company politics, CEO controversies, culture wars. Entertaining but rarely useful.

Deep dives: Long, technical articles about specific problems. Skip unless the topic is directly relevant to you.

Learning to sort signal from noise is a skill. Start broad, then narrow. Within a few weeks, you’ll know which sources consistently deliver signal and which are mostly noise. Follow the signal. Ignore the rest.

Ten minutes, three times a week. That’s all it takes to stay ahead of the curve.

Final Words

Now go build something.

You started this book as someone who was good with computers. You’re finishing it as someone who understands how software is built, how AI agents work, and how to direct them to build real things.

That’s not a small shift.

A year ago, the idea of building a working application in a weekend — with a 3D preview, a database, a PDF generator, and a professional interface — would have sounded absurd without a development team. Now it’s a weekend project. Not because the technology is magic, but because you’ve learned the skill that unlocks it: the ability to think clearly about what you want and communicate it precisely.

What You’ve Learned

You know what’s under the hood. A frontend (React) that the user sees. A backend (Django) that enforces the rules. A database (Postgres) that remembers everything. A cache (Redis) that keeps things fast. An API that connects them. Git that keeps everything safe. DNS that makes it findable. CI that makes sure nothing breaks.

You know what agents are. Not magic. Not sentient. A loop: observe, plan, act, check, repeat. Powerful when directed well. Dangerous when left unsupervised.

You know how to direct them. Clear instructions with constraints. Raw materials instead of vague descriptions. Verification instead of blind trust. The trust gradient — tight at first, loosened with evidence.

And you know when to step in. When judgment matters more than speed. When the human element is the point. When the stakes are too high for confident guessing.

The Crew Metaphor

This book is called the Crew Member’s Guide for a reason. In the Agentic Crew, there are captains — the engineers who build the ship and know every plank. There are cadets — the kids who are just learning what a ship is. And there are crew members — people with skills, knowledge, and roles that don’t involve building the ship but absolutely involve sailing it.

You’re crew. And a ship without a good crew doesn’t go anywhere.

The captain might know how to build the engine, but you know the waters. You know the customers. You know the business. You know what success looks like from the deck, not just from the helm. That perspective isn’t secondary. It’s essential.

What Comes Next

The tools will change. The models will get better. New agents will emerge that make today’s tools look primitive. That’s fine. The principles in this book — clear communication, healthy scepticism, domain expertise, and the willingness to steer — aren’t tied to any specific tool. They’re tied to how humans work with powerful systems. And that doesn’t change.

What I hope you take from this book isn’t a set of techniques. It’s a confidence. The confidence that you can sit down with an AI agent and build something real. The confidence that your ideas, your domain knowledge, and your judgment are exactly what’s needed. The confidence that “I’m not technical” was never really true — you just hadn’t found the right tools.

You found them.

Now go build something.

To everyone who was told
“you’re not technical enough.”
You are. You always were.
Now the tools agree.