Software Engineering Has Shifted. The Opportunity Is Bigger Than Code.

For at least four months, one of my staff members had been working on our mobile app. We still had not reached the point we needed to reach.

I had other parts of the business to deal with, so I gave the work time. Eventually, I needed to get closer to it myself. What had been completed? What was still missing? What would it take to get the app into the stores?

At 6 a.m. on September 7, I sat down and opened Codex. At 11 p.m., I was still there.

Seventeen hours. I got up to stretch, get something to eat, and take the occasional break. Codex kept running. Throughout the day, it worked through the implementation, surfaced questions, and asked for direction. I answered, clarified what I wanted, and kept it moving.

I had signed into the resources we needed in external browser tabs. With the ChatGPT browser extension and full system access enabled, I gave Codex a view across the code, the connected resources, and the work of getting the apps submitted. I was there to supply the product decisions as they came up.

By the end of that stretch, Android had been submitted to Google Play, iOS and macOS to Apple, and Windows to Microsoft. We had also added browser-installation support. Store approval was still ahead of us, but a project that had occupied at least four months had finally reached those submission milestones.

I kept thinking about what had changed.

The existing work gave me something to build on. But I also brought a clear picture of the product, the authority to make decisions, and enough AI credits to keep going until the remaining pieces came together.

That combination has changed my relationship with software development.

I could see the product before I could build it

I started my career writing Java. Fresh out of school, I struggled with syntax and with getting a complete application to work. Over time, I became more comfortable. I began enjoying it and taking on work beyond my immediate responsibilities.

Then my career moved toward project management, product development, and product marketing. I spent years learning to see technology through the eyes of the people who would use it.

I could picture a product. I could understand what a customer was trying to accomplish, how the screens should connect, and where an experience would become frustrating. My engineering background helped me understand what was possible. My product experience helped me decide what was worth doing.

But there was still a distance between what I could see and what I could personally implement.

Building Postly made that distance very real. In the early days, bugs and poor experiences kept the product from becoming what I wanted it to be. I worked on the website, made updates, and handled improvements there. The dashboard was different. I depended heavily on the development team for that part of the application.

I respected their ability to work in the code. They were closer to it than I was. Meanwhile, I carried a lot of the product direction in my head. They would ask how something should behave, I would explain, and the work would move forward through that exchange.

Then I started using AI to understand the dashboard myself.

At first, I needed explanations. Show me how this application is organized. Where does this feature live? How does this service connect to that one? What happens after the customer presses this button?

Gradually, the codebase became familiar. I could locate the relevant files, follow a connection, and understand more of the journey from one end to the other. Then I began changing things: fixing bugs, adding features, reviewing modules, and looking again at the places where customers were struggling.

Years of product experience suddenly had a more direct outlet. I could follow an idea much further into the work myself.

The mobile app brought the change into focus

With the mobile app, I wanted to look at the whole journey. Having parts of an application working was encouraging, but we needed to carry the product through the remaining fixes, preparation, and submissions.

That meant staying with it. An audit would uncover another issue. A fix would need checking. A release requirement would reveal another piece of work. I could keep moving between the product intention and the implementation because I understood the destination and could make decisions as questions arose.

My team usually gets that picture in pieces. A developer reaches a question, comes back to me for confirmation, gets another piece of context, and continues. Then the next question appears. Knowledge of the code and knowledge of what I want the product to become do not always sit with the same person.

During those seventeen hours, I could bring them together. The relevant accounts were open. The system was accessible. I knew how the separate parts were meant to fit. When Codex needed guidance, the person who could decide was sitting in front of it.

That is an important part of what happened that day. The uninterrupted run depended on the context and access I had assembled, as well as my willingness to remain involved. Even when I stood up from the chair, the work could continue; when it needed a decision, I came back to it.

It was an intense stretch. I recall spending close to $500 on AI credits during that push. I was willing to spend the money because I wanted to get the product to that point.

Even GitHub felt the pace. After roughly a hundred pushes, I ran into its usage allowance for the automated builds and checks. Continuing meant additional charges. I accepted them gracefully and kept going. By then, I had decided to fund the work through to submission.

I did not even have a MacBook. That could easily have become another pause in the project: we need a Mac before we can continue. Instead, we used GitHub's hosted macOS environment to build the Apple apps. The Mac resources we needed were available remotely, and we could keep moving from the computer I already had.

I could imagine the missing MacBook becoming another question a team member brought back to me. During that session, I could investigate the alternative and authorize it myself. The same was true when the usage allowance ran out. Each obstacle brought another decision, and I was there to make it.

