Comment on the standard for AI in engineering leadership.

Adoption strategy is the judgment about where an engineering organisation puts AI to work, in what order, at what scale and on what evidence, and when it narrows or stops an initiative that is not paying its way. It covers AI as a tool for the engineers and AI as part of the product, because both compete for the same money, attention and appetite for risk.

Core competency TJ-5 AI-assisted engineering sets the baseline for a team: decide the adoption, size the bet to teach. This unit is that judgment at the level of an organisation's choices: a portfolio of initiatives, a budget, a board and a market that all have opinions, and vendors whose deadlines are designed to arrive before the evidence does.

It matters because the evidence is real and uneven at the same time. Some tasks improve markedly with AI and some get worse, often inside the same job, and the difference is not obvious in advance. Organisations that adopt by enthusiasm spread money thinly over places it does not help; organisations that wait for certainty learn nothing while others learn. The examination tests the competency through a board that wants an AI strategy by the end of the quarter, a vendor discount that expires before a pilot can finish, and a pilot that has run for six months with enthusiastic reports and no measured change.

1. Adopt where the evidence about your own work says it helps. The question is not whether AI is useful in general but whether it helps with this team's tasks, in this codebase, for this product. Start where the work looks like the work AI has been shown to help with, and measure.
2. Every initiative is a bet with a stop condition. Write the hypothesis, the measure, the cost ceiling and the condition for stopping before starting. A bet without a stop condition is a commitment that has not admitted it yet.
3. Controls before scale. Review practice, data handling and measurement are in place before an initiative is widened. Scaling first and governing later means discovering the risks at the size that hurts most.
4. Size the bet to what it must teach. Large enough to produce evidence and capability, small enough to survive being wrong. Fund it by stopping something, so the trade-off is visible.
5. Report in the organisation's own terms. Promise outcomes the organisation can measure, in its own units, and report the uncertainty. Neither the vendor's figure nor the sceptic's anecdote is the organisation's result.
6. Stopping is a result. An initiative that is narrowed or ended on its evidence has done its job. Saying so openly is what makes the next bet credible.

The jagged frontier research

Dell'Acqua et al. (2026) ran a preregistered field experiment with consultants at a large firm. On tasks inside the model's capability, consultants using it completed 12.2% more tasks and worked 25.1% faster, with higher-rated quality. On a task designed to sit just outside that capability, consultants using the model were 19 percentage points less likely to reach a correct answer than those without it. The boundary between the two was not visible from the outside: the tasks looked similar. For a manager this is the central fact of adoption. The same tool helps and harms within one job, and only measurement on the organisation's own work shows where the line falls.

Uneven gains by experience research

Brynjolfsson et al. (2025) studied the staged rollout of an assistant to thousands of customer-support agents and found productivity rose on average, with the largest gains for the least experienced agents and little effect for the most experienced. The finding is from customer support, not engineering, and it cuts both ways for a manager: it suggests where early gains may come from, and it raises the question AI-6 Capability, roles and measuring impact takes up, of what the least experienced learn when the tool does the part they used to learn from.

Contested delivery effects contested

In software delivery the evidence disagrees. Becker et al. (2025) found experienced developers slower with AI tools in their own mature repositories, while believing they were faster. Cloud) (2024) estimated from survey data that higher AI adoption was associated with slightly lower delivery throughput and lower delivery stability, alongside faster code review and better documentation. What is contested is the size and direction of the effect on delivery as a whole, not whether individuals feel faster. A strategy that assumes a delivery gain is assuming the contested answer.

Modest aggregate effects contested

Acemoglu (2025) estimated AI's effect on total factor productivity across the economy over ten years at well under one percent, far below popular forecasts. Others expect much more, which is why the grade is contested. The estimate is about economies, not firms, and a single organisation can do much better or much worse than the average. It is useful to a manager for one reason: it shows that serious analysts disagree by an order of magnitude, so a board figure taken from a forecast is a choice, not a fact.

Discovery-driven planning practice

McGrath et al. (1995) argued that new ventures fail when they are planned as if their forecasts were known, and proposed planning them around the assumptions that must hold, tested at checkpoints, with each stage funded only when the previous one has paid off in evidence. The method predates AI and fits it closely. An AI initiative is a venture whose key assumptions (which tasks it helps, at what cost, with what risk) are unknown at the start, and the plan should say which assumption each stage tests.

Telling capability from claims practice

Narayanan et al. (2024) sets out how to separate real AI capability from inflated claims: ask what exactly the system does, how it was evaluated and on whose data, and whether the claimed effect was measured or projected. The book is most sceptical of predictive systems that claim to judge people, which matters to engineering leaders choosing tools for hiring and performance (AI-6 Capability, roles and measuring impact). Its questions are the ones a manager should ask every vendor and every internal enthusiast, including themselves.

The adoption map

The manager lists the organisation's work by kind (writing new code, maintaining old code, testing, incident response, documentation, customer-facing features) and marks, for each, the evidence that AI helps, the risk if it is wrong, and what measuring it would take. Initiatives start where evidence is strongest and risk is bounded. The map is revised as results come in, and it is the answer to "what is our AI strategy" that the organisation can be held to.

The bet sheet

Every initiative has a page: the hypothesis in one sentence, the measure and its baseline, the cost ceiling, the controls that must be in place, the checkpoint dates, and the condition for widening, narrowing or stopping. The page is written before the money is spent and read aloud at each checkpoint. An initiative that cannot fill in the page is not ready to start.

Sequencing

Initiatives proceed in an order that builds the foundations first: the data-handling policy and the review practice (AI-2 Governance, security and compliance, AI-4 Building AI-powered products) before the product feature that depends on them, measurement before the rollout it is meant to judge, and a small group before the whole organisation. A vendor's deadline does not change the sequence. If a discount requires skipping a stage, the discount is priced against the cost of being wrong at scale.

Measuring in local conditions

Each initiative is measured against a baseline on the outcomes the organisation cares about (cycle time, change failure rate, defect escape, customer resolution time), over long enough to see effects beyond novelty. Self-reported speed-ups are collected and not treated as the result. The measure is chosen before the initiative starts, so it cannot be chosen afterwards to fit.

Reporting upward

The manager reports each initiative in the organisation's own terms: what was tried, what the measure showed, what it cost, and what happens next. Where the result is uncertain, the report says so and gives the date of the next checkpoint. A board that is told "not yet, and here is when we will know" can plan; a board that is told what it hoped to hear cannot.

Stopping well

When an initiative misses its stop condition, it is narrowed or ended at the checkpoint, and the decision is announced with the evidence and what was learned. The people who ran it are credited for the evidence. An organisation that never stops anything is not running bets.

At team scope the question is which of the team's tasks benefit and how the team will know: a small bet on the team's own work, with its own measure. At organisational scope the object becomes the portfolio across teams: which initiatives to fund, in what order, on what evidence, with shared controls and measurement so that results are comparable, and with stopped initiatives as visible as started ones. At executive scope the object is the organisation's strategy and its claims: what it tells the board and the market about AI, how much it invests and from where, what it will and will not commit to on the strength of evidence it does not yet have, and how it keeps the option to change course as the technology and its price move (SV-3 Roadmapping, SV-4 Engineering economics).

• Chooses where to adopt from evidence about the team's own work, not from the market's enthusiasm. team
• Measures a team-level initiative against a baseline on outcomes, and treats self-reported speed-ups as a hypothesis. team
• Failure mode: adopting everywhere at once because the tool is available. team
• Frames each initiative as a staged bet with a hypothesis, a cost ceiling and a stop condition agreed in advance. org
• Sequences adoption so that controls and measurement are in place before scale. org
• Narrows or stops an initiative that misses its stop condition, and says so openly. org
• Keeps stopped initiatives as visible as started ones. org
• Failure mode: a pilot that runs indefinitely because nobody wrote down what success would look like. org
• Failure mode: letting a vendor's deadline set the sequence. org
• Failure mode: funding every initiative a little instead of a few properly. org
• Tells an executive what an AI investment can and cannot be expected to return, in the organisation's own terms. exec
• Treats a forecast figure as a choice among disputed estimates, not as a fact to plan around. exec
• Funds AI bets by visibly stopping something else. exec
• Failure mode: an AI strategy that is a list of tool purchases. exec
• Failure mode: committing to a return the organisation has never measured. exec

Learning versus waiting. Waiting for certain evidence means learning nothing while competitors learn; moving early means paying for evidence others will get cheaper. The judgment is to buy evidence deliberately, in bounded bets, where the organisation's own learning is worth more than the price.

Vendor terms versus the organisation's sequence. A discount that expires this month is designed to arrive before the pilot ends. The judgment is to price the discount against the cost of committing at scale before the evidence exists, and to walk away when the discount is smaller than the risk.

Enthusiasm versus evidence. Enthusiastic teams are an asset and a measurement hazard: they report the gains they feel. The judgment is to keep the enthusiasm and the measurement separate, and to let the measure decide.

Ambition versus survivability. A bet large enough to matter can be large enough to hurt. The judgment is to make each stage large enough to teach and small enough that being wrong is affordable, and to widen only on evidence.

A chief technology officer runs an engineering organisation of two hundred people. The chief executive has returned from a conference convinced that the company is behind, and a vendor has offered an organisation-wide licence for an agentic coding platform at forty per cent off, valid for three weeks. Two teams have trialled the platform for two months: one reports that it "changed everything", the other stopped using it after the first month. Nobody measured anything before the trials began. The board meets in five weeks and expects to hear the AI strategy.

The easy responses are to sign, because the discount is large and the chief executive wants momentum, or to decline, because the evidence is thin. Signing commits the organisation to a platform at full scale on the strength of one team's enthusiasm, with no controls agreed for what the agents may touch and no way to know in six months whether it helped. Declining tells the chief executive that engineering is resisting, and leaves the organisation with no evidence next quarter either.

The chief technology officer starts with what the trials can and cannot say. The enthusiastic team works on a young service with good tests; the team that stopped maintains an old system with few. That is consistent with what the research on uneven gains and the jagged frontier would predict, and it is a hypothesis, not a result. The CTO asks both teams to reconstruct cycle time and defect escape for the trial months against the months before; the numbers are noisy but suggest a modest gain on the young service and none on the old one.

