Picture a company that bought a few hundred AI licenses. A year goes by; what would tell you whether any of it mattered?
Most leaders reach for the usage report. That instinct is right, and it’s also nowhere near the finish line. Seats get filled, logins happen, and somebody in marketing makes a very good meme. None of that proves your team changed how it works.
Licenses prove access, but fluency proves something harder to buy: your people know which problems belong to AI, which ones belong to your developers, and which ones should never leave the building.
Here are the three shifts that show up when a team crosses that line, plus the one boundary a fluent team never crosses.
Summary
Fluent teams show it in three places: the first prototype arrives from the person with the problem instead of the dev team, work that always got cut (accessibility, observability, internal tooling) finally gets built because the economics changed, and people reach for AI on problems nobody assigned them. That last one predicts the other two, because pattern recognition comes from repetition, not from a mandatory workshop. The boundary holds steady around consumer data, public-facing systems, and long-term maintenance, where human expertise still owns the call.
Start With a Baseline, Not a Vibe
Before you can spot any shift, you need something to compare it against. Most companies skip that part and end up arguing about feelings.
“The first thing I’d look at is the usage report,” said Steve Anderson, Principal Developer and AWS Architect at Slingshot. “Purchasing licenses is one thing. Are people actually using them? And I wouldn’t wait to check.”
Usage answers the easy question. Chris Howard, Slingshot’s President, tracks what comes after it. “That’s what we did early on. We watched usage, but what follows that is the real question: are you seeing processes change?”
Process change is the signal. Measuring it requires groundwork that most teams never lay.
“You have to have baseline measurements, or it’s very difficult to assess impact,” Steve said. “That’s not specific to AI licenses; that’s any change. Without a baseline, I don’t know how you measure improvement.”
Skip the baseline and your ROI story collapses into anecdote. Productivity feels faster. Quality feels better. But neither claim survives a board meeting.
One signal shows up even without instrumentation, and it has nothing to do with speed.
“Most of the time, people who are fluent in AI take on more complex problems,” Chris said. “The AI handles the manual work, so your thinking gets elevated. You can pay more attention to the content of a presentation and how it’s going to land, and less on how you build the presentation.”
That’s the tell. A licensed team does the same work slightly faster. A fluent team moves up a level and starts solving things it used to postpone.
Shift One: The Prototype Shows Up Before the Project Does
The clearest structural change is who builds the first version. It’s no longer the development team; it’s the person who has the problem.
“It used to be that people would come to us with an idea and we’d prototype it, hand it back, and iterate,” Chris said. “We were the ones adjusting and tweaking. Now the customer comes to us with a concept and a prototype already built.”
Slingshot’s job shifted accordingly. Instead of translating a description into a first draft, the team applies technology and UX expertise to something that already exists, elevating it even further.
That reordering pays off immediately, because the expensive part of software has never been the code; it’s been the misunderstanding.
“It closes the communication divides,” Steve said. “You can click through someone’s prototype and get a real feel for what they were thinking. There’s less iteration, because it’s already sitting there, looking you in the face. Multiple rounds of iteration come at a time and money cost.”
Inside your own organization, the same shift is already underway. Your operations lead stops filing a requirements doc and starts sending a working click-through. Your CFO stops describing the dashboard and starts showing you one. That changes what your intake process needs to handle.
Chris sees the next step forming now. “We’re standing up what I’d describe as a fourth environment: a sandbox. The customer can use their own cloud instance to modify that sandbox, try different concepts, and our team can see what they came up with and do something with it.”
The prototype stops being a picture a developer glances at. It starts informing the entire design, and both sides keep editing it.
Shift Two: The Work That Always Got Cut Now Gets Built
Every CIO has a mental list of the items that die in every scoping conversation: observability, accessibility, internal tooling. The work everyone agrees matters, and nobody wants to fund.
That list of what ends up on the cutting room floor is getting shorter. “Ops tools and observability tools are hard to communicate the value of, and they’re usually very quick to be on the chopping block,” Steve said. “Now we’re able to implement them for a fraction of the cost, and teams are now approving that tooling for their applications.”
The same economics apply to quality work that used to lose the budget fight. “Making a web app fully responsive is much easier than it used to be,” Chris said. “Same with accessibility; that almost always got cut in the past.” Steve added a detail worth sitting with: “LLMs do that without you even asking them to.”
Read that as a governance opportunity, not a convenience. The standards you’ve been deferring for years now cost a fraction of what they did. If accessibility or observability still isn’t in your builds, the constraint is no longer budget.
Fluent teams also rebuild the connective tissue between conversations and code. “You can lean on Zoom, Otter, or any transcription service to record your project meetings, then ingest the transcripts into your specs,” Chris said. “You talk with a customer during the sales cycle and hear what’s important to them. Now you can hand all of that knowledge to the project team.”
Context that used to evaporate between sales and delivery now travels with the project. That’s a process change you can actually point to.
Shift Three: Fluent People Use AI When Nobody Asked Them To
The third shift never appears in a dashboard, and it predicts the other two better than anything else does.
Steve talked about a time when he used AI for personal reasons: “My family had seven options from a travel agent, and my kid was hyper-focused on the Bahamas,” Steve said. “I fed the seven options in, told AI to scrub the locations, and asked for a slideshow with pros and cons I could present to her so she could pick.”
Chris went further and built infrastructure for his own mornings. “I wear an Oura Ring, so I built an MCP for it and plugged it into my Claude instance. Every morning I get a daily brief: my calendar, emails I missed, AI news locally and globally, how I slept, and how ready I am for the day.”
He put the scale of the change plainly. “At this point it has entirely replaced everything I used to do with Google.”
Weekend tinkering looks like trivia until you notice what they produce. “Personal experimentation shows you know what a problem AI can solve looks like,” Chris said. “You know where it best fits.” Steve framed it as range: “It shows you’re thinking about applications beyond the obvious, instead of staying inside the box with it.”
Pattern recognition is the actual skill, and you can’t train it in a mandatory workshop. It comes from repetition across enough contexts that people stop guessing.
Personal use also delivers the lesson no vendor demo will. “I did some trip planning for Costa Rica, and it gave me prices for hotels,” Chris said. “When I went to book, it had understated the price by about four times. A hotel it said was $400 a night was $1,800. You start to realize you can’t fully trust everything it tells you.”
Better to learn about hallucinations on a hotel booking than on a client deliverable.
Fluency Also Means Knowing Where to Stop
Enthusiasm creates its own risk. The more capable the tool feels, the more people want to connect it to everything they own.
“Once you get into AI, you think ‘this thing is powerful, I’m going to hook all my things up to it,’ but that’s a problem,” Steve said. “Not having proper guardrails and safety gates in place is a mistake an AI-fluent person shouldn’t be making.”
Knowing what not to automate is part of the fluency, not a limit on it. “Anything touching consumer data needs proper controls,” Steve said. “Encryption, security, all of it. That isn’t something I’d completely outsource to AI. If you put something into the wild, you’re taking responsibility for it, so you need to understand what you built.”
Chris draws the line at exposure. “As soon as it’s public-facing, and especially public-facing with sensitive data, you want experts in that space looking it over, critiquing it, and prepping it for production. It doesn’t mean you can’t build it, just that it needs a review process.”
Two failure modes follow the same internal tools your team is now happily generating. The first arrives quietly. “Nobody really thinks about support and maintenance long-term. They don’t have a plan for it,” Chris said. “With the security vulnerabilities out there, that’s a fast-evolving world you have to keep up with.”
The second mode arrives on your best day. “You put out your MVP with certain assumptions about scale. If it explodes with popularity, that’s a blessing and a curse,” Steve said. “What you built wasn’t built for that scale of user base. The LLM built it just fine, but it didn’t prepare for a massive influx of people.”
Just because code compiled doesn’t mean it’s suited for the big leagues. Having a team ready to help can make or break your product over the long term.
Fluency Is a Behavior, Not a Purchase
Three shifts tell you where your team actually stands. First versions start arriving from the people with the problem instead of the people with the keyboards. Work that always lost the budget fight finally gets built. And your team reaches for AI on problems nobody assigned them, which is how they learn where it fits and where it falls apart.
Around all three sits the boundary that separates confidence from exposure: consumer data, public-facing systems, long-term maintenance, and anything carrying someone else’s personal information stays under human expertise.
None of that arrives with the invoice. Usage reports tell you people logged in, baselines tell you whether anything improved, and behavior tells you the truth.
You can buy every license on the market by Friday. You cannot buy the judgment to know which problems are worth handing over.
More on How Fluency Buys Back Time
Written by: Savannah Cherry
Savannah leads marketing and new business at Slingshot. She writes, posts, and creates all things Slingshot, and helps companies navigate working with a tech partner for the first time. While she isn’t developing software, her CIS minor and a tendency to tinker with AI tools to streamline her own work keep her up to speed on the team’s work. She co-organizes and hosts the Louisville AI Exchange, and she can’t rest until all her work is done.
Expert: Chris Howard
Chris has been in the technology space for over 20 years, including being Slingshot’s CIO since 2017. He specializes in lean UX design, technology leadership, and new tech with a focus on AI. He’s currently involved in several AI-focused projects within Slingshot.
Expert: Steve Anderson
Steve is one of our AWS certified solutions architects. Whether it’s coding, testing, deployment, support, infrastructure, or server set-up, he’s always thinking about the cloud as he builds. Steve is extremely adaptable, and can pick up the project and run with it. He’s flexible and able to fill in where needed. In his spare time, he enjoys family time, the outdoors and reading.
Frequently Asked Questions
An AI-licensed team has access. An AI-fluent team has changed how it works. Licenses are proven by a usage report, which only shows that people logged in. Fluency shows up in behavior: who builds the first prototype, which previously cut work now gets funded, and whether people reach for AI on problems nobody assigned them. A fluent team also knows which problems belong to AI, which belong to developers, and which should never leave the building.
Start with baseline measurements taken before the tools arrive, because without a baseline there is no way to assess improvement. Usage answers the easy question of whether seats are being used. The real question is whether processes changed. One signal appears even without instrumentation: fluent people take on more complex problems, because AI absorbs the manual work and their thinking moves up a level. A licensed team does the same work slightly faster. A fluent team starts solving things it used to postpone.
Because the person who has the problem can now build the first version themselves. That reorders the engagement. Instead of translating a description into a first draft, the development team applies technical and UX expertise to something that already exists. It also closes communication gaps, since clicking through a prototype conveys intent faster than a requirements document and removes rounds of iteration that cost real time and money. Inside an organization, it means intake processes need to handle working click-throughs, not just written specs.
Yes, and that changes the governance conversation. Ops tooling, observability, responsive design, and accessibility were historically first on the chopping block because their value was hard to communicate against their cost. Those items now get implemented for a fraction of what they used to require, and LLMs often handle accessibility without being asked. If those standards still are not in your builds, budget is no longer the constraint.
Anything touching consumer data, anything public facing, and anything carrying someone else's personal information. Encryption and security controls need human ownership, and public-facing systems with sensitive data need expert review before production. Knowing where to stop is part of fluency, not a limit on it. Two failure modes deserve planning: no long-term support and maintenance plan in a fast-moving security landscape, and an MVP built on assumptions about scale that breaks when the product succeeds.
