All roads led to Markdown - Pax Dynamics | Pax Dynamics

NewOpenAIRT-300 — open-source AI red teaming curriculum<br>Operational

Hi,I'mPax

Thinker ∴ Researcher ∴ Hacker ∴ Coder ∴ Founder ∴<br>Based in Bucharest.

Back to Blog<br>I have always worked in startups. My role has often been some version of this: arrive when things are messy, build foundations, figure out the hard parts, make the system less fragile, then keep it that way.

Spoiler<br>p]:mb-0 [&_strong]:text-white">You can find the Build Right skills that came out of this loop at the end of the article.

But on the side, the real hustle was always building cool products.

The idea pile

Having ADHD gives the whole process a very specific texture. I do not struggle to come up with ideas. That would be convenient. I come up with too many, too quickly, and with enough detail to make each one feel briefly inevitable.

My brain is good at the first 30%. It sees patterns, wedges, systems, missing tools, bad abstractions, better abstractions, and sometimes the tool that should exist underneath the better abstraction.

The first 30%Where plausible ideas become weekend prototypesidea 1 -.<br>idea 2 -|<br>idea 3 -+--> all plausible<br>idea 4 -| |<br>idea 5 -' v<br>weekend prototype<br>more interesting adjacent problem

The annoying part is that the ideas are often not bad. If they were obviously stupid, I could close the tab and move on. But they tend to be plausible. Sometimes good. Good enough for a weekend, then a prototype.

But soon enough, my brain finds a more interesting problem next to the initial problem.

After repeating this enough times, I decided the real issue was not any single startup idea. I needed a system that could evaluate my pile of ideas for me: research the market, estimate execution difficulty, compare impact, revenue potential, distribution, competition, and all the other things I know I should do.

The first escape hatch

So I started building CEOgenerator .

CEOgenerator was meant to triage startup ideas before I emotionally invested in them. Not find product-market fit by magic, but make the first pass less impulsive: gather evidence, compare opportunities, and decide which hypotheses were worth testing in the real world.

In a more honest phrasing, it was supposed to protect me from myself while still allowing me to have ideas.

CEOgenerator<br>The first layer was public-facing idea triage: compare startup concepts before losing days to the latest plausible one.

CEOgeneratorA filter for ideas that feel inevitabletoo many startup ideas<br>CEOgenerator<br>market research<br>execution difficulty<br>impact<br>revenue potential<br>distribution<br>urgency<br>competition<br>"which idea is actually worth building?"

Having already figured it out in my head, my next insight was that I needed an app factory to build stuff for me.

I kept calling this laziness, but that was only half true. The stronger impulse was leverage: if I could turn repeated work into a system, I could move faster without dragging my attention through the same setup steps every time.

So I moved one level down.

The next layerThe answer created a new questionCEOgenerator answers:<br>"What should I build?"<br>new problem:<br>"Who builds it?"<br>app factory / execution system

The control plane detour (Framepath)

I started building what I thought of as a control plane for AI workloads. That project was Framepath .

The idea was to coordinate AI work more reliably: governed agents, tasks, scripts, artifacts, review steps, etc. I wanted something inspectable, something that treated AI execution like real work rather than a sequence of hopeful messages.

Framepath<br>Framepath was the AI control plane layer: the execution harness for tasks, scripts, artifacts, and review steps.

Framepath thesisThe control plane for AI workAI work, unmanaged:

prompt -> output -> hope<br>prompt -> output -> hope<br>prompt -> output -> hope

AI work, with a control plane:

task<br>script / model call<br>artifact<br>review step<br>next bounded action

For about a month, this felt correct. Not obviously a distraction. That is the problem with these detours: they are usually defensible. Each abstraction solves a real limitation in the previous layer.

Then I started thinking about launching it.

A public release would need positioning, documentation, examples, growth experiments, content, maybe community, maybe developer relations.

Framepath launch taxThe control plane now needed a company around itFramepath (control plane)<br>needs launch<br>+--> positioning<br>+--> documentation<br>+--> examples<br>+--> growth experiments<br>+--> content<br>+--> community<br>+--> developer relations<br>"this is also too much manual work"

This was no longer just product engineering. It was the company-shaped work around the product: explaining it, distributing it, proving it, supporting it, and keeping the story coherent while the thing itself was still changing.

Again, the leverage instinct kicked in. The next conclusion arrived: I needed agents to help me run the company around the thing.

Governance all the way...