Stop Coding, Start Directing: The Paradigm Shift for Every Software Engineer

The paradigm shift every software engineer has to make and why it's not the one you're afraid of. DISCLAIMER: This post was written entirely by me! I used AI for a little research, spelling, grammar, and comprehension checks. Entertain me for a moment, let’s appreciate where we are today by understanding where we’ve been… or at least, where I’ve been. I remember when I first learned to code. I was bad, like really bad. But I was so curious! It all started by writing some VBA in an MS Access Database to create an IT Inventory app in the late 90s. Then I learned JavaScript, ASP (without the .Net), then C#, .Net ( I still have my .Net for Dummies book, see below) , jQuery, Python, Java, Angular, ReactJS, and Python again (yeah, had to relearn that one for some reason), and I’m sure there are others in there I forgot about. Learning to write code was rewarding! There were those days I’d spend hours on a bug, only to realize I didn’t initialize the variable or forgot a semicolon. I learned .Net over a weekend thanks to the above book. I never became an artist of the craft, like some of my colleagues have (you know who you are: Josh, Kevin, and many others), but I knew how to build anything. I loved that ability: I could build anything. Pure joy! If you haven’t had the joy of learning to code, do your best to learn it, because you can’t prompt your way to being a Senior Engineer . As I progressed in my career, I became an architect and senior lead. I started off by leading a single engineering team, and now I support large programs and teams. All the while, I never let go of hands-on-code. I still love coding for work and my myriad of side projects. Then, a few years ago, this GenAI thing showed up. Put me in that group of: oh-no-there-goes-my-joy. Joy, yes, not my job. I love my job because I get to do what I love. I loved the dramatic rollercoasters: architecting a perfect solution, realizing it’s wrong, getting to write every line of code, chasing impossible bugs, panicking with deadlines, late nights chasing hot fixes, seeing users engage with my solution, and deploying on Fridays. Oh, I miss those days. And AI was going to take all that from me. Not liking to be left behind, I pushed into GenAI. I started seeing the great potential AI was bringing: from autocompleting the line I’m writing and creating full functions to understanding the context across multiple pages and building whole code files from nothing… I adapted, like many others, and embraced it. I knew this wasn’t going to be a fad: adapt early or get dragged along later. And who could forget that little phase of AI code: the slop. As agentic coding started to mature, it hit puberty: We all knew the potential it had, but it was awkward in its own skin. As I write this, I can’t remember the last line of code I wrote. I still remember code I wrote 5+ years ago, but my most recent line of code is probably 9+ months ago. I write everything via an agent today. If this scares you, if you can’t adapt, if you don’t want to adapt to using AI, you’re not alone! I have good friends and colleagues who are going in this kicking and screaming. Some are considering leaving software because it is their art, it is their creative outlet. That joy I expressed above, they experience it 10x more than I do. I get it. But AI isn’t leaving. Change is hard. Before you give up or give in, let’s talk about it. I love talking to our engineers about this. I could go on for hours. I’ve had countless conversations about this, even last week! Over the course of 2026, I’ve had the opportunity to share my thoughts below with my teammates at work across several sessions, in various countries, Zooms, and events. I have a 3-day hands-on workshop to help upskill engineers, a similar 2-hour session, and a 75-minute talk on agentic engineering excellence. I’ve helped upskill employees and vendors across my company in agentic engineering. So far, so good. This seems to resonate with most, and I hope it does with you. Every time I talk to an audience about upskilling in agentic engineering, I always start with: The Paradigm Shift This is it. If you can get your head through this shift, then learning how to use agents to write code efficiently and reliably will come quickly. You’re an engineer! You figure things out all the time. AI tools aren’t the challenge; it’s our mindset. If you fight this, then you stop growing. Key topics in the paradigm shift for a software engineer: Be curious You’re a director It’s not about how AI is the co pilot Be Curious Everything we discuss today could change tomorrow I start every talk about agentic engineering with this, because this is the reality we are in today. We have to be curious; it’s paramount. We can’t hold onto one way of using an agent to code and never explore what’s next. The industry is moving too fast, and you will be out of date in no time. This isn’t a scare tactic to exhaust every new feature you hear about. You can be a few months behind, as long as you’re moving forward. I’m not up on the absolute latest and greatest in agentic engineering. But I have engineers across my teams who are curious, who learn what’s new, and share it with everyone. This is challenging for some engineers. They know their code. They know their tasks. They want to get paid; this is their job. I respect that. Previously, our knowledge and expertise grew with the technology landscape. I learned about serverless when the clouds showed up. I learned what’s new in ReactJS when they released a new version every 2 years or so. Today, software is less about the languages and more about the tools we use to build software. That’s where people are struggling to keep up. Being curious is the best way to stay relevant. Be curious. Stay curious. You’re a Director I loved those days of busting out a dozen components on my front end and a few APIs to support them. I loved building apps with vanilla JavaScript, proving to myself I still know what I’m doing and not always relying on a library (love you, ReactJS). To this day, I still debate with engineers on the value of installing another npm library when we can build it ourselves. (That’s another post for another day.) The feeling of pride and ownership was a dopamine hit. That’s gone now. AI took this away from me! It’s not all rain clouds, in fact, it’s even sunnier now! Once I let go of what I needed to feel pride and ownership in the code itself, I was able to find pride and ownership in something greater. I can create whole apps, with good code, in days compared to what used to take me weeks. My dopamine hit is now the speed of building quality solutions; I still feel pride and ownership in what I’ve built. However, I now direct agents to do my bidding. maniacal laugh . Being a Director of agents is a huge paradigm shift. For some, it’s hard; for others, it comes naturally. I have found that more senior folks get it; they jump into it. They have 10+ years of experience, already know what they want to build, and can tell an agent to do it for them, as they’re working with the next agent. Early-career engineers, junior engineers, should expect to struggle here. Without all that experience, it’s hard to think 5 steps ahead and plan out what your agents need to do. That’s okay! Embrace it. You are now learning how to think like an architect, a solution designer, not just a ticket-taker. If you can’t think through a solution and equip multiple agents to complete it, ask those who can. Set up 1:1s with your senior engineer friends and teammates, talk through the design and approach, ask them how they would direct the agents, and then go do it. You will learn. This is a new muscle, build it. It’ll hurt sometimes, but you’ll get better. I promise. Directing agents is akin to being a dev lead. I’ve been a dev lead for the last dozen years or so. I had a good handle on the product my team was working on. I would work with my product team to create stories that included the bigger picture where necessary, and were technically detailed enough for our engineers to run and complete them. Then I’d do a code review, provide feedback, and iterate as needed. I do the same today, just with agents. Evolve into an agent director . Keep the big picture in mind and what you need to accomplish, then unleash your agents. It’s not about how… This one is commonly debated, even today: If AI writes bad code, it’s unmaintainable. How am I supposed to figure out how to fix it? There are two false assumptions in this argument: AI writes bad code; you will have to figure it out. AI writes bad code It can. I have seen pure functional slop come from AI. It works, but it’s terribly written. I saw this a lot, especially during its puberty phase. Myself and teammates have rejected PRs because of how bad the code was. This is a real concern, but it’s not a blocker. We can mitigate this through using directing agents correctly! There are oodles of engineers who are wildly successful in creating good, quality code, because they know what to look for and how to direct the agent. Some quick tips to get you started (another post on best practices is coming shortly): Provide it with your coding expectations and guidelines. Give it code samples, or a gold standard repo it can refer to. Use plan mode, iterate on how it’s going to implement before it writes code. Perform code reviews before you commit. Ask it to remember what and why you are correcting it. Perfection is the enemy of the good-enough. Loosen your own high standards and focus on real issues: poor loop structures, memory/cache management, security risks, etc. When I hear an engineer complain that an agent wrote bad code, I ask to see their prompt and plan so I can see what’s going on. They never share it for some reason. An agent writing poor code is generally an issue of using the agent poorly. You will have to figure it out. If you’re using AI to write it, why in the world wouldn’t you use AI to debug it? Cleaner code is easier to debug, even for AI, but the argument “how am I supposed to figure it out” is not the right point of view. Rather, ensure it writes good-enough code to start with, provide it context and direction, and it can figure out the bugs too. It’s not about how, it’s about what. With the resolution of that argument, the paradigm shift for software engineers is not focusing on how the code is written, but rather on what we’re building. Think about the solution first from the most important point of view: the users. I used to joke: everything I’ve ever written worked perfectly until I let users on it. We have to transition from “ not my code” to “not my code ”. Loosen up the mindset that the code has to be perfect, the code has to be excellent, and move to the mindset that it’s not about the code, it’s about the product, it’s about the solution you’re building, not the code you’re writing. “ Loosen”, don’t let go of. We’re not vibe coding quality prod code yet. Your expertise is still needed to know what good looks like. I have seen AI write code very differently from how I would write it. Generally, I think “dude, why did you do it this way… oh, I see, very cool.” Instead of focusing on my preferences in code (it’s good enough), I focus on how users will interact with this. Not my code: the users. How will they experience my product? Is what I’m building useful? Intuitive? Innovative? Shift into being a Product Engineer. This is not new! Being a product engineer used to be a differentiator. I have had a good head on my shoulders to understand the product I was building, even years and years ago, when I was just taking tickets off the backlog. This afforded me great opportunities in my career. Now, this has to become a commodity. Your and my value isn’t in writing code, it’s in directing agents to build the product. We have to understand the product to do this efficiently. Arguably, this is why product folks love vibe coding. They don’t care about the code; they care about the product. It’s your and my jobs to bring proper software practices to bear to ensure our products are stable, cost-effective, performant, and safe. I highly suggest reading “Thinking in Systems” by Donella H. Meadows. It’s not a software book; it’s a systems thinking book. I’ve read it with my teams over the past few years, and I’ll read it again as my teams change. It’s very helpful in understanding systems and products beyond just code. AI is the co pilot. Microsoft jumped in and took over the Copilot name, and in my opinion, they’re now behind the times. Other than being impossible to talk to anyone about Copilot, because we never know which Copilot we’re referring to, the idea of AI being a copilot is outdated. On the business side: PowerPoints, reports, documentation, etc., there might be an argument to use AI as a copilot, as it assists you in delivering assets that could change the course of your business. Please, keep humans in that. It’s different in engineering. For engineers, it’s not about letting AI be your copilot; we want it to be the pilot. We are traffic control; we are directing agents into building a product. The paradigm shift is to stop looking at AI as a helper: unit tests, code reviews, and handle only the mundane tasks, like models or forms. Instead, start with AI. Take your task, and immediately think: how do I get AI from that airport to this airport? It’s going to pilot and get there, I need to run through the take-off checklist, ensure it knows the route, direct it around storms, above the turbulence, avoid no-fly zones, and the like. Ok, enough about airplanes. I have sat in sprint planning sessions for some of my teams and challenged them when they point a story 5 or 8 points. I ask why so high? They explain the work they need to do. I follow up with a: but how will AI do it for you? You will find that when you pivot from “what am I going to build” to “how will I get agents to build it”, your perspective changes, and you immediately see gaps and problem areas. You need to collect all the necessary information and details for your agent up front: API contracts, design patterns, requirements, etc. You think about dependencies earlier than when you face it writing the code yourself. This planning is crucial for successful agentic coding. This is a new muscle for many, but it makes you a better engineer. When we start with AI-first thinking, we immediately go into the director’s seat, have to understand more than just the immediate code in front of us, and are forced to think about the solution holistically. No, you’re not going to become lazy Another favorite of mine. In my conversations with engineers, this always creeps up, in some way: I don’t want to get lazy; I don’t want to lose my skills; if the code doesn’t matter, then what am I doing? As I hope you’ve seen above, you’re not going to get lazy. It’s like moving from being a runner to a bodybuilder. You’re going to find new muscles you didn’t know you had! Consider the teres major, the ‘little lat’ that works with your lats to widen your back, almost like wings! Most runners don’t have these as accentuated as a bodybuilder does. Far from lazy, you’re going to stretch into a new space, uncomfortable at first, and you may not see growth for a while. It takes 3 to 5 years for someone to get all bubbly with muscles. Our muscles grow after we work them. This is the same thing. You need to start, engage, and learn. You’re going to hurt, be sore, but keep going, keep pushing yourself. AI doesn’t necessarily make your job easier. Sure, you’re writing less code, but you’re doing more. Check out AI Didn’t Make Software Engineering Easier. It Made the Hard Parts Harder for more on how NOT lazy you’ll be. Your Move Be curious, you don’t have to be current with the tech Day-0, but keep exploring and learning. Lean on your teammates, social networks, blogs, etc. I read TLDR , TLDR AI , and TLDR Dev daily to keep up to date. It’s a lot, and I have a bad memory, but it’s helpful to get the highlights of what’s going on in the industry. I jump on 1 or 2 items a week to check out and explore further. I share with my teammates what I’m reading, and usually find someone who has gone deeper. We learn together. We are curious together. Directing agents is not an overnight achievement. It will take time to learn and master. If you are early in your engineering career, be curious with your senior teammates. Ask them questions, ask them to mentor you. If you are a senior with juniors on the team, reach out, ask them how they’re doing with agents, encourage them to try new things, and show them how you do it. Adopt the product mindset. Meet with your product owners and managers. Ask to sit on calls where they meet with users, or ask for recordings. Hear how the users talk about the product, see how what they expect is different than what was built. Think AI first. Well? Well? What do you think? I hope this has encouraged some to embrace AI more, and those who already have, see ways to help their teammates flourish. If you’re not sold, why not? Seriously, reach out, I’d love to chat over messaging , or a coffee/beer/bourbon in Boston, and hear your story and talk through it with you. I love to learn what I’m missing, and who knows, maybe we can grow more together. In my next post, we’ll discuss some best practices to enable us to produce quality code with our agents that is safe, secure, and performant. Make sure to follow! Side note: It’s not about going faster To me, it’s not about going faster. When I speak with the business, we discuss speed to market, or rather, more importantly, speed to value. Without the business, there’s no product, no engineers. We have to satisfy those who sign our checks. When I speak with engineers (don’t tell the business folks this), it’s not about speed for speed's sake. Using AI is about using a new tool that makes you a formidable force, a highly efficient engineer who can deliver quality solutions, who just so happens to be faster.