The CTO then negotiates. The vendor is offered a paid six-month commitment for four teams chosen to span the kinds of work the organisation does, at the discounted rate, with an option for the full licence at the same rate if the checkpoint is met. The bet sheet states the hypothesis (agent-assisted work reduces cycle time on services with good tests by a measurable amount without raising change failure rate), the baseline, the cost ceiling, the agent permissions agreed with security, and two checkpoints. The money comes from a tooling budget line that is explicitly paused.

At the board, the CTO presents the adoption map, the bet, and the disagreement in the evidence, including the estimates that put the economy-wide effect far below the vendor's claims. A board member asks why the company is not moving faster. The CTO answers that it is moving at the speed of evidence, that the first checkpoint is in three months, and that the board will see the organisation's own numbers then. The vendor accepts the staged terms, because a referenceable customer with real data is worth more to it than a discount deadline. At the first checkpoint the gain on well-tested services holds and the old system shows nothing, so the licence widens to the teams whose work resembles the first, and the old system's team gets investment in tests instead.

• TJ-5 AI-assisted engineering: the baseline judgment about adopting AI assistance that this unit builds on.
• SV-3 Roadmapping: staged bets and checkpoints in strategy generally.
• SV-4 Engineering economics: the economics of building, buying or renting AI capability.
• AI-4 Building AI-powered products: the evaluation and cost discipline an AI product bet depends on.
• AI-6 Capability, roles and measuring impact: measuring impact honestly, and what adoption does to how people learn.

1. What does the jagged-frontier experiment imply for where an organisation should adopt AI first?
   Answer

   That the same tool can help on some tasks and harm on others within the same job, and the boundary is not visible in advance. Adoption should start where the work resembles tasks AI has been shown to help with, and be measured on the organisation's own work to find where the line falls.
2. What belongs on a bet sheet before an AI initiative starts?
   Answer

   The hypothesis, the measure and its baseline, the cost ceiling, the controls that must be in place, the checkpoint dates, and the conditions for widening, narrowing or stopping.
3. A vendor's discount expires before a pilot can finish. How should the decision be made?
   Answer

   By pricing the discount against the cost of committing at scale before the evidence exists, and by negotiating terms that fit the organisation's sequence, such as a staged commitment with an option at the same rate. A deadline is not a reason to skip the stage that produces the evidence.
4. A pilot has run for six months with enthusiastic reports and no measured change. What went wrong, and what now?
   Answer

   Nobody agreed a measure, a baseline or a stop condition at the start, so enthusiasm stood in for evidence. Reconstruct a baseline if possible, define the measure and a checkpoint now, and narrow or stop the pilot if the measure does not move.
5. How should a manager use economy-wide forecasts of AI's effect when talking to a board?
   Answer

   As evidence that serious estimates disagree by an order of magnitude, so any single forecast is a choice rather than a fact. The organisation's own measured results, with their uncertainty, are what the board should plan around.
6. Why is stopping an initiative described as a result?
   Answer

   Because a bet exists to produce evidence, and a stop on the evidence is that evidence used. Stopping openly, with what was learned, is what makes the next bet credible; an organisation that never stops anything is not running bets.

• Dell'Acqua et al. (2026): where AI helps and harms within the same job.
• Brynjolfsson et al. (2025): uneven productivity gains by experience.
• Becker et al. (2025): experienced developers slower with AI tools while believing they were faster.
• Cloud) (2024): AI adoption and delivery performance, as survey estimates.
• Acemoglu (2025): a modest estimate of AI's aggregate productivity effect.
• McGrath et al. (1995): planning ventures around tested assumptions.
• Narayanan et al. (2024): telling real capability from inflated claims.

Governance, security and compliance for AI is the set of decisions that keep an organisation's use of AI accountable and safe: what data may go to which tools and providers, what an AI system may be allowed to do, which uses need review and which can be left to teams, when a use falls into a regulated category, and who owns each system once it is running. The competency is the manager's judgment about those decisions. It is not the lawyer's, the security engineer's or the auditor's judgment, though it decides when each of them is brought in.

Core competency TJ-5 AI-assisted engineering asks a manager to govern AI in proportion to risk; TJ-6 Security, privacy, and compliance as engineering responsibilities asks them to own security and privacy as engineering work. This unit applies both to the specific risks AI brings: data that leaves the organisation in a prompt, systems that cannot tell instructions from content, models that can repeat what they were trained on, agents that act, and regulation written specifically for AI.

It matters because the failures are cheap to cause and expensive to undo. An engineer pastes customer records into a public chatbot to draft a reply; a support assistant reads an email that tells it to forward the conversation history; a screening feature quietly becomes a regulated system. Blanket bans are ignored and blanket permission is discovered in an incident. The examination tests the competency through customer data pasted into a public tool, an assistant with system access reading inbound email, and a question from legal about whether a new screening feature is high-risk.

1. Know where the data goes. For every AI tool and provider, know what is sent, where it is processed, whether it is kept or used for training, and who can see it. A decision about a tool is a decision about a data flow.
2. Untrusted content is untrusted instructions. Any system that passes outside content to a model, and lets the model act, can be steered by that content. Design for it before release.
3. Proportionate, not uniform. Make low-risk use easy and high-risk use reviewed. A policy that treats a documentation helper like a hiring system will be ignored where it matters least and followed where it matters most only by accident.
4. Recognise regulated uses early. Some uses, such as screening job applicants, carry legal obligations. Spot them at the idea stage and bring in legal or compliance then, not at launch.
5. Every AI system has a named owner. Keep an inventory of what is in use, what it does, what it touches and who answers for it, so that accountability survives a reorganisation or a change of vendor.
6. Govern with frameworks, not from scratch. Established frameworks give the questions; the organisation supplies the answers in proportion to its risk.

Prompt injection and excessive agency practice

Project (2025) names prompt injection as the first risk for applications built on language models, and lists sensitive information disclosure and excessive agency among the others. Excessive agency has three causes: more functionality than the task needs, more permissions than the functionality needs, and more autonomy than the system's reliability justifies. The list is a shared vocabulary rather than research, and its value to a manager is exactly that: it lets a design review ask named questions that a security team will recognise.

Indirect prompt injection research

Greshake et al. (2023) showed that when an application feeds a model content from outside (web pages, documents, emails), text planted in that content can steer the model, and demonstrated data theft and misuse of tools against real systems. The authors found effective mitigations lacking at the time. The governance consequence is structural: an assistant that reads untrusted input and can take actions needs its permissions limited to what a hostile input could safely trigger, with a person confirming anything consequential.

Training data extraction research

Carlini et al. (2021) recovered verbatim passages of training data, including personal information, from a language model by querying it, and found larger models more vulnerable. For an organisation the lesson runs in two directions. Data sent to a provider that trains on it may surface elsewhere, which is why data-retention and training terms matter when choosing a tool; and a model the organisation trains or fine-tunes on its own data can leak that data to its users.

Risk management frameworks practice

Technology (2023) organises AI risk management into four functions: govern (policies, roles and culture), map (the context and the risks of a given system), measure (assessing those risks) and manage (acting on them). ISO/IEC (2023) specifies requirements for an AI management system, on the same structure as the information-security management standard many organisations already run. Centre et al. (2023) gives security guidance across design, development, deployment and operation. None of them tells an organisation what to decide. They give a manager a defensible checklist of questions and a structure that auditors and customers recognise.

Risk-based regulation practice

Union (2024) regulates AI by risk. It prohibits some practices, imposes obligations on providers and deployers of systems it classes as high-risk, and sets lighter duties elsewhere. Its Annex III lists high-risk uses, and point 4 covers employment: systems for recruitment and selection, including filtering applications and evaluating candidates, and systems used for decisions on promotion, termination, task allocation and performance monitoring. The obligations apply in stages, and the timetable has been amended since publication, so any date must be checked against the current consolidated text before it is relied on. The manager's task is recognition, not interpretation: knowing that a use may fall into a category, and involving legal or compliance before building it.

The data-flow register

For each AI tool and provider in use, the organisation records what data classes may be sent, where processing happens, the retention and training terms, and who approved it. Engineers can see the register and know which tool to use for which data. The register replaces the question "may I use AI for this?" with "which approved tool handles this data?".

Proportionate policy

The policy sorts uses into a few tiers. Low-risk uses (help with documentation, explaining code, drafting internal text with no personal data) are allowed with approved tools and no further review. Medium-risk uses (generated code on production paths, customer-facing text) follow the review and disclosure rules of AI-3 AI-assisted software delivery. High-risk uses (anything that decides about people, touches regulated data, or acts on systems without confirmation) need a design review with security and, where relevant, legal. The policy fits on a page and is revisited as tools change.

Designing for injection and agency

Any system that reads outside content and can take actions gets a review against the named risks before release: what is the most damaging action a hostile input could trigger, and is that action allowed? Permissions are cut to the task, consequential actions need a person's confirmation, and outputs that go elsewhere (to a database, a browser, another system) are handled as untrusted. Incidents of this kind run through AI-5 Operating AI systems in production.

Recognising regulated uses

The intake for any new AI feature asks a few plain questions: does it make or support decisions about people (hiring, promotion, performance, access to services)? Does it process special categories of personal data? Is it sold into a regulated sector? A yes sends the idea to legal or compliance before design starts. The manager does not decide whether the use is high-risk under a regulation; they make sure someone qualified decides early.

The AI inventory

The organisation keeps a list of every AI system in use, built or bought: what it does, what data and systems it touches, its risk tier, its owner, and when it was last reviewed. The inventory is the first thing an auditor, a customer's security questionnaire or an incident responder will ask for, and the thing most organisations discover they do not have.

Choosing a framework

The organisation adopts one framework as its structure, usually the one its customers or auditors already expect, and maps its policy and inventory onto it. It does not run three frameworks in parallel, and it does not treat certification as a substitute for the decisions the framework asks it to make.

At team scope the object is the team's own use: which approved tools it uses for which data, how it reviews the AI systems it builds against injection and agency, and when it raises a use for wider review. The manager makes sure the team knows the policy and follows it without friction. At organisational scope the object becomes the policy itself, the data-flow register, the AI inventory and the intake that catches regulated uses, set once across teams and owned by named people. At executive scope the questions are accountability and exposure: who answers for the organisation's AI systems, how its governance would look to a regulator, a customer or a court, and whether the framework it has adopted is being lived or only certified (AI-1 Adoption strategy and staged bets).

