I went to the Vermont Solutions Summit in Burlington last week mostly for one session. Neale Lunderville, CEO of VGS and chair of the Governor's AI Economic Task Force, was talking about how Vermont turns AI into an economic advantage.

That is a job I care about. I run technology at a company that builds websites, apps, and marketing systems for contractors across the country. AI is in our workflow every single day. So when the person shaping Vermont's AI strategy gets up to explain how he sees it, I want to hear it.

Most of what he said was good. Some of it was very good. But one idea sat at the center of the talk, and I think it is wrong. And because of who is saying it, I think it is worth pushing on in public.

The story that stuck with me

Neale told a story about an architect. Thanks to AI, this architect can get through the tedious parts of his work faster. The result is that he spends more time at home with his family.

It is a nice story. Everyone in the room liked it. It is the kind of story that makes AI sound humane, and I understand why it is appealing when you are trying to get a state to embrace something that scares a lot of people.

Here is the problem. That is not how it plays out.

The work does not shrink. It multiplies.

I have watched this cycle happen over and over in web development.

When site builders got faster, we did not build the same number of sites and go home early. We built more sites. When frameworks got better, we did not build the same apps with less effort. We built bigger, more complicated apps. When hosting got cheap and automated, we did not run fewer servers. We ran hundreds.

Every gain in speed got reinvested in more output. Not because anyone was greedy, but because the person down the street had the same gain, and standing still meant falling behind.

That architect is not going to keep the same client list and knock off at three o'clock. His competitor has the same tools. She just took on two more projects. Now he has to as well, or he starts losing bids. The time he "got back" gets spent on the next job within a quarter.

This is not cynicism. It is just what happens when a productivity tool becomes universally available.

We all have the same tools

That last point is the one I keep coming back to.

You have access to the same AI I do. So does the contractor across town. So does the guy who started his business last month. So does a firm in Austin, or Raleigh, or Toronto. There is no Vermont version of ChatGPT that is better than everyone else's.

When everyone gets faster at the same time, faster is not an advantage. It is the new floor. And the floor just moved.

That is what makes the "more time with family" framing dangerous. If Vermont's businesses hear the head of the Task Force say the payoff of AI is more free time, some of them will believe it. They will adopt the tools, feel a little relief, and settle in. Meanwhile, every competitor in every other state is using the same tools to do more, bid more, ship more.

We will not lose to AI. We will lose to the people who understood that the bar went up for everyone and got to work clearing it.

What he got right

I want to be fair here, because Neale said something else that matters more than the efficiency story, and it did not get the applause it deserved.

He said the Task Force needs clean data before it can do anything meaningful.

That is the whole game. I have spent a lot of years building CRMs and lead systems, and the number one reason a smart system produces dumb answers is garbage going in. Duplicate records. Empty fields. Three different spellings of the same town. Dates in five formats. AI does not fix any of that. It takes the mess and produces confident, polished, wrong answers at scale.

If the state does the unglamorous work of getting its data clean, current, and open, then Vermont businesses have something real to build on. That is not a commodity. Anyone can buy an AI subscription. Nobody can buy a clean, trustworthy dataset about Vermont's workforce, housing, permitting, or infrastructure. The state either builds that or it does not exist.

That is the part of the talk I wish had been the headline.

What I would tell the Task Force

Three things.

Stop selling time savings. It is not the payoff, and telling people it is sets them up to be blindsided. The honest message is harder but more useful: these tools raise the bar for everyone at once, and the businesses that win will be the ones that understand their own work well enough to use the tools better than the next guy.

Make clean data the first deliverable. Not a strategy document. Not a pilot program. A real, usable, open set of data that Vermont businesses can build on. That is a durable advantage. A subscription is not.

Be honest about what still requires a human. AI generates. It does not understand. Someone still has to know the customer, know the system, and know when the machine is confidently wrong. If the state invests in anything on the workforce side, invest in that kind of understanding. The tools will keep changing. Comprehension does not go out of date.

The real question

The question for Vermont is not how much time AI will save us. Everyone is saving the same time.

The question is whether we can clear the new bar before somebody else does.

