How do we change our interviews now that a key part of the job is working with coding agents? A senior engineer is now expected to manage coding agents to produce shippable products, not to write code. But many interviews still test closed-book problem-solving, the one activity the engineer won’t be doing!

The fix sounds simple: rebuild the interview around the actual work. Instead of asking a candidate to implement a quicksort, give them an ambiguous ticket, a real codebase, and the tools to solve it. Do that, and using AI stops being “cheating.” Using AI becomes the test. It’s easier said than done, but this is the direction we’ve been pushing our own interviews over the past six months.

We’d like to hear what you’re seeing: Have you changed technical screens? What signal do you still trust and what’s changed? What surprised you when you tried AI-allowed rounds? Reply to this email or grab time on my Calendly if you want to compare notes.

Basically, it’s a measurement problem

AI didn’t break technical interviewing. It exposed how long we’d been measuring a proxy for the job instead of the job itself. Karat’s survey of engineering leaders found that 71% say AI makes it harder to assess technical skills, and their CEO argues the root cause isn’t cheating so much as interviews that haven’t kept up with the job. Candidates can produce correct LeetCode answers or polished take-homes, but struggle to debug a multi-file change or explain why they rejected a plausible diff.

What doesn’t work anymore: puzzles without context

Take-home assignments and automated code tests were never strong signals for senior hires. Nowadays they’re close to useless when everyday tools can one-shot them. Interviewing.io let candidates use ChatGPT on modified LeetCode problems. Pass rates jumped sharply and interviewers rarely noticed. Pragmatic Engineer’s reporting on hiring managers found startups dropping take-homes and algorithmic screens for that reason, while Big Tech interviewers report asking harder variants of the same questions instead.

Making the questions harder buys time, not relevance. One hiring manager described re-running their interview questions through the newest model every few months. Eventually it one-shotted their second-round question, and there was no harder one left to reach for. Even with one in hand, a puzzle the model can solve tells you little about how a candidate exercises judgment under real constraints. Templated system design interviews have the same flaw. Candidates learn a script that fits a sixty-minute slot, and the script rarely resembles how your team actually decides tradeoffs.

What survives: judgment in realistic conditions

The interviews that still produce signal look more like the job. Startups and some larger product companies are adding rounds where candidates use AI on a realistic task while an engineer watches how they work. Shopify’s engineering leadership has been public about embracing that model: candidates who don’t use an agent often lose to those who use one well, and the interesting part is what happens next. Do they spot garbage output? Fix an obvious one-line bug by hand or keep prompting? Explain tradeoffs when the model suggests the wrong abstraction?

Strong candidates treat generated code as a draft, validate edge cases, and stay coherent when follow-ups go off script. Weak candidates paste, ramble, or collapse when asked to defend a design choice without a fresh prompt. The shift is to make these skills the whole interview, not just a bonus round after a puzzle.

Two industries pretending to be one

Big Tech and many enterprises are largely fortifying the old process: screen sharing, cheat suspicion flags, harder algorithmic questions, and talk of returning to in-person screens. Startups are redesigning it: dropping take-homes, allowing Cursor or Copilot, or running paid trial days where AI use is expected. Both are rational responses to the same shock, but they optimize for different risks. Incumbents fear false positives from hidden assistance. Fast-moving product companies fear false negatives from banning the environment their engineers already use.

Leaders should name which failure mode they are actually solving. Prohibiting AI without redesigning questions often pushes assistance underground and rewards performers who are mostly good at looking honest on camera. Allowing AI without new rubrics and interviewer training just makes the old false positives easier to generate. Pedigree screening rises when resume signal collapses, which is understandable and still a bad long-term strategy for teams that need builders who can navigate messy codebases, not just familiar logos on a CV.

Recruiter and engineering misalignment makes the signal problem worse before a candidate ever reaches a technical round. When screening criteria are vague, recruiters optimize volume while engineers want depth. Promising profiles never reach the right conversation, or weak ones burn panel time on puzzles that AI already solves. The corrective move is shared ownership of the bar: senior ICs define what “honest talent worth a coding assessment” looks like in practice, recruiters screen to that definition, and both sides treat the early filter as a trust problem as much as a skills problem.

What we’re currently doing

Our own hiring practice has changed multiple times over the past year, and we expect it to change again. (What follows is the coding track, which every engineering candidate goes through regardless of level. Candidates for higher-level roles also get a separate architecture and system design interview.) Our first step is a background interview: a deep dive into work the candidate has done that has real technical complexity, plus a frank discussion of the kinds of challenges that come with the target environment.

Candidates who clear this first step go on to three exercises that mirror how the work actually looks.

