What Building Real Software Taught Me

About Requirements, AI, the Final Mile, and Where Humans Still Matter

I am not a software developer. I have spent most of my career in military logistics, supply chain management, operations, and leadership, where the problems usually involve people, processes, resources, and figuring out why something that looks perfectly reasonable on paper does not work quite as well when an actual person tries to use it. I know how to dissect a process, challenge an assumption, ask uncomfortable questions, and determine whether something solves the problem it was intended to solve.

That changed when I was given the opportunity to use the Alchemy SDLC™ to help take a real application from an operational idea through requirements, development, testing, the Final Mile, and deployment. I have since gone through the process again, this time against requirements I had a much larger hand in authoring. I expected the code to be the difficult part because that was the part I knew the least about. Instead, producing code was remarkably fast. Figuring out exactly what the software should do, explaining it clearly enough to build, and proving the resulting application worked in the real world were considerably harder.

For years, organizations have treated development as the highly technical center of software delivery, while requirements, process mapping, testing, documentation, and user acceptance surround the “real work” of writing the application. AI-assisted development challenges that assumption because it compresses the activity we historically treated as the center of the process. When code can be produced remarkably quickly, the bottleneck moves. The question is no longer simply, How quickly can we build this? It becomes, How certain are we that we know what we are supposed to build? I watched that shift happen.

The Problem Before the Software

Brooks (2026c), in Mission Readiness Begins with Requirements Readiness, argues that software readiness begins well before development. Experience gave that argument considerably more weight for me. A requirement cannot merely make sense to the person who wrote it; it has to survive interpretation by developers, testers, users, and now automated development agents without quietly changing meaning along the way.

This creates an interesting problem with AI. An experienced person can hear an unclear statement and ask what it actually means. An AI development agent can identify ambiguity too, but it can also make a reasonable interpretation and continue working. That sounds efficient until the interpretation is wrong. Worse, the output may look completely legitimate: the button works, the page loads, the database accepts the information, and everybody gets to admire a beautifully functioning version of something nobody actually wanted.

Faster development does not make requirements less important; it makes mistakes easier to multiply. Brooks (2026b), in From Prompt to Production: Why AI Software Delivery Needs a Full SDLC, distinguishes between generating software and delivering production software. After watching development activities execute against written specifications, I understood why. A poorly considered business rule can become a perfectly functioning feature. An assumption can become a database field. An ambiguous sentence can become a workflow. AI did not make those decisions; it simply made our decisions executable.

The experience also changed how I viewed my own role. I did not suddenly become a programmer. What changed was that programming was no longer the barrier preventing me from participating directly in software delivery. I could ask why a workflow existed, what should happen when something failed, what information a user needed to make a decision, and whether the application reflected the process we intended. The technology compressed the part where I had the least experience and exposed the parts where I had considerably more.

When the Application Appeared

There is a strange moment when weeks of conversations, requirements, user stories, acceptance criteria, diagrams, and decisions suddenly become something you can open in a browser. The buttons work. Information moves. Something that existed only as words has become an application, and for someone who did not come from software development, that is remarkable to watch. It is also easy to draw the wrong conclusion: the application exists, so the hard part must be over. What we actually had was evidence that our requirements were detailed enough to create functioning software, not evidence that the software was ready for an actual user or operating environment.

I learned that distinction during the Final Mile. In one case, the application successfully deployed to Google Cloud Run and the deployment was healthy, yet every attempt to access it returned a 403 Forbidden error. The application was there, apparently ready to do what we designed it to do, but nobody could reach it because the request was rejected before it ever reached the application. The problem was not necessarily the application itself; it was the environment surrounding it—access policies, configuration, credentials, and infrastructure. Docker, Windows Subsystem for Linux, and environment configuration provided their own lessons. None of these issues made for an exciting AI demonstration, but they stood between a demonstration and something a customer could actually use.

Interestingly, the further we moved into the Final Mile, the more familiar the problems became. I did not know every command or syntax an experienced developer knew, but I understood troubleshooting: What changed? What was supposed to happen? What actually happened? Where did the process stop? What evidence do we have? AI could explain errors and help isolate failures, while professional developers handled issues requiring deeper expertise. My responsibility was to understand the problem and keep asking whether each fix moved us closer to the outcome we originally defined.

Stop Testing the Software. Start Testing the Job.

Testing created another shift in my thinking. Initially, I viewed it as proving that individual requirements worked. That was necessary and aligned with the traceability between requirements, acceptance criteria, automated testing, and release evidence described by Brooks (2026a), but passing individual requirements does not necessarily mean the application works. Real users do not experience software one requirement at a time. They click twice because nothing seemed to happen, save again, upload the wrong file, change a selection, go backward, refresh the page, or leave halfway through something and return later expecting the application to remember exactly where they were.

That led to what some developers call the “Obsessive-Compulsive Tour.” I deliberately repeated submissions, saves, uploads, selections, and other actions looking for duplication and non-idempotent behavior. Put more plainly, I started doing the annoying things users inevitably do to see whether I could break something. If I submitted twice, did I create two records? If I uploaded the same evidence again, what happened? If I repeatedly saved something, did the system remain in the intended state?

