Sidra Baig: Hello, hello everyone. My name is Sidra Baig and I’ll be your host for the next two sessions. And before we get started, I just wanted to take this opportunity to say that this is my fourth year being part of the Prepathon team here at Cloudways. And you guys just keep raising the bar higher and higher with your energy, questions, and enthusiasm. So we encourage you to keep it going, because we as a team love to see it. Now, we know that AI has made coding a lot easier, but there’s still a stark difference between production-ready code and working code. We’re going to be joined in this session by Tracy Lee, CEO of This Dot Labs, to help us understand what that really means for developers. Let’s give it up for Tracy.

Tracy Lee: Hi, thank you so much for having me. Hi everyone. Thanks for joining us. Love seeing the chat so active. Love to hear where everybody’s from. Feel free to post it on there, and also feel free to ask questions during the chat. There’s so many exciting things happening in life today. Should I try to share my screen and see if that works? Let’s see. Share screen. And I believe I got it. There we go. Can I get started?

Sidra Baig: Yeah, go right ahead.

Tracy Lee: Okay, awesome. Again, would love to hear where everybody is from, and love to hear thoughts. These days I think with AI we are all over the place. There’s like 10 million things happening. The industry changes so fast. I don’t know about you all, but the other day I was looking back at my text messages in January and March, and I realized how much my perception and mentality on AI has changed since then. So it’s just an exciting time to be alive. Hello, love seeing people from Ohio, from India, from Croatia. So, show of hands, or I guess in the chat, how many of you all feel like AI should generate 100% of code? Anybody? Yes? No? Got some yeses and nos in there. Let’s see. K, AI should not generate 100% of your code. Okay, got some nos. I don’t have any yeses though. Well, we’ll keep going.

So my answer is going to be no. Big nos from Olli. I love that we got one yes. Well, in my opinion, the answer is yes, because this is where the future is heading. But I’m sure that the folks of you who have said no are just asking yourself, well, how do you actually fully trust the results of AI? So we’re always asking ourselves that, how do you fully trust the results of AI? And that is why a lot of us aren’t adopting 100% of our code being generated by AI. But what if I told you that that’s actually not the right question to ask, because that question is actually addressing the symptom and not the root cause of the problem.

So what is the actual problem? The real question you should be asking yourself is, how much autonomy can my codebase actually safely support? If you figure this out, you’ll be set. But unfortunately, this actually isn’t just a technical challenge. It’s actually also a change in mindset. So that’s kind of what I want to talk about today. AI-generated code is becoming a normal part of engineering. The practical question we should all be asking ourselves, again, is just, how much responsibility can we safely give these systems today? So this talk is really about closing that gap through codebase readiness, trust boundaries, opinionated frameworks, to make sure you’re encoding the structure and verification that agents need to be successful.

But before we get into that, I wanted to say hello and tell you who I am and why I care so much about this topic. So my name is Tracy Lee. I’m the CEO of This Dot Labs. We help companies with AI enablement, application development, enterprise migrations, and AI-assisted engineering workflows. I’m also a Google Developer Expert for Angular. I’m a Microsoft MVP. I was previously on the RxJS core team and a GitHub Star. And I just love speaking at events, and I’m a community builder. So I spent more than a decade working in frameworks and large codebases, and that experience has really shaped how I think about structure and shared conventions and the roles they play when humans and agents work together in the same system. Over the next few minutes I just want to give you a practical model for increasing AI autonomy safely wherever your team is today.

So let’s start off with my mental model of AI adoption with developers. I don’t know how many of you are looking for jobs, but I sort of created this mental model mainly when I’m interviewing, actually, because I spend a lot of time sitting in on interviews. And the thing about it is, I can tell in the first five or 10 minutes where people are along in their AI journey. So I wanted to share that with you. Hopefully that helps you during your interview process, and hopefully that helps you understand how to think about where people are when it comes to AI adoption. These are the little boxes I put everybody in.

So Assist is the first one. For example, I might ask AI how to structure a component, and then I’m going to go ahead and implement it myself. AI is just advising me. It’s not actually doing the task for me. I’m pretty sure most of us are there now. Show of hands, or a yes in the chat, are you using AI to assist you right now? Thank you for the yeses. The second step is Generate. AI might create a small bit of code for me, such as a component or a test or maybe some documentation, but I’m still going to be reviewing every single line, understanding everything it creates. And in this step, AI has moved from suggesting to producing. So who else is using AI to generate code yourself, whether it be documentation, a test, a component, or anything like that? Good. I’m glad that everybody is using AI to generate a little bit of code. This is the interview process, by the way. So once we get to Orchestrate, if we’re doing that, then you guys are hired.