• Code analysis. We ask candidates to reason about somewhat obfuscated or obtuse legacy code and explain what it does. That rewards reading, tracing, and judgment, all critical skills in reviewing code that AI is creating.
• A function body against a flimsy specification. It is a simple problem the candidate will encounter often, but the spec is incomplete on purpose. We watch whether they ask the interviewer the right clarifying questions, and then we watch them build the simple thing once the ask is clear. Communication under incomplete information is the skill. Clever algorithm recognition is the LLM’s job.
• An AI-practices walkthrough, framed as day one on a project. The candidate has just cloned a codebase that has never been touched by an AI agent, and their first job is to explore it and get it ready for agentic development. We leave “ready” undefined on purpose. How they approach this task tells us how they think about setting an agent up to succeed. Next we hand them a ticket and ask how they would implement it with AI. Finally we show them the agent’s output and ask how they’d review it.

On that third exercise, we care how they work throughout: Do they understand AI basics and deeper SDLC habits? Do they explore the repo for docs and artifacts? Ask about existing tests, practices, and tech before prompting for code? How do they prompt to implement the ticket, and do they explore the generated code in depth with a critical eye? That last question is where judgment shows up, because the generated code looks plausible and the test is whether they can tell what’s wrong with it.

None of this is a finished template. It is our current bet on measuring the job we actually hire for: reading code, clarifying weak requirements, turning agentic assistance into trustworthy outcomes, and codifying what the agent gets wrong into rules so it doesn’t happen again.

AI is not ending technical interviewing. It is forcing honesty about what we have been optimizing for. The processes that survive will measure how engineers operate with assistance, incomplete information, and accountability for outcomes. That is closer to a PR review than a whiteboard puzzle, and for most product engineering teams, that is the job.

Reading list

• Engineering Interviews in 2026: 3 Trends Hiring Leaders Must Prepare For (Karat, January 2026) — The source of the 71% figure, drawn from 400 engineering leaders across the US, India, and China. The more alarming number is buried further down: confidence that the right candidates are getting offers fell from 68% to 47% in a single year.
• Three Ways AI is Reshaping Traditional Technical Interviews in 2026 (IEEE-USA InSight, 2026) — Where Karat CEO Mo Bhende makes the relevance argument directly: the fundamental job changed, technical interviews did not. Short, and the cleanest statement of the mismeasurement thesis we have found.
• How hard is it to cheat with ChatGPT in technical interviews? We ran an experiment. (interviewing.io) — Thirty-seven interviews where candidates were told to use ChatGPT and interviewers were told nothing. Pass rates hit 73% on verbatim LeetCode and 67% on modified versions, dropping to 25% on fully custom questions. Not one interviewer suspected anything.
• Tech hiring: is this an inflection point? (The Pragmatic Engineer) — Interviews with engineering managers at startups and mid-sized companies, most of whom say hiring is harder now than it has ever been. Useful for the practitioner quotes on why coding problems and take-homes both stopped working at the same time.
• How AI is changing software engineering at Shopify (The Pragmatic Engineer, with CTO Farhan Thawar) — The source for the Shopify approach described above. Thawar shadows interviews himself and uses generated code as a probe, asking the candidate whether it is any good. Worth reading for how differently that round is scored.

Often agentic loops are especially applicable in diverse domains. In healthcare, a patient chart review requires querying multiple systems, cross-referencing drug interactions, and reasoning across clinical history. In legal work, a contract review needs case law search, clause comparison, and conflict detection — not to mention that you may want to bring in significant client context. The loop exists because these problems are hard to solve with workflow-based designs.

Independent of workflow vs. agentic approach, scenario-based evals are the right approach for domain-specific applications. Each scenario is a specific input — a patient chart, a contract, a claims record — paired with an expert-defined expected outcome. Did the agent identify the medication interaction? Did it flag the indemnification clause? Did it reach the correct coverage classification? Did it ask the right questions and not ask ones it already had access to through context?

Why standard evals break for loops

Workflow-based implementations could test each step in isolation: given this input, does it produce the correct output to pass forward? In agentic loops, that no longer holds. The agent has autonomy over sequencing, and the order of operations may vary across sessions. Tool calls may fail or return unexpected results that the agent reasons past without flagging. An output-only eval catches none of it.

The non-determinism problem in domain evals

Here is where it gets genuinely hard. Evals are specific to a given scenario, but the agent’s path through that scenario is not fixed. Different sessions may pull different chunks from the retrieval system. The conversation may branch differently. The agent may reach the right conclusion through a different sequence of tool calls.

The way to handle this is to separate what you are actually testing. For the output layer, test the conclusion: did the agent identify the issue that matters? For the trajectory layer, test the key decision points: did it retrieve the document that contains the interaction? Did it call the drug lookup tool? Did it pass the correct patient ID? Trajectory evals do not require the agent to take an identical path every time. They require that the path passed through the checkpoints that justify the conclusion.

