Confessions of an Accidental Vibe Coder

I did not become a coder in the traditional sense.

I became something stranger.

An accidental vibe coder.

Or maybe the more honest phrase is this: vibe coding in a suit.

That phrase matters to me because it is not a metaphor. I wear a suit to work. I sit in management meetings. I deal with people, dashboards, business lines, reporting, delays, approvals, operations, expectations, and execution gaps. I am an engineer by education, but I am not a software developer. I did not grow up writing code. I was not the person who could open a blank screen and start building an application from scratch.

And yet, over the last few months, I have found myself doing something I never expected to do in this role: building real tools, dashboards, websites, automations, and internal business intelligence systems with the help of AI agents.

Not as a hobby.

For work.

For an actual group of companies.

The problem was never ideas

As a general manager working across a large, diversified group of companies in 11 sectors, my biggest problem was never a shortage of ideas.

It was the opposite.

There were too many things to track. Too many moving parts. Different sectors, different teams, different rhythms, different reporting formats, different systems, and different levels of urgency.

One business line needed better monitoring. Another needed cleaner dashboards. Another needed visibility on CRM activity. Another needed a way to see operational progress without waiting for someone to compile a report. Another needed a custom view that did not exist in the software we were already using.

From a management perspective, I could see what was missing. I knew what I wanted on the screen. I knew the question I wanted the system to answer. I knew what the dashboard should show, what the alert should catch, what the report should simplify, and what the team should be able to act on.

The difficult part was turning that vision into software.

The translation gap

This is the part many business leaders will understand.

You can explain your idea to a technical team. You can describe the dashboard. You can draw the workflow. You can say what the button should do, what the report should show, and how the system should feel.

But what is inside your head does not always arrive on the screen in the same shape.

That is not because the technical team is not capable. It is because there is a translation gap between business intent and technical execution.

I would explain what I wanted. The team would build what they understood. Then we would review it. Then I would clarify. Then they would adjust. Then another issue would appear. Then the requirement would evolve. Then we would go through another round.

This was normal, but it was slow.

Even basic dashboards, CRM views, ERP-linked tools, and internal monitoring systems could take several iterations before they felt right. The gap was not only communication. It was expectation. What I could see clearly in my mind was hard to transfer fully to someone else, especially when the business context was spread across so many sectors and companies.

That gap created delay.

It also created dependency.

Then agents changed the workflow

When I started using AI agents, something shifted.

For the first time, I could describe what I wanted in plain English and see it take shape almost immediately.

I did not need to know the syntax. I did not need to understand every framework. I did not need to become a developer first. I could explain the business problem, the user flow, the dashboard layout, the data I wanted to see, the kind of interface that would make sense, and the changes I wanted after seeing the first version.

Then I could keep iterating.

Prompt by prompt.

Screen by screen.

Fix by fix.

That was the turning point.

The agent did not remove the need for thinking. It made my thinking executable.

Suddenly, the distance between an idea in my head and something working on a screen became much shorter. I could test, reject, modify, rebuild, and improve without waiting for a full technical cycle every time.

That is when I started to understand what vibe coding really meant for someone like me. It was not about pretending to be a programmer. It was about using language, judgement, and business context as the new interface for building. If you want the deeper version of that argument, I wrote about the system around the model in After the Prompt: The Operator's Harness.

Vibe coding in a suit

Most people imagine coding as someone in a hoodie, sitting in a dark room, typing into a terminal.

My version looks different.

It looks like a business operator in a suit, using AI agents to turn management problems into working tools. Not after hours as a side project. During the workday, as part of how I operate now.

That is why I like the phrase vibe coding in a suit.

It captures the strange mix of old and new. Boardroom and codebase. Management and software. Business instinct and technical execution. Plain English and working applications.

I am not writing code line by line. I am briefing agents. I am reviewing outputs. I am testing the product against the real business need. I am saying, "No, this is not what I meant," or "Move this here," or "This dashboard should show the group view first," or "This needs to connect with the way our team actually works."

That is not traditional coding.

But it is building.

And for leaders, owners, and senior managers, that distinction matters.

What we started building

Once the workflow clicked, the possibilities opened up quickly.

We started moving beyond generic dashboards and third party business intelligence tools. We began building internal tools shaped around how our company actually works.

Not how a software vendor assumes we work.

Not how a template wants us to behave.

Our own flows. Our own views. Our own monitoring. Our own dashboards. Our own internal intelligence.

