What Are People Actually Using AI For in Software Engineering Right Now?

By Marc Boudria, Chief Innovation Officer at BetterEngineer.com

There is a strange tension in software engineering right now.

Every executive deck implies that AI is about to reduce development to a prompt box. Meanwhile, many senior engineers are quietly rolling their eyes, because they have seen what happens when a confident demo meets a real codebase, a brittle deployment pipeline, undocumented business logic, and three production fires before lunch.

Both sides are missing the point. AI is being used in software engineering. A lot. Stack Overflow's 2025 Developer Survey found that more than 84% of respondents are either using or planning to use AI tools in their workflow, while trust in those tools has dropped sharply. Only 29% said they trust AI output, and 46% actively distrust it.

That is the real story: adoption is high, but confidence is not. So the question is not whether developers are using AI. They are. The better question is: what is actually helping, and what is just performance theater?

Where AI Actually Fails in Software Engineering

1. Autocomplete Is Not an Engineering Strategy

Autocomplete is useful. But there is a meaningful difference between "this saved me from typing a repetitive function" and "this improved our engineering organization."

The problem is that code volume is not productivity. Generating code faster only helps when the generated code is correct, understandable, secure, maintainable, and aligned with the system it is entering. That is a much higher bar than "it compiled."

Early GitHub Copilot research found that developers completed a JavaScript HTTP server task 55.8% faster with AI assistance, but this was a constrained, isolated task, not an enterprise codebase full of legacy decisions and regulatory requirements.

More recent data complicates the story. A METR randomized controlled trial with experienced open-source developers working in mature repositories found that when AI tools were permitted, developers took 19% longer to complete tasks despite expecting to be faster.

AI coding tools are not useless. But the blanket claim that AI automatically makes developers faster is not supported by the evidence. In real codebases, the tax is review, correction, context management, and security validation. Almost right is where engineering time goes to die.

2. AI Agents Don't Fix Broken Knowledge. They Amplify It.

The enterprise agent demo is seductive: "It pulls from Jira, Slack, Confluence, GitHub, and our internal wiki." The uncomfortable question: does it know which of those sources is correct?

Most organizations do not have a retrieval problem first. They have a knowledge quality problem: stale documentation, contradictory sources, and unclear ownership. An AI agent aggregating internal systems does not solve that. It gives the mess a friendlier interface.

The 2025 DORA report frames this precisely: AI is an amplifier. Strong engineering systems get leverage. Weak systems get faster confusion. AI does not create operational maturity. It reveals whether you had any.

3. AI-Generated Tests Pass But Don't Catch Bugs

Point AI at a function, generate tests, and watch them pass. Everyone claps.

But passing tests is not the same as meaningful tests. AI-generated test suites often validate the current behavior of the code, even when that behavior is wrong. They miss edge cases, business rules, boundary conditions, and the failure modes that only surface after years of real users doing unexpected things.

A test suite that proves code already does what it does is not an engineering discipline. It is a ceremony. AI can draft tests. A human still has to understand what failure matters.

4. Good Architecture Requires Context. AI Has None of Yours.

AI can produce compelling architecture recommendations. Event-driven services, Kafka, Kubernetes, CQRS, feature flags — it will suggest all of it confidently.

What it does not know is your company. It does not know your team has two backend engineers, one of whom also handles support. It does not know procurement takes six months, or that your "temporary" billing system is a decade old with four downstream reporting workflows no one wants to touch.

Architecture is decision-making under real constraints. AI can explore options and compare tradeoffs. But when it makes recommendations without understanding staffing, compliance, deployment maturity, and operational support, it is not doing architecture. It is doing architecture cosplay.

5. "AI as a Learning Tool" Only Works When There Is Still Someone to Learn From

The pitch sounds reasonable: juniors use AI to learn faster, get unstuck, and explore codebases without constantly interrupting senior engineers. In the right environment, that can be true.

But many companies have already cut too deeply. They laid off experienced engineers, froze hiring, reduced mentoring capacity, and then framed AI as the solution. That is not a strategy. It is a coping mechanism with a subscription fee.

Junior developers need time, review, context, and access to senior engineers who can explain not just what the code does, but why the system exists the way it does. AI does not fill that gap.

Worse, it can make junior developers feel more productive while reducing comprehension. They ship code that they cannot fully explain. They accept answers they do not know how to challenge.

AI is only a learning accelerator when there is still a learning environment.

6. AI-Generated Code Creates a Verification Gap and a False Sense of Security

The more you trust AI code, the less you should. Sonar's 2026 State of Code Developer Survey found that 96% of developers do not fully trust AI-generated code to be functionally correct, while AI-assisted code is becoming an increasing share of what developers produce.