A case where the agent arrived at the right answer but skipped a critical tool call should not pass. That is not a correct evaluation. It is a lucky guess that will fail on the next prompt change.

How to start building this

You do not need a complete scenario library to get started.

• Start with production failures. Any trace where the agent reached a wrong conclusion, missed an issue, or called the wrong tool is a scenario waiting to be labeled. Get a domain expert to define correct behavior for that case and add it to the set. Five real failures are worth more than fifty synthetic happy-path cases.
• Write trajectory checkpoints, not just output assertions. For each scenario, identify the one or two tool calls or retrieval steps that are load-bearing. Test that those happened correctly and with the right parameters.
• Make “correct” explicit. Not a matching string, but a rubric: what must the output include, what must it not include, what tool calls must appear in the trace.
• Run evals on every significant change. Every prompt update, model upgrade, or tool integration should trigger a full scenario run. If scores drop, you do not ship.

The judge is itself a component to evaluate

Using LLM-as-judge to score outputs at scale is essential, but treat the judge as a component in your eval system, not a fixed oracle. Like every other component, it can drift. After a model update, your judge’s behavior may shift in ways you have not noticed. Build a calibration set for the judge: a sample of cases with human expert labels. Run the judge against them periodically and watch for divergence. When judge scores and expert scores disagree consistently, that is a signal. Either the judge has drifted, or your calibration set no longer reflects the scenarios the agent actually handles.

Treating the judge as infallible leads to calibration debt that accumulates invisibly and surfaces as production failures nobody predicted.

Reading list

• AI Agent Evaluations: A Developer’s Practical Guide (MLflow, 2025/2026) — Good on what specifically changes when you move from LLM to agent evals. The 75% judge-human agreement threshold as a recalibration trigger is a practical heuristic worth adopting. Apache-licensed tooling, no paywall.
• Evaluations for the Agentic World (QuantumBlack, January 2026) — Two detailed client case studies in regulated industries, a European telco and a European bank, covering trajectory validation, SME review as an eval layer, and continuous quality monitoring. The most concrete multi-agent eval case studies available in a public piece.
• A Pragmatic Guide to LLM Evals for Devs (Pragmatic Engineer, 2025) — The best starting point for teams new to systematic evals. Covers why LLM non-determinism breaks traditional testing and how to build a minimal eval suite that actually catches regressions. The golden dataset construction section is directly applicable to domain-specific scenario libraries.
• A Methodical Approach to Agent Evaluation (Google Cloud, November 2025) — The cleanest structural framework I have found: three pillars covering final output quality, trajectory analysis, and trust/safety. Worth reading specifically for the section on building a golden dataset when you do not yet have one. The Vertex AI mention at the end is a brief plug; the framework itself is tool-agnostic.
• Awesome-Evals (BenchFlow, GitHub) — A curated library of papers, blog posts, tools, and benchmarks organized by topic. Useful if you want to go deeper on any specific area: tool-calling evals, LLM-as-judge calibration, multi-agent evaluation. The “non-BS” framing in the description is accurate.

Wikis and similar systems — Confluence, Notion, and the rest — are orthogonal to the system itself. Pages fall behind quickly, because updating them is secondary labor. In a traditional SDLC, this isn’t the end of the world. Humans can just ignore out-of-date documentation, and rely on the bits they know to be reliable, filling in the gaps by asking their manager or emailing the product team. An agent won’t do that! A copy and paste from outdated docs will be treated as 100% true by an agent.

Ultimately, this is less a model problem than a documentation and memory problem.

The repository as the system of record

One solution to this problem is to make the repository the system of record. Requirements and rationales live alongside the modules they describe, and git history and PR comments explain what changed along the way. Jira and Confluence shift from being the source of truth to useful reports generated from what lives in the repo.

Several forces stack in favor of this locality, especially with agents in the loop. The simplest is colocation: docs that live next to src/billing/ change when billing changes. Local docs aren’t orthogonal to the work the way wiki articles are. And because they ride the same branches, the honesty machinery you already run (pull requests, human and agent review, CI checks, linters) can govern documentation too.

Locality also changes what a diagram is worth. A box-and-arrow PNG in Confluence is opaque to an agent, but a Mermaid flowchart beside the service entrypoint shows up in the diff and can be read by the tools. Underneath all of this is a question of what the artifact is optimized for. When agents and engineers reason about a change, the question is usually what a module does and what must not break, not where the payments wiki lives. A repository is organized around that question; a topical wiki fights it.

Karpathy’s markdown library: compile, don’t chunk

