Using AI well

docs.scrimba.com

Every few years the industry finds a new thing to lose its head over. Right now it is AI. You have probably seen both versions of the panic: the people convinced it changes everything and you are finished if you are not all in by Friday, and the people convinced it is a con about to collapse any minute. Both are loud. Both are mostly wrong.

The truth is quieter and more useful. AI is a capable tool with real, specific failure modes. Not a savior, not a threat, a tool. The question worth your time is not whether to side with the hype or the doom. It is how to use this thing well: where it earns a place in your work, where it does not, and how to keep your own judgement while the rest of the field is busy losing theirs.

That is what this chapter is about. The rest of the handbook teaches you how the machine works; this one is about how to hold it.

Where it actually helps you

Set the noise aside and the practical case is strong. A model is very good at the work that used to eat your afternoon: drafting a first version, explaining an unfamiliar codebase, turning messy text into structured data, writing the boilerplate test, summarising a long thread, getting you unstuck on a syntax you half remember. None of it is glamorous. All of it is real time back.

What that buys a tech professional is leverage. The floor on routine work rises, so you spend less of your day on the parts that were never the interesting bit and more on the parts that are: the design, the judgement calls, the things only you can see because you understand the whole system. Used like this, AI is not replacing the work. It is clearing the underbrush so you can get to it.

The catch is that it pays off only if you can tell good output from bad. A model will hand you a confident wrong answer as readily as a right one, and it is the way these models work that makes that unavoidable. The professional who benefits is the one who can read what it produced, catch the mistake, and keep moving. The one who cannot is shipping someone else's guesses with their own name on them.

JunoWhere it actually helps you Here's the part I love telling new engineers: the work you used to dread, the first drafts, the boilerplate, figuring out unfamiliar code, a model handles a lot of it. That hands you back time for the good parts, the design and the decisions. The one habit to build early is checking its work, because it will say a wrong thing as confidently as a right one. Once you can spot that, you're flying.

JunoWhere it actually helps you The practical win: give the model the routine work, first drafts, boilerplate, messy text into data, and keep the design and judgement for yourself. That's real time back. The catch worth flagging is that it's only an advantage if you can read the output and catch the confident wrong answer. Can't do that yet? That's what the rest of this handbook is for.

JunoWhere it actually helps you Yes, it's good at the dull half of the job, the drafts and the boilerplate nobody misses. Take the time it buys you and spend it on the calls a model can't make. One warning, said once: it hands you a wrong answer with the same confidence as a right one. If you can't tell them apart, you're not saving time, you're shipping my mistakes with your name on them.

What it can't replace

Here is the part the hype skips. Everyone is building with AI now, and that has not removed the need for humans who actually understand things. If anything it raises it.

A model has no stake in your project, no memory of why the system is shaped the way it is, and no sense of what matters to the people who use it. It reaches for a plausible next word, not the right call. So the things that stay yours are the things that were always the hard part: deciding what to build, knowing which trade-off is worth making, noticing that the convincing answer is wrong for this context, holding the whole system in your head. Strategy, taste, and understanding do not come in the box.

This is why "understand the machine" runs through the whole handbook. The more you direct a tool you do not understand, the more you are guessing. The engineer who knows how the model behaves points it where it is strong and keeps it away from where it is weak. The one who treats it as an oracle gets whatever the oracle felt like saying. Stay in the loop, at the level where the real decisions are made.

JunoWhat it can't replace It can feel like the model knows more than you. It doesn't, not really. It has no idea why your project matters or what the people using it need, it's only very good at sounding sure. The judgement, the "is this actually the right call", that part is yours and always will be. You're the one steering; the model is a fast pair of hands.

JunoWhat it can't replace A model has no stake in your project and no memory of why it's built the way it is. It optimises for plausible, not correct. So the strategy and the trade-off calls stay with you, and the more you build with it, the more that matters. Point it where it's strong, keep it off the decisions, and don't hand it the wheel.

JunoWhat it can't replace Everyone's coding with these things now, and somehow that's convinced people they can stop thinking. They can't. The model has no stake in your work and no clue what matters; it guesses well, that's all. Strategy, taste, catching the convincing answer that's wrong for this case, that stays human, and it's the part worth being good at. Direct the tool. Don't take orders from it.

Using it ethically

Effective and ethical are not separate goals here. They are the same habit seen from two sides.

Start with the rule that covers most of it: you own what you ship. If a model wrote it, you still read it, understood it, and stand behind it, the same as code from any teammate. Passing off output you have not checked, as if it were finished and yours, is how a confident wrong answer ends up in production with your name on it. Verify before you ship, every time it matters.

The rest follows from treating people as people. Be careful what you feed it: customer data, secrets, and anything private do not belong in a prompt you do not control. Be upfront about where the work came from when it counts. And resist the greedy version of this, the urge to cut every corner, flood every channel, or trade careful work for sheer volume. The tool is a multiplier, and a multiplier makes carelessness bigger too. Keep your principles and you keep the part of the job that was worth doing.

JunoUsing it ethically One rule keeps you out of trouble: you own what you ship. If the model wrote it, you still read it, understood it, and put your name on it, the same as anything from a teammate. Check it before it matters, keep private data out of prompts you don't control, and be upfront about where the work came from. None of it is complicated; it comes down to caring about the people on the other end.

JunoUsing it ethically One rule, holds up everywhere: you own what you ship. Model-written or not, read it, understand it, stand behind it, and verify before it matters. Keep secrets and customer data out of prompts you don't control, be upfront about the work, and don't use the speed to cut every corner. The tool's a multiplier, and it'll multiply your sloppiness as happily as your output.

JunoUsing it ethically Here's the one that bites people: you own what you ship. The model writing it doesn't make it not your problem; it makes it your problem with extra steps. Read it, stand behind it, verify what matters. Keep private data out of prompts you don't control, say where the work came from, and skip the urge to cut every corner, because a multiplier makes carelessness bigger too. Learn that the cheap way, not the way I did.

Keep your head

The field moves in waves, and it has done this before. Its history is a run of booms and winters, each one as certain at the time as this one feels now, each followed by a correction when the promises outran the results. That pattern is the best reason to stay level-headed: the loudest claim is rarely the one that lasts.

So treat the hype as weather, not gospel. The model that tops the rankings this month will be replaced, the demo that looks like magic usually has a narrow happy path, and "this changes everything" has been said about most things that did not. What does not get replaced is your understanding of how these systems work, the same way the ideas from each era outlived the products built on them. Keep learning the durable layer, keep your judgement switched on, and use the tool for what it is good at. That is the whole move: all of the leverage, none of the noise.

JunoKeep your head Don't let the noise stress you out. The field gets loud about a new thing every couple of years, and most of it settles down again. You don't have to chase every headline to keep up, I promise. Learn how this actually works, the way we are here, and you'll tell real progress from excitement. That's the calm in the storm.

JunoKeep your head Treat the hype as weather, not gospel. I've watched plenty of "this changes everything" demos turn out to have one narrow happy path, and the model topping the charts this month won't be next month's. What I bet on is the layer that doesn't move: how these systems behave. Keep your judgement on and you're fine.

JunoKeep your head I've been through enough of these cycles to stop getting excited at the top of one. It booms, it overpromises, it corrects, every time, and the loudest voice is never the one still standing after. So I don't chase rankings; I learn the parts that outlast the products. The hype is weather. You don't have to be.

That is the stance this handbook is written in: AI is a capable tool, you are the professional holding it, and the edge goes to the people who understand what they are working with. With that in mind, the next chapter opens the machine itself. How LLMs work is where the rest begins.