The Maker’s Guide to AI Coding (Extract)

The Maker’s Guide to AI Coding

For makers, engineers and solopreneurs

If you can describe it, you can build it

Peter Dalmaris

The Maker’s Guide to AI Coding If you can describe it, you can build it For makers, engineers and solopreneurs

● Peter Dalmaris, PhD

● This is an Elektor Publication. Elektor is the media brand of Elektor International Media B.V.

PO Box 11, NL-6114-ZG Susteren, The Netherlands Phone: +31 46 4389444

● All rights reserved. No part of this book may be reproduced in any material form, including photocopying, or

storing in any medium by electronic means and whether or not transiently or incidentally to some other use of this publication, without the written permission of the copyright holder except in accordance with the provisions of the Copyright Designs and Patents Act 1988 or under the terms of a licence issued by the Copyright Licencing Agency Ltd., 90 Tottenham Court Road, London, England W1P 9HE. Applications for the copyright holder's permission to reproduce any part of the publication should be addressed to the publishers.

● Declaration

The author and publisher have used their best efforts in ensuring the correctness of the information contained in this book. They do not assume, or hereby disclaim, any liability to any party for any loss or damage caused by errors or omissions in this book, whether such errors or omissions result from negligence, accident or any other cause.

● British Library Cataloguing in Publication Data

A catalogue record for this book is available from the British Library

● I SBN 978-3-89576-776-0 Print

ISBN 978-3-89576-775-3 eBook

● © Copyright 2026 Elektor International Media www.elektor.com

Editor: Clemens Valens Prepress Production: D-Vision, Julian van den Berg Printers: Ipskamp, Enschede, The Netherlands

Elektor is the world's leading source of essential technical information and electronics products for pro engineers, electronics designers, and the companies seeking to engage them. Each day, our international team develops and delivers high-quality content - via a variety of media channels (including magazines, video, digital media, and social media) in several languages - relating to electronics design and DIY electronics. www.elektormagazine.com

●4

Contents

Contents Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Why I wrote this book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Power and risk scale together . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 What you will build . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 What you will need . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 What you will not need . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 How this book is organised . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 About the code in this book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Part I — how AI-assisted coding works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Chapter 1 • What it is, and what it isn't . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 1.1 A directed collaboration, not a vending machine . . . . . . . . . . . . . . . . . . . . . . . . . 22 1.2 What it does well . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 1.3 What It Doesn't Know . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 1.4 The capability gradient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 1.5 The skills you bring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 1.6 Will it replace programmers? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 1.7 What to expect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Chapter 2 • The five levels of delegation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.1 Level 1: AI as reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.2 Level 2: AI for snippets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.3 Level 3: AI for functions and modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.4 Level 4: AI for complete files and components . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.5 Level 5: AI as agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 2.6 Higher is not better . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 2.7 Where the builds sit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Chapter 3 • Knowing your own level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.1 The limit is evaluation, not ambition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.2 Your level is per-domain, not global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.3 The danger zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.4 Borrowing trust deliberately . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

●5

The Maker’s Guide to AI Coding

3.5 Signs you are over your level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.6 Growing your level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Chapter 4 • Framing the problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.1 Why vague prompts produce vague results . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.2 Weak versus strong: the RC filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.3 The four elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 4.4 Your hardware knowledge is the context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 4.5 Common framing mistakes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 4.6 The specification habit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 4.7 Sidebar: letting the AI write the specification . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Chapter 5 • Failure modes and how to catch them . . . . . . . . . . . . . . . . . . . . . . . . . 43 5.1 Hallucination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 5.2 Context drift . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 5.3 Overconfidence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 5.4 Code that runs but is wrong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 5.5 Dependency bloat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 5.6 The five at a glance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 5.7 The git habit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 5.8 The fix mindset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Chapter 6 • Build: a calculator in a browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 6.1 The constraint is the point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 6.2 What you are building . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 6.3 Writing the specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 6.4 Two ways to the same specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 6.5 Where the first pass fell short . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 6.6 Verifying the result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 6.7 Where this build sits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 The Toolscape interlude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 The editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 The coding assistants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Part II — the development workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

●6

Contents

The eight-step spine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 The worked example: a serial data plotter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Beyond the code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Chapter 7 • Brainstorming and idea validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 7.1 The reflexive prompt problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 7.2 The agent as domain consultant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 7.3 From a vague idea to a first milestone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 7.4 The feasibility checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 7.5 When to stop brainstorming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Chapter 8 • Planning and specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 8.1 What a specification does . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 8.2 The four elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 8.3 The configuration that pays off later . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 8.4 The under-specification trap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 8.5 Git before the agent starts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 8.6 The handoff test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 Chapter 9• The mock-first pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 9.1 Build one layer at a time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 9.2 Start with a mock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 9.3 The shared interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 9.4 Prompt the assistant to build the mock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 9.5 Verify in isolation first . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 9.6 What building bottom-up gives you . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Chapter 10 • Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 10.1 Test each layer before the next one . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 10.2 The browser as a testing instrument . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 10.3 What failure looks like . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 10.4 When formal tests are worth writing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Chapter 11 • Iteration and refactoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 11.1 First-pass output is revision zero . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 11.2 The bad follow-up prompt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

●7

The Maker’s Guide to AI Coding

11.3 The targeted follow-up prompt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 11.4 When to iterate, when to discard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 11.5 Commit discipline during iteration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Chapter 12 • Documenting for future-you . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 12.1 What documentation is for . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 12.2 The docstring that adds nothing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 12.3 AI-generated documentation and the accuracy problem . . . . . . . . . . . . . . . . . . 86 12.4 The README is the entry point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Chapter 13 • Deploying for makers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 13.1 Maker-level deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 13.2 The hardware switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 13.3 The git log as a build narrative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 13.4 When to go further . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Chapter 14 • AI for the business layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 14.1 The same spec structure, different domain . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 14.2 Three categories where AI is consistently useful . . . . . . . . . . . . . . . . . . . . . . . . 95 14.2.1 Customer communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 14.2.2 Policy documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 14.2.3 Marketing copy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 14.3 Iteration works the same way . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 14.4 The accuracy problem in business writing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 14.5 Putting it together . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Chapter 15 • Comprehension as a discipline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 15.1 Comprehension at every stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 15.2 The discipline, concretely . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 15.3 The asymmetry you are working against . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 15.4 The maker's edge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Chapter 16 • Build: the serial data plotter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 16.1 Brainstorming with a frontier model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 16.2 Planning: scaffold before you build . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 16.3 Implementation: the mock-first data source . . . . . . . . . . . . . . . . . . . . . . . . . . 108

●8

Contents

