The hard part of AI tooling is everyone else

A note on how this was written: this post was drafted and condensed by Claude from an interview with me about how our engineering team at Langston uses AI tooling, then edited by me. The views, and any mistakes, are mine.

Most people can get an LLM to build something great for themselves. The hard part, and one of the highest-leverage things you can do, is building it so the rest of the team can use it.

I run engineering at The Langston Company, a consumer insights research firm. We're eighteen people. Three of us are engineers. There's no dedicated product manager; product direction happens across the team. Almost everything below is shaped by that, and almost everything below exists because I forced one constraint from day one: if a tool is good, it has to be shareable.

Alex Greco, a senior engineer on our team, wrote up how our engineering practice changed in two posts, 1% AI and 99% AI. His short version: in early 2025 AI wrote maybe 1% of our production code and mostly answered Stack Overflow-style questions. By late 2025, after we studied how experienced developers were actually using these tools and rebuilt our workflow around agents, it was writing the large majority of it. The work didn't disappear. It moved upstream into planning, design, and review.

This post is about the other half of that shift: the setup, tools, and workflows that let the whole team work this way, not just me.

Run agents a level above the repos

Our system is seven repositories. The API, the front end, database migrations, a few services, and infrastructure. They're one system, not seven projects. To reason about anything real, an agent needs to read the front-end code, the API code, and the database schema together.

Almost all the guidance and tooling out there still treats a single repository as the unit of work. Claude handles crossing that boundary reasonably well in some cases, but it's still not a first-class use case anywhere.

So from the beginning I set our agents up a level above the repos. Everything is checked out as siblings under a parent folder, and I run agent sessions from that parent. The shared instructions live there and describe the whole structure: what each codebase does, how they interact, how to work across them. That change alone improved the quality of what agents produce more than anything else I've done. Alex describes the same setup in his second post as the foundation everything else rests on. The benefits of a monorepo without the cost of building one.

Two habits follow from it. We configure cross-repository context in code review, so a change in the API repo is reviewed alongside the services and migrations it touches. And when a change spans a migration, an API change, and a front-end change, each pull request links the others and states the merge order. With that, the reviewer stops flagging calls to endpoints that "don't exist" because they only exist in the open PR next door.

If parts of your system are genuinely isolated and you'd rather an agent only see one of them, fine. That's not us, and I'd guess it's not most teams.

One repository for the shared tooling

One internal repository holds our shared agent instructions, our skill files (task-specific playbooks an agent loads on demand), and a database MCP server. The server lets an engineer's agent query our local, staging, and production-replica databases. Read-only is enforced in the server and again by the replica itself. The same repo holds the guidance for spinning up an isolated environment for a feature branch that spans multiple repos, and the tooling to manage it.

The files aren't the point. The point is that it's a repo. Improvements are reviewed, versioned, and immediately available to the whole team. When one person figures out a better procedure, it reaches everyone on the next pull. Nobody maintains a private prompt collection, and nobody's workflow quietly drifts from everyone else's.

Where oversight lives

Any employee can open a pull request now, through Claude in Slack. And I've stripped the human steps out of our release pipeline: once a pull request merges to main, it ships to production automatically, database changes included. That was a big change for us. So the question becomes where oversight actually lives, and for us the answer is code review, backed by the controls below. Whether every change should have a human in the loop is still an open question for us. I don't think it's settled.

Greptile does the automated pass. It reviews every pull request on open and gives it a confidence score. It builds a knowledge base of our product as it reviews, and the rules we give it live in the repo alongside the code, so its feedback matches our actual preferences instead of generic best practices. It catches real bugs, not just style nits. Alex puts its useful-suggestion rate around 85%, which matches my experience. We evaluated CodeRabbit, Devin's review product, and a couple of others. Greptile suited us best, though I've heard good things about CodeRabbit from people I trust. GitHub Copilot also reviews. Less impressive, but improving, and it occasionally catches something Greptile misses. Cheap enough to keep both.

We deliberately don't run review on every commit. Too noisy. Instead our agents know how to request a fresh review and incorporate the feedback, iterating until the score clears our bar. Only then does a human get asked to look.

Two more things back that gate up. Tests: we went from a few unit tests on simple functions to meaningful coverage, including a harness that spins up a real database next to the tests so we can exercise an endpoint end to end. That part is still early, more experiment than backbone. And automated deploy-order checks: a change can declare which database migrations it depends on, and both the pull request and the release pipeline verify those have actually shipped. That used to be a developer remembering to deploy in the right order. Now if it's wrong, the release fails instead of production.

We also don't review everything equally. Scrutiny scales with distance from the data model. Anything touching schema or persistence gets the most attention, because everything else flows from it. A React component gets much less. It's low risk, it's far from the data, and if it's wrong it's easy to fix. That matches how I'd triage a human's pull request.

The rest of the answer is speed of recovery rather than prevention. Worst case, merge to running in production is about five minutes across the full stack. Sometimes it's closer to one. Error reporting and logs from our hosted environment are readable from a developer's own agent session, so diagnosing an incident happens in the same place you write the fix.

What didn't work

The consistent failure mode: anything that only works on one person's machine.

