What the work actually taught us.

“The people we trust with the accountable core learned it by doing the work we are now handing to agents. If we do not deliberately rebuild that apprenticeship — putting juniors in the decomposer and reviewer seats early, with real accountability and a senior beside them — we are spending down a stock of judgement we have stopped replenishing. It will not show up this quarter. It shows up the year you cannot find anyone able to own the hard call.”

“In traditional software, engineering decisions and economic decisions often lived far apart. Features could be discussed in terms of effort, risk and customer value because the cost of serving one additional user was almost invisible. As usage-based intelligence became part of the product, that separation started to break down. The teams adapting fastest were the ones that made economics part of product design. They knew which capabilities were expensive to serve, which customers generated disproportionate cost, and which experiences created value without creating an equal increase in spend. The slowest teams treated cost as an infrastructure concern and discovered too late that the product itself had become the largest driver of the bill.”

“The surprising thing was not that building became cheaper. It was that shipping became more expensive. New capabilities could be created faster than ever, but every successful capability generated a stream of future obligations: usage, support, reliability expectations, operational cost and customer dependence. The conversation often started with a feature and ended with a product. What looked inexpensive at launch accumulated cost every time a customer used it. The organisations pulling ahead were not the ones asking whether they could afford to build something. They were asking whether they could afford to succeed with it.”

“One pattern appeared often enough to become familiar. An organisation recognised that a new capability carried uncertainty, so it created a council, steering group or governance forum to oversee it. The intention was sensible. The outcome was often less so. The group met regularly. Risks were discussed. Updates were shared. Questions were raised. Yet the most important decisions remained unresolved. Nobody could clearly explain who had authority to decide, what evidence would be sufficient, or what would happen if the answer was no. The forum created visibility but not accountability. Over time the absence of a decision became a decision in its own right. Pilots continued because nobody stopped them. Risks remained open because nobody accepted them. New work started because existing work had never formally ended. The organisation had created governance around the topic without creating ownership of the decisions. The strongest teams treated forums as inputs to decisions, not substitutes for them. They could point to a named owner, a clear threshold and a defined next step. Their meetings were shorter because the architecture of decision-making existed before the meeting began.”

“The first conversation was usually impressive. A model answered questions. A workflow was automated. A task that once took hours now took minutes. The demonstration worked. The second conversation was where things became difficult. Somebody eventually asked what the system could actually do in production. Could it update a record? Approve a transaction? Trigger a workflow? Access customer data? And if it did, who authorised the action, what permissions were used and how would anyone prove what happened afterwards? The discussion shifted almost immediately from intelligence to access. The model was rarely the constraint. Identity, authorization and accountability were. The teams that moved beyond demonstrations treated access as a product in its own right. They designed permissions, audit trails and reversibility with the same care they applied to prompts and models. Looking back, very few initiatives stalled because the model was not capable enough. Many stalled because nobody could answer a much simpler question: what exactly are we comfortable letting it touch?”

“We expected larger context windows to fix AI coding quality. In practice the opposite held. Heavily curated, owned context — conventions, architecture decisions and expected behaviours written down explicitly — consistently outperformed simply giving the model more files.”

“We repeatedly found that improving the engineering environment around the model moved acceptance more than changing the model itself. Shared instructions, repository structure and automated validation outweighed swapping one frontier model for another.”

“One pattern surprised us early: agent-generated code that compiled and passed tests but quietly violated architectural boundaries no human would have crossed. The fix was not a better model — it was moving the architectural constraints into the shared instruction layer, where acceptance rates then improved.”

“The first week of agent adoption often looks transformational — code appears faster, prototypes arrive sooner. The second phase is where reality appears: reviews lengthen, architecture questions surface, and engineers spend more time validating work they did not write. Generation accelerates immediately; acceptance rarely does.”

“A heuristic we keep using is blast radius. If the cost of a wrong answer is a developer’s afternoon, generate freely. If it reaches customers, money, security or compliance, acceptance work quickly dominates generation work.”

“We repeatedly found that reliability came less from model capability and more from feedback loops: generate, validate, feed the result back, repeat. The harness carried more of the reliability than the model did.”

“Building products that reason over specialist knowledge, we kept the model off the decision path: a deterministic resolver emits the answer with an evidence chain, and the model only assists interpretation. Experts trust what they can audit, not what they are asked to take on faith.”

“The systems that proved most reliable shared one characteristic: they validated rather than trusted. Whether the producer was a person, a pipeline or a model, contract failures surfaced early instead of corrupting downstream systems.”

“Across multiple delivery channels we learned that generation is rarely the source of reliability. Deterministic validation is. The gate mattered more than the generator.”

“Writing the eval first — the check two reviewers would independently agree on — forced the ambiguity out of a spec before generation began, and turned acceptance from a test of reviewer stamina into an engineering problem.”

“Building connected-device systems taught us reliability lives at the seams — power, connectivity, provisioning, serial stability, diagnostics — far more than in the electronics. Reliable field hardware is an operations problem wearing an electronics costume.”

“Letting agents reach real tools, we learned access is a boundary problem, not an integration one. Enforcing allow / deny / ask on every tool call — and recording who decided what — mattered more than the connection itself.”

“We started treating context as an engineering asset — versioned, owned, with eviction and provenance — rather than prompts each developer retypes. That shift did more for consistency than any model upgrade.”

“On local versus hosted models, the useful question was never “which is better” but “what boundary does this data require, and what fits inside it”. The boundary, not the benchmark, drove the choice.”

“When we instrumented our own delivery, output metrics — commits, lines — told us nothing useful. Acceptance rate and rework told us everything: whether intent was actually reaching production.”

“Reviewing governance controls, we noticed a pattern: the controls creating the most delay were often least able to explain which bad decision they prevented. Asking that question became the fastest way to distinguish assurance from theatre.”

“Walking a single intent from strategy to production, we could watch meaning leak at each handoff that no one owned. The loss was never in the building — it was in the translation between the people doing the building.”

“The expensive thing was rarely a bad decision — it was a slow one, or one nobody could later explain. Recording the decision and classifying its reversibility did more for speed than any new tool.”

“We discovered architecture failures were rarely caused by bad decisions. They were caused by forgotten decisions. Recording why something exists often proved more valuable than documenting how it works.”

“The most expensive dependency was rarely technical. It was the dependency that required two teams to coordinate before either could move.”

“The easiest mistake in AI projects is mistaking a successful prototype for a repeatable capability. Prototypes demonstrate possibility. Operating models determine sustainability.”

“Knowledge systems do not fail because information is missing. They fail because nobody owns what is no longer true.”