When Machines Work Together

Picture something different from a programmer at a desk.

You have an idea. You do not know everything you need to build it. You may not even know whether the technology exists. So you ask one machine to investigate, another to explain what it found, another to build a first experiment, and another to challenge what was built. You use the result yourself. You redirect the work. You keep what was learned. And when something better becomes available, you change the machines you use and the way they work together.

That is the arrangement this chapter is about. The previous three chapters each gave you a capability: following what changes (Chapter 17), giving a machine durable context and instructions (Chapter 18), and choosing the right intelligence for each job (Chapter 19). Here they come together. You become the director of a collection of intelligent capabilities working towards an objective you care about — and your ability to create stops being limited to what you knew and could do at the start.

Several lasers, one target

I think of it as focusing several lasers on one point. The important thing is not the number of beams. It is that they converge.

That is the difference between a team and a crowd. Several capable machines without a shared direction produce incompatible suggestions, duplicated work and expensive confusion: one rewrites what another just built, a reviewer critiques a design nobody chose, research piles up that answers a question no one asked. The same machines aimed at one clearly stated objective can each contribute something the others cannot.

The direction is yours. Not the implementation plan — the machines can propose that — but the objective: what you are trying to make, for whom, and what would count as success. Everything else on the team takes its bearings from that.

This book was written this way

I can describe this from experience, because the book you are reading was made by a small team of machines.

I set the direction: what each chapter is for and what it must argue. One AI system helps me develop those ideas and turns them into detailed commissions. Other systems draft chapters from those commissions; one of them also acts as an editor, reviewing drafts and sometimes reshaping a commission before writing because the plan repeats what an earlier chapter already said. The repository holds the shared record — an editorial index, evidence notes for every chapter, an instruction file — so that whichever machine picks up the work next starts from the same place. I read what comes out and decide what stays.

It works, and it also fails in instructive ways. One night two separate sessions were working in the same folder at once. I gave one of them a chapter to write, and it found a finished draft of that chapter already waiting — written minutes earlier by the other. Nothing was lost, but the lesson was plain. A team of machines needs the same thing a team of people needs: someone to decide who is doing what, and a shared record everyone actually reads.

Learn what you need along the way

The deepest change is this. In traditional development you learned a technology before you could use it: the language, the framework, the library, the method. With a team of machines, much of that learning can happen inside the work.

Suppose you want to build an unusual interface between people and AI — something you speak to while you walk. You know nothing about speech recognition, audio processing or the research on conversational interfaces. You do not need to study them first. A machine can research the concepts and explain them at the level you need, find the existing tools, compare their trade-offs and propose a first experiment. Another can build it. You try it, and only then do you understand what you actually want — which sends the research off in a better direction. Learning, researching, experimenting and creating become one loop rather than a sequence with years of study at the front.

You are not limited to the tools you knew existed yesterday.

Two precisions keep this honest. First, when the team researches a skill or installs a library, the underlying model has not learned anything; its weights are unchanged. What has grown is the combined working system — you, your records, your tools and the machines you direct. Second, a capability the team has read about is not a capability you can trust. A new technique becomes part of your working method when it has been tried on real work and evaluated, not when it has been described convincingly.

One direction, several machines

Chapter 18 showed that one machine can take on several roles — researcher, collaborator, engineer, reviewer, organiser — through different instructions and context. A team simply distributes those roles, and adds a couple that matter more once there is more than one machine: an evaluator that compares results against the objective and the evidence, and a recorder that keeps decisions, experiments and discoveries so the next session can continue.

These are responsibilities, not an architecture. You do not need six agents. Roles can be combined; a role can exist for one afternoon; a single capable model, used in clearly separated sessions, can be the whole team for a long time. Separate machines earn their place when they contribute something a single one cannot: a different capability, a cheaper way to do routine work (Chapter 19), or — most valuable of all — a genuinely independent view.

Teams also cost something. Each additional machine adds expense, delay, permissions to manage and more chances for the parts to disagree. So the rule I hold myself to is simple: every machine should have a reason to be involved. If you cannot say what a member of the team contributes that the others do not, it is decoration.

The person in the middle

None of this asks you to approve every technical decision. The machines can plan, research, identify what is missing and recommend changes, and routine choices can be delegated outright. Your part is different, and it is not small.

You know the problem, what you value, what you are willing to spend, and what useful looks like. You decide what the team may touch and which consequential actions — spending money, publishing, deleting, changing anything that matters to other people — need you. And you direct the work in ordinary language: “I want this to be easier to use.” “Find out what other approaches exist.” “See whether a different model would do this better.” “Build me a version I can try.” “Get someone else to challenge it.” “I don’t like where this has gone — let’s try another direction.”

The test is not how many decisions you made personally. It is whether the team is still pursuing your goals, or has quietly substituted its own.

Tune it like a racing car

A racing team does not build a car, declare it finished and never touch it again. The car is driven. The data is examined. Engineers find where it loses time; mechanics change the set-up; specialists look at particular components; the driver says how it feels. The car goes back out, and the results decide what happens next.

A product developed with a team of machines can follow the same rhythm. You use the application. A research role looks for possible improvements. A builder makes a change. Review and evaluation investigate it. You use the new version. The results are kept, and the next experiment begins.

That is not a new method. It is the loop this book has used from the start — communicate, build, evaluate, improve — with different parts of it handed to different machines. Directing sets the goal; investigating and equipping find the knowledge and the right tools; building makes something usable; challenging tests it independently; experiencing is your judgement of the real thing, as in Chapter 15; improving changes it; remembering keeps what was learned. Small tasks need only some of these. The value is in the rhythm, not the ritual.