• Traces where data goes when the team uses an AI tool, and decides what may be sent. team
• Reviews any system that reads untrusted content and can act, against the named injection and agency risks, before release. team
• Treats provenance and licensing questions about generated code as engineering risks with owners. team
• Failure mode: assuming a tool's data terms without reading them. team
• Failure mode: giving an assistant that reads email the ability to send it. team
• Sets AI policy in tiers, so low-risk use is easy and high-risk use is reviewed. org
• Recognises when a use may be regulated, such as screening job applicants, and involves legal or compliance at the idea stage. org
• Keeps a data-flow register and an AI inventory with named owners. org
• Adopts one recognised framework and maps policy onto it. org
• Failure mode: a blanket ban that engineers route around with personal accounts. org
• Failure mode: discovering at launch that a feature falls into a regulated category. org
• Failure mode: an inventory that lists the bought tools and forgets the ones the teams built. org
• Keeps accountability for AI systems with named people as teams and vendors change. exec
• Failure mode: treating certification as proof that governance is working. exec

Control versus adoption. Rules strict enough to remove the risk get worked around; rules loose enough to be followed leave risk behind. The judgment is proportion: easy paths for low-risk use, real review for high-risk use, and an approved tool for every common need, so that the workaround is never the easy option.

Speed to market versus regulatory review. Involving legal early feels like delay; involving them late can mean rebuilding. The judgment is to ask the regulated-use questions at the idea stage, when the answer costs a conversation rather than a redesign.

Agent capability versus attack surface. Every tool an assistant can use is a tool a hostile input can try to use. The judgment is to grant capability for the task and confirm consequential actions, accepting that some convenience is the price of not being steered.

Framework compliance versus real governance. A certificate is evidence a structure exists, not that its decisions are good. The judgment is to use the framework for its questions and to keep asking whether the answers are still true.

A director of engineering runs four product teams at a company that sells software to human-resources departments. A product manager proposes a feature that ranks job applicants by how well their CVs match a role, using a language model, and a large customer wants it within the quarter. At the same time, a security engineer reports that a support team has been pasting customer tickets, which include employee names and salary details, into a public chatbot to draft replies.

The easy responses are to build the ranking feature quickly, because the customer wants it, and to ban public chatbots outright. The first risks building a system that falls into a regulated category without anyone having asked, on data the company may not be allowed to use that way. The second will be obeyed for a week and then routed around, because the support team still has to answer tickets and now has no tool to help.

The director deals with the data flow first, because it is happening now. The security engineer confirms which provider the support team used and what its terms say about retention and training. The director asks for an approved assistant with enterprise terms (no training on inputs, a defined retention period, processing in the right region) to be made available to support within days, adds it to the data-flow register, and has the policy say plainly that customer data goes only to approved tools. The support team is told what happened and why, without blame; the gap was the absence of an approved option.

The ranking feature goes through intake. It ranks people for hiring, so the director asks legal before any design work. Legal's view is that a system that filters or evaluates job applicants is very likely high-risk under the EU regulation for the company's European customers, with obligations on the company as provider and on customers as deployers. The director takes that to the product manager and the customer with three options: build the feature with the controls and documentation the obligations require, on a longer timeline; build a narrower feature that helps recruiters search and read CVs without ranking or filtering people; or decline. The customer chooses the narrower feature for this quarter and the full feature on the longer timeline.

The narrower feature still reads documents uploaded by outsiders, so the design review covers injection: the model's output is shown to a recruiter, never acted on, and it has no tools. The feature, the support assistant and the provider are added to the AI inventory with owners. When the customer's procurement team later sends a security questionnaire about AI, the director answers it from the register and the inventory in an afternoon.

• TJ-5 AI-assisted engineering: the baseline judgment about governing AI assistance in proportion to risk.
• TJ-6 Security, privacy, and compliance as engineering responsibilities: security and privacy as engineering work, including data sent to tools.
• AI-1 Adoption strategy and staged bets: the adoption decisions that governance has to keep pace with.
• AI-3 AI-assisted software delivery: agent permissions and review rules in delivery.
• AI-5 Operating AI systems in production: running injections and data exposures as incidents.

1. An engineer asks whether they may use AI to draft replies to customer tickets. What question should the policy answer instead?
   Answer

   Which approved tool handles this data. The data-flow register records what data classes each approved tool may receive and on what terms, so the decision is about the data flow, not about AI in general.
2. An assistant reads inbound customer email and can look up and send account details. What is the risk, and what is the design response?
   Answer

   Indirect prompt injection: instructions planted in an email can steer the assistant into misusing its tools, for example sending data to an attacker. Cut its permissions to what a hostile input could safely trigger, require a person to confirm consequential actions, and treat its output as untrusted.
3. A product manager proposes using a model to rank job applicants. What should the manager do first?
   Answer

   Send it to legal or compliance before design starts. Systems that filter or evaluate job applicants appear in the EU AI Act's list of high-risk uses, and the manager's job is to recognise that and get a qualified view early, not to interpret the regulation.
4. Why does a blanket ban on public AI tools usually fail?
   Answer

   Because the work it was helping with still has to be done, so people route around the ban with personal accounts, and the risk moves out of sight. The effective response is an approved tool with acceptable terms for each common need, and a clear rule about which data goes where.
5. What does an AI inventory contain, and who needs it?
   Answer

   Every AI system in use, built or bought: what it does, what data and systems it touches, its risk tier, its owner and its last review. Auditors, customers' security questionnaires and incident responders all ask for it first.
6. What does a risk management framework give a manager, and what does it not?
   Answer

   A structured, recognised set of questions (for example govern, map, measure, manage) and a shape that auditors and customers understand. It does not make the decisions, and certification against it is not proof that the decisions are good.

• Project (2025): named risks, including prompt injection and excessive agency.
• Greshake et al. (2023): indirect prompt injection against real applications.
• Carlini et al. (2021): extracting training data from a language model.
• Technology (2023): the govern, map, measure and manage functions.
• ISO/IEC (2023): requirements for an AI management system.
• Centre et al. (2023): secure development of AI systems across the life cycle.
• Union (2024): risk-based regulation and its list of high-risk uses.

AI-assisted software delivery is the way a team writes, tests, reviews and ships code when assistants and coding agents produce much of it. The competency is the manager's judgment about the delivery system around that code: the conditions on which generated code is accepted, what an agent may touch, how review and testing change when code becomes cheap to produce, when an agent may work unattended, and how the team keeps understanding what it ships.

Core competency TJ-5 AI-assisted engineering establishes the baseline: adopt deliberately, ownership does not move, govern in proportion to risk. This unit is the next level down, where those principles meet the pipeline. It assumes the team already uses the tools and asks what has to change in the way work flows for the result to be safe and fast, not merely fast-looking.

It matters because the bottleneck moves. When code is expensive, writing it limits the pace and review keeps up. When code is cheap, review, testing and understanding become the constraint, and a team that does not adjust ships more change with the same checks, or fewer. The failures are quiet: a review queue nobody can clear, a test suite that passes because it was written to pass, an agent with credentials nobody meant it to have. The examination tests the competency through forty pull requests opened overnight, a review queue that tripled after rollout, generated tests that missed a production defect, and a request to give an agent merge rights.

1. Accept generated code on evidence, not fluency. Code is accepted when its author can explain it, it meets the usual review standard, and tests show it does what was required. Plausible-looking code is the default output of these tools and proves nothing.
2. Review capacity sets the pace. The rate at which the team can understand and check change is the real limit on delivery. Generation that outruns it borrows against the future.
3. A test must test the requirement. Tests written from the code assert what the code does. Tests written from the requirement assert what it should do. Generated tests drift towards the first kind unless someone insists on the second.
4. Give an agent only the permissions its worst mistake can afford. Decide repository, secret, network and merge access by the damage a wrong action could do, and contain the agent to match.
5. Unattended work is guarded work. An agent may work without a person watching only on tasks whose failure the pipeline will catch, behind checks that apply to every change whoever or whatever wrote it.
6. Understanding is a delivery asset. A team that can no longer debug or change its own code has lost speed it has not yet noticed losing. Protect the ability to explain the system as deliberately as the ability to ship it.

Technical primer

Coding tools work at three levels. Completion suggests the next lines as an engineer types. Chat answers a request with a block of code the engineer pastes and adapts. An agent takes a task, reads the repository, plans, edits files, runs commands and tests, reads the results and repeats until it judges the task done. Each level hands the tool more of the loop and the engineer less of it.

All three produce code that is statistically plausible given what they were shown: the files in their context, the request, the patterns of public code. Plausible is usually close to correct and sometimes subtly wrong, and the wrong cases look exactly like the right ones. An assistant has no stake in whether the code is secure, maintainable or consistent with decisions the team made last year, unless those decisions are in front of it.

An agent adds action to that. It runs with whatever access its environment grants: the repository, a shell, the network, credentials in environment variables, the ability to push a branch or merge one. Its mistakes are therefore not only wrong code but wrong actions, at machine speed. What an agent can do is decided by its environment, not by its instructions, which is why permissions and containment belong to the manager's decision and not to the prompt.

Security of assistant-written code research

Pearce et al. (2022) found that a substantial share of assistant-generated code in security-relevant scenarios contained known classes of vulnerability. Perry et al. (2023) ran a user study and found that participants with an assistant wrote less secure code than those without, and were more likely to believe their code was secure; participants who trusted the assistant less produced fewer vulnerabilities. Both used models now superseded, and the proportions will have moved. The management consequence has not: generated code is checked as a class, by scanning and review aimed at known failure modes, and confidence is not evidence.

AI and delivery performance contested

The evidence on whether assistants improve delivery points in different directions. Cloud) (2024) estimated from survey data that a 25% increase in AI adoption was associated with an estimated 1.5% reduction in delivery throughput and a 7.2% reduction in delivery stability, alongside faster code review and better documentation. Becker et al. (2025) found experienced developers slower with the tools in their own repositories, while believing they were faster. The first is an association across organisations, the second a small trial; neither settles the question. What is contested is the size and even the direction of the effect on delivery as a whole. The defensible position is to measure throughput and stability in the team's own conditions before and after, and to treat a felt speed-up as a hypothesis.

Generated tests and fault detection research

Schäfer et al. (2024) found that language models could generate unit tests reaching substantial statement coverage on real packages. Coverage measures which lines ran, not whether a test would fail if the code were wrong. Petrović et al. (2018) describes how Google made mutation testing practical at scale by mutating only the changed lines and showing surviving mutants in code review: a test that still passes after the code is deliberately broken is a test that checks nothing. Together they give a manager the right question about a generated suite. Not how much it covers, but what it would catch.