I think we can. But not if we are telling ourselves the floor did not move.

Have you watched a Banana Ball game yet?

If you have not, here is the short version. A pitcher on stilts. Players in kilts. A first base coach who dances every inning. Batters doing choreographed routines on the way to the plate. Backflip catches in the outfield. A guy in a yellow tuxedo running the whole thing.

Then the rules. Two-hour time limit, hard stop. Every inning is worth one point, so a nine-run blowout in the third means nothing in the fourth. No bunting. No walks. Throw ball four and the batter takes off running while every fielder has to touch the ball before he can be tagged. A fan catches a foul ball in the stands, that is an out. Batters can steal first. Tie game goes to a one-on-one showdown.

It looks like a circus. It is not a circus. It is one of the most disciplined things I have seen built, and the more I dug into how they do it, the more it looked like a blueprint for running an agency that serves contractors.

Ten years ago it was one small stadium

The Savannah Bananas started in 2016 as a summer league team in a minor league park in Georgia. Ten years later they are running a six-team league playing 75 stadiums in 45 states in a single season. Yankee Stadium. Wrigley. College football stadiums that hold 100,000 people. They have sold out every home game since day one and you need to win a lottery to buy a ticket.

That did not happen because of the stilts. Underneath all the noise, the game is still baseball. Bat, ball, three outs. They did not invent a new sport. They looked at what fans actually complained about and cut it.

They found the friction by watching, not guessing

The two-hour time limit did not come from a brainstorm. They started taking photos of the grandstands every 30 minutes to see when people got up and left. Most fans were gone by the two-hour mark. So they tested a two-hour game.

Every rule has the same origin. Walks are boring, so they became sprints. Batters stepping out of the box slows things down, so that is gone. Walk-offs are the best play in baseball, so every inning counts and a walk-off is possible every inning. They did the same thing off the field with ticketing, parking, and concessions. Anywhere a fan got stuck, they smoothed it out.

That is how we try to work at Red Barn. Stop asking clients what they want and watch where they get stuck. Where do they stop opening the reports? Where does a homeowner bail on the website? That is your two-hour mark. Fix it.

They design every second, including the parts you do not see

Jesse Cole's company is not even called the Savannah Bananas. It is called Fans First Entertainment. Fans First is on a sign in every locker. The walkway out to the field says "Tonight is someone's first time seeing our show."

Opening night in 2016 already had all-inclusive food, a senior citizen dance team, and players dancing. Before the gates open there is a parade Cole emcees himself. They even design the players' first day: a DJ in the parking lot at 8:30 in the morning, buses with balloons, hundreds of people lining the street, a custom hype video, fireworks.

If they are that deliberate about a rookie's first day, the fan experience is not an accident.

Most agencies think the experience starts when the website launches. It starts with the first phone call. It includes the kickoff, the first invoice, the first time the client logs into the dashboard, the first time something breaks at 9 PM on a Friday. Every one of those is a moment you either designed or left to chance.

Same show everywhere. Never once feels imported.

Here is the part that really got me. The Bananas run the same show in 75 stadiums. Same rules, same dances, same guy in the yellow tux. It should feel like a touring act. A road show that rolls in, does the thing, rolls out.

They just played Gillette Stadium for the first time. It did not feel like a road show. It felt like New England's show.

They pulled David Andrews and Willie McGinest onto the field. Hunter Henry, a current Patriots captain. Shane Victorino, who won a World Series at Fenway. The Loco Beach Coconuts, the team they were playing, are coached by Victorino and built around his Hawaii roots. The only Rhode Island native in all of Banana Ball got a spotlight because Rhode Island was in the stands. Keith Urban walked out of the seats with a guitar in the sixth inning.

Cole himself is a Scituate kid. He posed like the Tom Brady statue outside the stadium the day before. The local paper ran a story about his Scituate High teacher. The Thursday before, they held a free meet-and-greet at a Dick's in Dedham.

And it is not a Gillette thing. At Fenway it was Johnny Damon, Jackie Bradley Jr., Brock Holt, Spaceman Lee, Keith Foulke, Doug Flutie. In Denver, Kristen Bell showed up. They started in Brockton, then Fenway, then back to Fenway, then Gillette. They climbed the local ladder one rung at a time.

