You know that I'm ambivalent about the use of AI. I use AI for "dumb" tasks like summarizing or analyzing documents, but also for more complex tasks like Vibe Coding (e.g. that's how Cylenivo was created - more on that in the linked article). At our company, we also keep discussing where there's potential for using AI - just like everyone else. But that's not what this article is about.

We are (still) experiencing an acceleration through the use of AI when we look at pure output. There are even companies that, completely incomprehensible to me, use consumed tokens as a goal or metric for evaluating devs - and it even has a name: Tokenmaxxing (Oh dear). That alone would be worth another article. In my estimation, this acceleration will continue for now.

What we see far too little of, however, is the measurement of the value of this output. Is your product, which is being developed at this increasing speed, also getting better at the same speed or with the same acceleration? I continue to doubt that.

I deliberately spoke of output above and not of Outcome. For me, outcome is strictly tied to value. What value have we added to the product through the change?

To answer this question, I like to turn to my Work-Feedback Loop. The fundamental thesis of the WFL and of agile work is: The product must prove itself in reality and respond to real feedback in a short time. In the Work-Feedback Loop, we have a cycle for this that puts it simply but concisely, as described here:

A system only learns reliably from reality if all four steps are actually coupled:

1. Work creates a real effect (not just internal activity),
2. that effect becomes visible as feedback (as a signal, not an opinion),
3. it leads to a decision (priorities/assumptions/resources change),
4. and that decision changes future work.

If AI now accelerates us on the work side and is meanwhile capable of doing so fairly error-free, then Feedback must be accelerated too. Specifically, feedback from reality. Only then do we have a closed loop. But I strongly doubt that the majority of product development/product management receives and/or can process this feedback at that speed.

If that's not the case, we end up in the "Actionism" quadrant of the Diagnosis Matrix. We invest without knowing whether the result actually creates value. A startup can do that, but not an insurance company or a bank. And if an insurance company does it anyway, we end up in Enshittification land, which all users famously love.

And that's where the myth of system acceleration through AI breaks down - the one that the Sams and Darios of this world preach to us.

I have a wonderful quote from ThePrimeagen from a Talk for you:

If the cost of a line of code has dramatically dropped, then the cost of the right line of code has dramatically increased.

I think that makes it clear that a system doesn't necessarily become more productive just because it becomes faster.

I would wish that all of us - especially in the agile bubble - talk more about the Feedback Loop again when we discuss AI adoption and how to deal with it.

Most flow tools act as if their real customer is the manager. Dashboard, traffic light, heatmap, reporting done. In that story, the team shows up only as a data supplier.

That's one of the reasons I built Cylenivo (another is that Jira simply doesn't have any good or meaningful reporting).

What it's about

Cylenivo is a small, free desktop app (Windows, Mac and Linux) that computes Cycle Time, Lead Time, Throughput, Time in Status and Rework from your ticket data. It pulls the data from Jira, or via plugins from Trello or OpenProject, and processes it locally.

That's the whole trick: an insight tool, not a surveillance tool.

Why I built it

Because I wanted to know how long tickets actually sit around in our team. Not "what is done_date – start_date", but where the time really leaks away. In which status. How often tickets move backwards ("rework"). Which workflow step is the hidden bottleneck.

You can't answer those questions cleanly in any PM tool, because most tools work off ticket fields. Cylenivo works off status transitions and uses every single from_status → to_status step with a timestamp. That's the difference between "the ticket was open for 12 days" and "the ticket was in Review for 4 days, then back in Dev for 6 days, then in Review again for 2 days". The second story is the interesting one.

What you do with it in the team

You look at the cycle time distribution together. P50, P85, P95. The question is not "who is slow". The question is "what do we learn from this".

If the P85 is twice as high as the P50, you have an outlier problem: something is regularly throwing tickets back. Look into the rework analysis. Which status path is walked backwards most often? Which tickets are affected? That's a diagnosis, not a verdict.

That's exactly what makes Cylenivo a tool for the Work–Feedback Loop: you shorten the loop between "we work" and "we see what our work produces". Visibility into real lead times and rework gives the team something it can use to adjust its own process. Without someone from outside showing up and defining "measures".

What it is not

Cylenivo is not a velocity dashboard for management. Cylenivo has no personal metrics and no speed leaderboards. Anyone using Cylenivo to compare individual developers has missed the point of the tool, and won't get anything useful out of the data anyway.

