A team can produce more draft changes without delivering more accepted work. The review queue grows, senior engineers become interruption points, and developing engineers get fewer chances to reason through an unfamiliar problem. The manager sees activity, but the workload has moved rather than disappeared.
That is a planning problem, not an argument that assistance is always helpful or always harmful. Some preparation tasks may improve. Some changes may become easier to review. Other assignments may require more context, correction, and coordination. An engineering manager needs to see those differences and decide how work, approval, and learning will be assigned.
This guide follows a hypothetical team preparing a set of internal workflow changes with approved AI assistance. The case uses invented tasks and proposed local planning conditions. It reports no staffing, productivity, or employee outcome. The artifact is a workload and responsibility plan that includes review capacity, work in progress, mentorship, access, and escalation.
The finish line is a team decision you can inspect and adjust. It is not a promise that an AI-native team needs a particular number of people. Your organization still needs to decide what work it values, which risks it accepts, and who is accountable when a proposed change becomes an operating system.
Follow one change through the review queue
The engineering workbook separates preparer and reviewer effort. Use the blank trial log to follow one task from the first draft to acceptance. Include rework and coordination that occur after the draft looks complete. If a task is abandoned, record the reason instead of keeping only its initial drafting time.
When generated tests overwhelm reviewers
A large test suite can increase the work required to understand what has been asserted. Ask which behavior and failure condition each proposed test covers. Review a smaller, coherent batch with a clear purpose before extending it. Confirm that failures would expose a meaningful defect rather than mirror the implementation.
Record reviewer time, redundant or misleading cases, defects discovered and the acceptance decision. If the review queue grows, examine batch size, test relevance, verification skill and the definition of done. The answer may be a workflow change rather than another reviewer or another generator.
Keep task categories separate
A documentation update, a production incident and a security-sensitive change carry different context and review needs. Avoid treating all generated output as interchangeable units. SPACE supports considering multiple dimensions of productivity rather than one activity measure. Measurement reference.
DORA's qualitative work, already cited in this guide, describes verification burdens and the movement of work to reviewers. It does not supply a universal ratio of senior engineers to AI-assisted implementers.
Review the management decision too
Before a staffing or responsibility change, identify the task mix, missing experience, failure costs and evidence you would need to reconsider. A neat cost scenario is a useful input, but it cannot supply a team design by itself. Keep the responsible decision with the people who understand the system and its obligations.
Map the path from assignment to accepted and operated work
Draw the actual workflow for a selected task. Include preparation, implementation, review, corrections, integration, release, and operating ownership where relevant. Different tasks may use different paths. The goal is to see where effort and decisions occur rather than impose a decorative process diagram on every change.
Give each stage an observable completion condition. A draft may be ready for review while the change remains unaccepted. A merged change may still need a reviewed rollout. An operating handoff may be required before the task can be called delivered. Keep those distinctions on the planning board when they affect commitments.
The assistant can help summarize permitted task notes or prepare a responsibility draft, but the manager must verify who actually accepts the work. An owner name generated from an organization chart is not an agreement. Ask technical and operating owners to review the plan. If a responsibility remains unassigned, show that condition instead of scheduling the task as if the work will disappear. This is especially important when faster preparation makes it easy to accumulate more commitments than the team can responsibly finish.
A hypothetical team plan: draft capacity increases while review remains scarce
A team plans several internal workflow changes. Some are narrow field mappings, some alter permissions, and one affects an integration operated by another team. Developers can use an approved assistant for permitted preparation. Senior reviewers remain responsible for acceptance, and normal deployment ownership still applies.
The manager wants to redesign the workload without assuming that every task becomes faster or that everyone should use the same amount of assistance. The proposed plan names tasks and owners, protects time for review and learning, and defines which observations would require a change. These issues become its core record.
The case is hypothetical; its acceptance conditions are proposed local decisions, not measured project results or industry benchmarks.
Draft versus accepted work
The planning board treats an opened pull request as a completed task. Review and correction remain in a separate queue, so the reported output hides work still needed before the change can be accepted. Inspect a shared task-state definition and the review queue.
The case accepts this part only when the plan distinguishes prepared, reviewed, accepted, and operated work where those stages matter. It rejects the proposal when draft volume is reported as completed delivery while review remains unresolved.
Next, revise the board states and assign an owner to each acceptance step. The review asks: Which stage is the team actually committing to complete this week? This requires workflow design. Count the effort spent reclassifying work and reviewing the delivery boundary in the experiment.
Review capacity
The schedule assumes one senior engineer can review every generated change between other responsibilities. It does not account for the attention required by permission and integration decisions. Inspect a review-capacity plan by task consequence and available attention.
The case accepts this part only when the planned review load has accepted owners and time rather than an assumed unlimited reviewer. It rejects the proposal when faster drafting creates a queue the designated reviewers cannot inspect responsibly.
Next, reserve review time and reduce or split work when the queue exceeds the agreed boundary. The review asks: What work will the reviewer stop doing to accept this load? This requires capacity management. Count the effort spent planning review attention and negotiating competing responsibilities in the experiment.
Task-specific assistance
The manager proposes a single tool-use expectation for every assignment. A narrow fixture draft and an ambiguous customer requirement need different inputs and different review conditions. Inspect a task-to-assistance map with permitted inputs and expected outputs.
The case accepts this part only when each assignment defines what assistance prepares and what remains a human decision. It rejects the proposal when a generic adoption target substitutes for task acceptance and permission design.
Next, write separate assistance boundaries for the selected task categories. The review asks: What result should this task produce, and what must the assistant not decide? This requires delegation design. Count the effort spent defining assignments and reviewing their access needs in the experiment.
Learning and mentoring
A developing engineer receives complete generated patches and is judged on throughput. The plan has no opportunity to establish whether they understand the interface or can explain a failure independently. Inspect a reviewed learning assignment and mentor time allocation.
The case accepts this part only when the plan includes an inspectable reasoning task and protected feedback for the intended skill. It rejects the proposal when draft output is treated as evidence of understanding without a walkthrough.
Next, assign one independent fixture or failure explanation and schedule its review. The review asks: What should the engineer be able to explain after this assignment? This requires skill-development planning. Count the effort spent the mentoring review and independent practice in the experiment.
Operational ownership
A generated change adds an integration dependency. The task owner can merge code, but the plan does not name who investigates failures or accepts the support obligation after release. Inspect a service-owner agreement and operating handoff.
The case accepts this part only when the dependency has an accepted operating owner and escalation path. It rejects the proposal when delivery is declared complete while the operating responsibility remains unassigned.
Next, review the integration obligation with the service team before commitment. The review asks: Who acts when this dependency fails after the author moves on? This requires cross-team coordination. Count the effort spent obtaining ownership and preparing the operating handoff in the experiment.
Permissions and data
The assistant could prepare richer context if it read more internal material. The manager's authority to assign a task does not establish that every repository or employee record may be sent to the tool. Inspect the approved data and action boundary for each assignment.
The case accepts this part only when the team uses permitted inputs and retains separate approval for consequential actions. It rejects the proposal when a workload goal silently broadens data access or automation authority.
Next, narrow the context or obtain the documented owner review before expanding. The review asks: Which permission is necessary for this task rather than merely available in the tool? This requires permission judgment. Count the effort spent reviewing data scope and separating preparation from action in the experiment.
Performance interpretation
The manager sees one person preparing more changes and another spending more time on review. Comparing their draft counts alone would misrepresent the responsibilities each carried. Inspect a responsibility-aware task and review record.
The case accepts this part only when feedback considers assigned work, acceptance evidence, and review obligations within its stated limits. It rejects the proposal when individual performance is inferred from incomparable draft volume.
Next, review contributions against their actual responsibilities and avoid unsupported tool-use rankings. The review asks: Whose essential work is missing from the visible count? This requires people-management judgment. Count the effort spent interpreting contributions and checking measurement limits in the experiment.
Staffing decisions
A promising pilot leads to a proposed staffing ratio before the team has examined task mix, review, operations, and the work it would choose to do with any additional capacity. Inspect a separate staffing decision brief with workload and uncertainty assumptions.
The case accepts this part only when staffing decisions use the organization's actual obligations and evidence rather than a universal AI ratio. It rejects the proposal when a bounded preparation result becomes a claim that a role or position is unnecessary.
Next, separate the workflow trial from the consequential staffing decision. The review asks: What evidence would justify this staffing change beyond faster first drafts? This requires organizational decision-making. Count the effort spent preparing the decision assumptions and reviewing broader consequences in the experiment.
Plan review as work with limited attention
Review is not free capacity left over after implementation. A reviewer may need to understand a requirement, inspect a permission boundary, establish an independent expected result, or negotiate a dependency. Treat the attention as part of the workload rather than a delay caused by an uncooperative senior engineer.
Estimate capacity through the actual assignments and record uncertainty. A local plan can reserve blocks for consequential review, limit simultaneous drafts, and split a large change into inspectable parts. It should not claim that one reviewer can handle a fixed number of generated pull requests across every environment. The complexity and familiarity of the work matter.
Watch the queue. If preparation increases while reviewed acceptance does not, ask whether the constraint moved. The next action may be narrowing assistance, improving task contracts, reducing work in progress, or developing another qualified reviewer. It is not automatically hiring fewer authors or asking reviewers to approve faster. The plan should identify which change it will test and what observation would make it revise the workload.
Make the queue response explicit before the trial. The team might stop starting new consequential changes while a permission review is unresolved, or split preparation from implementation. The exact response is a local planning choice. Its value is that a growing queue triggers a decision instead of becoming another invisible obligation assigned to the same busy reviewer.
Define task-specific assistance instead of a generic adoption quota
State what the assistant prepares, what inputs it may see, and what conditions the person must verify. Preparing a test fixture from an approved contract is different from deciding the contract. Drafting an explanation of supplied code is different from authorizing a deployment. These distinctions let the manager delegate work without delegating decisions the tool cannot own.
Avoid judging every task by the same tool-use measure. More interaction with an assistant does not establish better delivery, and less interaction does not establish resistance. Ask whether the assignment reaches its reviewed outcome and what costs or constraints explain the result. A useful trial can discover that one task benefits while another needs a different method.
Let the people doing the work identify confusing context or permission gaps. If they cannot provide a permitted input that represents the problem, fix the assignment or narrow it. A manager should not pressure an engineer to improvise authorization to meet an adoption goal. Clear task boundaries support a more practical conversation than arguments about whether a person is pro-AI or anti-AI.
Revisit the assistance boundary when the task changes. A fixture draft may become an integration change after the team discovers a missing adapter behavior. That discovery does not automatically expand the assistant's authority. Update the task contract, owner, and acceptance conditions before continuing.
Keep a record of declined assignments as well. A task may be unsuitable because its permitted inputs omit essential context, its output cannot be checked economically, or its consequence requires a different process. Reporting that reason helps the next planning cycle. Hiding the task as a failed adoption attempt would obscure what the team learned about its actual work.
Protect mentoring that demonstrates actual understanding
Choose a learning objective tied to the work. A developing engineer might independently establish one expected output, explain one failure state, or trace one caller before asking for alternatives. The assignment can still use assistance elsewhere. The point is to establish understanding where the role requires it.
Reserve mentor attention and record the feedback task. If mentoring becomes an invisible activity squeezed between urgent reviews, a faster drafting workflow may reduce the practice that develops future reviewers. The team can test a modest protected exercise rather than claiming that all learning must happen without tools.
The skill-formation preprint studied a small short task involving participants unfamiliar with a library. Its immediate comprehension findings do not prove long-term skill loss for every senior engineer, and interaction-pattern comparisons do not establish one universally correct prompting method. Use the limits to design local evidence: ask what the engineer can now explain, reproduce, or challenge. A polished output and a high task count do not answer that learning question.
Keep data, action, and operating permissions explicit
The manager can assign a task within organizational authority, but data handling and consequential actions may have separate owners. Approval to prepare a proposal does not automatically authorize repository uploads, customer-data use, merge, deployment, or production changes. Put the boundary into the assignment.
Review current official integration documentation and the organization's approved policy before expanding tool access. This guide does not rank coding products or claim a vendor's current retention behavior. If a task cannot be represented inside the permitted boundary, reduce context or obtain the appropriate review. Do not make broad access an unstated assumption in the capacity plan.
NIST SP 800-218 provides general secure development practices that can inform review and lifecycle responsibilities. NIST's generative AI risk profile offers voluntary evaluation and risk-management guidance. These sources do not certify a team's integration or authorize its data flow. Their role is to support relevant questions while actual owners decide which controls and permissions apply.
Measure the whole workflow without misusing individual counts
Choose a measure aligned with the planning question. Draft queue size can reveal a bottleneck. Reviewed acceptance can reveal completion under a stated standard. Follow-up corrections can reveal additional work. None alone supplies an individual performance rating or a staffing formula.
Record preparation, review, corrections, and operating handoff. If one engineer authors fewer changes because they carry consequential review, their draft count omits part of their contribution. Discuss responsibilities before comparing output. Respect the organization's employee-data boundaries and avoid creating a surveillance experiment merely because the tool can log activity.
DORA's qualitative analysis describes respondents' experiences with generation and checking burdens. It is observational, not proof that adoption causes a particular team outcome. METR's 2026 update explains why the earlier narrow slowdown and later uncertain estimates do not provide a universal current effect. A local workload trial should report its task mix and limits. It can support a revised assignment plan without pretending to answer every productivity or employment question.
Discuss responsibilities and role choices before changing headcount assumptions
A workflow trial can reveal that the team needs more requirement clarification, stronger review, different operating ownership, or targeted learning. Those are responsibilities to examine. Whether they require a staffing change depends on the broader workload, organizational decisions, and evidence beyond the pilot.
Separate a staffing brief from the assistance trial. State the work the organization intends to perform, the capacity assumptions, the operating obligations, and the uncertainty. Do not claim that a favorable preparation example establishes an engineer is unnecessary or that a title is protected forever. Consequential personnel decisions need their own accountable process.
Invite people to discuss the work they want to own and the skills they need to demonstrate. A senior engineer may want deeper technical responsibility; another may want to develop review or coordination skills. A manager can offer a bounded assignment to test that direction. AI capability does not settle the preference. The role conversation becomes more honest when the workload plan shows what the responsibilities actually involve rather than relying on a general story about the future of engineering.
A 30-day workload and responsibility trial
In the first week, choose a bounded set of tasks and map preparation, review, acceptance, and operation. Confirm owners, permissions, and the completion standard. Reserve review and mentor attention before increasing drafting volume. Make the trial's possible next decisions visible to the team.
In the second week, run the assignments with task-specific assistance boundaries and record queue changes, review effort, and unresolved issues. In the third week, inspect whether the constraint moved and whether learning practice actually occurred. Ask affected owners whether the plan fits their real attention rather than relying only on the board.
In the fourth week, revise work in progress, task contracts, ownership, or assistance where the evidence supports it. Keep staffing conclusions separate and name what broader evidence they would need. Choose one responsibility-development action for each relevant assignment, such as reviewing a permission fixture or explaining a failure state. The trial can end with a narrower use of assistance and still provide a useful planning result.
A team handoff that preserves owners, capacity, and open decisions
The plan should let the next reviewer understand what the team has committed to do and what remains conditional. The following hypothetical handoffs illustrate how to transfer an issue without assuming that faster preparation solved it. They do not report actual team results or personnel outcomes.
Keep capacity and authority distinct. A person may have time to prepare a draft without authority to approve its data use or deploy it. An owner may have authority while lacking the available attention the schedule assumes. Showing both makes the plan easier to revise when priorities change. A vague note that everyone will help hides the conditions the manager needs to manage.
Draft versus accepted work handoff. Attach a shared task-state definition and the review queue to the workload and responsibility plan. Write the unresolved review question: Which stage is the team actually committing to complete this week? The next person should be able to perform this action: revise the board states and assign an owner to each acceptance step.
Task-specific assistance handoff. Attach a task-to-assistance map with permitted inputs and expected outputs to the workload and responsibility plan. Write the unresolved review question: What result should this task produce, and what must the assistant not decide? The next person should be able to perform this action: write separate assistance boundaries for the selected task categories.
Operational ownership handoff. Attach a service-owner agreement and operating handoff to the workload and responsibility plan. Write the unresolved review question: Who acts when this dependency fails after the author moves on? The next person should be able to perform this action: review the integration obligation with the service team before commitment.
Performance interpretation handoff. Attach a responsibility-aware task and review record to the workload and responsibility plan. Write the unresolved review question: Whose essential work is missing from the visible count? The next person should be able to perform this action: review contributions against their actual responsibilities and avoid unsupported tool-use rankings.
Compare your options
| Case issue | Evidence to retain | Acceptance condition | Reason to stop |
|---|---|---|---|
| Draft versus accepted work | a shared task-state definition and the review queue | the plan distinguishes prepared, reviewed, accepted, and operated work where those stages matter | draft volume is reported as completed delivery while review remains unresolved |
| Review capacity | a review-capacity plan by task consequence and available attention | the planned review load has accepted owners and time rather than an assumed unlimited reviewer | faster drafting creates a queue the designated reviewers cannot inspect responsibly |
| Task-specific assistance | a task-to-assistance map with permitted inputs and expected outputs | each assignment defines what assistance prepares and what remains a human decision | a generic adoption target substitutes for task acceptance and permission design |
| Learning and mentoring | a reviewed learning assignment and mentor time allocation | the plan includes an inspectable reasoning task and protected feedback for the intended skill | draft output is treated as evidence of understanding without a walkthrough |
| Operational ownership | a service-owner agreement and operating handoff | the dependency has an accepted operating owner and escalation path | delivery is declared complete while the operating responsibility remains unassigned |
| Permissions and data | the approved data and action boundary for each assignment | the team uses permitted inputs and retains separate approval for consequential actions | a workload goal silently broadens data access or automation authority |
| Performance interpretation | a responsibility-aware task and review record | feedback considers assigned work, acceptance evidence, and review obligations within its stated limits | individual performance is inferred from incomparable draft volume |
| Staffing decisions | a separate staffing decision brief with workload and uncertainty assumptions | staffing decisions use the organization's actual obligations and evidence rather than a universal AI ratio | a bounded preparation result becomes a claim that a role or position is unnecessary |
Write a workload and responsibility plan for one assisted workflow
Choose a small set of tasks and a review period. Use the worksheet to expose workload transfers and missing agreements. It does not supply a staffing ratio or authorize a new tool integration.
A reflection tool for planning your next step, rather than a predictive score.
- Map task stages through reviewed acceptance and operating handoff.
- Name each accountable owner and confirm their accepted responsibility.
- Define assistance inputs, outputs, and excluded actions per task.
- Reserve review attention and choose a work-in-progress boundary.
- Protect a concrete learning assignment and its mentor feedback.
- Record queue, review, correction, and unresolved-work observations.
- Separate performance and staffing interpretations from the workflow trial.
- Review the plan and choose a bounded next assignment.
The hypothetical manager separates draft completion from reviewed acceptance and identifies permission changes that require senior attention. They reserve time for those reviews and define a bounded independent fixture task for a developing engineer. The worksheet does not assume the trial will increase delivery; it establishes the work and observations needed to decide.
The manager also notices a habit of promising more capacity before discussing which responsibility must be deprioritized. They choose to ask the service owner what attention is genuinely available instead of filling the schedule with an optimistic assumption. That conversation addresses decision behavior alongside the technical plan.
If you repeatedly make commitments that your own evidence does not support, examine what drives that pattern and choose a different action to test. AI and the Andes Retreat is a five-day seminar in Peru's Sacred Valley for 8-15 participants, with no plant medicine. It offers space to examine the decisions, behavior, and actions shaping your life. You can bring a question about your professional direction and choose an action to test afterward. It is not a coding course or a promise about hiring, income, or career security.
Your working notes
Use this page while you think. Your notes stay in this browser tab; download them before you close it.
What does this question change for you?
A practical answer can change how you work. It can also leave a personal decision unresolved: what to learn, what to stop postponing, or which responsibility to take next. Name that decision before collecting another prediction.
Work through your next decision. Your notes stay in the browser tab, and the exercise gives you no predictive score.
If a recurring pattern keeps preventing action, AI and the Andes Retreat offers five days of practical inquiry in Peru's Sacred Valley, followed by support and accountability. Read about the seminar and assess whether that work fits your question.
Frequently asked questions
Search research and audience discussions informed these questions. Some wording has been adapted to the task covered by this guide.
How can AI help an engineering manager understand team workload?
It can help prepare a workload summary from permitted records, but verify task stages, responsibilities, and missing effort. Draft counts can hide review and correction work. In the team case, distinguish prepared, accepted, and operated changes and ask owners whether the planned attention is available. Do not use a generated summary to infer individual performance automatically. The useful output is an inspectable plan with open obligations, not a claim that activity has become delivery.
What should becoming an AI-native engineering manager mean in practice?
Define the responsibilities you want to demonstrate rather than relying on the label. Practice task-specific delegation, review-capacity planning, data boundaries, measurement, and protected learning. In the team case, a useful plan identifies what assistance prepares and which decisions remain with accountable people. Test a bounded workflow and revise it from observations. Tool adoption alone does not establish managerial competence, and a title does not supply a staffing ratio or operating agreement.
How should a manager respond when AI-generated tests overwhelm reviewers?
Review a smaller batch with an explicit purpose for each test. Check the behavior and failure condition covered, identify redundant or misleading cases, and record the effort needed to accept the work. If generated tests move the bottleneck to reviewers, examine batch size, verification skill and the definition of done. A larger generated suite is not proof of broader useful coverage or a reason by itself to change staffing.
How should I decide the structure of an AI-assisted engineering team?
Design around the work, acceptance decisions, operating obligations, and available attention. A team building AI systems may need different responsibilities from a software team using coding assistance. In this guide's case, identify authors, qualified reviewers, service owners, and learning support without assuming a universal pod size. Confirm that each owner accepts the role. A diagram of titles does not establish capacity, and faster preparation does not eliminate the need for review or operation.
How can I use AI as an engineering manager without automating my judgment?
Give it a permitted preparation task such as drafting a responsibility map or summarizing approved task notes. Verify the summary against actual owners, task states, and unresolved decisions. In the workload case, the assistant cannot accept another team's support obligation or decide that a developer's contribution is low. Keep authority and data boundaries explicit. Use the draft to improve a conversation and plan, then record the human decision and the evidence supporting it.
What should junior developers learn when AI writes more of the draft code?
Choose an inspectable reasoning task tied to their role: establish one independent expectation, trace a caller, or explain a failure state. Assistance can still support other preparation. In the team case, reserve mentor time to review the demonstration instead of treating draft throughput as proof of understanding. Keep the learning objective and feedback visible in the workload plan. A polished generated patch does not establish that its author can maintain or challenge the result.
How should I respond when a junior developer submits weak AI-assisted code?
Address the specific behavior, evidence gap, and learning need rather than the origin label alone. Ask the author to explain the contract and one consequential check, then provide scoped feedback and mentor attention. In the team case, a missing permission expectation requires correction and practice. Do not solve every gap by having a senior rewrite the patch invisibly. Record acceptance conditions and a follow-up task that demonstrates understanding before increasing the developer's responsibility.
How should an AI-first team plan code-review workload?
Plan review as assigned work with limited attention. Classify consequential changes, name qualified reviewers, and set a response when the queue grows. In the team case, faster preparation should not create unreviewed permission changes. Narrow tasks, reduce work in progress, or develop additional review capability when the evidence supports it. Do not assume the AI-first label makes review unnecessary or that one senior engineer can absorb unlimited drafts between other responsibilities.
What should staff engineers and managers own in an AI-assisted workflow?
Agree responsibilities explicitly with the organization and affected teams. Staff engineers may help establish technical contracts and review consequential assumptions; managers may plan capacity, ownership, and learning. Those are proposed divisions to confirm, not universal title rules. In the team case, a service dependency needs an accepted operating owner before delivery is called complete. Keep authority, available attention, and preparation separate so that a generated plan cannot silently assign an obligation.
When should I allow an automated workflow that includes verification?
Review its actual verification evidence, permitted actions, failure consequences, and accountable owners. A claim that the team is confident in the checks is not enough by itself. Start with a bounded task and retain the normal acceptance boundary. In the workload case, preparing a fixture differs from merging or deploying a change. If the process expands, revisit its permissions and recovery plan instead of treating the initial preparation approval as continuing authority for every action.
How should I assess an engineer who is productive without using AI?
Assess the responsibilities and accepted work rather than treating tool use as the performance outcome. Examine requirements, review, corrections, and operating contributions within the organization's process. The public question's claim that avoiding AI causes productivity is not established here. In the team case, an engineer may carry review work invisible in draft counts. Discuss the actual evidence and task constraints before requiring a different method or comparing people whose assignments are not comparable.
What if developers feel pressured to generate more code to look productive?
Clarify the completion standard and the contributions the team actually values. Draft volume can transfer work into review and maintenance, so do not make it the sole sign of performance. In the workload case, show who establishes permission expectations and who carries corrections. Invite people to identify the pressure and missing work through the appropriate conversation. Revise the assignment or measure when it rewards activity that does not reach accepted and operated outcomes.
How should I challenge a productivity target chosen before the team has evidence?
Ask what decision the target serves and which observations would support it. Propose a bounded workflow trial with a shared acceptance stage, task-mix notes, and review costs. Keep uncertainty visible rather than promising the desired number. In the team case, a target that ignores review attention can create a queue instead of delivery. Separate the assistance trial from staffing commitments and explain what broader evidence a consequential organizational decision would require.
How should I respond to the assumption that AI help removes a workload constraint?
Show the actual task stages and the work the assumption leaves out. Assistance may prepare a draft while requirements, review, permissions, and operating ownership remain unresolved. In the team case, identify the limited reviewer attention and ask which responsibility would be deprioritized to accept more work. Propose a bounded test rather than another blanket argument about tools. A capability claim does not establish the available capacity of the people who must accept the result.
Can a team use less process and still manage its workload?
Evaluate the function each process serves and how the team will retain necessary decisions, visibility, and ownership. A public anecdote about minimal process is not evidence that removing a meeting is appropriate everywhere. In the workload case, the team still needs to see review queues, permissions, and operating obligations. Test a bounded change and state what would trigger revision. Do not replace a process with an assistant summary unless the underlying responsibility and evidence remain inspectable.
What should engineers do to adapt to AI in their team workflow?
Clarify the assigned task, permitted assistance, evidence expected at handoff, and the decisions they still own. Bring recurring review or learning burdens to the manager with concrete examples rather than hiding them behind a polished draft. In the hypothetical team, an author should explain a changed permission path and unresolved checks before requesting review. Practice the underlying reasoning independently as well. Adaptation is a conversation about accepted work and responsibilities, not a requirement to use a tool on every task.
How can AI assistance increase team workload?
It can create additional preparation, correction, review, or operating work in a particular workflow, even when drafting takes less time. Measure that possibility rather than assuming it occurs everywhere. In the hypothetical team, more proposals can leave reviewers with a growing queue of permission and recovery questions. Track the work by role and task, including rejected proposals. Narrow the assignment or adjust the handoff before increasing output targets, and keep the person who carries each obligation visible.
How should leaders prepare for possible changes in team responsibilities from AI agents?
Map tasks, acceptance decisions, action permissions, and operating obligations before changing roles. Test a bounded assignment and identify what remains unresolved after a generated output appears. In the hypothetical team, automating draft preparation does not settle who approves a release or maintains recovery evidence. Discuss changes with the people carrying that work, including training and review capacity. The observed question assumes agents take over roles; this guide treats that outcome as a hypothesis requiring scoped evidence rather than a staffing fact.
Which engineering-management skills matter when adopting AI assistance?
Practice defining accepted work, recognizing transferred burdens, coaching explanation and verification, and negotiating priorities with evidence. A manager should be able to distinguish an author-time improvement from a team-capacity improvement. In the hypothetical team, explain why reviewers need independent permission evidence and how the queue will be observed. Build these skills through a small responsibility map and a retrospective on one scoped trial. Tool fluency helps preparation but does not replace judgment about workload, learning, or accountable decisions.
What criteria should a manager use to evaluate an AI tool for the team?
Evaluate the exact task, permitted information, action scope, inspectable output, correction burden, and operating ownership. Verify current official claims for the actual configuration, then trial a meaningful failure as well as a normal case. In the hypothetical team, examine whether the tool improves handoff evidence or merely produces more proposals for an unchanged review queue. Compare roles and accepted outcomes over the same scope. A popular product or compelling demonstration does not settle its fit for this team.
Sources and evidence
These guides were drafted with AI assistance and checked against the linked sources. Examples labeled hypothetical illustrate a decision; they are not participant stories or measured results.
Studies answer specific questions about particular people, tasks, and tools. Their dates and limits matter. A result about task assistance is not a forecast for an entire profession.
- How AI Impacts Skill Formation, preprint version 2
- NIST SP 800-218: Secure Software Development Framework
- NIST AI 600-1: Generative Artificial Intelligence Profile
- DORA: Balancing AI tensions: Moving from AI adoption to effective SDLC use
- METR: We are Changing our Developer Productivity Experiment Design
- O*NET: Software Developers
- Observed audience question: How to use AI as engineering manager
- The SPACE of Developer Productivity: There's more to it than you think (2021-02)
Where the audience questions came from
These linked discussions and comments supplied questions and wording. They do not establish the truth of the replies, verified professional identities, or how common a concern is.
- Observed audience question: What should junior devs actually learn now that AI writes so much of the code?
- Observed audience question: How to deal with juniors shipping AI slop code?
- Observed audience question: AI first teams - how are you dealing with code reviews?
- Observed audience question: Where are the staff engineers and the managers at these companies?
- Observed audience question: If your team can establish a workflow that has some automated steps with a verification process you are confident in, why wouldn’t you allow this?
- Observed audience question: I wonder why they can’t make the connection that perhaps you are the one of the most productive BECAUSE you don’t use AI?
- Observed audience question: Are you in a position where you need to race out that slop to not look unproductive compared to your team members?
- Observed audience question: How do I tell them that they should not assume a target at the start and just go with what results the team can get?
- Observed audience question: And what is worse, with AI the rebuttal from management is usually, 'well you have AI to help, don't you?
- Observed audience question: Have you ever worked in a team with minimal process?
- Audience discussion informing the engineering question