Same product everywhere. Localized every time.

That is exactly what a good local website does

I have built a lot of websites for contractors. The ones that work do what the Bananas do. They make a homeowner feel like this company is from here.

Not "we proudly serve the greater region." From here. The truck in the photo has the local plate. The tech in the picture is the guy who actually shows up. The service area page for your town mentions the road everybody complains about, the old housing stock with the ancient oil boilers, the ice dams that hit every February. The reviews are from neighbors with real names on real streets.

When a homeowner lands on that site at 11 PM with a dead furnace, she does not want a national brand. She wants the guy from here. Localization is how a website says "we are the guy from here" before anyone picks up the phone.

Crawlers care. Users care more.

Everybody in my industry talks about local SEO like it is a trick you play on Google. Get the citations right, stuff the city name in the title tag, build a page for every town in a 50-mile radius.

Yes, the crawlers care about local signals. Consistent business info, real reviews, real local content, pages that actually describe a place. That matters and we do it.

But the crawler is not the one who calls you. The homeowner is. And the homeowner can tell in about four seconds whether your site was built for her town or spun out of a template for 40 towns at once.

Google is getting better at telling too. Those 40 spun city pages that used to rank are now a liability. Thin, repetitive, no real local knowledge. The stuff that survives the next update is the stuff that was written for a person in a place.

Bad representation in a small community will kill you

The Bananas could have shown up at Gillette with a generic celebrity and a generic bit. Nobody would have booed. But it would have felt like a road show, and New England would have quietly filed them under "fine, saw it once."

Contractors live and die by this. You work in a community where everybody knows everybody. The homeowner at the supply house knows the guy at the diner who knows the school board president. If your website has stock photos of a model in a spotless uniform, a page that describes a lakefront town as a mountain town, a review from "John S." that nobody has ever met, that gets noticed. Not always out loud. But it gets noticed.

In a big market that is a rounding error. In a town of 12,000 it is the story people tell about you.

This is why I will not play the shortcut game with our clients. Private blog networks, fake reviews, auto-generated city pages. They juice a quarter and cost you the relationship. Bad content is not neutral. In a community, it is an insult. It says you did not care enough to learn the place.

What real localization looks like

For the Bananas it is Victorino coaching the other team and a Rhode Island kid getting his moment.

For a contractor it is simpler than people think. Real photos of your real trucks in real driveways. Service pages written by someone who knows the town, or at least talked to someone who does. Reviews you earned. Sponsoring the Little League team and putting the photo on the site. Knowing that the north side of town is all 1970s ranches with electric baseboard and the south side is new construction with heat pumps, and writing about that.

None of it is complicated. All of it takes actually caring about the place.

The point

The Bananas prove that a system can scale without feeling like a franchise. You keep the product tight and you localize the experience. The rules do not change from Savannah to Foxborough. The faces on the field do.

Same for a website. The platform, the hosting, the structure, the security, that stays consistent. That is our job, and we absorb that risk so the contractor does not have to. The content, the photos, the reviews, the local knowledge, that has to be real and it has to be from here.

Crawlers reward it. Customers feel it. And in a community, feeling at home is the whole game.

I've written before about AI search and why real work beats shortcuts. I stand by all of it. But I want to go a level deeper today, because there's a concept most people in my industry still talk around instead of about.

Graphs.

Not charts. Graphs in the computer science sense: nodes and connections. Things, and the relationships between things. Every system that decides whether your business gets found is a graph. There are several of them, they work differently, and you engineer for each one differently. If you understand that, the whole AI search conversation stops being scary and starts being a to-do list.

Graph one: the link graph

This is the original. Google built its empire on it. Every page on the web is a node. Every link is a connection. PageRank was just a way of asking the graph: who points at you, and do the people pointing at you matter?

Twenty-five years of SEO tactics, good and bad, were attempts to engineer this graph. Real ones earned links by being useful. Fake ones built private blog networks to counterfeit connections. The graph got smarter, the counterfeits got caught, and the businesses built on them burned. I've watched that cycle at least four times.