What it can do: Monte Carlo forecasts. If someone asks you when the next 30 tickets will be done, you simulate it once from the last few weeks of throughput and give back an honest range. No made-up deadline, no story point magic.

Where the data stays

On your machine: we use a SQLite file in the app directory. If you want to use the AI analysis, you can plug in Ollama locally or configure an external provider of your choice. But no one is forcing you to dump engineering data into a cloud whose business model you don't know. That matters enough to me that it was a design decision, not a feature bullet.

If you want to try it

Cylenivo is open source (MIT + Commons Clause), runs on macOS, Linux and Windows, and has a plugin system for data sources beyond Jira. The app lives at cylenivo.org, the code is at github.com/nobsagile/cylenivo.

If you have a team that wants to look at its own work honestly, the app might be something for you. If you're looking for a reporting tool for the next steering meeting, there are better options.

Let me know how it goes for you – nobsagile@gmail.com or https://mastodon.social/@cylenivo on Mastodon.

This post doesn't really belong here. As you know, this blog is about agile.

But over the past few weeks I've had an experience that's been on my mind, and the reactions to it are what pushed me to write this post. I built a desktop app: Cylenivo, available for Windows, Mac and Linux. I'd had the idea for a while, because Cylenivo fills a gap in Jira: proper analysis of Cycle Time and Lead Time (and a few other small things...).

The catch: I can't code. What I can do is conceive ideas, turn them into good user experiences, and I have the domain knowledge: like how to calculate a Cycle Time in a way that actually makes sense (which is more complex than you'd think...).

What's also changed in 2026: AI coding has taken another significant step forward. The tools from the major vendors around AI-assisted development have improved considerably compared to, say, 2024.

What has really changed since 2024

For Cylenivo I worked with Claude Code. I could just as well have used Codex or Gemini. This article isn't about which model is best. What interests me is the state of things in 2026, and that state is different from what it was in 2024 or 2025. I've done a lot of experimenting with AI-assisted development over the years and was often disappointed with the results. That's changed. The quality of the output, the reliability in more complex contexts, the ability to produce coherent code across multiple iterations - all of that has improved substantially.

That's the background, to give you some context.

The feedback that made me write this

Cylenivo has received various reactions. One of them was, roughly: "Won't touch it, it's made with AI." I've thought about that, and I can understand the sentiment to a degree (I'll get to that in the next chapter). What bothers me is that the most important question gets completely ignored: Does the app solve a problem? Does it do what it was built to do? Is it useful? For some people, that no longer seems to matter once the word "AI" enters the room. And I don't think that's a sensible position. Not because of my app, but when you follow that logic further.

I think this is a disconnect from reality that doesn't hold up under sober examination. The majority of software in use today almost certainly contains elements that were built with AI assistance. And that share is only going to grow. Anyone who wants to consistently reject AI-assisted development will struggle to find software they're willing to use.

And then there's AI slop. That irritates me too: empty LinkedIn posts that were obviously generated by a model and contain nothing of substance, videos where AI-generated voices read out meaningless text, products where AI features were bolted on because it's trendy, not because they add any value. That is AI slop.

But an app that solves a concrete problem is not slop. Regardless of what it was built with. A lot of things are being thrown into the same bucket right now that simply don't belong together.

The real disadvantages that deserve to be taken seriously

Of course I have serious concerns about where all of this is taking us. And there are legitimate objections to AI and AI in software development that I share, particularly because in my job I carry responsibility for developers.

The most obvious objection is the environmental one. The energy consumption of large language models is substantial, and the infrastructure behind them is not carbon-neutral. Anyone who factors that into their decision has good reasons for doing so.

A second objection concerns training data. Models were trained on code and content where the questions of copyright and consent haven't been clearly answered. On top of that, there's the question of what happens to the data you enter during use. These are legitimate concerns that I don't want to argue away.

What concerns me most personally is the question of developer growth. If AI is increasingly writing the code, what happens to the learning process? How does a junior become a senior when the bulk of the cognitive work is handled by a model? Will we eventually see a generation of developers who are good at reviewing code, but not at thinking it through? I don't have an answer to that. The question is entirely valid.

Then there's speed itself as a risk. AI significantly accelerates the production of code. But feedback cycles — the question of whether what you're producing is actually needed — don't move any faster (see also: Work-Feedback Loop). The risk of pure output-driven activity shouldn't be underestimated: we build more, faster, but not necessarily the right things.