We’re not the only ones thinking this way. Andrej Karpathy recently described an approach to building an LLM knowledge base that bypasses classic RAG for many real workloads. You dump raw material into a folder, let an agent compile it into interlinked Markdown, and run periodic lint passes so the library stays consistent. At team scale he argued structured text plus indices beats opaque embedding search that returns plausible fragments with weak provenance.

That pattern rhymes with system documentation too. You already have the raw material of a knowledge base scattered everywhere: git history, tickets, Slack threads, and code. You’re just not compiling it into agent-readable truth that lives beside the work. Karpathy’s point is that the model can be your librarian. Once the pattern is established, summaries, cross-links, and cleanup become ongoing maintenance, done entirely agentically, rather than a one-time migration project. This doesn’t mean vector databases are dead; it means the interesting bet for many product engineering teams is versioned Markdown in git, maintained with the same habits as code.

What you should do Monday

We are intentionally not prescribing a full-on “move your tickets into git” or “replace Jira with YAML tasks” project. Ticket workflow is a separate fight, and many teams are not ready for it. This thesis calls for different experiments around documentation and shared memory.

Try this: pick one bounded subsystem and require that its functional and architectural documentation live in Markdown/Mermaid stored alongside the code. Treat wiki pages as deprecated for that slice. Then add a lightweight gate that makes drift visible: a CI check that fails when certain paths change but their docs don’t, or an agent lint step that compares README claims to test names and public API surfaces.

Run a Karpathy-style compile pass to flesh out this new library: export related decisions from Slack into a raw/ folder, then run a bounded agent job to produce interlinked docs/ with backlinks. Review the agent’s work and tweak based on what it missed or under/overemphasized. Measure whether onboarding and agent sessions get faster, more accurate, or just plain easier.

Whatever experiment you run, teams will have to adjust. This change lands differently on each side of the house. Product leaders will need to build fluency with repo-resident artifacts (reading a spec in git, commenting on a PR). For engineering leaders, the change means owning freshness: if agents read the repo, stale local docs are now a production risk, not a technical-writing nuisance.

None of this requires replacing the wiki overnight. Plenty of orgs will keep it as the official face for auditors and executives, and that’s not wrong. Different consumers need different views. The bet worth running in 2026 is smaller: for the teams shipping with agents, stop asking them to treat a parallel documentation universe as true. Put truth beside the implementation, let git govern change, and let agents help maintain the library the same way we finally learned to let CI maintain tests.

Further Reading

• LLM Wiki (Karpathy’s own gist) – Andrej Karpathy, ~Apr 2026. His three-layer pattern: raw/ (immutable sources) → wiki/ (LLM-generated interlinked Markdown) → a schema file (he names CLAUDE.md / AGENTS.md), with ingest/query/lint ops and the LLM as “compiler.” This is the thesis in his own words and uses the raw/ folder the draft references.
• Stop Writing Passive Documentation (DDS) – Alper Kinali, Apr 2026. “Passive documentation… is a critical point of failure”; agents “lack context, they hallucinate.” Near-verbatim support.
• Docs as Code — Write the Docs – canonical reference. Authoritative definition: version control, PR review, CI gating, block a merge that lacks docs.
• Mermaid — Introduction – Mermaid project, maintained. Explicitly positions itself against “Doc-Rot”; text-defined, version-controllable diagrams vs. opaque binaries.
• Is RAG Dead? Context Engineering & Semantic Layers – Steve Hedden, TDS, Oct 21 2025. Backs “structured context beats embedding search.”
• Docs for Developers (book) – Bhatti, Corleissen, Lambourne, Nunez, Waterhouse; Apress, 2021.
• Why we use “docs as code” — GOV.UK – Jen Lambourne, GDS, Aug 25 2017.
• Squarespace’s docs-as-code journey – Squarespace Eng, 2025.

Almost every CTO or VPE we talk to is asking some version of the same question: “Are we picking the right tools, building out the right workflows, and putting our people in the right places?” In other words: how should engineering teams actually operate now, with agents writing most of the code?

Teams are landing in pretty different places. Some are pushing toward full autonomy with minimal human review. Others are keeping tight control, using AI more as a reviewer or assistant. Most are somewhere in the middle.

But which workflow you pick isn’t really the challenge. The inputs are.

The bottleneck has moved. Writing code is getting cheaper, but building reliable systems requires more than just code. Specs, tests, and review are now the limiting factors, and agents amplify whatever you feed them. Strong inputs get strong results. Weak ones fail faster, at scale, and with less visibility into why.

One theme for the second half of 2026: engineering leaders need much better visibility into what other teams are actually doing. Too much of this is still being figured out in private, and some of the public conversation is noise.

