A working brief for the engineering team: the current model and tool landscape, the practices that separate teams who ship from teams who thrash, and the risks we have to engineer around.
Six parts, building from what the technology actually is, through how to work with it, to the platforms we can use.
What human and artificial intelligence each are, how they differ, and why capability is jagged.
Almost everyone uses it, fewer than half trust it, and tools have moved from autocomplete to agents.
Models change fast, open-weight options matter, and the harnesses around them are what you actually use.
The six building blocks, the six common mistakes, and how to refine until a prompt is reliable.
Automation versus agentic workflow versus agent, which to build, and context engineering.
Zapier, Make and n8n: what each is and why they matter to us.
Before we use it well, we should be precise about what it is — and what it is not. Most bad decisions about AI start with a category error here.
The full spectrum of cognitive, emotional, social and physical capacities that let a person understand the world, learn from very few examples, and make value-based decisions in ambiguous situations.
Logic, abstraction, and cause-and-effect thinking that generalises to situations never seen before.
Recognising and managing feelings, in yourself and in the person across the table.
Original thought and genuine invention, not only recombination of what already exists.
Deciding what should be done, not merely what can be done. This is the one that carries accountability.
Computer systems that perform tasks once thought to require human thinking — by learning statistical patterns from very large datasets and using them to predict the next best output.
Learns correlations from billions of examples. It is extraordinarily good at what resembles what it has seen.
Runs continuously, consistently, across many tasks at once, without fatigue or mood.
Excellent at the shape of task it was trained for, and unreliable a short distance outside it.
Needs human framing, evaluation and correction. It has no independent way to know whether it succeeded.
Not better and worse. Different in kind — which is precisely why the division of labour between them is a design decision worth making deliberately.
| Dimension | Human intelligence | Artificial intelligence |
|---|---|---|
| Learns from | Lived experience and a handful of examples | Enormous datasets and millions of examples |
| Strength | Depth and meaning — knowing what matters | Speed and scale — knowing what, and how fast |
| Creativity | Original intent and direction | Recombining existing patterns fluently |
| Ethics | Moral agency and accountability | No moral agency — it optimises against data |
| Nature | General, contextual, and slow to scale | Narrow, literal, and scales instantly |
| Failure mode | Tired, biased, inconsistent — and usually knows it | Confident, fluent, and wrong — and cannot tell |
Capability is not a smooth line from simple to hard. Even the strongest 2026 frontier models solve doctoral-level problems one moment and fail at something a child handles the next — and nothing in the output signals which you just got.
Fluency feels like understanding, but the model has no model of truth — only of language. It predicts what a correct-sounding answer looks like. When the pattern is right, the answer is right. When the pattern is right and the fact is wrong, the answer still sounds right.
You cannot delegate on the basis of difficulty. "This task is easy, so it will be fine" is not sound reasoning about a jagged system. You delegate on the basis of whether the output can be checked — which is the whole argument of section 05.
AI is a remarkably capable tool — not a colleague with judgement. It amplifies your thinking; it does not take over your responsibility. Keep a person in the loop wherever the answer has consequences.
Adoption stopped being the interesting question about eighteen months ago. Effectiveness is the interesting question now.
These two facts sit side by side in every major 2025–2026 survey, and they explain why "just give the team Copilot" is not a strategy.
Most teams are running a mix. Knowing which generation a tool belongs to tells you how much supervision it needs.
Inline next-line suggestions. You stay in the driver's seat the entire time. Low risk, low ceiling.
Copilot inline, Tabnine, Codestral FIM
Ask, paste, apply a diff. The model sees files you point it at. You still assemble the context by hand.
Cursor, Cline, Copilot Chat, Continue
Plan, edit across files, run the test suite, read the failure, fix it, repeat. Sessions run for hours. Fleets run in parallel.
Claude Code, Codex, Antigravity CLI, Muse Code, Devin
When the agent can run the code, the bottleneck moves off "can it write the function" and onto what the agent is allowed to see, run and merge. That is an engineering problem, not a prompting problem — and it is the subject of section 03.
A snapshot that will be partly wrong in ninety days. Learn the shape of the landscape, not the leaderboard.
Selected coding-relevant releases. The point is not to track all of them — it is to notice that any tool decision you make has a ninety-day shelf life.
For internal tooling, bulk refactors, test generation and anything that runs in a loop, the gap to frontier is small and the price gap is one or two orders of magnitude.
5.3 targets software engineering, autonomous agents and security, with a claimed 50% coding improvement over 5.2. The Flash variant is multimodal at roughly $0.075 / $0.25 per million. Coding plans start around $18/month. Note 5.3 moved off MIT to a bespoke licence.
First open 3T-class model — 2.8T total parameters, native vision, 1M context. Weights on Hugging Face under a custom licence with a commercial-agreement threshold for large model-as-a-service businesses.
Generally available across app, web and API with three reasoning-effort levels and OpenAI Responses API compatibility. 1M context, output to 384K. Off-peak usage bills at half the peak rate — relevant for overnight batch work.
Dense 27B under Apache 2.0, text/image/video in, 262K context extensible to 1M. The realistic option if we ever need to run something on our own hardware for data-residency reasons.
The harness is the part that holds context, runs tools and manages subagents. On the current evidence it matters roughly as much as the model.
Terminal, desktop and web. Subagents, agent teams, skills, hooks and a plugin marketplace. Highest satisfaction of any tool in the JetBrains January 2026 pulse — 91% CSAT on 18% adoption.
App, CLI, IDE and web. Adopted the SKILL.md format as an open standard, so skill packs now work across both ecosystems.
Antigravity CLI replaced Gemini CLI at I/O 2026. Meta's Muse Code shipped in beta in August; xAI open-sourced Grok Build in July.
Full-screen Agents Window for parallel multi-agent execution across local, cloud, SSH and worktrees, plus a separate CLI with cloud handoff.
Agent command centres and spec-driven workflows built into the editor. Kiro in particular is built around specs rather than chat.
Model-agnostic, self-hostable, no lock-in. OpenCode reported 150K+ stars and 6.5M+ monthly actives by April 2026.
Pick one primary harness for the team and one open-source fallback. Shared muscle memory, shared config files and shared skill packs are worth more than each developer optimising their own setup.
The craft of telling a model exactly what you need — clearly, with the right context, in a way that can be repeated and tested.
In 2026 the job is not finding magic words. It is assembling the right context — role, task, constraints, examples and output format — so the model can reliably do the thing you need, again tomorrow, for someone else.
Cleverness in context assembly is the craft that replaced it. What the model can see matters far more than how you phrase the ask.
Version them, test them, review the changes. A prompt that matters to the business belongs in the repository, not in someone's chat history.
Relevant context yields far larger gains than any rewording ever will. If output is poor, ask what the model could not see — not how to say it more nicely.
Any prompt that has to work more than once should have all six. Missing blocks are where inconsistent output comes from.
Who the model should act as.
The job, in one clear line.
The data, documents or facts it needs.
Boundaries, rules, length limits.
One to five samples of the pattern you want.
The exact shape of the output.
quarterly-summary Role: Senior financial analyst. Task: Summarise the Q3 report for the board. Context: <report> ...the actual figures... </report> Limits: Only figures from the report. Max 120 words. Format: 3 bullets + a one-line risk callout.
ticket-triage Role: Support lead for an ERP rollout. Task: Classify this client ticket and route it. Context: Teams: finance, inventory, integrations. Example: "Invoice total wrong" → finance · high. Format: team · priority · one-line reason.
Worth reading aloud to the team once. Every one of them is common, and every one is cheap to stop doing.
Build complexity through iteration. It is a conversation partner, not a search box.
"Make it better" gives it nothing to aim at. Name the goal and the audience.
Prefer positive instructions. A pile of negatives degrades quality; use them sparingly.
More context is not better context. Curate high-signal material instead of drowning the task.
"Take a deep breath" and similar folklore do not help. Clear structure does.
Without a test set you cannot tell whether a change helped or just moved the error somewhere you did not look.
Start simple, then diagnose what is actually missing rather than guessing at rewordings.
A clear, direct prompt with no examples yet. See what you get.
Missing instruction? Missing context? Missing example? Name which one.
Examples for pattern. Steps for reasoning. A format spec for reuse.
Run it against a small fixed set of cases. Keep what wins; record what you changed.
Even a twenty-example evaluation set is worth more than a week of impression-based tweaking. Loop until the prompt is reliable, not until it is impressive once.
The teams getting real output are not using better models. They are engineering the context the model works inside.
Three different things, routinely confused, with very different costs and failure modes. Naming the level correctly is half of scoping a project.
Predefined, rule-based steps. The same input produces the same output every time. Ideal for high-volume, predictable work where correctness is non-negotiable.
When a form is submitted, send this email. Post the ledger entry on the first of the month.
Deterministic rails orchestrate the flow, with model-powered steps dropped in at the genuinely fuzzy decision points. Predictable and flexible — the sweet spot for most business systems today.
Extract vendor data with a model, then route approval through fixed rules. Classify complaints, route each by existing policy.
The model decides actions at runtime. It reasons, picks tools, adapts, and persists until the goal is met rather than until a script ends. Most capable, least predictable, hardest to audit.
"Keep this client from churning" — it monitors, follows up, escalates.
One question decides it: can the logic be written down?
And whenever you need an audit trail, regulatory defensibility, or a result that must be identical every single time. Payroll is the canonical case: the rules are fixed and the answer must be right on every run, not most runs.
When the task genuinely needs interpretation and adaptation at runtime. Answering varied, unpredictable support tickets is the canonical case: every one is different and needs to be understood before it can be routed.
Start with the simplest option that works. Add agent reasoning only where branching logic would become unmaintainable. Most real systems end up combining both — the agent interprets the ambiguity, the workflow enforces the consistency — and that combination is usually the right answer rather than a compromise.
The unit of work stopped being the prompt. It is now the whole environment the agent sees: rules, tools, memory, scope, and the checks that run without being asked.
What the project is, how it is built, what is forbidden
Lint, tests and blocks that run deterministically
Reusable procedures loaded only when relevant
Isolated scopes, parallel work, clean contexts
The acceptance criteria the work is checked against
Sessions now run for hours, so context has to survive compaction, overflow and restarts. And running five to fifty agents in parallel multiplies whatever your context setup is — good or bad.
Good context engineering is what makes agents consistently useful rather than occasionally impressive. Every hour spent here is repaid across every session afterwards.
Zapier, Make and n8n. The tools that actually build the level-one and level-two systems from the previous section — and the ones our clients will name.
All three do the same fundamental job: connect software that was never designed to talk to each other, without writing and maintaining integration code. All three have now added AI and agent features on top.
Something happens in one system, a sequence of steps runs, something changes in another. A form submission creates an invoice. A payment updates the CRM. A file lands and gets filed.
Each platform now lets you drop a reasoning step into the middle of that flow — classify this message, extract these fields, decide which team handles it — which is exactly the level-two pattern from section 05.
A meaningful share of what we currently quote as custom integration work is four modules on one of these platforms. Knowing when that is true protects both our margin and our credibility.
These are not toys, and they are not a replacement for engineering either. They are the right tool when the work is plumbing between systems that already have APIs. They become the wrong tool when the logic gets deep enough that you are effectively programming in a visual editor with no tests and no version control.
The oldest of the three and still the default name. Its whole design philosophy is that a non-technical person finishes a working automation in minutes.
| Billing | How it works |
|---|---|
| Unit | The task — roughly each successful step in a workflow. A ten-step workflow bills ten tasks per run. |
| Free | ~100 tasks a month, two-step workflows only — reduced sharply from earlier years. |
| Paid entry | Roughly $20–30 a month for about 750 tasks, rising steeply from there. |
| Agents | A separate meter in "activities", with its own free allowance and paid tier. Agent usage does not draw on your task pool. |
Formerly Integromat. A drag-and-drop canvas rather than a list of steps, which is what makes genuinely branching logic practical without writing code.
| Billing | How it works |
|---|---|
| Unit | The credit — one per module execution. A ten-step scenario costs ten credits per run. Make moved from "operations" to credits in 2025. |
| Free | ~1,000 credits a month, two active scenarios. |
| Paid entry | Around $9–12 a month for roughly 10,000 credits — broadly three to five times cheaper than Zapier at equivalent volume. |
| The catch | AI modules do not consume credits at the same rate as ordinary ones. This is where credit forecasts go wrong. |
A node-based canvas like Make, but source-available and self-hostable. For our market, that single property changes which conversations we can have.
n8n is fair-code under the Sustainable Use License, not OSI open source. Self-hosting is free for your own internal business use. The moment you charge clients to run their automations on your instance, you need a paid commercial licence. The technical setup is identical either way, which is exactly why firms get this wrong.