And finally, there's the issue of dependency. Anyone who deeply embeds their development processes in AI tools becomes dependent on companies that are free to set their own prices and terms. We've seen this pattern before, for example with Uber. They effectively displaced the traditional taxi market in many US cities. Now that the alternatives are gone, prices are rising. The same risk exists with AI infrastructure, once market penetration is high enough.

What AI makes possible in development

All that said, there are tangible advantages that belong in this conversation. The most important one for me: someone who can't code can still bring an idea to life. That's not a small thing. Cylenivo, by my rough estimate, represents the equivalent of several hundred hours of development work. As a hobby project that I offer as a free download, that would simply have been unaffordable through an agency or a freelance developer. The idea would have stayed in my head, and a product that can help teams would never have existed.

AI also makes development faster (by now across the entire product lifecycle) and in certain contexts more cost-effective than purely human development. That's an economic fact, and a threatening one. But it remains a fact, and in a market where you're competing globally, it's not economically rational to ignore that potential - unless you're comfortable watching a business die. That sounds dramatic, but ultimately, that's where it leads.

Myths that no longer hold true in 2026

There are several persistent beliefs about AI-assisted development that may have been accurate in 2024 but no longer reflect reality. The first myth is that it only works with a perfect one-shot prompt, that you need to know exactly what you want from the start, and that any failure means starting over. That's no longer the case. Iterative development, corrections, follow-up questions, discarding partial approaches and restarting in a specific area, that's a completely normal workflow today.

The second myth is that AI gets hopelessly lost in complex projects. That also no longer matches my experience, provided you create the right conditions.

The third myth, which I still encounter from time to time: more complex ideas simply can't be implemented. Cylenivo is not a simple product. It includes calculations, database logic, a GUI for three operating systems, and export functionality. And yet it was entirely possible to build.

Then there's the fourth myth of poor code quality and maintainability. In reality, that depends (as it does with human developers) on how you approach the work. Anyone who takes AI-generated code without review may well end up with poor code. Anyone who works in a structured way, reviews regularly, and explicitly checks for architecture issues, security vulnerabilities and potential bugs gets something different. The source code of Cylenivo is publicly available on GitHub. Take a look and give feedback - that's explicitly welcome and I'd genuinely appreciate it.

What you actually need to make this work

In my experience, the demands placed on the person developing with AI are consistently underestimated. The idea that you can simply type in an idea and receive a finished app is still widespread. Often, funnily enough, among people who reject AI entirely. What you actually need can be described across four areas.

First, you need a good harness for the AI: well-structured, detailed information about the project, the tech stack, the architecture. Tools like Context7 help bring up-to-date documentation into context. Meta-information (such as the CLAUDE.md file) needs to be kept continuously up to date. And after every significant change, an explicit review covering architecture, security and bugs is essential, not as an optional step, but as a fixed part of the process. (Again: just like you would with human developers.)

Second, you need domain experience. AI cannot supply a concept or a product vision. Design in the sense of user flows and interaction logic has to come from a human and requires experience. Calculations need to be understood and specified upfront. An example from Cylenivo: what is Cycle Time, really? From which moment to which moment is it measured? Is it measured only once, or also when a ticket crosses the Cycle Time boundaries multiple times? That's a domain decision, not a technical one, and it has to be made by a human.

Third, prompting experience matters considerably. I've been doing this since late 2022, and I'm still learning. The ability to formulate a requirement in a way that the model interprets correctly is not trivial, and it doesn't come without practice.

Fourth: the surrounding toolset is just as important as in traditional development. Tests (properly thought-through tests, not just any tests) are non-negotiable. A solid development environment, clear test scenarios, a structured workflow and small stories. At its core, that's analogous to what human developers need too.

Conclusion

I can understand why people reject AI in software development. The objections (environmental impact, data ethics, the future of the developer profession, dependency on large corporations) are real and deserve serious engagement. What I can't understand is blanket rejection that doesn't actually build on those arguments, but settles for "AI" as a label.

My recommendation is straightforward: look at how AI-assisted development actually works today before you form a fixed opinion. Especially if you're skeptical, and especially if you're a developer. Not because you have to like AI, but because an informed opinion is better than a reflexive one. That's true for this topic just as it is for any other.

I firmly believe that agile work is the best approach when it comes to delivering good software quickly. This doesn’t depend on a specific method, but rather on keeping the Work-Feedback Loop closed and short. That’s why this is my main focus right now.

And I’m annoyed by two things.

On one hand, I hear at conferences, in podcasts, and in my feed that AI is changing everything. That agile work will become obsolete because of it. That teams need to reinvent themselves because a prompt will now handle everything. On the other hand, I hear that AI is the devil’s work, that you should just stay away from it, that it’s all wildly overrated.

