Zdeněk Obst is a Senior Engineering Manager at Ataccama. We spoke about the Ataccama’s newest team structure, the Agentic Pod, and what six months of running one has taught him.

Let’s start from the foundation. Before we dive into Agentic Pods specifically: how does Ataccama approach AI adoption as a company?

At this moment, our AI adoption has three layers. At the top, there’s AI Crew: a cross-functional team that owns the strategic, company-wide approach to AI. This team evaluates which processes can be automated across all functions: people, operations and finance; go to market; and of course, product and engineering. Once processes are mapped AI Crew evaluates which tools are the best to do it and how we support all the Ataccamers across the organization with trainings and day to day adoption.

Closer to software engineering sits the AI Circle. Effectively a horizontal structure, similar to what other companies call a guild. Its job is to support AI-native development across the software development lifecycle: providing guidelines, evaluating AI tools, that kind of thing.

And then there are Agentic Pods: a new type of AI native team that embedded AI in its daily routine: from processes to coding.

So what exactly is an Agentic Pod?

We started this as a controlled experiment in February 2026. Essentially it’s a team of five people who operate end-to-end and try to use AI as a force multiplier. For context, our regular software engineering teams at Ataccama run seven to ten people. So we deliberately cut the team down and filled it with AI power users, sort of a “two-pizza team,” but smaller and more startup-like.

You called it “experimental” — what does that actually mean in practice?

It’s a controlled experiment, but not a lab experiment. We didn’t put a group of people in a sandbox and say “go play with AI and see what happens”. This team works on a real product, with real customers, real prospects, a real roadmap with real promises, on-call duty, every ceremony a normal team has. It’s an experiment fought on a true battlefield, not in a self-contained sandbox.

Could you tell me more about the team itself?

Five people. Diana is our Product Lead, what you’d call a Product Manager on a regular team. She’s mostly outward-facing: talking to customers and partners, picking which battles are worth fighting. But she also uses AI quite heavily to capture and analyze market signals that help with prioritization. Also she can contribute with smaller code changes directly on her own. Then there’s the engineering side; I’m the Engineering Lead, plus three full-time engineers; Tom and Patrik; who are front-end experts, and Igor, who’s a backend expert.

OK, so we have a team, now can you describe the processes and the flow how Agentic Pod operates?

It starts with signals. Signals are exactly what they sound like, inputs from anywhere that tell us what people want from the product. We have developed AI skills that operate across our platforms and gather those signals. This ranges from customer requests that land in an inbox, discussions in internal Slack channels about what sales or pre-sales are hearing, to call transcripts, to notes from Notion. We use AI to capture all of that into what’s essentially a “Notion database”, a simple, structured list of things. Ideally attributed to a specific customer or an Ataccamer requesting them.

Regularly, we turn clusters of signals into capabilities, another Notion database, a step more refined and structured. A capability might map three or four signals into one item, as often they are similar. This process is entirely captured by AI. Think of it as unprioritized backlog. This whole step, from signal to capability, is automated, AI crawls, gathers, and clusters it.

From there, our Product Lead deliberately picks a single capability to build a key human decision that AI supports rather than automates, and turns it into a one-pager: a short, yet essential document describing the problem, the context, why we want to build it, and a very high-level user flow.

That one-pager gets assigned to a single developer, who owns it end to end. They turn it into what we call a Spec Jam, and Spec Jam isn’t just a document, it’s a whole process, and it’s actually also a skill in our internal Claude marketplace. The Spec Jam is the de facto PRD (Product Requirements Document) defining scope, out-of-scope, acceptance criteria, constraints and it is still written at a business and product level, not a technical one.

The owner drafts the first version with the help of AI, shares it with the team, and everyone comments in Notion on whatever’s unclear. We also generate a list of open questions, partly by AI, partly by people, flagging gaps the initial spec might have missed. AI contribution is especially valuable here, as it’s brainstorming power excels at discovering edge cases and potential gaps that humans might overlook. Then the team gets on a call, sometimes two or three calls for a bigger feature, and works through the comments and questions together. The goal is to take all the knowledge and ideas the team has about the feature and materialize it in the document. We record and transcribe those calls, and AI updates the Notion page afterward. Every question gets a traffic-light status: green, yellow, or red. The goal is to get most of the items green or at least mostly green with a couple yellows that can be sorted out later during implementation, no open comments, before moving on.

And once the spec is settled?