Excessive agency practice

Project (2025) names excessive agency as a distinct risk and gives it three causes: an agent with more functionality than its task needs, more permissions than its functionality needs, and more autonomy than its reliability justifies. Ruan et al. (2024) tested tool-using agents in emulated high-stakes environments and found that even the safest of them took risky actions in a substantial share of cases. The tools were emulated and the models date from 2023, so the figure is not a current rate. The structure of the risk is current: the three causes are three separate dials, and each is a decision.

Code review as understanding research

Bird (2013) found that developers expect code review to find defects, but that much of its value lies in knowledge transfer and shared awareness, and that understanding the change is the central difficulty. When an assistant writes the change, the author may understand it no better than the reviewer. Review then becomes the only point at which anyone on the team comes to understand the code, which is why its capacity, not the generator's, sets the safe pace.

The acceptance conditions

The team writes down, in a few lines, what any change must meet regardless of how it was produced: the author can explain what it does and why, it is small enough to review in one sitting, it passes the pipeline, and its tests were written against the requirement. Disclosure of assistance follows the organisation's policy (AI-2 Governance, security and compliance). The conditions apply to every change, so nobody has to decide whether a given line was generated.

Review when volume rises

The manager watches review load as a delivery metric: queue length, time to first review, size of changes. When generation raises volume, the response is to keep changes small, ask authors to explain their change before review, limit work in progress, and accept that some generated changes are not worth the review they need. The response is never to review faster by reviewing less.

Tests that test the requirement

For important behaviour, someone who understands the requirement writes or approves the test before trusting the code. Generated tests are welcome for breadth and are judged by what they would catch: mutation testing on the changed lines, or a deliberate fault introduced to see whether anything fails. A suite that reports high coverage and has never caught anything is treated as unproven.

Agent permissions

Agents get access in tiers. By default an agent reads the repository and writes to its own branch in a sandbox, with no production credentials and limited network access. Wider access is granted per task class, for a stated reason, by someone who owns the risk. Merge rights are not a default at any tier, because merging is the step at which a person accepts responsibility for the change.

Unattended work

An agent may run unattended on task classes whose failures are reversible and visible: dependency updates in a well-tested service, formatting, documentation, a defined migration with a test that proves it. Each class has its checks, a human checkpoint before merge, a limit on the number of changes it may open, and a way to stop it. Classes are added on evidence from supervised runs.

Pipeline checks for every change

Static analysis, dependency and secret scanning, and policy checks run on every change, so the safety of the pipeline never depends on who or what wrote the code. The checks are aimed at the failure modes generated code is known for, and are tuned so that they are trusted, not routinely overridden.

Protecting understanding

Periodically an engineer explains a recent change in their own area: how it works, what it assumes, what would break it. When the answers get thinner, the team is losing the understanding Bainbridge (1983) warned that automation erodes: the skill to step in is the one that decays when nobody practises it. The response is more review for understanding and deliberate time for engineers to work through the system themselves, including the early-career engineers whose learning AI-6 Capability, roles and measuring impact covers.

At team scope the object is the team's own pipeline: acceptance conditions, review load, the test suite, the agents the team runs and what they may touch. The manager sees the review queue and the test results directly and adjusts within days. At organisational scope the object is the delivery system across teams: shared pipeline checks, a common tiering of agent permissions, a rule that unattended task classes are approved on evidence, and a view of throughput and stability by team, so that one team's speed is not bought with another's incidents. At executive scope the question becomes whether AI-assisted delivery is improving outcomes for the organisation, measured on delivery and stability over quarters, and what the organisation is willing to let agents do without a person in the loop (DE-5 Designing how work flows).

• Sets acceptance conditions that apply to every change, however it was produced. team
• Treats review capacity as the pace-setter and adjusts change size and work in progress when volume rises. team
• Judges a test suite by what it would catch, not by its coverage. team
• Grants agent permissions by the damage a wrong action could do, and keeps merge as a human step. team
• Notices when engineers can no longer explain changes in their own area, and responds with review for understanding. team
• Failure mode: reviewing faster by reviewing less when the queue grows. team
• Failure mode: trusting a generated test suite because the coverage number is high. team
• Failure mode: giving an agent merge rights to save review time. team
• Failure mode: treating fluent code as evidence of correct code. team
• Approves unattended agent work by task class, on evidence from supervised runs, with a limit and a way to stop it. org
• Puts pipeline checks in place that apply to every change across teams. org
• Measures throughput and stability by team before and after adoption, and reads the results honestly. org
• Failure mode: a different, informal set of agent permissions in every team. org
• Failure mode: celebrating pull-request volume while change failure rate rises. org
• Decides how much the organisation will let agents do without a person in the loop, on measured outcomes. exec
• Failure mode: setting delivery targets that assume a productivity gain nobody has measured. exec

Throughput versus review capacity. Assistants raise the volume of change and review does not scale with it. The judgment is to let review capacity set the pace, make changes smaller and better explained, and accept that some generated work is not worth reviewing.

Agent autonomy versus blast radius. An agent that can do more saves more time and can do more damage. The judgment is to widen autonomy one task class at a time, on evidence, and to keep the irreversible steps, merging and deploying, with a person.

Coverage versus confidence. Generated tests make high coverage cheap, and coverage is easy to report. The judgment is to ask what the suite would catch, check it with deliberate faults, and keep human-written tests on the behaviour that matters most.

Speed today versus understanding tomorrow. Accepting code nobody fully understands is faster this sprint and slower every time it must be debugged or changed. The judgment is to treat understanding as part of done, and to measure it.

A team lead runs a team of six that owns a payments service. Three months ago the team started letting a coding agent handle dependency updates unattended: it opens a pull request for each update, the pipeline runs, and an engineer approves if the build is green. The arrangement has saved hours a week. Last Tuesday an update to a date-handling library changed how one function treated time zones, the agent adjusted two call sites and generated tests for them, the build was green, an engineer approved it between meetings, and for six hours some refunds were dated a day early. Finance caught it in reconciliation.

The easy responses are to stop the agent entirely, because it caused an incident, or to treat it as a one-off and remind engineers to read changes properly. The first throws away a practice that mostly works and teaches the team that the answer to a failure is to retreat. The second blames the engineer for a gap in the system: the arrangement asked a person to approve, in seconds, a change whose risk nobody had classified.

The team lead runs a blameless review. It finds three things. The generated tests asserted the new behaviour of the changed function, so they passed by construction; no test anywhere stated the requirement that a refund carries the date it was issued. Dependency updates had been treated as one task class, although a patch to a logging library and a behaviour change in a date library carry very different risk. And the human approval had become a formality, because nothing in the pull request told the engineer that this one was different.

The changes follow from the findings. The team writes requirement-level tests for the money paths, dates and amounts first, and adds mutation testing on changed lines in the payments module, so that a test which cannot fail is visible in review. Unattended updates continue for patch releases of libraries off the money path; anything that changes behaviour, or touches payments, now arrives with a summary of what changed in the library and needs a reviewer who owns that area. The agent loses nothing it needs and keeps the work it does well.

Two weeks later the agent opens a minor-version update to the same library. The summary flags a changed default. The mutation report shows a surviving mutant in the refund date logic, which the new requirement test catches. The engineer who reviews it understands why it is safe before approving it, which was the point of the review all along.

• TJ-5 AI-assisted engineering: the baseline judgment about AI assistance that this unit builds on.
• TJ-3 Code review and quality standards: the standards floor every change must meet, generated or not.
• DE-5 Designing how work flows: AI assistance as part of how work flows through the team.
• AI-2 Governance, security and compliance: the security, data and disclosure policy that agent permissions sit inside.
• AI-6 Capability, roles and measuring impact: protecting the learning of early-career engineers when assistants write the code.

1. Review time has tripled since the team adopted assistants. What is the wrong response, and what is the right one?
   Answer

   The wrong response is to review faster by reviewing less. The right one treats review capacity as the limit on safe delivery: smaller changes, authors who explain their change before review, limits on work in progress, and acceptance that some generated changes are not worth the review they need.
2. A generated test suite reports high coverage. What question should a manager ask about it?
   Answer

   What it would catch. Coverage says which lines ran, not whether a test would fail if the code were wrong. Mutation testing on changed lines, or a deliberately introduced fault, shows whether the tests check the requirement or merely assert what the code already does.
3. An engineer asks for an agent to have merge rights so it can fix flaky tests unattended. How should the request be judged?
   Answer

   By the damage a wrong merge could do. Merge is the step at which a person accepts responsibility for a change, so it stays human by default. The agent can open the fixes in its own branch with the pipeline checks applied, and a reviewer who owns the area approves them.
4. What do the security studies of assistant-written code imply for a team's process?
   Answer

   That generated code must be checked as a class, through scanning and review aimed at known vulnerability types, and that an engineer's confidence in the code is not evidence. One study found people using an assistant wrote less secure code and were more likely to believe it secure.
5. What are the three causes of excessive agency, and why does the distinction help a manager?
   Answer

   Too much functionality for the task, too many permissions for the functionality, and too much autonomy for the agent's reliability. Each is a separate decision, so a manager can narrow one without abandoning the agent.
6. On what kinds of task may an agent reasonably work unattended?
   Answer

   Task classes whose failures are reversible and visible, where the pipeline would catch a mistake: patch-level dependency updates in a well-tested service, formatting, documentation, a defined migration with a proving test. Each class needs its checks, a human checkpoint before merge, a limit and a way to stop it, and is approved on evidence from supervised runs.

• Pearce et al. (2022): vulnerabilities in assistant-generated code.
• Perry et al. (2023): less secure code, more confidence, with an assistant.
• Cloud) (2024): AI adoption and delivery throughput and stability, as survey estimates.
• Becker et al. (2025): experienced developers slower with AI tools while believing they were faster.
• Schäfer et al. (2024): coverage reached by generated unit tests.
• Petrović et al. (2018): mutation testing on changed lines in code review.
• Ruan et al. (2024): risky actions by tool-using agents in emulated environments.
• Project (2025): excessive agency and its three causes.
• Bird (2013): code review as understanding and knowledge transfer.
• Bainbridge (1983): automation and the erosion of the skills needed to step in.