In my experience, AI is a tool like Excel (okay, it’s significantly more powerful than Excel, but still just a tool). Like other tools, this one can be used effectively to support agile work. This article presents my pragmatic view of AI.

I’ve been using AI since ChatGPT was released in December 2022 - first out of curiosity, then systematically, then with a sense of disillusionment, and finally pragmatically. I’ve tried a lot of things, wasted a lot of time, and found a few things that really work. That’s what this is about.

My Context

I’m the team lead of a Kanban team with seven people. We work on projects for different, but always the same, clients. I’m not a developer. My work happens in two directions: internally - supporting the team, designing processes, writing user stories, assisting with concept development, etc.; and externally - planning projects with clients, developing strategies with clients, and organizing regular meetings and other coordination sessions.

My daily toolset: Jira, Confluence, Slack, email, calendar, Joplin for notes.

The tool I use for AI is called Claude Cowork. The key reason: It integrates directly with Jira, Confluence, Slack, email, calendar, and Joplin. That makes a difference, which I’ll explain in a moment.

A word on data before anyone asks: I’ve granted AI read-only access to my email and calendar. That’s a decision I made consciously, and one that everyone must make for themselves. I’m not offering advice on this, because it depends on your own situation, your employer, and your personal risk assessment. I’m just reporting what I do.

What AI can really do - and what it can’t

Before I get into specific use cases, here are a few fundamental observations from three years of practical experience:

AI amplifies. If something already works well without AI, AI can make it better. If something is bad, AI makes it worse. That sounds trivial, but it isn’t if you take an honest look.

AI produces a lot. The trap is that you feel productive without actually being so. I’ve experienced this myself. You let AI generate something, it looks good, you feel efficient. But did it really save time? You have to ask yourself this question, again and again, with uncomfortable honesty.

AI can’t think. Anything that requires experience, judgment, or creativity is beyond AI. AI can’t write a user story that’s truly good. Understanding the requirements, identifying the gaps, asking the right questions - that’s human work. What AI is good at: reading large amounts of text quickly, building summaries, finding connections between data points that you yourself would have overlooked if you were in a hurry.

AI makes mistakes. Still. And that won’t change completely. “Human in the loop” isn’t an option; it’s a must.

Use Case 1: Preparing for a Regular Meeting

This is my best example because it most clearly illustrates the difference between “AI as a chat tool” and “AI with access to data.”

I have a so-called “skill” in Claude Cowork, which is basically an instruction file that describes what the AI should do. This skill does the following: It checks the calendar to see when the last regular meeting with the respective client took place. It reads the minutes and notes from the last meeting from Joplin - or, for some clients, from Confluence. It searches Jira for everything that has changed since the last meeting: new stories, status updates, blockers. It reads the relevant emails from the interim period.

From all of this, it generates a structured template: What should I address in the next regular meeting? Which points remain open? What has changed?

What stands out here: The AI finds connections that I, as a human, would have overlooked if I were in a hurry. An email in which a client mentioned an expectation that isn’t included in any story. A status in Jira that doesn’t match the current status in the last note. These cross-references between multiple data sources are the real added value, not the generated text.

Of course, I edit the generated note because AI makes mistakes. And because I want to have the final say. But it’s a good start, and the time savings are real.

Use Case 2: Daily Prep

I’m a participant in the daily stand-up, not a facilitator, but I contribute my perspective as a team lead. I have a dedicated skill for this.

This skill looks at the latest daily log from Joplin and then scans Jira, Slack, and email since the last daily. It generates a new report: What should I address today?

That sounds simple, but it’s actually quite useful in practice. If there are status updates in emails or Slack that haven’t been updated in the corresponding stories, the skill picks up on that. It identifies stories that have been stuck in a status for too long. It sees when someone has sent in a sick note and links that to the story assignments, with a note that the team should check if someone else can take over.

A human can also spot these connections. I review them myself as well, because AI makes mistakes. But the AI finds them reliably and quickly, even when I’m under time pressure. That’s the point.

Use Case 3: General Meeting Preparation

For other meetings, such as project meetings, refinements, or more unstructured coordination sessions, there’s a similar but more flexible skill. It also pulls information from all connected sources and generates a summary of what might be relevant.

