# AI changed my role before it changed my software > Source: > Published: 2026-10-08 09:00:00+00:00 My first attempt at [vibe coding](https://www.infoworld.com/article/4078884/what-is-vibe-coding-ai-writes-the-code-so-developers-can-think-big.html) face-planted. I shook my head and stared at the screen. Well, this is obviously not for me. I became convinced the problem was the AI. I had uploaded the working Excel spreadsheet that already contained the business logic, workflows, and calculations I wanted the AI to replicate. How hard could this possibly be for “[artificial intelligence](https://www.infoworld.com/article/4061121/a-brief-history-of-ai.html)” to translate into an application? The result was a mess. I closed the browser and didn’t come back to it for almost a month. Then one night, almost reluctantly, I decided to try again. Twenty minutes later, I wasn’t frustrated anymore. I was unsettled. On this second attempt, I changed only one thing: instead of asking the AI to infer my intent, I explained the outcome I wanted. I described the user journey, assessment flow, registration process, scoring logic, and expected behavior. Somewhere around the fifth or sixth prompt I realized I had stopped thinking like a programmer and started thinking like a product leader with enough technical depth to direct the machine. An hour later, I had the foundations of a production-ready application: a polished React interface, a SQL back end, user registration, and working assessment workflows. The remarkable part wasn’t the speed. It was the dawning realization that software development itself had quietly changed and I hadn’t noticed until I was standing in the middle of it. Working as an [agile coach](https://www.infoworld.com/article/2259475/what-is-agile-methodology-modern-software-development-explained.html), team agility assessments, usually spreadsheet-based, were simply part of the job. You administered them, reviewed the findings, and guided teams toward improvement. Easy, right? Nope. In practice, I came to distrust these massive maturity assessments. They promised precision but often delivered exhaustion. My latest working assessment tool had over 120 questions. One hundred and twenty questions. There had to be a better way. I found myself reaching for a medical analogy. Most teams don’t need an advanced MRI diagnostic. Most of the time they just need an X-ray to find what’s broken. A comprehensive MRI may have its place, but it’s rarely the best place to start. So I decided to deconstruct the spreadsheet-based assessment process and turn heavyweight assessments into a lightweight application, a Team Agility Quick Scan a team could take in 10 minutes with just 12 questions. The concept worked and I had a nice spreadsheet tool. Soon I realized I didn’t want to spend my time distributing spreadsheets or asking organizations to manage yet another Excel file. I wanted teams to experience the assessment, not inherit another document to maintain. So I thought, [vibe coding](https://www.infoworld.com/article/4058076/vibe-coding-and-the-future-of-software-development.html)? I had a use case. After some research, I settled on the Replit platform. When my first attempt failed, I blamed the AI. Walked away. My failure happened because I expected AI to behave like a programmer. When I came back a month later, I changed how I treated the AI, less as a contractor and more as a collaborator. Instead of showing it what I wanted, I described the outcome I was trying to achieve. I stopped specifying implementation and started specifying intent. I explained the user journey, the assessment flow, the registration process, and how scores should be aggregated and displayed. I stopped thinking in terms of code and started thinking in terms of behavior. After a few rounds of editing and wordsmithing the first prompt, I submitted it. Three minutes later, the AI responded not with a few snippets of code, but with what amounted to a design proposal. It outlined the application, described how it intended to build it, and then quietly announced that the first version was ready to test. “Go ahead,” the AI suggested. “Create your first assessment.” I clicked the Register Account button. The registration flow worked. The interface looked polished. I clicked the Create Assessment button. It worked. I could create a quick scan assessment, navigate through the application, and begin exercising functionality that, only moments before, had existed solely in my imagination. The questions snapped into view. Easy to read, easy to answer. Then I clicked the View Results button. My jaw hit the floor. It wasn’t perfect. But it was far better than I expected. The important thing was that the foundation existed. From that point on, our interaction became less like programming. It was collaboration. After a while, it felt less like programming and more like directing. I suggested changes; the AI implemented them. I refined the user experience; it generated another iteration. I pointed out missing functionality; it filled in the gaps. I made color and design graphic suggestions; it agreed with some, improved on others. Each conversational exchange nudged the product closer to what I had envisioned. Watching the application evolve in real time was exhilarating. Each prompt became another design review. Each iteration became another product conversation. AI accelerated implementation, but it depended on a human to supply context, priorities, and judgment. Now I understand why so many people are captivated by vibe coding. It compressed the distance between an idea and a working prototype in a way that felt almost magical. A prototype like this would have taken weeks for a small team or a solo developer to produce, followed by more work to get to a minimum viable product (MVP). I know because years earlier I funded a software idea, spent months working with an excellent offshore development team, and ultimately watched the finished product disappear into the dustbin of history. I promised myself I would never repeat that experience. This time, I had something approaching a working MVP in hours and for pocket change. I had no idea that the easy part was already behind me. Class, as it turned out, was now in session. The first version of the application appeared quickly, almost without effort. Getting it ready for the real users was a different story. The actual coding sessions were remarkably short. A focused burst of prompts, a review, a few refinements, and the application would leap forward by another meaningful increment. The velocity was unlike anything I had experienced. I estimate I spent about 40 hours over three calendar months getting the application ready to put in front of early users. Nothing compared to the time and treasure spent earlier. But that speed hid an important truth. The AI could generate features with astonishing efficiency, but it couldn’t eliminate the countless design decisions that surround a production application. As the application matured, I discovered that AI could generate code with astonishing speed, but it couldn’t make architectural decisions for me. As the product manager, I wanted to know about user activity in real-time with a simple email notification. I asked the AI to add that. Whoa, down the rabbit hole Alice went. Soon I discovered email notifications required selecting and integrating a dedicated delivery platform. I had to subscribe to a service, then integrate it with the application. I learned about this side of software engineering I had not known about before. Soon, I had emails incoming when a new user enrolled, completed an assessment, or deleted their account. Next, I did not like the native user authentication process that came with the AI. So, I asked, let’s do something different. Again, I discovered that independent authentication required introducing a separate identity provider. Again, another third party to integrate into the application. Again, thankfully the free tier had all the performance specs I needed, and no new costs were introduced. Decisions about where AI belonged inside the product required restraint as much as ambition. None of those questions were solved by code generation. They were architectural choices affecting security, operations, maintainability, and user trust. The more time I spent on the application, the more I realized that AI collaboration doesn’t erase software engineering. It relocates it. It accelerates software construction while exposing product design, integration strategy, operational decisions, and long-term stewardship as the real work. The code came surprisingly easily. Everything around the code did not. That became the central lesson. AI can generate code with astonishing efficiency. It cannot decide where system boundaries belong, which compromises are acceptable, what users truly need, or when a technically correct answer is strategically wrong. Those remain human responsibilities. Technology is astonishing. It can compress the distance between an idea and a working product from months to days or even hours. What once required a team of specialists can now begin with a conversation and a well-crafted prompt. That should excite every knowledge worker. But there is an important distinction between building software fast and building the right software. Getting started with AI collaboration is remarkably easy. Producing something that is secure, intuitive, maintainable, and genuinely useful still requires judgment. It requires making architectural trade-offs, understanding users, questioning assumptions, and recognizing when the AI has confidently gone in the wrong direction. In the end, my biggest lesson had nothing to do with software. The hard part didn’t disappear. It moved. AI made coding easier, but it made judgment more valuable. The future of work isn’t about humans competing with AI. It’s about developing people who can frame better problems, recognize better answers, and lead increasingly capable machines. Enterprise leaders should pay attention because this pattern extends beyond software. Whenever AI compresses execution, judgment becomes the scarce resource. Organizations that mistake faster implementation for better decisions will simply produce poor outcomes more quickly. Organizations that invest in product thinking, architecture, governance, and human discernment will compound AI’s strengths instead of amplifying its weaknesses. *—* *New Tech Forum* **provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all** **inquiries to** *doug_dineley@foundryco.com***.**