That trust gap is dangerous. A Stanford-affiliated study published through ACM found that participants with access to an AI assistant wrote significantly less secure code than those without one, while also being more likely to believe their code was secure.

That combination should concern engineering leaders. Not because AI writes bad code every time. But because AI can produce code that looks normal enough to pass a tired human review. That is how verification debt accumulates quietly.

Where AI Actually Delivers in Software Engineering

The pattern across successful AI use in software engineering is consistent: AI works best when the task is bounded, the context is available, the output is reviewable, and the cost of being wrong is manageable.

1. Boilerplate Is Exactly What AI Was Made For

Generating repetitive, well-defined code — DTOs, API handlers, form scaffolding, validation structures, migration drafts, configuration templates — is one of the most reliable uses of AI in engineering.

The key phrase is known patterns. AI is strongest when the developer already knows what good looks like and is using the tool to reduce typing, not outsource thinking. This is not revolutionary. Most useful tools are not. They are just useful.

2. AI Solves the Blank Page Problem in Documentation

Documentation is one of the clearest wins. Not because AI understands your system automatically, but because it can turn rough notes, code comments, PR descriptions, and implementation details into a first draft faster than most engineers want to do manually.

AI can help draft README files, API usage examples, onboarding guides, internal changelogs, release notes, and runbook outlines. A human still needs to verify the content, but here the AI is not pretending to be the final authority. It is helping overcome the blank page problem.

3. Developers Get Faster Orientation in Unfamiliar Codebases

AI can help a developer ask questions of an unfamiliar codebase: Where is this function called? What are the likely side effects? What module owns this behavior? What does this error trace imply?

It will hallucinate. It will misread intent. But as an exploratory tool, it can reduce the time it takes to form an initial mental model, particularly when engineers are dropped into legacy systems or unfamiliar services.

Used correctly, AI becomes a map-making assistant. Used incorrectly, it becomes a confident intern with root access. Those are not the same thing.

4. Synthetic Data Generation Is a Genuine Engineering Win

AI can generate realistic test data: fake users, edge-case payloads, malformed inputs, localization variants, boundary conditions — data that feels more real than "John Test" and "foo@example.com."

This is useful for prototyping, stress-testing assumptions, and building internal demos without exposing production data. The caveat: synthetic data is not automatically representative data. For fraud detection, clinical logic, financial workflows, or anything where distribution matters, it requires serious scrutiny. For standard software engineering workflows, it is a strong practical win.

5. AI Helps Translate Product Intent Into Technical Drafts

AI is useful for turning a messy product requirement into a structured technical breakdown — draft acceptance criteria, ticket descriptions, dependency lists, and edge cases to consider.

The keyword is draft. A senior engineer still has to validate it. But for teams that struggle with vague requirements, AI can reduce the friction between product thinking and engineering execution.

6. PR Descriptions and Code Reviews Get Better 

AI can summarize a diff, explain a change, highlight likely risk areas, and draft a PR description before a human reviewer looks at it.

This is not the same as letting AI approve code. It is using AI to prepare human reviewers for more efficient reviews. That distinction matters. AI should not be the accountable party, but it can help the accountable party move faster.

What Engineering Leaders Should Be Asking

The answer is not "ban AI" or "AI everything." Both are lazy positions. The right move is to define where AI is permitted to help, where its output must be reviewed, and where it is not mature enough to be trusted.

Stop asking: How do we get more AI into the workflow?

Start asking:

• Where does our team lose time to repetitive, well-understood work?
• Where do we suffer from poor or absent documentation?
• Where do developers need faster orientation?
• Where are we generating low-risk scaffolding?
• Where would AI output create security, compliance, or maintainability risk?
• And critically: are we using AI because it helps, or because someone wants to say we are using AI?

That last question is the uncomfortable one. It is also the one that matters most.

The Bottom Line: AI Is a Tool, Not a Strategy

AI is useful in software engineering when it is treated like a tool with defined applications.

It accelerates bounded tasks, helps produce drafts, and supports exploration and boilerplate. It helps competent developers move faster through certain kinds of work.

It does not fix broken engineering cultures or replace senior judgment. It does not substitute for mentorship, testing discipline, security review, or product thinking.

The companies getting real value from AI are the ones asking honestly where the tool actually fits.

The real question is not how much code AI can generate, or how many developers it can replace.
It is: where can AI reduce friction without reducing accountability?

That is where the value is. Everything else is theater.

BetterEngineer works with companies that want practical technical leverage, not another round of buzzword strategy. We help teams evaluate where AI can realistically improve engineering workflows, where it introduces risk, and what talent, process, and governance are required to make it work.