Agentic AI Is the Next Big Step in Generative AI

Introduction

Good evening, and welcome to the evening keynote. My name is Simon Harrer, and I want to tell you a bit about agents. But first, a few words about who is standing in front of you tonight, when everyone is already a little tired.

I am a software developer at heart. Among other things, I wrote a book, "Java by Comparison", about writing clean, readable Java code. Fun fact: that book lives on inside Anthropic's models. We know that because of the court case about the pirated copies Anthropic downloaded from the internet, this book and many others, and used for training. The training itself was not the problem in that case. Downloading pirated copies was.

I did a lot in the software development world, and today my home is the data world. I translated the "Data Mesh" book from English into German, and I am Co-Founder and CEO of Entropy Data, a spin-off of INNOQ. But tonight is not about data. Tonight is about agents, software agents.

My First Encounter with Agents

My first encounter with agents was in April 2025. I remember it exactly. I was travelling to an event with a colleague from INNOQ. The train was delayed, so we suddenly had two more hours than planned, and we sat in the restaurant car. My colleague showed me what he was working on. He was using Claude Code, as one of the very first people I knew.

We had a piece of software that needed to know which tables and columns exist in a database. So we thought: we could build a small adapter that connects to the database, reads the metadata, which tables are in the schema, which columns are in each table, and pushes it into the other software through its API.

And we just did it. For two or three hours we only prompted, wrote not a single line of code ourselves, drank quite a few beers, and reviewed everything along the way, the way we had learned it. At the end, we configured the software, entered the secrets, started it up, and it did exactly what we wanted. That blew me away.

What Is an Agent?

What was behind it? It was the first time we dealt with an agent: an LLM in the background that uses tools, again and again in a loop, until it is done and has completed its task.

In our case, that was Claude Code with some old model, I do not even remember which one. As tools, it wrote files, compiled the code, and ran the tests. Everything we now know from the agentic loop. That is basically the simple definition of an agent. There is not more to it. And still, back then, it started to transform the world, or at least my world.

Using Claude Code More and More

After that, I used Claude Code more and more. I had not used it before. I prompted more myself, tried things out, and threw a lot of it away again, because I thought: what a load of rubbish it has written.

But it kept growing. I got the 20 dollar subscription, and I kept hitting its limits. That was annoying.

Opus 4.5 and Opus 4.6

Then Opus 4.5 came out in November 2025. I do not know if you remember that moment as clearly as I do, when you suddenly realized: wow, the size of the tasks I can give this model is so much bigger. The agent together with this model can handle big tasks.

You can see it in the METR chart. The horizontal axis is time, the vertical axis is how long a task would take a human, for tasks the model completes successfully 50% of the time. Opus 4.5 beat the best model before it, GPT-5.1-Codex-Max, by more than two hours.

And shortly after, Opus 4.6 came out and raised it from about five or six hours to around twelve hours. So a task that takes a human twelve hours, Opus 4.6 completes correctly in half of the cases. Many of the tasks we do every day fit under that.

Task Length Doubles Every Six Months

That was the big moment, the magic moment with Opus 4.5. And the task length keeps doubling roughly every six months.

Of course, I then got the 100 dollar plan, because I realized I needed more tokens. I ran into the limit far too often.

Approve Fatigue Leads to YOLO

What came next: you were programming, and Claude kept asking: are you sure you want to run this command on your machine? Please confirm. And an approve fatigue set in. I just pressed Enter, or said "yes, and don't ask again", but it did not remember.

At some point I switched to YOLO mode, and today I use auto mode. That was another one of those moments: you trusted the agent more and more to get it right and to behave well. And you accepted it, because the benefit was simply gigantic. I do not know if you felt the same. For me, the benefit was gigantic.

What Do I Use Agents For? Everything

So here we are today, eleven months after that Opus 4.5 moment. Not even a year. And personally, I do everything with agents. Everything:

• Developing features, including tests
• UI testing with the Playwright MCP server
• Infrastructure provisioning with Terraform
• Performance optimization with the Dash0 MCP server
• Working through tickets with the GitHub CLI
• Generating changelogs automatically
• Creating documentation, including screenshots
• Exploratory testing
• Cost optimization on Microsoft Azure: what is expensive, should I do it differently, do the costs match what I do?
• Writing a patent, reviewing contracts, preparing negotiations
• Customer relationship management
• Filling out tenders and security questionnaires
• Implementing ISO 27001 processes
• Filing travel expenses and matching receipts in DATEV
• Adding things to the wiki, and creating short animated videos

And the list goes on. All of this I now do with agents, with something that is eleven months old. That is mind-blowing.

I Don't Write Code Myself Anymore

As I said at the beginning, I am a software developer at heart. I wrote a book about clean code in Java, about writing code that others can read well. And I do not write code myself anymore. That is crazy.

