iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
AI can help engineers generate and change code, but it does not make software engineering automatic. Its value depends on the surrounding system: clear priorities, sound tests, security practices, code review, and responsibility for what ships. The practical goal is not to let a model take the reins; it is to direct its assistance and verify the result.
How is AI changing software engineering?
AI is becoming a capability inside engineering workflows, helping with tasks such as drafting code and other development work. That can change how quickly an individual gets an initial result. It does not remove the engineering work needed to determine whether that result fits the product, behaves correctly, or can be maintained.
DORA’s 2025 State of AI-assisted Software Development draws on survey responses from nearly 5,000 technology professionals worldwide and more than 100 hours of qualitative data. Its central conclusion is that AI amplifies organizational strengths and weaknesses: teams with effective engineering practices may be better positioned to use it, while weak coordination or poor validation can magnify existing problems. This is a reported research finding, not proof that every organization will experience the same effects.
Recommended Free Tools
“AI’s primary role in software development is that of an amplifier. It magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones.”
— DORA, State of AI-assisted Software Development, 2025, as presented in the report abstract on Google Research.
Does AI actually make developers more productive?
It can help with individual work, but perceived productivity, time saved on a task, and successful delivery of reliable software are different measures. DORA’s March 2026 article reports that 90% of technology professionals use AI at work and more than 80% believe it has increased their productivity. Those figures describe reported use and belief; they are not an independently measured productivity gain for every developer or team. DORA also notes that time saved in initial generation may be redirected to auditing and verification (DORA, “Balancing AI tensions: Moving from AI adoption to effective SDLC use,” March 10, 2026).
DORA’s 2024 report found a tradeoff: AI adoption was associated in its findings with increased individual productivity, flow, and job satisfaction, alongside negative effects on software delivery stability and throughput. These are reported findings, not guaranteed outcomes for each team. They illustrate why faster task execution alone cannot establish that a team is delivering more reliably or sooner (DORA, Accelerate State of DevOps Report, 2024).
Can you trust AI-generated code?
Trust it as a proposal to evaluate, not as a result that is correct merely because it looks plausible. The sources cited here do not establish that any particular coding assistant is secure or insecure, nor do they show that generated code is uniformly reliable. A human team remains accountable for deciding whether a change meets requirements and is safe to ship.
That distinction matters because an implementation can compile and still misunderstand the intended behavior, miss an edge case, create a security issue, or make future changes harder. The appropriate level of scrutiny depends on the change’s impact and the consequences of failure. A small, reversible edit and a change affecting access controls or sensitive data should not receive identical review.
What should developers review in AI-assisted changes?
Review the change as engineering work, not just as generated text. These checks are practical guidance rather than a measured product comparison:
- Requirements: Does the change solve the requested user problem, including the relevant edge cases?
- Behavior: Do tests cover expected behavior and failure paths? Run the project’s appropriate checks rather than relying on a plausible explanation.
- Security: Check how the change handles identity, permissions, input, sensitive data, and external dependencies where relevant.
- Integration: Does it fit the surrounding architecture, interfaces, and operational assumptions?
- Maintainability: Can another engineer understand and safely modify it? Avoid accepting unnecessary complexity just because it was quick to generate.
- Evidence: Confirm that claims about behavior, dependencies, or compatibility are supported by the code and project documentation.
Verification takes time and should be planned as part of the task. If generating an implementation is quicker but reviewing it takes longer, the relevant question is whether the complete, validated workflow improved—not whether the first draft appeared sooner.
How can teams use AI without sacrificing quality or security?
Make AI use part of the software development lifecycle rather than a side channel that bypasses normal controls. Start with bounded tasks, preserve review ownership, and use the same quality and security expectations that apply to other changes. Teams should ensure that stable priorities, user needs, testing, and codebase maintenance remain visible alongside local productivity.
NIST’s SP 800-218A supplements version 1.1 of the Secure Software Development Framework with practices and tasks specific to AI model development across the software development life cycle. NIST describes the profile as relevant to AI model producers, producers of systems that use AI models, and acquirers. It is a framework reference for secure development, not a certification that a particular coding assistant or its output is safe.
- Set the boundaries. Decide which work is appropriate for AI assistance and what data or permissions the workflow may access, according to your organization’s policies.
- Keep changes reviewable. Prefer work that can be inspected, tested, and traced to a clear requirement; split broad changes when that makes review more reliable.
- Validate before integration. Use relevant tests, code review, and security checks before merging or releasing. Do not treat a generated explanation as evidence that checks passed.
- Watch delivery outcomes. Evaluate quality, stability, throughput, and user impact alongside developer perceptions of speed or flow. Adjust the workflow if review burden or production problems outweigh local gains.
What should engineering leaders measure?
Use measures that distinguish task-level assistance from team-level delivery. A workflow can make an individual feel faster while adding review effort or creating instability elsewhere. DORA’s findings make those dimensions important to examine together, rather than using adoption or output volume as a proxy for success.
- Individual experience: Ask whether developers report better flow, satisfaction, or ability to complete tasks.
- End-to-end delivery: Track whether work reaches users reliably and how changes affect throughput and stability.
- Verification cost: Account for the time needed to inspect, test, and correct assisted work.
- Long-term health: Consider maintainability, security practices, and whether changes support user needs over time.
For broader context on sustainable codebases and engineering practice, Google Research’s page for Software Engineering at Google: Lessons Learned from Programming Over Time describes a 2020 book by Hyrum Wright, Titus Winters, and Tom Manshreck. It predates the current generative-AI wave and is not an AI coding guide.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
