What engineering teams need to turn AI use into value

Nine out of ten developers use AI as part of their work in 2026, according to DORA research. Sonar reports another sign that experimentation has become routine: 72% of developers who have tried AI use it every day. Sonar sells developer tooling and benefits commercially when organizations invest in the quality of AI-assisted software, so its figure should be read with that interest in view. For engineering leaders, widespread use changes the problem: the harder engineering task is turning adoption into reliable business value.

AI adoption is widespread. Engineering judgment is still scarce.

Widespread adoption can produce disappointing results because value depends on where engineers use AI and what happens around the generated work. A team may concentrate AI use on writing code or documentation while leaving other useful software development lifecycle (SDLC) problems untouched. Faster generation can also outrun testing, review, security, and operating practices, leaving the organization unable to determine whether the extra output should ship. More output by itself does not establish more value.

That gap matters more when engineers work across several AI tools. “The 5 AI tools modern software engineers are using in 2026” describes an environment where developers use different AI tools for different purposes. Training centered on prompt engineering in one product covers only part of the work because engineers must also choose among tools, integrations, techniques, and applications across the SDLC. Their role requires decisions about how AI fits into an engineering system.

Those decisions shape the economics of adoption because organizations pay for subscriptions and token consumption. Tool access creates value only when engineers improve what they automate, the quality of the resulting work, or the efficiency of the process around it. Engineers also need to catch failures before higher development velocity spreads them further, because faster generation can increase correction costs along with output.

For that reason, engineering AI proficiency in 2026 spans eight areas: software-development fundamentals; tooling fluency; choosing where AI adds SDLC value; agentic systems; context and token management; spec-driven development; evaluation and human intervention; and safety and governance. Together, these areas cover four larger requirements: sound engineering foundations, selective expansion of AI use, operational management of execution and cost, and evaluation backed by governance. Training has to build competence across them while teaching engineers to decide when each belongs in a development process.

AI proficiency starts with software-engineering fundamentals.

That decision-making starts with skills that predate generative AI because AI increases the speed at which a development process produces work. The surrounding engineering process determines whether that speed produces useful software or accelerates failure. Training engineers to operate an AI tool cannot compensate for weak testing or poor discipline elsewhere in the SDLC because generated work still has to pass through those practices.

Unit and regression testing make this dependency concrete. If engineers cannot write good tests and the organization lacks a strong testing culture, AI-generated mistakes can move through development undetected. A system that generates more code can then increase the amount of questionable code requiring review and correction, so added velocity becomes added cost.

Testing is one instance of a requirement that extends across the SDLC because AI-generated work enters existing engineering processes. Engineers still need strong practices for planning, implementation, testing, deployment, and maintenance to assess generated output and use it safely. As AI accelerates individual steps, those conventional skills provide the basis for deciding whether the resulting software is correct and suitable for production.

The same foundation has to account for AI-induced skills decay. Engineers who repeatedly delegate activities that once exercised their technical judgment can lose practice in the underlying skills, so organizations need a deliberate strategy for keeping those skills current. Without such a strategy, greater dependence on AI can coincide with a weaker ability to inspect generated work, diagnose failures, or operate effectively when generated answers are inadequate.

Maintaining those skills is part of the AI investment because subscription and token spending cannot compensate for weak engineering practice. Capable engineers can use conventional development methods to constrain the extra velocity and identify errors before they spread through later stages. The practical baseline for AI proficiency is the entire SDLC and the engineering discipline needed to keep its outputs trustworthy.

More AI capability depends on choosing where to use it.

With that baseline in place, engineers can make better use of a wider AI tooling landscape. Different SDLC problems can call for different tools, plugins, and integrations, so instruction focused on good prompts in one product gives engineers a narrow set of options. Broader tooling fluency lets them choose and configure technology for the development problem in front of them.

Plugins show how that fluency can change an outcome. Superpowers, for example, can be adopted as a plugin to customize Claude, and this kind of customization can significantly affect development tasks. When a team gets weak results from a general-purpose setup, engineers with specialized training can test whether tooling or configuration is responsible before deciding whether AI fits the development task.

A wider toolset creates a practical question about where AI can help inside the SDLC. Code generation and documentation are two candidates, while planning and design can also use AI for architecture diagrams, API contracts, and Jira tickets. Testing can include gap analysis of existing tests or legacy code, and maintenance can include scanning for security vulnerabilities and analyzing error logs during troubleshooting. These examples expand the problems engineers can examine without implying that every problem needs AI.

That larger search space makes selection part of the engineering method. Teams can start with parts of the development process that already need improvement and consider AI as one candidate solution. A conventional solution may fit an application or business process better, while AI can add unnecessary complexity in some cases. Wider AI knowledge improves the decision because engineers understand more of the available options and their tradeoffs.

The same selection principle applies when teams move from back-and-forth prompting into agentic systems. An agentic system gives AI a structured process for taking actions toward a task, while a multi-agent system coordinates multiple such agents around developer work. Because an agent can perform several steps between a request and an outcome, engineers need to understand its architecture, limitations, and guardrails. These systems create control problems that an isolated model response does not create.

Agentic competence includes knowing how to build an agentic harness, the surrounding structure through which an agent receives tasks, uses tools, and operates within defined controls. The harness expands what a team can automate while creating places where engineers can constrain that automation. Understanding agentic systems gives engineers another technical option, but the development problem still determines whether that option is suitable.

Tokens, context, and specifications move cost control into engineering.

As AI becomes embedded in those workflows, spending decisions increasingly happen during engineering work. AI activity consumes tokens, and token consumption directly creates cost. Engineers choose models, determine how much context a task receives, and shape usage patterns while designing and operating the workflow, so many cost decisions happen alongside technical ones.