16.4 Testing the streaming pipeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 16.5 Iterating on the frontend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 16.6 Documenting and logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 16.7 Adding a replay feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 16.8 Switching to the real Arduino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 16.9 A one-command launch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 Part III — a language model inside the tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 The build: a datasheet Q&A tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Four things that are new . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 How this part is arranged . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 Chapter 17 • AI inside the tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 17.1 When a function is the right answer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 17.2 The two conditions that justify a runtime model . . . . . . . . . . . . . . . . . . . . . . . 129 17.3 The factors that argue against it . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 17.4 A three-question test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 17.5 The test applied to the datasheet tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 Chapter 18 • API basics: requests, streaming, and structured output . . . . . . . . . 132 18.1 The messages array . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 18.2 Parameters worth knowing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 18.3 Blocking versus streaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 18.4

Structured output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

18.5 Keeping credentials safe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 Chapter 19 • Retrieval-augmented generation . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 19.1 The problem in concrete terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 19.2 The pipeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 19.3 Embeddings, without the mathematics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 19.4 Failure modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Chapter 20 • Preparing documents for ingestion . . . . . . . . . . . . . . . . . . . . . . . . . 141 20.1 What a PDF contains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 20.2

Why datasheets are the hard case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

20.3 The spectrum of approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

●9

The Maker’s Guide to AI Coding

20.4 How it fits into the pipeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 Chapter 21 • Cost, latency, and graceful failure . . . . . . . . . . . . . . . . . . . . . . . . . . 145 21.1 How token costs add up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 21.2 Latency, and how to handle it . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 21.3 The failure modes you will meet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 21.4 Graceful failure in practice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 Chapter 22 • Build: the datasheet Q&A tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 22.1 Planning and the specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 22.2 Scaffolding and the first streaming call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 22.3 Building the RAG pipeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 22.4 Fixing extraction with markdown conversion . . . . . . . . . . . . . . . . . . . . . . . . . 163 22.5 Hardening the tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 22.6 The finished tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 Part IV — a multi-user application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 The build: a resource booking system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 Four things that are new . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 Where "maintain" lands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 How this part is arranged . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 Chapter 23 • Multi-user application design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 23.1 Two problems that look like one . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 23.2 Two roles, one asymmetry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 23.3 Where authentication and isolation meet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 23.4 Why this can't wait . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 Chapter 24 • Database design and the ORM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 24.1 Why a relational database, and why PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . 177 24.2 Tables, keys, and relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 24.3 Working with tables as objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 24.4 Deciding whether two bookings collide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 Chapter 25 • Building a multi-file project with an agent . . . . . . . . . . . . . . . . . . . 182 25.1 The structure is part of the specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 25.2 Build in layers, lowest first . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

● 10

Contents

25.3 Keeping the agent oriented across sessions . . . . . . . . . . . . . . . . . . . . . . . . . . 184 25.4 Commit as you go, and watch it work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 Chapter 26 • External APIs and background jobs . . . . . . . . . . . . . . . . . . . . . . . . . 186 26.1 Depending on a service you don't control . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 26.2 Work that runs on a timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 Chapter 27 • Finishing and shipping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 27.1 Testing before you deploy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 27.2 The one document that has to exist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 27.3 Deploying to a real server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 27.4 What maintaining this application looks like . . . . . . . . . . . . . . . . . . . . . . . . . . 195 27.5 Where this goes next . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 Chapter 28 • Designing for multiple organisations . . . . . . . . . . . . . . . . . . . . . . . . 197 28.1 Three ways to keep tenants apart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 28.2 How the booking system does it . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 28.3 The design moment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 Chapter 29 • Build: the resource booking system . . . . . . . . . . . . . . . . . . . . . . . . 202 29.1 From concept to codebase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 29.2 Schema and project skeleton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 29.3 Authentication first . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 29.4 Bookings and conflict detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 29.5 External dependencies and background work . . . . . . . . . . . . . . . . . . . . . . . . . 214 29.6 Finishing and shipping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 29.7 One codebase, many organisations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 29.8 The design system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 29.9 The finished application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 Appendix A • RAG evolution and alternatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 The question underneath all of them . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 Giving the model more: long context and cache-augmented generation . . . . . . . . . . 222 Letting the model search: agentic retrieval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 Keeping RAG's shape and sharpening it . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

● 11

The Maker’s Guide to AI Coding

Baking it into the model: fine-tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 Choosing, from the datasheet tool outward . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 Appendix B • The Centaur Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 Why I wrote this appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 Control, Skill and the Centaur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 Why makers are well-placed, and still at risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 A moment to check yourself . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 Rules you can adapt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 Build your own check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 About disclosure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 How I use AI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 Sources and further reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 AI shaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 Appendix C • Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

● 12

Introduction I do not consider myself a programmer. I never really have.

Over the years I have picked up a wide range of languages and technologies: Python, Ruby, JavaScript, C and C++, a little assembly at university, HTML and CSS, shell scripting, a handful of databases and web frameworks. I understand how modern applications are glued together, from REST APIs to webhooks to event-driven architectures, and I can read and write code across a lot of contexts. But I am a maker first. My interests are wide, and that breadth keeps me from going deep on any single thing for long. Electronics, PCB design, embedded systems, education, content. Programming is one tool in a large workshop, not the whole shop.

For most of my life as a Maker, engineer, and educator, that breadth came loaded with a dose of frustration that I suspect you can recognise: my ideas ran faster than my ability to build them. Often, I have a vision for an application I want to build. I know what it should do, how it should behave, what problem it would solve. But getting from that vision to a working software application was always the slow and frustrating part of the process. I would commit to weeks of wrestling with software development frameworks I half-knew, debugging logic I had half-forgotten, fighting the friction of each language's particular ecosystem. I learned to be patient. Furthermore, I learned to scope my ideas down to what I could realistically build alone, within a reasonable amount of time. The limitations attached to this approach were serious, and they were crippling to my ability to complete my most ambitious projects. Across my whole career I have shipped maybe three or four pieces of software I would call finished. The rest stalled at the prototype stage, or never left my head.

Why I wrote this book That changed, and it changed sharply rather than gradually, once I started using AI coding assistants seriously rather than experimentally. What changed was not that I became a better programmer overnight but that the gap between idea and working prototype literally collapsed.

I can now take a software-shaped idea and have a prototype running in hours. Not simply a wireframed sketch, but a working prototype I can interact with and improve. Given a bit of clear specification and a little more patience, I can now build things I am happy to put in front of other people. Things I complete.

Once I understood how to harness the power of AI coding assistants, I started applying this understanding outside of Maker projects. I have built tools that prepare briefings before a meeting, systems that pull usable knowledge out of years of old course material, and small applications that plan long drives for fuel efficiency. I am a licensed pilot, and even my flight preparation has changed: I have co-written tools that collect, decipher and present in a graphical way forecasts, NOTAMs, and flight plans. None of these are Maker projects in