So I want to take this opportunity and simply say thank you. Those were 25 great years in which I was allowed to write code. All the programming languages I worked in: what I built in Prolog, what I built in Ruby, my first steps in BASIC and Turbo Pascal back in school, PHP websites, Python, and of course a lot of Java in the enterprise world.

Those were 25 wonderful years. And at the same time, it is clear: that is over. I understand it rationally, but emotionally it has not quite sunk in yet. It is simply a crazy time, because we now do all of this with AI agents.

The Baseline

Let's look ahead. How does this agentic world work? What is the standard way of working right now?

A human writes a prompt for the agent. The agent runs off and generates something: program code, a contract document, or a substitute receipt for my travel expenses. Whatever it is. And then I review it. That is the classic way, that is how we all started, and it is the baseline for the whole concept.

With Feedback Loops, AI Can Review Its Own Work

The problem: there is a lot we have to review. So maybe we can help the agent to review a bit by itself. The idea here is feedback loops for the agent. The more feedback loops I give the agent, the more it can review automatically.

There are many kinds. The simplest is the compiler. The agent compiles, gets compile errors, reads the error message, fixes it, and checks again whether it compiles. That is an automatic feedback loop, and it simply runs until the code compiles. The more such feedback loops I can hand over, the better the thing I generate, and the higher the quality of what I end up reviewing.

I wrote down a few: compile the code, run the tests, run linters with best practices, check code quality metrics. But it gets more interesting: how well does our change fit our security guidelines? Does it match the corporate design? Are my architecture constraints met, my macro architecture guidelines? Does it integrate with the other system I have a test environment for? There are thousands, and in your context you will find many more.

What matters is: I have to think in feedback loops. I have to help the agent check quickly and efficiently whether what it generated is good. The more and the better tools you give the agent, the better the result, because it runs with these feedback loops for a long time. Technically you can do it with skills, MCP, or a CLI tool. Conceptually, they are always feedback loops.

Encode Knowledge About Feedback Loops and Guidelines as Skills

The second thing we noticed: we wrote a prompt, and the next time we did a similar task, we had forgotten much of what we prompted. The idea of skills is to write down cleanly, once, how a certain task is done. Even if it is just how to check the security guidelines for a Spring Boot project in your company.

Then I can tell the agent: here is a skill library, and it contains the skill for how we meet our security guidelines. In the prompt I only say "make sure security is fine", and the agent finds the skill and executes it. Reproducibly, to a certain degree, but always with the same instructions. You can encode all your guidelines and company policies in skills, and share them.

Here is an example of a skills repository. Every skill is a subfolder with Markdown files. You share this repository in your company and plug your coding agents into it, and they find the skills.

Let's Make It Easy to Make Good Decisions

Even with skills and feedback loops, we are completely overrun by the amount of things the AI generates. We used to say every pull request must be reviewed by someone else. That person really looked at the code, left nitpick comments like "let's rename this variable", and it went back and forth until everyone was happy and the pull request was merged. We cannot do that anymore. We generate too much. The speed is too high.

What is happening instead: in addition to the thing it generates, the agent also generates a report. And we review the report. We shift the review from the generated thing to the generated report.

Three concrete examples from my company. Top left: a before/after comparison table, color-coded, so I can quickly see what changed and whether I agree. For a UI change, I get before and after screenshots with the changes highlighted, and I can say: this UI change is fine. I do not look at the code for that. And if I care about architecture, I get a high-level architecture diagram, before and after, and I sign off on that.

I do not look at the code anymore. These are pull requests with 4,000 or 5,000 lines, and the next one is just as big. How am I supposed to read that? It is no longer possible. But a report I can assess quickly. We have to optimize these reports for us humans, so we can decide quickly whether a change is good and how to adjust it.

This combines well with feedback loops. I still need them for security. And I can have a skill that creates these reports, so it remembers: database migrations are sensitive, so visualize them, and assess right away whether they are breaking. Share that skill, so everyone on the team uses the same one.

From Human in the Loop to Human on the Loop

So we move from human in the loop to human on the loop. There is a trigger in the system, the agent runs, again with feedback loops and skills, and automatically produces the thing. And at first, no human is planned to review it. Only now and then.

Some call this direction the dark factory: only machines work, and every now and then you switch the light on to review sporadically, and then switch it off again. It is fully automated.

My Agents Are Started Automatically

We already have a few of these agents running. One reacts to exceptions in production. When one comes in, it commits a fix to main, which is deployed to production automatically, and we hope the fix is fine. No human is involved anymore. We restricted it to certain kinds of errors, and we are very happy with it.