The link graph still matters. But it's no longer the whole game. It might not even be the main game.

Graph two: the knowledge graph

In 2012 Google announced "things, not strings." Instead of matching keywords, it started building a database of entities. People, places, businesses, products, and the facts connecting them. That knowledge graph now holds billions of entities and hundreds of billions of facts, and here's the part that should get your attention: Google's AI is trained on it. So when Gemini or AI Overviews answers a question, it's reading from that graph.

This is where most contractors are losing without knowing they're playing.

Your business is either a clear node in that graph or it's noise. And I see the same mistakes constantly. The company is "Quick's Heating & Cooling" on the website, "Quicks Heating and Cooling LLC" on Google Business Profile, "Quick's HVAC" on Facebook. To a human, that's obviously one company. To an entity resolution system, that might be three weak nodes instead of one strong one.

So let's talk about entities, because this word is about to matter to your business whether you like it or not.

An entity is anything a machine can identify as one distinct thing. A person. A company. A place. A service. A product line. Not a keyword, a thing. "Furnace repair" is a string. Your company, which does furnace repair in three counties and has since 2004, is an entity. The whole shift in search over the last decade has been machines learning to work with things instead of strings. And your job now is to make sure the machines know exactly which thing you are.

Every business has a set of entities that matter, and most contractors have never mapped theirs:

Your company. The main node. It needs one canonical name, one exact spelling, used everywhere without exception. Website, Google Business Profile, Facebook, Yelp, license filings, truck wraps. Every variation you allow splits your signal.

Your people. The owner is an entity. So is your lead tech with the master license. When your about page names real people with real credentials, and those names show up consistently in reviews, videos, and local press, the machines connect person to business and both nodes get stronger. Faceless companies make weak entities.

Your services. Furnace installation is a different entity than duct cleaning. A separate page for each real service, marked up with schema, tells the graph exactly what you do instead of making it guess from a wall of text on one page.

Your places. Every town you serve is an entity the machines already know cold. Your job is to build the edge between your node and those town nodes. Real location pages, real service area data in your markup, real reviews that mention the town by name.

Your affiliations. The brands you install, the certifications you hold, the associations you belong to. Rinnai is a strong entity. Bosch is a strong entity. When your site and their dealer locator both confirm the relationship, you inherit a little of that strength. This is why I tell contractors their manufacturer relationships are an SEO asset most of them never use.

Then you connect it all. Schema markup on your site declaring what each entity is. The sameAs property linking your website to your profiles so machines know they're all one thing. An about page that functions as your entity's home base: plain, factual, machine-readable statements about who you are, what you do, where, and since when.

Engineering this graph isn't glamorous. It's consistency and structure, applied everywhere, forever. Entity recognition doesn't happen overnight either. Get the signals consistent and it typically takes months, not days, for the graph to consolidate around you. Which is exactly why it's defensible. Your competitor can't buy it in a weekend.

Boring? Absolutely. It's plumbing. But you'd never tell a homeowner the plumbing doesn't matter because nobody sees it.

Graph three: the trust graph

This one is the reviews, citations, mentions, and third-party proof surrounding your business. Google Maps runs on it. And increasingly, AI assistants lean on it hard, because when someone asks Claude or ChatGPT who to call for a dead furnace, the model isn't just reading your website. It's looking for independent confirmation that you're real, local, and good.

Real reviews from real customers. Mentions from your local paper, your suppliers, your manufacturer's dealer locator, your chamber of commerce. Each one is an edge in the graph connecting your node to sources the machines already trust.

You cannot fake this one at scale anymore. People try. Fake review farms are just the trust graph's version of a PBN, and they end the same way.

Graph four: the retrieval graph

This is the newest one, and it lives inside the AI systems themselves. When an AI assistant answers a question, it retrieves content, maps how the pieces relate, and assembles a response from the sources it can actually parse and verify. Some of the newer retrieval systems literally build a graph of concepts from the documents they read.

What that means practically: structure is no longer just for humans. Content that answers the question directly, defines terms plainly, and states facts a machine can lift cleanly gets cited. Content that buries the answer under 800 words of throat-clearing doesn't. I've spent my whole career saying keep it simple, make it look beautiful, have it work. Turns out the machines agree with the first part.