● 13

The Maker’s Guide to AI Coding

the traditional sense. They span my professional work, my hobbies, and the running of my business. The common thread is that each one was a software-shaped problem, and the implementation bandwidth that used to stop me no longer does.

The best way I have to describe the feeling that stems from the ability to delegate most of the programming to AI coders is that my creation capability ceiling has lifted. What I can create is now limited by my imagination and my ability to describe what I want, not by my fluency in any particular programming language or framework. And the ceiling keeps rising, because what is hard for an AI tool to write this month is often routine for next month's.

I can think of only one other technology that has had this kind of broad, cross-domain effect on my life, and that is the Internet. That is not a casual comparison. As the Web evolved, I transformed the way I learned, worked, communicated, and ran a business. AI coding tools are doing the same thing, touching every part of my working and hobbyist life at once rather than improving one corner of it. That is an extraordinary thing to be able to say, and it is why I wrote this book.

Power and risk scale together There is a catch, and it is the reason this book is as much about human judgment as it is about tools.

As I handed more of my work to AI, I noticed that the power and the risk scaled together.

When you ask for a single function and check it, the worst case outcome is a function that does not quite do what you wanted; you'll, hopefully, catch it in review, fix it, and continue; no harm done. When you hand over a larger piece of a system, the AI tool can produce code that runs, passes its tests, but is still subtly wrong in a way that only surfaces under conditions you did not think to check. Or it does exactly what you asked, and what you asked turns out to be the wrong thing. Because you handed over so much at once, the bug, whether small or large, may not surface until much later.

While we are on the topic of things that can go wrong, it's worth going into this a little deeper. Early on, I asked an assistant to add a moving average to a temperature-logging script. It ran, the plot looked smoother, and I moved on; only weeks later did I notice that every session opened with its readings dragged toward zero, because the model had quietly filled the averaging buffer with zeros rather than waiting for real samples. Nothing crashed, and no test failed. That is the shape of the problem, and the wrongness comes in several categories. Some are logic errors: a calculation that looks right but uses the wrong formula, an array index that is off by one because the model inferred the convention from code it had seen rather than from what you told it, a boundary condition that works for the inputs you tested and fails silently for the ones you did not. These can be found with careful testing, if you write tests that are careful enough.

Some are subtler. Security vulnerabilities in AI-generated code are often introduced not by carelessness but by pattern. The model has seen thousands of examples where user input is concatenated directly into a database query, or passed to a shell command, or stored with weaker protection than current best practice requires. It generates what it has seen.

● 14

Introduction

It doesn't know your threat model, only the code you put in front of it. The result can be code that passes every functional test you wrote, ships into production, and contains a vulnerability that nobody planted deliberately, and nobody went looking for either.

Then there is the opacity problem. When you write code yourself, you carry a mental model of every decision in it, including the ones you made badly. When an AI writes a large block of it, anything you didn't actively read and understand becomes a blind spot. Your review is only as thorough as your mental model, and with generated code that model is always incomplete in places you cannot easily see.

The more you delegate to the AI coding agent, the more precisely you have to think before you delegate. The bottleneck moves from "can I write this code?" to "can I describe what this code should do clearly enough that a machine, or another person, could build it correctly?" That is a completely different skill, and most of us have never had to develop it, because we were the ones writing the code. In everyday work we rarely have to spell things out in fine detail, because close-knit teams share so much context. We leave a great deal unsaid and trust the other person to fill in what we mean.

There is a second risk, slower to appear and harder to notice. As the AI produces good results consistently, the natural response is to trust it more and check it less. That is not an irrational process; it is how trust works among humans. But scrutinising code is a skill, and skills weaken without exercise. The developer who stopped reading generated output carefully several months ago is less equipped to catch the subtle error today. This creates a compounding dynamic: as the AI becomes more capable, humans get less practice at precisely the skills they would need to catch the AI being wrong. I am acutely aware of this risk, and this book is written on the assumption that you are too. I assume you are willing to remain conscious of how much you are delegating, and of what core skills you might be losing by doing it. But I want to name and shout-out this risk plainly rather than assume it away, because the pull toward comfortable trust is real, and it does not feel like a loss until something goes wrong. As the old saying goes, "if you don't use it, you lose it."

This book is built around that shift. There is a spectrum of how much you hand over, from asking a quick question to turning an autonomous agent loose on your files. Chapter 2 lays out the five levels of delegation this book uses, centred on the size of the task you hand across. The rest of the book is about working well at each level: when to trust the output, when to verify it carefully, and when to keep your own hands on the work.

What you will build This is a book you build along with, not just read. Each part ends with a real tool, something you could use, not a tutorial exercise with the interesting parts removed.

A calculator in a browser (Part I). Your first build is an interactive analyser for a firstorder RC filter. You enter resistance and capacitance, and it plots the frequency response and marks the cut-off. It is a single self-contained HTML file, built with nothing more than a chat-based AI assistant in your browser: no editor, no terminal, no installation. The point is

● 15

The Maker’s Guide to AI Coding

not the tool itself but the experience of framing a request precisely enough that the output is useful. That is the skill everything else builds on.

A serial data plotter (Part II). Point it at an Arduino or any microcontroller sending values over a serial connection, and it plots several variables live. This is where you see and experience the full development workflow end to end: brainstorm, specify, build, test, refine, document, and ship, working in a properly configured editor with an AI coding assistant.

A datasheet question-and-answer tool (Part III). You give it a PDF datasheet, the kind you have downloaded a hundred times and skimmed looking for one pin description or one timing figure, and you ask it questions and get cited answers back. This is the first build where a language model runs inside the finished tool at run time, not just in your workflow.

It demonstrates retrieval-augmented generation (RAG), a pattern that is immediately practical for anyone who has lost twenty minutes inside a hundred-page datasheet.

A resource booking system (Part IV, the capstone). A complete multi-user application that lets a group share and book equipment or facilities. You build it across the whole of Part IV, moving through every stage from idea to deployed software, and you meet the concerns that separate a personal script from an application other people rely on: multiple users, a database, external services, background work, and multi-tenancy (where one application serves multiple independent groups of users).

Part V steps back from building to the durable skills, the parts of this craft that will still matter when today's tools have been replaced.

Figure 0.1. The structure of the book: five parts, four hands-on projects, each operating at a higher level of delegation than the last.

What you will need The list is short, and none of it is expensive.

• A computer. Windows, Mac, or Linux all work. Nothing powerful: if it runs a browser and a code editor, it is enough.

● 16

Introduction

• A code editor. Free, cross-platform, and used throughout the hands-on chapters.

If you strongly prefer a different editor, the ideas transfer, though the walkthroughs assume one specific editor.

• An AI coding assistant. This is the tool that sits between you and the model, reading your files and applying changes. Part II introduces the options and gets you set up. You do not need to install anything to start reading.