What’s actually working

From what we’re seeing across teams and practitioner write-ups, a few patterns are emerging. Not as a single “right way,” but as things that consistently hold up.

Front-load the thinking: spec, tests, then code

The teams getting reliable output are putting more effort into shaping the problem up front (acceptance criteria, edge cases, tests) before letting agents implement. The shift is subtle but important: less time writing code, more time defining what “correct” looks like.

Parallelize aggressively, but with boundaries

Running multiple agents in parallel is becoming common: one exploring, one implementing, one cleaning up. (Stripe built a harness that ships >1,000 agent-driven PRs per week. ) But the teams doing this well isolate each agent in its own worktree, container, or sandbox, so mistakes don’t cascade. Parallelism helps, but only if it’s contained.

Where this breaks

A few failure modes show up just as consistently.

Tests written after the fact

This is amplification working against you. When you ask an agent to write tests after the implementation, the existing code becomes the spec. Agents don’t push back. They complete the task you gave them, even if the task is wrong. The result: tests that lock in whatever’s broken. Discipline matters more with agents, not less: tests first, then implementation.

Context can be a liability

Many teams are leaning on rules files (CLAUDE. md, AGENTS. md) to guide behavior. But they go stale quickly. Codebases evolve, and these files rarely keep up. Without regular review, they can make things worse, with agents following outdated or rigid instructions. Structure is necessary for good results, but bad structure gets amplified.

What actually changes for teams

Coding agents don’t remove the need for senior engineering judgment. They concentrate it. The work shifts toward defining problems clearly, validating outputs, and keeping the whole system reliable. Teams with weak specs, inconsistent tests, or overloaded review processes feel more pain, not less. Teams with strong fundamentals move faster.

The work moves up the stack, and the pressure moves with it. And the systems you build around the agents matter more than the agents themselves.

Reading list

• Embracing the parallel coding agent lifestyle – by Simon Willison. Concrete patterns for running several coding agents at once. Covers worktrees and Docker for isolation, what kinds of work to delegate to parallel sessions, and what to supervise more tightly.
• How Stripe built “minions” – by Steve Kaliski via Lenny’s Newsletter. Inside Stripe’s production agent harness shipping ~1,300 PRs/week from Slack reactions. Covers the harness layers, how they handle code review at that scale, and what they had to build vs. adopt off-the-shelf.
• Why Testing After with AI Is Even Worse – by Matti Bar-Zeev. Why asking an agent to write tests after the implementation produces tests that validate existing bugs instead of catching them. Makes the case for TDD with agents, not against it.
• How System Prompts Define Agent Behavior – by Srihari Sriraman and Drew Breunig (nilenso). A close read of system prompts across Claude Code, Cursor, Codex, Gemini, and others. Shows the same model producing dramatically different workflows depending on the prompt wrapped around it.
• Your CLAUDE. md Is Making Your Agent Dumber – by Cordero Core. Recent research finding that LLM-generated CLAUDE. md / AGENTS. md files actively decrease agent success rates compared to having no context file at all. Practical guidance on what to do about it.
• Ralph Wiggum as a “Software Engineer” – by Geoffrey Huntley. Walks through “Ralph,” a bash-loop technique for autonomous coding agents. Concrete on what kinds of projects it suits and where senior engineering judgment stays non-negotiable.

Yes we still need QA, but what “QA” means is rapidly changing.

Teams using agentic coding are shifting quality both left and right. Left into work definition, acceptance criteria, and test architecture. Right into integration confidence, production signals, and release confidence.The shift matters because no downstream checkpoint can absorb the volume agentic engineering can produce.

QA has to stretch in both directions – into the decisions that shape the work, and into the signals that show it will hold up in production.

Where this is heading

The shape of QA is still in flux.

Some teams are pushing quality further left, with more rigor in specs, acceptance criteria, and engineering guardrails before agents ever start writing code. Fowler’s recent “harness” framing pushes even further in that direction: the goal is to create stronger guides, checks, and boundaries around agentic work so that quality is built into the system earlier, rather than rescued at the end.

At the same time, teams are also being pushed right. Faster code generation increases the need for integration confidence, release confidence, observability, and production feedback.

Both moves follow the same pattern: QA is no longer a stage in the pipeline. It’s a thread running through the whole SDLC.

Where AI helps

AI can be genuinely useful in QA work.

• It can generate baseline unit tests quickly.
• It can help fill gaps in integration coverage.
• It can suggest edge cases.
• It can help analyze failures faster.
• It can reduce repetitive test-authoring work.

We worked with one client that had a 10+ year old Java application with almost no test coverage. Spending weeks writing tests by hand was not getting prioritized. AI generated a baseline suite in hours.

