AI-first ops increased the team's velocity 2.5 times without increasing headcount

In late 2025, Claude Opus 4.5 was released. We took this as an opportunity to implement a new way of working.

At that time, the Threecolts Platform team was serving 20+ products in the company. It barely had the bandwidth to meet everyone's expectations.

With a love of processes, we turned all repetitive tasks into skills and workflows in Git. We treated them as code: carefully curate each skill file, create a pull request when it needs an update, and have another teammate review it. We chose Git for version control, so we could cherry-pick changes if we messed things up.

We aimed to make the workflows deterministic to avoid LLM hallucinations: one agent per function, one skill per task. This enabled us to rethink the development process: we split it into stages and clearly defined responsibilities. This helped us move from one project at a time to three in parallel without increasing headcount. The team lead focused on solution architecture while the other engineers focused on implementation, without compromising on quality.

Of course, maintaining skills added admin work, which, to be honest, no one liked despite its obvious benefits. So I built a skill to run after each Claude Code session:

• Initially, I invoked it on demand at the end of a session.
• Then I created a post-session hook (a bad idea, since it was messing up the context).
• Finally, I landed on a nightly cron job that picks up the day's sessions and identifies ways to improve the skills and internal tools used for the admin work mentioned above.

The beautiful thing is that we literally built an engine that improves with each Claude Code session. P.S. No evals at this point.

Once we mastered prompts and skills, we progressed towards agents. We were good at deterministic development, had MCPs connected, and had a team of agents.

We asked ourselves: what can we delegate? The idea came from my own pain point: how could we reduce tech support work?

Most of our time was spent helping stakeholders: answering documentation questions, figuring out whether something was a bug, reproducing issues, fixing bugs, etc.

So I created a custom AI agent for Linear. Literally a wrapper around my local Claude Code setup.

Imagine the following:

• A user assigns an issue to the app in Linear (back then, there was no option to use @Linear to do the work in Slack).
• The agent follows the system prompt (aka our deterministic troubleshooting workflow).
• The agent tries to reproduce the issue in "scribe" style: steps and screenshots.
• The agent reports back with a root cause analysis.
• The agent offers 3 solutions: a one-time fix, a short-term solution, and a long-term solution.
• Once the user picks a solution, the agent starts development and spins up an isolated environment (thanks to our elegant CI/CD).

A recreated version of this flow in my personal environment:

As a result, you have:

• Process at scale + compounding context in Linear
• No overwhelming Claude Code setup for non-tech folks
• Budget-lean implementation without high API costs

I really loved how simple and elegant it was. Anyone can build this proof of concept, but, security-wise, don't forget to allowlist IPs for the Linear app...

Despite how powerful AI is, I prefer to build regular automation when the whole workflow is predictable.

For example, when we migrated from Jira to Linear, we badly missed triggers (aka rules), so I built a scrappy version first. An engineer refactored my boilerplate code later.

While I've been heavily Linear-pilled, I still struggled to keep up with all the admin work needed to keep stakeholders up to date.

One of the key challenges was to show the downstream impact of deprioritizing a ticket before the decision was made. Trade-offs were no longer blind.

It's one of many little things I've built to accelerate async ops and remove people from processes. The best part: it's not a one-time gain — it compounds.