I’m not a traditional coder. I’m a founder-operator and CFO who has spent 25+ years building businesses, solving operational problems and figuring out how to make things work better. Now I’m using AI to write code, build websites and apps, and develop a multi-agent environment where different agents can execute different parts of the work.
Call it vibe coding. For a tech-minded business owner, it’s a game changer.
The practical change is that I can take a business problem further on my own. I can describe what I need, work with AI on an implementation, test the result and keep refining it. An idea that once needed a specialist’s availability, a development budget and a place in the project queue can now reach a working prototype much sooner.
That creates room to tackle smaller operational improvements that are useful but difficult to justify as standalone software projects.
01
A shorter path from idea to test
Most operators can point to a process that wastes time. Someone copies information between systems. A recurring check depends on somebody remembering. A report takes more effort to assemble than it should. The person closest to the problem often knows what a better process would look like.
AI-assisted building gives that person a way to start implementing it.
My own work has included websites and apps, information gathering and structured reports, alongside experiments with scheduled tasks and business automation. The useful part is being able to move between the business requirement and something I can actually inspect. When the output misses the point, I can revise the instructions or the implementation and try again.
A concrete example in my local environment is scheduled version checking with logging. I’ve confirmed that piece works. It’s a small job, but it makes the operating questions tangible. Did the check run? What did it find? Is there a record? Does anything need attention?
Those questions matter more as the work becomes consequential. A successful scheduled check is a starting point for broader testing, not proof that the entire environment is production-ready.
02
TRON as Chief of Staff
I’ve recently added OpenAI Dots to the setup and named my dot TRON 😏. In the architecture I’m building, TRON is the top-line, always-on manager above the DorkOS multi-agent platform, positioned as my AI “Chief of Staff.”
The role is to help translate my priorities into defined work, coordinate tasks and bring back the results or decisions that need my attention. On my Mac, DorkOS provides the environment for organizing local agents that carry out assigned work. TRON is my coordinating point across that activity.
This is how I’m structuring my own setup. Local execution depends on the computer being available, the necessary connections working and the permissions I’ve granted. Human approvals and the tools’ safeguards still apply.
The Chief of Staff idea helps me think about responsibilities. I set the objective and decide what matters. TRON helps coordinate the work. The executing agents need clear assignments and a way to show what they did. Giving an agent a role is useful only if I can tell whether it fulfilled that role.
03
The operator still owns the outcome
Writing a request is part of the job. Defining a useful result takes more thought.
For a report, I need to specify the source information, the period covered and what the reader needs to decide. For an automated check, I need to know what counts as a problem and when it should be escalated. For a website or app, I need to test the actual user journey, including what happens when information is missing or something fails.
Business experience helps with those decisions. It tells me which exception matters, where a handoff breaks down and what would make the output usable by the next person. AI can help implement the process, but I remain responsible for whether the process makes sense.
I also need to distinguish permission to investigate from permission to change something. Access should fit the assignment, and consequential actions need the right review. A good-looking result can still contain an error. Testing has to go beyond asking the agent whether it finished.
04
What I would build first
For another owner or executive, I’d start with one recurring problem whose result is easy to check. Choose something small enough to understand end to end. Describe the current process, define the improvement and test it against real examples before expanding its responsibility.
There are limits. Generated code needs review. Integrations fail. Local machines go offline. Maintenance continues after the first successful run. More complex or higher-risk work still benefits from experienced technical specialists.
My broader multi-agent setup is still developing, and I’m treating it that way. What I can already see is a practical new ability to build and test improvements myself. For a business owner who understands the work and is willing to learn, that changes which ideas are worth trying.
END OF LINE.