Building AI-powered products is the work of putting a language model inside something customers use: a support assistant, a search that answers in sentences, a feature that drafts, classifies or summarises. The competency is the manager's judgment about that work. It covers which approach to take, how to know whether the product is good enough to ship and whether a change made it better or worse, how to design for a component that is sometimes wrong, what the product will cost at real volume, and how to depend on a model the team does not control.

Core competency TJ-5 AI-assisted engineering covers AI as a tool for building software; this unit covers AI as part of the software shipped. A wrong coding assistant costs a reviewer some time. A wrong product feature is wrong in front of a customer, at scale, in a phrasing nobody chose.

It matters because these products behave unlike most software. The same input can produce different outputs, quality is a distribution, a demonstration convinces long before the product is reliable, and the cost of each answer grows with use. Ordinary delivery instincts produce two characteristic failures: a launch date set by the demo, and a quality claim nobody can check. The examination tests this competency through a fine-tuning proposal for data that changes every week, a four-week deadline set after a board demonstration, a model bill that tripled after launch, and a provider withdrawing the model version a product depends on.

1. Choose the approach by what is wrong. Prompting, retrieval, fine-tuning and tool-using agents fix different problems. Start from the failure you need to remove, then choose the cheapest approach that removes it, and know what each choice makes harder to change later.
2. No evaluation, no change. A model, prompt or retrieval change ships only after it has been measured against a set of cases that represents real use. An opinion formed from a few impressive examples is not a measurement.
3. An evaluation set is a maintained asset. It goes stale as the product, the users and the world change. It has an owner, it is refreshed from real use, and its age is known.
4. Design for the wrong answer. Assume the model will sometimes be confidently wrong. Decide where that is tolerable, where a person must check, and how the product tells users what it does not know.
5. Price it at volume. Latency, unit cost and quality are one trade-off. Work out what the product costs at the usage you hope for before the launch makes that usage real.
6. Treat the model as a dependency you do not control. Pin the version, test before every upgrade, and keep the option to change provider in proportion to what being locked in would cost.

Technical primer

A language model produces text one fragment at a time, each chosen by probability from what came before. Everything the model knows about the task in front of it arrives in its context: the instructions, any documents supplied, the conversation so far. The context has a limit, and models do not use all of it equally well.

The four approaches change different things. Prompting changes the instructions in the context and nothing else. It is cheap to try and easy to undo. Retrieval searches a store of the organisation's own documents for each request and places the most relevant passages in the context, so the model answers from current material it was never trained on. Fine-tuning adjusts the model itself by further training on examples. It can shift tone, format and behaviour on a narrow task, but it is slow to change and must be repeated on each new base model. A tool-using agent lets the model call functions (search, query a database, take an action) and act on the results across several steps. It extends what the product can do, and with it what the product can get wrong.

Because the output is sampled, the same request can produce different answers, so quality is measured over many cases. And because the context is assembled at run time, which passages go into it, in which order, affects the answer as much as the model does.

Retrieval-augmented generation research

Lewis et al. (2020) combined a generative model with a retrieved index of documents and found answers that were more specific and more factual than the model alone, and that could be traced to the passages used. Ovadia et al. (2024) compared retrieval with unsupervised fine-tuning as ways to give a model new knowledge and found retrieval better for both familiar and new facts. That comparison does not cover supervised fine-tuning on worked examples, and it is often cited as if it did. Liu et al. (2024) found that models use information at the start and end of a long context better than information in the middle. Taken together, the management position is that knowledge which changes belongs in retrieval, behaviour and format may belong in fine-tuning, and a retrieval system is only as good as what it retrieves and where it puts it.

LLM-as-a-judge contested

Using one model to grade another makes evaluation cheap enough to run on every change. Zheng et al. (2023) found that a strong model judge agreed with human preferences about as often as humans agreed with each other: 85% against 81%, with ties excluded. The same study found the judge preferred whichever answer it saw first, and could be swayed by longer answers. It could not determine whether a model favours its own answers. What is contested is how far that agreement generalises beyond the tasks studied. A model judge is useful once checked against human grading on the product's own cases, and no substitute for that check.

Criteria drift research

Shankar et al. (2024) studied people building automated evaluations and found that they could not fully define their grading criteria before looking at outputs: grading outputs was how they discovered what they cared about. The first rubric will be wrong in ways only real outputs reveal, so the plan needs time for at least one revision before the numbers mean much.

Non-determinism in hosted models research

Atıl et al. (2025) ran identical requests against hosted models configured to be as deterministic as their settings allow, and found accuracy varying by up to 15% across runs, with no model consistent on every task. A single run of an evaluation is a sample. A difference of a few points between two versions may be noise, and a product that must give the same answer twice has to be designed to do so: by storing answers, by constraining output, or by not using a model for that step.

Model behaviour drift research

Chen et al. (2024) measured the same named model service three months apart and found large changes in behaviour, some tasks better and some much worse; on one task accuracy fell from 84% to 51%. A model reached by name through a provider is a moving dependency unless its version is pinned, and an upgrade changes the product whether or not the team's code changed.

Hidden technical debt in machine-learning systems practice

Sculley et al. (2015) argued that in a production machine-learning system the model is a small part of the whole, and that most of the long-term cost sits around it: data dependencies, entangled components, feedback loops and changes in the outside world. It predates language models but describes their products closely: the prompt, the retrieval index, the evaluation set and the pinned model version all need owners, versions and tests.

The approach decision

Before building, the team writes down the failure to remove, the approaches considered, their cost to build and run, and what each makes harder to change. Most products start with prompting and retrieval, which can be changed in a day. Fine-tuning is chosen for a stated reason (a format the model will not hold, a latency or cost target a smaller tuned model meets), never because it sounds more serious. An agent is chosen when the product must act, and its permissions are agreed with whoever owns the risk (AI-2 Governance, security and compliance).

The evaluation set

The team assembles cases from real use, including the hard and embarrassing ones, each with the answer or criteria a good response meets. It starts small and grows from production, where every complaint and surprising output is a candidate case. The set has an owner and a refresh date, and Huyen (2025) describes building the evaluation before the feature as evaluation-driven development. A model judge is used only for criteria where it has been compared with human grading on these cases.

Shipping a change

Every change to the model, the prompt or the retrieval index runs against the evaluation set, several times where variation matters, and is compared with the current version on the same cases. The decision rule is agreed in advance: what improvement justifies the change, and what regression on which kind of case blocks it. The change then ships the way any risky change does, behind a flag or to a share of traffic first, with a way back. AI-5 Operating AI systems in production covers running it once it is live.

Designing for failure

For each kind of output the team decides what a wrong answer costs. Where the cost is low, the product answers and makes correction easy. Where it is high, a person reviews before the answer takes effect, or the product declines. The interface says what the answer is based on, and what the product cannot do. A feature that always sounds certain trains users to stop checking.

The cost model

Before launch, the team estimates cost per request, requests per user and users at planned volume, compares the result with what the feature earns or saves, and identifies the levers: a smaller model for easy cases, shorter contexts, caching, limits per user.

The model dependency

The product names a specific model version, not a model family. Upgrades are planned work, run through the evaluation set, never automatic. The team knows the provider's deprecation policy, keeps prompts and evaluation sets portable enough that a second provider could be tested in weeks, and decides openly how much of that portability is worth paying for (SV-4 Engineering economics).

At team scope the object is one product: the approach, the evaluation set, the failure design and the cost model for a feature the team owns. The manager makes sure evaluation exists before changes ship, and holds launch dates to the evidence. At organisational scope the object becomes the practice across products: shared evaluation tooling, a common rule that model and prompt changes are production changes, a view of model cost across teams, and one position on providers instead of each team negotiating its own lock-in. The organisational manager also sets delivery expectations upward, because the gap between demonstration and reliable product is where most AI commitments fail (DE-2 Estimation, planning, and honest commitments). At executive scope the object is the portfolio: which products justify their running cost, how dependent the organisation is on one provider, and how the strategy holds up if prices, models or regulation change (AI-1 Adoption strategy and staged bets).

• Chooses between prompting, retrieval, fine-tuning and an agent by the failure to be removed and the cost of each, and can say what each choice makes harder to change. team
• Requires an evaluation set that represents real use before a model or prompt change ships. team
• Keeps the evaluation set refreshed from production and knows how old it is. team
• Reads an evaluation result with its limits in view: run-to-run variation, a model judge that has not been checked against people, a set that no longer matches the users. team
• Designs the product around wrong answers: where to answer, where a person checks, where to decline. team
• Failure mode: proposing fine-tuning to give a model knowledge that changes every week. team
• Failure mode: judging a change from a handful of impressive examples. team
• Failure mode: treating one evaluation run as a precise measurement. team
• Prices the product at the volume the plan expects before launch, and knows which levers move the cost. org
• Manages model choice as a dependency: pinned versions, tested upgrades, portability proportionate to the lock-in risk. org
• Sets delivery expectations that allow for the distance between a demonstration and a reliable product. org
• Establishes across teams that a model, prompt or retrieval change is a production change. org
• Failure mode: a launch date set by the demonstration. org
• Failure mode: a model referenced by family name, upgraded silently by the provider. org
• Failure mode: discovering the unit cost from the first month's invoice. org
• Decides which AI products justify their running cost, and how much dependence on one provider the organisation will accept. exec
• Failure mode: an AI product portfolio whose total cost nobody has added up. exec

Demonstration versus product. A convincing demonstration takes days and a reliable product takes months, and the demonstration is what the stakeholders saw. The judgment is to show the evaluation results beside the demonstration from the first meeting, so that the date is set by evidence, and to say early how the last share of quality will be paid for.

Evaluation versus speed. Building and maintaining an evaluation set feels like delay when the team could be shipping. Without it, every change is a guess and every regression is found by customers. The judgment is to start with a small set immediately and grow it from production, rather than wait for a complete one or skip it.

Automated grading versus human judgment. A model judge makes evaluation cheap and fast, and it has biases. Human grading is trustworthy and slow. The judgment is to check the automated grader against people on the product's own cases, use it where it agrees, and keep people for the criteria where it does not.

Convenience versus lock-in. One provider's full platform is the fastest way to build, and the hardest to leave. The judgment is to decide how much portability is worth paying for, given what a forced migration would cost, and to keep at least the prompts and evaluation sets portable.

