This post was written by Vladimir, Head of Engineering at Amondo, who has spent the last six months rethinking how a small, senior team can compound its output without compromising on quality. Connect with him on LinkedIn to continue the conversation.

Opinionated before AI

At Amondo, our Engineering team is full of strong professional programmers with many years of experience. We don’t do “stuff” just for the sake of it. We always approach problems thoughtfully and choose the best possible solution. When the team adopted XP practices, we started with trunk-based development and a strong QA pipeline. We automated it, covered integrations with plenty of tests, and hardened our core architecture with DDD.

But, recently, we ran into a problem: if we were to hire, we didn’t have a proper process for pull request reviews. So, we collected feedback and wrote instructions for devs to follow before each PR. But the more the world around us became automated, the more I questioned it: why should we bother following instructions if a program could follow them for us?

At the same time, it was January – the time when many people actually “cracked” AI coding and started to understand how to use it, and when. The same happened to me: I used the Superpower plugin and managed to close more tasks than I normally would, while keeping all my other responsibilities under control. And instead of just being a 10x engineer, I really wanted to be 10x^10.

I started to think about how to change my flow so I could stop paying attention to clutter that was no longer a priority – and, more importantly, how to make my team more productive as well.

My patterns, like the patterns of each team member, were different. One day, I could be using aConductor and parallelise my work with worktrees. Another day, Cursor would release cloud agents, and I would be running any idea I had from my phone, inspired by a talk from Kent C. Dodds.

We had strong practices, but no way to scale the team’s brain into the tools. How could I make everyone more productive, not just me?

Compound the team’s knowledge

I started small. I read great pieces from Matt Pocock and Builder.io, about how they keep their AGENTS.md, skills, etc. I completely revamped our docs structure: /docs, /skills, and README.md were agentic-first. I was super excited, I merged the PR, and... nothing happened. No spike in PRs, no decrease in comments during review, no decrease in bug reports.

“What did I do wrong?” I thought. “So much effort cannot just do nothing.”

Then, one day, I was talking with my friend about our experiences with agents. We realised we had a similar flow: any task starts in Linear, you then copy the branch ID and description, and start Conductor work on it, pushing everything and opening a PR at the end. Then any problem or review comment gets addressed by the “Fix PR comments” button.

“Why do we even keep ourselves in this loop?” we wondered together.

The very next day, he shared Compound Engineering.

For those who do not know, compound engineering is a methodology for working with AI coding agents. In a few words, you have extendable guardrails for Claude, and you accumulate team knowledge in the repository. The whole structure encourages your team to improve the flow by writing new agents, updating specific domain skills, and sharing their brainstorms and plans.

The greatest bit is that all team members would have a standardised workflow that works for everyone. And they have to pay at least 30% of their attention to improving the flow.

I opened a PR with these changes. I tweaked the compound flow with required TDD for Claude while it works, and added different agents (like Postgres Protector, built on top of Planetscale skills). And as soon as I merged the PR, development changed forever.

I couldn’t do tasks the regular way anymore. I concentrated on polishing the flow, eliminating repetitiveness, teaching it our style from comments in review, and adding strict guardrails.

I also got my first compliments from peers who tried it. Then I got my first reviews suggesting new Commands and Skills. I added /learn-from-pull-request, which compiles suggestions from PRs into changes in Skills. I created an automation in Cursor that kept our variation of Compound Engineering in sync with the official plugin.

In a few weeks, we almost tripled the number of PRs. Developers were reviewing a lot, and I was running the workflow from my phone in Cursor, just dictating new features or prototypes I wanted to see. PRs had bugs and problems resolved before a human would even take a look. And the team was encouraged to share knowledge. The joke that “tell developers they are writing Skills, not documentation, and they’ll be happy to do so” became the truth.

Together with our QA, we shipped a project in three weeks that would have taken months before, while keeping the quality to a high standard. Plus, developers themselves started to propose changes:

“We have a good understanding of our domains and well-documented conventions in docs/skills now. Cross-spec reviews catch more actual issues since a fresh perspective spots things that domain experts overlook. Let’s assign reviewers only if you made changes in someone’s domain”

That blew my mind. It was an unexpected effect, demonstrating we’re not just playing with the tools, we’re actually adopting and evolving the whole team process.

In the next cycle, I asked the team for even more: do not use your editors, only use the workflow and “teach” our Claude how to work better. It’s not an experiment for us anymore; it’s a mandatory practice.

So, what’s next?

Interface shifts from human to agent

Linear just dropped an Agent inside the product. We’ve used Linear from almost day one and I’ve always seen them as a good reference point for culture and company standards – from copying their “zero bug policy” to utilising every possible part of a project.

“Issue tracking is dead” was not something surprising to me either. As much as I like Linear, making it a tool for keeping context about your product feels like a natural next step. I still miss a few bits in the product, though. Like the need to switch to Slack to discuss a project. Creating special project channels is a frustration point for me, as I want the Linear Agent to see these conversations as well. But more and more, it’s not the place for a user to have an experience; it’s a place for AI to communicate with humans. Not UX-first, but AX-first.

Most likely, you have Notion in your team, are using Slack for communication, and Granola for transcripts. All of these have separate agents, MCPs, and CLIs. And, while there are tools, like Claude or Viktor, that connect these together, we don’t really need them as users; we want agents to be in the context without all these bridges. Agents and processes need to be ready for the next step – orchestration.

The described workflow, with all these skills and agents, gave us the desired pace, quality, consistency in the results, and the ability to safely automate manual steps.

It also allowed me to build a very simple orchestrator named “Amoforge”.

When a task with a special label appears in Linear, Amoforge runs our strict and battle-tested workflow. It shares mid-session results in Linear as well as a comment on the task. It opens a PR and monitors its status – comments, conflicts – and reacts to them. It then merges a task as soon as it gets approval. The human is still in the loop to make the best decision for the company. This involves writing a proper task with enough context, documenting decisions in a project, and reviewing results. The human is the knowledge keeper and at the core of the compound, delegating what we can automate.

This pace highlights problems quicker. The processes that felt “slow” before – TDD, code review, domain-driven design – are now what keep the machine from flying apart. The new reality does not replace the engineering discipline. It demands more of it.