Others carry less risk. Once a day, our changelog for our customers is created from the commits. Nobody looks at it anymore. Another agent translates our documentation from English into German, French, and Spanish. Nobody looks at that either. We are only six people in the company. Otherwise this would not be doable at all. That means you have to rely more on feedback loops and skills.

Loop Architecture

I built a website, loop-architecture.com, that describes the direction I am showing here. Let me take you on a thought experiment.

This is a sheet of paper, and I drew various elements on it. In the middle is the code repository of your application, the system you are responsible for. At the top is a system with the logs, traces, and metrics. Then a system with the CI/CD runs and their results. The application runs in the cloud, on Azure, where I can fetch lots of information and even change things. There is a repository for the Terraform infrastructure, and information about the Terraform runs. There is a Jira Service Desk with support tickets from customers, Confluence with documentation and architecture diagrams, Slack for our internal communication, a repository for the documentation and one for the German documentation, OneDrive with files such as our security policies, and a system for our ISO 27001 certification, with our vendors and risks.

In your context, you probably have many systems where information lives as well. The exciting part: now we can draw edges. Whenever the code changes, I update the documentation automatically, and whenever that changes, I update the German documentation. Whenever there is an error in the logs, traces, and metrics, I do an autofix in my Git repository. Whenever a CI/CD run fails, I do an autofix and run CI/CD again. Whenever a Jira Service Desk ticket comes in, I automatically create a pull request that already implements the feature, and a human only has to look at the report and press OK, or iterate.

Think in these big feedback loops for your software development lifecycle, and ask where you can put agents. Not all agents are critical like the one that fixes straight into main and deploys. Translating docs into German has no customer data and no risk. For me that is totally low risk: just let an agent do it. That is what I want to give you: try drawing something like this at home. The elements, and then the edges. You do not have to use paper. I just like paper.

Loops in Practice

Here is the same thing, a bit more polished. From the app repository, the changelog is generated automatically. The docs are generated automatically, and then translated. We also have a marketing page, and we keep the features described there in sync, so when we build a great new feature, it shows up there automatically too.

Or the DevOps side, with Dash0, a provider for OpenTelemetry observability. Either I fix my errors directly, or I triage first: ask in Slack, create a ticket, and then another loop fixes those tickets. On the compliance side, loops keep the evidence in OneDrive up to date and implement the ISO 27001 controls from Kertos in the app.

Logic Moves Into Skills

I said "commit right away", but you can always do one step less. Instead of committing, I create a gap analysis and inform a human, who then has to do something. That is the human in the loop step. When I am confident enough, I switch to human on the loop and take the human out. They do not have to press OK every time, because at some point you get the approve fatigue from the beginning again, just on a larger scale. And then we switch to YOLO again. I think that will happen here too.

You can automate this. This is live from our system in Claude Code routines, an agentic runtime in the cloud at Anthropic. The changelog sync at the top right is the one we run, daily at 9 a.m. In its first line it says: use the update-changelog skill. The prompt is tiny. It just points to the skill, where the actual logic lives. The logic moves into skills.

Draw Your Own Loop Architecture

Here are the instructions I want to give you. Draw all your systems, brainstorm which edges you can draw, and add the triggers. Then just try it. Where is your information? Where are your dependencies? Where do your macro architecture guidelines live, your security guidelines? What influences how you build your software? Maybe business requirements, maybe other relevant systems.

Even if you do not fully automate it and just type it in manually and say "compare", you will see: interesting, we deviate quite a lot. That is always the first thing you notice, and it shows how valuable it is to bring this information in.

I recently did this for our website. Google has the search index, and Google tells you how your website stands in it. You can connect that. I can also connect our web analytics, how visitors use our website. Then I use both to improve my HTML pages. Same principle. It takes a while until the search index improves, but it is one big feedback loop that keeps improving my website. These feedback loops can get very big.

I'm Planning with This AI Budget

I am CEO of a small company of six people. What does this mean for me? First, I am planning the AI budget. Last year we really started with the 20 dollar plan per person per month. Now we are at a bit more than 100 euros per person per month, and for the coming years we budgeted 1,000 to 2,000 euros per person per month.

I do not know if it will really turn out like that. That is just how I prepare. Costs go down, models get better, maybe there are alternatives from China, but what we do with agents is not getting less. Our usage is growing exponentially. You have to budget and price that in, so you are not surprised. Right now we simply benefit from heavily subsidized subscriptions.

I Won't Be Renewing the IntelliJ Licenses

I will not renew the IntelliJ licenses. As Ralf D. Müller put it: the IDE is dead, you just haven't noticed yet.

I do not code myself anymore, so why would I need an IDE for coding? You could say I need one for reviewing. But I do not review code anymore either, I review the report. So what do I need it for? And if I really need one, I can use VS Code. I would rather spend that money on AI. That is my perspective.