An engineering director at a business-software company runs three product teams. Sales has promised a large customer an assistant that answers questions about the customer's contracts, and the chief executive showed a prototype to the board, where it answered five questions well. The board expects launch in six weeks. The team lead proposes fine-tuning a model on the customer's contract archive, which grows by several hundred documents a month. Quality so far has been judged by the product manager trying a dozen questions. Nobody has estimated the cost at the customer's expected usage.

The easy responses are to accept the date and the plan because the board saw it working, or to refuse the date. The first commits the company to unmeasured quality built on an approach that fixes the wrong problem. The second hands the decision to people with less information than the director.

The director starts from what is wrong. The customer's contracts change monthly, so the knowledge belongs in retrieval, where a new document is searchable the day it arrives. Fine-tuning on the archive would bake in a snapshot and need repeating, and the evidence for fine-tuning as a way of adding knowledge is weak. The team keeps fine-tuning in reserve in case the model will not hold the citation format the customer needs. The director then asks for an evaluation set before any further building: two hundred real questions collected with the customer's legal team, with the clauses a correct answer must cite, including questions the contracts do not answer, where the right response is to say so. The product manager's dozen questions become the first twelve cases.

The first evaluation run shows the retrieval prototype answering well on simple lookups and badly when the answer spans two documents, and occasionally inventing a clause. The director takes that to the chief executive with three things: the measured results, a cost per question at the customer's expected volume (which is affordable with a smaller model for simple lookups), and a staged plan. In six weeks, the customer gets the assistant for single-document questions, with every answer linked to the clauses it used and a clear refusal when no clause applies. Questions across documents follow when the evaluation shows they are reliable, with a date set by that evidence.

The chief executive dislikes telling the board the launch is narrower than the demonstration suggested, but accepts the director's case: a narrow product that cites its sources will be trusted, and a broad one that sometimes invents a clause will lose the customer. The model version is pinned, and the evaluation set gates every later change.

• TJ-5 AI-assisted engineering: the baseline judgment about AI assistance that this unit builds on.
• AI-1 Adoption strategy and staged bets: whether an AI product is the right bet at all, and when to stop.
• AI-2 Governance, security and compliance: the security and data risks of what the product sends to a model and lets it do.
• AI-5 Operating AI systems in production: running the product once it is live, including incidents and drift.
• SV-4 Engineering economics: the AI service as a build, buy or rent decision, and the economics of lock-in.
• DE-2 Estimation, planning, and honest commitments: honest commitments when the work is uncertain.

1. A product manager proposes fine-tuning a model so that it can answer questions about prices that change every week. What is the better approach, and why?
   Answer

   Retrieval, which puts current documents in the model's context at request time. Fine-tuning would fix a snapshot that needs repeating with every change, and the evidence for it as a way of adding knowledge is weak. It suits behaviour and format better.
2. Two versions of a prompt score 81% and 83% on a single run of the evaluation set. What should the team conclude?
   Answer

   Nothing yet. Hosted models vary from run to run even with deterministic settings, so a two-point difference from one run may be noise. Run each version several times on the same cases, look at the spread, and look at which kinds of case changed, before deciding.
3. When is it reasonable to use one model to grade another's output?
   Answer

   When the automated judge has been checked against human grading on the product's own cases and agrees on the criteria in question. Model judges can approach human agreement on some tasks but show biases, such as favouring the first answer shown or longer answers, so they are an instrument to calibrate, not a substitute for human judgment.
4. Why should the first version of an evaluation rubric be expected to change?
   Answer

   Because people discover what they care about by grading real outputs (criteria drift). Criteria written before looking at outputs miss failures nobody anticipated, so the plan should include reviewing real outputs and revising the rubric before relying on the numbers.
5. A team references its model by family name and lets the provider update it. What is the risk, and what is the practice?
   Answer

   The behaviour of a named model service can change substantially between versions, so the product can change without any change to the team's code. Pin a specific version, treat upgrades as planned changes run through the evaluation set, and know the provider's deprecation policy.
6. What should be known about cost before an AI feature launches?
   Answer

   The cost per request, the expected requests per user and the number of users at the volume the plan hopes for, compared with what the feature earns or saves, plus the levers that reduce cost: smaller models for easy cases, shorter contexts, caching and usage limits.

• Lewis et al. (2020): retrieval-augmented generation and traceable answers.
• Ovadia et al. (2024): retrieval against unsupervised fine-tuning for adding knowledge.
• Liu et al. (2024): how models use long contexts.
• Zheng et al. (2023): agreement and biases of model judges.
• Shankar et al. (2024): criteria drift in building evaluations.
• Atıl et al. (2025): run-to-run variation in hosted models.
• Chen et al. (2024): behaviour change in a named model service over time.
• Sculley et al. (2015): where the cost of a machine-learning system sits.
• Huyen (2025): evaluation-driven development and choosing the approach.

Operating AI systems in production is the work of running a product that depends on a language model once real users rely on it: knowing whether it is still behaving well, changing it safely, responding when it goes wrong, keeping its cost under control, and noticing when the world it serves has moved. The competency is the manager's judgment about that operation.

Core competency DE-3 Reliability, incident response, and operational ownership covers reliability and incidents for any service, and this unit inherits all of it: service-level objectives, on-call, blameless review. What changes with AI is the shape of failure. A conventional service fails loudly: it errors, times out, falls over. An AI feature usually fails quietly. It answers, promptly and fluently, and the answer is wrong, or harmful, or quoting a document it should never have seen. Every availability dashboard stays green.

It matters because users and courts treat what the product says as what the company says. In Tribunal (2024), a tribunal held an airline responsible for its website chatbot's misstatement of a fare policy and called the suggestion that the chatbot was responsible for its own words "a remarkable submission". The decision is a small-claims ruling and binds no one, but its reasoning is the one a manager should plan for. The examination tests the competency through a confidently false answer shared publicly, a provider outage that takes the main feature down, a prompt changed in a dashboard without review, and a cost alert fired by an agent calling a model in a loop.

1. Watch quality, not only uptime. An AI feature can be available and wrong. Instrument it for the quality, safety and cost of its answers as well as for whether it responds.
2. A model, prompt or index change is a production change. Anything that changes what the product says goes through testing, staged rollout and a way back, whoever made it and wherever it was made.
3. An AI incident is an incident. A false or harmful output at scale, an injection, a runaway cost: each gets the same discipline as an outage, including containment, communication and a blameless review.
4. Fail safe, not silent. Decide in advance what the product does when the model or provider fails or misbehaves, and make sure someone can switch the feature off in minutes.
5. Cap the cost before it caps you. Budgets, alerts and limits go in before launch, because a model bill can grow faster than anyone reads an invoice.
6. Evaluate again when the world moves. The users, the documents and the model all change. Know what the system was evaluated on, notice when production no longer looks like it, and evaluate again.

Technical primer

Several things can change an AI feature's behaviour without anyone changing its code. The model: a provider may update a model behind a name, or retire a version. The prompt: often edited in a configuration file or a vendor's dashboard, outside the code review that guards everything else. The retrieval index: when documents are added, removed or re-processed, what the model sees changes. The inputs: users ask new things, in new ways, and some of them are adversarial. The provider's infrastructure: latency, rate limits and outages are someone else's operations.

A request that returns a fluent but wrong answer looks, to ordinary monitoring, exactly like a good one: a successful response in normal time. Quality therefore has to be measured directly. The usual signals are a sample of real answers graded by people or by a checked automated judge, user feedback and escalations, the rate at which the product declines or hands over to a person, the documents retrieved for each answer, the number of tool calls or steps an agent takes, and tokens and cost per request. None of these comes free with a standard monitoring stack; each is a decision.

Service-level objectives and error budgets practice

Beyer et al. (2016) describes setting explicit objectives for a service and treating the gap between the objective and perfection as a budget to spend on change. For an AI feature the practice carries over with one extension: the objectives include quality as well as availability and latency, for example the share of sampled answers judged correct and the share that cite a source. When quality burns through its budget, the response is the same as for availability: slow down change and fix the cause.

Production as the place models are understood research

Shankar et al. (2024) interviewed engineers who run machine-learning systems and found that teams do not know how a model will behave until it meets production, and that successful operation is a continual loop of validation, versioning and monitoring rather than a launch followed by maintenance. The finding predates most language-model products, but it describes them well: the evaluation before launch is the start of knowing how the product behaves, not the end.

Distribution shift and model drift research

Huyen (2022) describes how the data a system meets in production moves away from the data it was built and evaluated on, and why monitoring must look for that movement. Language-model products add a second source of drift: the model itself. Chen et al. (2024) found that the behaviour of the same named model service changed substantially within three months. A product therefore drifts from both ends, its users and its model, and needs evaluation that is repeated, not only performed once.

Indirect prompt injection research

Greshake et al. (2023) showed that applications which feed a model content from outside, such as retrieved documents, web pages or emails, blur the line between data and instructions: text planted in that content can steer the model, including towards leaking data or misusing its tools. For operations this means that the retrieval index and every external input are part of the attack surface, and that an injection is an incident with a security owner (AI-2 Governance, security and compliance, TJ-6 Security, privacy, and compliance as engineering responsibilities).

Unbounded consumption practice

Project (2025) names unbounded consumption as a risk: inference that is excessive or uncontrolled, whether from abuse, a loop or a design that never anticipated the volume, leading to degraded service and economic loss. It is the AI form of a capacity problem, with a difference that matters to a manager. The failure shows up first on a bill, not on a latency graph.

Quality monitoring

The team samples real answers every day and grades them, by people or by an automated judge that has been checked against people (AI-4 Building AI-powered products). It tracks feedback, escalations and the rate of declined or handed-over requests, and sets objectives for quality beside availability. A drop in quality pages someone in the same way an outage would.

Changing the system

The model version, the prompt, the retrieval configuration and the index-building pipeline are all versioned and changed through review. A change runs against the evaluation set, then ships to a share of traffic with its quality signals watched, with a way back that has been tested. Prompts are not edited in a dashboard by whoever has access; where a vendor dashboard is the only place to change them, access is restricted and every change is logged and reviewed.

The AI incident

The team defines in advance what counts as an incident: a false or harmful answer seen by users at scale, a confirmed injection, data shown to the wrong person, a cost spike. The first action is containment: switch the feature to its fallback, disable a tool, or turn it off. The second is the record: users who received a wrong answer that could cost them are told and the error is put right, because the company owns what its product said. The review that follows is blameless in the sense of Allspaw (2012): it asks how the system allowed the failure, and accountability attaches to fixing that system.

Fallbacks and the kill switch