Some of these tools connect with existing systems. Some support reporting. Some improve visibility. Some help monitor activity across business lines. Some are still evolving. The important part is that we can now shape them continuously.

If something does not fit, we change it.

If the model improves, we improve the product.

If the business requirement changes, we do not have to start a long cycle again. We can brief the agent, test the change, and keep moving.

That is a very different kind of leverage.

The uncomfortable part

I do not want to make this sound cleaner than it is.

There are risks.

Sometimes I still feel uncomfortable about what is happening under the hood. How secure is it? How stable is the infrastructure? What happens if something breaks? What if a dependency fails? What if the code works today but becomes difficult to scale later? What if I do not fully understand the technical choices the agent made?

These are real questions.

The strange thing is that the same agents that create the system can also help diagnose it. They help debug. They explain errors. They suggest fixes. They rebuild parts that fail. They help me understand enough to keep going.

It becomes an iteration loop.

Build. Break. Diagnose. Fix. Improve. Repeat.

That loop is not always comfortable, but it is powerful.

And with every new generation of AI models, the quality improves. The design gets better. The code becomes more stable. The debugging becomes clearer. The agents become better at helping a non-developer stay in the process without being completely blind.

Why this matters for business leaders

The people who should pay attention to this are not only developers.

Founders should pay attention. Family business owners should pay attention. CEOs, COOs and general managers should pay attention.

But this is not only for the top of the org chart. Team leads should pay attention. Managers running a single function or department should pay attention. Project owners, small business owners and people responsible for even one process they care about should pay attention.

You do not need a senior title to use this. You need a real problem and the willingness to describe it clearly.

Anyone who has ever said, "I know exactly what I need, but I cannot build it," should pay attention.

For years, technical execution was a bottleneck for many business leaders. If you did not have a developer available, the idea waited. If the software vendor could not customize it, the business adjusted itself to the tool. If the dashboard was not right, people exported to Excel and worked around it. If the reporting was not visible enough, management waited for another meeting.

AI agents change that equation.

They do not make everyone a software engineer.

But they do give operators a new kind of technical leverage.

If you understand the business problem clearly, if you can explain the workflow, if you can review the output with discipline, and if you are willing to iterate, you can now build far more than before.

That is a major shift.

The real skill is briefing

The more I use agents, the more I realise the future skill may not be coding in the old sense.

For many people, the skill will be briefing.

Can you explain what you want clearly? Can you describe the business logic? Can you spot when the output is wrong? Can you keep pushing until the tool matches the reality of the company? Can you translate messy operational experience into clear instructions?

That is where managers and operators may have an advantage. We live with the problems. We know where the friction is. We know which reports nobody reads. We know which dashboards look good but do not help decisions. We know where the business is blind.

Agents are useful because they can turn that knowledge into something visible.

But only if the person briefing them knows what matters.

What changed for me

Before agents, I had to depend heavily on others to translate my ideas into technical output.

Now I can sit with the problem myself.

I can shape the first version. I can test the logic. I can refine the interface. I can push the system closer to what I originally imagined. I can involve the technical team later with more clarity because I am no longer handing over only an abstract idea. I can show a working direction.

That changes the conversation.

It makes me faster. It makes the company faster. It reduces the distance between management thinking and operational tools.

It also changes how I see technology.

Software is no longer only something we buy, request, or wait for.

It is something we can shape.

The next builders may not all look like coders

I still respect real developers. Maybe more than before.

Using agents has shown me how much complexity sits behind the screen. It has also shown me that the boundary around who can build is moving.

The next generation of builders will still include programmers. Of course it will.

But it will also include operators, managers, founders, and business owners who know their problems deeply and can use agents to turn that knowledge into tools.

Some will build at night after work. Some will build internal dashboards before asking for budget. Some will create prototypes before hiring teams. Some will finally see their ideas appear on screen without losing half the vision in translation.

That is what happened to me.

I did not plan to become a vibe coder. I did not set out to build software. I was trying to solve business problems across a large and complex group. Then AI agents gave me a new way to do it.

So yes, I am an accidental vibe coder.

And I am doing it in a suit.

Frequently asked questions

Keep exploring

Author note

Prateek Saxena writes about AI transformation, business operations, and the practical use of AI agents in real-economy companies from Abu Dhabi. More in the media kit, on the Al Zaabi Group role page, or across the Journal. More practical guidance is on the AI agents for business operators hub.