I Can Build a B2B SaaS Startup with 6 Engineers

The really exciting part is that we, as a six-person startup, can do a gigantic amount. You can think big. If you set your mind to it, you can build big features you could never have built before, such as integrations with large vendors, where their documentation is good and ours is clear. That would have been so much effort before.

A funny story: last week I was at an event with other vendors, and I said: it would be cool to have an integration between us. The other one said: yes, exactly. So I sat down and prompted it. Three or four hours later it was done, and now the partnership can start. Things change when you can move at that speed. It will not be perfect, so you iterate. But nobody in this world says: let's plan this integration for two months. You can always say: I'll take half a day, then the first prototype is there, and we go from there.

Sometimes we are much too fast for our customers. B2B customers are often slow and a bit overwhelmed by our delivery speed. And at the same time they expect it to go much faster. If I tell a customer "thanks for your feature idea, it goes on the roadmap, maybe in six months", some customers say: are you crazy? You have agentic AI. Where is the problem? Expectations have risen enormously.

I had it again today. A customer reported a problem. One person's first reaction was: let's create a ticket. The other said: I had 20 minutes, I already built it. What is the better reaction for the customer? Expectations will become gigantic. "Let's create a ticket" means: it will not happen.

The real bottleneck now: I can build everything, and very quickly. I have to know what I want to build. How do I want to shape my product? That is the exciting part, at least in my startup.

I Hire Very Little Now, and When I Do, It's More Likely…

One more point on hiring, because agentic AI changed that too. Whom do we hire? We hire very little, because a few people can achieve a gigantic amount.

When we hire, we hire either juniors who grew up AI-native. I do not have to explain anything to them. When a customer asks for an integration, they sit down and prototype it in two hours. They think that way: the customer asks, and the prompt is started immediately. That mindset is there.

Or I hire a principal. They are expensive, but they have a lot of experience with customers, they can integrate my feedback loops, build my skills, they have deep knowledge and good taste from their experience. For that, I am willing to pay the premium. In between, it gets difficult. If I have the choice, I would rather take one of the other two. That changes the job market too.

Two Tasks for Architects

I wrote down two core topics. The first: macro architecture guidelines and security guidelines. They are not becoming less important, because they are part of the feedback loops and part of your skills, and you need to build them. That is how you get quality into the applications you are co-responsible for. It is part of the harness, or whatever you call it, and its impact is very big. Privacy, dependency management, API management: all of these topics go in there.

Make sure this gets introduced, that you control it, that your knowledge and rules go in, and that they are enforced. Maybe start with the monitoring approach, with gap analysis. You do not have to push changes right away. Set it all up and run gap analyses across all systems: do your systems currently meet your macro architecture guidelines and security requirements? Then go from there.

The second task is loop architecture. Help your teams think about where they have dependencies. Can I learn something? Can I automatically, or at first assistant-style, improve my software from my log files? Can I use these sources? And make sure there is a good agent runtime to run these agents, because not everyone has an Anthropic subscription and can use Claude Code routines.

The Opportunities Elsewhere Are Many Times Greater

Agentic coding is the AI killer feature right now. But we are a bubble, the software development bubble, and it is actually small. There is an area where the opportunities of agentic AI are a thousand times greater. Some of you may already see it, but as software developers we sometimes do not.

The opportunity is much, much bigger when we automate the real business processes of a company. That is the lever. I automate my customer support center with AI agents. Or my returns process. Not by hiring people to make phone calls, but with an AI agent working in real time with specialized models. That is where the gigantic potential is. Compared to that, agentic coding is nice. This is the transformative potential, and we sometimes forget it when we dive too deep into software development.

Agents Are Data Hungry: It's All About Governance

What does that look like? An army of agents is coming, because the business will want it. They want to access your enterprise data and APIs, and then they can automate business processes.

Once agents can reach the databases and APIs, I can tell an agent: do this task. A customer calls, the agent sees the phone number, looks up the customer in the database, and sends them a gift card through a REST API call, because they complained and need to be calmed down. An agent can simply do that with a few MCP calls.

But for agents to do that, they need to know: what does the data in here mean? What does this API mean? Am I allowed to use it at all, and for which purpose? Is my use case covered? How do I get access? What quality does it have, and do the SLAs fit? Maybe the data is outdated, a customer calls, and the data product only has data from last month, so I cannot use it. These are the big topics of the future.

A Once-in-a-Lifetime Opportunity

Why am I telling you this? In my view, no one is better suited to help shape this than you, the software architects. This is the big lever. It changes every company.

So use this once-in-a-lifetime opportunity. Think beyond classic software development. Where do you already see this happening in your company? Where are people doing it? If you have the chance to be part of it, I recommend you take it, because I believe this will be the big lever.