Each AI feature has a defined fallback: a simpler rule, a search without generated answers, a hand-off to a person, or a clear message that the feature is unavailable. A flag can switch to it in minutes without a deploy, and the switch is tested. Where possible a second provider or model has been tried against the evaluation set, so that a long outage has an answer beyond waiting.

Cost controls

Before launch the team sets a budget per feature, alerts well below it, limits per user and per tenant, and, for agents, a maximum number of steps and tool calls per task. Cost per request is on the same dashboard as latency. A cost alert is treated as a possible incident, not an accounting matter, because a loop or an abuse pattern looks the same on a bill as success does.

Evaluating again

The team knows what the system was evaluated on and when. It re-runs the evaluation on a schedule, after any model or index change, and whenever the monitoring shows production moving away from the evaluation set: new kinds of questions, new documents, a change in declined requests. New production failures become evaluation cases.

At team scope the object is one feature in production: its quality signals, its change process, its fallback and its budget. The manager makes sure someone is watching quality and can switch the feature off, and runs incidents with the team. At organisational scope the object becomes the operating practice across AI features: one definition of an AI incident, shared tooling for sampling and grading answers, a rule that model and prompt changes are production changes everywhere, a cost view across teams and providers, and on-call that knows what to do when a provider fails. At executive scope the questions are exposure and accountability: what the organisation's AI features are saying to customers, who is answerable for it, how much the organisation depends on any one provider, and whether its incident record would stand up in front of a regulator or a court.

• Instruments an AI feature for quality, safety and cost as well as availability. team
• Puts model, prompt and index changes through review, staged rollout and a tested way back. team
• Runs an AI-specific failure as an incident: contain, correct the record with users, review blamelessly. team
• Designs a fallback and a kill switch that work in minutes without a deploy. team
• Treats a confirmed prompt injection as a security incident with an owner. team
• Failure mode: green availability dashboards taken as evidence the feature is working. team
• Failure mode: prompts edited in a vendor dashboard by anyone with access. team
• Failure mode: treating a wrong answer as a support ticket rather than an incident. team
• Sets budgets, alerts and limits before launch, including step limits for agents. org
• Establishes one definition of an AI incident and one change rule across teams. org
• Re-evaluates when production drifts from what the system was evaluated on. org
• Failure mode: learning the unit cost from the first month's invoice. org
• Failure mode: no plan for a long provider outage beyond waiting. org
• Knows what the organisation's AI features say to customers and who answers for it. exec
• Failure mode: assuming the vendor is responsible for what the product tells customers. exec

Quality monitoring versus cost. Grading real answers takes people's time or a judge's tokens, and it is tempting to sample too little to see anything. The judgment is to sample enough to detect the failures that matter most, weighted towards the answers with the highest stakes.

Change speed versus control. Prompts are easy to change, and a fix is often one sentence away. The same ease lets an untested edit reach every user at once. The judgment is to keep the edit easy and the release controlled: review, evaluation and staged rollout, fast enough that nobody is tempted to bypass them.

Availability versus correctness. Keeping a feature up feels like success, and switching it off feels like failure. A feature that is up and wrong is worse than one that is clearly unavailable. The judgment is to decide in advance at what point the fallback is the better product.

Provider dependence versus resilience. One provider is simpler to build on and to operate. A second is insurance with a running cost. The judgment is to buy as much resilience as the cost of a long outage justifies, and to have tested it.

A team lead runs the team that owns the help assistant on a software company's customer site. It answers questions from the public help centre, which the team re-indexes nightly. On a Monday morning, support reports several customers quoting a refund rule that does not exist: the assistant is telling them that annual plans can be refunded in full within sixty days. The real policy is thirty days. Availability and latency dashboards are normal.

The easy responses are to treat it as a content error, ask the help-centre team to fix the article and move on, or to switch the assistant off indefinitely until someone can promise it will never happen again. The first leaves customers holding a promise the company made and has not corrected, and fixes nothing about how it happened. The second removes a feature most customers use well because of a failure nobody has yet understood.

The team lead declares an incident. Within the hour the team switches the assistant to its fallback, search results without generated answers, and confirms the false answer is no longer being given. Support pulls the conversations from the weekend in which the assistant gave the sixty-day rule, and the company contacts each customer, honours the refund for those who acted on it, and corrects the record for the rest. Nobody suggests that the assistant, not the company, made the promise.

The blameless review finds the cause. A draft policy page, written for a promotion that never launched, was published to the help centre with a hidden flag the indexing pipeline ignored. The nightly index picked it up, and the assistant retrieved it because it matched refund questions better than the real page. Nothing in the pipeline compared what the assistant said before and after an index change, and nothing in monitoring sampled answers about money.

The fixes follow. The indexing pipeline honours the hidden flag and logs every document added or removed. An index change now runs the evaluation set before it goes live, and the set gains cases on refunds, cancellations and pricing, the answers that cost the most when wrong. Daily sampling is weighted towards those topics, with an alert on any answer that cites a page published in the last day. The assistant returns to service on Wednesday. The team lead writes the incident up for the wider organisation, because the help centre is not the only team whose documents feed a model.

• TJ-5 AI-assisted engineering: the baseline judgment about AI assistance that this unit builds on.
• DE-3 Reliability, incident response, and operational ownership: reliability, incident response and operational ownership for any service.
• TJ-6 Security, privacy, and compliance as engineering responsibilities: security and privacy, including the data an AI feature can expose.
• AI-2 Governance, security and compliance: the governance and security policy that injections and data exposure fall under.
• AI-4 Building AI-powered products: the evaluation set and the design decisions that operation depends on.

1. Why are availability and latency dashboards not enough for an AI feature?
   Answer

   Because an AI feature usually fails by answering wrongly, promptly and fluently, which looks like success to availability monitoring. Quality has to be measured directly: sampled and graded answers, feedback and escalations, declined requests, retrieved documents and cost per request.
2. A prompt was changed in a vendor dashboard without review and complaints rose the next day. What practice was missing?
   Answer

   Treating the prompt as part of the production system: versioned, changed through review, run against the evaluation set, rolled out to a share of traffic with its quality watched, and reversible. Where a dashboard is the only place to change it, access is restricted and every change is logged and reviewed.
3. The product gave customers a false statement of policy. What are the first two actions?
   Answer

   Contain it, by switching to the fallback or turning the feature off, and correct the record with the customers who received the answer, because the company is responsible for what its product said. The blameless review follows.
4. What makes an application that retrieves outside content vulnerable to prompt injection, and what follows for operations?
   Answer

   Retrieved content and instructions reach the model together, so text planted in that content can steer it. The index and every external input are part of the attack surface, and a confirmed injection is a security incident with an owner.
5. What cost controls belong in place before launch?
   Answer

   A budget per feature with alerts below it, limits per user and per tenant, step and tool-call limits for agents, and cost per request on the same dashboard as latency, with a cost alert treated as a possible incident.
6. When should a team evaluate a production AI feature again?
   Answer

   On a schedule, after any model, prompt or index change, and whenever monitoring shows production moving away from what the system was evaluated on. New production failures become evaluation cases.

• Beyer et al. (2016): service-level objectives, error budgets and incident management.
• Shankar et al. (2024): how engineers learn model behaviour in production.
• Chen et al. (2024): behaviour change in a named model service.
• Huyen (2022): distribution shift and monitoring.
• Greshake et al. (2023): indirect prompt injection through retrieved content.
• Project (2025): unbounded consumption.
• Allspaw (2012): blameless review and accountability.
• Tribunal (2024): a company held responsible for its chatbot's statement.

This competency is the manager's judgment about people in an organisation that uses AI: how the team builds the skill to use it well, how early-career engineers keep learning when the tools do the work they used to learn from, how candidates and engineers are assessed fairly when assistance is everywhere, how the effect of AI is measured honestly, and how its effect on roles and headcount is discussed without false promises in either direction.

Core competency TJ-5 AI-assisted engineering asks a manager to build capability rather than count licences and to measure in their own conditions. This unit takes those two duties further, into the decisions that shape careers: who learns what, who gets hired on what evidence, what is claimed about productivity, and what people are told about their jobs.

It matters because the effects on people arrive slowly and are hard to reverse. A team that stops practising a skill does not notice until it needs it. A cohort of juniors that never learned to debug is a staffing problem three years later. A productivity claim built on how fast people feel becomes a headcount plan nobody can deliver. The examination tests the competency through a plan to hire a third fewer engineers on the strength of AI, early-career engineers who ship changes they cannot explain, a survey that says engineers feel twice as fast while delivery has not moved, and a team asking whether their jobs are safe.

1. Capability is built, not bought. A licence gives access, not skill. Teams learn to use AI well through practice, shared conventions and time set aside to learn, and the manager plans for that like any other capability.
2. Protect how early careers learn. When assistants do the tasks juniors used to learn from, the learning has to be put back on purpose: work they do unaided, review that asks them to explain, and problems chosen to teach.
3. Assess the judgment, with clear rules. In hiring and in performance, assess what the person can reason through, under rules about assistance that are stated in advance and applied to everyone.
4. Measure outcomes, not feelings. Self-reported speed-ups are not a measure. Measure outcomes in the team's own conditions, over long enough to see beyond novelty, across more than one dimension of productivity.
5. Hold contested claims as contested. The evidence on AI and productivity disagrees with itself. Say so, rather than citing the study that suits the decision.
6. Be honest about roles and headcount. Say what the organisation knows and does not know about AI's effect on jobs, and promise nothing it cannot keep, in either direction.

Gains concentrated among the less experienced research

Brynjolfsson et al. (2025) found that an assistant raised customer-support productivity on average, with the largest gains for the least experienced agents and little for the most experienced. The study is in customer support, and its relevance to engineering is a question to test rather than a given. Its management consequence is double-edged: the people who gain most in output are the people whose learning is most at stake.

Assistance and learning research

Bastani et al. (2025) ran a field experiment in which students practised with an AI assistant. An unrestricted assistant improved their practice performance and harmed their performance once it was taken away; an assistant designed to give hints rather than answers largely avoided the harm. The study is of school students, not engineers, and its lesson transfers as a mechanism rather than a number: when the tool supplies the answer, the learner can perform without learning, and the design of the assistance decides which happens.

Confidence and critical thinking research