• Access to a large language model. The assistant connects to a model, either through a cloud service or running locally on your machine. You can complete every build in this book without expensive model access.

• An internet connection for cloud models. Local models do not even need that, though a reasonably capable machine helps.

No specialised hardware. No paid licences before you have decided this is for you.

In practice (current as of July 2026). The specific editor, assistants, and models I use, along with current pricing and a rough cost for a full run through the book, change every few months. As I write this, that means VS Code as the editor, an assistant such as Cline or Claude Code, and a model from the Anthropic Claude family, but treat those as examples rather than requirements. I keep an up-to-date list, with install links, at txplo. re/ai_resources. The principles in this book do not depend on any of those specifics, so the running text names categories of tool rather than particular products. The Toolscape interlude before Part II and the appendices at the back collect the current names in one place, each dated.

What you will not need It is worth being just as clear about what is not required.

• You do not need to be a programmer. Some background helps you judge what the AI produces, but it is not a gate. People with no formal programming experience are building real software with these tools right now.

• You do not need fluency in any particular language. The builds use Python and JavaScript because they are practical choices for the tools involved. You will develop the ability to read and guide code as you go; that is built into the workflow.

• You do not need prior experience with AI tools. This book starts at the beginning.

• You do not need expensive hardware or subscriptions. Every build can be completed with affordable model access.

What you do need is a tolerance for ambiguity. AI-assisted development is not a deterministic process. You will get outputs that are incomplete or wrong, you will iterate, and now and then you will throw something away and start again. The workflow this book teaches is built around that reality rather than pretending it does not exist.

How this book is organised The book is in four parts, followed by three appendices. Part I covers how AI-assisted coding works: the mental model, the five levels of delegation, how to frame a problem, and

● 17

The Maker’s Guide to AI Coding

how to catch the ways it goes wrong. Part II is the development workflow, stage by stage, with the serial data plotter as the worked example. Part III is about applications that use a language model at run time. Part IV is the capstone, a full application built from nothing.

The appendices hold the material that would have interrupted the flow: a technical detour on the alternatives to retrieval-augmented generation, an essay on the durable skills, and a glossary.

Some material in this field goes stale quickly: model names, tool versions, prices, install steps. I have quarantined all of it. The short Toolscape interlude before Part II, and Appendices A and B at the back, are the only places where you will find specific products and numbers, and each carries a date and a pointer to txplo.re/ai_resources for the current version. The main chapters are written so that a reader who ignores every dated box still understands every principle. If you are reading this a year after it was printed, the chapters still hold; check the resources page for the current tool set.

If you are new to all of this, read the parts in order. Each one assumes the one before it.

If you already work with AI coding tools and want the workflow, you can move quickly through Part I and slow down at Part II. There is also a companion to this book. If you are someone who likes to see a thing done, take it in, and then do it yourself, I have recorded a full video course that follows the same builds you will find in these pages. Where the book explains each build and walks you through the key steps, the videos capture every detail of the work: each prompt I write, each response the AI agent sends back, the dead ends, the corrections, and the small decisions that rarely fit onto a printed page. It is the closest thing to sitting beside me while I develop these applications. If you want finer granularity on the practical chapters, or you simply learn better by watching before you build, that is what the course is for. You will find it, with current links and details, at txplo.re/ai_course.

About the code in this book Throughout this book you will encounter Python code. It comes from my own builds of the projects in this book, including intermediate iterations and fragments chosen to make a specific point. Much of it is exactly what an AI coding assistant produced, lightly edited or explained in the surrounding text. If you are not fluent in Python, that not a problem. These examples are not exercises for you to type out and memorise. They are here to show you what the output of AI-assisted development looks like, so that you can recognise it, read it, and form a judgement about whether it does what you asked.

One of the core responsibilities you carry as the human in this workflow is reviewing what the agent produces before you run it or hand it to someone else. You don't need to be able to write the code yourself to do that review, but you do need to spend enough time with it to understand what it is doing. If a block of code is unclear to you, a practical technique is to open a separate chat session with any capable language model, paste the code in, and ask it to explain what each part does. This serves two purposes at once: it builds your own understanding, making you a better reviewer over time, and it gives you a second perspective on the agent's output, one that may catch something the first agent got wrong.

● 18

Introduction

Using one AI to check the work of another is not a sign of being sloppy or lazy; it is a technique I use myself, particularly when the code is complex or a function's correctness is critical.

Let's turn to Part I, which starts with what AI-assisted coding is, and, just as importantly, what it is not.

● 19

The Maker’s Guide to AI Coding

Part I — how AI-assisted coding works Large language models have reached a level of capability that allow you to simply open a chat window, describe a tool you want, and have working code back within minutes. It is the reason this book exists. It is also the reason Part I comes before any of the building.

The gap between getting some code back from the LLM, and getting code you can trust is entirely made of judgement, which is the one thing the assistant cannot supply on your behalf.

As a Maker, you are already familiar with this mode of operation. You don’t solder a part onto a board because the vendor’s marketing page says it will work. Instead, you do your due diligence. You open the datasheet, you check the supply voltage, you look at what happens at the edges of the operating range, and only then do you commit. Working with an AI coding assistant asks for the same reflex, applied to something with which you have a fluent conversation and is occasionally, confidently wrong. Part I builds that reflex before you have a project riding on it.

The build: an RC filter analyser Part I closes with the smallest build in this book, so that you can concentrate on the fundamental skill of creating a specification. You will use a chat assistant in a browser tab.

No editor, no terminal, no local installation, no project folder. You write a specification, you send it to the AI assistant, and you get back a single HTML file.

The tool you’ll create is an RC low-pass filter analyser. The user enters a resistance in kilohms and a capacitance in nanofarads, and the tool calculates the cut-off frequency and plots the magnitude response as a Bode plot with the cut-off marked on the curve. Change either value and the plot updates immediately.

The reason this particular tool opens the book is that you can easily check it for correctness.

With R at 1 kΩ and C at 159 nF, the cut-off should land close to 1000 Hz. When the file comes back, you can cross-check that the physics that the assistant implemented are correct. Every build that follows from here is larger, but none of them changes what you are actually doing, which is framing a problem precisely, and then checking the answer against something you already know to be true.

What this part covers This first part of the book contains five chapters that lead into that build. Each chapter closes a gap that trips people up when they first start to use these tools.

A working mental model. Most disappointment with AI coding assistants traces back to a wrong picture of what they are. Chapter 1 replaces the vending-machine picture, in which you put in a request and take out a product, with a directed collaboration, in which the quality of what you get out is set by the quality of the direction you put in. It also covers the capability gradient. You will learn what these tools do genuinely well, what they do badly, and what they cannot know about your project at all.

● 20

Part I — how AI-assisted coding works