That was valuable. But “better than nothing” is not the same as “good enough to trust.” That is still the trap.

QA responsibilities still exist

Whether you call it QA or absorb the responsibility into other functions, the responsibilities still exist:

• Helping define what “correct” means before work starts.
• Shaping acceptance criteria, workflows, and edge cases.
• Validating outcomes, not just checking whether scripts pass.
• Improving release confidence across systems, not just within a single change.
• Watching production signals and feedback after release.
• Helping teams identify where AI-generated coverage looks good but misses the real risk.

QA’s future will vary by organization: some will keep a distinct function, some will shift testing into engineering, and others will refocus specialists on end-to-end validation, production risk, and release confidence.

What does not hold up is the idea that QA can remain a cleanup step at the end.

A more practical QA playbook

A practical approach for 2026 looks something like this:

• Use AI aggressively to generate baseline unit and integration test code, followed by careful human review to finalize.
• Involve QA earlier in shaping acceptance criteria and edge cases.
• Put more energy into integration confidence and release confidence.
• Spend less time maintaining brittle scripts and more time validating outcomes.
• Treat QA as part of quality system design, not just test execution.

That last point is one of the biggest changes.

The QA teams that create the most value in an agentic world are not just writing or maintaining scripts. They are helping design the system that makes rapid change safe.

Additional reading

• Harness engineering for coding agent users – The best conceptual piece in this set. Useful for thinking about how trust moves from manual review toward a stronger surrounding harness.
• A Thoughtworks perspective on CircleCI’s 2026 State of Software Delivery – A strong operating-model piece on what happens when delivery systems designed for human-speed change meet AI-assisted throughput.
• How to Lead an AI Testing Transformation: A Playbook for QA Leaders – Vendor source, but useful for thinking through how QA organizations may need to change.
• The SDLC Doesn’t End at Code Generation: Why Platform Engineering Teams Must Modernize Quality Next – Helpful on the idea that shift-left alone is not enough.
• Stop Maintaining Scripts. Start Testing Outcomes. – Good shorthand for one of the biggest changes in QA work.
• Does using AI in QA testing increase risk for software companies? – A useful counterweight to the idea that AI-driven testing is automatically safer.

CPOs, VPs of Product, and CTOs are experiencing a common challenge: while agentic coding tools accelerate product development, they also introduce new friction between product and engineering. A product manager (PM) creates a spec that tells engineering what they want built, and then one of two things happens:

• The engineer appropriately asks the agentic coding tool what questions it has. The agent immediately surfaces 15 questions, 12 of which need input from product. You have a cycle time hit and more context switching.
• The engineer doesn’t surface the questions and builds it anyway. After PR reviews and QA, they realize the implementation does the wrong thing.

One theme for the first half of 2026: product and engineering leaders need to reduce this new friction.

What changed

A PM’s spec has two audiences.

First, people:

• Reviewers (customers, leadership, other PMs) who need to confirm the product intent.
• Engineers who need to reason about tradeoffs, durability, and how it fits the architecture.

Second, agents:

• The agentic coding tool that will try to execute what you wrote, literally, at speed.

So what do we do?

PMs should use codebase-aware tools before handoff

I would highly recommend that product leaders and product managers try out the new Claude Desktop app, which bundles Claude, Claude Cowork, and Claude Code into a more PM-friendly interface. You can use it for a LOT more product needs than creating specs – see the additional reading below.

To get your PMs onboard, consider using the tool to ask:

“What does the product do today in scenario X?”

If you have Claude Desktop connected to your code, it often can answer those types of questions. It also will provide you the answer to:

“Given this draft spec, what questions do we need to answer before someone starts work?”

This helps PMs clarify ambiguity so you avoid the new friction points.

It’s time to change the default from “PMs don’t have visibility into the repo.” That policy actively works against speed and alignment. By giving the AI tooling access to the code base, PMs are empowered with insight while maintaining the separation of responsibilities with engineering.

Side note: Markdown is quickly becoming the shared format for specs because it’s easy to diff, easy to reuse, and plays nicely with repos and agent workflows. Pick a Markdown editor you like (Obsidian is a good choice) and make it part of the standard toolkit.

PRDs and Tickets => Specs

You may want to start calling PRDs / Tickets or other definitions of what’s to be built “specs” internally, not because PRD is wrong, but because it communicates a shift: the output is meant to be fed into an agentic coding tool w/ more specifics.

The upcoming virtual mini-conference and the additional reading has lots of help on this front, for example – acceptance criteria and edge cases are critical.

AI supports PMs but does not replace their judgment; it should enhance decision-making efficiency. Use AI to accelerate drafting, decomposition, and edge case discovery. But the final tradeoffs, priorities, and product decisions still belong to the PM. And us engineers still get to rely on PM judgment to know what to build.