We went through several answers to one question before it stuck: where should decisions and work-in-progress live? A folder of markdown files in a repo. A git-based issue tracker that stored everything in JSON no human could read. Agents generating their own issues. Each worked for the developer who set it up. The problem was everyone else. If the work only exists in git, how does a researcher or a co-founder see what's in flight, or get a report on what shipped? Nothing could report on it, so nobody outside engineering could see it. That's what eventually moved us from Shortcut to Linear: better MCP support meant agents, engineers, and the rest of the company could work from the same source of truth.

A tool only you can run fails four ways. It goes stale when you stop maintaining it. Nobody else benefits. It creates divergent workflows. And it becomes a maintenance burden nobody else can pick up. If a tool is good, the instinct should be to get it in front of the team, not to keep it as personal tooling.

Also abandoned: various plugins and add-ons to our coding harnesses, and API-based billing for Claude, which we moved to subscriptions to control cost. None of it was wasted. Most of what didn't work taught me what does.

Adoption was a teaching problem

I built an internal Slack bot that anyone can tag. It writes read-only SQL against our production database and searches an index of our internal documentation and source code, so it can answer anything from "what is this conversion rate" to "how does this feature work."

It changed how people work more than anything else I've built, for relatively little effort. The unlock was coaching, not capability. When someone asks me how something works, I'll often tag the bot publicly, let it answer, then react in the thread. "Yeah, that's right." "That's not quite it, let me ask differently." "I'm going to give it access to more data so it can do this better." That shows people what good prompting looks like, models evaluating the output instead of trusting it, and makes clear I'm still their partner on the problem rather than pushing them off onto a robot.

I've since taken that further. One of our co-founders, who leads research, has the best read on what our users need because he's a user himself. I gave him Claude in Slack, which can write code and open pull requests against our product, and coached him on using it. Over a week or two we closed a large backlog of papercuts that had never been worth prioritizing individually. It also buried a small team in review volume and broke a few things. But it's the closest our roadmap has ever tracked what users actually want.

Prompt by voice

Smallest change with the biggest return. Most of my prompting is now spoken rather than typed.

It feels ridiculous for the first few days. But it removes writer's block entirely. You speak spontaneously, and the model doesn't care that you repeated yourself, stuttered, or circled back. You think out loud and get it all down. Distilling a large pile of text into what you actually meant is one of the things LLMs are genuinely good at. For getting an idea out of my head and into the model, nothing else comes close on bandwidth.

Claude and Codex have transcription built in. I use a third-party desktop app called Handy. Keyboard shortcut to start, speak, stop, and it pastes the transcript into whatever chat box I'm in, with your choice of transcription model behind it. Worth trying for a week before deciding.

Where I'd start

There isn't a clean ordered list. It depends on your organization. But roughly:

Get your hands dirty first. Use the tools, try the different coding harnesses (Claude Code, Codex), and learn what levers exist. Most of what I've built came from things I couldn't have predicted before starting.
Turn repeated prompts into shared files, and store them centrally. As soon as you're re-typing the same context, put it in a file the team shares. The real unlock is that one person can update a procedure once and have it reach everyone immediately.
Give the agents context and tools. Your issue tracker, bug reports, customer service requests, backlog, product vision. Anything that makes a decision better-informed. Then write the guidance for when and how to use each.
Get people excited. Show them what's possible, give them examples, let them be creative. The Slack bot changed our company more through coaching than through capability.

Resources

A course I signed up for but haven't taken yet: AI Hero by Matt Pocock. I've followed his TypeScript work for years and like how he approaches teaching, so I expect it to be good.

On social media, the advice I'd give first is to not follow forty accounts. Here's a starter set that gives you a usable timeline without drowning in AI Twitter:

@bcherny: Claude Code. The primary signal for agentic coding in the terminal.
@cursor_ai and @amanrsanger: the IDE most teams compare against. The founder account is lower volume and more substantive.
@opencode and @thdxr: open-source coding agent. A useful counterweight to vendor marketing.
@OpenAIDevs: Codex and OpenAI platform updates without the CEO-account noise.
@AnthropicAI: Claude model and product releases.
@OfficialLoganK: Gemini and the Google AI developer surface.
@simonw: the best public notebook of what these tools actually do when tested. "Did this really work?"
@karpathy: sparse, but the highest-signal technical intuition available.
@emollick: evidence on AI at work. The strongest account here for a non-engineer.
@swyx: the ecosystem map. Helps place a new tool in a category.
@chipro: production AI systems and evaluation tradeoffs.

Add these if you're specifically running coding agents in production: @hwchase17 (agent orchestration), @dexhorthy (agent control, as in "can we let this touch real systems?"), @zeeg (MCP and permissions friction), @clairevo (AI-augmented product management), and @FactoryAI and @aidenybai (competitor and code-review-bot comparisons).

Separately, these are the people I keep citing in my own research notes, which is a good proxy for who's producing durable ideas rather than takes:

@mattpocockuk: TypeScript, now AI engineering. Clear and practical.
@GergelyOrosz: The Pragmatic Engineer. The best source on how real teams are adapting, including a good survey on how teams decide which pull requests still get human review.
@poteto: React Compiler, now at Cursor. Open-sourced the skill set she uses daily. The most concrete thinking I've seen on making agents prove their work.
@VictorTaelin and @dzhng: the "review the decisions, not the diff" argument, which is the single most useful reframe I've adopted.
@kentcdodds: building in the open on personal AI assistants and MCP.