The third step is Delegate. So I’m going to give an agent a result that I want. I’m going to say, hey, I want something, and I’m going to give it some constraints. So I might tell an agent to build something for me or handle a portion of a migration. It’s going to generate the code, it’s going to update tests, it’s going to submit a PR, it’s going to make sure the build passes. I’m really delegating a piece of work to an agent. Anybody doing that? I’m telling you, if you are, you’re hired soon. Love to hear that. I’d love to hear the nos too. If you’re not doing that, love to hear that, and also understand why you aren’t doing it.

The fourth step is Operate. This step is, in my opinion, sort of where we’re actually starting to see the true value of AI. This is where you’ve created systems in which AI actually operates. So in this step you don’t have to initiate and supervise every task. Let’s say there’s a failing test, or a production error, or a support request, or a review comment that’s going to trigger a workflow, and in that workflow the agent is going to investigate something, it’s going to create a fix, it’s going to run the checks that we’ve defined, it’s going to open up a PR, and a human might still be there to approve a result. But the difference between Delegate, step number three, is that in Delegate you initiated the work, whereas in this step, number four, Operate, is where AI is responding itself. When you look at three and four, it doesn’t really seem like a step, because this isn’t really meant to be a ladder. It’s just more this important idea that each step transfers more ownership of the workflow from the human to the system. And you can be in different stages in your company, in your workflows, for different kinds of work. You might feel very good to delegate one workflow completely to AI while still using AI only as an assistant somewhere else.

Love that you’re using OpenClaw, Olli. I am not that brave yet, although I feel like I should be. So how many of y’all are doing the Operate function? Anybody going that step of Operate? The fifth step is Orchestrate. This is where multiple agents, tools, repositories, and services can actually coordinate in an entire workflow. So that means that you basically have a team of agents. One might be investigating a production error, one might be updating the front-end application, another might be updating the API, where the system is going to manage it all. So the difference between four and five is that Operate is going to complete one defined loop, whereas Orchestrate coordinates several loops across boundaries. Anybody there yet? Orchestrate. Crickets, I hear. Yeah, I feel like steps four and five are sort of where we are headed. So if you’re curious to see where things, in my opinion, are going, I feel like four and five are really where we need to get from a mindset perspective as an engineering ecosystem. And most people aren’t there yet.

The last step is the What’s Next. This step represents a possible future. This is something that we talk about a lot as engineers, I’m sure, at meetups, where systems can now coordinate complex work, they can actually learn from outcomes. Some call it self-healing. And help improve the workflow themselves. But again, the whole theme for this idea, in these different steps, is just that it’s our ability to allow AI to have an increase in ownership. And the problem is just, how do you actually get there? What is the biggest blocker for us to move closer towards autonomy? So this is where I want to name the central problem in AI adoption, is the trust gap.

When AI assists me or generates a piece of code, I can inspect the output, I can correct anything before it happens, I have a lot of control. But when I actually have a system that I’m allowing to plan and execute things, then what? So it makes sense, when a workflow has no boundaries, you feel like you have to inspect everything AI does. The system is not giving you any other reason to trust the result. But the question can’t be, do I trust AI, because that’s not really helpful. Trust has to be really specific. It’s, which decision am I delegating? What do I allow the agent to change? What must remain true at all times? What evidence am I going to require to be able to trust the result? When does a human actually need to step in?

But you really have to ask whether you can trust a system to carry out your intent across a change without requiring continuous attention from you. And that trust depends on more than just model capability or our delegation as developers. It very much depends on whether your codebase can actually support the responsibility that you’re giving the agent. And that’s really why I feel like codebase readiness is the biggest overlooked opportunity that you can execute on right now. Doesn’t matter where you are, doesn’t matter if you’re on steps one or five of the journey, but this is the biggest overlooked opportunity that you can fix to improve your AI journey today. And not doing this is really why most developers are stuck in the early stages of AI adoption. So you should be telling your managers that, and again, this should really make you feel empowered to be able to do something about what you’re doing today to prepare yourself for the future.

Now if we look at this chart, I just wanted to illustrate this. We talked about two different things now. We talked about autonomy, where are you on the autonomy scale, and we also talked about codebase readiness. So this chart looks at both things. The vertical axis here is autonomy, how much responsibility can I actually give AI. The horizontal axis is codebase readiness, how good are the guardrails you have actually put in place. So in the bottom left, both are low, which means people are performing the work manually, they’re compensating for gaps through experience and continuous attention. And this is where a lot of people still are. Whereas on the bottom right, you have really high codebase readiness, which means you have an awesome clean codebase, it’s nice to go into, there’s strong boundaries, there’s maybe eval setup or verification setup, but people are mostly performing the work still. And that investment to have a nice codebase, a codebase that’s ready, is definitely not an investment that’s wasted. The team is already benefiting, because everything you do to improve AI within your workflows is actually going to improve the human experience as well. So in this bottom-right corner, you’ve been able to create the option to delegate more safely later.