A scale of delegation, and an assessment of your own position on it. There is no single answer to "how much should I hand over?". Chapter 2 sets out five levels, from using the assistant as a reference to letting an agent run commands on your machine, and makes the case that higher is not better. Chapter 3 is the uncomfortable half of that because it promotes the idea that the ceiling on how much you should delegate is not your ambition, but your ability to evaluate what comes back. That ceiling is different in every domain you work in, and Chapter 3 covers how to tell when you are above it.

Framing a problem as a specification. A vague request produces vague code. To address this problem, you need to write better structured request. Chapter 4 breaks a good request into four elements and shows the same RC filter problem framed weakly and then strongly, so you can see the difference clearly. Your hardware knowledge is the context that makes your specifications better than a general-purpose developer’s.

The five ways it goes wrong, and how to catch each one. Chapter 5 covers hallucination, context drift, overconfidence, code that runs but is quietly wrong, and dependency bloat.

It also teaches you to use git and often commit, so that any bad AI output can be undone quickly.

How this part is arranged In summary, this first part of the book contains five concept chapters, and then a build.

Every part of this book follows that shape, and the build is where the concepts stop being advice and start being something you have done.

After the build, and before Part II begins, you will find the Toolscape interlude. It is the one place in the book that names specific products: an editor, two coding assistants, the models behind them, and the settings worth changing before your first real session. It sits outside the parts, because product names age faster than principles do, and quarantining them in one dated section means the chapters around it stay correct as the tools change. Read it when you are ready to move from a chat window to

● 21

The Maker’s Guide to AI Coding

Chapter 1 • What it is, and what it isn't There is a lot of noise around AI coding assistants. Some of it is hype, some of it is genuine capability. The gap between the two is where most beginners lose precious time trying to understand what's hype, what's real, and how to make the most of this technology. People tend to arrive expecting either too little, and then under-use the tool, or too much, and then get burned the first time it fails in a way they did not see coming.

Before you install anything or run a single prompt, it is worth taking a few minutes to make sure the mental model in your head matches how these tools work.

Most people start with the wrong picture. It looks something like this: you describe what you want, the AI writes the code, you run it, and the job is done. This is like a vending machine for software. You insert a description, and the machine gives you a program. The problem is that this picture breaks down fast. The first time the tool misreads your intent, or produces something almost right but not quite, or confidently calls a software library that doesn't exist, you conclude the tool is broken. While it is true that all technology has failure points, in this case, the most likely culprit is that your mental model was wrong.

1.1 A directed collaboration, not a vending machine AI-assisted coding is a directed collaboration between human and machine, not a transaction. AI-assisted coding is not about issuing a single prompt and getting a final answer, but a collaborative loop.

The keyword to remember when you work with AI is context. Context is everything the model can see when it generates a response: your prompt, any code or error messages you have pasted in, the conversation so far, and any background files you have loaded. You give the AI context about what you need, and it generates something: code, an explanation, a plan. You then evaluate that output. Does it do what you intended? Does it fit your constraints? Depending on what you receive and what you want, you give it corrected or expanded context, and it generates a response. That cycle continues until you have something that works.

Four steps all up, repeated: provide context, receive output, evaluate, redirect.

● 22

Chapter 1 • What it is, and what it isn't

Figure 1.1. The collaboration loop: provide context, receive output, evaluate, redirect, and repeat. The AI generates; you judge and steer.

The important point is who is driving this collaboration. The AI is not and should not be the driver; you are. The AI generates, you judge. If you step back and let it run without your input, you will get output that may or may not match what you need, with no reliable way to tell which without checking.

Let's look at a programming example. Suppose you want a Python script that reads temperature from an I2C sensor and logs the readings to a CSV file. You start with something like: "Write a Python script that reads from an I2C temperature sensor and saves readings to a CSV." The AI gives you code back. Maybe it imports a library you don't have. Maybe it assumes an I2C address that doesn't match your sensor. Or, maybe the CSV layout doesn't fit the analysis script you will run downstream.

No matter what the problem or issue you find in the AI response, you don't throw the result away and start over. You note what is wrong, add that information to the context, and continue the conversation. For example, you can write to the AI something like this: "The sensor address is 0x48. The CSV needs two columns, timestamp and temperature in Celsius. Use smbus2 directly, not the Adafruit bus device library." The next output will be much closer.

That is the loop in action, and for it to work you are responsible for setting the direction and the guardrails. In the context of the sensor example, you know the sensor address. You know what the downstream script expects. You recognise that the library the AI reached for will not run on your hardware. The AI generates; you supply the knowledge that makes the generation useful.

1.2 What it does well Modern AI tools are very capable. Here is what that means across a set of tasks where they consistently deliver results.

● 23

The Maker’s Guide to AI Coding

Boilerplate and scaffolding. Ask the AI to write a Python script that opens a serial port, reads lines at 9600 baud, parses comma-separated values, and writes them to a timestamped CSV, and you will have working code in seconds. These are well-bounded problems with well-established patterns. The result may not be production-hardened, but it runs, and you can test and adjust it. The kind of task that used to cost you thirty minutes of searching documentation and copying from forums now takes ninety seconds.

Explaining unfamiliar code. Paste in a library function you have never seen to your AI chatbot, ask it what it does, and you get a plain-language explanation. This is useful when you inherit someone else's code, work with a library outside your usual domain, or want to understand a piece of generated code before you run it.

Translating between languages and frameworks. Imagine you wrote a sensor driver in C for an AVR microcontroller and now need the equivalent in MicroPython for an RP2040.

The logic is the same; the syntax and library calls differ. Translating that kind of code idiomatically, rather than line by line, is something these tools do well.

Writing tests for existing functions. Give the AI a function and ask for unit tests, and it will produce plausible cases, including edge cases you might have missed. They are not a substitute for thinking about what you are testing, but they are a solid start and a real time saver.

Finding bugs, given an error and context. Paste the error message and the relevant code and ask what is wrong. For common categories such as type mismatches, off-by-one errors, and incorrect API calls, the diagnosis is often right on the first try. This is the kind of task that used to require a lot of Googling or poring through documentation; many common bugs resolve correctly on the first reply.

The thread running through all of these is that they are tasks where the pattern is common and the context you need to supply is small. Where the tool struggles is anything that depends on context it doesn't have. That is where your job begins.

1.3 What It Doesn't Know Perhaps what's most important when you collaborate with AI, is what AI doesn't know about your project. Most people new to AI assistants don't realise the importance of what the AI doesn't know. The AI doesn't know your project, and it never will unless you tell it.

It doesn't know that your sensor reads in millivolts while your firmware expects raw ADC counts. It doesn't know that the library's documented I2C address changed between versions. Likewise, it doesn't know that this particular board runs at 3.3 V logic, what you decided last week, or which constraints you are working within. What it does know is only what you put in the conversation, and the quality of what you get back is almost entirely a function of what you put in.

