99% AI
Over the last six months, the engineering team at The Langston Company has completely changed how we write software. We went from 1%–10% of our production code being written by AI to 99%. A change we didn't think would be possible a year ago.
We were never opposed to LLM-assisted development. We've stayed closely connected to the industry and have been watching where it's headed. If you've been paying attention, the trajectory is hard to ignore. The models and tools have been improving steadily, with new ones appearing constantly. Trusted developers have been praising Claude, Codex, and Cursor. We outlined where we were a year ago in this article titled 1%.
The difference between then and now isn't just the models and tools improving drastically. The difference is that we finally set up a truly agentic workflow. Until you do that, you're not really using AI. You're just using a smarter Stack Overflow.
If you're not familiar with what an agentic coding workflow means, there are plenty of deep-dive articles out there covering the topic. What we want to share is how we actually built ours, and what it changed for us.
The Workspace
The core of our setup is what we call the Langston Workspace. It's a custom repository that acts as a wrapper around all of our repositories. Structurally, it mimics a monorepo but without the overhead and baggage that comes with actually managing one. The workspace uses git rules to ignore the nested repos it contains, so each codebase stays independent while still being co-located.
Inside the workspace, we store our agent definitions, skills, MCP server configurations, and custom tools written as bash scripts. By bringing all of our repositories together in one place, our agents have full context across the entire stack. They can read and write code across services, understand how the layers connect, and make decisions that span the frontend, API, and database at the same time.
One of the most practical benefits is that all of this configuration lives in git. Every teammate shares the same agent files, the same tool definitions, the same context. There's no "it works on my machine" version of an agent setup.
We primarily run our workflow using OpenCode, which lets us launch agentic sessions directly inside the workspace. We choose a model, enable whatever MCP servers are relevant to the task, and we're off.
More recently, I've been using Cursor and their workspace feature. It replicates a lot of what we built, but with less configuration and a nicer UI. Cursor was even able to search my laptop for existing agent files and skills and pull them in automatically. I prefer it day to day. The tradeoff is that our workspace configuration is checked into git and shared across the team — Cursor doesn't have a clean way to replicate that, at least not that I know of. So it's become my personal preference, while the shared workspace remains the team standard.
A Typical Feature
Here's what building a new feature looks like for us now.
We start a new session in OpenCode, Claude Code, or Cursor. The first thing we do is load our Planning agent, which is configured with a custom agent file that knows how we write tickets, understands our project structure, and is pointed at our Linear MCP server. We write out the requirements, provide background context on the task, and drop in any screenshots or mockups we have.
For UI design, we use Vercel's v0 to sketch out basic layouts, though we've been moving toward Claude Design lately. Claude Design connects more naturally with our codebase. v0 wants to build your entire app when you give it repo access, which isn't what we want from a mocking tool. We just want something we can quickly iterate on, not a parallel implementation.
Once we've loaded up the context, the agent searches the codebase and comes back with a plan. We read through it carefully and go back and forth refining scope, confirming or adjusting assumptions, and finalizing the approach. This part matters a lot. Handing a half-baked plan to an agent and letting it run is a good way to end up with a lot of spaghetti on the wall.
When the plan is solid, we switch to our Building agent, which carries context about our coding style, testing requirements, and architectural patterns. The LLM writes the code, we review it, test it, and when it's ready, we commit it.
From there two code review integrations start their review. We still have Copilot enabled, but honestly its comments are surface-level and I don't think we'd see a drop in quality if we turned it off. Our real reviewer is Greptile, which does thorough, in-depth reviews. Its suggestions are useful about 85% of the time, which is a high bar for an automated review.
We also have a custom command in our agent tools: /pr-review {github_url}. It fetches all the comments from the pull request, filters out the noise, determines which suggestions are worth acting on, makes the fixes, and pushes the code back up. It is LLMs all the way down.
What's Left for Us
The obvious question is: what does that leave the engineers to do?
My answer is software engineers still control the most important parts of delivering software. We spend more time talking to stakeholders, gathering real requirements, and thinking carefully about system design. We think harder about what we're building and why before we ever start a session. The robot will write the code but it needs a capable person who understands the system to be in charge.
This is the part that often gets glossed over in the "AI will replace engineers" conversation. LLMs don't do well when you let them run loose. They need direction. They need someone who understands the architecture, the business logic, and the constraints. The craft of software engineering hasn't gone away, it's shifted upstream.
A small team like ours can now build what would have taken a team double or triple our size two years ago. That's the real headline. Not that AI writes code, but that it changes the leverage a small, thoughtful team can have.
The process isn't perfect. We still ship bugs. We still carry tech debt. We still feel behind sometimes. But we are moving faster, thinking at a higher level, and building better software than we were a year ago.
Claude Sonnet 4.6