Lee et al. (2025) surveyed knowledge workers about tasks they did with generative AI and found that greater confidence in the tool went with less critical thinking, and greater confidence in their own ability went with more. The data are self-reported, so the study shows an association in how people describe their work, not a measured decline. It is still a useful warning about where review effort goes when the tool is trusted.

Measuring developer productivity practice

Forsgren et al. (2021) argued that developer productivity has several dimensions (satisfaction and well-being, performance, activity, communication and collaboration, efficiency and flow) and that no single metric captures it. Becker et al. (2025) adds a specific warning for AI: experienced developers in a randomised trial were slower with the tools while believing they were faster. Together they define an honest measurement of AI's effect: outcomes across several dimensions, against a baseline, with self-report collected and not trusted on its own.

Structured assessment research

Hunter (1998) synthesised decades of research on selection methods and found structured interviews among the strongest predictors of job performance. The finding predates AI and matters more because of it: when candidates can use assistants for take-home work, a structured conversation about how they reasoned, what they would check and what could go wrong is harder to outsource and closer to the judgment the job needs (PL-3 Hiring and onboarding).

Labour-market effects contested

The evidence on AI and jobs disagrees. Eloundou et al. (2024) estimated how many occupations' tasks are exposed to language models, which is a measure of potential, not of jobs lost. Humlum et al. (2025) used administrative data from Denmark and found effects of AI chatbots on earnings and hours close to zero, ruling out effects larger than 2% two years on. Brynjolfsson et al. (2025), a working paper, found early-career workers in the most exposed occupations falling behind their less exposed peers in employment. What is contested is whether, where and how fast AI changes employment. A manager talking to a team about their jobs should know that the honest answer is uncertain, and that the early signs, where there are any, concern the start of careers.

Building capability

The team sets aside regular time for engineers to share what works and what does not: which tasks the tools help with, how to check what they produce, conventions for prompts and for review. Fluency is treated as a skill with a learning curve, so the manager expects the first months to be slower for some, and does not judge the tools or the people on that period alone.

Early-career development

Junior engineers do some work unaided, chosen because it teaches: debugging, reading unfamiliar code, writing a design before asking for one. In review they explain their changes, generated or not, and a senior engineer probes the reasoning, not only the result. Assistance for juniors is set up to explain and hint rather than to hand over answers where learning is the point. The manager watches for the signal that matters most: a junior who ships quickly and cannot explain what shipped.

Assessing people

Hiring states its rules on assistance in advance: what candidates may use, in which parts of the process, and what is assessed. Structured interviews probe reasoning, trade-offs and what the candidate would check. Performance assessment looks at outcomes and judgment, not at volume of output, which assistants inflate. The same rules apply to everyone, so that nobody is advantaged or penalised for using, or declining to use, the tools.

Measuring impact

Before an adoption, the team records a baseline on outcomes: cycle time, change failure rate, rework, incident trends, and a short survey of satisfaction and flow. After, it measures the same things over at least a quarter. Self-reported speed is collected alongside and reported separately. The result is reported upward with its uncertainty, and with the outcome measures leading (SV-5 Engineering metrics and measurement).

Talking about roles and headcount

When leadership raises headcount, the manager brings the organisation's own measured results, the state of the external evidence, and a plan that lets any change follow the evidence instead of running ahead of it. When the team asks whether their jobs are safe, the manager says what is known and what is not, what the organisation has decided and what it has not, and does not offer a guarantee they cannot keep.

At team scope the object is the team's own skill, its juniors, and the honesty of its measurement: time to learn, unaided work that teaches, explanation in review, a baseline before adoption. At organisational scope the object becomes the system across teams: hiring rules on assistance that are consistent, a career framework that still develops the skills AI erodes, a shared method for measuring AI's effect, and a manager-of-managers who notices when one team's juniors are learning and another's are not (PL-5 Career development and growth paths). At executive scope the questions are the workforce plan and the organisation's word: what it commits to on headcount, on what evidence, how it keeps a pipeline of future senior engineers when the entry-level work is changing, and what it says publicly and internally about AI and jobs (AI-1 Adoption strategy and staged bets).

• Builds the team's AI capability through practice, shared conventions and time to learn. team
• Gives early-career engineers unaided work that teaches, and asks them to explain their changes in review. team
• Assesses candidates and engineers on judgment, under assistance rules stated in advance. team
• Measures AI's effect on outcomes against a baseline, and reports self-reported speed separately. team
• Failure mode: counting licences or active users as capability. team
• Failure mode: praising a junior's output without checking they can explain it. team
• Protects the learning of early-career engineers across teams, in the career framework and in how assistance is set up. org
• Keeps hiring rules on assistance consistent across teams. org
• Holds contested productivity evidence as contested in what it reports upward. org
• Failure mode: a productivity claim built on a survey of how fast people feel. org
• Failure mode: take-home tests that the assistant can complete, assessed as if it could not. org
• Failure mode: cutting junior hiring without a plan for where future senior engineers come from. org
• Speaks honestly about AI's effect on roles and headcount, without promising what the organisation cannot keep. exec
• Lets any headcount change follow measured evidence rather than forecasts. exec
• Failure mode: a headcount plan that assumes a productivity gain nobody has measured. exec

Output versus learning. Assistants let juniors produce more and can stop them learning. The judgment is to accept some loss of short-term output for unaided work and explanation that build the skill the organisation will need later.

Measurement versus morale. Engineers who feel faster may resent being told the outcome measures have not moved. The judgment is to share the measures openly, credit the feeling as real, and treat the gap as something to understand together.

Fairness versus realism in assessment. Banning assistance in hiring tests something the job no longer looks like; allowing it unstructured tests the tool. The judgment is to state the rules, allow what the job allows, and assess the reasoning the tool cannot supply.

Reassurance versus honesty. A team anxious about its jobs wants to hear it is safe, and nobody can promise that. The judgment is to say what is known, what has been decided and what has not, and to keep every promise made.

A senior engineering manager leads three teams through their managers. Leadership has asked for next year's hiring plan with "a third fewer engineers, because of AI", and the plan as drafted cuts all graduate hiring. Separately, two of the managers report the same pattern: their newest engineers ship changes quickly with assistants, but in review they cannot say why the code works or what would break it. An internal survey says engineers feel about twice as fast; delivery metrics over the same period are flat.

The easy responses are to submit the plan, because leadership asked and the survey seems to support it, or to refuse any reduction and defend every role. The first builds a headcount commitment on a feeling, and removes the entry point through which the organisation grows its future senior engineers. The second ignores a real question and spends the manager's credibility on a position the evidence does not support either.

The senior manager starts with measurement. With the three managers, they assemble the outcome measures for the year: cycle time slightly better on two teams, change failure rate slightly worse on one, rework unchanged. They put the survey beside it and note the gap, and they bring the external evidence: studies that find large gains on some tasks and none or losses on others, a randomised trial in which experienced developers were slower while feeling faster, and labour-market studies that disagree on whether AI is changing employment at all.

They then deal with the juniors, because that problem is already costing review time. The managers agree a practice: graduates do some work unaided each sprint, chosen to teach; every change they submit is explained in review; and their assistant is configured to explain and suggest rather than complete whole tasks where learning is the point. A quarter later, the managers report that review is slower for graduates and that they can now explain what they ship.

The hiring plan goes to leadership with the measured results, the uncertainty, and a proposal: hold total headcount flat for the year, keep graduate hiring at a reduced but non-zero level with the new development practice, and revisit at two checkpoints with the organisation's own numbers. The senior manager says plainly that if the measures show a lasting gain, the plan will change, and that cutting the graduate intake to zero would save money this year and cost senior engineers in three. Leadership accepts the flat plan and the checkpoints. When one of the teams asks at an all-hands whether their jobs are safe, the senior manager tells them what was decided, what the numbers show, when the next review is, and that they will hear about any change from their manager first.

• TJ-5 AI-assisted engineering: the baseline judgment about building capability and measuring AI's effect.
• PL-3 Hiring and onboarding: hiring on evidence of capability, as opposed to access to tools.
• PL-5 Career development and growth paths: career development and growth paths that still build the skills AI erodes.
• SV-5 Engineering metrics and measurement: measuring and reporting AI's impact honestly.
• AI-1 Adoption strategy and staged bets: the adoption decisions whose effects this unit measures.
• AI-3 AI-assisted software delivery: review for understanding in delivery.

1. Why might the people who gain most in output from AI be the ones most at risk?
   Answer

   Because the largest gains have been found among the least experienced, and their output can rise while their learning stalls if the tool supplies answers they would otherwise have worked out. Output and learning have to be managed separately.
2. What practices protect how early-career engineers learn when assistants are available?
   Answer

   Some unaided work chosen to teach, explanation of every change in review with the reasoning probed, and assistance configured to hint and explain rather than hand over complete answers where learning is the point.
3. A survey says engineers feel twice as fast; delivery metrics are flat. What should be reported upward?
   Answer

   The outcome measures first, with their baseline and uncertainty, and the survey reported separately as perception. Self-reported speed-ups have been shown to diverge from measured results, so they are not the measure of AI's effect.
4. How should hiring adapt when candidates can use assistants?
   Answer

   State the rules on assistance in advance and apply them to everyone, allow what the job allows, and assess reasoning through structured interviews that probe trade-offs and what the candidate would check, which is harder to outsource than a take-home task.
5. What is the honest summary of the evidence on AI and jobs?
   Answer

   That it is contested: exposure estimates measure potential, not job loss; some administrative data show effects close to zero; and some early evidence suggests early-career workers in the most exposed occupations are falling behind. Nobody can promise a team their jobs are safe or unsafe on this evidence.
6. Why is cutting all graduate hiring a risky response to AI?
   Answer

   Because it saves money now and removes the pipeline through which the organisation grows its future senior engineers, on the strength of a productivity gain that may not have been measured. A reduced, non-zero intake with a deliberate development practice keeps the option open.

• Brynjolfsson et al. (2025): productivity gains concentrated among the less experienced.
• Bastani et al. (2025): how the design of assistance decides whether learners learn.
• Lee et al. (2025): confidence in AI and self-reported critical thinking.
• Becker et al. (2025): experienced developers slower with AI tools while believing they were faster.
• Forsgren et al. (2021): the dimensions of developer productivity.
• Hunter (1998): the validity of structured interviews.
• Brynjolfsson et al. (2025): early-career employment in AI-exposed occupations, a working paper.
• Humlum et al. (2025): small labour-market effects in Danish administrative data.
• Eloundou et al. (2024): occupational exposure to language models.