Eventually, we moved beyond features and began walking the application as the people who would actually use it. Instead of touring screens, I had to follow the work. Each role entered with different information, responsibilities, and expectations. One user needed information to make an operational decision, another needed to complete an action and provide evidence, and another needed to determine whether the record told a defensible story of what happened, who did it, when it occurred, and what evidence supported the decision. Organizations do not need software because they want more screens or workflows; they need a job accomplished. Someone still has to sit in front of the finished product and ask: Can I actually do my job with this?

The Person Who Says Yes

There is a point where software delivery has to move beyond whether the system technically works. Tests may have passed, defects may have been corrected, and evidence may show that the application does what the requirements say it should do. Eventually, somebody has to answer a different question: Is this what we actually needed? User acceptance testing changed the way I viewed that responsibility. I had to consider whether the experience made sense to the person doing the job, whether the right information was available at the right time, and whether I would be comfortable putting my name behind the answer.

AI can contribute to nearly every activity surrounding that decision. It can analyze requirements, generate code, build tests, identify inconsistencies, document results, and help diagnose failures. What it cannot do is assume organizational accountability for accepting the outcome. Somewhere between an operational need and a production application, a person still has to decide that the evidence is sufficient and the system is fit for its intended purpose. That is not a control I believe we should be trying to engineer away.

This became even clearer during my second build because the requirements were no longer somebody else’s work. I had helped author them. On the first application, ambiguity could lead me upstream to understand what a requirement was supposed to mean. On the second, if something was unclear, I had to confront the possibility that I was the one who had failed to make it clear. There was nobody upstream to blame, which has a remarkable way of improving your appreciation for precise requirements.

What Two Builds Changed for Me

Before doing this myself, I probably would have described AI-assisted software development primarily in terms of speed. After working through two applications, speed is no longer the part I find most interesting. What interests me is what happens when the difficulty of turning a well-defined idea into software begins to fall. I did not spend years learning programming languages before I could contribute meaningfully to a build; I entered through the problem. My experience with operations, process improvement, logistics, leadership, and asking why something works the way it does became directly applicable because the technology helped bridge the gap between domain knowledge and technical construction.

There is a temptation to interpret this as AI replacing developers. My experience suggests something more nuanced. The work did not disappear; portions of it moved. Development accelerated, exposing the quality of the requirements. Automated testing increased, making undefined edge cases more obvious. Applications appeared faster, which meant the Final Mile arrived sooner. Professional developers remained especially valuable when the application encountered infrastructure, security, deployment, integration, and environmental realities that did not care how quickly the original software had been produced.

Across both experiences, I keep coming back to three places where I would be reluctant to remove people: requirements, the Final Mile, and acceptance. At the beginning, someone has to understand the problem well enough to define it. Near the end, someone has to connect the application to the messy reality in which it will operate. Finally, someone has to examine the evidence, consider the intended outcome, and accept responsibility for saying it is ready. AI can make each of those people dramatically more capable, but capability and accountability are not the same thing.

The Part That Still Belongs to Us

I started this experience thinking the remarkable story would be that someone who was not a developer could help build an application. That is still remarkable to me, but it is no longer the story I would tell. The more important lesson is that faster software development does not eliminate the disciplines surrounding software; it exposes them. Weak requirements become functioning mistakes faster. An application can deploy successfully and still be inaccessible. Every requirement can pass while the person sitting in front of the finished system still cannot accomplish the job.

The discussion around AI and software development therefore needs to mature beyond whether AI can write software. I have watched it happen. The better question is what an organization must know, document, test, and ultimately own when software can be produced at a pace that begins to exceed its traditional ability to think through those things. For me, the answer starts and ends with accountability: someone has to understand the problem before the first line of code exists, and someone has to own the outcome after the last line has been written.

I am still not a software developer, and I am comfortable saying that. What I have become is someone who understands considerably more about what it takes to deliver software. AI helped close a technical gap that once would have kept me on the outside of the development process, but it did not eliminate the need for experience, judgment, professional developers, or accountability. Maybe that is the real opportunity in AI-assisted development: allowing people with different kinds of expertise to participate where technical barriers once kept them out. If we can do that without confusing acceleration with readiness or automation with accountability, we may end up with something more valuable than faster software. We may actually build better software.

References

Brooks, K. (2026a, July 19). From acceptance criteria to automated assurance: How the Alchemy SDLC™ feeds Playwright-enabled testing from a traceable requirements baseline. ACC3 International. https://acc3int.com/whitepapers/acceptance-criteria-to-automated-assurance/

Brooks, K. (2026b, July 22). From prompt to production: Why AI software delivery needs a full SDLC. ACC3 International. https://acc3int.com/whitepapers/from-prompt-to-production/

Brooks, K. (2026c, June 29). Mission readiness begins with requirements readiness: Reducing software delivery risk before development begins. ACC3 International. https://acc3int.com/whitepapers/mission-readiness-requirements-readiness/