Watching the Agentic AI Revolution in Development
There's something deeply fascinating about hearing the stories of tech in the 70s and 80s. It was the wild west. There were no rules, no limitations, no established playbooks. Nobody was doing it for the stock options or the LinkedIn flex. People were just doing what they loved – building things that didn't exist yet, inventing the foundations of the digital world we now take for granted.
Think about what came out of that era.
DNS servers- quite literally the internet's address book, the system that takes a website name you type and tells your browser exactly which IP address to find it at. Without DNS, you'd be memorizing numbers like `192.168.1.50` instead of typing `google.com`. It was invented in 1983 by Paul Mockapetris and it still runs the entire internet today.
Then there's RADIUS- the protocol that lets internet service providers securely authenticate, authorize, and account for dial-up remote user connections. If you ever heard that screeching handshake sound of a modem connecting in the 90s, RADIUS was the invisible bouncer checking your credentials behind the scenes.
Or computer terminals- in the early days, they were the only way for more than one person to interact with a single computer. You'd think they'd be obsolete by now, but developers still live in them. Every time you see a developer with that black screen and green text, that's a terminal, and it's still one of the most powerful tools in the industry.
The leaps in tech from that era were so great and so world-changing that it's hard to even put into perspective. They weren't just improving things. They were creating the things that everything else would be built on top of. Now that technology is everywhere, even our cars because that touch screen that sits on the dashboard of every new vehicle, that's a computer running the graphical version of a terminal!
And the innovation didn't stop. The same spirit of "build the thing that doesn't exist yet" carried forward through the decades. Think about the advancements in code testing/software testing alone:
- Continuous Integration – the practice of automatically merging and testing code changes multiple times per day so you catch breaks before they reach production.
- Jenkins – the open-source automation server that became the backbone of CI pipelines for an entire generation of developers, ugly UI and all.
- Selenium – the browser automation framework that lets you write scripts to click through websites like a real user, revolutionizing end-to-end testing (and also causing decades of developer frustration with flaky selectors).
- GitLab CI – CI/CD pipelines built directly into your Git repository so every push triggers builds and tests without ever leaving your code hosting platform.
- Playwright – Microsoft's modern cross-browser automation framework that made browser testing fast, reliable, and almost pleasant, with auto-waiting and network interception that Selenium only dreamed of.
Each of these tools was a leap forward, a way to catch bugs earlier, ship faster, and make better software.
I missed seeing all of those inventions take place. I wasn't there when someone first compiled a browser test in Selenium and thought this changes everything. I wasn't in the room when the first CI pipeline turned red, flagging something wrong in the code, and saved a development team from pushing a "bug" to production. But I did get to witness something I believe is just as significant.
I got to see the leap into Agentic AI engineering.
Not Vibe Coding – This Is Something Different
Before I go further, let me clear something up. This is not "vibe coding." Vibe coding is the term that's been floating around for developers who sit with an AI chatbot, describe what they want in loose, casual terms – "make me a landing page with a hero section and some testimonials" – and let the AI figure it out while they sort of vibe their way through the process. They don't understand the output in terms of programming, they just think as long as it looks right, it's good to go. Most of the people doing this can't even read or understand a single line of code. While it's fun for prototyping or neat for beginners doing simple things, it's not engineering. There's no rigor, testing, validating or methodology. It's just vibes.
Agentic AI engineering is something categorically different. It's the practice of directing an autonomous AI agent with specific rules, constraints, and guidelines to navigate a real codebase, find relevant code, reason about the problem, and produce tested, functional code changes. The developer isn't vibing. They're engineering –they're just doing it with a collaborator that happens to be an AI that can read the entire codebase, connect to external platforms, reason through problems, self-correct, and iterate at a speed no human can match.
And I didn't just read about it. I got to watch it happen, sitting next to a coworker who was living it every single day.
The Transformation: From Breakpoints to Agent Prompts
When this co-worker first started reaching out to collaborate (he was a developer at the company) I watched him work the way developers had worked for years. He'd be in Visual Studio, sifting through code trying to understand what another developer had written before he could fix it, setting breakpoints to trace through execution to find the exact spot where the issue was, creating branches to work on sections of the code separately from the man codebase, and manually rewriting lines to address the "bug". It was meticulous, painstaking work. Most of the time, he'd read a function, trace the data flow, set a breakpoint at the line he suspected, run the debugger, step through line by line, inspect variables, and slowly – slowly – narrow down the issue before being ready to solve it. It often took half a day for one "simple" bug that a customer reported.
It was the craft though. It was how it was done. And it took time.
Then agentic AI came out and he started using an agent. And I watched the transformation happen in real time.
At first, it was small. He'd prompt his agent with specific rules and guidelines: "Read the bug pulse on Monday for X. Find the part of the code related to this reported bug. Here are the files involved and the tools you have. Look for the function that handles the API response parsing." The agent would search, find, and suggest. He'd review, correct the agent, prompt again, get another response, repeat this process as often as needed and then apply the fix. At first, there was a lot of back and forth with the agent to get it to do the right thing, but it still took way less time than him trying to trace down the "bug" himself through the code.
But things started to run on all cylinders. As he refined his guidelines and as the agent went through this process over and over again, it learned. It got noticeably better. The suggestions became more accurate. The code changes became more aligned with the codebase's conventions. The need for prompting shrank. Week by week, I watched the human-to-agent ratio shift. Less direction, more results. Same person, same codebase, but the workflow was fundamentally transforming.
Sometimes he'd switch modules. He'd try a different agent model that could keep more context in memory – especially the source code itself. And when I say "keep more context," I mean the ability to hold the entire codebase in working memory while reasoning about a single bug. No human can do that. The best developer might hold a few files in their head. The agent held the whole project, the whole software.
Agent Guides
Then he did something that seemed wildly futuristic. With a single prompt, he'd have his agent reference a guidelines PDF – the very same guidelines document that the agent itself had written based on his original prompts in the first place. The agent had essentially written its own instruction manual from his guidance, and now he was telling it to go read it. This lessened the "wrestling with AI" that he often had to do before.
That then set the agent off on an autonomous run that looked like this:
1. Automatically connect to Monday.com- the project management platform where our bug reports and feature requests live as pulses on a board.
2. Find the right pulse- the specific bug or task card, out of hundreds, that was assigned to him.
3. Read through the bug report and all its comments- parsing the issue description, any reproduction steps, screenshots, tester notes, and developer discussion threads.
4. Find the code that related to that bug- searching through the entire codebase to identify the specific files, functions, and lines that were relevant to the reported issue.
- Analyze the code for obvious mistakes or issues – reasoning about the logic, checking for edge cases, identifying potential problems.
6. Suggest code change-generating a concrete code fix or new implementation, ready for review.
All of that, from one prompt. And I'd be watching the agent's log in OpenCode scroll across the screen like magic (to me that seriously is what it is). It would reason through steps, automatically retry when something didn't work, self-correct, and try again with a different approach. It needed very little from him to do what he needed it to do. The agent wasn't just a tool. It was a collaborator that could think, stumble, recover, and deliver.
Agent Writes, Build Checks, We Test
Once the agent suggested a code change, the workflow looked like this:
My coworker would examine the code snippet, patch, or Git diff the agent provided. He'd read through it carefully -- because even with an AI, you don't just blindly accept code changes into your codebase. He'd understand exactly what was changing and why.
Then he'd have the agent run a build on his computer to check the code changes to the branch of code that it was working on for any errors. If the build spat out syntax errors or compilation failures, the agent would catch them, understand what went wrong, and often fix them before my coworker even had to say anything. Once the build completed and proved there were no syntax errors, he'd relaunch his development server.
And then came my favorite part. He and I would test the changes in the UI in his development environment on his computer. Together. In real time. Do the code changes actually fix the bug? Does the feature work the way it's supposed to? Does anything else break? Did the agent miss anything?
Many times, he'd have me do the testing solo. I'd click through the flow, and if – more like when – I found something that broke, I'd report it back to him. He'd feed my feedback to his agent and say, essentially, "try again." The agent would take the new information, correct its approach, rewrite the code, rebuild, and hand it back to his development environment. Within minutes, sometimes less, I'd be testing the new code changes in the UI again.
The turnaround time to refix code was super short. We're talking about a loop that used to take hours – find the issue, understand the code, write a fix, compile, deploy to a dev server, test, find another issue, repeat – compressed into minutes. We did this in huddles for high-priority bugs affecting our user base, and the speed at which we could iterate was something neither of us had ever experienced before.
How Agents Changed Everything
Again, let me be clear about why this was so different from the old way. Before the agent, if my coworker needed to fix a bug, here's what he'd do:
- Search through the codebase manually, trying to understand what another developer wrote, reading through functions and files, looking for the relevant logic.
- Set breakpoints, run the debugger, step through execution line by line to trace the problem.
- Manually rewrite code, trying to preserve the existing logic while adding the fix.
- Rebuild, relaunch, test, and repeat.
The agent sped up every single one of those pieces. The agent could search through and understand the total codebase in minutes – not days, not hours, minutes. It could connect to platforms like Monday.com to gain context on past bug reports far faster than a person could search and read through them. It could keep context better and remember things better than any human can when trying to update and fix line after line of interconnected code. I didn't get tired. It didn't lose the thread. It didn't forget what file X did when it was editing file Y and all the dependencies within the software.
And the most remarkable part: as the agent understood more, did more, and learned more, it got sharper and more efficient. It was like having a super smart, super fast assistant that never slept, never got frustrated, and got better at its job every single day.
Watching Technology From the Future
Here's what I keep coming back to. Watching developers write code has always fascinated me. There's something mesmerizing about watching someone who knows their craft take a blank screen on a webpage and turn it into something functional, useful, alive. I've always loved that.
But watching technology write its own code? Watching an agent reason, self-correct, search a codebase, connect to an external platform, analyze a bug, write a fix, build it, fail, try again, succeed, and hand it back – all while I'm sitting there watching the log scroll like something out of a science fiction movie?
That's like watching technology from the future somehow be on your screen, right here, right now.
It's amazing how far technology has brought us, and how much it has helped us along the way. Every era had its breakthrough. The 70s had DNS, RADIUS, and the foundations. The 90s had the web. The 2010s had CI and DevOps. And now, here we are, and the breakthrough is agents that can engineer.
Will I wish I could have been there for the other major breakthroughs? Of course. I would have loved to see the room when someone first explained the concept of DNS. I would have loved to see the first CI pipeline turn red and save the day. I would have loved to watch the first Selenium script click through a website and realize that testing would never be the same.
But I'm so thankful – deeply, genuinely thankful – that I got to see this one. Agentic AI engineering. The thing that's happening right now, in my time, in my workflow, in my day-to-day.
I know this technique of coding is still very new. It's not something everyone can just jump onboard and start using right away. There's a learning curve. There are guidelines to write. There are models to understand. There's a whole new way of thinking about development that hasn't been standardized yet.
But it's going to be amazing to watch how this changes the tech and development world as it gains more popularity. Because if watching one developer transform his workflow with an agent was this jaw-dropping, imagine what happens when an entire industry does it.
The Story Continues
And here's the latest chapter. My now-no-longer-coworker – has his agent connected to Playwright. He's got it doing automatic QA testing on the code that he writes, validating it even more before it ever gets passed off to a traditional QA tester.
And because that's the thing, the beautiful, limitless thing about agents: you can connect almost anything to them. You can have them do all sorts of tasks for you. The only limit is what platforms and tools allow through their APIs and integrations. Playwright, Jira, Monday.com, your codebase, your build scripts, your deployment pipeline – connect them all to an agent and it becomes a one-person engineering team that never sleeps.
There is so much more that could be said about this. So many more stories, so many more breakthroughs, so many more "wait, it can do that?!" moments that happened in those huddles. The age of agentic AI and seeing what all it can do, it can leave you speechless when you see it for the first time. And honestly? Even the second time. And the third. And every time after that.
Now to continue my learning and have the opportunity to use an agent for tasks and future learning in the tech world, I created DuckBuddy. My own company concept where I can interact with my agent and learn more about what agents can do for all types of roles at companies. Read this next article to learn more!