And a racing team always has a car that can race. The analogy does not mean software is never finished or never stable. It means there is a current version people can rely on, and a continuing possibility of a better one.

Let the machines challenge one another

The most dangerous illusion in a team of machines is agreement.

Three models can share the same mistake. A reviewer can confidently approve a defect. Five agents can produce a great deal more work without producing a better application. A newer model can do worse on precisely the task where you expected it to shine. In my own more technical work I have run comparisons where adding models or more elaborate prompting strategies did not improve the verified results. Agreement among machines is not evidence; it may just be the same blind spot, counted several times.

So be careful what you call independent. Asking the same model to “now act as a reviewer” can be useful, but it is not independent review: it shares the original’s assumptions and often its affection for its own work. Independence comes from a different model, a different provider, real tests that run the thing, or a human with relevant expertise.

The team must be judged by what it accomplishes, not by how much intelligence or activity it appears to contain. Evidence depends on the purpose: the application doing what it should, a test catching a regression, a user finishing a task more easily, a measurable saving in time or cost, a new capability shown working in a real experiment, an experience that is clearly better. Useful systems keep the last accepted version, can undo changes that turned out worse, and only promote an improvement when there is enough evidence that it is one.

When the team discovers something new

This is the part of the arrangement I find most exciting, so it deserves care.

Suppose the research role finds a library or technique you had never heard of, and that the coding machine would never have reached for. Suddenly there is a new possibility. The team can investigate it, read its source and documentation, work out what using it would require, and propose a bounded experiment. If you agree, it can try it and evaluate the result. If the result holds up, your working system now has a capability it did not have yesterday, and you can attempt things you could not before — without first mastering the technology underneath.

That is real amplification. It is also exactly where a team of machines can do the most damage if nobody is directing it. A discovery is not a licence. The team must not install arbitrary code, expose credentials, grant itself new permissions or deploy changes because something interesting turned up. New capabilities come in through the same boundaries as everything else — your permissions, the project’s limits, the purpose of the work — and they stay on trial until they have earned trust.

Try Machine Coding — Build With a Team

This exercise uses the AI Frontier Scout from Chapter 17. That application is proposed rather than built for this book, so treat this as an illustrative exercise; if you have not built a scout, use the arcade game from Chapter 13 instead, described at the end. You do not need a multi-agent framework. You can play every role with one capable AI in clearly separate sessions, or use different models if you have them and are permitted to. Nothing below reports results from a run of my own.

Give the team a direction.

I want to improve my AI research application so it finds developments relevant to my work and helps me decide which are worth investigating. Help me work out the single most useful improvement to make first.

Ask a researcher.

Before changing anything, research how other systems approach this. Find a few methods or tools, explain their advantages and limitations, and give me the sources. Don’t change the application yet.

Equip the team.

Based on that research, which tools or models would suit this improvement? Check whether I can use them, what they cost and what restrictions apply. Recommend a simple approach I can actually use.

Hand the work to the builder.

Implement a small version of the approach we chose. Keep everything that already works. Show me what changed and give me a version I can try.

Get it challenged.

I want a critical review of this change — from a different model or real tests if we have them. Look for wrong assumptions, defects, missing functionality and regressions. Tell me exactly what was checked and what remains uncertain.

If the only reviewer available is the same model in a new session, say so in your notes: it is a second look, not an independent one.

Experience it.

Show me the new version next to the old one. I want to use both and decide whether this actually improves my research. Ask me what I think, and don’t assume the change is better.

Keep what was learned.

Record what we tried, why, what worked, what didn’t and what we decided to keep. Preserve the working version and the evidence, so I can return later and understand how this evolved.

You have done the exercise when you can say: what the objective was, what the research contributed, which tool was chosen and why, what the builder changed, what the review actually established, what you decided to keep, and what is recorded for next time.

With the arcade game instead. Set the direction as “I want the game to feel better to play.” Ask a research role for a few basic principles of what makes simple arcade games satisfying, with sources. Have a builder propose and make one or two changes based on them. Ask for a review that looks for anything broken. Then play it, describe what you feel, and let that feedback shape the next round. One AI, clearly separated sessions, no subscriptions required.

Your team, not mine

My own team reflects what I do: programming, writing, research and building AI systems. Yours should reflect what you do.

A historian would assemble different roles from a musician. A teacher would need different expertise from a small-business owner concentrating on customers and accounts. Someone who mostly wants a better personal routine might need nothing more than a good researcher and a reliable organiser. Some projects need one model; some need several specialised tools; some need a human expert at a particular point; and some operations, as Chapter 19 said, need no AI at all. There is no optimal team. There is only the team that fits your work. The objective is not to copy my machinery. It is to develop machinery suited to your own ambitions.

The product grows with you

Something happens when you work this way for long enough. Three things begin to develop together.

You develop: you learn more about the domain, the technology and what you actually want. Your working environment develops: it gains better records, sharper instructions, more suitable tools and, as Chapter 17 described, better models as they arrive. And your product develops: it absorbs the experiments that worked and moves closer to an objective that has itself become clearer. Each feeds the others. You find a new idea because of something the team researched. The team gains a capability because you asked it to look into a limitation. The product reveals a problem that changes what you wanted in the first place.

I call the result a living product. I mean that as a metaphor, not a biology: software capable of continuing, directed change, not software that changes itself or is somehow alive. Not every change is an improvement, and a living product is not an unstable one. It keeps a dependable version while the next one is explored, and it changes when there is reason and evidence to change it.

You are not simply building something with AI. You are developing a way of working in which you, your machines and your creations can keep improving together. What that relationship looks like over months and years — as models change, as you learn, as old experiments are reconsidered and the product keeps evolving — is where the next chapter, ALIVE — Living Technology, begins: software that takes part in its own continuing improvement.