● 24

Chapter 1 • What it is, and what it isn't

Three important failure shapes come from this: AI hallucinates, and it does so with confidence. An assistant will invent library functions that don't exist, cite documentation that doesn't do what it claims, and give you a register or I2C address that is simply wrong, all in exactly the same tone it uses when it is right.

This is the most important characteristic to internalise. Often the AI output looks correct and it compiles. It may even run before it fails. The compiler doesn't know the address was made up. Ask for a MicroPython script to read a temperature sensor over I2C and you will get a fully formed function with an address, a register, and a conversion formula. If the datasheet says those values are different, then the code will fail, and you can lose an hour suspecting the hardware before you check the code. The remedy is to verify sensor-specific values against the actual datasheet, and never assume a confident answer is a correct one.

The AI has no knowledge of your electronics workbench. The model doesn't know which version of a library you have installed, which microcontroller is on which pin of your specific board variant, or that one of your test sensors is faulty. It infers everything from what you write, or, where the model and tool both support image input, from photographs of your workbench and instruments. Not all tools and models accept images, so check your tool's documentation before relying on it. Leave that context out of your prompt and the output is built on assumptions that may not match your situation.

The AI gives confidently wrong architecture for complex systems. For small, isolated tasks it is reliable. For multi-file systems with non-obvious dependencies, it can produce a structure that looks reasonable and is subtly broken. It may produce circular imports, the wrong abstraction layers, coupling between modules that makes sense for two weeks and causes trouble for the rest of the project. The larger and more interconnected the codebase, the more judgement you have to apply.

I have used the word context throughout this chapter because it is the most important variable you control. The model has no access to anything outside its context window. If it's not in the context, it doesn't exist as far as the model is concerned.

1.4 The capability gradient Let's put those two halves together and a gradient appears. Capability starts strong on well-bounded, pattern-rich tasks: boilerplate, explanation, tests, refactoring. It becomes unreliable at the far end, where the task needs knowledge the model cannot have, such as your specific hardware, a novel architecture, physical constraints, or consistency across a large codebase. In between sits a conditional zone, with tasks such as debugging with context, adapting existing code, and multi-file changes. Good context shifts those toward the reliable end; poor context shifts them toward the unreliable end.

● 25

The Maker’s Guide to AI Coding

Figure 1.2. The capability gradient: reliable on bounded, pattern-rich tasks; conditional in the middle where context decides; unreliable where the work requires knowledge the model cannot have. Verification is always yours.

One thing never moves along that gradient: verifying the output is always your job, wherever the task sits.

1.5 The skills you bring The main skill you need to use these AI tools well is not writing code, but reading it.

You need to be able to look at generated code and ask (yourself) whether it makes sense for your situation, whether a function is doing what you think it is doing, and whether you could tell if the answer were wrong. You don't need to have written it, but you do need to be able to evaluate it.

The second skill is describing what you want clearly enough that the AI can act without guessing. This is the real bottleneck for most beginners. "I want a tool that reads sensor data" is too vague. Compare that with "I want a Python script that reads from a serial port at 9600 baud, expects lines in the format timestamp,temperature,humidity, logs a warning and continues when a line doesn't match, and writes valid readings to a CSV file with an ISO 8601 timestamp column". The latter is a specification an AI can act on. Chapter 4 is devoted to writing them.

The third thing you bring is domain knowledge, and for a Maker this is a genuine advantage rather than a gap to close. You already know things the AI can only approximate. You know what a low-pass RC filter does, that its cut-off frequency is 1/(2πRC), and what the response curve should look like for a given pair of component values.

That knowledge is exactly what good prompts are built from. For example, this prompt: "Plot the magnitude response of a first-order RC low-pass filter from 1 Hz to 100 kHz on a logarithmic axis, with the cut-off frequency marked", gives the AI enough to work with. But this one: "Make an RC filter calculator", leaves almost everything to guesswork. You can hand the tool more precise context than someone who doesn't understand the physics, and that is a framing advantage, not a limitation.

● 26

Chapter 1 • What it is, and what it isn't

1.6 Will it replace programmers?

The question gets asked, so I'll try to give you my take.

For makers and solopreneurs, the question stops being "I can't code" and becomes "what can I build?" The ceiling lifts. Work that would have meant months of learning a new domain, such as parsing a binary file format, writing a GUI, or standing up a REST API, with AI coding assistants becomes accessible, because the assistant handles the unfamiliar syntax and boilerplate while you supply the domain logic and verify the result.

For professional programmers, what changes is which skills matter most. Syntax recall and typing speed matter less. Specification quality, review judgement, and knowing when the output is wrong matter more. The role shifts toward direction and verification and away from mechanical production.

I like comparing AI code assistants with a CNC router. A CNC router doesn't replace a skilled fabricator; it lets that fabricator produce work with a precision and repeatability hand tools cannot match. You still need someone who knows what the part is supposed to do, which tolerances matter, and how to check the finished piece. An AI coding assistant is the same kind of tool. It raises what you can accomplish. It doesn't remove the need for the person who understands the problem.

1.7 What to expect You can now build real tools that work. Not toy demos, but software you will use, the kind of thing that sits on your bench or in your workflow.

Of course, you will still hit obstacles; they are just different ones. The old walls were syntax, unfamiliar libraries, and language barriers. The new walls are specification quality, keeping context under control in long sessions, and catching the errors the AI is confident about but wrong on. These are more tractable problems, but they are still problems.

The quality of what you get out of a collaboration with an AI coding agent is directly proportional to what you put in. A vague prompt produces vague code; a real specification produces a working draft. There is no shortcut around the thinking. You still have to think, and, in a way, the quality of your thinking is more important now that it has ever been. The tool makes the execution faster once you have done the thinking.

Here's another analogy: You are the director, and the AI is the crew. A good director doesn't walk onto set and say "make a film." They arrive with a plan, communicate it clearly, watch what comes back, and make the judgement calls. That is the job the rest of this book prepares you for, and the first step is learning to choose how much of a given task to hand across. That is the subject of Chapter 2.

● 27

The Maker’s Guide to AI Coding

Chapter 2 • The five levels of delegation The loop you learned about in the last chapter runs at many different scales. You might run it to look up a single fact with your favourite AI chatbot. You might run it to specify and receive a complete working file. Likewise, you might hand a brief to an agent (an AI that can read files and run commands on your behalf) and let it work for twenty minutes before you check in. These are very different uses of the same basic mechanism, and they call for different habits, different tools, and different amounts of oversight from you.

This chapter gives you a map of that range. It answers one specific question: how big a task are you handing across? There is a second, related question, which is how far you step back and how much you supervise. The two are not the same, and the next chapter focuses on the supervision question. For now, the focus is the size of the handover.