The results here are slightly worse than with the Jour-Fix skill. The reason is simple: the more structured a meeting is, the better AI can prepare for it. With the Jour-Fix, the skill knows exactly what to look for. In a more open-ended meeting, the search space is larger, and the AI is less certain about what’s truly important.

Still, this skill is a good starting point. I have to edit the generated note more thoroughly, but I’m not starting from scratch, and that saves time.

I have other smaller use cases, such as summarizing information and analyzing documents, but I think everyone does that by now, so I haven’t focused on them in this article.

What all this means

AI is no substitute for agile work. It doesn’t make teams faster, processes leaner, or feedback loops shorter. People have to do that. With experience, discipline, and the will to truly improve things.

What AI does: It relieves me of the cognitive overhead of laboriously gathering information from various sources. The result is that I can devote my energy to what it’s really needed for - my team, my clients, and the substantive (intellectual) work.

Reducing mental load isn’t a glamorous goal. It’s not “AI changes everything.” But it’s real, measurable, and noticeable every day.

That’s enough for me.

Since publishing the Work-Feedback Loop, I have received a few questions. It is time to address them in an article.

How did the Work Feedback Loop originate/what was the motivation behind it?

In online discussions (primarily on Mastodon), but also at work, I repeatedly found myself asking the question, how do I define agile working? Furthermore, I have increasingly noticed—also for myself—that the term agile is quite overused.

The Work-Feedback Loop emerged from these two perspectives: what is the essence of agile working and how can it be explained without using the term agile?

Ultimately, the point is that we can only work successfully in a fast-paced market if work is closely linked to feedback. It is necessary for feedback to have a direct influence on work. Quote from the first paragraph of the Work-Feedback Loop:

The Work–Feedback Loop is a thinking and diagnostic model that shows whether work in your organization creates real effects, makes them visible, triggers decisions, and actually changes future work. It helps you quickly identify the structural bottleneck that limits adaptability—without debating methods or “agility” as a label.

This concise image is the basis for how the Work-Feedback Loop came about. The development towards a diagnostic model was then the natural next step.

And the term “model” is important to me here. The Work-Feedback Loop is not a method. It is not a replacement for Scrum or Kanban. Nor does it seek to replace other methods and thinking models such as Flight Levels or PDCA.

And that brings us to the second question I have been asked so often.

How does the Work-Feedback Loop position itself in relation to other methods or models?

I think the best way to start is with the following graphic.

Here, I divide the related terms into the dimensions “team level” or “system level” and “supports work” or “explains systems.”

Methods or models that are more operational and closer to the team are located further down. If they are intended more for daily work, they are located further to the right.

Scrum as a method is located at the bottom left of the diagram. The Cynefin framework as a method for classifying complexity and deriving appropriate decisions and courses of action is at the top right.

The Work-Feedback Loop is intended as a conceptual model for diagnosis. It is not to be understood as an everyday tool or even a method. That is why it is positioned relatively high up. The Work Feedback Loop is very good at diagnosing systems, which is why it is positioned relatively far to the right.

This explains the two big questions for now. Of course, I look forward to further feedback – you can reach me here.

Flight Levels describe where decisions are made in an organization. Nested Work–Feedback Loops describe whether those decision layers are capable of learning. The distinction matters. One is a map of coordination and authority. The other is the underlying mechanism that determines learning speed. When both perspectives are combined, what emerges is not another framework hybrid, but a structural lens on how organizations adapt across levels.

Flight Levels are typically understood as three connected strata: operational delivery, cross-team coordination, and strategic direction. Each level represents a distinct locus of decision-making with its own cadence and scope. This view clarifies where work is managed and where intent is set. Yet identifying decision layers does not automatically ensure that those layers respond effectively to reality. That question requires a different perspective, and this is where the Work–Feedback Loop becomes essential.

The Work–Feedback Loop describes a simple structural dynamic: work encounters reality, reality generates feedback, and learning occurs only if that feedback alters subsequent decisions and actions. Learning speed is therefore not determined by how much data an organization collects, but by how safely and economically it can translate signals into change. When we apply this lens to Flight Levels, each level becomes a loop with its own feedback cycle, tempo, and decision rights. The levels are not merely stacked; they are nested.

At the operational level, the loop typically runs at high frequency. Teams build, observe system behavior, adjust code or process, and repeat. Feedback may take the form of test results, runtime signals, defect patterns, or direct user reactions. In well-designed systems, this loop can be tight and responsive. However, operational learning is often constrained by outer loops. Architectural gates, funding structures, or approval mechanisms can delay or dilute response. In such cases, feedback exists, but the ability to act on it is structurally limited. The loop is active, yet partially blocked.

