Cursor built an internal AI help desk that now handles 80% of employee support tickets. No giant call center, no army of analysts—just a small team that pointed AI at its own internal chaos and got back a lot of time.

That’s the shift that matters for you. AI isn’t just “write more code faster” anymore. It’s starting to quietly eat the boring internal work that keeps your team from doing the higher-leverage stuff.

The rest of this is about what that actually means for a small team, what numbers to watch, and how to try this without drinking your own Kool-Aid.

What Cursor’s AI setup means for small teams today

Cursor didn’t just plug in a chatbot and call it a day. They used “forward-deployed engineers” to sit with ops and sales, understand the workflows, and then build custom AI tools around those jobs.

That’s the important pattern: a few engineers embedded with the business side, turning messy, repetitive work into structured prompts and tools. You don’t need a research lab for that, just people who can ship and iterate with real users.

Their internal AI help desk is basically a company brain. Anyone can ask it questions about policies, systems, past decisions, or how to do X in the stack, and it answers from internal docs and history. That flattens “who do I ping for this?” and makes onboarding less about tribal knowledge and more about searchable context.

On the engineering side, there’s decent data that AI coding tools move the needle. A University of Chicago study (cited in Fortune’s writeup on Cursor) found teams using AI coding assistants merged 39% more pull requests than teams without them.

But there’s a catch on the deep work. A METR study, also referenced there, found experienced developers actually took 19% longer on complex tasks with AI because of prompt crafting, verification, and extra review. The tools sped up typing but added overhead in thinking and checking.

Put together, this is the real picture for a small team: AI can crush repetitive support and shallow coding tasks, but it can also slow you down on the gnarly problems if you’re not deliberate about how you use it.

Why founders should care about AI’s real impact now

If an AI help desk can resolve 80% of internal tickets, that’s a big chunk of support and ops time back. For a 10–20 person team, that can be the difference between “we’re always behind” and “we have cycles to build the next thing.”

That reclaimed time doesn’t have to go into more tickets. It can move into better onboarding, better customer conversations, or finally fixing the broken internal process everyone complains about but no one has time to touch.

AI-powered internal search also chips away at your dependence on the one person who “knows how this works.” When institutional knowledge is queryable instead of stuck in Slack DMs and someone’s head, new hires ramp faster and you reduce single points of failure.

For developers, the real upside isn’t just faster code generation. If AI can handle boilerplate and simple refactors, your senior people can spend more time on architecture, boundaries, and tradeoffs. That’s where long-term maintainability comes from.

The 39% lift in merged pull requests is useful because it’s concrete. It gives you permission to treat AI tools as a real investment line item, not a toy. You can say, “We expect X% more throughput, and we’ll measure it.”

The flip side is just as important. If you only sell “everything will be 2x faster,” you set your team up for frustration when complex work actually slows down by ~19% at first. Underestimate the friction and you’ll get quiet resistance and tool abandonment.

How to start using AI tools effectively in your small team

I’d start where the work is boring and well-defined, not with your hardest problems.

• Map the repetitive work. List the internal support and ops tasks that repeat every week: “How do I file expenses?”, “What’s our SOC 2 answer for this?”, “How do I run this deployment?” These are prime candidates for an AI help desk or workflow bot.
• Centralize your knowledge. Pull policies, runbooks, onboarding docs, and key Slack answers into one place the AI can index. The goal is that a new hire can ask, “How do we ship a hotfix?” and get a step-by-step answer that matches reality.

On the engineering side, don’t just tell devs to “use AI more.” Point it at the right layer of work.

• Use AI to sketch designs, propose API shapes, or outline migration steps before anyone writes code.
• Use it for code review assistance: “Find risky parts of this diff,” “Suggest tests I’m missing,” or “Explain this legacy module.”
• Keep humans fully in charge of critical logic, security-sensitive code, and final approvals.

If you can, assign at least one engineer to be your internal “forward-deployed AI person” for a sprint or two. Their job is to sit with ops, sales, or support, watch what they do, and then wire up AI tools that actually match those flows.

Finally, set expectations in numbers, not vibes. Decide what you’ll track: pull requests merged per week, average ticket resolution time, onboarding time to first shipped change, etc. Then compare before and after AI adoption over a few weeks, not just how fast it feels.

Where to learn more about AI’s operational impact

If you want to go deeper on Cursor’s setup and the studies behind these numbers, the Fortune piece on Cursor’s AI help desk is a good starting point. It links out to the University of Chicago work on AI coding assistants and the METR analysis of developer performance.

Pay attention to how Cursor’s CEO, Michael Truell, talks about customizing tools to their own workflows instead of chasing generic “AI for everything.” That mindset—specific problems, specific workflows, specific tools—is what makes this usable for a small team instead of a science project.

Is your team ready to deploy AI tools effectively?

Use this as a quick gut check before you spin up another bot:

• Do you have repetitive internal support or ops tasks that chew up a lot of time?
• Is key institutional knowledge currently siloed in a few people or buried in Slack and Notion?
• Can your developers shift some focus from typing speed to architectural planning and review?
• Can you allocate at least a bit of engineering time to customize AI tools for your actual workflows?
• Have you picked 2–3 clear metrics (like PRs merged, ticket resolution time, onboarding time) to measure impact?
• Are you okay with some initial slowdowns on complex work while people learn how to use these tools well?
• Is your team culturally open to iterating on how you use AI, instead of expecting magic on day one?

If you’re nodding “yes” to most of these, you’re in a good spot to treat AI as part of your operating system, not just a shiny demo. The opportunity isn’t just more output—it’s getting your small team out of low-value work and into the problems only you can solve.