Over the past few months, we surveyed all 30 members of our delivery team, 30 people across 7 departments, about exactly how we use AI in software development. Developers, QA engineers, product managers, designers, DevOps, and business analysts. We weren’t looking for hype. We wanted honest answers about where AI saves time, where it struggles, and where human expertise remains irreplaceable.

What came back is the clearest answer we’ve ever had to a question many people are Googling right now: how do software developers actually use AI tools? People use AI in production, for client work, and to meet deadlines.

Every one of our 30 team members uses AI. Every one of them still reviews its output before it reaches a product. The average productivity gain is about 30%.

How Do Software Developers Use AI Tools?

Software developers use AI tools mainly to accelerate well-defined, repetitive, or research-heavy work: writing tests, generating scripts and migrations, analyzing unfamiliar code, drafting documentation, and writing SQL, while keeping architecture, complex business logic, and final quality review in human hands. Across our team, the use of AI tools produced an average productivity gain of about 30%, and 100% of developers reviewed AI output before merging it.

The Numbers We Actually Measured

Vague claims about tenfold productivity are precisely what we’re trying to avoid, so let’s be specific about what the survey found.

AI Tools Our Team Uses

We’re deliberately not loyal to a single tool. Different models really are better at different jobs, and pretending one wins everything is how you end up with mediocre output across the board. Here’s the actual stack, straight from the survey.

In practice, this is how we choose between AI tools:

• Gemini for research and analysis over large data sets.
• ChatGPT for broad tasks and anything that builds on earlier context.
• Claude for code, legacy analysis, and MCP integrations, as it reads unfamiliar codebases best.
• Cursor is useful, but we deliberately limit its scope.
• Paid tiers are preferred because they yield materially better results.

That last one came through loudly. Free tiers produce noticeably worse output, including flat-out errors in things like formulas. About 60% of the team pays for premium plans.

Where AI Coding Tools Genuinely Shine

The averages hide the interesting part. Gains are wildly uneven, not just between departments but between two developers sitting side by side. Here’s where the value actually showed up.

Development (14 people)

These are real tickets. A SQL performance problem that once took three or four days was resolved in about an hour. Migration scripts that took an hour are done in five minutes. That’s not hype; it’s the kind of grinding, well-scoped work AI is genuinely great at.

But the same developers were just as specific about where AI actively hurts if you let it run unsupervised:

• “Solve it at any cost.” It often produces code that works but ignores better architectural decisions.
• Redundant, duplicated code. It rewrites existing validation and ignores existing logic.
• Scope creep. It edits unrelated functions or files it was never asked to touch.
• Recursive “fixing.” Fix/test loops with no real progress — one dev watched it spin for 3+ iterations.
• Cursor touching too much. Hard to track the diff on a 100-file commit.
• Outdated libraries. It references deprecated methods even when you name the version.
• Long-chat decay. It loses the thread after enough messages.

Read that list again and notice something: none of it is a reason to stop using AI. Every item is a reason you need an experienced engineer reviewing what it produces. Which is the whole argument.

PM / PO

Operational work turned out to be a near-perfect fit.

The Part Most Vendors Leave Out: Where AI Fails

If a team only shows you the wins, that’s marketing, not reporting. Here are the complaints the whole company raised, ranked by severity.

AI tools are APIs. The processing parameters can change without warning. The model can get worse the moment a new version ships. The token algorithm can change. Your build’s behavior and its cost can shift because an AI provider two steps removed from you pushed an update overnight. Predictability is genuinely in question, which is why we treat AI as a powerful assistant within a controlled process, never as the autonomous author of your product.

The most dangerous version of this scenario shows up when you lean on AI agents instead of assistants: the design and detailed-verification layer can quietly vanish. Our stance, shaped directly by this survey, is simple: AI belongs in the hands of an engineer who owns the outcome.

How AI Changed Software Development Work

Here’s the finding that reframes the whole conversation. AI didn’t just make our people faster at their existing jobs. It changed what the job is.

That’s the line the whole team keeps landing on, the consensus of all 30 people:

AI replaces “writing lines of code and text.” It does not replace thinking, responsibility, or engineering judgment.

The work moves up the stack toward architecture, review, and decisions. The barrier to entry for new technologies (Playwright, TypeScript, SQL for QA) has dropped significantly. But knowing the language and the system got more important, not less, because that’s what lets you review and debug well.

How We Use AI Responsibly: Our Working Practices

“We use AI responsibly” means nothing without specifics, so here are the actual habits the team converged on.

Prompting

• Be explicit: “do X,” “don’t do Y” — concrete constraints in every request.
• Give full task context plus access to the existing code.
• Have the model ask when something’s unclear rather than invent an answer.
• One chat, one role, one topic. Start fresh after 3–4 exchanges to avoid context rot.

Workflow

• Start with the overall context, then break the work into small pieces.
• TDD with AI: AI writes the tests, a human refactors, and AI generates the implementation.
• Small commits, so rollback and review stay easy.
• Pipeline across models: each AI does what it’s best at; the human synthesizes.
• During incidents, AI and humans investigate in parallel.
• Cross-check one model against another (Gemini ↔ ChatGPT).

Tool choice

• Match the tool to the task (see the routing guide above).
• Keep Cursor’s change scope under control.
• Pay for the premium tiers.

Why This Matters When You Choose Who Builds Your Software

We’ve audited vibe-coded SaaS products and found nine critical issues, reviewed Lovable from prototype to production, and helped founders stabilize systems that AI built but couldn’t scale. The through-line never changes: AI is a multiplier for people who know how to steer it and a trap for people who trust it without checking.

That’s not an argument against an AI-assisted vendor. It’s an argument for asking harder questions. Before you pick who builds your product, ask:

• Which tools do you use, and for which tasks? A real answer is specific, like the table above.
• Who reviews AI-generated code before it ships? The only acceptable answer is a qualified human, every time.
• How do you handle the things AI is bad at: architecture, complex business logic, and scope control?
• What’s your policy on autonomous agents versus assisted development?

At LaSoft, the answers are built into how we work — and this survey is the evidence. Thirty people use AI every day. Thirty people review its output every time. The speed is real, about 30% on average and far more on the right tasks, but the responsibility never leaves human hands. AI changed how we build software. It didn’t change who’s accountable for it.

FAQs