The coordination level introduces a different tempo and a broader scope. Here the focus shifts from individual features to flow across teams and value streams. Signals appear as queue lengths, blocked work, integration friction, or rework patterns. The intention of this loop is not to optimize local productivity but to regulate systemic flow. Nevertheless, coordination loops frequently operate within constraints they do not control. When incentives reward utilization rather than flow, the loop may respond rationally within misaligned guardrails. Learning occurs, but only within boundaries that undermine overall performance.

At the strategic level, the loop stretches further in time and consequence. Decisions concern investment logic, portfolio sequencing, and risk appetite. Feedback arrives as outcome metrics, market response, opportunity cost, and shifts in competitive position. The challenge at this level is rarely the absence of information. It is decision latency. Signals rise from lower loops, yet mechanisms to adjust priorities, funding models, or strategic intent remain slow or ambiguous. Accountability becomes diffuse, and response becomes cautious. Learning decelerates precisely where its leverage would be highest.

Seen through this lens, the critical issue is not the existence of loops but their coupling. Nested Loops imply interdependence. The outer loops define intent and constraints for the inner loops. The inner loops generate signals that should inform and reshape outer decisions. When this downward and upward coupling functions, constraints remain adaptive rather than rigid. When it fails, organizations experience a familiar pattern: high transparency, abundant metrics, frequent reporting, and yet minimal structural movement. Feedback accumulates, but it does not convert into authorized change.

This dynamic explains why introducing Flight Levels alone does not guarantee improvement. Establishing meetings or coordination layers clarifies where conversations occur, but it does not ensure that feedback is translated into economically viable action. The existence of a decision forum does not imply that decision rights are clear, that response options are affordable, or that constraints can be revised without political friction. Without these properties, loops exist in form but not in function.

Nested Work–Feedback Loops provide a diagnostic extension to Flight Levels. They allow us to ask whether each level possesses a defined cadence, whether feedback is systematically interpreted into options, whether those options can be enacted within acceptable risk, and whether decision authority is aligned with responsibility. These questions shift the conversation from coordination rituals to structural capability. They also surface a central insight: scaling is not primarily about adding more coordination layers, but about improving the coupling between loops so that learning propagates across levels.

When Flight Levels are understood as the organization’s decision architecture and Nested Work–Feedback Loops as its learning physics, the focus changes. The goal is no longer merely alignment or transparency. The goal is increasing learning speed across interconnected layers of authority. This requires that feedback from operational reality can influence strategic intent without excessive delay, and that strategic adjustments can reshape operational constraints without destabilizing execution. In such systems, adaptation becomes a property of structure rather than heroics.

The practical implication is straightforward yet demanding. Organizations do not suffer from a lack of feedback. They suffer from structural constraints that prevent feedback from becoming affordable change. By examining Flight Levels through the lens of Nested Work–Feedback Loops, we gain a way to evaluate not just where decisions reside, but whether those decisions are embedded in loops that truly learn. Only then does coordination translate into capability, and only then does structure support sustained learning rather than inhibit it.

If Feedback Doesn’t Change Work, It’s Not Feedback.

Most organizations believe they have feedback. They run retrospectives, collect user input, track metrics and OKRs — and yet the underlying work rarely changes in a meaningful way. Feedback is not information. It is only feedback if it alters the next piece of work. When acting on a signal is slow, expensive, or structurally difficult, the system behaves rationally: it acknowledges the signal and continues as before. That is not a mindset issue. It is a coupling issue. The Work–Feedback Loop is a small thinking model to make that dynamic visible and to diagnose whether a system can actually learn.

Read the full explanation here: The Work–Feedback Loop

If AI were as easy to use as many posts suggest, it wouldn’t require this many posts explaining how to use it.

Over the past months, a clear pattern has emerged in AI-related articles in blogs, podcasts and posts on social media, especially on LinkedIn. The focus is no longer on spelling correction or summarization. Those use cases are commodities by now. Instead, the attention has shifted to much bigger promises: AI for Product Management, HR, Marketing, process automation, even strategy.

What is revealing is not the ambition behind these promises. It is the amount of guidance required to make them work. There are pages-long blog articles and long youtube videos explaining all necessary steps and controls required to make AI “successful” — without acknowledging what this complexity implies. And the authors don't even recognize it.

