Why I Became an AI Developer After Being a Founder

For years I was the person asking engineers to build things.

Now I build them myself.

That transition can look like a career change from the outside: founder and CEO, then AI Developer.

It does not feel like one.

It feels like the same job with the distance between an idea and an executable system dramatically reduced.

Founders already do a large part of software development

When I co-founded Xpress Delivery, I was not spending my days writing application code. But I was constantly doing the work around the code:

• deciding what the product should do,
• decomposing operational problems,
• defining edge cases,
• choosing which integrations mattered,
• prioritizing development,
• debugging processes with customers and operations,
• translating messy reality into system behavior.

A large part of product engineering is deciding what should exist and why.

Historically there was still a large implementation gap between that decision and working software.

AI coding tools changed the economics of that gap for me.

AI did not remove engineering. It changed my leverage.

I use tools such as Claude Code, Cursor, model APIs, n8n, Python, TypeScript, Docker and automated tests as part of a normal development loop.

The useful part is not that a model can produce code quickly.

The useful part is that I can stay much closer to the complete problem.

Instead of handing a specification across organizational boundaries, I can move continuously through:

problem
→ process model
→ architecture
→ implementation
→ test
→ user feedback
→ production change

That loop suits the way I naturally work.

But it also creates a trap.

If code becomes cheap, bad architecture becomes cheap too.

The new bottleneck is judgment

When an agent can generate thousands of lines of plausible code, implementation volume stops being a useful signal.

The questions that matter become:

• Is this the right abstraction?
• Which parts should be probabilistic?
• What must remain deterministic?
• Where can the system fail?
• Which actions need human authority?
• How do we verify that the agent actually changed what it claims to have changed?
• Will somebody be able to understand this system six months from now?

This is why my operations background has been more useful in AI development than I expected.

Running a real company trains you to distrust happy paths.

Customers do unexpected things. APIs fail. People misunderstand instructions. Data arrives late. Reconciliation breaks. A process that is correct 98% of the time may still create an operational disaster at scale.

AI systems have exactly the same character.

Production systems made me more conservative about autonomy

In systems such as InvoiceFlow and Onboarding Flow, I have increasingly separated interpretation from execution.

Models are useful for messy inputs and language.

Schemas, state machines, business rules, tests and approval boundaries are useful for deciding what the system is allowed to do next.

I am also experimenting with a public R&D project, Hermes JIT Context OS, around context management for long-lived agents. It is work in progress, not something I treat as a finished answer. The goal is to explore how an agent can receive the smallest relevant state for the current turn while maintaining explicit authority and freshness rules.

That project exists for the same reason as my production work: I care less about making agents look intelligent and more about making AI systems understandable and operable.

I still want to be hands-on

There is a common assumption that once someone has been a founder, CEO or product leader, the natural next step is to move further away from implementation.

I do not want that by default.

I like building.

I like opening a terminal, tracing a webhook, changing a schema, testing an API and watching a system move from an idea to something another person can use.

I also like product strategy, enterprise discovery and leading teams.

I do not see those as competing identities.

The role I am best at sits somewhere between them:

understand the business problem deeply enough to choose the right system, then stay technical enough to help build and ship it.

Depending on the company, that role may be called AI Developer, Forward Deployed Engineer, AI Product Lead, Agentic Systems Builder or Head of AI.

The title matters less to me than the loop.

I want to stay close enough to the work that ideas can still become running systems.