The Engineering of AI Agents: Context, Harnessing, and Autonomy

Yes, I was here last year at QCon, so about a year ago, and I gave a talk with the title from autocomplete to agents. And I tried to just give a bit of the lay of the land of where we are in terms of AI coding, because as Blanca said, everybody's a bit overwhelmed, including me, even though I have time to look into this topic full time. And I'm going to try and do something like that again today. And so a year ago I was mainly talking about the new agentic modes that at the time everybody was starting to pay attention to. The term vibe coding was about two months old at the time I think. MCP was all the rage and Claude Code was still in diapers I think. Like it was already kind of there but not generally available yet. So that's kind of where we were about a year ago. And so I try to kind of reflect on the high level kind of things that happened over the past year. And one of the things is that context engineering evolved. So this is also a term that wasn't even around last year at QCon London. This started being a term that it started floating around around June. And basically the simplest definition of it is you want to curate the information that your model or your agent sees. to get better results. So that's the simple definition. It means different things like when you're building an agent or, you know, using a coding agent, which is what I'll be talking about right now. And again, a year ago, I had a slide that was similar to this one that was talking about the... kind of the state of context engineering at the time for coding agents, which was rules files. So you just have like an agents MD, a cloud MD file in your workspace. And every time you start a session with an agent, the agent gets sent this file. So you can kind of put typical pitfalls, repeated errors in there. So I had a thing like my agent kept forgetting to activate a Python virtual environment every time it ran a Python process. So you would put stuff like that in there. And MCP servers were also around at the time, as I said, which help an agent get more dynamically get data. And so since then, there have been all of these things, right? Not just rules and MCP servers, also commands and skills and sub-agents and plugins and specs. And, you know, so there's been a lot of activity in that space. And I just want to, like, zoom in on one of those things because it's been confusing to quite a lot of people, I think. I took a sabbatical the end of last year, and when I came back, skills had come out. And I was very confused at the beginning what exactly. it is. So I'll try to zoom in a little bit on that. So one thing that skills help you do, so first of all, this was a new concept introduced by Anthropic based on a lot of different things that had already been going on. And so what it basically is, one, it helps you modularize those rules that I was talking about. So you don't just have to have one big file in your workspace that always gets sent to the agent, but you can have like little subfolders that Yeah, that modularize the different things you want to tell the agent. So it can be from like, here's how we usually build a React component all the way to here's how you get logs from our AWS test environment. And so these... modules can then be loaded by an LLM just in time. So that's another big thing. So this kind of progressive kind of lazy loading of context. And the agent or the large language model will just get a description of the skill. So here it's just like a get log skill and the description says get logs from a test environment, for example, for debugging incidents. And then when the large language model realizes, oh, that seems to be what we're doing, there is more information on that. then it's just going to load that so it's not filling up your context window from the start. Then the next thing with skills is that they can include more files than just this markdown file. So you can have additional documentation in this folder. You can have scripts in this folder that you want the agent to execute. So you can have like, it's a folder, it's not just one markdown file. And then as I mentioned, so you can have scripts in here as well, or you can refer, so I mean this you could do this before but it's been a thing that more people have caught on to now that you can just tell the agent in the markdown file to use the CLI that is installed on your machine and this is kind of like the realization that has had a lot of people shift a lot of their use cases away from MCP in agentic coding and just like paid more attention to what CLI's do we already have on our machine what scripts can I write to have my agent do that because you know it's a lot more straightforward than having yet another different type of process running on your machine. So in a nutshell, context engineering is a combination of the following things. So one, it's of course, as always, reusable instructions and conventions, right? So it's, you know, how do you write a React component, how do you bootstrap a new project, stuff like that, but also just like coding conventions and stuff like that. And that is combined with kind of like context interfaces, right? Things like the description of the skill or things like the the list of tools that an MCP server has or the list of tools that are built into the coding agent. So all things that the LLM can then take and say, oh in this situation I want to call this tool, I want to load that skill, I want to call this MCP server tool. So it's all about how can you get this to be intelligently loaded just in time. there's always non-determinism as always involved with this right so you never have a guarantee that the LLM will actually decide to load your skill and as a human then my job becomes a lot to manage that context and also to manage and monitor the context size because even though context windows are of course a lot bigger now technically than they used to be a year ago or especially two years ago still when they kind of get full you can kind of feel the performance, the effectiveness of the agent degrade and also of course like it starts costing a lot more money, right? Because every time you go back and forth with the model you send like the full context window. So there are now encoding agents, there are different features to help you monitor what's actually in your context, and it's actually quite interesting to also see all of the things that take up space, right? So on the left here is a session that I started with Cloud Code, and it was actually very shortly after I started the session, so I hadn't even typed a lot, and already the context window is 15% full, because there's a Cloud Code system prompt, there's all of these context interfaces, like skills that I have and stuff like that, and so that will be you know, that's also part of how you have to balance your skills and all of the things that you give to a coding agent. On the right is also like, yeah, GitHub Copilot also has that feature. So at the moment it's basically the Cloud Code team is leading the pack and then everybody else copies what they're doing. It's a little bit the high level summary. And then finally, a really powerful feature that I would also see as part of context engineering, which started becoming more popular last year as well, is sub-agents. So a lot of the coding agents have that built in now. So it's this idea that the main agent can spawn off sub-agents. And the most common use case of that that we don't even control but that the agents often decide to do is that when you start a session and the agent wants to research what's in your code base, it often spawns a sub-agent to do that. like I don't know if you could some of you might be able to read that on the bottom right there's a cloud code screenshot that shows this explore agent so then because like research often takes up a lot of tokens because it has to read a lot of files and stuff like that and find the ones that are relevant to the task and then it just reports back the result to the main session and the main session doesn't have all of the potentially like over um you know overload of like some stuff that it doesn't have to know But you can also use this yourself. So a very common use case for sub-agents that we as users try to do is like a code review agent, right? A lot of people like to have kind of a separate context window that doesn't know about all of the history in the session, do a code review, or maybe also have that use a different model and so on. So this feature has like unlocked a lot of other stuff that I'll also be talking about in a few minutes. So in the context engineering area, ask yourself what coding conventions do you want to amplify? Because all of this is a way to amplify things with AI, right? Good stuff and bad stuff, right? So it's also... have to be careful what workflows can you maybe build for modernization initiatives like migration is a super good use case for generative ai and now with some of these these options in the coding agents it becomes easier to build something like that i just recently talked to a colleague who was working with a client who had thousands of CICD pipelines in an older tool that they wanted to migrate to GitHub Actions and she was building kind of like a workflow, you know, a human supervised workflow with different sub-agents and skills and MCP servers and stuff like that. What tools should be available in your organization? to make it easier for an agent to take certain actions or to get information. So that can be CLIs, it can be MCP servers, maybe also language servers. I'll get a little bit back to that later, but like if you have, yeah, maybe more unusual languages where you can give the agent more information and tools that actually understand how the language works. Yeah, and not only coding conventions, but also what are practices you want to amplify. My favorite examples that I always mention are things like improving an architecture decision record, or how do you do threat modeling, stuff like that. So you can have those and skills as well to help people actually understand those. There are a few lots of open questions as well. So context engineering is a little bit engineering in quotes, right? So like how do you version and distribute these? So there's like first ideas. There's now these plug-in marketplaces. Some of you might have heard of them. Also again introduced by by Anthropic and the Cloud Code team. But it's still not quite mature. It's all kind of like evolving. And also a big question of course is is the context that you have is it making things better or worse? right and this is all about evals evaluation of of the skills so again entropic just released something to make it easier to to do something like evals the skills registry tesl also released something recently so that's kind of like in the early stages as well so with all the model improvements that of course that of course have also been happening right and this more powerful context engineering There's been this trend towards giving agents more autonomy and reducing human supervision, right? I guess that's what all the hype is always about. Like, when can I just have AI build all of my code, right? So supervised, kind of like me as a developer, I sit in front of the computer, in front of the session, and I still kind of look what it's doing, and I steer, and there's a lot of back and forth versus unsupervised. This is a screenshot from mid of last year when OpenAI's... Codex first came out where you basically have these cloud agents. You just send it off in the cloud maybe for 20 minutes or something to do something for you. And at this point, a lot of the big coding agent products have this ability for you to not only have agents work locally in the IDE, but also in the cloud. So top left here is cursor. Bottom right is Cloud Code. I think Copilot has this as well. And of course now you can also do this from your mobile phone, right? So people starting to code on their commute to work if they have one, I guess. But another option to do this, like you can use these cloud coding agent platforms. But another way to do this is also that because there's been this rise of CLI-based coding assistance, so again, Every one of the big products now also has a command line based version of it. So there's a cursor CLI, there's a copilot CLI. The first one that got a lot of attention, of course, again, is cloud code. And because you can run them in headless mode, you can also put them into your existing pipeline systems, right? So, for example, there are GitHub actions for cloud code and copilot and so on. So, as part of this, a familiar beast rears its head, right? Which is we have to sandbox this somehow, right? Or we have to give the agent a proper environment. So, we have to figure out how to give it all of the tools that it needs, all of the compilers, all of the dev tools, and so on. Out of memory error is just like a representation of, like, you know, we have to give these the right amount of resources and stuff like that. Internet access is in our CICT pipelines with dev sandboxes is already a big question, like how much internet access do we give it or not? And there's like new concerns now with agents with like prompt injection, right? When they load maybe untrusted content on the web. So there's like a few new questions, but some of it is also like existing challenge that we have, right? And not just in the cloud, but there's also a trend to less supervision locally. So this is a... a visual from Steve Yeggy's Gastown blog post, which maybe a lot of you have read, where he's saying, you know, kind of like the, it says the eight stages of deaf evolution to AI and stage six here is having three cloud code instances in parallel on your machine and stage seven is ten instances in parallel. I tried the three instances and it's a lot, like I kept typing the wrong thing into the... wrong session and stuff like that so it's like but it is something that uh in some teams out there is is um actually happening right and so that last picture there the stage eight is like a short intermezzo for the the hype du jour i want to call it which is um agent swarms and gas down is an example of that and there's this project cloud flow that has been around for quite a while i think it was recently renamed um i unfortunately forget the new name And there were these two experiments recently by Cursor and Anthropic as well that got a lot of attention. So by agent swarms I basically mean you send out a lot of agents, like dozens or hundreds. right? So you kind of like throw as many agents as you can at the wall and you see what sticks and maybe are there going to be like emerging new behaviors, how do we coordinate those and so on. And those experiments by Cursor and Anthropic made a lot of people nervous I think. So Cursor basically had a bunch of agents run for, I think the longest run was for a week to build a browser and Anthropic had them build a C compiler and so then people were like oh my god does this mean now you know AI is already there, it can build these things. Like one thing to keep in mind with these two is that both of those use cases, and they were probably also specifically picked for that, cursor actually also say they specifically picked the use case. Both browsers and C-compilers are very very well specified problem. So and the specification is all over the internet. And also, especially in the case of the C compiler, there's even a very, very elaborate test suite that the agent can use to get feedback on if it works or not. And that's often what we don't have when we build enterprise software, right? We don't have it to that level. So I don't think you necessarily have to go and try, like... Gastown for the context of probably what a lot of your work environments are. But if you want to still dip your toes into this, a good way to do that is also Cloud Code released a feature. This is in preview, so you have to switch preview flag, I think, which is called agent teams. Some people use agent teams and swarms as the same thing. I kind of like to think of them conceptually as two different things, right? You either send out like dozens and hundreds of agents that AI even decides which ones to use or maybe you can also do it in like a smaller context right here I was trying this with five agents I think and so the the key is that there needs to be a lot of orchestration right so the main agent kind of decides what can be parallelized they can also talk to each other and stuff like that but this is all like still early days I would say so let's go back bit back to the present and the less supervision like some things that you should be asking yourself like where do you want to experiment with those cloud agents or with like less supervised agents right depending on your environment you might not want to take like large risks but you can experiment with things like cleaning up feature toggles or like lots of people again use like code review agents and stuff like that And then how do you gauge the appropriate level of supervision for a task? And also how do you help people in the organization gauge that level of supervision that you should choose? And so I found myself doing a lot of like micro, sometimes macro, but like lots of little risk assessments when I use AI. Should I use it for this? Should I not use it? How much review should I? apply. And so risk assessment is always in any situation a combination of three things probability, impact and detectability. And in this context for me that is first I think about the probability that AI might get something wrong and that probability depends like I assess that by my knowledge of the context I've given it, by my knowledge of how good the tool works, by my experience of using it for similar things before. So it's something that, you know, like an intuition you have to build up over time using these tools. And it's also about stuff like how confident am I even in my requirements, so how well can I even specify what I want. Impact, of course, is if AI gets something wrong, it's all about the use case criticality, right? Is this a proof of concept or a spike? Or is this something that will get me out of bed at 2 a.m. in the morning on the weekend because it's a critical workflow and I'm on call? And then the detectability is about, it's the detectability that AI got something wrong. So this is all about me knowing my feedback loops. And then by assessing that, I make a decision about like which type of workflow I use. Like do I use a very super elaborate one with like lots of planning in the beginning and stuff like that? Or do I just like start with a quick prompt? It also determines how much I review. So do I just like fully vibe code and not look at anything? Or do I look at every single line of code or something in between? And also, how long do I let it go off without supervision? Because the longer it goes off without supervision, the more I have to review afterwards and actually see what happened. And if you look at these things, actually only the thing that I have highlighted in yellow here now, like knowing the context and knowing how good the AI is at this type of task, that's the new thing, right? All of the other things an experienced developer at least should already be good at, right? But this is kind of like the skill that we have to hone. And it's also about like you have to be this tall to ride the roller coaster. You have to be this tall to reduce. supervision, right? So the probability that AI gets something wrong can increase with like a bad code base, right, because it will pick up on existing patterns. It can increase with like you have like a very, you have a system where things are in lots of different places, so it has like a lower chance to actually get all the information. Detectability is also something like if you don't have feedback loops, if you don't have good test automation and stuff like that, then you have fewer ways to both yourself verify what happened but also give the agent the ability to verify that. And there's more things to be cautious about of course. So I also talk a bit about security and cost. Also two things that have changed over the past year but maybe not in a direction that we like. First of all security, like almost every week now there's some like report of something happening, right? Like so one of the so it's usually all related to prompt injection. So this idea that an agent gets content from an untrusted source that might give it instructions that you weren't aware of, right? So and one thing that can happen with that is unwanted command execution. So all of the agents have like these allow list features in them that let you you can also configure them to say with this pattern or for these commands I usually you know you don't have to bother and ask me if you may execute that but for other ones you maybe always want to say yes you're allowed to yes you're allowed to but there are like some weaknesses in the implementations of these and that combined with like other stuff still not being quite figured out and with AI being non-deterministic is like a risk. Another security risk is the extraction of secrets. This was just from, what is it today, this is from 11 days ago, I think. There was like, so this is like a big risk, especially for open source projects that are open for GitHub issues by anybody, but then immediately trigger like an agent without much supervision. And so this one actually managed through like some prompt injection in GitHub issue to extract the secrets. that allowed the attacker to push to the NPM registry for this particular tool. So it's like not all of this is relevant for what we're doing inside of an enterprise, for example, but it shows us a much increased risk again in the dependencies that we're using and how careful we have to be about the ecosystem that we're pulling into our application. really great model for like thinking through this. I hope a lot of you have already heard about this. If not, then please look it up. Simon Willison wrote about this in June 25, this idea of the lethal trifecta. So when you have an agent that has exposure to untrusted content and access to private data and can externally communicate, then you have a high risk of, yeah. getting data problems, getting security problems with this agent, right? And this is like even more relevant for business use cases of agents, by the way, because as soon as you integrate like email, for example, with read and send rights, permissions into an agent, you already have the lethal trifecta. So it's not a technical problem, it's a conceptual problem, and it will be interesting to see on the business side of things how all of those use cases with agents that were promised to us we'll even be able to get around this. So with less human supervision, security, so think about are you making it easy to sandbox coding agents also locally, not just in the cloud, right? So both with like pre-existing things like dev containers, for example, that I've been using a lot for this recently, but also there's like a bunch of new products popping up that have interesting ideas about this. Yeah, so just like sandboxing your agents even when you run them locally to reduce the supervision. and what is the AI security literacy among the engineers in the organization, right? Like do they even know what's happening under the hood? You know, don't use this YOLO mode where you don't even have to allow any of the commands, it just does what it wants, right? Stuff like that. And then secondly for cost, the honeymoon is definitely also over, right? So in the beginning of 24, I heard a keynote where the keynote speaker said, generating 100 lines of code only costs about 12 cents. Compare that to a developer salary. I mean, leaving aside that lines of code is, of course, not a good measure of value, right? Let's leave that aside. But it's not even like 12 cents anymore. right? So this is from summer 2025. There's some websites where people post their token usage, right? And there was this one person who was using, on average, $380 a day, which if you extrapolate that to 20 workdays a month, 12 months, would be a developer salary of $91,200, which is not a bad developer salary in Germany, to be honest. And of course, this was summer, like this has like exploded even more, right? So we've gone from like $20 flat rates in the beginning, I think Copilot might have even been $10 in the very beginning, right? I'm not sure, to more like $200 flat rates that are not really flat rates because you get request limiting and then you see people on Reddit saying, oh, it's only the middle of the month and I'm out of tokens and what do I do? You know, because we can't work without them anymore. That's a whole other topic. So why is the cost ballpark for a change far from 12 cents now? So now we don't just like, remember like when the the keynote speaker this was like early 24 so we were mainly doing autocomplete right? Maybe asking in a chat for a few lines of code right? But now we have the agent research the existing code then make a plan then we review and adjust the plan. Then we start implementation, we have it run the tests and fix the tests and check the lint errors and fix the lint errors, maybe check the browser if it's a visual UI feature, fix that again, have a code review agent running, react to that, have a summarization. So it's all of this back and forth. And it might even just be two lines of code afterwards, right? So, yeah. So where are we then after these last 12 months? So context engineering, I talked about in the beginning, is like becoming a very powerful lever now of amplification, both for good and bad, but you can actually do a lot of stuff now to make it more probable that the agent does what you want. And then again, model improvements I haven't even explicitly mentioned here. That has definitely also happened, but I find that actually less interesting than all the other stuff that's happening around that. And so as a result of these things, like there are strong forces tempting us. out of the loop, right? So we have to think about like where in a given organization or a given use case can we give into that pool and where is it treacherous, right? So kind of this like, oh this feels really good and gives me like quick results but like what will this mean in a year maybe? Because yeah, so there's kind of like this need for speed, right? Everybody just wants to be faster and more throughput and look how many PRs we merged this week, right? But with this like more autonomy and less supervision there's also not just a question of security and cost but also what happens to maintainability of the code, right? There was an interesting article recently by a team at OpenAI that says they have been working on a code base for the last five months. It started as a greenfield code base and their kind of rule for themselves was we we don't want to touch the code directly, we just want to interact with the agent and then continuously improve the all the setup around it to make it easier for the agent to maintain this autonomously. And it was a mix of these things, so it was like a lot of that context engineering stuff, right, like skills and stuff like that. They also put in more deterministic checks like custom linters and structural tests and stuff like that, and then they still said they kind of had like entropy increasing and like drift happening so they had what they called garbage collection so like agents continuously kind of running against the code base and cleaning up over time and this architectural constraints with more deterministic tools as well this is something that has been popping up in a lot of stories that teams that use agents like this a lot recently. So I also experimented a little bit with it. So it's this idea of having, yeah, structural tests that's agent feedback. So think stuff like ArcUnit or SpringModulus or, in my case, I was working on a TypeScript code base, so I used something called DependencyCruiser, which I had actually never heard of before. And I think the reason is that we've had these tools for quite a while, but I think a lot of people haven't used them because we think we were still working on the code, right? in a lot of cases of course there are, but we were like yeah yeah I know how to modularize, I don't need a tool like to to help me with these constraints, but now they're becoming like really interesting feedback tool for the agents, right? So here in this case in my application I kind of like, and again I worked on this together with AI, defined like the different layers that I wanted in the application and then set up a bunch of different rules. So there was one for example that that said that external SDKs may only be imported by files in this client's folder that had lots of clients for other APIs. You don't want to do that in the domain folder, right? And so then this was like additional feedback for the agent. And what's also interesting about these linters and structural tests and so on is our ability to go and enhance and extend the messages now, right? And make the, it's kind of like a good type of prompt injection, right? So you adjust the messages so that they also contain instructions or hints for the agent how to react to those. So let's say you have maybe like a linting rule, every file may only have 500 lines of code, and if you want to avoid that the agent just makes every line multiple statements, so that it stays in the 500 lines of code, you could put into that error message, that is a smell for a design problem, so you should consider refactoring. So just give it more context on what that message means to us. So this is basically all about how can we increase our trust in the agents, ultimately. building a harness like this, right? So the team called this harness engineering because ultimately, like let's think like a few years from now, I think we're not aiming for perfection that we want the agents to build the perfect code, right? We certainly aren't building perfect code, but how do we get enough confidence and trust for our particular situation? Because we want to safely and quickly in a sustainable way deliver software, right? And so I just wanted to share like a mental model of how I have recently been thinking about this. So again I talked a lot about the context engineering, the skills and so on, and all of those things are kind of like feed forward into the agent, right? So we're anticipating what the agent might do wrong and we're trying to give it all the tools and instructions to increase the probability that it does what we want, right? So those would be like giving it principles, coding conventions, maybe reference documentation, how-tos, and so on and so on. And then after the agent does its first generation of code, very often it's not immediately perfect, so then we give it feedback, right? So static analysis, we have like... maybe give it access to logs and start the application and see if it actually works, the browser and so on, so that all lets the agent do some of the road work of corrections before we even look at what it's doing. And this can actually be a mix of CPU and GPU-based things, right? So I took this framing from this company called Modern, who recently started using that as framing for the CPU-based tools that they use. uh you know we can have a code review agent but uh that is still like based on gpu inference right like what if we enhance that with a lot more cpu based more deterministic things and we can actually have the same thing in the feed forward as well so all the things that i mentioned here before were kind of gpu inference based but if we give the agent access to clis to maybe like bootstrap scripts to code mods like open rewrite recipes and stuff like that then again we can like feed it the things that make it more probable that it does the right thing. And that also comes back here like to the language servers that I mentioned before. So for example you can now give an agent access to something like IntelliJ's refactoring capabilities, right? So it can actually use the rename symbol functionality to do a refactoring instead of doing text diffs all over the place. Again makes it more probable that it does the right thing in the first place. So and then that all of those things together I would call a harness. So some of those things are built into the coding agents themselves, right? So like the way they do code editing, the way they do code search, they can improve all of those things. It's all part of the feed forward harness. But then there's like a bunch of things that we can control ourselves and like make it specific to our situation. And then as humans, we're kind of like the in the steers of this, right? So and that's what that OpenAI team was trying to do. They were trying to like continuously improve this harness around the agent. And of course for that we can also use AI. And so that's the new potential of these structural tests that I mentioned before and linting that previously we wouldn't have built custom tooling for that. It was too much work. But now actually for that experiment that I was doing, I did all of that with AI. I didn't write that myself. And that's like a lot lower risk factor. than some of the production software we write. And I also wonder if that's kind of like one of the new abstraction layers, actually. So will we maybe at some point in the future just have these like Let's say topologies right that cover 80% of what we do like we build data dashboards a lot that just collect data from from other APIs and show it or there's maybe a crowd business service or event processors or just like typical types of applications that we write and then we have a definition of how they're supposed to be structured and what the tech stack is and then maybe have instead of a service template we have a harness template for that that we can instantiate to then work on our code base And then we might not even care anymore if it's React or Vue, right? But one of our decision metrics might actually be, is there an existing harness for that? So I don't have to worry about that and I don't have to build that up initially. But all the examples I just gave or everything I just talked about with this harness were all about maintainability and internal code quality. I still have lots of questions about verifying functionality and of course that's That's ultimately the key, right? We still want our software to work. We don't only want safety critical systems to work, we want all software to work. So I think we need ideas how to harness different aspects of our applications. So I just talked, I would say, a lot about maintainability. Maybe there's also something like architecture, fitness, so how can we have a harness for operability, performance, and so on. And then there's, like I said, behavior. So right now, what most people do is they feed forward a description of the functionality, and then the feedback part is mostly like, oh, the test suite is green, but the test suite was generated by AI. And then you do some manual testing, and then... that's it right so that's the approach right now that i see some people say they do more review of the tests and all of that but i'm sometimes a little bit skeptical um so and that's not good enough right like we have to come up with better ways to do this so how does all of this change my trust level so improved models have definitely increased uh some of my trust level much more sophisticated context engineering so the progressive loading of context more tool integrations sub-agents uh all of those also offer a lot of new ways to increase my trust level. New food for thought for like how far can we push static analysis and stuff like that. But in terms of the question marks, I still see models do stupid things all the time. There was just this post on Reddit that went viral this week or last week, where the agent was saying, oh, yeah, you said no, but I thought you said no to me asking you for permission, so I just went ahead. Something like that, like a teenager kind of like, you know, yeah, you said no, but I thought you meant something else, right? So I still see that happen all the time. There's like this cognitive overload in the loop, right? So there's more and more anecdotes now of people like talking about burnout or just being overwhelmed either by like doing all of the review or like trying this like multiple sessions at the same time. And so... and also mostly when I hear this done dialed up to 11 with like a lot of AI autonomy, it's done by quite experienced engineers, right, who have the capacity for more load because they have so much experience. And yeah, then there's just this like pressure for speed from up above as well, right, so and then if you put pressure on people to be faster with AI, they will cut corners and become more sloppy, right. And interestingly, there was an article about Amazon reflecting recently on some outages that supposedly were related to AI-generated code. And one of their reactions to it is now to have more gateways where senior engineers have to review what's going into production, which seems kind of like, weren't we supposed to be faster going into production, and now we're just putting in more gateways, right? So yeah, that probably also isn't the... solution. So I've recently been asking myself more and more with this like speed, how much speed do we actually need, right? It's like what is the Goldilocks speed that is fast enough but not too fast, right? So just imagine Homer falling off that fast treadmill. I didn't want to have an actual gift of a human falling off the treadmill. So yeah, what are the risks of all of the speed but also how does the speed actually help the organization, right? Isn't there like aren't there other things that we should be looking into? So to wrap up, I talked a lot about reducing human supervision and increasing the ability to use AI as an automation tool, right? Like building a lot more for us because that is definitely the through line of everything that's happening and that's what a lot of people see in the future, right? But AI is a Swiss army knife with lots and lots of potential use cases. of course plenty of them are useful with supervision and they don't necessarily overload you but they're actually like a good extension of what you otherwise would have to be manually for and it would take a really long time right so um so many things have developed over the past year that also make you more effective make the use of ai more effective and a better developer experience when you're using it as an enhancement of yourself right And over the next 12 months, we're going to learn a bunch more. Again, there will be new good ideas, but we'll also discover more about all the worries and concerns that we have, right, about overload, about skills, atrophying and stuff like that. So these were just like some of the things that I was posing to you as questions to reflect on. And that's, I think, the least you have to do is reflect on these questions. And it's like a good kind of like how do you say, thought experiment, right? How ready would you be if you wanted to give AI more autonomy within your delivery, right? What's your automated safety net? What's your security stance? What's people's AI literacy at this point in time? And improving those things is always worth it. It's also worth it for the humans and AI can even help you improve that safety net already today if you want to be prepared in the future. That's it.