Most of these articles are not describing simple tools that teams can pick up and use. They describe carefully constructed setups that rely on elaborate prompt instructions, chained interactions, manual validation steps, and repeated human intervention to prevent subtle but costly errors. The more ambitious the use case, the more scaffolding appears around the AI.

These details matter, because they reveal something fundamental. This kind of AI usage is not a plug-and-play accelerator. It is exploratory work. The outcomes are uncertain, variance is high, and feedback is delayed. Progress does not come from execution speed, but from repeated inspection and correction.

This is where the real cost of AI adoption sits. Not primarily in tokens. Not in tooling licenses. The dominant cost is hidden in the work–feedback loop.

Someone tries an approach, inspects the output, adjusts the prompt, adds another safeguard, reruns the process, and evaluates again. Each cycle looks small in isolation. Together, they form a slow and expensive learning loop that is easy to underestimate, especially when the initial demos look impressive.

The paradox is that the more guidance a system needs, the more carefully we should ask where real feedback actually enters the system. Who notices that something is wrong? How quickly does that information affect the next decision? And how expensive is the correction once a mistake slips through?

Before adopting AI, it is worth being explicit about what you are trying to achieve. Are you running an experiment to explore a problem space and generate insight? Or are you trying to accelerate an existing workflow that already works reasonably well?

Both are valid goals, but they have very different economics. In experimental settings, slow and costly feedback loops are often acceptable because learning itself is the objective. In operational workflows, however, those same loops can quietly erase the promised efficiency gains.

In many cases, AI does not reduce the cost of work. It shifts it. And unless the surrounding work–feedback loop is deliberately designed and measured, that shift often makes work more expensive long before it ever gets cheaper.

When organizations talk about agile success, they usually list things they can see on a calendar: Daily Stand-ups, Retrospectives, and Sprint Plannings. They hire Scrum Masters, buy Jira licenses, and call it a "transformation." 

But these are just the tip of the iceberg—the visible rituals of agility. Like a real iceberg, the parts that actually determine whether you move or sink sit below the waterline. If the loop between Work and Feedback isn't getting faster or safer, you aren't "being agile"; you're just participating in expensive theater. Let's look deeper into that.

The Tip: The Surface of "Mechanical Agility"

At the top sit the practices that are easy to buy and easy to measure, but they are enablers, not drivers:

• Frameworks (Scrum, SAFe, Kanban): Rules that organize activity but don't guarantee a single ounce of value.
• Rituals (Dailies, Plannings): Synchronization points that, without the right skills, devolve into mere status reporting.
• Defined Roles: New titles that often hide old command-and-control power structures.

This level represents Mechanical Agility. It feels busy, but it’s an illusion of progress. If you stop here, you've essentially hired a world-class pit crew for a car with a broken engine. You are optimizing for activity (the theater) instead of learning (the craft). Try to look below the waterline!

The Waterline: The Great Lie Detector

The waterline is where the theater meets reality. It acts as a filter: Everything above the line is a promise; everything below is the actual capability to keep that promise. If your teams do "Sprints" (above) but have a brittle architecture and a manual testing process that takes weeks (below), the waterline becomes a wall. You see the motion, but the work never reaches the truth of the market.

Below the Surface: The Operational Physics of the Loop

The real power of agile work lies in the load-bearing structures beneath the water. These aren't "soft topics"—they are technical and economic necessities that determine the latency of your feedback loop. 

1. Operational Principles (The Economic Engine)

• Decision Latency Reduction: Real agility isn't about "empowerment" as a feeling; it's about the technical and organizational ability to get a "Yes" or "No" in minutes, not weeks.
• Economic Reason: The realization that every unvalidated feature is an expensive inventory of risk. If you aren't shipping, you're just gambling with the company's money.
• Technical Judgment: Moving away from "following the process" to "reasoning about the system." Skills beat manuals every time.

2. Engineering Discipline (The Load-Bearing Foundation)

This is where most icebergs melt. Without technical excellence, the rituals at the top become a dead weight that sinks the ship. 

• Technical Confidence: The capability to push the "Deploy" button on a Tuesday afternoon without heart palpitations. This isn't a mindset; it's the result of rigorous CI/CD and automation.
• Slicing & Decoupling: Engineering the work into tiny, independent units. If your architecture is a "Big Ball of Mud," your feedback loop will always be slow, no matter how many Daily Scrums you attend.
• Technical Debt Management: Treating the codebase as a production tool, not a landfill. Continuous refactoring is the only way to keep the cost of change affordable.

3. Cultural Integrity (The Feedback Fuel)