Why I'm telling you this

Because "AI is changing search" is true but useless. It doesn't tell you what to do Monday morning. Thinking in graphs does.

Audit your entity. Is your business one consistent node or five contradictory ones? Fix your structured data. Earn edges in the trust graph the only way that works: by doing good work and getting it confirmed by people and platforms that matter. Write content that a machine can quote and a homeowner can understand.

None of this is a hack. That's the point. Every graph I just described has one thing in common: it's a map of reality. The link graph maps who vouches for you. The knowledge graph maps who you are. The trust graph maps whether you deliver. You engineer your position in these graphs by making the reality better and then making the reality legible.

The tactics people used to fake their way through the link graph don't transfer to the new graphs. But the fundamentals transfer perfectly. Be real. Be consistent. Be clearly good at something specific.

The web was always a graph. Now everything reading the web is one too. Make sure you're a node worth connecting to.

Last week I stood in Fenway Park and watched Phish turn a baseball stadium into a living room. This week I caught Oteil and Friends, and watching Oteil Burbridge play bass is watching fifty years of this music flow through one guy. He held down the low end for the Allman Brothers. He carried the Dead's songbook forward with Dead and Company. Now he leads his own band through all of it.

Two shows in two weeks, and the same thought kept hitting me both nights.

The Grateful Dead played roughly 2,300 shows over thirty years. The Allman Brothers ran for forty five years and survived losses that would have ended any other band. Phish is still going after four decades, and on any given night they will play a song they have played a thousand times and make it sound like they are figuring it out for the first time.

That is not luck. That is not magic. That is a system. And I think about it more than I probably should.

They Play the Bad Notes in Public

Phish takes real risks on stage. Every night. Sometimes a jam goes nowhere. Sometimes Trey flubs a lick in front of twenty thousand people. And the next night they get back up and take the same risks again.

Compare that to how most of us work. We polish everything in private. We do not ship until it is perfect. We treat mistakes like something to hide instead of something to use.

The Dead had a saying about this. Every mistake is just a doorway to the next idea. Jerry Garcia hit wrong notes constantly. He also turned more wrong notes into right ones than maybe anyone who ever played the instrument. He could do that because he was not afraid of the mistake. He was already listening for where it could go.

The only way to learn is to try. If you never allow yourself a wrong note, you are never going to find anything new either. You get safe work. Safe work is forgettable work.

Showing Up Is the Whole Trick

Here is the least romantic part, and the most important. These bands kept going by playing. Constantly. Through years when it was not cool. Through lineup changes, bad reviews, personal disasters, and stretches where the music honestly was not great.

The Dead were not fashionable for most of their existence. Phish broke up twice and came back. And the Allman Brothers set the standard for endurance nobody wants to match. They lost Duane Allman in 1971, right as they were becoming the best band in America. They lost Berry Oakley a year later, three blocks from where Duane went down. They kept playing. Broke up, reformed, broke up again, came back in 1989 and ran another twenty five years. They did not wait for inspiration or the right moment. They booked the tour and played the shows.

Creativity is not a lightning strike. It is a practice. The bands that lasted fifty years did not last because every night was transcendent. They lasted because they showed up on the nights that were not. The great nights only happen because the ordinary ones keep the machine running.

I have been building for the web for a while now. Flash sites, table layouts, a dozen frameworks that were going to change everything and then quietly disappeared. The tools never stopped churning. The habit of showing up and building the next thing is the only reason I am still here. Nobody remembers the glamorous years anyway. The unglamorous ones are where you earn your keep.

Play With People Who Listen

One more thing. None of these bands is a solo act with a backing band. They are conversations. The Allmans ran two lead guitars and two drummers, which should be chaos, and instead Duane and Dickey Betts invented a harmony language other bands are still borrowing. The bass player is allowed to take the song somewhere. The drummer can change the whole feel of a jam and everyone follows.

