On 21st of August 2026, I had a chance to attend an internal unconference within Zalando where the topics were around Agentic engineering. It was an interesting experience to learn from what others are thinking about AI, and in this post I picked out some of the interesting musings from my end.

Please note these musings are my interpretations and my thoughts of some discussions I was listening to, and many of them are opinionated.

1. Documentation and Knowledge bases#

Given that Agents are smarter with more knowledge they have, documentation and investing in knowledge bases are becoming priority (again!).

1.1 Faster to write, faster to lag : Just like many other practices, AI has accelerated creating documentation. Or it has gone the other extreme, that the changes go faster and the documentation lags behind even faster. So what are some of the important methodologies to create documentation? Whom do we create them for (humans or agents)? Ensuring that there is less AI slop in documentation becomes even more key, as just because we can create them faster does not guarantee a good quality.

1.2 What kind of documentation? : What are the different kinds of documentation? Fundamentals are making a comeback. It helps if people are able to think what kind of documentation they are writing. The Diátaxis framework names four: tutorials (to learn), how-to guides (to solve a problem), references (to look up facts), and explanations (to understand the why).

1.3 The hardest part is not in the codebase : We think that the biggest pain point in documentation is documenting code, APIs, architecture etc. But actually it might be the tacit knowledge which does not exist anywhere in the codebase. That is the why behind an architectural decision, the alternatives that were weighed and dropped, the domain rules everyone on the team just knows. This means information which might exist in chats, emails, or verbally in meetings.

1.4 The era of passive information is gone : A mental model for me on learning, be it documentation or through a book, is 1) find an anchor point to start my research 2) direct searches to sub parts. Through these jumps of 1) and 2) I would gain a lot of passive knowledge which does not help with the current task but might come handy later. This is disappearing in the RAG era, where you are handed a synthesized answer instead of the source documents, so the browsing between the anchor and the answer never happens.

2. ROI becomes important#

Gone are the era for cheap and subscription based tokens. Its common for most LLM providers to have token based costs. This makes it important to think about ROI at an early stage

2.1 When does an experiment stop being an experiment? : At what point do you stop an experiment and start thinking about the ROI that might come out of it? Usually with experimentation one is not looking at costs to begin with, but has to soon take the token usage and other infrastructure costs into account to see how much they spent as part of the experiment. This matters more with agentic workflows than it did with a chat window the same task can consume many times the tokens, and the spread between two runs of the same experiment can be large. So a cost that looked like a rounding error during the first week of an experiment is not necessarily the cost you carry into production.

2.2 Indicators are not targets : Differentiating indicators (a hint on what to do next) from targets becomes even more important. Here DORA metrics is an indicator which can give you a hint to check bottlenecks and take action based on, say, high lead time in PR reviews. But it should not be a target. This is the DORA team’s own position, that the metrics exist to inform continuous improvement and not to be handed out as goals. The moment you turn one into a target (“every team deploys twice a day by Q4”), Goodhart’s law takes over and the number gets optimised instead of the thing it was standing in for.

2.3 Break the lifecycle down : Productivity improvements are easier to see when you break down the development lifecycle. Think about defining different stages of SDLC which matter, and it can be as granular as necessary depending on how the team operates. It makes it easier to pick a stage and then act upon it to see productivity gains.

2.4 Token sandboxes as guardrails : Token sandboxes and how they can act as guardrails. In practice this means putting hard budgets around the spend, per team, per application, per agent, or per session, so that a request or a run that goes over the line is blocked or stopped rather than silently billed. The useful part is not just the cost ceiling but the circuit breaker. An agent stuck in a retry loop gets halted early instead of burning through a month’s budget overnight.

2.5 Not just direct GMV : The focus can’t just be direct GMV gain. Let’s say there is a topic or initiative which can speed up future addition of software in that particular area. Then there is value in measuring along a different dimension, where here it is more about how it impacts speed of delivery and execution. The GMV gain from that is real, it is just indirect. It shows up as the ability to run more projects, or to get other projects to market faster.

3. Agentic practices in the SDLC, especially code review#

Which are some of the places we are looking into to use agents better? Code review becomes more and more the place with a smoking gun!

3.1 Is review really the bottleneck? : People are bringing up code reviews as the bottleneck. The problem is understandable, code is shipping faster, in larger chunks, which makes more code to review. But an interesting question popped up: is this really the biggest bottleneck, or is it a psychological factor as well that we never really liked to review code and rather enjoyed writing it more?

3.2 New ways of working : Alongside this, the shape of the workflow itself is shifting. Teams are opening a pull request early and letting it be the working surface. The agent’s commits land into an already open PR, and review runs continuously alongside the work instead of arriving as one lump at the end. The broader version of this is that humans move up a level. You review the specification, the architecture and the constraints, while the agents handle the implementation detail and a bot does the first pass over the diff.

3.3 Bots need context : Different bots are cropping up to help with code reviews. It helps if they have additional context of requirements and also domain and architecture. Additionally, there are different levels of bots, where some have more “thinking” like capabilities and can go deeper.

3.4 Specs and tests are back in fashion : Spec-driven development and test-driven development are coming back into fashion. I remember having a conversation with my uncle where I was sharing some research I did with spec driven development, and he mentioned that back in the 90s and 2000s one could not start writing code till the specs were formalised! It feels like the 1990s or early 2000s again, with this resurgence of good coding practices.

3.5 Testing bingo : Testing mechanisms are making a comeback because they bring more confidence in the code. There are two aspects here: AI elevates the risk of changes if your code is not tested properly, or AI makes it faster to write tests and you can increase your test quality (not to be confused with coverage) if leveraged properly. At one point discussions around agentic engineering and testing became a bingo game and all testing practices like “mutation testing”, “smoke tests” and “property tests” made a round :D

3.6 What does 2030 look like? : An interesting exercise: what does a developer’s work look like in 2030? Today we treat code as the contract for what a piece of software does. Will that change completely, to a format AI agents understand better and that isn’t meant for humans at all? Will we not be able to read and understand code anymore, not because we do not have the skills, but because code itself will have evolved into something else? It would be the same move we already made once, where high level languages were built on top of assembly, and today almost nobody reads the assembly their compiler emits.

Closing thoughts#

Now as I was driving home from the unconference, I realised none of the topics we spoke about had anything to do with AI. These are known software engineering problems for decades and they are making a comeback just because they have either been expedited, or we have the tools to solve them. Or rather, we really need to solve them to utilise the full potential of agentic engineering.

I recall listening to a very nice anecdote in the past that when it comes to writing “industrial grade code”, there are 2 kinds of steps. First you design where to write code and come up with a full footprint of your work, and then you write parts of your code and crack it! With the quality of LLMs, the latter is a solved problem, and there is no denying that the individuals who had the most joy cracking that part are the ones now missing it the most. Is this wrong? I don’t know, code was always a medium to have a contract on how a software is supposed to behave! I would be curious to see how this “contract” evolves over time, and to drop an additional blog post on What Is Code? by Unmesh Joshi, which argues that code has always served two purposes: instructions for the machine, and a conceptual model of the problem domain. The first is the part LLMs are commoditising. That gives a different and more abstract mental model on code.