Before getting into the levels, consider two common mistakes. A maker who needs a oneline function to convert millivolts to volts fires up a full agent session and waits while the AI reads a dozen files to produce five lines of arithmetic. Another maker who needs an entire serial-port management module writes it by hand, line by line, because they never thought to delegate it. Both are losing time: one by over-delegating, one by under-delegating. The five levels give you the vocabulary to avoid both traps.

Think of the five levels as a vocabulary rather than a ladder. You don't advance through them like stages in a game, unlocking the next one and leaving the last behind. A skilled Maker moves up and down the scale all day, matching the level to the task in front of them.

Let me walk through each one with an example from the bench.

Figure 2.1. The five levels of delegation, from AI as reference through to AI as agent.

What moves along the axis is the size of the task you hand across, not your skill level.

2.1 Level 1: AI as reference You ask a question and the AI answers it. For example, you might ask "What is the I2C address range for peripherals on an Arduino Uno?", or "What does this linker error mean?", and "What is the difference between SPI mode 0 and mode 3?" You take the answer away and apply it yourself.

● 28

Chapter 2 • The five levels of delegation

Level 1 maps onto what most people already do with a search engine, except that the AI synthesises and explains rather than handing back a list of links. For a maker digging through an unfamiliar datasheet or decoding an obscure error, it is useful. It also has the lowest ceiling of the five: you are not getting code, you are getting knowledge that helps you write code yourself. Most makers who use AI at all start here.

2.2 Level 2: AI for snippets In this level, you own the code and use the AI to fill in one piece of it.

Say you are writing firmware for a sensor interface, and you need a function that converts a 12-bit ADC reading to a voltage given a 3.3 V reference. You ask the AI to write that specific function. The AI gives you get something you can paste into your existing file, you check that the formula matches the hardware, and you integrate it.

In Level 2, you are still the architect. You decided the program structure, the data types, and where this function sits; the AI handled one implementation detail. If the snippet is wrong, you catch it, because you know what it's supposed to do. The discipline at Level 2 is that you are not asking the AI to generate the whole program. You are asking for a piece you can evaluate on its own terms.

2.3 Level 3: AI for functions and modules In Level 3, the AI is not filling in a snippet. It's implementing a complete, self-contained part of your design.

Say you need a Python class that manages a serial connection to an Arduino. The class opens the port, sends commands formatted as JSON, reads responses, handles timeouts, and raises a clean exception if the connection drops. You describe the interface and the behaviour; the AI writes the implementation.

You designed the interface, the AI wrote the body, but you still need to understand the result well enough to test it and fit it into the rest of the system. This is where domain knowledge starts to pay off in your prompts. Knowing what the class must handle, including the awkward cases like a dropped connection or a malformed response, is what makes the specification precise enough for the AI to get it right.

2.4 Level 4: AI for complete files and components In Level 4, you provide a specification and the AI returns a working file or subsystem.

For example: "write a single-file Python script that reads sensor data from a serial port at 9600 baud, where the data arrives as comma-separated lines with three fields, timestamp, voltage, and current; plot all three on a live-updating graph; and save the data to a CSV when the user closes the window". In response to this prompt, the AI will give you a complete, runnable script. Notice what makes this specification work: it names the exact fields the data contains (so the AI parses the right columns), and it states an explicit exit condition (closing the window triggers the save). Those two details eliminate the most common sources of a wrong first draft.

● 29

The Maker’s Guide to AI Coding

At this level you are the architect and the reviewer. You specify what the system does, and the AI writes the whole thing. The quality of the output depends heavily on the quality of your specification. If you under-specify, you'll get something that technically works but doesn't fit your requirements. If you specify precisely, you'll often get something close to final on the first pass. This is where framing becomes the bottleneck, which is exactly what Chapter 4 is about, and it's where most of the build work in this book sits.

2.5 Level 5: AI as agent In Level 5, the AI doesn't just generate code. It reads your files, runs commands, observes the output, and responds to what it finds. You set a goal and the AI executes the steps.

Tools that work this way include Claude Code (the tool used throughout this book), Cursor in Agent mode, and GitHub Copilot Workspace.

In practice, it looks like this: You point an agent at a folder containing a half-built serial plotter and tell it: "The graph freezes when the Arduino sends malformed data. Find the issue and fix it." The agent reads the source, locates where the parser fails on unexpected input, writes a fix, runs the script to check it, and reports what it changed. You didn't write that code or diagnose the bug. You reviewed the change and decided whether to accept it.

Level 5 is the most powerful mode in this book, and the one that asks the most of you, because you have to be able to read and evaluate what the agent produces. An agent running unchecked can make plausible-looking changes that quietly break something you were not watching. The habits that matter most here are reviewing every change, committing your work before each agent run, and running your tests on the result. At Level 5, reviewing every AI-generated change is what makes the level safe to use. Chapter 5 covers the related habits.

2.6 Higher is not better It is important to keep in mind that working at a higher Level is not better. You should pick the appropriate Level for the task on hand.

If you need a one-line function to strip whitespace from a sensor label, Level 2 is the right call. Reaching for a Level 5 agent to produce five lines wastes context, invites unnecessary change, and takes longer than just asking for the snippet or writing it yourself. The skill is not always operating at the highest level available. It's choosing the right level for the task in front of you.

A Maker who uses Level 1 for a quick lookup, Level 3 for a module, and Level 5 for a gnarly debugging session is using these tools well. The levels are a vocabulary for making those choices deliberately rather than by habit.

2.7 Where the builds sit The builds in this book are arranged so that the level rises as you go, because you cannot evaluate what an agent produces until you have spent time at the lower levels. The progression is deliberate.

● 30

Chapter 2 • The five levels of delegation

Build

Part

Level

Calculator in a browser (RC filter

I

3–4

Serial data plotter

II

4

Datasheet question-and-answer

III

4–5

IV

5

analyser)

tool Resource booking system (capstone)

You'll start with a complete single file written from a specification, with no editor or agent in sight. Then, you'll move into proper Level 4 work in your editor, writing detailed specifications and handling multi-file output. By the time you'll get to the capstone project, you are running agents across many files, evaluating their decisions and steering multistep work. Each build gives you the foundation the next one assumes.

That covers how big a task to hand over. It leaves open the harder, more personal question: how much of that handover can you safely supervise right now? That is what the next chapter is about.

● 31

The Maker’s Guide to AI Coding

Index A adaptive routing agentic retrieval

224, 236 221, 223, 224, 225, 226, 236 authentication 32, 33, 92, 147, 148, 166, 167, 174, 175, 176, 183, 184, 202, 210, 211, 212, 236, 243 authorisation 176, 210, 236 B background job