That placement gives engineers a different role from FinOps, the function responsible for managing and optimizing technology spending. Engineers can choose the best cost-fit model for a task, monitor how it is used, and recognize signals that a model’s context has become overloaded. Those choices affect spending while the work is being constructed, which means useful cost management depends on technical knowledge of the information and model capability a task requires.

Context management follows from that cost responsibility because supplying more material to a model affects both token consumption and model performance. Engineers need enough knowledge of token usage to recognize inefficient workflows and enough knowledge of models to change the design when necessary. Cost awareness consequently becomes part of implementation, where engineers can change consumption before usage accumulates.

Repeatability creates a related implementation problem as teams encode instructions for coding agents. Teams commonly use scoped rules files such as Claude.md, AGENTS.md, or Cursor’s .cursor/rules/ directory to direct behavior within a particular environment. As AI-assisted development expands, relying on these local instructions can make auditability, reproducibility, cost effectiveness, and governance harder to manage across teams and projects.

Spec-driven development (SDD) addresses that scaling problem by organizing development around specifications that make intended work explicit and repeatable. Pluralsight author Axel Sirota has written about SDD and its benefits for enterprise development, where consistency and oversight become important across teams and projects. Pluralsight sells technology skills training and benefits commercially from demand for enterprise development and AI upskilling, which gives it a stake in this framing. SDD can give an organization a stronger basis for tracing what an AI system was asked to do, reproducing the process, managing resource use, and applying governance.

Those specifications connect operating discipline to engineering quality because an AI workflow needs instructions that machines can follow and people can inspect. As workflows become agentic, more actions can occur between a human request and the final output. Specifications then become part of the engineering surface through which an organization defines expected behavior before evaluating whether the system delivered it.

Reliable AI requires evaluation, human intervention, and engineering-owned governance.

Once a specification establishes expected behavior, evaluation determines whether actual behavior stays within those expectations. Engineers need to recognize signals that an AI tool requires human intervention, including drift, where behavior or output moves away from the expected standard over time. They also need to troubleshoot implementation failures around APIs and SDKs because software connecting a model to the rest of a system can create failures that appear to be problems with AI quality.

Useful evaluation depends on specifications that are rightsized for machine and human comprehension. A specification needs enough detail to direct and assess the AI while remaining clear enough for an engineer to inspect and reason about it. That balance matters especially when an engineer has to diagnose why an agent behaved incorrectly, because agentic workflows can contain several intermediate actions before the final result appears.

Agentic behavior also requires evaluation methods that can inspect those actions and results. Human-in-the-loop (HITL) evaluation deliberately inserts people into a process at points where their judgment is required, while LLM-as-a-judge uses a language model to assess generated output against defined expectations. Observability frameworks, which expose evidence about what a running system is doing, add information teams can use to detect failures, drift, and other conditions that warrant investigation.

Evidence from evaluation still leaves an organizational question about which actions automation can complete independently. A rule such as “Pull requests need human approval.” creates an explicit boundary that an engineering workflow can enforce. Leadership needs to supply guidance at this level so engineers have a shared approval policy across projects instead of inventing one separately for each implementation.

That boundary can change as the organization gains maturity and confidence. A team with stronger specifications, evaluation practices, operating evidence, and experience may decide that some activities need less manual review, while higher-risk actions continue to require sign-off. Human oversight is an engineering control whose placement can evolve with demonstrated capability, allowing approval requirements to match the risk and evidence associated with a workflow.

Changing the approval boundary raises the stakes for safety and governance because engineering teams have exceptional ability to create security solutions, while their access can also create serious security problems. Individual engineers therefore need practical rules for safe AI use, including keeping API keys and other secrets away from AI tools and withholding production database credentials from them. These rules make security part of everyday AI engineering practice at the point where sensitive access is available.

Project-level governance extends those rules into the systems engineers build. Engineers need to implement governance around credentials, agent permissions, specifications, evaluation, observability, and mandatory human approval. These mechanisms determine what AI can access, which actions it can take, how engineers inspect its behavior, and when a person must intervene, so governance becomes part of execution.

Agent guardrails make the relationship between policy and implementation especially clear. An organization can define a governance policy centrally, but engineers building the agentic harness have to translate that policy into technical boundaries around actual model and tool behavior. The same requirement applies to observability and sign-off because the workflow needs to record enough information to evaluate behavior and prevent an automated process from crossing a boundary that requires human judgment.

The resulting implementation links each safeguard to a specific engineering function. A specification defines expected behavior, evaluation tests actual behavior, observability makes operation inspectable, human approval covers actions that require judgment, credential controls limit access, and agent guardrails restrict what autonomous processes may do. Governance becomes concrete when engineers put those boundaries into the workflows where AI actually operates.

Key takeaways for decision-makers

• Build AI skills on engineering fundamentals: AI increases development velocity, making testing, review, deployment, maintenance, and technical judgment more consequential. Engineering organizations need practices that preserve these skills as developers delegate more work to AI.
• Choose AI based on the engineering problem: Tool fluency, SDLC knowledge, and agentic expertise help engineers identify where AI creates value and where conventional approaches fit better. Engineering managers can train teams to evaluate tools, integrations, and agentic systems against specific development needs.
• Treat AI cost control as an engineering responsibility: Model selection, context management, token usage, and specifications shape costs during implementation. Engineering and FinOps functions can align on standards that make AI workflows cost-efficient, reproducible, and auditable.
• Engineer evaluation and governance into AI workflows: Specifications, evaluations, observability, human approval, credential controls, and agent guardrails determine how safely AI operates. Technology leaders can define organization-wide policies while engineering teams implement those controls in the systems they build.