The majority of follow-up work happens in repositories rather than in Notion. The Product Lead is usually less involved at this point. The owning engineer writes a Design Doc, which focuses strictly on software design (how code structures and modules change, not just UI/UX design), living as a markdown file in the actual Git repository, written in the context of the existing codebase. It might name specific modules or classes that need to change, not exhaustive detail, but enough to convey the shape of the implementation. It goes through a normal merge request and gets reviewed by most of the team.

Then comes implementation. Honestly, this step takes less time than the phases before it, we spend most of our effort making sure we’re building the right thing, and AI has made the actual building comparatively fast. Although It’s not always one-shot and sometimes it takes multiple iterations.

We also consult customers during the implementation phase, using actual working software, not wireframes. In the pre-AI era, we’d build wireframes but now it’s often faster to build a real UI, show it to the customer, and throw it away if it’s wrong, than to spend time on a wireframe.

Once it’s done, we review and test it, and reviewing takes a real chunk of time these days because even if we add a lot of context to AI, we still see it does not get things right, at least not on the first try. Then we ship it behind feature flags, rolling out gradually until it’s generally available.

You’ve mentioned AI several times as a “force multiplier” — but where do people remain irreplaceable in this process?

A few places, and they matter a lot. First: judgment. AI output today is far from optimal, we don’t have fully autonomous workflows, because we can’t just trust what comes out. Someone has to review it, steer it, correct it.

Second: domain expertise in review. Even though our engineers now contribute across the whole stack, we still lean on people’s original specialization when reviewing. Former backend experts review more critical backend contributions, especially AI-assisted ones written by a frontend person, and vice versa. We’re better at cross-stack work than we used to be, but we’re not a team of true full-stack experts yet. But we as a team are getting better at this.

Third: and probably the most important. Resolving ambiguity and materializing domain knowledge. The whole point of the Spec Jam review is that a room full of people with real domain knowledge argues through the gaps AI can’t see, so we build the right thing. That’s fundamentally human work even though AI still supports us and provides its ideas as well.

Fourth: and this one’s easy to overlook. Sustainable pace. AI makes it dangerously easy to keep going. Someone has to notice when the team is heading toward burnout, and that’s a leadership responsibility, not something you can automate.

As a summary, what would you recommend to any leader who is undergoing an AI transformation in the organisation, to watch for?

If you take nothing else away from our experience, I would say, use the time AI frees up to deepen engineering ownership through domain knowledge. AI shouldn’t just help you ship faster code; it should accelerate and support how engineers become true product engineers who deeply understand the domain they build for.

Here are the points I would suggest as of today, but remember that AI recommendations get outdated pretty soon these days:

1. Deliberately reinvest the saved time into domain mastery

The single best outcome of our setup was that our engineers effectively became product engineers, talking directly to customers and deeply understanding their problem space. But don’t expect this to happen automatically. Deliberately redirect the time saved on implementation toward product and customer thinking, to ensure that the outcome is what you need to create the best product on the market.

2. Don’t confuse broader contribution with true full-stack fluency

AI enables engineers to cross stack boundaries much faster. It still requires a decent amount of time and training to get to true full-stack. However, it is way easier to get there with the help of AI.

3. Clean house before scaling up AI

A messy codebase produces messy AI output; a clean codebase produces better results. Before leaning hard into AI-assisted development, materialize your team’s tribal knowledge: document your code structures, enforce strict static analysis rules, and define explicit prompt rules (like custom AI guidelines). Codebase hygiene is your highest-leverage investment before scaling.

4. Actively defend your team’s focus against “one-more-prompt” burnout

The low friction of AI creates a subtle, dangerous pull to juggle too many things at once. Establish clear guardrails: aim for one or two deep-focus topics plus a handful of genuinely small tasks at a time. The warning sign for me personally is when I return to an open session and can’t recall what it originally was about. Then I know that I probably run too many parallel sessions at a time. Address this proactively in 1:1s.

5. Retain human steering and plan for tool redundancy

AI output still requires human judgment and direction. Furthermore, rely on fallbacks: AI model providers have outages, token limits exist, and pricing can change. Be careful not to let your team’s execution rely entirely on a third-party tool’s uptime.

6. Swap broad AI lectures for targeted, problem-driven working sessions

While broad AI training sessions work well for general tool awareness, real skill growth happens in smaller and targeted groups. Have your team’s write down their specific, day-to-day pain points, questions or just uncertainties about AI development, then pair them with 1–3 dedicated power users for an hour of focused discussion about those. That targeted approach is what actually works better than frontal lectures to a broad audience.

Note

This blog post was created as a follow up to Zdenek’s presentation of Engineering Leading Community, hosted by Ataccama