By the time I got up that night, I had worked around the missing hardware, accepted additional costs, and stayed with the questions as they appeared. The limitations had been real. So had the alternatives we found.

The money was one part of the trade-off. There were also seventeen hours of my attention and the breadth of access I had enabled. A tool working across more of the business can carry a task further, but a mistaken action can also reach further. I was putting my time, accounts, and resources behind the work while staying close enough to guide it.

As a small-business owner, I now find those decisions difficult to separate. How much context can I make available? Which access is necessary? What am I comfortable allowing the tool to do, and where do I want it to stop for me? How much capacity can I afford to give someone else so they can work with similar continuity?

That day, I could make those choices myself. Creating the same conditions across a team is a different decision, with its own costs and responsibilities.

A developer can understand the assignment and still be repeatedly interrupted by usage limits. Just as the tool begins to help them trace a problem across the application, the allowance runs out. They wait, reduce the scope, or try to continue with a less suitable setup. The work loses continuity.

My assessment of the mobile-app experience is that the staff member needed a stronger product vision and enough capacity to work effectively with Codex or Claude. I had both available to me, along with the freedom to devote a concentrated stretch of time to the problem.

I was also building on work that already existed. The four months and my intervention cannot be compared as if we had both started with an empty folder. Still, the difference in momentum was impossible for me to ignore.

For me, the product knowledge, the freedom to make decisions, and the ability to keep the tools running had come together in a way I had not experienced before.

Then it happened again with AskOnu

The next day, I saw a similar pattern with AskOnu.

AskOnu is our AI assistant and a standalone commercial product for other businesses. We also use its capabilities inside Postly, where our own customer problems help us sharpen what useful assistance should look like.

Another staff member had been handling that work. In our exchange, he described running out of his AI allowance before getting far enough into the task. I could see the same two needs: clearer product direction and enough tokens to carry the work through.

For me, the intended experience was quite specific. If a customer says a post failed, the assistant should ask for the Post ID and investigate. It should look at the available records, use its understanding of the product, explain what it finds, and help the customer take the next step.

If the customer replies with more information, the conversation should continue from there. If the assistant cannot establish the cause, it should acknowledge that and help the customer reach support.

The database and code connections existed to serve that experience. Their presence alone did not make the assistant useful. The product needed a clear idea of what to do with them.

I spent about an hour directing and carrying through the latest troubleshooting changes with AI assistance. We added investigation through read-only database and code access, retained the context of follow-up questions, and made support referrals depend on whether the investigation remained unresolved. The checks passed; we still needed to verify the behavior in production.

That hour built on the existing AskOnu system. What struck me was how quickly a focused intervention could move the work once the expected customer experience was explicit.

I knew what I wanted the assistant to accomplish. I could recognize when an answer fell short. And I had enough room to keep working with the tool until the implementation came closer to that intention.

Coming back to the work

These experiences have made me think differently about the years I spent away from daily programming.

For a long time, those years seemed to put more distance between me and the code. Now, much of what I learned during them helps me direct the work. Customer understanding, product decisions, and the ability to connect separate parts of an experience have become immediately useful at the keyboard.

I still need engineering judgment. A change can appear to work and fail somewhere else. A customer can take a path I did not consider. Every improvement has to survive contact with the rest of the product.

My early experience with Postly makes it difficult to forget that. Customers experience the missed connection, the failed action, and the confusing screen. They do not experience how impressive the tool looked while generating the code.

So I keep going back through the modules. I inspect, question, test, and revise. AI has made that participation more accessible to me. The responsibility for the experience remains.

There are questions I am still working through. How much AI capacity can I provide across the team? How do I know it is being used effectively? How much of my own pace comes from knowing the product so deeply, and how much comes from being willing to spend hours on it without stopping?

The cost is real. So is the difference I have felt when I can keep going. I have more freedom as the founder to make that trade-off, and the mobile app and AskOnu made that difference particularly visible.

I do not have a finished formula for all of this. I have two recent experiences, a much closer relationship with my own product, and a growing sense that skills I developed years ago are finding a new use.

When I think back to the young Java developer struggling to get a complete application working, this feels like a remarkable turn. I spent years developing an understanding of products and customers. Now I can bring more of that understanding directly into building.

That is what the shift in software engineering feels like to me: the distance between what I can imagine and what I can help create is getting shorter.

For years, I could see the product I wanted to build. Now I can spend much more of my time inside the work of making it real.