It wasn't long ago that we hosted our first #AIMaxxing meetup at Pandektes' new HQ in Copenhagen. Despite the terrible name, the evening was a success, and we've already started planning the next one.

For the past few months, we've been running internal sessions under the same name (and I'm very open to suggestions for a better one). We started them to get out of the little silos we'd built for ourselves. Each of us had developed a slightly different setup and way of working with AI, and it was clear we could learn a lot more from one another.

So we started meeting once a month to show each other what we were building, and how. Before long we were inviting guests: Maciek walked us through how they build at Linear, and Mitchell showed us how Cognition uses Devin to build Devin.

Along the way, I realised the value isn't only in sharing what we learn. It's in having a broader peer group to learn from. I wanted that circle to be bigger, and closer to home. So we opened the doors to people from across the Copenhagen tech scene.

Why does this matter so much to us? Some of the biggest companies in legal AI have raised more in a single round than we have in total. We still compete with them for the same budgets, often in the same customer meetings. We can't out-hire them, so we have to out-ship them. And in legal, speed only counts if the quality holds.

This write up focuses on what Lucas and I shared that night: how our product team works, and what has made the biggest difference.

Organisation > token utilisation

We're a small product team of 13, mostly engineers, plus two product designers and two legal engineers. As a company, we've raised around €16 million to date. Compared to others in legal tech, we have far fewer resources to work with. Yet we compete with them for the same budgets, often in the same customer meetings.

We keep a high velocity as a team, and we think that's mostly down to how we've organised ourselves, and less about how much AI we use.

We act as one big product team, but regularly break off into smaller project teams. We spin projects up and down as needed, which gives people the chance to work across the app in different domains.

We keep a few simple rules for running a project. Every project:

• is created and visible in Linear

• has its own Slack channel, connected to the project in Linear

• has one lead, who keeps both up to date so anyone in the company can follow along

These days, we only have three fixed rituals. A 30-minute (usually shorter) planning every two weeks. Quality Wednesdays every Wednesday, which we borrowed from Linear. And a retro at the end of each two-week cycle.

Linear

For a long time, we weren't very disciplined about Linear. We tracked planning loosely in Notion. Planning always took an hour, we were rarely prepared for it, and nobody found it very useful.

Connecting our agents to Linear through its MCP helped. It's up to each project lead to make sure the work is scoped, the issues are created and everything is correctly represented in Linear, and many of us were already using the MCP for that. But the real tipping point was when we started using the Linear bot in Slack.

From that day, you could see collaboration happening in real time. The number of issues we create each week went up about 8.5 times, from around 15 to around 124. That isn't more bugs. It's more of the work becoming visible, because logging it now takes seconds. Linear went from the place where things went to die in the backlog to somewhere you could watch real progress, as issues moved into review and out to production.

A regular workflow for me now: I take the transcript from a feature testing session, drop it into Slack, and let Linear slice it into issues. Then I share the thread with whoever asked for the changes, so they can follow along and see exactly when their requests are handled.

Devin

The next big accelerator was Devin, a coding agent that runs every session in the cloud. It started as a reviewer on every pull request, and it wasn't an instant hit. Some of us found it annoying; it would flag the same thing again and again. But it also caught things we never would have.

Lucas championed it and set it up to run our whole app in its own cloud environment, so it could build and test features end to end. Even then, many of us, myself included, were stuck in our ways for a while and struggled to break the habit of working locally. The tipping point here was making Devin available through Linear, so any issue could be delegated to it directly. Suddenly, a whole new set of possibilities opened up.

A few months ago, we shipped our Word add-in. It was always a bit cumbersome to maintain, until I gave Devin a Microsoft 365 login and set up its environment with the desktop version of Word, which has a much richer feature set than the browser version. Now I can just shout at Devin in Slack to handle incoming bugs and feature requests, without ever needing to log in to Word myself.

Eventually we invited the whole product team into Devin, and, like Linear, we added it to Slack. That brought back pair programming in a way we didn't expect. With an agent in a Slack thread, everyone works with the same agent, in the same context, asynchronously. It's now common to see designers and engineers pairing in Slack, which cuts the time it takes to make design and product decisions, or to get a fix out.

Agents that start on their own

The next step was not waiting for anyone to ask. Something happens in Slack, Linear, GitHub or on a schedule, and the agent starts with the right context and tools, does the work and reports back. Think of it as a background job where the middle isn't a fixed script.

Some of the automations we run today:

• Quality: a deep pull-request reviewer, and changes to the Word add-in that automatically trigger a regression test in the real app.

• Monitoring our deploys: when a deploy fails or a test turns flaky, the agent investigates how often it happens and why, proposes a fix, tests it, and assigns someone to review it.

• Localisation: the agent prepares Danish and German translations, and a person approves them in Slack.

People still make the product decisions, approve, merge and deploy.

When it can't do something, ask what it's missing

We treat the agent like a remote engineer with its own computer. So when it can't do something, our first reaction shouldn't be "it can't do that" but "what is it missing?"

It couldn't really work on our iOS app without a Mac, so we gave it one. Now it builds our iOS changes, runs them in the simulator and posts screenshots and a video. And for the Word add-in, it runs on a Windows machine, which mirrors how our customers actually use it.

We're not great at asking that question every time yet. But each time we do, we fix the gap once, and every future session benefits.

More PRs = faster fixes

From May to October, we merged about 2.6 times as many pull requests as in the same months a year earlier: 2,992 against 1,169. In October, about half of them came from the agent. Our own pull requests went up too.

More pull requests aren't the goal. Faster fixes for customers are. And that speed has a cost, which we'd rather be honest about:

• Review is the new bottleneck. There are more pull requests than we can comfortably review. While you wait for a review, you start something new, then switch back. The context switching adds up.

• Agents copy patterns, good and bad. Old anti-patterns spread quickly when an agent learns from them. Keeping guardrails in place takes discipline, and code that sits between an old and a new data model still needs a human hand. There are no one-shot fixes there.

• More side quests than we can finish. It also means we can take on work we couldn't before. Our new format for ingesting legislation is one of them.

We're now looking at how to make review lighter for low-risk changes. Anything touching security, customer content or infrastructure always gets a second person who didn't write the code. Automated review is a required check, never an approval.

Where we're heading

The direction we're aiming for: ship straight to main, and let agents review every step, watch production after each deploy, toggle feature flags and roll back when something looks wrong. A lot of the team rallied around Thorsten Ball's talk on how Amp works this way.

We're moving towards that together with our compliance team, at a pace that fits the industry we serve. Our customers trust us with legal work and confidential documents, and we won't trade security for speed.

#AIMaxxing will stay open. If you're building with agents too, come by and show us what you've figured out. We'd love to compare notes.

And if this sounds like the way you want to work, we're hiring.