That is what I was watching at the Oteil show this week. A guy who has spent his whole career listening, now with a band built around it. The material moves between the Allmans catalog and the Dead catalog and it all fits, because the tradition was never about any one band. It was about how they played together.

That only works with trust. Trust that the people around you are paying attention. Trust that if you take a risk, someone will catch it and build on it instead of letting it die.

The Takeaway

Take your risks in public. Show up on the ordinary nights. Surround yourself with people who actually listen.

The Dead, the Allmans, and Phish are not just bands. They are proof that creativity is not something you have. It is something you do, over and over, for decades, with people you trust. Two nights in two weeks reminded me of that better than any business book ever has.

Now if you will excuse me, I need to figure out which show I am catching next.

Last weekend I took our development team up to camp for a retreat. We went to a rodeo. We did team building. We had fun. Some of it was conversations with the team about my role. Some of it was just me, up at camp, with room to think. That kind of quiet is hard to find during a normal week, and it's usually where the honest reflections happen.

What a CTO actually does is a fair question, because the answer keeps evolving. Here's the honest version: I say no a lot.

AI changed the math

We are moving fast into AI and the tools built around it. My team can build things better and faster than ever. Someone can spin up a working prototype in an afternoon that would have taken two weeks a few years ago.

That sounds like a dream. In some ways it is. But it created a new problem.

When building was slow, the cost of an idea was obvious. You had to justify weeks of work before anyone wrote a line of code. Now the build is cheap. The demo is impressive. And the real cost is hidden somewhere downstream.

So more of my job has become evaluation. What software, what services, what stacks earn a place in what we run. Not because the ideas are bad. Most of them are good. That's what makes it hard.

The no is almost never about the code

When I say no, it's rarely "this doesn't work." It usually works great.

The no is about everything around it. It doesn't fit our stack. It's missing a piece of information from the rest of the company. It solves a problem for one person but creates a maintenance burden for everyone. Nobody talked to the stakeholders who would actually live with it.

Building was never the bottleneck. Owning is the bottleneck. Somebody has to maintain that thing, secure it, integrate it, and fix it at 2am three years from now. AI made building cheap. It did not make owning cheap.

The PHP question

Here's a real example we wrestle with. We are experts at PHP. Twenty-plus years of it. We know Node too. So should we move to Node?

Maybe. The technology argument is easy to make. But changing a stack is not just changing a stack. It's changing workflows for people who have mastered the current one. It's trading deep expertise for shallow expertise and hoping you close the gap before it costs you.

Our debugging instincts, our deployment pipelines, our institutional knowledge. That's all part of the stack too, even though it never shows up in a framework comparison chart.

So the question is never "is Node good?" It's "are we eating our own efficiency to make the switch, and what do we actually get back?" Sometimes the answer is yes, move. Often the answer is that the boring, proven thing is still the right thing. Things don't need to be the latest and greatest to be the best.

Saying no without deflating people

This is the part I'm still working on. When you say no to a really smart person who just built something impressive, it can land like you don't care. Like the door is closed. That's the last thing I want.

What I try to do is show the ledger. A bare no feels like a verdict on the person. A no with the reasoning visible feels like a decision they were part of. Here's what this costs us downstream. Here's what's missing. Here's what would have to be true for this to become a yes.

Sometimes they come back and convince me. That's a win. That's exactly the kind of team I want. People who think for themselves, try things, make mistakes, and push back when they believe in something.

The job, as best I can describe it

My job is not to be the smartest developer in the room. It's to protect the whole system. The stack, the team, the clients who depend on what we run, and the efficiency we've spent years building.

Sometimes that means saying no to good ideas. It's a hard balance. But somebody has to read the whole ledger, not just the first column.

If you're a technical leader dealing with the same thing, I'd genuinely like to hear how you handle it. Especially the people side. The technology decisions are the easy part.

I grew up on the command line. My first machines were old Tandy computers running DOS, and there was no other way to use them. You didn't click anything. You typed. Loading a game, copying a file, formatting a disk, it all happened at a prompt. The CLI wasn't a power-user feature. It was how you made the computer work, period.

