Spiko has grown fast. In almost three years, we are approaching 2 billion euros in assets under management. A team of less than 10 engineers shipping at that pace needs every advantage it can get. For us, AI tooling is one of those advantages.
We do not adopt tools blindly: we understand how they work under the hood, evaluate trade-offs, and make informed choices. The productivity gains are real, which is why staying current on agent practices is a priority.
As of May 2026, this is our setup and how we use it.
Our Tooling Choices
OpenCode
Most of the team uses OpenCode, an open source AI coding agent that runs in the terminal.
Here is why it works for us:
- Open source and extensible. Custom agents, skills, and MCP servers let us encode our team’s conventions directly into the tool.
- Provider-agnostic. Not tied to a single LLM provider.
- Terminal-native. Fits naturally into our existing workflow.
A good model is not enough. A recent LangChain article, The Anatomy of an Agent Harness, makes a useful distinction: the model provides intelligence, but it is the harness (system prompts, tools, orchestration, hooks) that determines how effectively that intelligence is applied. OpenCode allows us to have better control over every layer of the harness compared to Claude Code, from system prompts, to tool selection and orchestration logic.
Models
We primarily use Claude (Anthropic) as our main model. It handles complex TypeScript well, follows instructions precisely, and produces code that respects our existing patterns. For lighter operations like code review, we use smaller, cost-effective models.
Skills and CLIs over MCP
OpenCode supports two main extension mechanisms: MCP servers and Skills.
MCP servers let you connect external tools (like Notion, or GitHub) to the agent. They are powerful but come with a cost: each MCP server adds tools to the context, which consumes tokens and can slow down responses.
Skills are a different approach. They are reusable SKILL.md files that encode domain-specific instructions and workflows. The agent discovers them automatically and loads them on demand. Unlike MCP servers, skills do not bloat the context when they are not in use.
We have shifted toward skills as our primary extension mechanism, combined with CLI tools where external data is needed. Here is why:
- Lazy loading. Skills are only loaded when relevant, keeping the context lean. MCP servers register all their tools upfront regardless of whether the agent needs them.
- Discoverability. CLI tools are self-documenting: the agent can run
--helpon any command to understand its capabilities and options without needing the full tool schema pre-loaded in context. - Specificity. A CLI call with precise arguments replaces a generic MCP tool interface. A skill injects only the instructions that matter for the current task.
We still use MCP for complex integrations (like Notion or Figma), but for workflow knowledge and team conventions, skills combined with CLIs are the better fit.
What Makes a Good Skill
Anthropic published best practices for agent skills that align with what we have learned through experience:
- Concise and focused. We write them assuming the model is already a capable engineer.
- Example-driven. A two-line code snippet does more work than a paragraph of explanation.
- Project-specific. A skill should always teach the agent something it does not already know. Skills for generic operations, like opening a pull request, are useless.
What Engineering Processes Are Automated
OpenCode lets us define custom agents, each tailored to a specific task with its own set of permissions, MCP integrations, and skills. Rather than using one generic assistant for everything, we switch between purpose-built agents depending on what we are doing.
Writing Code
The plan agent operates in read-only mode: it explores the codebase but cannot make changes. It is used to iterate on an approach before writing any code, or to explain unfamiliar code, summarize what a module does, or clarify the reasoning behind a pattern.
The build agent executes. It has access to most of our MCP integrations: Notion for specs, Nx for monorepo context, Effect docs, Shadcn, Figma, and more.
Since OpenCode runs in the terminal, it pairs well with git worktrees. Each worktree gets its own agent session, which makes it easy to parallelize work.
Code Review
The review agent works on pull requests, branch diffs, or uncommitted changes. It runs locally during development or automatically in CI through our spiko-bot.
spiko-bot in CI
When a pull request is opened or marked as ready for review, spiko-bot checks out the code and launches the review agent. Developers can also re-trigger it at any point by commenting /review.
The review agent does not do a single monolithic pass over the diff. It reads the PR description to understand intent, then dispatches parallel sub-agents, each focused on a specific review track. Which tracks are activated depends on what files changed.
Once all sub-agents finish, the review agent synthesizes the results: it deduplicates overlapping findings, adjusts severity when needed, and posts a single atomic GitHub review via the API with inline comments, code suggestions, and a verdict.
The bot defaults to approve or comment. It only uses request changes for genuine production threats: security vulnerabilities, data integrity risks, or critical type safety violations. This keeps the bot useful without becoming a gate that developers reflexively dismiss.
The Continuous Improvement Loop
We built an automated feedback loop that runs every Monday morning. A scheduled GitHub Actions workflow does the following:
1. Collect feedback. The agent queries the GitHub API for developer reactions to bot reviews from the past week: dismissed reviews, direct replies to bot comments, and negative reactions.
2. Categorize. Each piece of feedback is classified (false positive, wrong severity, missing context, knowledge gap, noise) and ranked by frequency and signal strength.
3. Route and edit. For each actionable item, the agent identifies which skill or rule file caused the bad review and drafts a targeted edit, adding a calibration note, adjusting a severity level, or adding an exception.
4. Create a PR. The agent opens a pull request with all changes. This PR requires human approval before merging.
Once merged, the next review cycle picks up the updated rules automatically.
On-Call Operations
The on-call agent is purpose-built for incidents. It uses the pup CLI from Datadog and the bq CLI (BigQuery) to query production data (anonymized). When an alert fires, the on-call agent can:
- Query Datadog for logs, traces, metrics, and monitor status
- Query production data through
bqwith anonymization safeguards - Correlate signals across services to build an incident timeline
- Isolate root cause with evidence before proposing a fix
- Load specialized skills for incident response, deployment checks, and post-mortem writing
This significantly reduces time-to-diagnosis. Instead of manually switching between dashboards, the incident is investigated in a single conversation where the agent pulls the data directly.
What Comes Next
Agent Orchestration Platform
The next step is deploying a coding agent orchestration platform. Today we run agents in GitHub Actions and locally through OpenCode in the terminal. The goal is to unify this into a single platform, connected to Slack and GitHub. Any team member could trigger and interact with agents from Slack, while the platform handles scheduling, routing, and execution. A centralized platform also means shared context: agents can access previous runs, reuse knowledge across sessions, and build on each other’s work instead of starting from scratch every time.
Enabling AI for Non-Engineering Teams
The benefits of AI are not limited to writing code. We are working on extending AI capabilities to other teams at Spiko. Examples include:
- Database access to let non-technical team members query data using natural language.
- Support tickets to help sort and respond faster.
- Sales to automate research, prep meeting briefs, and draft outreach.
Staying Agile
The AI landscape evolves fast. The workflows and tooling change constantly. Our approach is deliberately agile and we keep our setup modular enough that adopting a new tool or workflow is straighforward.