I’ve been involved with software development for a long time.
I’ve designed systems, worked with databases, managed enterprise software projects, written requirements, and spent years translating business and operational problems into technology solutions. At PPI, I managed as many as six programmers at one time.
But there was one part of the process I generally didn’t do myself.
I didn’t sit down and write all the production code.
I hired programmers to do that.
My role was to define what the business needed, work through the processes and requirements, review what was being developed, identify problems, make decisions, and determine whether the software actually did what we needed it to do.
Today, I’m doing something remarkably similar.
Except the programmer is an AI.
I’m currently developing a SaaS platform for service and rental operations using OpenAI Codex as the primary software-engineering agent.
The platform brings together many of the things these businesses deal with every day, including leads, customers, quotes, orders, inventory, scheduling, dispatch, field operations, billing, payments, reporting, and the operational workflows that tie everything together.
It’s a substantial software project.
And I’m not personally writing the production code.
Codex is.
That sounds simpler than it actually is.
I didn’t type, “Build me a SaaS application,” and watch a complete product appear.
If anything, this project has reinforced something I learned years ago while managing programmers.
Knowing how to write code and knowing what software needs to do are two very different things.
My job is largely the second one.
The Coding Changed. The Management Didn’t.
When I managed programmers, I couldn’t simply tell them to “build the system.”
Someone still had to answer questions like:
What exactly is the business process?
What happens first?
What happens next?
What information needs to be captured?
What exceptions can occur?
Who should be allowed to do what?
What happens when something fails?
How do we know the result is correct?
Those questions haven’t disappeared because the programmer happens to be AI.
For this SaaS, I’ve had to work through questions like:
What actually makes inventory available for another rental?
What happens after an asset is picked up but hasn’t completed the next operational step?
Who is allowed to change customer pricing?
What should customers be able to see?
What happens if a payment processor succeeds but the application doesn’t receive the expected notification?
How should the system prevent the same transaction from being processed twice?
What happens when two users try to change the same information?
What should happen when an outside integration fails?
Those aren’t primarily programming questions.
They’re operations, process, product, risk, and control questions.
Eventually someone has to decide the answer.
That’s my job.
Codex’s job is to turn those decisions into working software.
AI Didn’t Eliminate the Work. It Moved It.
That may be the biggest thing I’ve learned so far.
AI hasn’t eliminated the work required to create software.
It has shifted where much of the work happens.
Instead of spending my time converting requirements into programming syntax, I can spend more of it working on the requirements themselves.
What should happen?
Why should it happen?
What could go wrong?
What are the dependencies?
What must not change?
What would prove the requirement has actually been satisfied?
Those questions become even more important when implementation can happen much faster.
Codex can inspect the existing software, work within the repository, implement functionality, modify database structures, create tests, run validations, and work through GitHub branches and pull requests.
But speed creates another challenge.
It becomes very easy to create more software.
And more software isn’t necessarily progress.
Sometimes the Right Instruction Is: Don’t Write Any Code
This was one of the more surprising lessons.
There have been situations where a requirement appeared to represent unfinished work.
The obvious response would have been to tell Codex to implement it.
But after inspecting the system, we sometimes discovered that the functionality was already there.
The real problem was that the requirement, testing, documentation, or evidence hadn’t been properly reconciled with the existing implementation.
In those cases, adding more code would have been the wrong move.
That changed how I think about AI-assisted development.
When code becomes inexpensive to produce, restraint becomes more valuable.
The goal isn’t to maximize how much code AI creates.
The goal is to build the right system.
Sometimes that means writing code.
Sometimes it means fixing code.
Sometimes it means testing something more thoroughly.
And sometimes it means leaving perfectly good software alone.
My Prompts Actually Got Shorter
Early in the project, I did what I suspect a lot of people do when they start working seriously with AI.
I tried to explain everything.
The prompts became enormous.
Requirements, background, exceptions, warnings, technical details, rules.
More detail felt safer.
Eventually, I realized I was starting to get in the way.
As the project matured, much of that information became part of the repository and the project’s governing documentation.
The requirements were there.
The architecture was there.
Dependencies were documented.
Tests existed.
Completed work had evidence.
Rules defined what the agent could and couldn’t change.
The system itself increasingly provided the context.
My instructions became much simpler:
Use the governing requirements.
Inspect what already exists.
Don’t rebuild completed work.
Determine the next dependency-safe item.
Implement it.
Test it.
Provide the evidence.
Stop when a business decision requires me.
That worked much better.
The lesson wasn’t that prompting became less important.
It was that the environment around the AI became more important than the individual prompt.
I Don’t Automatically Trust “Complete”
Another lesson came directly from my years in operations, quality, project management, and software implementation.
“Done” has to mean something.
If Codex reports that a work item is complete, that doesn’t automatically make it complete.
Does the implementation satisfy the requirement?
Did the appropriate tests pass?
Were the important edge cases considered?
Did anything else break?
Are permissions enforced?
Are failures handled correctly?
Does the implementation match the actual business process?
Is there evidence supporting the completion claim?
Sometimes Codex has found problems I missed.
Sometimes I’ve found problems in Codex’s interpretation.
Sometimes the software was correct and the requirement was wrong or incomplete.
And sometimes everything worked, but the evidence wasn’t sufficient to prove it.
That process feels surprisingly similar to managing human technical teams.
The technology changed.
The need for review, testing, judgment, and accountability didn’t.
Capability and Authority Are Not the Same Thing
I’ve also become much more deliberate about what authority an AI agent should have.
An AI agent can potentially have tremendous execution capability.
That doesn’t mean it should have unlimited authority.
There are actions I don’t want an AI making independently simply because it technically can.
Production infrastructure.
Security decisions.
Financial transactions.
Major business-rule changes.
Uncontrolled cloud provisioning.
Anything else with significant business consequences.
The same management principles I’ve used with organizations and systems still apply.
Permissions matter.
Approval limits matter.
Segregation of duties matters.
Testing matters.
Traceability matters.
Recovery matters.
Accountability matters.
The objective isn’t to keep AI from doing meaningful work.
Quite the opposite.
I want the agent to accomplish as much as possible independently within clearly defined boundaries.
But there’s a major difference between giving something the ability to execute and giving it the authority to decide.
This Feels Familiar
Maybe the most interesting part of this project is how familiar some of it feels.
For years, if I needed software developed, I worked with programmers.
I understood the business.
I defined the problem.
I explained the workflow.
We discussed the requirements.
They built something.
I reviewed it.
We found problems.
Requirements changed.
The software changed.
We tested it.
Eventually, we decided whether it was ready.
I’m still doing many of those same things.
What has changed is the distance between an idea and its implementation.
Instead of a requirement working its way through multiple layers before reaching the person doing the coding, I can work much more directly with the entity performing the implementation.
That feedback loop can be extraordinarily fast.
And I think that has implications far beyond this project.
Domain Experts May Be Able to Build Things They Couldn’t Build Before
Think about how much industry knowledge exists inside businesses that has never been turned into software.
A production manager understands a manufacturing problem.
A dispatcher understands routing.
A warehouse manager understands inventory movement.
A contractor understands estimating.
A purchasing manager understands supplier problems.
A healthcare professional understands a workflow.
A small business owner understands dozens of inefficiencies outsiders may never see.
Historically, having that knowledge wasn’t enough to create software.
Someone still had to translate it through analysts, architects, developers, testers, and technical teams.
Those people still provide tremendous value, particularly in complex, regulated, highly scaled, security-sensitive, or technically demanding systems.
I don’t see AI making professional software engineers irrelevant.
But I do see something else happening.
The distance between knowing a problem extremely well and being able to build software that addresses it is shrinking rapidly.
That’s a big deal.
It means the next generation of software creators may include more operations people, industry experts, project managers, entrepreneurs, engineers, and business leaders who would never have considered themselves software developers.
They may not personally write the code.
They may not need to.
Their value may come from understanding the problem, designing the system, defining the constraints, directing the AI, evaluating its work, and knowing when the result is actually right.
AI Isn’t Only Building the Product
There’s another layer to this project that makes the experiment even more interesting.
AI isn’t only helping me build the platform.
I’m also designing AI capabilities into the software itself, with the goal of helping operators automate routine work, identify problems earlier, and make better operational decisions.
That’s a different part of the story, and one I’ll write more about as the product develops.
I’m Still Building It
This project isn’t finished.
There are still capabilities to complete, validations to perform, and decisions to make before I would call the product finished or production-ready.
That’s actually one reason I wanted to write about the experience now rather than wait until the end.
I’m learning things during the process that I probably won’t remember quite the same way once the finished product exists.
So far, though, one conclusion has become pretty clear.
I didn’t suddenly become a software programmer.
I already knew how to manage software development.
For years, I did that by working with human programmers.
Now I’m finding out what happens when much of the implementation can be performed by an AI agent instead.
And I’m increasingly convinced that this is the more interesting story.
AI may make programming dramatically faster.
But its larger impact may be giving people who deeply understand businesses, industries, processes, and problems a much more direct way to turn that knowledge into working software.
I’m building one of those products now.
And I’m learning quite a bit along the way.