Then Windows and the Mac took over, and for the next thirty years the entire software industry worked on hiding that prompt. Prettier interfaces. Drag and drop. WYSIWYG editors. No-code platforms. The command line got pushed into a corner where only developers and sysadmins ever went. A black screen with a blinking cursor. If you didn't already know what to type, you were stuck.

Then AI showed up, and the terminal won anyway.

The numbers are hard to ignore

The clearest example is Claude Code, Anthropic's AI coding tool. It doesn't run in a slick web app. It runs in the terminal. The same interface we've had since the 1970s.

And it's the fastest-growing software product most of us have ever seen. It hit $1 billion in annualized revenue six months after its public launch, and $2.5 billion by February 2026, according to Reuters and Anthropic's own reporting. For comparison, Cursor, another popular AI coding tool, took more than a year to cross $500 million.

Usage numbers tell the same story. SemiAnalysis found that by early February 2026, Claude Code was authoring roughly 4 percent of all public GitHub commits, around 135,000 commits per day, and projected it could reach 20 percent or more by the end of the year. Anthropic reported that weekly active users doubled in the first weeks of 2026 alone, and business subscriptions quadrupled.

Meanwhile, the Pragmatic Engineer survey from February 2026 found that 73 percent of engineering teams now use AI coding tools daily, up from 41 percent a year earlier. At small companies and startups, Claude Code adoption sits around 75 percent. Three out of four.

Think about what that means. The hottest interface in software right now is a text prompt in a terminal window. Not despite being a terminal. Because of it.

And it's not just developers anymore

Here's the part that really gets me. I'm watching designers, marketers, and project managers open a terminal like it's nothing. People who would have laughed at you five years ago if you suggested they use the CLI.

Anthropic's own Economic Index research shows the shift. Coding is still the biggest use case, around 35 percent of conversations, but usage is spreading fast across other kinds of work. The top ten tasks made up 24 percent of all activity in late 2025 and only 19 percent by February 2026. The tool is diffusing outward, from developers to everyone else. Analysts covering the space say the same pattern showing up in engineering is arriving in marketing, finance, legal, and operations, just a year or so behind.

Non-developers aren't learning the command line. They're skipping the part that made it hard.

The interface was never the problem

This is the lesson, and it's one I've been preaching for years.

The CLI wasn't scary because it was ugly. It was scary because you had to already know what to type. Every GUI ever built was an attempt to solve that knowledge problem with buttons. AI solved it with language. You say what you want. It figures out the rest.

And once the knowing part was fixed, it turns out people are perfectly happy with a blinking cursor. Nobody misses the ribbon menus.

That should tell you something about how much of modern software is over-engineered. We spent decades stacking abstraction on abstraction, framework on framework, trying to make things "easier." The terminal is basically unchanged since the 70s. It does one thing. You tell it what you want, it does it. It outlived every trend because it's simple and it works.

Things don't need to be the latest and greatest to be the best.

What this means if you run a business

If you're a contractor or a business owner reading this, here's the takeaway. The tools your vendors and partners use are changing fast. Real fast. Development that took weeks now takes days. Teams in published case studies report development velocity gains of 2x to 10x after adopting these tools.

But here's what hasn't changed. Someone still has to understand what got built. AI can generate code faster than anyone can type it. It can't tell you whether that code is the right code for your business, whether it's secure, whether it'll survive the next platform update, or what breaks when something changes. Writing code was never the bottleneck. Comprehension was, and still is.

So when you're evaluating a digital partner, don't ask whether they use AI. Everyone does now, or will soon. Ask whether they understand what they're shipping. Ask who's accountable when it breaks. The tools got faster. The responsibility didn't move.

The command line won because it kept things simple and it worked. That's not a bad standard for the rest of your technology either.

Sources:

• SemiAnalysis, "Claude Code is the Inflection Point" (February 2026): GitHub commit share and adoption trajectory
• The Pragmatic Engineer, "AI Tooling for Software Engineers in 2026" (survey ran January 27 to February 17, 2026): daily AI tool usage and adoption rates
• Anthropic, Series G funding announcement (February 2026): Claude Code revenue, weekly active users, and business subscription figures
• Anthropic, Economic Index report (March 2026): usage diversification and task distribution data