I believe every software team should be heavily using AI right now. I also believe it’s never been easier to ship something you’ll regret.
There are new surveys about AI and software teams coming out every week. After months of following along and participating in some, and a whole lot of conversations with engineering leaders, those two beliefs keep coming up together.
Why now?
There’s no question that the speed is real. Stanford researchers studied the work of more than 100,000 engineers and found AI made them 30 to 40% more productive on simple, greenfield work. The gains were biggest in Python and TypeScript, likely because that’s where the models have the most code to learn from. In Robby Russell’s 2026 Rails Community Survey, 74% of Rails developers said AI makes them more capable.
It’s changing how people buy, too. About half of the new inquiries we have received this year came through ChatGPT, Claude, and other AI tools. In 2023, we got one. If your team is still waiting for the other shoe to drop, your competitors aren’t.
What about the code you already have?
The same Stanford study I linked above found significantly smaller gains on complex, established codebases, often 10% or less improved productivity. If your patient portal or lending platform runs on a Rails app that’s been growing for ten years, that probably sounds about right.
AI struggles in old code for the same reasons a new engineer does. Nobody wrote the decisions down or debated them, the tests are thin, and the context for how we got here lives in a few people’s heads. Fix that, and AI gets a lot more useful. We’ve seen it take on the work that might otherwise get pushed aside, like basic upgrades, test coverage, or finally untangling that code everyone’s been afraid to touch.
On a recent engagement in a regulated industry where there’s no room for error, one of our consultants reported spending about 80% of their day focused on discovery work and making sure the SPEC was absolutely perfect. This required a lot of back-and-forth with stakeholders and ended up being the biggest bottleneck. However, once it’s complete, Claude was able to implement it without our consultant needing to be involved.
What should worry you?
Anyone on your team can now open a pull request with thousands of lines of code before lunch…and hopefully not land in your queue on Friday afternoon.
A PR that size can hide a lot of slop. It can hide worse, too. A permission check that stopped working and nobody noticed. Patient data that ended up in a log file. A rounding error in a payment that nobody catches until the auditors do. Veracode found that 44% of AI coding tasks introduced a security vulnerability, even when the code ran fine. In a regulated business, that’s how a bad week turns into a bad year.
We see this in our own work. Virtually every audit we’ve done on a vibe-coded app headed for a regulated industry has turned up serious flaws that needed a careful look and adjustments from our developers before the app could launch safely and in some cases legally. Most of those apps are TypeScript and React, since that’s what tools like Lovable build by default, and they often look finished long before they’re safe to launch into production. Apps that experienced developers vibe coded have held up better in our experience, which tracks. They use the same tools, and they know what to look for. The difference is the judgment of the person using them.
Are your leaders and engineers seeing the same future?
Here’s a theory I’ve come back to several times recently, especially after DHH’s infamous Rails World keynote. The gap between what executives expect out of AI and what engineers expect is getting wider, and it’s causing real friction on teams.
Many leaders assume AI will only take on more of the work. In Atlassian’s 2026 State of Developer Experience research, 64% of leaders said more AI usage leads to better outcomes, and 41% of developers said they use AI more than they need to because they feel it’s expected. Meanwhile, plenty of great engineers are holding on to writing code by hand for as long as they can. In Robby’s Rails survey, 51% said the pace of AI makes them anxious about the long-term value of their skills, and a third said they’re frustrated by the growing expectation to use it.
I don’t think either side is wrong. Leaders are right that AI is here to stay, and engineers are right that someone has to eventually own what it spits out. The teams moving fastest are intentionally closing that gap. They talk openly about where AI helps and where it doesn’t, and they give the people doing careful review of this output real credit for it.
What does good judgment look like?
- Keep pull requests small enough that someone can really read them. If nobody can review it, it’s not done.
- Write your standards down where the tools can follow them, in tests, linters and the rules you give your agents.
- Put your most experienced people on anything that touches patient data, payments or permissions.
When should you bring in help?
Your team can do most of this on its own. But when the stakes are high, like launching a product in a regulated space or changing a system that moves money or holds health records, it helps to have people beside you who’ve done it many times before. That’s especially true for the AI tools themselves. Many of the assistants and agents our clients ask for are built in Python, and they tend to sit right next to the most sensitive data a company has.
If you’re hiring for that, here are two questions I recommend asking. What will be true when you’re done? And what will my team be able to do after the consultants all go home? In our engagements, we agree on a short list of outcomes up front with our clients, and then leave behind the tests, the standards, and the habits that keep their teams moving.
Use AI, use it a lot, and use it now. Just make sure a human with good judgment is also involved reading and making sense of what it writes.