You absolutely can.

What I bring is the ability to figure out what the software should actually do, how it should behave once real people start using it, what could go wrong around the edges, and what the system itself can handle so the user doesn’t have to.

I have 15 years of experience in operations and systems work, so I don’t begin with code. I start by trying to understand the system the software is entering:

• how people already behave
• where friction keeps recurring
• what depends on what
• what information is missing or arriving too late
• whether an apparently isolated problem is actually being produced somewhere else

A lot of that relies on pattern recognition and systems thinking. A feature can make perfect sense on its own and still create problems once it touches the rest of a workflow. I’m good at spotting those interactions early and noticing when several small frustrations are actually symptoms of the same underlying problem.

I also use branching and contingency reasoning to run features forward before and during development. What happens after this click? What if the user doesn’t have that information yet? What happens when two people interact with the same item differently? What state does the system enter if something is late, incomplete, duplicated, reassigned, changed, or abandoned?

My background in knowledge architecture and information logistics means I’m also paying attention to what information needs to exist, where it should live, when it should appear, who needs it, how it changes over time, and how much of that structure the user is being asked to keep in their own head.

That’s where cognitive load becomes part of the design.

Sometimes the right improvement really is a new feature. Other times it’s one less decision, an earlier piece of information, an automatic transition, a state the user no longer has to keep track of, or a visual hierarchy that makes the next action obvious.

Once there’s enough of a model to test, I use Codex to implement it quickly, and then the prototype starts giving us information back. I can see what works in practice, where my assumptions were wrong, what edge cases only became visible once the thing existed, and what needs to change before the software gets more complex.

What you’re paying for is systems analysis, interaction design, information architecture, contingency modeling, cognitive-load reduction, prototyping, testing, and technical implementation. Codex lets me move through the implementation much faster, but the speed is useful because there’s judgment behind what gets built and how it gets revised.

If you already have those skills, know exactly what you need, and you’re comfortable directing Codex through the implementation and debugging yourself, you may not need me.

Codex makes software cheaper and faster to write, but the quality of the software still depends heavily on the thinking that shapes it.