133, 186, 188, 190, 194, 215, 236 blueprint (Flask) 182, 236 boilerplate 24, 25, 27, 237 C cache-augmented generation (CAG) 221, 222, 225, 237 centaur 221, 227, 228, 229, 231, 233, 235, 237, 238, 240, 242, 244 chunking 126, 139, 151, 154, 170, 223, 237 constraints (specification element) 22, 24, 25, 38, 39, 40, 41, 43, 44, 45, 48, 49, 53, 64, 69, 70, 71, 75, 94, 95, 96, 97, 105, 114, 154, 155, 156, 237 content refusal 147, 237 context 15, 21, 22, 23, 24, 25, 26, 27, 30, 38, 39, 40, 41, 42, 43, 45, 46, 48, 49, 50, 53, 54, 57, 60, 64, 69, 71, 78, 89, 94, 96, 103, 105, 132, 135, 136, 137, 138, 140, 142, 145, 147, 154, 155, 161, 162, 163, 164, 166, 169, 184, 188, 189, 198, 210, 215, 221, 222, 223, 225, 226, 229, 237, 238, 242, 243, 244 context (specification element) 15, 21, 22, 23, 24, 25, 26, 27, 30, 38, 39, 40, 41, 42, 43, 45, 46, 48, 49, 50, 53, 54, 57, 60, 64, 69, 71, 78, 89, 94, 96, 103, 105, 132, 135, 136, 137, 138, 140, 142, 145, 147, 154, 155, 161, 162, 163, 164, 166, 169, 184, 188, 189, 198, 210, 215, 221, 222, 223, 225, 226, 229, 237, 238, 242, 243, 244

● 246

context window cosine similarity D data isolation decorator (Python)

25, 136, 169, 223, 225, 237, 238, 242, 244 138, 238

174, 176, 239 175, 210, 239

E embedding 127, 130, 137, 138, 139, 143, 154, 155, 160, 161, 162, 164, 165, 223, 224, 237, 238, 239, 245 embedding model 127, 137, 138, 139, 143, 155, 160, 161, 162, 223, 239 F fine-tuning foreign key

221, 224, 225, 239 178, 200, 208, 239

G graceful failure 145, 147, 148, 149, 166, 236, 237, 238, 240, 241, 243, 244 graph-based retrieval 224, 240 H hallucination 21, 43, 45, 140, 232, 240 hybrid search with re-ranking 224, 240 I idempotent

188, 240

M Markdown 49, 105, 142, 143, 144, 151, 156, 158, 160, 163, 164, 165, 168, 169, 240 migration (database) 176, 198, 199, 200, 201, 208, 217, 241 mock-first 73, 75, 77, 91, 102, 108, 237, 241, 244 multi-tenancy 16, 197, 200, 201, 207, 217, 219, 241, 244 O ORM (object-relational mapper)

172, 177,

Index

178, 179, 181, 205, 239, 241, 242, 244, 245 output format (specification element) 39, 40, 41, 48, 49, 64, 67, 69, 70, 94, 96, 105, 106, 147, 156, 241 P primary key

178, 200, 239, 241

R RAG (retrieval-augmented generation) 16, 126, 136, 137, 138, 139, 156, 159, 168, 221, 222, 223, 224, 225, 236, 237, 238, 239, 240, 242, 243, 245 reverse centaur 227, 228, 229, 233, 242 reverse proxy 92, 194, 195, 216, 242 route (Flask) 71, 78, 80, 83, 94, 110, 111, 117, 124, 158, 159, 175, 176, 183, 188, 198, 199, 210, 215, 217, 219, 239, 242 S schema (database) 39, 104, 134, 173, 174, 176, 177, 179, 181, 182, 183, 196, 197, 198, 199, 200, 201, 202, 207, 217, 219, 241, 242 self-checking retrieval 224, 242 self-hosting 128, 243 Server-Sent Events (SSE) 78, 103, 110, 121, 158, 243 service error 147, 243 streaming 79, 102, 110, 116, 123, 132, 133, 135, 146, 147, 151, 156, 157, 158, 168, 236, 238, 242, 243, 244 structured JSON extraction 142, 243 system message 132, 243

125, 133, 151, 161, 162, 163, 165, 168, 171, 244 tenant 173, 178, 197, 198, 199, 200, 201, 207, 217, 218, 244 timeout 90, 147, 187, 244 token 59, 128, 129, 145, 146, 147, 148, 149, 158, 163, 165, 166, 169, 218, 243, 244 V vector 127, 137, 138, 139, 151, 154, 155, 160, 161, 162, 164, 166, 168, 172, 177, 182, 223, 224, 238, 239, 240, 245 vector store 127, 137, 139, 155, 160, 162, 164, 166, 168, 172, 177, 182, 223, 238, 245 VPS (virtual private server) 193, 195, 216, 245 W worker process

189, 245

T task (specification element) 15, 24, 25, 26, 27, 28, 30, 31, 32, 33, 38, 39, 40, 41, 43, 44, 45, 48, 56, 57, 58, 59, 60, 64, 67, 69, 71, 72, 94, 96, 97, 105, 106, 107, 108, 112, 116, 119, 141, 154, 155, 164, 182, 184, 185, 209, 228, 244 temperature 14, 23, 25, 26, 32, 43, 66, 69, 75, 76, 79, 80, 81, 82, 83, 84, 87, 91, 96, 99, 101, 102, 103, 104, 108, 109, 119,

● 247

The Maker’s Guide to AI Coding

The Maker’s Guide to AI Coding

If you can describe it, you can build it AI coding assistants are changing what makers and solopreneurs can build.

Tasks that once demanded weeks of learning a new language, framework, or software stack can now be delegated to an AI—provided you know how to describe the job, judge the result, and keep control of the process.

The Maker’s Guide to AI Coding is a practical guide to doing exactly that.

It explains how to work with AI coding tools as collaborators rather than vending machines, how much to delegate, how to write specifications that produce useful results, and how to recognise hallucinations, context drift, overconfidence, and code that runs but is still wrong.

The book is built around four increasingly ambitious projects. You begin with a browser-based RC filter analyser, then develop a live serial data plotter for Arduino and other microcontrollers. Next comes a datasheet questionand-answer tool using retrieval-augmented generation (RAG), followed by a complete multi-user resource booking system with authentication, a database, external services, background jobs, and deployment.

No advanced programming background is required. The emphasis is on thinking clearly, guiding the AI, testing what it produces, and preserving the skills needed to evaluate its work. Along the way, you learn development workflow designed to remain useful as tools evolve.

Peter Dalmaris is an educator, engineer, and lifelong learner.

He is the founder of Tech Explorations, where he creates online courses and books that empower electronics enthusiasts, STEM educators, and students around the world. With a background in engineering and academic teaching, Peter is known for his hands-on, accessible approach to technical education. His work combines theory with practice, helping learners of all levels build confidence through making and experimentation.

If you can describe what you want to build, this book shows you how to turn that description into working software.

Elektor International Media www.elektor.com

● 248