• Time to Truth: How long can you lie to yourselves before a real user tells you the feature is useless? Culture determines if truth is welcomed as data or punished as a failure.
• Psychological Safety as a Performance Metric: Safety is not about being "nice." It's about the speed at which technical risks and mistakes surface so the loop can react.

The Stress Test for Your Iceberg

Don't look at your Jira velocity to measure agility. Ask these two diagnostic questions to see if you've addressed the layers below the surface:

1. The Dependency Test: If we cancelled all meetings (the tip) today, how long would it take for the team to realize they are building the wrong thing? (This measures your Feedback Capability).
2. The Fear Test: How many people have to sign off before a developer can push a small, safe change to production? (This measures your Operational Friction).

Conclusion: Stop Polishing the Tip

Frameworks organize your ignorance. Technical and operational skills eliminate it. If your "Agile Transformation" is focused only on the tip of the iceberg, you are burning money on narrative work—work that only describes the system instead of moving it.

Real agile work happens below the waterline. It's the hard, often invisible labor of building technical confidence and reducing decision latency. It's about mastering the craft so the Work-Feedback Loop can finally spin at the speed of reality.

The label is burnt. The work begins.

Welcome to the workshop.

AI is not a toy anymore

AI – or more precisely: LLMs – has become established. Everyone uses it. Some use it well, some less well. But that’s not what this is about. I’m concerned with the economic side of using AI.

The OpenAIs of this world have managed to keep token prices low since 2022 (roughly in the range of $2–$10 per 1 million tokens, depending on the model). As a result, the costs for many use cases were practically negligible.

I believe that will change in 2026. Time to look at the implications.

We will see a mix of pay-per-token and volume contracts. And in that mix, costs will become relevant – so relevant that they will force decisions. That’s good, because the discourse shifts: away from “AI can do everything” toward “Is this use of AI worth it for us?”. Only then does a feedback loop emerge.

As soon as AI costs money, usage patterns become visible – and assessable.

The return of a familiar kind of waste

The nice thing is: we already know this situation. I’ll use a different example to make the point clear: meetings.

Meetings have low per-instance costs. The frequency is high. And often there is no feedback on impact. That is exactly why meetings are rarely questioned consistently.

Why is that? Meetings convey activity. Coordination feels like work – and therefore like value. But soberly speaking, a meeting is not automatically valuable.

With AI it’s similar. Each individual prompt is written quickly. And the responses from LLMs are designed in such a way that they often create a feeling of success and progress. We have the impression that we are being productive.

Waste rarely comes from big wrong decisions, but from frequently repeated, barely examined micro-costs.

AI without a work-feedback loop

In every activity – large or small – there is a work-feedback loop. Without feedback, we may have done work, but we don’t know whether it was meaningful.

When using AI, we see typical cases in which exactly this feedback part is missing:

• Summarizing without a decision
• Analyzing without consequences
• Generating without use

Important: Output is not the same as impact. That shows: AI amplifies systems – it does not correct them.

Put more precisely: tokens do not create value.

Value only arises when a decision is made or a system state changes. If that doesn’t happen, tokens are a cost item without value creation. And that happens often – precisely because AI is so easily available. We are subject to the false assumption that more information automatically leads to better results.

Value does not arise from knowledge, but from effective decisions.

Visibility is not progress

There is another level: psychology.

AI is also readily used for psychological reasons. Besides the mechanism that LLMs often deliver agreement and a “sense of progress,” motives such as control, modernity, and the feeling of momentum come to the fore. We already know these feedback effects: status meetings, dashboards, or agile rituals – likewise often without real impact.

Too often it’s about narrative work instead of system work. Many AI applications buy reassurance, not flow.

When costs become visible

What happens when costs rise? In that moment, waste becomes measurable: How many tokens did we need for this ticket description? How many for this meeting summary? How many for this decision?

Then you quickly find: under budget pressure, the evaluation of AI use turns out differently. The flow problem – AI as an activity generator without impact – was already there before. Relevant costs only make it impossible to ignore.

Economics doesn’t discipline – it exposes.

What AI will actually demand from teams

What does that mean? Teams must clearly distinguish between work that moves systems and work that only describes systems. With AI use, the central question will become louder: does it make our decision better or faster – or just better justified?

This is not a tool question. It is a system question.

AI forces teams to focus on impact – not efficiency.

Closing thought

AI does not destroy bad systems. It makes their costs visible. If you didn’t have flow before, you now get a bill.

It won’t be AI that will change companies, but the clarity about what they are burning money on.