Engineering still has to engineer

A clear spec does not eliminate engineering responsibilities. Strong teams do two things consistently:

1. Architecture and technical planning: fit the spec into the system in a durable way (constraints, data flows, integration points, performance, security).
2. Task shaping: break the spec into finer-grained development tasks that are independently testable, so agentic execution stays controlled and reviewable.

A good spec allows the engineers to focus on the work that actually requires engineering judgment.

Reading list

• Agentic workflows for software development – A good overview of agentic workflow design, especially the idea of deterministic checks and evaluation gates that keep speed from turning into chaos.
• How to write PRDs for AI Coding Agents – A practical reframing of PRDs as “spec architecting” so agents (and engineers) can implement reliably with fewer missing assumptions.
• How to Write a PRD with AI (Claude Code tutorial) – Template-forward guidance on assembling a PRD/spec from known context files (including a prd-template.md style approach) so your spec is consistent and agent-friendly.
• How to write a good spec for AI agents – The clearest explanation of “spec as prompt”: why big docs fail and how structure plus constraints drives correct execution.
• Claude Code for Product Managers – A PM-oriented walkthrough of exploring a repo in plain English to tighten tickets/specs and surface the right questions before handoff.
• Claude Code for PM work – Grounded notes on where PM workflows break today (docs are incomplete, reality lives in code) and how codebase-aware tools can reduce that gap.
• The Definition of Ready in the AI Era – A strong argument for shifting DoR from “can dev start?” to “if built exactly as written, would we be satisfied?”

Adversarial testing: why it matters for LLM and RAG systems

Adversarial testing or “red teaming” is about trying to make your AI fail on purpose, before malicious actors or edge-case users do. For LLMs and RAG, that means probing for prompt injections, jailbreaks, hallucinations, data leakage, and subverted retrieval strategies.

LLM systems are vulnerable to cleverly crafted prompts that skirt safety limits and encourage harmful, biased, or unauthorized outputs.

RAG and hybrid architectures have unique takeover risks: manipulating the retrieval pipeline, poisoning source documents, or confusing context windows so the model behaves unpredictably.

Adversarial testing uncovers real issues that aren’t obvious until your model is live: privacy leaks, bias amplification, data extraction attacks, and unreliable inferences; all the stuff that keeps CTOs and CISOs up at night.​

How do tech leaders integrate adversarial testing for LLM/RAG?

• Simulate attacks with both manual red teaming and automated tools and test vectors like prompt injections, data poisoning, and retrieval manipulation.
• Chain attacks across model and retrieval layers; don’t assume vulnerabilities stop at the model boundary.
• Use playbooks like MITRE ATLAS, OWASP ML Security Top 10, and keep logs for every test; they’re useful for team learning, postmortems, and compliance.
• Layer in robust monitoring so adversarial scenarios are caught in real time, not just during scheduled security reviews. Real-time monitoring is essential for both security and reliability.
• Involve domain experts and skeptics. Adversarial ideation is creative work, not just automation. It takes deep product knowledge and a healthy dose of adversarial thinking to imagine how your outputs could be abused.​

• Simulate attacks with both manual red teaming and automated tools and test vectors like prompt injections, data poisoning, and retrieval manipulation.
• Chain attacks across model and retrieval layers; don’t assume vulnerabilities stop at the model boundary.
• Use playbooks like MITRE ATLAS, OWASP ML Security Top 10, and keep logs for every test; they’re useful for team learning, postmortems, and compliance.
• Layer in robust monitoring so adversarial scenarios are caught in real time, not just during scheduled security reviews. Real-time monitoring is essential for both security and reliability.
• Involve domain experts and skeptics. Adversarial ideation is creative work, not just automation. It takes deep product knowledge and a healthy dose of adversarial thinking to imagine how your outputs could be abused.​

Reading List

• Complete AI Red Teaming Guide for Beginners in 2025 (Practical DevSecOps)
• Invisible commands, real threats: The rise of prompt injection in AI
• 3 Takeaways from Red Teaming 100 Generative AI Products (Microsoft)
• What is ‘red teaming’ and how can it lead to safer AI? (World Economic Forum)
• AI Red Teaming Case Studies: Ethics And Security 2025 (Troy Lendman)

A few definitions to start

Autonomous agentic system: an LLM wrapped in a loop that can plan, take actions via tools, observe results, and continue until it reaches a stop condition (or it’s forced to stop).

Tool calling: the agent selecting from a constrained action space (tool names + schemas) and emitting structured calls; your runtime executes them, validates outputs, and feeds results back into the loop.