📩 Subscribe to the InfoQ Weekly newsletter!

No hype. No fluff. Just the signals senior engineers actually care about - from #AI, #DevOps, and #Java to #CloudComputing & #SoftwareArchitecture.

🗓️ Delivered every Tuesday, it's your quick round-up of innovator & early-adopter technologies.

Join 250,000+ developers who read it to stay ahead 👉 https://www.infoq.com/news/#infoq-nl
************************************************
As we move from simple autocompletion to autonomous AI agents, "vibe coding" isn't enough for enterprise-grade software. 

Birgitta Böckeler (Thoughtworks) explores the shift from prompt engineering to "Harness Engineering"—the practice of building deterministic safety nets around non-deterministic models. 
 
⏱️ Video Timestamps (For Navigation)
0:00 – The Evolution: From Autocomplete to Agents
2:15 – What is Context Engineering? (Rules, MCP, and Skills)
5:30 – Modularizing Context with Anthropic Skills
8:45 – The Cost Reality: $380/day per Developer?
11:20 – Subagents and Research Workflows
14:05 – The "Lethal Trifecta" of AI Security Risks
17:50 – Harness Engineering: Building Deterministic Safety Nets
21:10 – Maintaining Quality: Structural Tests as Feedback Loops
24:40 – The "Goldilocks Speed": How much velocity do we actually need?
28:15 – Final Thoughts: Scaling AI Autonomy Safely

🔗 Transcript available on InfoQ:   https://bit.ly/4we3odZ      
   
#SoftwareArchitecture #AIAgents #GenerativeAI #SoftwareEngineering #ClaudeCode #GitHubCopilot #ContextEngineering