You may have spent years becoming the person others call when the system behaves strangely. You understand why a seemingly simple change has consequences, which questions a specification leaves unanswered, and what happens after the release. Then a demonstration shows a model producing something that looks like several days of your work in a few minutes.
The question deserves an honest answer. It also deserves a more precise definition of your work than the demonstration provides. Producing code, producing an accepted change, and running a dependable system are different accomplishments. If you are responsible for the latter two, you need to examine how the entire process is changing.
This guide is for experienced engineers, technical leads, and engineering managers who want to act intelligently. It considers opportunities as well as threats: using assistance to investigate alternatives, reducing a frustrating preparation task, developing a stronger review process, or making space for a different kind of technical work. It also examines situations where adding AI would make the work harder.
The research includes published developer field experiments, METR's measurement updates, an occupational task inventory, and DORA's analysis of engineers' experiences. Reddit discussions help identify the questions readers raise. They do not establish a person's expertise or turn a comment into evidence about the whole industry.
You can use the guide to produce a concrete next step: a proposed experiment, a conversation with your manager, or a decision about what to learn. You may still have a larger personal question about the work you want to do. Give that question its own attention. A useful technical test and an honest examination of your next chapter can proceed together.
What does the research actually say about developer productivity?
A field-experiment paper published in February 2026 studied AI code completion across 4,867 developers at Microsoft, Accenture, and an unnamed Fortune 100 company. Its pooled estimate was a 26.08% increase in completed tasks, with a 10.3 percentage-point standard error. Less-experienced developers adopted the tool more and showed larger gains. Individual experiments produced noisy and differing estimates.
That is evidence of useful assistance in the tasks and settings studied. It is not evidence that a particular senior engineer will become exactly that much faster. The uncertainty matters, as does the measured outcome. Completed tasks do not automatically tell you about maintainability, production reliability, the organization's return on investment, or how many engineers it should employ. Some authors also have affiliations with participating technology companies.
Different studies can produce different results without one being fraudulent. The task, the surrounding codebase, the developer's knowledge, and the way time is counted all matter. In a familiar repository, understanding context may consume more effort than entering syntax. In a narrow, well-specified task, generating a plausible implementation may be a larger part of the work.
METR's February 2026 productivity update is especially useful here. The organization explains why its older 2025 result, a 19% slowdown in a specific experienced-developer setting, should not be treated as today's general effect. Its follow-up suggested improvement, but participant and task selection, together with difficulties measuring concurrent-agent work, made the estimates unreliable. Repeating the old slowdown as a verdict on current tools would be misleading. Repeating a biased follow-up as a dependable speedup would also be misleading.
For your own work, the practical response is to ask a narrower question. Can a particular approved tool help you produce an acceptable change in a particular process, after preparation, review, and corrections are counted? That question can be tested. You can compare results without requiring one study to settle every future engineering decision.
Write down which claim you are borrowing from a source. If the finding concerns task completion, keep it a task-completion finding. If you want to infer changes in hiring or compensation, acknowledge that you have moved to a different question. A useful study can inform that question without supplying the answer.
Which parts of a senior engineer’s work are you comparing with AI?
Begin with your actual recent work rather than a job-title description or a list of supposedly safe skills. Take an ordinary completed change and reconstruct what made it possible. Who established the need? What ambiguity had to be resolved? Which systems or people constrained the choice? Who determined that the result was acceptable?
The O*NET software-developer profile includes user needs, requirements, design constraints, specifications, testing, integration, maintenance, and coordination. It is a broad occupational inventory, not a study of senior engineers' current workload or a forecast of AI displacement. It is useful because it reminds you to include work that a coding demonstration may leave out.
Your inventory might contain a customer conversation that changed the requirement, a compatibility decision, an explanation to another team, and an investigation into a misleading test failure. Some of those tasks may be good candidates for assistance. Others may need information the system cannot access or a decision it is not authorized to make. Keep both possibilities visible.
For each activity, describe the input and the acceptable result. "Architecture" is too broad to test. "Prepare a comparison of two proposed storage approaches against these agreed constraints" gives you something you can inspect. "Leadership" is too broad to test. "Draft a summary of the open technical decisions from approved meeting notes" is more concrete.
Include the ordinary work of checking. An engineer may be useful because they know when a requirement is incomplete, not because they can personally type every implementation. That is a reason to investigate how their work changes. It is not proof that the position will remain economically secure forever. Organizations can redesign responsibilities and staffing as their needs change.
The inventory should also include what you enjoy. Perhaps debugging a difficult failure is the work you want more of. Perhaps you prefer shaping requirements or developing others. These preferences do not establish business value, but they matter when choosing your direction. If assistance removes a task you dislike, the change may create room for work you want. If it removes the practice you value, you may need to make a deliberate choice about where that practice stays.
Does a successful prototype mean the production work is solved?
A prototype answers some questions very well. It can show a possible interaction, expose an unclear requirement, and give people something concrete to discuss. Its value does not depend on pretending it is already ready for every operational condition.
Ask what the demonstration actually established. Was it produced from a complete specification? Did it run only on invented data? Were unusual cases excluded? Did a competent person inspect the implementation? Was the result evaluated beyond the path shown in the presentation? These questions are relevant to any prototype, regardless of how it was created.
In DORA's March 2026 analysis, researchers examined 1,110 open-ended responses from Google engineers in Q3 2025. Engineers described rapid generation alongside auditing and verification effort. The analysis distinguishes prototypes from production readiness and discusses how AI can amplify existing strengths and weaknesses in a workflow. These are qualitative self-reports from one company, not a causal estimate of every team's productivity or a labor-market forecast.
For a proposed change, make the remaining work visible. You may need to establish behavior under incomplete inputs, compatibility with existing interfaces, access boundaries, monitoring, and a recovery path. The specific checks depend on your system. A small internal helper and a customer-facing payment component have different consequences and should not share an acceptance standard simply because both contain code.
The senior engineer's opportunity is to help turn a promising possibility into a decision the organization can understand. That might involve improving the prototype's specification, narrowing its scope, or deciding the prototype should remain a learning artifact. You can recognize useful progress while identifying unfinished work.
Try separating the conversation into two sentences: "This demonstration shows that we can produce this kind of draft," and "Before release, these conditions remain unresolved." It is easier to discuss the next action when enthusiasm and acceptance are recorded separately. You are then debating the real remaining work rather than choosing between celebration and dismissal.
Avoid turning production readiness into an impossibly long checklist for a low-consequence experiment. Choose checks proportionate to the task, while preserving the requirements that actually matter. The goal is a competent acceptance decision, not a ceremony that makes every change take longer.
How should you review AI-generated code?
Start with the intended behavior. If the requirement is vague, a readable implementation can conceal the fact that no one has decided what the system should do. Describe acceptable inputs, expected outputs, exceptional conditions, and the consequences you need to avoid. A review can then assess something more meaningful than whether the code looks plausible.
Inspect the change in manageable pieces. A large patch may contain some useful work and several assumptions that are difficult to see together. Ask for a smaller scope when necessary. The person responsible for the change should be able to explain why each meaningful part is present and how it relates to the requirement.
Use tests that examine the requirement independently of the generated implementation. A model may help propose cases, but cases derived only from its own code can reproduce its assumptions. Add cases from your understanding of the domain, historical failures, interface expectations, and the important limits of the task. Passing tests establish only what those tests meaningfully examine.
Look at the surroundings too. Does the change fit the actual dependency versions, data definitions, and operational constraints? Does it introduce a new assumption about ordering, access, or persistence? What does another part of the system expect? The answer will depend on your environment, so this guide does not offer a universal security checklist or a claim that one tool is safe.
Include a maintainability question: can an authorized teammate understand the change without reproducing your entire conversation with the model? Keep the accepted explanation with the work where appropriate. Record material assumptions and unresolved questions. A polished summary is useful only if it matches the actual change.
DORA's verification findings give a research-based reason to count this effort rather than assuming it disappears when generation becomes faster. They do not prove that every generated change creates extra work. Your trial should permit both findings: assistance may reduce total effort, or it may produce a draft whose checking costs exceed its benefit.
Stop the trial if you cannot inspect the consequence of a change competently or if the proposed input or permission is outside your authorization. Narrow the task, seek the relevant expertise, or use the established process. Those actions preserve the possibility of a useful test later. They also prevent an experiment from quietly becoming an unreviewed production decision.
What should a technical lead measure before expanding AI use?
Measure the path to accepted work. Generation time is one part of that path. Input preparation, clarification, review, rework, integration, and later explanation may be other parts. If the change shifts work to a colleague, include that work instead of calling it a personal productivity gain.
Choose a fair comparison. A carefully specified AI-assisted task should not be compared with an ordinary task that was allowed to remain ambiguous. If better preparation explains much of the improvement, that is still valuable information. It means you should investigate better preparation as well as the tool.
Define the acceptance standard before seeing the outcome. You might require that the change satisfies a known behavior, preserves an existing interface, and can be explained by the engineer responsible for maintaining it. Choose standards suited to the actual task. Avoid a numerical score that implies validation you do not have.
Record both time and quality. A faster change with a serious omission is different from a faster change that meets every required check. A slower attempt that teaches you an important constraint may be useful for learning but unhelpful as a recurring production method. Give each result its proper interpretation.
METR's measurement update explains why concurrent agents complicate time comparisons. System runtime and human effort are different. A model can be working while you do something else, yet still require preparation and a later review. Equally, several attempts can consume attention that does not appear in the final successful transcript. Keep the human activities visible.
Agree on the duration and scope of the trial with the responsible people. A limited number of representative tasks may answer an immediate operating question, while leaving broader questions unresolved. Do not convert one good result into evidence about every repository, developer, or future release.
At the review, decide what follows from the observation. Continue the same scope if it meets the standard. Revise the task or input if the failure is understandable. Stop if the required quality cannot be checked or the full process is not useful. Expand only when the evidence supports the specific expansion you propose. A pilot is valuable when it changes a decision, including the decision to decline the new workflow.
What can you do when your employer uses very little AI?
An ExperiencedDevs discussion asks whether a job with very little AI use is a sinking ship or an opportunity. The author's concern includes a locked-down workplace environment and uncertainty about falling behind. This is an observed question, not verified evidence about that employer or a representative survey of experienced engineers.
Treat the constraints as information. A restriction may concern customer data, security, contractual requirements, or an unfinished approval process. Ask the responsible person what the boundary is and what learning or experimentation is permitted. Do not bypass workplace controls to prove that you are keeping up.
You can separate professional literacy from deployment. Learning how to define a task, inspect an answer, understand limitations, and compare alternatives does not require putting proprietary code into an unapproved tool. The OECD distinguishes AI literacy from advanced AI engineering. That distinction can help you choose a learning objective appropriate to your responsibilities.
Where your circumstances permit, practice with public or personally owned material in a separate approved environment. Make sure ownership and permissions are actually clear. A public practice project can teach you how a tool responds to incomplete requirements, how much checking it needs, and what you can explain afterward. It will not reproduce every constraint of your employer's system, so record that limitation.
At work, you may be able to improve requirements, review, documentation, or coordination without introducing a new model. Those improvements matter because any future deployment will operate within the process you build. Investigate whether an approved internal experiment could answer a specific question, rather than asking for an unlimited change to policy.
If you are considering leaving, examine the whole opportunity. A job with more AI tooling may also have weaker supervision, less relevant domain work, or responsibilities you do not want. A restrictive job may offer valuable craft or leadership practice while its tool policy evolves. Neither environment is automatically the right choice. The career-change guide helps examine the larger move.
How can experienced engineers learn without giving away the practice?
Choose what you want to learn before deciding how much assistance to use. If your goal is to complete an already familiar preparation task, substantial help may fit. If your goal is to understand an unfamiliar library or design, letting a tool supply the finished solution may remove the very practice you intended to do.
Anthropic's skill-formation study involved 52 recruited, mostly junior developers learning an unfamiliar Python library. The AI-assisted group averaged 50% on an immediate comprehension quiz, compared with 67% without assistance. Task-time improvement was not statistically significant. The interaction patterns associated with stronger learning were not causal estimates of which prompting method works best.
This small, specific vendor-authored study does not establish long-term cognitive decline or tell you how every senior engineer learns. It does make a useful distinction visible: producing a solution and understanding the solution are different outcomes. You can define your practice to examine both.
For a learning task, first write the behavior you expect and the concepts you need to understand. Try an initial explanation or implementation yourself when that fits the goal. Use assistance for a question you can name, such as comparing approaches or explaining an error. Then close the answer and explain the result in your own words.
Change one relevant condition. Can you predict what will happen? Can you diagnose a failure without asking for a completely new solution? Can you identify why a proposed alternative would be unsuitable? These checks give you information about your current understanding. They are practical exercises, not validated measures of intelligence or universal rules about how much AI to use.
For mentoring, discuss the learning goal explicitly. An associate who can submit a working change but cannot explain its behavior needs a different next exercise from someone who understands the concept and is learning to review faster. Avoid judging only output volume. Keep a path by which people can develop the knowledge required to accept responsibility later.
Your own experience also needs renewal. Ask which part of your judgment depends on assumptions about tools, architectures, or customer expectations that have changed. Testing those assumptions is different from abandoning your expertise. You are examining where it still applies and where additional practice would make it more useful.
Will faster coding create more engineering jobs?
There are several possible responses to cheaper implementation. An organization may build more, reduce some costs, move work into a different service, or change how it staffs delivery. Which response occurs depends on demand, quality, organizational choices, and the surrounding economics. Faster completion in a task experiment does not establish the net employment result.
Be cautious with a simple argument that demand must always expand enough to absorb everyone. Be equally cautious with a simple argument that each task saved removes a person. Both skip the decisions that connect task capability to employment. Those decisions can differ across organizations and across periods.
The Stanford analysis revised in August 2026 found concerning patterns among younger workers in exposed occupations, primarily involving reduced hiring. Experienced workers did not show a comparable gap. The authors describe the findings as indicators rather than causal counts of jobs lost to AI. Education controls, earlier divergent trends, and differences across data sources matter to interpretation.
For a senior engineer, that result does not prove permanent protection. It also does not justify treating every difficulty in the job market as an AI effect. You can take concerns about the entry path seriously while asking what evidence exists about the particular role, employer, and market you are considering.
The BLS 2025-2035 projections provide a conditional scenario under stated assumptions. They are not a personal job-security promise or an unemployment forecast. Exceptional technological change can undermine historical relationships used in a projection. Use the official outlook as one source of context while recognizing what it cannot settle.
For your next decision, gather closer evidence too. What work is your organization approving? Which capabilities does it seek? Are responsibilities changing in the jobs you would actually apply for? Have the requirements changed, or only the language used to describe them? Compare real opportunities without turning a few postings into a universal market statistic.
Give yourself a way to update the judgment. A material change in the organization's plans, a relevant capability you can verify, or a change in the work available to you can justify reconsideration. Constantly refreshing general predictions may add little. The scenario guide gives the longer-term uncertainty a separate place.
How should an engineering manager respond to pressure for more output?
Translate the request into an operating question. More output could mean more prototypes, more accepted changes, a shorter wait for a customer, or a larger volume of code. Those are different goals. Ask which outcome matters and what quality or reliability requirements remain binding.
If the goal is faster customer delivery, find the actual delay. An implementation task may be slow, but the bottleneck could also be unclear requirements, a review queue, an integration dependency, or a decision no one has made. Increasing generation at the front of a congested process may leave accepted delivery unchanged while making the queue harder to inspect.
Make the proposed change visible to the people who will operate it. Who prepares inputs? Who checks the output? Who handles exceptions? Who has authority to accept a change? The O*NET information-systems-manager profile includes priorities, standards, feasibility, budgets, coordination, security, and recovery. Its task data are older and it is not a dedicated CTO study, but it supplies a useful reminder of the responsibilities a tool deployment sits within.
Keep disagreements concrete. An engineer saying "This is all hype" and a manager saying "Everyone must use AI" may be arguing past the same missing definition. A proposed trial with permitted inputs, acceptance criteria, and a review date gives each person something to assess. It may reveal a genuine opportunity or a requirement the demonstration never addressed.
Do not use the pilot to quietly settle a different staffing question. A tool's performance and the organization's responsibilities deserve separate decisions. If a team member's work becomes faster, ask what happens to their other tasks, learning, review capacity, and customer obligations. A measured task result does not by itself supply an organizational design.
You can advocate a practical experiment without claiming certainty about the economy. You can also recommend stopping a proposed deployment while remaining curious about another use. The most useful position is one you can explain in terms of the work and revise when relevant evidence changes.
Hypothetical example: a principal engineer tests assistance on a familiar service
Consider a fictional principal engineer, Mara, whose team maintains an established service. A director has seen an impressive coding demonstration and wants to know whether the team could shorten a recurring maintenance task. Mara agrees the question is worth testing. She does not begin by promising a productivity percentage.
The team chooses a narrowly scoped change involving a well-understood internal interface. It avoids a release-critical path and uses only material permitted in the approved environment. Mara records the behavior the change must preserve and identifies the person who can assess it. Another teammate writes acceptance cases from the existing requirement, rather than asking the same model to invent tests solely from its own implementation.
Before the assisted attempt, they reconstruct the ordinary process. The baseline includes clarifying the request, preparing the local environment, implementing the change, reviewing it, and producing an explanation the next maintainer can use. They do not treat the fastest remembered manual attempt as the entire baseline, nor compare a prepared assisted task with an unprepared manual one.
The tool receives a specific assignment and produces a proposed change. Mara asks the author to explain the assumptions and review it in smaller pieces. An unresolved question about how an existing consumer handles a missing value is recorded before acceptance. The trial can continue only after the responsible people settle that requirement. The system is not allowed to decide the customer-facing behavior on its own.
At the review, the team compares accepted work and the effort needed to produce it. Several outcomes would lead to different actions. If the process meets its standard with less total effort, they might repeat the same scope on another representative task. If generation is faster but review becomes much harder, they might narrow the assignment or stop. If improved preparation explains the benefit, they might adopt that preparation in both methods.
Mara also asks who learned from the attempt. The teammate responsible for maintenance needs to understand the behavior, even if the tool created most of the initial draft. That requirement prevents a successful demonstration from being mistaken for a successful learning exercise.
The example gives Mara a business conversation grounded in an observable test. It does not forecast her employer's headcount or describe a real company's result. Its point is the decision process: choose a checkable task, preserve responsibility, count the complete work, and let the observation determine the next move.
Hypothetical counterexample: more code makes the review queue worse
A second fictional team works on a system with many interdependent changes and a small number of qualified reviewers. Its manager wants to increase delivery volume. Contributors begin using an approved tool to produce larger patches, but the team has not changed how requirements are clarified or how review capacity is allocated.
The visible output increases. That does not yet establish that customers receive useful work sooner. A reviewer now has to reconstruct several decisions from a large patch. Some assumptions belong to another team. Some tests follow the implementation without independently checking the intended behavior. The review cannot responsibly be completed by reading the model's confident explanation.
For this hypothetical team, the next action is not another demand for more generated code. The manager and technical leads investigate where work stops. They may need smaller changes, clearer ownership of requirements, or a different review sequence. They might also decide that assistance is useful for preparing a focused comparison or identifying questions, while keeping the implementation trial limited.
The example illustrates a decision you should permit your own measurement to reveal: the attractive new tool may not address the current bottleneck. Better inputs and coordination may matter more than faster generation. DORA's qualitative findings describe tensions around verification and production readiness, but they do not prove this fictional team's result. The team would have to examine its own work.
Stopping the expansion is a legitimate outcome if the process cannot meet its acceptance requirements. It does not require an ideological conclusion that AI should never be used. Equally, acknowledging a useful narrower application does not require claiming the entire delivery process is solved.
This distinction matters for an accomplished engineer who feels pressure to be either enthusiastic or resistant. You can support an experiment while insisting that the result be judged properly. You can identify a real failure without turning it into a universal story. The professional decision concerns the work in front of you and the responsibility you have accepted.
What might you want from the next chapter of your technical career?
A capability question can conceal a preference question. You may be asking whether AI can perform a task while also wondering whether you still want that task to occupy most of your week. Keep the questions separate long enough to examine each.
If you enjoy hands-on engineering, name the practice you want to preserve. That could mean understanding a difficult system, investigating a failure, or turning a requirement into a clear design. Ask where your current or possible role gives you that practice and where it is being removed. Choosing some assisted work does not automatically require surrendering every part of the craft.
If you want broader responsibility, examine what that responsibility actually involves. A technical lead may need to coordinate decisions, make requirements legible, mentor others, and explain consequences to people outside engineering. A title does not tell you whether you enjoy that work. Try an appropriately authorized piece of it before treating it as the obvious next step.
You may discover that the central question is personal. Perhaps you understand the options and still postpone speaking to your manager. Perhaps you keep comparing tools instead of testing the project you want to build. Observe the specific behavior and its circumstances before assuming a hidden explanation. A real practical barrier needs a practical response. A repeated pattern that remains after the barrier is resolved deserves a closer look.
The meaning-and-work guide explores how professional identity can change when familiar tasks change. The decision guide helps turn incomplete information into a proportionate next step. These questions deserve room without requiring you to resolve the future of software engineering first.
You can begin with something modest: a learning session you can complete, a conversation with a clear question, or a proposed trial with an acceptance standard. The larger answer becomes more useful when it enters your actual calendar and circumstances. You retain the responsibility to examine what happens and decide what follows.
Compare your options
| Option | Question it can answer | What to examine | When to reconsider |
|---|---|---|---|
| Approved assistance on a familiar task | Does it improve accepted work in this process? | Preparation, review, corrections, interfaces, maintainability | Required quality fails or checking exceeds the benefit |
| A learning project with public material | Can I understand and evaluate a relevant capability? | Explanation, changed conditions, diagnosis, remaining limits | The tool completes the work while understanding remains unclear |
| A technical-lead responsibility | Do I want and competently perform broader coordination? | Authority, decisions, handoffs, stakeholder expectations | The role offers a title but little of the work you want |
| Improve the existing review process | Is the bottleneck generation or acceptance? | Change size, specifications, reviewer capacity, coordination | The change addresses the wrong delay |
| Investigate another role before moving | Does the opportunity fit my requirements and priorities? | Actual duties, permitted tools, supervision, learning, obligations | Assumptions about the role conflict with verified information |
Write one engineering decision you can test
Choose a task or professional question you genuinely face. Use the worksheet to make the next action inspectable. It organizes your thinking and does not predict employment or certify a deployment.
A reflection tool for planning your next step, rather than a predictive score.
- Name the decision in one sentence, including who has authority to make it.
- Describe the actual input, the required result, and the important constraints.
- Separate what you have observed from what you are assuming about AI or the market.
- Resolve data and action permissions before beginning the test.
- Choose a limited comparison and record preparation, review, corrections, and acceptance.
- Set a review date and a condition that requires stopping before that date.
- Decide what the observation would justify next, including revising or declining the process.
Hypothetical completed worksheet. A technical lead wants to know whether an approved assistant helps prepare a design comparison. The assignment uses permitted internal material and asks for a draft against agreed constraints. The lead retains the decision and does not permit repository changes or customer commitments.
The required result is a comparison that accurately represents the source material, labels unresolved requirements, and supports each consequential claim. Another qualified teammate checks it. The lead records preparation, review, and correction effort as well as generation. A factual omission affecting the decision pauses the trial; a polished layout cannot compensate for it.
At the agreed review, they decide whether to repeat, narrow, or stop the assignment. A successful draft would support another similar test, not a conclusion about all engineering work. Separately, the lead wants to discuss a broader technical role with their manager. They record that conversation as a personal next action instead of waiting for the tool trial to decide it for them.
You can be good at solving technical problems and still feel stuck on the question of what you want to build next. If you understand the possible paths but keep postponing a useful test, bring that gap to AI and the Andes Retreat. The five-day seminar in Peru's Sacred Valley, for 8-15 participants and with no plant medicine, gives you space to examine what is driving your behavior and choose an action to test at home. Support and accountability continue afterward.
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, audience discussions, and the existing seminar FAQ library informed these questions. Some wording has been adapted to this guide.
Are software engineers still needed with AI?
Current research shows assistance with selected tasks, not dependable replacement of an entire engineering role. The developer task inventory includes requirements, design, testing, integration, maintenance, and coordination. Examine how those responsibilities change in your actual organization. Some tasks may require less implementation effort while others acquire more review work. Continued need in one setting is not a guarantee of employment in every setting, and a successful coding demonstration does not settle the staffing decision.
Will AI replace senior software engineers in 2026?
There is no established universal replacement date for senior software engineers. The published developer experiments measured selected task outcomes rather than the disappearance of whole roles. Look at changes in your responsibilities, your employer's plans, and the opportunities you would actually pursue. Avoid treating seniority as permanent protection, while also avoiding a calendar deadline unsupported by the evidence. A useful response is a concrete assessment and learning plan, rather than a prediction about every senior engineer.
Will AI reduce software engineer jobs?
The net result depends on demand, staffing decisions, costs, and how organizations change their work. A task becoming faster does not supply that result on its own. The Stanford employment analysis identifies concerning younger-worker patterns but does not establish a causal universal job-loss count. Track the work your organization needs and the requirements of relevant opportunities. You can investigate change without assuming either that all demand disappears or that productivity guarantees more hiring.
How should a software engineer learn AI?
Choose a task relevant to your responsibilities and a specific learning outcome. Practice defining the requirement, checking the proposed result, and explaining its limits. The OECD separates AI literacy from advanced AI engineering; you do not need to treat every use as a decision to become a model specialist. Keep a record of what you can now do and explain. If the practice uses workplace material, resolve permission and data requirements before introducing it to a tool.
How do I verify AI-generated code?
Check it against an independently stated requirement. Review manageable changes, examine assumptions and interfaces, and use tests that cover meaningful behavior rather than merely reproducing the implementation. Confirm that the responsible engineer can explain the result and that it fits the actual environment. DORA's analysis describes verification effort alongside faster generation. Count that effort in the trial. If you cannot competently inspect an important consequence, narrow the assignment or obtain the appropriate review before accepting it.
How can an engineering manager use AI?
Investigate a specific preparation, analysis, or coordination task with clear inputs and an inspectable result. For example, an approved process might draft a summary of open technical decisions from permitted notes. Someone still needs to verify the summary and own the decisions. The manager task profile includes priorities, standards, budgets, coordination, and recovery; it is not an AI replacement forecast. Judge assistance by the full process and the requirements of your organization, rather than output volume alone.
What should a senior engineer check before choosing an AI tool?
Start with the task, permitted material, required capabilities, review method, and the actual account arrangement. Check current provider documentation and your organization's policy before connecting the tool. A product's marketing category does not establish permission to share proprietary code or customer information. Compare candidates on the same approved task, including preparation and correction effort. This guide does not rank current products or certify a tool as safe. The useful choice is an arrangement you can inspect and operate responsibly.
Which security questions should I resolve before an AI coding pilot?
Identify what information the tool can access, what actions it can perform, and who has approved those permissions. Check the service terms, connected components, and the consequences of an incorrect action with the appropriate specialists. Keep the first test within a scope you can review and recover from. A coding task and a deployment permission are separate decisions. This is a planning prompt, not a complete security assessment; unresolved requirements should be settled before sensitive information or production authority enters the pilot.
Is programming still worth learning in 2026?
It can be worthwhile when understanding program behavior matters to the work you want to do. Choose the depth according to your goal, rather than studying only to defend against a speculative replacement date. If you need to maintain, review, or change software, test whether you can explain it and diagnose a failure. The skill-formation study distinguishes completing a supported task from learning it. Its narrow results do not prove a universal rule about every person's education.
Am I falling behind if my engineering job uses very little AI?
Limited use alone does not establish that your job is a bad opportunity. Ask why the restriction exists, what is permitted, and which responsibilities you are developing. You may be able to practice with public or personally owned material outside the restricted process, if your circumstances allow. Keep ownership and permissions clear. Compare possible jobs across their actual work, supervision, and learning opportunities. More tools do not automatically mean a better role, and bypassing workplace controls is not a sensible learning plan.
What does responsible, productive AI use look like for an experienced engineer?
It begins with a task whose result you can inspect, material you are allowed to use, and a person who remains responsible for acceptance. Try a narrow draft, comparison, or explanation before expanding authority. Count review and correction alongside generation. DORA's findings explain why production readiness deserves separate attention. A useful trial can also show that the tool adds little value to a task. Responsible use includes accepting that result and choosing a better-fitting process.
How should I assess dependence on an AI service whose price may change?
Record the actual plan and usage terms, and separate vendor charges from the team's operating effort. Ask what happens if access changes, the price rises, or the service stops fitting your task. Keep enough understanding and documentation to evaluate alternatives or return to an appropriate manual process. This does not require predicting a provider's future pricing. It requires knowing what the workflow depends on now and deciding which dependencies your organization is willing to accept.
What should we do when AI-generated pull requests become too large to review?
Reduce the scope of each change and make its requirement and assumptions clear. Examine whether the actual constraint is review capacity, coordination, or incomplete specifications. More generated output does not establish faster accepted delivery. Keep responsibility with the contributor and the authorized reviewer, and measure the full path to acceptance. DORA describes verification tensions, but your team must inspect its own work. Stop expansion if important changes cannot be reviewed competently, then revise the process before trying again.
Should I give an AI tool access to my entire codebase?
Only consider access that your organization has explicitly approved for the actual service and account arrangement. A whole-codebase assignment can include information or authority beyond what the proposed task requires. Identify the specific need, permitted material, review standard, and recovery arrangement first. A broad demonstration does not settle confidentiality or production requirements. If those questions remain unresolved, use a narrower approved scope or public practice material. The decision needs the appropriate technical, security, and contractual review for your environment.
Should junior engineers deliberately use less AI while learning?
Choose assistance according to the learning objective rather than imposing one universal amount. If the purpose is to understand a new concept, preserve opportunities to explain the behavior, change a condition, and diagnose a failure yourself. Anthropic's small skill-formation study found an immediate quiz gap in one learning setting; it does not establish long-term outcomes for every junior engineer. Discuss the goal with the mentor and assess understanding separately from the speed of producing an answer.
Could engineering experience become more valuable as AI improves?
Experience may help with particular requirements, review, and operational judgments, but its value depends on the task and the organization's needs. Do not convert that possibility into permanent career immunity. Test where your knowledge improves an accepted result and where your assumptions need updating. The developer field experiments found differing benefits by experience in code completion; they do not price future senior judgment. Demonstrate relevant work while continuing to learn, rather than relying on years served as the entire argument.
How do I distinguish a working AI prototype from production-grade software?
Name the conditions needed for the actual release, then ask which ones the prototype has demonstrated. Inspect important exceptional behavior, integrations, access, and recovery requirements with the responsible people. The appropriate checks differ across systems and consequences. DORA's qualitative analysis distinguishes fast prototypes from production readiness. A prototype can still be useful while leaving release conditions unresolved. Record the remaining work explicitly instead of treating a successful demonstration as the final acceptance decision.
How can I discuss concerns about mandatory AI use with management?
Describe the actual work concern and propose a way to examine it. That could be an unresolved data permission, a review burden, a learning requirement, or a task that does not benefit from the proposed tool. Ask what outcome management wants and which acceptance requirements remain binding. Suggest an approved trial with a review date where appropriate. Keep wider ethical concerns explicit too. This guide cannot settle an employment dispute; use your organization's proper process when the issue requires one.
How can we prevent AI prompting from replacing understanding of the system?
Require the responsible engineer to explain meaningful changes and verify them against the intended behavior. Preserve learning tasks in which people can diagnose a failure or predict the effect of a changed condition without receiving a finished answer. Record accepted decisions where the team can maintain them. Skill-formation research provides a reason to distinguish output from comprehension, with narrow study limits. Avoid judging understanding solely by how many changes someone submits or how confident their generated explanation sounds.
What if solving technical problems no longer feels like worthwhile work?
Examine what feels unimportant: the customer problem, the product's purpose, the daily practice, or your role in it. Those lead to different decisions. A tool may change an activity without answering why you want to do the work. Name one commitment you want to test and the practical conditions around it. The meaning-and-work guide gives this question more room. If you understand the options but repeatedly postpone acting, examine that specific behavior before assuming a new job will resolve it.
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.
- Skills in the AI age
- Employment Projections and Occupational Outlook Handbook: 2025-2035
- Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of Artificial Intelligence
- We are Changing our Developer Productivity Experiment Design
- How AI Impacts Skill Formation
- The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers
- Balancing AI tensions: Moving from AI adoption to effective SDLC use
- O*NET 15-1252.00: Software Developers
- O*NET 11-3021.00: Computer and Information Systems Managers
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.
- Audience question, r/ExperiencedDevs: Over reliance on AI
- Audience question, r/ExperiencedDevs: Examples of useful/responsible AI usage
- Audience question, r/ExperiencedDevs: Interviewed candidates for “AI engineer” roles this week, my god is this really where our industry is going?
- Audience question, r/ExperiencedDevs: Over reliance on AI
- Audience question, r/ExperiencedDevs: Examples of useful/responsible AI usage
- Audience question, r/ExperiencedDevs: Am I right to deliberately use less AI early in my career?
- Audience question, r/ExperiencedDevs: Job requires/uses very little AI. Sinking ship or goldmine?
- Audience question, r/ExperiencedDevs: Struggling with moral implications of AI
- Audience question, r/ExperiencedDevs: Giving your codebase entirely to the AI
- Audience question, r/ExperiencedDevs: A lot of you all don't have an AI problem, you have a culture problem.