In the top left, autonomy is high but readiness is low. And this is where I feel like you hear most of the horror stories of, it’s just chaos at machine speed. The agent is making lots of changes, it has a lot of autonomy, but it’s missing a lot of things, there’s not a lot of checks, mistakes travel quickly. We’ve all heard horror stories here. In the top right, you’re in a very good state, where you have high codebase readiness and you have high autonomy as well. So in this situation, agents can actually be given meaningful responsibility, you can trust the system a little bit more, and the results work because there’s really good guardrails and eval setup for agents to be successful. The goal here is not to push every task towards maximum autonomy. The appropriate level depends on the risk and the consequence. The real point here is that you can’t increase autonomy without codebase readiness.

Readiness also means encoding decisions. So in a low-readiness codebase, many of those decisions that you have are very implicit. I’m sure you all are on teams where patterns live within people’s heads, or that one developer that you always have to ask, who knows just everything. We always love those teammates. But the problem is AI can’t use that if they don’t know. They can’t go into those developers’ heads. In a low-readiness codebase, maybe just a developer on the team is going to know which edge cases matter, which rules must never be broken. But while that works so well when an experienced person can continuously pay attention, an agent just can’t reliably follow all the knowledge that the system never expressed. It just has to guess. And this is why a lot of times when you’re trying to give agents more work, you’re like, wow, this is a mess, you didn’t get it exactly right. Well, the agent doesn’t know. The agent only knows what the system provides it.

So to get your codebases more ready for a state of AI, you really need to make sure you’re encoding your decisions within the environment. Project structure is going to tell the agent where things belong. Components and contracts are going to preserve earlier architectural decisions. Types, tests, permissions, automated checks, everything are going to be defining what’s true. And that doesn’t eliminate judgment, but it reduces the number of things the agent has to invent or infer during every change. And you can think of it as, humans have to do this well, right? A new team member who comes on your team is going to have to understand these things, get onboarded, etc. So the more you can decrease the amount of onboarding for an agent, the more you’re decreasing the amount of onboarding for a human as well.

And there’s a mindset change here as well when it comes to implementing AI. When we talk about creating guardrails, this can mean a lot of things, and it does not mean making every part of the work rigid or forcing AI to produce the same answer every time. You’re not trying to force AI to think the way you do, because it can’t always think the way you do. It’s non-deterministic. You can’t expect AI to solve the problem the way you would. For me, I don’t need the model to produce an identical solution every single time. I just need every acceptable solution to remain inside the same safety boundaries. But for me to be able to trust the output, and for a human to be able to trust the output, you have to still make sure that a human is deciding where the boundaries are, which guarantees actually matter. But my point here is, to be able to grow the trust that we have in AI, you just have to get more comfortable with having those guarantees in place around where AI will do the work to get more work done, that we can trust using AI.

So let me make this really practical. Let’s say I’m doing e-commerce, or maybe like a food delivery clone, and I want to add a delivery instructions field to a checkout flow. This red frame over here on the slide is the trust boundary. So inside of it, I give AI the room to make choices. It can decide implementation structure, it can write the validation copy, it can make small local refactors if that helps. But then the system is going to ensure that all the things that I need to remain true are true. The work stays within the checkout feature, the payment behavior stays unchanged, the application builds properly, the tests still pass. And anything outside that boundary goes to a human. So whether that’s a new dependency, a contract change, a payment edit, all of that is going to trigger a human review. And that is really the mindset shift for me. I don’t have to trust AI in the abstract, but I need to decide which boundary decision I’m willing to delegate and how the system will help me trust the result. The best way to do this is to start with reversible, low-risk work, and then as the workflow that you create repeatedly produces evidence that you trust, then you can start widening the boundary. Trust basically grows one bounded decision at a time.

So the question as well is, where do these boundaries come from? Six months ago or so, we were all talking about prompts. I don’t know if you guys ever shared your prompts or looked for people’s prompts, and there would be these huge prompts that people would share online to say, oh, here’s my prompt so that I can make sure AI is doing it right. But the trust boundaries that we create can’t only live inside a prompt. Teams can’t invent a new supervision system for every single task. These boundaries have to live within the codebase itself, in the architecture, the components, the contracts, the dependency boundaries, the permissions, the tests. And this is where opinionated frameworks become really relevant.

