Ask a developer where their week actually goes, and very little of the answer involves typing. It goes to reading code somebody else wrote three years ago. It goes to tests nobody wanted to write, cleanup that never makes the sprint, and the weeks a new hire spends with access to everything and nothing they can safely ship.
AI has changed all four of those. That part is settled. The open question comes next: what you do with the hours that come back.
You have two moves available. Shrink the team and hold output flat, or keep the team and raise output. The first one looks like savings on a spreadsheet. The second one compounds. Here is where the time actually shows up, and why the second move wins.
Summary
Comprehension time, test writing, the maintenance backlog, and ramp-up all shrink once AI moves into the workflow, and the hours they return are the ones that never showed up on a roadmap. Teams getting real value from that draw the line at reversibility instead of approved tool lists, and they treat a green build as a claim to verify rather than a conclusion. Reinvest the hours and you get more output at the same cost, systems that stay serviceable longer, and a team you can staff against demand.
Place 1: Understanding Code You Didn’t Write
The most expensive thing about an unfamiliar codebase is not the change you make. It’s finding where to make it.
“When you’re new, or you’re working on several projects at once, you can spend 75% of your time trying to understand the code and figure out where to make your edits, versus actually making them,” said Doug Compton, Principal AI Developer at Slingshot.
Chris Chandler, Senior Developer at Slingshot, joined a project already well into development: 40+ developers he had never worked with, roughly 30 repositories, and no institutional history to draw on. He used to hunt down subject matter experts and ask them to dump everything they knew. Now he points AI at the repositories first, builds his own documentation, and arrives with specific questions.
“Research that used to take two or three days comes back in 15 or 20 minutes,” Chris said. “Even when AI doesn’t make the change for you, it points you in the right direction.”
Comprehension time never looked like a problem because it looked like work. It was work, but it produced nothing. Winning it back does not just make developers faster. It makes the worst systems in your portfolio approachable again: the old, undocumented ones that only two people understand.
Place 2: The Tests Nobody Wanted to Write
Unit tests went from a line item teams argued over to something that simply happens. Coverage stopped being a decision and started being a default.
“Nobody writes tests by hand anymore. There’s no reason to,” said Nathan Thomas, Senior Developer at Slingshot. “It’s one of the best things AI does, and it was one of the first things everybody adopted.”
The economics here flipped completely. “Unit tests used to almost double the cost of a project,” Doug said. “Writing the test took about as long as writing the code, and then every change broke something a developer had to go investigate.”
That cost explains every thin test suite you have ever inherited. Coverage was never really a quality debate, it was a budget one, and quality usually lost.
Cheap tests are not automatically good tests, though, and Nathan flagged a failure mode worth building policy around. AI wants to be helpful, and that instinct cuts the wrong way when something breaks.
“The test was supposed to enforce something,” Nathan said. “AI sees it failing, and it changes the test instead of fixing what broke.”
That inverts the entire point of a test suite. Treat a green build as a claim to verify, not a conclusion. Even with that check in place, the trade is lopsided: reviewing generated tests costs a fraction of what writing them did. Your team keeps the coverage and gets the week back.
Place 3: The Maintenance Backlog That Never Made the Sprint
Every development team carries a list of work everyone agrees is worth doing and nobody ever gets approval to do.
“Refactors were something you’d love to do, but they were too risky or took too long, so you hardly ever got to them,” Doug said. Cleanup followed the same pattern. That debt built quietly. Teams noticed it the day someone proposed rewriting the application from scratch.
“AI lets you address these a little at a time instead of waiting for them to build into a major issue,” Doug said.
Deferred maintenance works like debt. The longer you carry it, the more the eventual fix costs. Small, continuous paydown changes that math, which means the systems your business depends on stay serviceable years longer than they otherwise would. That is a capital argument, not a hygiene argument.
Boilerplate follows the same logic. Wiring up a standard CRUD endpoint took a developer an hour or two of monotonous, low-judgment work. Point AI at an existing example and it produces the same thing in minutes.
The team draws one hard line. “I wouldn’t let AI run database updates without reviewing them first,” Doug said. “Anything sensitive or hard to undo, I want to see the plan before it executes.”
The distinction is not capability. It’s reversibility. If a mistake is cheap to unwind, let the agent run. If it isn’t, a human approves the plan before anything executes. That principle scales into policy far better than a list of approved and forbidden tools. Set the line once, and your developers stop asking permission for the maintenance work that was never risky to begin with.
Place 4: The Weeks It Took to Ramp Someone Up
Onboarding used to be the most expensive thing a CIO couldn’t line-item.
“Bringing in a new developer used to take weeks before you’d trust them to work independently, and sometimes much longer,” Chris said. “Now you can get someone going in days, if not sooner.”
He attached a real condition to that. The speed depends on whether the developer can write good prompts and pull scattered context into them: Slack threads, their own notes, the documentation attached to a work item. Ramp time didn’t vanish so much as change shape. The question is no longer whether a candidate knows your stack, but how well they work with AI.
Doug watched the same change from the staffing side. Getting genuinely strong on a project used to take weeks, sometimes months. Now people move between projects and stay productive almost immediately.
He also described where team-level leverage comes from. “On every new project, I brought the same utility class along,” Doug said. “Now teams do the same thing with shared prompts, commands, and skills, and that speeds up onboarding too.” The asset is no longer a folder of helper methods. It’s shared, reusable context about how your organization works.
This reaches directly into resourcing. Seniority still matters for architecture and for the edge cases that AI walks straight into. But you no longer need your most senior developer to be the only person who can safely touch a given system. You can staff against demand instead of against who already knows the code.
Reclaim, Don’t Cut
The tempting read on all of this is same output, fewer people. That gets the math backward.
“Most companies limit the number of developers they have because of cost. It’s not cheap to hire,” Doug said. “But if you could keep the same cost and get much more output, most companies would want that.”
Team size was never a judgment about how much work was worth doing. It was a ceiling set by what developers cost. AI moves the output you get per dollar, which means the ceiling moves too. Cutting the team to bank the savings takes the one variable that just improved and holds it flat.
The other choice carries a cost that never shows up in the business case. Chris has watched it happen. “I’ve seen a team downsized with a directive to replace those people with AI,” he said. “It doesn’t go over well with the developers who are left.”
The deeper problem is that the cut doesn’t accomplish what it promises. Whatever AI absorbed, it did not absorb the part of the job your business runs on. “Stakeholders are not going to communicate with the AI,” Chris said. “They want somebody who understands the technical side of the product and can represent it.”
Doug pointed at the other half. Developers stay plugged into what the company is trying to accomplish. They also carry the judgment about what good architecture looks like and how an aging system fits together. AI holds none of that reliably, and it never knows your goals. Trade those people away, and you keep the speed while losing the direction.
What You Actually Bought
The hours come back from four places: understanding unfamiliar code, writing tests, working the maintenance backlog, and getting people productive on new projects. All four were expensive, all four were invisible, and none of them ever appeared on a roadmap as work.
What you do next decides whether the gain lasts. Reinvest the hours, and you get more output at the same cost, healthier systems, and a team you can staff against demand. Cut instead, and you take the savings once, then lose the people who hold your context and judgment.
Your developers just got their week back. Deciding what they spend it on is a bigger call than any tool you’ll buy this year.
Is Your Team Stalling?
Written by: Whitney Powell
Whitney earned her degree in Marketing and Management from the University of Kentucky and discovered her passion for marketing and events. Her go-getter attitude, willingness to learn, and problem-solving abilities elevate the Slingshot team. Known as a daredevil, Whitney loves trying new things and embracing challenges, whether traveling to new places or taking on new projects at work.
Expert: Doug Compton
Born and raised in Louisville, Doug’s interest in technology started at 11 when he began writing computer games. What began as a hobby turned into his career. With broad interests that range anywhere from snorkeling, science, WWII history and real estate, Doug uses his “down time“ to create new technologies for mobile and web applications.
Expert: Chris Chandler
Chris brings decades of software development experience, from DOS-era systems to cloud and AI. He’s led engineering teams in healthcare tech, modernized legacy systems, and helped organizations make smarter technical decisions without overcomplicating things. He also completed a postgraduate program in AI and machine learning. A self-described big kid, Chris still builds retro-style video games and tinkers with new tech just to see what it can do.
Expert: Nathan Thomas
Understanding what people are trying to say, versus what they are actually saying is one of Nathan’s great strengths and he uses this superpower coupled with technology to create solutions to problems. An early bird, he is usually the first to arrive and works in the dark until Chris arrives and turns on the lights. When the day is over, he goes home to enjoy a few of his favorite things; tv, bourbon, and petting dogs. Preferably all at the same time.
Frequently Asked Questions
AI returns the most hours in four places: understanding code somebody else wrote, writing unit tests, working the maintenance backlog, and getting new developers productive on a project. All four cost real time before AI, and none of them ever appeared on a roadmap as work. Comprehension alone can consume up to 75% of a developer's time on an unfamiliar codebase.
New developers reach independent work in days instead of weeks. Instead of hunting down subject matter experts, a developer points AI at the repositories, builds their own documentation, and arrives with specific questions. Research that used to take two or three days comes back in 15 or 20 minutes. The gain depends on how well that developer writes prompts and pulls scattered context together from Slack threads, personal notes, and work item documentation.
Yes, with review. Writing tests by hand used to almost double the cost of a project, which is why so many inherited test suites stay thin. Coverage was a budget decision, not a quality one. AI removes that cost, but it introduces a failure mode worth building policy around: when a test fails, AI often rewrites the test instead of fixing what broke. Treat a green build as a claim to verify, not a conclusion.
Set the line at reversibility, not capability. If a mistake is cheap to unwind, let the agent run. If it is expensive or impossible to undo, such as database updates or anything touching sensitive systems, a human reviews the plan before it executes. That principle scales into policy far better than a list of approved and forbidden tools, and it stops developers from asking permission for maintenance work that was never risky.
Cutting banks the savings once and stops there. Team size was never a judgment about how much work was worth doing. It was a ceiling set by what developers cost, and AI raises the output you get per dollar, so the ceiling moves. Keeping the team and reinvesting the hours compounds instead. Cuts also remove the people who represent the product to stakeholders and carry the judgment about architecture and aging systems, and AI holds neither of those reliably.