Orchestration (the “real software” around the model): state management, retries, idempotency, timeouts, tool gating, context assembly/pruning, audit logging, and escalation paths.

Closed-loop evaluation (Plan -> Act -> Judge -> Revise): a repeatable harness where you run realistic tasks, score outcomes (ideally against ground truth and human-calibrated judges), learn what broke, and iterate.

Guardrails + safe stopping: runtime-enforced constraints (policies, budgets, circuit breakers, permissions) that limit what the agent can do and force it to stop or escalate when risk rises or progress stalls.

A small set of practices that pay off fast

Treat your tools like a product surface, not a pile of functions.
The failure mode is “death by a thousand tools”: overlapping capabilities, ambiguous names, and huge schemas that make selection brittle. Keep tools narrow, make them obviously distinct, and hide tools by default unless they’re relevant to the current step. “Just-in-time” instructions and tool visibility is a pragmatic way to scale without drowning the model in choices. 

Move reliability into deterministic infrastructure (not prompt magic).
If an agent can trigger side effects (create a ticket, refund an order, email a customer), you need transactional thinking: idempotent tools, checkpointing, “undo stacks,” and clear commit points. Prompts don’t roll back production systems; your runtime does. 

Put hard budgets and explicit stop reasons into the main loop.
Most “runaway agents” are simply missing guardrails that set limits on: iterations, tool calls, dollars, and wall-clock time; and “no progress” detectors (same tool call repeating, same plan restated, same error class recurring). When the agent hits a threshold, it should stop with a structured summary: what it tried, learned, and needs from a human.

Design for long-running work with durable state and resumability.
If the agent’s job can outlast a single context window (or a single process), assume it will crash, time out, or be interrupted. Store state externally, make steps replayable, and separate “planning notes” from the minimal context required to proceed. The goal is to resume cleanly without redoing expensive work or compounding earlier mistakes.

Make evaluation real: production-like tasks, ground truth, and judges you can trust.
Vibe checks don’t catch regressions. You want a small-but-representative set of real tasks sampled from production distributions, with ground truth where possible, and automated judges that are calibrated against human agreement (so you know what “good” means). Also assume reward hacking and metric gaming will happen. Build detection for it the same way you do for any other adversarial input.

Security guardrails: constrain action space, validate everything, and sandbox execution.
Tool calling expands your attack surface (prompt injection is just one angle). Practical defaults: strict schema validation, allow-lists for tool targets, content sanitization, least-privilege credentials, and sandboxed execution for anything that can run code or touch sensitive systems.

More reading

Building production-ready agentic systems: Lessons from Shopify Sidekick (Shopify, Aug 26, 2025)

AI grew up and got a job: Lessons from 2025 on agents and trust (Dec 18, 2025, Google Cloud)

Effective harnesses for long-running agents (Nov 26, 2025, Anthropic)

What 1,200 Production Deployments Reveal About LLMOps in 2025 (Dec 19, 2025, ZenML)

Ground Truth Curation Process for AI Systems (Aug 20, 2025, Microsoft).

Function calling using LLMs (May 6, 2025, Martin Fowler).

How to build your first agentic AI system (Oct 2, 2025, TechTarget).

AI coding tools are transforming how we make software. But measuring the impact of these tools is harder than it looks!

To address this pressing issue, we are excited to announce our upcoming webinar: AI Coding Tool Metrics: DORA and CTOs Deep Dive. This expert-led session aims to provide engineering leaders with the clarity and tools needed to navigate the complexities of measuring the impact of AI coding tools effectively.

For the first time, the LA CTO Forum is opening this session to a broader audience. Join us, along with fellow CTOs, VPEs, heads of engineering, senior product leaders, and IT leaders, to gain a practical and reality-based view of measuring AI coding tools in the real world.

Event Details

• Date: Friday, January 9, 2026
• Time: 8:00 AM – 10:00 AM PST / 11:00 AM – 1:00 PM EST

Reserve your spot

During this two-hour mini-conference, attendees can expect:

• Insights from a DORA researcher on how high-performing teams are adopting AI-assisted development and the key metrics that correlate with better outcomes.
• Real-world experiences shared by two CTOs on measuring AI tools in their organizations, including utilization, quality, satisfaction metrics, and handling non-code work.
• A moderated discussion among CTOs and attendees to address key questions and concerns.

Key Takeaways

• Discover the metrics used by leading organizations to measure the impact of AI coding tools and the tools that can help capture them.
• Learn how to assess where your team stands on the AI adoption curve and strategies to catch up if needed.
• Understand the hidden value AI tools provide beyond just increasing code output.

Don’t miss this opportunity to gain valuable insights and strategies to effectively measure the impact of AI coding tools in your organization.

All registrants will receive the slides and a full session recording.