I don’t know if you guys have seen online, depending on the circles you’re in, for example PHP sounds like an outdated technology, okay, that’s the circles that I live in, but there are a lot of people who are saying, wow, PHP is actually more opinionated, it has more documentation, it has more structure in it. So you hear a lot of people saying, hey, I’m going to choose PHP because AI is going to do a better job at it. And you can have your own opinions on whether that’s true or not, you can have your own opinions on whether frameworks still matter or not. But in my opinion, this idea of creating boundaries that live within the codebase itself, this is where opinionated frameworks become really relevant, because they can make more of the environment explicit, consistent, inspectable, enforceable. And generally opinionated frameworks reduce decisions that every developer or agent has to reinvent. They provide known places to work, known ways to compose behavior, shared commands for proving the result. It’s awesome. I really love opinionated frameworks, but that’s because I came from Ember.js and AngularJS. Vue.js also does this very well, and of course other frameworks in React.

So the reason why I think this is so awesome, if you’re having project structure tell an agent where the feature belongs, if you have components provide known units of composition, if you have dependency boundaries that create explicit seams for capabilities, types and schemas for contracts, shared build and test workflows, all of these things are so awesome, because it reduces the amount that an agent needs to infer during every single change, and it gives the team really useful raw materials for building workflows that they can trust. And remember, even though I’m talking about 100% of your code being generated by AI, the team still remains responsible for choosing those right boundaries.

So I want to map the needs of an AI-ready codebase to the rails that an opinionated framework can provide. Agents need a standard project model. If they have that, they can really understand the workspace, which is awesome. If there are components and templates in a design system, it’s really awesome because they can compose existing parts instead of having to reinvent. Having explicit services and dependency boundaries is really awesome as well. And again, this is another example of making the environment more explicit but still keeping the team owning the architecture, the permissions, the product judgment.

So I opened up by asking a question, which was, should AI actually generate 100% of our code? And my answer is still yes. For the people that said no, because most people did say no in the chat, is anybody a little bit more bought in, maybe just a little bit? We’ve been a little quiet for a little bit, so I don’t know. But I hope you are. I hope you see a path, because I think again, as developers, we think a lot about the future and what it’s going to be like, and what happens when 100% of our code is generated by AI, or, hey, that’ll never happen because of this. But the way we move forward as an industry, as developers, and for personal growth as a developer, is just to put one foot in front of the other. Just take one small step, one small step, one small step.

And that’s kind of what I’m trying to show you guys today, is you don’t have to just YOLO it all. You just need to take one small incremental step. Start trusting it one small incremental step at a time. Adoption of AI takes a really long time for us as humans to process. It’s easy to make a lot of technological advancements, we see how fast new models are coming out every single day. But as humans, as developers, the faster we hop on the train of adoption and start walking down that line, the better off we’re going to be overall, because that’s the one thing that you can’t speed up. You can’t speed up human adoption. So the faster us as humans can go through that adoption phase, the better off we’re going to be.

So my answer is still yes. Yes, 100% of our code should be generated by AI. But you need to make sure that your codebase is ready. You need to make sure that your workflows can actually provide and prove the results that you want. AI needs room to choose where variation is helpful. Surrounding systems have to be able to keep the important rules fixed through structure, permissions, contracts, evals, tests, review boundaries. Opinionated frameworks really help make that surrounding system explicit. Humans should always remain responsible for defining the boundaries, choosing the evidence, deciding when a consequence requires actual judgment. But hopefully that moves you guys forward a little bit.

If you want to continue the conversation, you can find me online. Here’s my email. We are hiring. You can find me on Twitter and LinkedIn as well. You can find the website, thisdot.co, to see the work that we do. We do have a workshop coming up. If you go to workshops.thisdot.co and you want to be taught by some amazing AI-forward engineers who are boots on the ground, our CTO Elliot and one of our engineering leads Jonathan actually host this workshop, and I think the next one will be in about a month. So it’s a really great way to get started, and it’s a really great way to learn from the best, if you will. If you do want a discount code, feel free to email me as well. And then, we also have, for executives out there, a bunch of events. So if you go to events.thisdot.co, you’ll see a CXO Connect where it’s director level up. But if you want to have conversations across the board with executives who are doing AI, feel free to hit me up too, and I’m always happy to get you connected. Here’s my email, here’s my social media, and here’s the website. And feel free to ask questions in here, by the way. Thank you so much.

Sidra Baig: Well, thank you Tracy for that incredible session. I mean, I had a lot to learn from that as well. So good. That was really good. And I think we are right on time, so we might not be able to take any questions here, but feel free to stick around in the chat, answer any questions that you want, and people can also talk to you there. Thank you. Thank you so much. Thank you for being here.