Working with AI at Distrope

In the last six months, the tools engineering teams use to work with models changed more than they did in the entire previous decade. Desktop apps wired to CLIs, autonomous cloud agents, shared context protocols, and .md files acting as a team's operating memory — all of it landed between November and April. Working with AI stopped being open a chat window, paste code, copy the answer and became an orchestration exercise: give the agent the right context, the right tools, and let it close loops.

The models didn't change that much. What changed is how we use them.

Agents stopped being chat

A year ago, "working with AI" was a copy-paste flow. Today the leading teams — Distrope included — work with agents that read code, edit files, run commands, propose migrations, open pull requests, review their own runs, and report back with evidence. Not magic; three pieces that matured at roughly the same time:

• CLIs with real tool access — Claude Code, Codex CLI, Gemini CLI, Aider, OpenCode. The agent lives on your machine or in a sandbox, runs git, reads logs, executes tests, and responds with the output in hand.
• Autonomous cloud agents — the same workflows, but triggerable from a webhook or a scheduled task. The agent can wake up overnight, read a report, decide whether something needs investigation, and open a ticket if it finds something.
• The .md filesystem as memory — conventions like CLAUDE.md and AGENTS.md give the agent an identity, a work contract, a history. With a well-written .md, the agent behaves like a team member, not a chatbot.

That last piece is what changed how we work.

Six months building workspaces

Since last November, at Distrope we've been building what we internally call workspaces: directories with their own root .md, decision records, operational runbooks, and tokens scoped to that brand or domain. Each workspace has one or several agents assigned to specific tasks.

Today we run workspaces for:

• Server ops — periodic sweeps over logs, anomaly detection, incident opening, and proposing the fix (not just alerting).
• Comms triage — incoming messages across async channels, filtered, classified and summarized before a human steps in.
• Platform sync — moving data between Monday, Supabase, Stripe, Google Docs and Make without a human clicking through; when something breaks, the agent leaves context, not a bare stack trace.
• Internal reminders — the "this has been pending since last Thursday" inbox. Trivial for a human, but trivial to-dos are the ones that slip.
• Project onboarding — when we start with a new client, the first sweep through docs + stack recognition + first ADRs went from days to hours.
• Technical research — decision spikes ("does this stack work?") that used to be a day of reading are now a 40-minute session testing examples in parallel.

None of these replace a person. What they do is absorb the work that doesn't need a person — so human time goes to design, client conversations, and decisions that actually require judgment.

What changed inside

Three things we feel every day:

Speed. Implementations that used to take three days close in half a day. Not because the code writes itself — the boring code writes itself: configuration, boilerplate, first-order tests, mild migrations. What's left for humans is denser and more fun.

Reach. We can take on projects with legacy stacks that didn't fit a week before. An agent opens a repo with a decade of accumulation, maps what each piece does, identifies the reported bug, and leaves a reviewable plan of changes in hours. That recon phase used to be a separate quote.

Quality. Every change passes through at least one automated review — real, not cosmetic. An agent reads the full diff, runs the tests, and writes an opinion before a human does. The human signs at the end, but with the noise already filtered.

What changes for a client

A concrete example, no names: we came into a client with a Node backend that had been running for eight years. They had an intermittent bug nobody had been able to reproduce — the kind that "fixes itself later". In the first session with an agent we reconstructed the suspicious flow, found a race condition in a callback, wrote the test that reproduced it, fixed it, and deployed. Four hours, cold. That same client had a reports module pending for eight months; we closed it the following week.

This kind of speed doesn't cost more. On the contrary: it lets us offer retainers with more real scope at the same price, because human time spends differently. The client sees more continuous progress and fewer "we're on it" weeks.

The next step: agents for your brand

The pattern doesn't stay inside Distrope. What we're starting to offer — and what will grow in the coming months — is setting up the same infrastructure inside the client's team:

• Initial setup — picking the right tool (from open-source options like OpenCode to Claude Code deployments), configuring access with scope discipline, and writing the first .md that defines how the agent will operate.
• Training — sessions with the human team so they use the agent as a tool, not a toy. Golden rules: never give it permissions you wouldn't give a junior, never trust its output without verifying, never let it run in production without logs.
• Ongoing support — the first few months the agent needs tuning: which docs to read, which to ignore, how to report, what it can and can't touch. We've already walked that process.
• Custom workspaces — the same way we have one per Distrope domain, we can build one per domain of the client's operation: support, sales, ops, engineering.

AI stopped being a product you buy once. It became an infrastructure layer, closer to the cloud: you pick it carefully, configure it well, care for it month by month, and get a return that scales with usage.

If you're part of a team that still sees AI from the chat side, from where we stand there's a lot of ground left to gain — and the road is already paved. You just have to start walking it.