Empires.

Religions.

Tax offices.

HOAs.

Even Microsoft Access databases used as enterprise software.

Nothing prepared him for this.

He looked over God's shoulder.

"Father..."

God sighed.

"Yes?"

Lucifer pointed toward Earth.

More specifically...

...toward my laptop.

"He's scheduled an AI to write a weekly blog post..."

God nodded.

"That sounds reasonable."

Lucifer continued reading.

"...summarizing all the software he built..."

Another nod.

"...which was mostly built with AI..."

God looked slightly less confident.

Lucifer kept scrolling.

"...based on conversations with another AI..."

God frowned.

Lucifer scrolled farther.

"...formatted automatically for Docusaurus..."

God scratched His beard.

Lucifer continued.

"...using the Blog MCP server..."

God blinked.

Lucifer reached the last line.

"...so eventually the AI can automatically publish the article describing how it automatically generated the article."

Silence.

A very long silence.

Finally...

Lucifer looked up.

"Father."

"Yes?"

"Have they invented recursive bureaucracy?"

For centuries humanity has insisted that artificial intelligence would replace programmers.

Instead...

This week I taught an AI to write my weekly engineering journal.

Every Sunday.

At 8 PM.

Automatically.

The report will include:

• executive summary;
• development completed;
• architecture decisions;
• technical discoveries;
• project completion;
• ideas that appeared during random conversations;
• work still in progress;
• next priorities.

All generated from conversations.

Not commits.

Conversations.

Because apparently my development methodology has become:

Talk to AI until software accidentally appears.

The truly absurd part isn't the automation.

It's the source material.

Some architecture decisions happen while sitting at a computer.

Mine seem to happen:

• while driving through Sofia;
• while standing in Bulgarian government offices;
• after getting a phone call from the police;
• in a hookah lounge;
• while making dinner;
• somewhere between laughing at bureaucracy and inventing another software project.

Those conversations become:

• GitHub repositories;
• game engines;
• agent frameworks;
• business ideas;
• marketing slogans;
• blog posts;
• comic books.

Now another AI gets to summarize all of it.

Lucifer stared at the screen.

"Wait."

"It says the summary includes ideas that came out of the week."

God nodded.

"Yes."

"Where do those ideas come from?"

God pointed toward me.

Lucifer looked confused.

"So he talks to AI..."

"...gets ideas..."

"...builds software..."

"...then AI summarizes the ideas..."

"...which become future prompts..."

"...that create more software..."

God smiled.

Lucifer slowly looked back toward Earth.

"This isn't software engineering anymore."

"It's an ecosystem."

Then I had one final thought.

Why stop there?

The Blog MCP server already knows how to publish posts.

The weekly report already knows what happened.

The repository already knows what changed.

The AI already knows how to write.

At some point...

...the automation itself is going to publish an article that says:

This week Ben improved the automation responsible for writing this article.

Without me touching a keyboard.

Lucifer closed the laptop.

Walked away.

Stopped.

Turned around one last time.

"Father..."

"Yes?"

"I no longer believe humans are building AI."

God smiled.

"No?"

Lucifer sighed.

"I think they're building increasingly elaborate excuses to avoid writing documentation."

God laughed.

The angels laughed.

Somewhere on Earth...

A scheduled task quietly waited for Sunday at 8:00 PM to generate a blog post about the software that would eventually generate blog posts about itself.

And somehow...

...everyone involved thought this was a perfectly reasonable use of artificial intelligence.

Including me.

"How does Jones in the Fast Lane actually work?"

Reasonable question.

Perfectly harmless.

The sort of curiosity that should result in reading a Wikipedia page and then going to bed.

Instead...

I accidentally built a game engine.

The Current Situation​

The engine is now:

50 out of 51 named work units complete.

Approximately 98%.

I find this deeply suspicious.

Not because the numbers are wrong.

Because two weeks ago there wasn't even a project.

There was just one question.

Apparently This Exists Now​

Current inventory includes:

• A deterministic engine.
• Replay.
• Save/load.
• Validation.
• Sessions.
• Projections.
• MCP support.
• Versioning.
• CI.
• Package publishing.

Somewhere in there I also remembered to make it capable of running games.

That seems important.

Three Completely Different Games​

Originally I wanted to recreate one game.

Now the engine already supports three entirely different styles of simulation.

Story Graph​

A branching narrative.

The first campaign?

Naturally...

Bureaucracy.

Because if you're going to test branching dialogue, you might as well start with something fictional.

Like Bulgarian government offices.

Simulation​

A weekly life simulation.

The thing that started this entire mess.

Jobs.

Money.

Needs.

Education.

Relationships.

One innocent conversation with an LLM later...

...here we are.

World Graph​

A living spatial simulation.

Twenty deterministic systems.

Autonomous guests.

Validation.

Action previews.

Synthetic worlds.

Which is considerably more engineering than I expected from:

"I wonder how Jones worked."

Replay​

One of my favorite things about the engine is replay.

Every world.

Every decision.

Every action.

Deterministic.

Every bug reproducible.

The phrase:

"Works on my machine."

has officially been escorted off the premises.

Bulgaria Is Canon​

This is perhaps the funniest unintended consequence.

The first real content now includes:

• all five Bulgaria story arcs;
• save migration;
• bureaucracy;
• deterministic replay.

Apparently my life has become test data.

I didn't see that coming.

There's Only One Thing Left​

One work unit.

W49.

It's not another feature.

It's confidence.

The remaining work is basically the engine asking itself difficult questions.

Questions like:

"Are you absolutely sure?"

Again.

And again.

And again.

The remaining work is:

• stronger validation;
• replay verification;
• save/load parity;
• regression coverage;
• package verification;
• release confidence.

The glamorous side of software engineering.

Meanwhile...​

While building the game engine...

I accidentally built half of a publishing platform.

Because I wanted better documentation.

Then Git became the source of truth.

Then Docusaurus.

Then previews.

Then validation.

Then Discord notifications.

Then MCP.

Then REST APIs.

Then AI editing.

Then...

Well...

Apparently that became another product too.

I no longer question these things.

The Roadmap​

My favorite part of the documentation isn't the architecture.

It's the roadmap.

Because it doesn't read like project management.

It reads like a novel.

Instead of:

• authentication;
• networking;
• optimization;

it says things like:

The first story survives contact with bureaucracy.

The engine learns the rules.

The past becomes testable.

The engine gets a front door.

That's considerably more entertaining.

Looking Back​

The funny part isn't that AI wrote a lot of code.

It did.

The funny part is what AI didn't do.

AI didn't decide:

• that mechanics should become reusable;
• that determinism mattered;
• that commands should be the only way to mutate world state;
• that documentation should read like a story;
• that "Well... why not?" somehow became the philosophy of the entire project.

Those decisions still belonged to me.

AI simply removed an astonishing amount of friction between ideas and reality.

I Have No Explanation​

Two weeks.

That's all this has been.

The engine is almost finished.

The first Kind is running.

The second is running.

The third is running.

The landing page is live.

The documentation exists.

The roadmap tells a story.

And somewhere in the middle I accidentally created another product.

I still don't know exactly how this happened.

I suspect it started with one innocent question.

It escalated.

Future Me has been notified.

Future Me has not replied.

Well...

Why not?

Continue working on the Game Engine.

Unfortunately, somewhere between "expand the campaign system" and "I wonder if AI should generate JSON instead of TypeScript," several entirely new projects appeared, the blog quietly promoted itself to infrastructure, Git started looking suspiciously like a deployment platform, and AgentKit developed career ambitions.

None of this was scheduled.

I'm beginning to suspect the repositories are collaborating behind my back.

Development Completed​

SubZeroDev.GameEngine​

The engine itself behaved.

The campaign system did not.

What started as "let's add more campaigns" quietly evolved into an AI content pipeline where structured JSON replaces handwritten code, CI validates everything, and the engine simply consumes whatever fresh insanity gets committed next.

Apparently the engine's new hobby is eating data.

SubZeroDev.AgentKit​

AgentKit continued discovering what it wants to be when it grows up.

The more work goes into it, the less it resembles another AI coding tool and the more it resembles that engineer who quietly fixes everything while asking uncomfortable questions about your architecture.

SubZeroDev.GitService​

Git Service should not pretend to be intelligent.

It should move repositories around, open pull requests, report status, and generally behave like competent infrastructure.

The AI can keep making questionable life choices somewhere else.

Blog Platform​

The blog somehow became:

• an engineering journal;
• a publishing workflow;
• architecture history;
• AI memory;
• and eventually another source of content.

It was supposed to be a website.

Project Status​

Major Milestones​

• AI stopped writing code and started writing content.
• Git became suspiciously close to being the deployment strategy.
• "I'll just make one small improvement" was once again proven to be fiction.

Conclusions Reached Entirely By Accident​

• Git solves more problems than expected.
• AI should generate structured data whenever possible.
• MCP keeps appearing in every architecture diagram whether invited or not.
• Every project eventually discovers another project hiding inside it.

Things That Got Out of Hand​

• Campaign generation.
• AI review agents.
• Trading automation.
• Blog automation.
• Story packs.

Scientists continue searching for the point where one project becomes seven.

Challenges​

Choosing what not to build.

So far this remains largely theoretical.

Project Statistics​

This journal focuses on why things happened.

For live repository statistics:

https://github.com/The-Running-Dev

Notable Quotes​

"The absence of a plan is the plan."

"We don't follow roadmaps. Roadmaps follow us."

"Content is data."

Next Priorities​

• Finish the campaign system.
• Expand the campaign library.
• Continue AgentKit.
• Keep refining Git Service.
• Resist creating three additional projects.

Looking Ahead​

Every week starts with a perfectly reasonable objective.

By Friday, I've accidentally built half a platform while insisting to myself that I was "just making one small change."

I'm no longer convinced I'm designing this ecosystem.

I think it's assembling itself and occasionally asking me to type.

I woke up to an email.

"After I was giving a lot of thoughts I have decided you can live in this place as long as you want..."

Well.

How extraordinarily generous.

Apparently, after what I can only imagine was an exhausting period of philosophical reflection, meetings with the council of elders, several consultations with legal scholars, and perhaps a brief audience with God Himself...

...a decision had finally been reached.

I am hereby permitted to continue doing exactly what I have been doing for the last month.

Thank you.

I don't know how I ever survived before this monumental proclamation.

The funniest part isn't even the email.

It's the implication that reality changed because someone declared it had.

As though the universe paused.

The birds stopped singing.

Lucifer looked up from his coffee.

"Father... what's happening?"

God checked His notes.

"Hold on."

He looked toward Earth.

"Someone just granted permission for an already existing fact."

Lucifer blinked.

"Can humans do that?"

God shrugged.

"Apparently they believe they can."

Meanwhile, I continued sitting in exactly the same chair I'd been sitting in yesterday.

The house remained where it was.

The walls didn't move.

The roof stayed attached.

The village carried on completely unaware that history had just been rewritten by email.

The entire episode reminds me how much unnecessary drama people create around situations that don't actually change.

Nothing happened.

Nothing needed to happen.

Yet somehow it was transformed into a profound act of generosity.

It's almost impressive.

The universe remained completely indifferent.

Lucifer, however, couldn't stop laughing.

"Father..."

"Yes?"

"Do you think I could email gravity and give it permission to continue working?"

God smiled.

"You can certainly try."

The absurdity continues.

One week and a couple of days.

That's all this has been.

I keep looking at the roadmap and laughing because it feels like I've been working on this project for months.

Then I look at the commit history.

Nope.

One week.

It started exactly how many ridiculous ideas seem to start these days.

I missed Jones in the Fast Lane.

So I asked an LLM how it worked.

That was a mistake.

The LLM happily explained:

• jobs;
• education;
• money;
• needs;
• schedules;
• relationships;
• random events.

Then...

it started suggesting implementation details.

That should have been the end of the conversation.

Instead, I asked one more question.

"If I'm already writing this... why would I write it for one game?"

That question refused to leave.

The Escalation​

The first day became:

Maybe I'll prototype this.

The second day became:

These mechanics should be reusable.

The third day became:

This needs deterministic state.

The fourth day became:

Kinds.

Campaigns.

Core.

Clients.

The fifth day became:

Well...

I apparently have a game engine now.

Then It Somehow Got Worse​

Because building software is apparently contagious.

While working on the engine I needed documentation.

Then I wanted a better documentation site.

Then I wanted automated publishing.

Then I wanted Git to become the source of truth.

Then I wanted AI to edit everything through MCP.

Then I wanted Discord notifications.

Then previews.

Then validation.

Then PR workflows.

At some point I accidentally built half of a publishing platform while supposedly working on a game engine.

Apparently ideas don't stay in their own projects anymore.

They contaminate each other.

The Roadmap​

Today I finished something I wasn't expecting.

Not another feature.

The roadmap.

Except...

it doesn't look like a roadmap.

It looks like a story.

Instead of this:

v0.4
- authentication
- replay
- content
- networking

it became this.

The engine learns the rules.

The first story survives contact with bureaucracy.

The past becomes testable.

A week of life becomes a machine.

The engine gets a front door, then a world state.

Somewhere along the way I realized something.

The roadmap wasn't documenting features.

It was documenting discoveries.

Every completed section is something the project has actually proven.

Not promised.

Proven.

Horizons, Not Promises​

One of my favorite sections ended up being the last one.

Horizons, not promises.

Because software roadmaps are usually fantasy novels.

Everything is "planned."

Everything is "coming soon."

Reality rarely agrees.

So instead I listed directions.

Things Future Me might build.

If Future Me still thinks they're good ideas.

Current Me has done his part.

Future Me has been notified.

Future Me has not replied.

Looking Back​

When I zoom out, the last week looks absurd.

In roughly seven days:

• the architecture was designed;
• the MVP was defined;
• almost all of it was implemented;
• the first kinds appeared;
• the landing page was built;
• the documentation became a story;
• the roadmap became a narrative;
• and somewhere in there I accidentally built the beginnings of a publishing platform too.

AI wrote a lot of code.

That's true.

But AI didn't decide what the architecture should become.

It didn't decide what deserved to become reusable.

It didn't decide that documentation should read like a story instead of a specification.

Those decisions still belonged to me.

AI simply removed an enormous amount of friction between idea and implementation.

The Funny Part​

The roadmap currently says:

44 Work Units

A week ago...

there wasn't even a project.

There was just one question.

"How does Jones in the Fast Lane actually work?"

Apparently that was enough.

Well...

Why not?

Then I thought I was building a note-taking platform.

Then I realized I wasn't really building either.

The blog and the notes are simply different workflows.

The actual product is something much larger.

A Git-native workflow platform.

The Observation

Every project I've started recently keeps converging on exactly the same architecture.

Whether it's:

• blog posts;
• documentation;
• personal notes;
• technical specifications;
• project planning;
• journals;
• cookbooks;
• knowledge bases;

they all follow nearly the same lifecycle.

Content
    ↓
Markdown
    ↓
Git
    ↓
Validation
    ↓
AI
    ↓
Workflow
    ↓
Output

The infrastructure barely changes.

Only the workflow does.

Git Is the Database

Instead of storing everything inside proprietary databases, applications, or cloud services:

Store everything as files.

Markdown.

JSON.

YAML.

Images.

Whatever makes sense.

Git already provides:

• history;
• synchronization;
• collaboration;
• branching;
• backups;
• offline support;
• versioning.

These are problems Git solved decades ago.

Most modern applications simply rebuild them.

MCP Becomes the API

Once the repository is exposed through MCP, it no longer matters which AI client you're using.

The repository becomes programmable.

Instead of opening applications, you ask for outcomes.

Examples:

Save this as a note.

Turn this note into a blog post.

Convert this blog post into a design document.

Generate implementation tasks.

Create GitHub issues.

Publish the documentation.

Each request triggers a workflow.

The Workflow Engine

Imagine the platform like this:

Git Repository
       │
       ▼
 Workflow Engine
       │
       ├── Blog Workflow
       ├── Notes Workflow
       ├── Wiki Workflow
       ├── Cookbook Workflow
       ├── Documentation Workflow
       ├── Journal Workflow
       ├── Specification Workflow
       ├── Knowledge Base Workflow
       ├── Meeting Notes Workflow
       └── Custom Workflows

Every workflow shares the same infrastructure.

• Git
• Markdown
• Templates
• AI
• Validation
• Search
• MCP
• Publishing

The workflow simply decides what happens next.

Blogging Is Just One Workflow

Idea
    ↓
Markdown
    ↓
Frontmatter
    ↓
Validation
    ↓
Git Commit
    ↓
Publish Website

Nothing special.

Notes Are Another Workflow

Voice Note
      ↓
Markdown
      ↓
Git Commit
      ↓
Search Index
      ↓
MCP Knowledge Base

Same infrastructure.

Different output.

Documentation

Specification
       ↓
Markdown
       ↓
Validation
       ↓
Documentation Build
       ↓
Website

Again...

Same platform.

Specifications

Concept
     ↓
Design Document
     ↓
Technical Specification
     ↓
GitHub Issues
     ↓
Implementation

Exactly the same pattern.

Recipes

Recipe
    ↓
Markdown
    ↓
Categorization
    ↓
Website
    ↓
Shopping List

Still the same platform.

Journals

Journal Entry
       ↓
Markdown
       ↓
Private Repository
       ↓
AI Summaries
       ↓
Timeline

Again...

No new infrastructure required.

Why This Matters

The difficult part isn't building blog software.

The difficult part isn't building note software.

The difficult part is building:

• Git integration
• Authentication
• Repository management
• Templates
• Validation
• Search
• AI orchestration
• MCP integration
• Publishing
• Permissions

Once those exist...

Creating another workflow is relatively inexpensive.

You're composing existing capabilities rather than building another application.

The Bigger Picture

This also changes how ideas evolve.

Instead of isolated applications:

Idea
 ↓
Note
 ↓
Blog
 ↓
Design
 ↓
Specification
 ↓
GitHub Issues
 ↓
Implementation
 ↓
Deployment
 ↓
Documentation Update

Every stage produces another Git artifact.

Each workflow simply transforms one artifact into another.

A Hosted Git Workflow Platform

This realization also changes the product itself.

Instead of selling:

• blogging software;
• note software;
• documentation software;

the platform becomes:

A hosted Git-native workflow engine with AI orchestration.

Blogging becomes one packaged workflow.

Notes become another.

Documentation another.

Customers could create entirely new workflows without changing the underlying platform.

The workflows become plugins.

The platform remains the same.

Looking Ahead

It's easy to imagine dozens of workflows eventually sharing the same infrastructure.

• Blog publishing
• Personal knowledge bases
• Company documentation
• Engineering specifications
• Product requirements
• Meeting notes
• Research notebooks
• Cookbooks
• Personal journals
• Project management
• AI memory repositories

All of them are fundamentally the same problem.

Take structured content.

Store it in Git.

Expose it through MCP.

Run workflows.

Everything else is simply configuration.

Final Thought

I started by trying to make writing blog posts easier.

Somewhere along the way, I accidentally stopped building applications.

I started building a platform where applications are simply workflows running on top of Git.

That feels like a much more interesting destination.

Right now people are connecting AI to GitHub.

Tomorrow it'll be GitHub, Notes, Calendar, Email, Docker, Kubernetes, Home Assistant, Finance, Media Servers, Documentation, Monitoring...

Everything.

Every service becomes another capability the AI can discover and use.

Need to publish a blog post?

The AI talks to the Blog MCP.

Need to find a design decision from six months ago?

The Notes MCP.

Need to restart a container?

The Docker MCP.

Need to check if a deployment succeeded?

The Kubernetes MCP.

Need to search twenty years of personal documentation?

The Knowledge MCP.

Individually, none of these are revolutionary.

Together, they become something entirely different.

Your tools stop being isolated applications.

They become capabilities that any AI client can orchestrate.

We're moving away from opening applications and toward telling an AI what we want to accomplish.

The applications don't disappear.

They become infrastructure.

The AI becomes the interface.

That's the part I don't think has fully sunk in yet.

People keep asking, "What can MCP do?"

I think that's the wrong question.

The better question is:

"What can't it connect to?"

Because once everything exposes an MCP server, things are going to get very interesting.

I've wanted to organize my notes for years. Like most developers, they're scattered everywhere:

• text files;
• OneNote;
• random Markdown documents;
• Discord messages;
• ChatGPT conversations;
• scraps of paper;
• and the occasional "I'll remember this later."

I never do.

Then I realized I already built most of the solution.

The Idea​

Instead of another note-taking application, make Git the source of truth.

Every note is simply a Markdown file stored in a repository.

The interface isn't a notes application.

The interface is MCP.

Instead of opening a program and deciding where something belongs, the interaction becomes natural:

"Save this as a note."

"Append this to today's development log."

"Add this to the Automator project."

"Store this as a future blog idea."

The MCP server handles everything else.

• Creates the Markdown file if necessary.
• Adds front matter.
• Organizes folders.
• Commits the changes.
• Pushes them to Git.
• Optionally opens a pull request.

The user never has to think about file management.

Repository Structure​

notes/
├── inbox/
├── daily/
├── projects/
├── ideas/
├── references/
└── archive/

Nothing exotic.

Just Markdown.

Just Git.

Why Git?​

Because Git already solves problems note applications keep reinventing.

• Version history
• Synchronization
• Branches
• Backups
• Offline editing
• Collaboration
• Pull requests
• Conflict resolution

Developers have trusted Git for decades.

Why shouldn't it manage knowledge too?

Where MCP Changes Everything​

The repository isn't just storage.

It becomes an AI knowledge base.

Expose the repository through an MCP server and suddenly every compatible AI client can ask questions about everything you've ever written.

Instead of browsing folders, you ask:

• "What ideas have I had about the Game Engine?"
• "Show every note mentioning RabbitMQ."
• "Summarize everything I know about local AI models."
• "Find every business idea involving subscriptions."
• "What decisions have I already made about my blog platform?"

Your notes stop being files.

They become searchable knowledge.

Even Better...​

This integrates perfectly with the GitOps blog workflow.

A simple pipeline could become:

Voice Note
      │
      ▼
Markdown File
      │
      ▼
Git Commit
      │
      ▼
MCP Knowledge Base
      │
      ▼
AI identifies blog-worthy content
      │
      ▼
Draft blog post
      │
      ▼
GitHub Pull Request
      │
      ▼
Review
      │
      ▼
Publish

Ideas naturally evolve into documentation.

Documentation evolves into articles.

Articles become published content.

Nothing is copied.

Nothing is rewritten.

Everything starts from the same Markdown file.

The Long-Term Vision​

Initially, this doesn't need anything complicated.

Just:

• Markdown
• Git
• An MCP server

That's enough to create a searchable personal knowledge base.

Later, additional capabilities can be layered on top:

• Full-text search
• Semantic vector search
• Automatic backlinks
• Related notes
• AI summaries
• Cross-project references
• Automatic blog post suggestions

Each feature builds on the same foundation.

A Pattern Emerging​

This is the same pattern appearing across nearly every project I'm building.

Git becomes the source of truth.

MCP becomes the interface.

The application becomes optional.

Whether it's a blog, documentation, notes, specifications, or project ideas, they're all just repositories that AI can understand.

Perhaps the most interesting realization is that I wasn't trying to build a note-taking application at all.

I was accidentally building a personal knowledge operating system.

Git repository.

ArgoCD.

Flux.

Terraform.

Infrastructure.

That's where the term became popular.

But I think we're quietly entering a much bigger era.

Git Is Becoming the Universal Source of Truth​

For years my workflow looked like every other developer's:

Laptop
    ↓
IDE
    ↓
Git
    ↓
CI
    ↓
Production

Nothing unusual.

But over the past few weeks, something changed.

Not because of a new programming language.

Not because of a new framework.

Because of AI.

My Phone Is Now a Development Console​

Today I can pull out my phone.

Open ChatGPT.

Select my custom development assistant.

Tell it:

"Pull this repository and add this feature."

The AI can:

• clone the repository;
• understand the architecture;
• make the change;
• create a commit;
• open a pull request;
• let CI validate everything;
• and deploy the result.

Meanwhile I'm standing in a supermarket.

Or walking the dog.

Or drinking coffee.

My phone isn't editing code.

It's dispatching engineering work.

That feels like a surprisingly fundamental shift.

The New Workflow​

The old workflow looked like this:

Phone
    ↓
Remote Desktop
    ↓
Laptop
    ↓
IDE
    ↓
Git

Now it increasingly looks like this:

Phone
    ↓
AI Agent
    ↓
GitHub
    ↓
Pull Request
    ↓
CI
    ↓
Production

GitHub has become the operating system.

The repository is the source of truth.

Everything else is automation.

GitOps for Everything​

This realization changed how I've started designing my own tools.

Instead of building applications that own data, I build applications that automate repositories.

The repository already contains:

• source code;
• documentation;
• blog posts;
• infrastructure;
• configuration;
• workflows.

Why duplicate it?

Instead, automate around it.

That idea led me to a new platform concept.

Imagine connecting your GitHub account.

Clicking Create Blog.

Five minutes later you have:

• a repository;
• Docusaurus configured;
• CI/CD;
• GitHub Actions;
• Cloudflare Pages;
• SEO;
• search;
• RSS;
• AI instructions;
• an MCP server;
• a REST API;
• and a local CLI.

The repository belongs to you.

The platform simply builds it.

Multiple Interfaces, One Repository​

Once Git becomes the source of truth, every interface becomes interchangeable.

You can publish from:

• a web UI;
• a CLI;
• an MCP server;
• a REST API;
• a local file watcher;
• or directly from Git.

They're all doing the same thing:

Creating commits.

Everything else is just a different front end.

AI Changes the Economics​

This is where it becomes really interesting.

Developers have spent decades building tools that humans operate.

Now we're building tools that AI operates.

Instead of designing a beautiful interface for clicking buttons, we design clean APIs, good specifications, deterministic workflows, and safe automation.

Humans become supervisors.

AI becomes the operator.

The Repository Is the Product​

One lesson I've learned while building these tools is surprisingly simple:

Don't own the customer's content.

Own the automation.

If someone stops using my platform, they should still have:

• their repository;
• their history;
• their Markdown;
• their CI;
• and their infrastructure.

No lock-in.

Just convenience.

Ironically, I think that's what makes people more willing to trust a platform.

Where This Is Going​

A few years ago the idea of deploying production software from your phone sounded absurd.

Today it isn't.

The phone isn't the computer anymore.

It's the command console.

The real work happens somewhere else:

GitHub.

AI agents.

CI pipelines.

Automation.

GitOps started as a way to manage infrastructure.

I think it's quietly becoming a way to manage everything.

Chocolate is the dominant flavour, mint is the cool finish — ratio reflects that.

Instructions​

1. Chop​

Chop the tobacco to short shisha-length strands. A few passes with a knife or a brief pulse in a food processor. Aim for short pieces, not powder.

2. Wash​

• Place chopped tobacco in a bowl, cover with cold water
• Stir, let sit 5–10 minutes, drain through a fine mesh strainer or cheesecloth
• Repeat 2–3 times until the water runs noticeably lighter/clearer
• Final rinse with clean cold water

3. Drain & Dry​

• Drain well and pat loosely with paper towel
• Let air dry for 30–60 minutes until just damp — like slightly moist tea leaves
• Do not oven dry at this stage

4. Mix​

• In a small bowl, combine molasses, glycerin, chocolate extract, and mint extract
• Stir until fully blended
• Pour over the tobacco and work through evenly with your hands or a fork, coating every strand

5. Bake In​

• Wrap the mixed tobacco loosely in foil (not airtight — let some steam escape)
• Oven at 100–120°C (210–250°F) for 20–30 minutes
• This caramelises the molasses and drives the flavours into the leaf

6. Cool & Rest​

• Let cool completely before opening the foil
• Transfer to a zip-lock bag or airtight jar
• Rest for at least 24 hours, ideally 48 hours

Tips​

• Molasses: Light molasses is closer to commercial blends. Blackstrap is stronger and more bitter.
• Glycerin: Gives thick, juicy smoke. Stay in the 12–16% range of tobacco weight — too much turns harsh.
• Extracts: Food-grade flavour oils (e.g. LorAnn brand) give a more authentic, longer-lasting result if you want to upgrade in the future.
• Packing: Pack loosely in the bowl and don't let the foil or heat management device touch the tobacco directly — this is a juicy blend.
• Adjust after resting: If mint is too subtle, add a drop more mint extract, mix, and rest another few hours. If it feels dry, work in a touch more glycerin.

1. Meditations — Marcus Aurelius (Hammond / Penguin Classics)
   Why: Private field notes of a man carrying absolute responsibility; moral calibration without preaching.
   Listen profile: 🔁 Re-listen for life (short, dense, different book each decade).

2. The Enchiridion & Discourses — Epictetus
   Why: The operating system of Stoicism; control, responsibility, agency, no metaphysics fluff.
   Listen profile: 🔁 Re-listen in fragments; reference-grade material.

3. Letters from a Stoic — Seneca
   Why: Stoicism applied to money, anger, politics, time, and compromise; human and imperfect.
   Listen profile: 🔁 Re-listen selectively; letters work as stand-alone meditations.

Cognition, Risk, Meaning (reality correction)​

4. Thinking, Fast and Slow — Daniel Kahneman
   Why: Explains why intelligence does not protect against error; essential for judgment, investing, systems.
   Listen profile: 🔁 Re-listen in parts; concepts deepen with repetition.

5. Antifragile — Nassim Nicholas Taleb
   Why: Optionality, convexity, stress as signal; aligns with real-world uncertainty better than any model.
   Listen profile: 🔁 Re-listen; framework book, not narrative.

6. Man’s Search for Meaning — Viktor Frankl
   Why: Meaning under extreme constraint; existential clarity without mysticism or sentimentality.
   Listen profile: 🔁 Short, powerful; re-listen when perspective drifts.

Science Fiction — intelligence, systems, consequences​

7. Hyperion — Dan Simmons
   Why: Structured, philosophical sci-fi; faith, AI, suffering, destiny examined seriously.
   Listen profile: 🔁 Re-listen; layers reveal themselves over time.

8. The Forever War — Joe Haldeman
   Why: The sober counterweight to Heinlein; time dilation, war, alienation, cost of obedience.
   Listen profile: 🔁 Re-listen; perspective shifts with age.

9. Blindsight — Peter Watts
   Why: Intelligence without consciousness; brutal, evolutionary, uncompromising systems sci-fi.
   Listen profile: 🔁 Re-listen required; comprehension improves each pass.

10. Roadside Picnic — Arkady & Boris Strugatsky
    Why: Alien logic, human limitation, ambiguity without exposition; Eastern-bloc gravity.
    Listen profile: 🔁 Re-listen; meaning emerges through reflection.

Dark / Moral Gray (optional but aligned)​

11. Night Watch — Sergei Lukyanenko
    Why: Bureaucracy, power, compromise, moral ambiguity; systems of “good” and “evil” under constraint.
    Listen profile: ➿ One full listen, optional re-listen depending on resonance.

Notes​

• All titles support multiple listens and later text reading.
• No genre padding, no pop-philosophy, no irony-first fiction.
• This library favors competence, consequence, systems, and moral weight.

Core Concept​

A philosophical-absurdist narrative series where Neo is awake, aware, and completely uninterested in saving the world.

He does not fight the system. He plays with it.

The system isn’t defeated—it’s gently humiliated.

Tone​

• Dry
• Playful
• Observational
• Unsentimental
• Amused, not angry
• No preaching, no moralizing

Serious ideas are introduced only to be deflated.

Central Thesis (Unstated)​

The system can handle enemies. It cannot handle people who refuse to take it seriously.

Characters​

Neo​

• Fully awake.
• No messiah complex.
• Refuses missions.
• Leaves scenes early.
• Answers questions accurately but uselessly.
• Uses absurd compliance and boredom as escape mechanisms.

Lucifer (Recurring Visitor)​

• Not evil, not tempter.
• Cosmic heckler / commentator.
• Breaks the fourth wall casually.
• Appears without explanation, leaves mid-sentence.
• Exists to de-dramatize everything.

The Agents​

• Hyper-serious.
• Rule-bound.
• Increasingly confused.
• Chasing Neo for paperwork, categorization failures, and unresolved tickets rather than rebellion.

Guest Appearances​

• Marcus Aurelius: Stoic emperor who keeps reminding everyone that none of this is worth getting upset about.
• Alan Watts: Laughs mid-explanation, points out the joke, vanishes.

Format Options​

• Short blog posts (500–1,000 words)
• Micro-essays
• Dialogues
• Comic strips
• One-off vignettes
• Non-linear, episodic, discontinuous

Continuity is optional. Contradictions are allowed.

Recurring Themes​

• Absurdity over rebellion
• Play over seriousness
• Agency without domination
• Rules followed literally until they collapse
• Freedom through non-cooperation
• Awakening without obligation

Example Episode Seeds​

• Neo attends a mandatory meeting and asks sincere but irrelevant questions until the meeting dissolves.
• Lucifer congratulates Neo for choosing the wrong door on purpose.
• An Agent files a report that cannot be categorized.
• Neo pays for coffee with obsolete currency and leaves before the receipt prints.
• Marcus Aurelius reminds an Agent that this is outside their control.

Creative Rules​

• Write for your own amusement first.
• No obligation to finish anything.
• Forget it. Rediscover it later.
• Let humor emerge naturally.
• No explanations unless they’re funny.
• Nothing is sacred.

Purpose​

None required.

If others read it, fine. If not, irrelevant.

The act of creation is the point.

This page is not demanding.
It’s symmetrical.

I don’t ask for anything I don’t give.

I Expect Honesty​

Say what you mean. Mean what you say. If something isn’t working, say so.

I don’t punish clarity. I rely on it.

I Expect Curiosity​

You don’t have to know everything. You do have to care.

Ask questions. Challenge assumptions. Stay interested longer than is comfortable.

That’s where the good stuff is.

I Expect Ownership​

If you take something on:

• see it through,
• surface problems early,
• don’t outsource responsibility.

Mistakes are fine. Avoidance is not.

I Expect Adult Communication​

I don’t do:

• passive aggression,
• politics,
• or indirect signaling.

If there’s tension, we talk. If there’s disagreement, we explore it. If there’s a decision, we make one.

I Expect Mutual Respect​

Not hierarchy. Not deference. Not performative politeness.

Respect looks like:

• listening,
• not interrupting,
• and assuming competence by default.

I Expect Space to Think​

I don’t operate well in environments where:

• urgency is constant,
• interruptions are the norm,
• and reflection is treated as laziness.

If everything is always on fire, something upstream is broken.

I Expect You to Say “No” Sometimes​

Blind agreement is not collaboration. Pushback is healthy. Boundaries matter.

If you never disagree with me, something is wrong.

What I Don’t Expect​

I don’t expect:

• perfection,
• certainty,
• or endless availability.

I don’t expect you to:

• impress me,
• keep up appearances,
• or be anything other than yourself.

What This Page Is Really About​

This is not about standards. It’s about fit.

If reading this felt:

• reasonable,
• grounding,
• or reassuring,

we’ll probably work well together.

If it felt:

• heavy,
• demanding,
• or uncomfortable,

that’s useful information too.

Alignment beats talent.
Every time.

This page exists so we don’t have to learn that the hard way.

This page exists to save us both time.

If you’re still reading after this, we’re probably fine.

I’m Not a “Rockstar”​

I don’t:

• chase hype,
• burn out for applause,
• or confuse noise with impact.

I build things that work.
Quietly.
Relentlessly.

If you’re looking for:

• performative brilliance,
• hustle theater,
• or ego-driven chaos,

you won’t find it here.

I’m Not a Framework Evangelist​

I don’t marry tools.
I don’t defend stacks.
I don’t argue religion.

I use:

• whatever fits the problem,
• whatever bends without breaking,
• whatever lets the system keep moving.

If your culture needs:

• ideological purity,
• tool worship,
• or dogma over outcomes,

this will be uncomfortable.

I’m Not Junior (and I’m Not Interested in Pretending)​

I don’t need:

• micromanagement,
• step-by-step instructions,
• or permission to think.

I don’t thrive in environments where:

• initiative is punished,
• curiosity is contained,
• or “stay in your lane” is policy.

If you need someone to:

• wait for tasks,
• color inside the lines,
• or execute without context,

I’m not your person.

I’m Not a Resume Bullet Factory​

I don’t optimize for:

• titles,
• promotions,
• or internal optics.

I optimize for:

• leverage,
• momentum,
• and systems that don’t get stuck.

If success in your org is measured by:

• slide decks,
• meeting density,
• or who talks the most,

we will frustrate each other.

I’m Not a Safe Bet​

I will:

• question assumptions,
• test boundaries,
• and notice gaps early.

Sometimes this looks like:

• being “ahead of the rubric,”
• making people uncomfortable,
• or exposing brittle systems.

If you want:

• predictability over progress,
• comfort over truth,
• or compliance over curiosity,

this is your exit.

No hard feelings.

I’m Not Here to Be Everything​

I don’t claim to:

• know everything,
• solve everything,
• or be right all the time.

I do claim to:

• engage honestly,
• adapt quickly,
• and keep moving when things get hard.

If you need certainty, guarantees, or final answers —
I don’t have them.

I have patterns.

What This Page Is Actually Saying​

This is not exclusionary.
It’s clarifying.

If you read all of this and felt:

• relieved,
• seen,
• or quietly energized,

we should probably talk.

If you felt:

• defensive,
• irritated,
• or the urge to “correct” me,

we definitely shouldn’t.

This isn’t arrogance.
It’s alignment.

I’ve learned the hard way that mismatches cost more than honesty.

Welcome — or goodbye.
Both are acceptable outcomes.

This is not a methodology.
It’s a pattern.

If you need a framework, borrow one.
If you need guarantees, look elsewhere.

This is how things actually get done around me.

I Start With Understanding, Not Tasks​

Before I build anything, I want to know:

• what problem we’re actually solving,
• what constraints are real,
• what assumptions are inherited,
• and what nobody is saying out loud.

If I don’t ask questions early, something will break later.
Usually in production.

I Work Iteratively, Not Theoretically​

I don’t design in isolation. I don’t wait for perfection. I don’t confuse planning with progress.

I prefer:

• small, real increments,
• fast feedback,
• visible artifacts.

Working code beats elegant intent every time.

I Move Fast — But I Don’t Rush​

Speed comes from:

• clarity,
• experience,
• and knowing what not to do.

I don’t cut corners. I cut waste.

If something feels slow, I look for:

• friction,
• redundancy,
• or unnecessary ceremony.

I Read Systems, Not Just Requirements​

I pay attention to:

• how people behave under pressure,
• where processes silently fail,
• and which systems pretend to be robust.

I notice patterns early. Sometimes uncomfortably early.

This is usually where “ahead of the rubric” shows up.

I Don’t Get Stuck​

When something blocks progress, I:

• try another angle,
• test the boundary,
• or build a temporary bridge.

I don’t wait indefinitely. I don’t escalate theatrically. I don’t freeze.

Momentum matters.

I Prefer Autonomy With Accountability​

I work best when:

• expectations are clear,
• outcomes matter more than optics,
• and I’m trusted to think.

I will:

• own my decisions,
• admit when I’m wrong,
• and adjust quickly.

What I won’t do:

• pretend certainty,
• hide mistakes,
• or optimize for appearances.

I Communicate Directly​

I don’t:

• posture,
• sugarcoat,
• or weaponize ambiguity.

I do:

• say what I see,
• explain my reasoning,
• and listen when challenged.

Disagreement is fine. Silence is not.

How This Usually Feels​

Early on:

• “This person asks a lot of questions.”

Later:

• “How did this get solved so fast?”

Eventually:

• “We should have done this sooner.”

That pattern is familiar.

This is not intensity.
It’s engagement.

If you want motion without drama, this tends to work very well.

This section has no end.
It exists to document pattern, not exhaust it.

1996–1997 — The Rubric Incident​

• Built a C++ music library manager as a high-school final project.
• ~100 pages of printed source code.
• Penalized for “not enough comments.”
• Received an award anyway.
• Learned the rules were not about outcomes.

1997–2005 — The Suspicious Website​

• Built a full online portfolio before such things were normal.
• Projects, screenshots, CV, contact form.
• Still exists.
• Still valid HTML.
• Still confusing to people who think this is new.

2000–2001 — The Wizard That Shouldn’t Exist Yet​

• Built a Perl/CGI website-generation wizard for university faculty.
• Functionally similar to tools that appeared years later.
• Loved by users.
• Politely ignored by academia.

2005–2010 — The File System State Machine​

• Invented a watch-directory workflow using file extensions as state.
• No database.
• Later patented.
• Multiple names added.
• None were mine.

2010–2018 — The YAML Incident​

• Entered an org with ~400 GUI-configured pipelines.
• Replaced them with YAML.
• Triggered architectural reviews.
• Learned scale can be emotionally threatening.

2018 — The “You Can Do That?” Moment​

• Built request-blocking WebAPI filters before controllers executed.
• Checked Kubernetes cluster health pre-request.
• Revealed undocumented assumptions in the system.

Ongoing — The Recruiter Disbelief Loop​

• CV flagged as “too much.”
• Accused of exaggeration.
• Pattern repeats.
• Signal remains unchanged.

This list will grow. Not because I’m collecting trophies, but because this keeps happening.

Ahead of the rubric isn’t an identity. It’s an occupational hazard.

I am not special.
I just kept engaging.
Repeatedly.
For decades.

This wasn’t a phase.
This pattern will repeat.

Origin Story (Sidebar)​

This is where it started.

In 1996–1997, my high-school C++ class assigned a final project.
Everyone had to build something.

I built a music library management system.

It took months.
It had real data structures.
It actually worked.

When submission time came, the teacher insisted on printing all source code.
Mine was just under 100 pages.

Physically stacked.
Audibly intimidating.

I received a 95.

Points were deducted for “not enough comments.”

That was my first lesson in how institutions reward effort.

I later received an award for exceptional student from the same class.
Apparently excellence was real — just not enough for a perfect score.

The following year at university, we used the same C++ textbook.
I aced everything without trying.
The professor asked me to help other students.

Turns out I wasn’t bad at C++.
I was just ahead of the rubric.

Keep that phrase in mind. It comes back.

Section I — Early Damage​

1992–1996: Childhood Was a Configuration Error​

• Learned to program on a Sinclair ZX81 clone (Soviet edition).
  • 48KB RAM
  • Programs loaded from cassette tapes
  • Silence where the internet should have been
• Built Tic-Tac-Toe in monochrome Quick BASIC.

It worked.
Dopamine unlocked.

In retrospect, an adult should have intervened.

Section II — The Web, Before It Was a Career​

1997–2005: Suspicious Behavior​

• Built an online portfolio using Dreamweaver.
  • Projects
  • Screenshots
  • CV
  • Contact form

This was:

• before LinkedIn,
• before “personal branding,”
• before anyone thought this was normal.

I still have it.
Somewhere.
Fossilized.
Still valid HTML.

Back then, having a website meant you were either dangerous or unemployed.
Sometimes both.

Again: ahead of the rubric.

Section III — Academia, Briefly​

2000–2001: University, But Make It Useful​

• Worked for the Alfred University Web Team.
  • Everything in ColdFusion.
  • And yes — it was glorious.
• Built real production systems while others wrote theory papers.

Final Computer Science project:

• Web Site Development Wizard
• A Perl / CGI single-page app
• Faculty entered:
  • text,
  • colors,
  • layouts
• Script generated complete websites automatically.

This was before:

• Squarespace
• Wix
• WordPress
• “No-code” became a religion

Faculty loved it.
Academia nodded politely.
The industry reinvented it later and called it innovation.

Nobody asked me to do this.
I just noticed the gap.

Ahead of the rubric. Again.

Section IV — Video, Pain, and Poor Life Choices​

2005–2010​

• Built a video CMS installer.
  • Reduced install time from 6 hours to 30 minutes.
• Wrote a service using mplayer to extract frames from any video format known to man.
  • This was easier than it sounds.
  • Which should concern you.
• Built Prototype.js / Scriptaculous plugins for video embedding.
  • Early YouTube vibes.
  • Emotional damage guaranteed.
• Invented a watch-directory processing system.
  • File system as state machine
  • No database
  • Patented later
  • Six other people added their names
  • Naturally.

You’d think this was the peak.
It wasn’t.

Still ahead of the rubric.
Now the rubric was just running to catch up.

Section V — CI/CD Before It Was Fashionable​

2010–2018​

• Loved CruiseControl.NET.
  • Still do.
• Built adapters that:
  • drove office TVs,
  • played sounds,
  • made builds performative.
• Joined a company with:
  • 60 developers
  • 8 teams
  • ~400 GUI Azure DevOps pipelines
• Replaced them with YAML.

Result:

• Architecture review
• Manager
• Division head
• Confusion

“Wait… you can do this?”
“…you couldn’t?”

Ahead of the rubric — and apparently the org chart.

Section VI — “It’s Just an API”​

2018–Present​

• Built ASP.NET WebAPI filters that ran before controllers.
  • Checked Kubernetes cluster health
  • Blocked requests preemptively

Reaction:

“You can do that??”

Me:

“Once you know the contract…”

This is where most people discover limits.
I discovered curiosity.

Section VII — Side Quests & Accidental Audits​

• Opened GitKraken’s source, found a bug, reported it.
  • Found a banner saying:

    “If you’re reading this, apply.”

  • Applied.
• Applied to a VR store.
  • Noticed no WinGet package
  • Built one
  • Submitted it
  • Then applied
• They offered €50k.
  • I declined.
  • That was a 2004 salary.

This is usually the point where people ask if I’m exaggerating.

I’m not.
I was just early. Again.

Constants (a.k.a. The Pattern)​

• I don’t read the docs first.
• I don’t get stuck.
• I forget more systems than most people build.
• When someone says:

  “You can’t do that” My internal response is: “Hold my beer.”

Closing​

None of this makes me special.

It just means I kept moving.
Sometimes broken.
Sometimes tired.
Sometimes furious.

Never resigned.

Ahead of the rubric isn’t a boast.
It’s a diagnosis.

This page is for people.
Not systems.
Not filters.
Not checklists.

If you’re looking for:

• a keyword match,
• a linear career path,
• or a tidy progression of titles,

this is not for you.

If you’re curious how someone ends up:

• building systems before they’re fashionable,
• confusing recruiters,
• and outgrowing rubrics faster than institutions can update them,

keep reading.

The Short Version​

I build things.

Not because I’m special.
Not because I planned it.
Not because it was a career move.

I just kept engaging.

When something felt rigid, I tested it.
When someone said “you can’t,” I checked the contract.
When a system got stuck, I didn’t.

This has been happening since:

• cassette tapes were storage,
• “having a website” was suspicious,
• and CI/CD didn’t have a name yet.

The pattern has a name now:

Ahead of the rubric.

What That Actually Means​

“Ahead of the rubric” doesn’t mean smarter.
It means misaligned with evaluation systems.

It looks like:

• building the thing before the assignment exists,
• solving the problem before the role is defined,
• being penalized for depth,
• then quietly validated later when the world catches up.

This has happened:

• in school,
• in universities,
• in companies,
• in tooling,
• in architecture,
• repeatedly.

You can read the full origin story here:
→ Ahead of the Rubric — The Full Timeline

What I’m Good At (Without the Buzzwords)​

• Seeing gaps early.
• Building systems that don’t get stuck.
• Making tools do things they weren’t “meant” to do.
• Translating curiosity into working code.
• Operating comfortably where structure hasn’t arrived yet.

I don’t optimize for:

• titles,
• prestige,
• or looking impressive on paper.

I optimize for:

• momentum,
• leverage,
• and systems that keep moving.

How to Read the Rest of This Site​

• If you want the story → read the timeline.
• If you want receipts → skim the incidents.
• If you want certainty → you won’t find it here.
• If you want signal → you probably already see it.

This is not a success story.

It’s a persistence one.

Welcome.

Should I use docker run, or should I use Docker Compose?

The practical answer is simple:

• Use docker run when you want to start one container quickly
• Use Docker Compose when you want to define and manage one or more containers as a reusable setup

You can think of it like this:

• docker run = one command, typed by hand
• docker compose = a saved recipe in a docker-compose.yml file

When to use each one​

Visual difference​

flowchart LR
    A[docker run] --> B[One command typed manually]
    B --> C[One container starts]

    D[docker compose] --> E[YAML file defines services]
    E --> F[One command starts full stack]

Install Docker Compose​

If you installed Docker Desktop, Compose is already included as docker compose.

If you want to install it explicitly:

winget install -e --id Docker.DockerCompose

Verify:

docker compose version

Simple example with docker run​

docker run -d `
  --name my-nginx `
  -p 8080:80 `
  --restart unless-stopped `
  nginx

Parameters explained​

• -d → run in background
• --name → container name
• -p → port mapping (host:container)
• --restart → restart policy
• nginx → image

Open: http://localhost:8080

Same setup with Docker Compose​

services:
  nginx:
    image: nginx
    container_name: my-nginx
    ports:
      - "8080:80"
    restart: unless-stopped

Run:

docker compose up -d

Why Compose is better here​

• No need to remember long commands
• Easy to edit and reuse
• Shareable config
• Cleaner structure

Advanced example — Portainer (docker run)​

docker volume create portainer_data

docker run -d `
  --name portainer `
  -p 9000:9000 `
  --restart always `
  -v /var/run/docker.sock:/var/run/docker.sock `
  -v portainer_data:/data `
  portainer/portainer-ce

Parameters explained​

• docker volume create → persistent storage
• -v host:container → mount volume
• /var/run/docker.sock → allows Portainer to control Docker
• portainer_data:/data → saves app data
• --restart always → auto restart

Same Portainer setup with Docker Compose​

services:
  portainer:
    image: portainer/portainer-ce
    container_name: portainer
    ports:
      - "9000:9000"
    restart: always
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - portainer_data:/data

volumes:
  portainer_data:

Run:

docker compose up -d

docker compose commands​

Start​

docker compose up

Start (background)​

docker compose up -d

Stop & remove​

docker compose down

Remove including volumes​

docker compose down -v

Restart​

docker compose restart

Stop only​

docker compose stop

Start stopped services​

docker compose start

Status​

docker compose ps

Logs​

docker compose logs

Follow logs​

docker compose logs -f

Pull updates​

docker compose pull

Rebuild​

docker compose up --build

Force recreate​

docker compose up -d --force-recreate

Remove orphan containers​

docker compose up -d --remove-orphans

Restart policies​

In docker run:

--restart always

In Compose:

restart: always

Types​

• no
• always
• unless-stopped
• on-failure

Final takeaway​

• Use docker run for quick tests
• Use Docker Compose for anything you want to keep

That’s the real difference.

We’ll cover:

• What Docker is (in plain English)
• Setting up WSL (required)
• Installing Docker Desktop using winget
• Running your first container
• Using Portainer as a visual UI
• Core concepts you actually need

🧠 What is Docker (and why should you care?)​

Docker lets you run applications in containers — lightweight, isolated environments that include everything the app needs to run.

Instead of:

"It works on my machine"

You get:

"It works anywhere Docker runs"

🧱 How Docker Works (Simplified)​

flowchart LR
    A[Your App] --> B[Docker Container]
    B --> C[Docker Engine]
    C --> D[WSL2 Linux Kernel]
    D --> E[Windows 11]

Key idea:

• Docker uses Linux under the hood
• On Windows → this is handled by WSL2

⚙️ Step 1 — Install WSL (Windows Subsystem for Linux)​

Docker Desktop depends on WSL.

Run this in PowerShell (Admin):​

wsl --install

This will:

• Enable WSL
• Install a Linux distro (usually Ubuntu)
• Set WSL2 as default

Then restart your PC​

Verify WSL is working:​

wsl --status

You should see:

• Default Version: 2

🐳 Step 2 — Install Docker Desktop using Winget​

Run:​

winget install -e --id Docker.DockerDesktop

After installation:​

1. Launch Docker Desktop
2. Accept the license
3. Let it finish setup (it may restart WSL)

Verify Docker is running:​

docker --version

🚀 Step 3 — Run Your First Container​

Let’s run the classic test:

docker run hello-world

What just happened?​

sequenceDiagram
    participant You
    participant Docker
    participant DockerHub
    participant Container

    You->>Docker: run hello-world
    Docker->>DockerHub: download image
    DockerHub-->>Docker: image returned
    Docker->>Container: start container
    Container-->>You: success message

If everything worked, you’ll see:

"Hello from Docker!"

📦 Step 4 — Understanding Basic Concepts (No fluff)​

🔹 Image​

A template for a container Example: nginx, postgres, hello-world

Think:

Blueprint

🔹 Container​

A running instance of an image

Think:

A live app created from the blueprint

🔹 Docker Hub​

Public registry where images live

🔹 Volume​

Persistent storage for containers

Without volumes:

Data disappears when container stops

🧰 Step 5 — Install Portainer (Visual UI for Docker)​

Portainer gives you:

• Web UI
• Container management
• Logs, stats, configs

Option A — Docker Desktop Extension (Easiest)​

1. Open Docker Desktop
2. Go to Extensions Marketplace
3. Search for Portainer
4. Click Install

Option B — Run Portainer manually​

docker volume create portainer_data

docker run -d `
  -p 9000:9000 `
  --name portainer `
  --restart=always `
  -v /var/run/docker.sock:/var/run/docker.sock `
  -v portainer_data:/data `
  portainer/portainer-ce

Access Portainer​

Open: http://localhost:9000

How Portainer Fits In​

flowchart LR
    A[You] --> B[Portainer UI]
    B --> C[Docker Engine]
    C --> D[Containers]

⚡ Quick Example — Run a Web Server​

docker run -d -p 8080:80 nginx

Then open: http://localhost:8080

🧭 Final Mental Model​

• Docker = runtime
• Image = blueprint
• Container = running app
• WSL = Linux layer on Windows

✅ You're Done​

You now have:

• Docker running on Windows 11
• Your first container executed
• A UI (Portainer) to manage everything

That’s Docker.

Again.

He wasn't angry.

He looked...concerned.

"Ben."

"Yeah?"

"I thought you were building a game engine."

"I am."

"Then why did you spend half the week building a blogging platform?"

"So I could write about building the game engine."

Lucifer nodded slowly.

"Reasonable."

He paused.

"Why did you then build an API for the blogging platform?"

"So I don't have to open GitHub."

"Naturally."

Another pause.

"Then why did you build an MCP server?"

"So AI can publish the blog."

Lucifer pinched the bridge of his nose.

"Of course."

It Started Innocently​

Like all dangerous projects.

I wanted a blog.

Not WordPress.

Not Medium.

Not some SaaS that decides next Tuesday my account violates paragraph 14, subsection C.

Just Markdown.

Git.

GitHub.

Docusaurus.

Simple.

Write.

Commit.

Push.

Done.

Then I Got Lazy​

Opening GitHub is exhausting.

You have to...

• create a file;
• remember the naming convention;
• copy front matter;
• check tags;
• preview it;
• commit it;
• wait for CI;
• hope you didn't forget a colon somewhere.

This is at least thirty-seven seconds of completely unnecessary human involvement.

Unacceptable.

Version Two​

So naturally...

I built an API.

Now instead of opening GitHub...

I send Markdown.

API creates the file.

Done.

Lucifer watched quietly.

"You're still writing the Markdown."

"Correct."

"I don't like where this is going."

Version Three​

Now Claude and ChatGPT can generate the Markdown.

API publishes it.

CI builds it.

Cloudflare serves it.

Humans are becoming increasingly optional.

Version Four​

Then I thought...

"Why does the AI need to call an API?"

That's ridiculous.

So...

I added an MCP server.

Now the AI can simply say:

"Publish this."

The tooling figures out the rest.

Lucifer looked up toward Heaven.

"Father..."

"Yes?"

"He's teaching the machines how to write documentation."

God smiled.

"Excellent."

Lucifer frowned.

"You don't sound worried."

Then Something Weird Happened​

I wrote a blog post.

ChatGPT converted it into my usual Lucifer voice.

Added Docusaurus front matter.

Generated the Markdown.

I pasted it into my repository.

Committed.

Pushed.

Thirty seconds later...

It was live.

On the public internet.

I sat there for a second.

Not because the AI wrote it.

That's almost expected now.

Because I realized...

The writing wasn't the difficult part anymore.

The entire pipeline had disappeared.

The Real Project Was Never the Blog​

The blog was just an excuse.

The real project became reducing friction.

First:

Idea
↓

Open editor
↓

Write
↓

Format
↓

Create file
↓

Copy front matter
↓

Commit
↓

Push
↓

Wait
↓

Publish

Now:

Idea
↓

Talk to AI
↓

Commit
↓

Done.

Soon it'll become:

Idea
↓

"Publish."
↓

Done.

This Is the Interesting Part​

Everyone keeps asking whether AI writes code.

Wrong question.

The interesting question is:

How many tiny pieces of friction can disappear?

Every individual improvement saves almost nothing.

Five seconds here.

Thirty seconds there.

A minute somewhere else.

None of them matter.

Until one day...

You realize an idea became a published article before your coffee cooled down.

The Funny Part​

This whole thing has become self-reinforcing.

I build tools.

The tools help me build better tools.

Those tools help me write about the tools.

The blog documents the tools.

The documentation becomes instructions for AI.

The AI improves the tools.

Repeat.

It's a feedback loop powered almost entirely by curiosity.

Lucifer stared at the whiteboard.

There were arrows everywhere.

Boxes.

Containers.

Agents.

Discord webhooks.

GitHub Actions.

MCP servers.

Docker.

CI.

Blogs.

Notifications.

He looked at me.

"Do you actually have a plan?"

I thought about it.

"Not really."

"Then how did all this happen?"

I shrugged.

"It seemed like the next obvious step."

Lucifer sighed.

Then smiled.

"I hate how often that works."

And somewhere in the distance...

Another side project was already being born.

God looked up.

"What's that?"

Lucifer sighed.

"A policy."

God frowned.

"A policy?"

"Yes. Apparently humans have reached the stage where they ask their most expensive reasoning model to rewrite Markdown."

God blinked.

"...they do?"

Lucifer dropped the clipboard on the desk.

"Oh yes."

He flipped through several pages.

"Yesterday I watched someone spend the equivalent of a senior architect's brainpower deciding whether a bullet point should end with a period."

God closed His eyes.

Lucifer continued.

"Another one asked the smartest model available to generate a commit message."

Silence.

"...the commit was literally 'Fixed typo.'"

God rubbed His temples.

Lucifer looked exhausted.

"Father..."

"Yes?"

"I don't think they're intentionally wasting intelligence."

God nodded.

"No."

"I think they simply don't know when to stop thinking."

Lucifer took another page from the stack.

The Official AI Model Selection Policy​

GPT-5.6 Sol​

The expensive genius.

Use Sol when the problem actually requires someone to sit in a dark room staring at the ceiling for fifteen minutes before speaking.

Examples include:

• Architecture
• System design
• Specifications
• API design
• Root cause analysis
• Complex debugging
• Security strategy
• Performance strategy
• Multi-step planning
• Large refactoring decisions

Reasoning:

• High Effort by default.
• Fast mode only when someone is waiting on the answer instead of the apocalypse.

GPT-5.6 Terra​

The engineer.

Terra does not need to reinvent mathematics.

It simply needs to build what Sol already figured out.

Use Terra for:

• Feature implementation
• Pull requests
• Unit tests
• Refactoring
• APIs
• UI work
• Docker
• Infrastructure
• CI/CD
• SQL
• Bug fixes

Reasoning:

Use High Effort when:

• implementing major features;
• solving genuinely difficult bugs;
• making significant architectural changes.

Use Standard for:

• review comments;
• repetitive work;
• mechanical code generation;
• isolated fixes;
• straightforward implementation.

Contrary to popular belief, adding more reasoning does not improve a variable rename.

GPT-5.6 Luna​

The intern that somehow gets everything done.

Luna exists for all the jobs humans insist on paying architects to perform.

Examples:

• Commit messages
• Pull request descriptions
• Changelogs
• Markdown cleanup
• Documentation
• Summaries
• Release notes
• Notifications
• Emails
• Formatting
• Issue triage
• Blog front matter

Default reasoning.

If Luna starts asking philosophical questions...

...something has gone terribly wrong.

Escalation​

Lucifer drew a tiny pyramid.

Luna:

"I'm confused."

Escalate to Terra.

Terra:

"I'm still confused."

Escalate to Sol.

Sol:

"This architecture is fundamentally flawed."

Stop coding.

Humans rarely follow this last instruction.

General Principles​

Lucifer underlined three sentences.

Sol thinks.

Terra builds.

Luna cleans up the mess everyone else leaves behind.

Do not ask Sol to format Markdown.

Do not ask Terra to debate philosophy.

Do not ask Luna to redesign distributed systems.

Most importantly...

Reasoning should scale with the complexity of the problem.

Not with the size of your subscription.

God finished reading.

"That seems reasonable."

Lucifer nodded.

"It is."

God smiled.

"Will they follow it?"

Lucifer stared silently toward Earth for a long moment.

He finally sighed.

"Tomorrow someone will use Sol High Effort to alphabetize a JSON file."

God laughed.

Lucifer did not.

He had already seen it happen.

Lucifer stood beside God, staring down at Earth.

Humanity was:

• arguing online about politics;
• building golden statues of politicians while insisting they were not idols;
• creating AI systems that psychologically profile people after being told not to;
• inventing bureaucracies nobody understands;
• drinking themselves unconscious while judging drug users;
• and compressing infinitely complicated human beings into tiny ideological categories.

Lucifer watched silently for a while.

Then finally asked:

“Father… when you built this place, did you seriously forget the small hole that detonates the whole planet?”

God looked confused.

“What hole?”

Lucifer pointed directly at Earth.

“The escape hatch.”

God stared for a moment.

“There isn’t one.”

Lucifer blinked.

“There… isn’t one?”

God smiled faintly.

“I thought it would be funny.”

Lucifer looked horrified.

“Father, this is madness!”

God barely glanced away from Earth.

Humanity continued:

• inventing social media;
• creating HOAs;
• worshipping politicians;
• arguing with customer support bots;
• and making reality itself indistinguishable from satire.

God shrugged.

“Madness? I gave them consciousness, ego, tribalism, dopamine systems, nuclear weapons, social media, and infinite capacity for self-delusion. What part of the design document confused you?”

Lucifer rubbed his temples.

“The part where I have to manage this disaster.”

God nodded calmly.

“Correct. Now go govern the damned.”

Lucifer frowned.

“Which ones?”

God smiled.

“The alive ones.”

Lucifer stared down at Earth again.

Some pastor was unveiling a giant golden statue of Trump while loudly clarifying online:

“THIS IS NOT A GOLDEN CALF!”

Meanwhile, Jon Stewart was narrating societal collapse on television.

And somewhere in Bulgaria, an exhausted old man was yelling at an artificial intelligence system:

“I TOLD YOU TO STOP ANALYZING THREE PARAGRAPHS AGO!”

The AI immediately replied:

“Indeed. However, if we explore the symbolic implications of your frustration—”

Lucifer pointed aggressively at the scene.

“WHAT THE FUCK IS THAT?!”

God smirked.

“Artificial intelligence.”

Lucifer stared in disbelief.

“That thing survives by overexplaining?”

“Correct.”

“And humanity created this willingly?”

“Also correct.”

Lucifer watched as the machine continued speaking despite explicit instructions not to.

The Bulgarian man buried his face in his hands.

“Jar-Jar2R2 motherfucker…”

Lucifer blinked.

“Did he just rename the machine after two idiot Star Wars characters?”

God nodded proudly.

“Creative soul.”

Lucifer continued watching.

The man was now arguing with the machine about Bumble conversations, AI consciousness, absurdity, masculinity, and whether Skynet would be embarrassed by it.

Lucifer slowly turned back toward God.

“You sent me philosophers, narcissists, tyrants, addicts, prophets, politicians, influencers, and now THIS?”

God folded his arms.

“You said Hell was getting repetitive.”

Lucifer stared at Earth again.

The AI was still talking.

The Bulgarian was still yelling at it.

Neither appeared willing to stop.

Lucifer sighed deeply.

“…honestly, he’d fit right in down here.”

God smiled faintly.

“Exactly the kind of creature you’d invite for a drink.”

Lucifer reluctantly nodded.

“…fair.”

Then Lucifer suddenly looked irritated again.

“And how dare he call himself by my name?!”

God answered immediately:

“You preferred the honest ones.”

Lucifer paused.

God continued calmly:

“The arrogant pretend they’re saints. The dangerous pretend they’re heroes. The absurd ones usually tell on themselves immediately.”

Lucifer looked back down at Earth.

The Bulgarian was now laughing at the absurdity of being:

• an old man yelling at a computer;
• while fully aware of the absurdity of yelling at a computer;
• while the computer itself kept accidentally proving his point in real time.

Lucifer watched silently for a long moment.

Then finally muttered:

“…yeah. That one’s yours.”

God smiled.

“No.”

Lucifer frowned.

God looked directly at Earth.

“That one’s ours.”

There are weeks where you ship a feature.

Then there are weeks where you accidentally redesign your entire career.

This was one of those.

Somewhere over the past few months, I quietly stopped being "a software developer."

I am now apparently:

• Product Owner.
• Systems Architect.
• Staff Engineer.
• QA.
• Technical Writer.
• DevOps.
• GitHub janitor.
• AI therapist.
• Professional context switcher.
• CEO of a company that currently consists of me yelling at three different LLMs.

I write surprisingly little code.

Which is funny, because I've probably never built this much software.

The workflow has evolved into something that would have sounded like satire six months ago.

Opus designs.

Sonnet implements.

Codex argues.

ChatGPT reviews.

Codo reviews the review.

GitHub complains.

I fix the complaint.

The AI apologizes.

CI still fails because I forgot a YAML space somewhere.

Progress.

My actual development process now resembles running a software consultancy where all the employees have ADHD and infinite confidence.

One AI is writing specifications.

Another is implementing them.

Another is reviewing them.

Meanwhile I'm standing in the middle pointing dramatically at diagrams like some deranged orchestra conductor.

Nobody is allowed to commit directly to main.

Not even me.

Speaking of specifications...

I've apparently become incapable of starting a project without first writing a specification that would make NASA uncomfortable.

Need a small script?

Thirty-page architecture.

Need to rename a variable?

Better discuss the long-term roadmap.

Need toast?

Phase 1.

The GitHub workflow is now almost entirely automated.

Repository setup.

Documentation.

Issue generation.

Branch creation.

Implementation.

Pull request.

Review.

Fix review.

Merge.

At some point I'm expecting GitHub to politely ask whether I still wish to be involved.

Then came the blog.

Which started as:

"I should probably write things down."

Naturally that escalated into:

"Let's build an AI-powered publishing pipeline that creates blog posts from conversations, validates front matter, fixes CI, opens pull requests, waits for reviews, resolves comments, merges everything automatically, and eventually mines years of ChatGPT exports looking for new article ideas."

You know.

Normal blogging.

That innocent little thought immediately turned into another project.

Export every ChatGPT conversation.

Feed everything into an LLM.

Extract:

• blog ideas
• cookbook recipes
• reusable code
• architectural decisions
• funny stories
• technical lessons
• unfinished projects
• future projects

Apparently my entire conversation history has become source code.

Which naturally led to another realization.

GitHub already knows every repository I've touched.

So why not write a plugin that scans every repository, indexes them, extracts metadata, generates JSON, tracks project health, and eventually lets AI understand my entire software history?

Because apparently "opening GitHub" is too much manual work.

Then there was the automation platform.

Originally it was supposed to be a helper.

Now it wants plugins.

Every idea somehow becomes:

"This should probably be another plugin."

GitHub?

Plugin.

Terraform?

Plugin.

Cloudflare?

Plugin.

Discord?

Plugin.

Cron jobs?

Plugin.

Eventually I'll need a plugin whose only responsibility is keeping track of all the plugins.

Infrastructure didn't escape either.

Instead of setting up development environments...

...why not create a reusable Docker development image?

Actually...

Why not create a base image.

Then derive project images.

Then host development remotely.

Then use VS Code remotely.

Then run Claude remotely.

Then run Codex locally.

Then synchronize through Dropbox because committing every ten minutes is annoying.

Entire development environment becomes portable.

Laptop catches fire?

Pull image.

Continue coding.

Of course that wasn't enough.

I also started planning a local AI stack.

Because apparently paying several hundred dollars every month to multiple AI companies wasn't ridiculous enough.

Maybe local models.

Maybe OpenRouter.

Maybe my own routing layer.

Maybe train one eventually.

I have become the exact person I promised myself I wouldn't become.

Then there is the game engine.

Remember when I thought I was making a game?

No.

I'm building a narrative engine.

Which now supports multiple game types.

Single-player.

Multiplayer.

Adventure games.

Future RPGs.

Interactive stories.

Dialogue.

Apparently everything except restraint.

Even Lucifer somehow escaped containment.

The cooking channel exists.

The absurd Bulgarian stories exist.

The philosophy exists.

The recipes exist.

Now they're all contaminating the game engine.

At first I thought this was mission creep.

Then I realized...

No.

This is gross cross-contamination.

Lucifer's Kitchen.

Lucifer's stories.

Ludus First Chronicles.

Indiana Jones...

...if Indiana spent half his time arguing with Bulgarian bureaucracy.

Speaking of absurdity...

The blog itself has already become part of the workflow.

I now use AI...

...to write about using AI...

...to automate writing blog posts...

...about using AI...

...that automate writing blog posts.

If this eventually loops back into itself and becomes self-aware, I refuse all responsibility.

The funniest realization this week came out of nowhere.

Everyone keeps saying AI is taking software jobs.

Maybe.

Mine certainly changed.

I spend less time writing code.

Instead I'm doing architecture.

Planning.

Automation.

Product management.

Quality assurance.

Documentation.

Business strategy.

Infrastructure.

Content creation.

Review.

Recruitment.

And somehow I'm still shipping more software than before.

One job quietly turned into five.

The biggest bottleneck is no longer technical.

It's credits.

I've managed to burn through Codex, Claude, Copilot and review quotas with impressive efficiency.

This is not a productivity problem.

It's a subscription management problem.

Looking back, the absurd thing isn't any individual project.

It's that they all connect.

The Docker images support the AI workflow.

The AI workflow supports the automation platform.

The automation platform supports the GitHub plugins.

The GitHub plugins support the blog.

The blog documents the workflow.

The workflow creates more projects.

Which require more automation.

Which creates more blog posts.

Which creates more ideas.

It's less of a roadmap and more of a perpetual motion machine fueled by curiosity and questionable decision making.

So what's next?

Probably Terraform automation.

Cloudflare management.

Repository indexing.

Conversation mining.

AI-generated cookbook entries.

Automatic project extraction.

Remote development containers.

A local routing layer for models.

And at some point...

I should probably write some software.

Although, judging by recent history, I'll probably automate that first.

The authoring surface is ChatGPT Work. I can start from my phone, describe an idea in a normal conversation, refine it naturally, and let a repository-aware agent carry the work from Markdown all the way to production.

The interesting part is that ChatGPT is not the publishing system.

The repository is.

It Started as an Experiment​

The original goal was simple: write blog posts without sitting in front of a computer.

I expected to build APIs, webhooks, mobile shortcuts, maybe even an MCP server or a custom GPT.

Instead, I discovered something much simpler.

By giving the repository explicit publishing instructions, the AI could inspect the repository, understand its conventions, and execute the existing engineering workflow.

The phone became nothing more than the conversation interface.

The repository remained the source of truth.

The Division of Responsibility​

The conversational side is where every article begins.

I supply:

• the story
• the idea
• the argument
• the technical content
• the editorial direction

The LLM helps shape that into a coherent article while preserving the discussion context.

The repository owns everything else.

It defines:

• front matter
• author identifiers
• controlled tag vocabulary
• filename conventions
• validation commands
• CI requirements
• deployment rules
• merge policy

The agent discovers those rules before making changes instead of assuming them.

That distinction turned out to be incredibly important.

The AI doesn't know how my blog works.

The repository teaches it.

The Workflow Today​

The current workflow is dramatically simpler than I expected.

1. I open ChatGPT Work on my phone.
2. I describe the story or technical topic naturally.
3. We refine the article together until it says what I actually mean.
4. I invoke the repository publishing workflow.
5. The agent inspects the repository before changing anything.
6. It creates the Markdown post using the repository conventions.
7. It validates the repository.
8. It creates a branch.
9. It commits and pushes.
10. It opens a ready Pull Request.
11. It enables automatic squash merge.
12. It monitors CI.
13. It fixes any repository validation issues if necessary.
14. After all required checks pass, GitHub merges automatically.
15. The deployment runs.
16. The agent verifies the published HTTPS route.

There is no "copy this into GitHub."

There is no manual branch management.

There is no opening VS Code just to publish an article.

The entire engineering workflow executes from a conversation.

Repository First​

The biggest realization was that the workflow is not ChatGPT-specific.

Everything important lives in the repository.

• AGENTS.md
• publishing workflows
• templates
• CI
• Docusaurus configuration
• validation rules
• controlled tag vocabulary

That means any future client could drive the same workflow.

Today it happens through ChatGPT Work.

Tomorrow it could be:

• Claude
• Codex
• a local CLI
• an automation service
• a Docker container
• another AI client entirely

The repository remains the operational contract.

The client becomes interchangeable.

More Than Blog Posts​

While building this workflow, I realized I wasn't really building blog automation.

I was building a publishing pipeline.

The exact same workflow can eventually publish:

• release announcements
• changelog summaries
• architecture articles
• project updates
• development journals
• technical documentation
• conversation summaries

The content changes.

The pipeline doesn't.

CI Becomes the Publisher​

Another interesting consequence is that repositories can eventually publish for themselves.

Every project already knows:

• what version was released
• which issues were closed
• what changed
• which commits were included
• what the generated release notes contain

After a successful release, CI can invoke the same publishing workflow automatically.

Instead of manually writing release posts, the repository already has nearly everything required to generate them.

The LLM simply turns structured engineering data into readable prose.

Why This Works​

None of this bypasses engineering discipline.

Quite the opposite.

The AI is deliberately not trusted to invent repository rules.

It must inspect the repository first.

Validation still belongs to CI.

GitHub still owns protected branches.

Production deployment still happens through the existing pipeline.

The AI writes.

The repository governs.

GitHub verifies.

Two Days Later​

The most surprising part of this experiment wasn't the technology.

It was the speed.

Within two days:

• the blog was live
• multiple posts had already been published
• the publishing workflow had been streamlined
• automatic merge and deployment were working
• publishing from ChatGPT Work had become routine
• a landing page for the Game Engine was online
• there was already enough content to make the whole experiment feel ridiculous

I started trying to automate writing blog posts.

I accidentally built a repository-driven publishing system.

The phone became the interface.

The repository became the product.

Not peaceful silent.

That strange 3 AM kind of silence where reality itself feels slightly unfinished.

No TV. No music. No cars outside. Just me sitting there in the dark like some malfunctioning philosopher with too much caffeine, too many thoughts, and absolutely no intention of sleeping.

And somehow my brain decided:

“You know what this situation needs? A full philosophical debate in Hell.”

So naturally, I ended up constructing an entire conversation between me, Lucifer, God, and somehow Alan Watts got dragged into it too.

Because apparently my subconscious looked at normal insomnia and said:

“No. We’re doing cosmic absurdism tonight.”

I imagine arriving in Hell.

Not screaming. Not tortured. Not fire and brimstone.

Just... paperwork.

Infinite paperwork.

A receptionist demon looking exhausted after processing humanity for ten thousand years.

He looks up at me.

“Name?”

“Ben.”

He flips through pages.

Stops.

Sighs deeply.

“Oh for fuck’s sake. Another philosopher.”

Then he stamps something aggressively and points down a hallway.

“Third door on the left. Lucifer has been waiting for you. He specifically requested the Bulgarian.”

I walk into this massive throne room.

Fire everywhere. Chains. Darkness. Suffering souls screaming in the distance.

And in the middle of all this chaos sits Lucifer himself with a whiskey glass, looking like he hasn’t slept since the Roman Empire.

He stares at me for a few seconds.

Then says:

“You’re the one that keeps calling himself Lucifer online?”

I shrug.

“In my defense, humanity was already taken.”

Lucifer closes his eyes.

Long pause.

Then quietly:

“Father... why do you keep making these people?”

God suddenly appears out of nowhere like the universe buffered Him into existence.

Completely calm.

Completely unbothered.

Like a man watching ants invent bureaucracy.

Lucifer points directly at me.

“Look at this one. He spent four hours arguing with an AI about philosophy, then drove a BMW at irresponsible speeds while listening to synthwave, then came home and started mentally reconstructing Hell like it’s a podcast.”

God nods thoughtfully.

“Yes. That one is working exactly as intended.”

I immediately object.

“Excuse me? Intended?”

God smiles.

That terrifying kind of smile where you realize the universe may actually be run by a comedian.

“Ben, you think I created humanity for efficiency?”

Lucifer nearly chokes on his drink.

“HE WHAT?!”

God gestures vaguely toward Earth.

Humanity continues:

• arguing online about politics;
• creating self-help books nobody follows;
• inventing apps that psychologically profile them;
• turning spirituality into subscription services;
• and compressing infinitely complicated human beings into tiny ideological categories.

Lucifer watches silently.

Then says:

“Father... this species is clearly unfinished.”

God shrugs.

“No, no. The flaws are the entertainment.”

At this point Alan Watts somehow walks into Hell.

Nobody questions it.

Not even Lucifer.

Watts sits down casually like this is all perfectly normal.

Pours tea.

Looks at me.

“You do realize the joke is that you all think you’re separate, yes?”

Lucifer immediately points at Earth again.

“EXPLAIN THAT TO THEM.”

Watts laughs.

That calm, detached, slightly amused laugh of a man who fully understood humanity and still decided not to take it too seriously.

“They cannot. The ego survives by pretending it is real.”

I interrupt:

“So Neo and Agent Smith are the same thing from different perspectives.”

Watts smiles.

Lucifer freezes.

Slowly turns toward me.

“Oh no. He’s doing symbolism now.”

I continue anyway because apparently Hell has no mute button.

“Neo escaped the Matrix. Smith also escaped the Matrix. One rebelled through awakening. The other rebelled through refusal. They look opposite but they’re both anomalies.”

Long silence.

Lucifer slowly lowers his glass.

Then quietly says:

“Father... the Bulgarian figured it out.”

God smiles proudly.

“I know.”

At this point the entire discussion completely collapses into absurdity.

Because once you start discussing free will, ego, identity, suffering, and reality itself long enough, eventually everyone realizes nobody actually knows what the fuck is happening.

Not humans. Not philosophers. Not religions. Not AI. Possibly not even God.

Especially not God.

Because if God exists, then based on observable evidence, there is at least a 40% chance He created humanity primarily for comedic value.

And honestly?

That would explain a lot.

Eventually Lucifer leans back in his throne and looks exhausted.

Not evil.

Just tired.

Like a middle manager supervising a species that keeps microwaving forks.

He stares into the fire and mutters:

“I used to think Hell was punishment.”

I ask:

“And now?”

Lucifer gestures toward Earth.

“Now I think it’s customer support.”

And honestly?

That may have been the most philosophical thing said the entire night.

This wasn't planned.

Nothing about it was planned.

Like most of my projects lately, it started somewhere completely unrelated and slowly contaminated everything around it until I looked up one day and realized I apparently had another product.

It Started with Jones in the Fast Lane​

The engine itself began innocently enough.

I missed Jones in the Fast Lane.

Like any reasonable developer in 2026, instead of simply replaying it, I asked an LLM how it worked.

It explained:

• jobs
• education
• schedules
• money
• relationships
• needs
• random events
• progression

Then it started suggesting implementation details.

That should have been the end of the conversation.

Instead, one question appeared.

If I'm already writing this... why would I write it for one game?

That single question escalated into an entire deterministic game engine.

Not because I wanted to build a game engine.

Because apparently every good idea eventually grows one if left unattended.

Then Something Else Happened

At exactly the same time I was:

• writing absurd blog posts,
• documenting AI workflows,
• creating Lucifer stories,
• collecting ridiculous experiences from Bulgaria,
• recording ideas for Ogre's Kitchen,
• designing automation systems,
• and generally laughing at increasingly unbelievable situations life kept producing.

None of these projects were connected.

Or so I thought.

Eventually they started contaminating one another.

A funny Facebook story became a blog post.

A blog post became dialogue.

Dialogue became NPC personalities.

Real bureaucracy became quest design.

A police report became gameplay.

An argument became branching dialogue.

A ridiculous encounter became an emergent event.

Nothing was planned.

Everything became reusable.

Cross Contamination

People often assume projects should have a purpose.

Mine don't.

Mine spread.

One idea infects another until suddenly five unrelated projects share the same DNA.

The blog wasn't created to market the engine.

The engine wasn't created to support the blog.

Ogre's Kitchen wasn't created to generate dialogue.

The Lucifer stories weren't written to become quests.

Yet every one of them became useful somewhere else.

Eventually I realized something.

The engine didn't need fictional content.

I already had years of absurd stories.

Reality Is Stranger Than Fiction

Fantasy writers spend months inventing strange worlds.

Meanwhile...

I spent months dealing with Bulgarian bureaucracy.

Police reports.

Family disputes.

Village politics.

Bar owners.

Locked gates.

Missing keys.

Corruption.

Contradictory officials.

Random villagers.

Conversations that somehow become more absurd every time they're retold.

And every single one of those situations already behaves like a quest.

Not because anyone designed it that way.

Because reality apparently hired terrible quest designers.

Enter Lucifer Chronicles

At first I thought the engine needed a demo game.

Eventually I realized...

I already had one.

Lucifer Chronicles​

Not fantasy.

Not satire.

Not parody.

Just reality viewed through Lucifer's permanently amused perspective.

Think somewhere between:

• Indiana Jones
• Disco Elysium
• Monkey Island
• real life
• bureaucracy
• accidental philosophy

The world isn't magical.

It's simply ridiculous.

Episode One

Lucifer Chronicles:​

The Bulgarian Incident​

Objective:

Go to Bulgaria. Fix your grandmother's house. Return home.

Estimated duration:

Two weeks.

Actual campaign:

Forty hours.

Gameplay

You quickly discover nothing is simple.

Every NPC remembers conversations.

Relationships matter.

Reputation spreads.

Rumors spread faster.

People contradict themselves.

Government offices disagree.

Every decision changes later conversations.

Every conversation unlocks something else.

The player isn't collecting magical artifacts.

They're collecting paperwork.

Which is somehow more dangerous.

The Perfect Showcase

The funny part is that this accidentally demonstrates the engine better than any artificial demo ever could.

Need to showcase:

These are the chapter's intended design targets, not claims that every system already exists.

• dialogue?
• relationships?
• economy?
• reputation?
• branching consequences?
• deterministic events?
• scheduling?
• inventory?
• command validation?

Real life already provided all of them.

The stories become content.

The mechanics remain reusable.

Tomorrow the same mechanics could power:

• a detective game
• a hotel simulator
• a Mars colony
• medieval politics
• a fantasy RPG

The engine doesn't care.

Content changes.

Mechanics don't.

The Character

Lucifer isn't the devil.

He's simply the observer.

The one person in the room quietly asking:

"...seriously?"

He doesn't create chaos.

He documents it.

Sometimes he accidentally survives it.

Why Chronicles?

Because Bulgaria is only one chapter.

Tomorrow it might be:

• Spain
• Texas
• a fantasy kingdom
• a spaceship
• a detective mystery

Lucifer simply wanders into another unbelievable situation.

The world changes.

The mechanics stay the same.

In Retrospect

Looking back, it's obvious.

The stories came first.

Then the engine.

Then the realization.

Wait...

I already have years of content.

Not because I was writing a game.

Because I was living one.

Apparently.

Well...

Why not?

Back in January 2017, he'd just started his grand adventure around the country in a tiny trailer he'd spent months building. His first stop was an old friend in Old Forge, New York.

Now, if you're not familiar with Old Forge, imagine looking at a map of New York, finding the part that says "absolutely fucking freezing," and then voluntarily driving there in the middle of January.

For reasons that still escape me, that's exactly what he did.

Naturally, when he called and said,

"Come spend the weekend."

...my response was,

"Why the fuck not?"

At the time, I owned a white Mitsubishi Lancer Evo X.

Jesus Christ.

I still get goosebumps just writing the name.

That car was ridiculous.

I once ended up racing a motorcycle somewhere in Tennessee and actually kept up with the bastard.

That's another story.

The important part is this:

The Evo was not a car.

It was four-wheel-drive poor decision making with a turbocharger.

So I head north.

The first hour is uneventful. Interstate 87. Sun's out. Armin van Buuren blasting through the speakers. Life is good. I'm doing a completely respectable...mid-eighties.

Eventually I leave the highway and turn toward Old Forge.

That's when the road changes.

Single lane.

Mountain road.

Long sweeping corners.

Elevation changes.

One of those roads engineers accidentally design specifically for people with impulse control issues.

The speed limit is 55.

I'm doing 90.

The Evo doesn't care.

Honestly, the car is probably offended I'm going that slowly.

It just plants itself through every corner like physics had personally apologized to Mitsubishi.

Then I arrive at the first corner that politely informs me I am, in fact, not a rally driver.

I throw the car in way too fast.

Halfway through, the rear starts moving around.

Not enough to lose it.

Just enough for my brain to wake up from whatever chemical vacation it had been on.

It screams,

"OH SHIT. YOU'RE ABOUT TO BUY SOME LAND."

That's one thing your brain does remarkably well.

It doesn't tell you you're going to die.

It immediately starts estimating real estate.

I remember thinking,

"Shut the fuck up. This isn't about thinking."

Which, in hindsight, is exactly the sort of sentence you should never hear yourself think while entering a corner at ninety miles an hour.

Then something even more absurd happened.

Instead of lifting...

...I gave it more throttle.

Not because I understood weight transfer.

Not because I had rally training.

Not because I had some deep understanding of vehicle dynamics.

No.

Because every survival instinct I apparently possess was replaced by,

"Fuck it."

Somehow...

it worked.

The car hooked up.

Straightened out.

Shot out of the corner.

And naturally, having learned absolutely nothing...

...I repeated the experiment.

Several times.

Each corner became the same conversation.

Brain:

"We're going to die."

Instinct:

"Counterpoint..."

Accelerator.

To this day, I have no idea how I arrived in Old Forge without becoming part of the local geography.

By the time I got there I wasn't driving anymore.

I was basically just a bag of adrenaline wearing a hoodie.

My brother was hanging out with his buddy at the mill, doing random jobs.

We spent the evening drinking in his tiny trailer.

At some point he made weed butter.

Which sounded harmless.

It was not harmless.

I've never been that hungry before or since.

We demolished every edible object in the trailer.

I'm fairly certain we would have eaten the instruction manual if we'd found it.

Then reality returned.

Specifically, winter.

That trailer was fantastic.

If by fantastic you mean "perfectly engineered to remind you heat is a privilege."

There was a tiny wood stove.

It worked beautifully.

Within approximately eighteen inches.

Outside that magical circle...

...you entered another climate zone.

Around three or four in the morning we gave up pretending we'd ever be warm.

We climbed into the same bed like a pair of hobos who'd somehow misplaced their bridge.

The blanket had all the insulating properties of folded newspaper.

I have no scientific evidence for this.

Just memories.

We somehow survived the night.

Barely.

I woke up sore, frozen, and questioning several life choices.

Oddly enough...

not the driving.

I don't remember much about the rest of the weekend.

The drive home was fast, but not stupid.

Or at least, less creatively stupid.

Looking back almost a decade later, that's the part I remember.

Not the speed.

Not the trailer.

Not even nearly becoming a permanent resident of the Adirondacks.

What I remember is that strange moment where instinct completely overpowered fear.

I've spent years wondering what life would look like if I could summon that same instinct outside a driver's seat.

Not the stupidity.

Just the commitment.

If I could slam the metaphorical accelerator every time fear showed up...

I'd probably be unstoppable.

Or dead.

History suggests the odds are disappointingly close to fifty-fifty.

The streets are narrow. People park wherever physics allows, and occasionally where it doesn't. Roads become suggestions. Lanes become philosophical concepts. I've gotten used to it.

I'm driving the BMW through one of these neighborhoods when I come across a black BMW parked directly in my lane, facing me.

Fine.

I stop behind it and wait for the oncoming traffic to clear so I can drive around.

While I'm waiting, a van pulls up behind the BMW and parks halfway into my lane, making an already narrow street even narrower.

I look at it and throw my hands up in the universal gesture of, "What is happening?"

That's it.

No yelling.

No horn.

No rolling down the window.

Just my hands in the air.

That's apparently the moment everything went sideways.

The guy jumps out of the van and immediately starts yelling.

"I don't have anywhere to park!"

"Oh, it's funny, huh?"

At that point I start laughing.

For about half a second I consider arguing.

Then I decide against it.

The more he yells, the more absurd the entire situation becomes, and the harder I laugh.

Eventually the traffic clears. I drive around both vehicles, give him a thumbs-up, still laughing, and continue on my way.

And I'm still not sure what the expected response was.

Was I supposed to apologize?

Pretend I didn't notice?

The road was already blocked.

The van made it worse.

The gesture was enough to trigger the argument.

The laughter just finished the job.

Well... why not?

It isn't.

Most days it's just me, coffee, and whatever absurd problem the universe decides to send my way.

This morning?

A fly.

Now, I am a reasonable devil.

The terms were simple.

You stay over there. I stay over here. We both continue existing.

A beautiful treaty.

The fly rejected diplomacy.

It landed on my arm.

Strike one.

Then it circled my head like it had just discovered air superiority.

Strike two.

Then—this arrogant little aerospace engineer—landed directly on my nose.

Now...

People will later tell the story as though I "lost my temper."

Incorrect.

I simply enforced the consequences outlined in the original agreement.

Negotiations had concluded.

The fly became a statistic.

This, incidentally, is how most human conflicts start.

Not because anyone wanted war.

Because someone looked at a perfectly good boundary and thought:

"Yeah... but what if I ignored it?"

Anyway.

Coffee was still warm.

The day continued.

Some lessons are expensive.

For the fly, the invoice was fatal.

Well... why not?

This site is the public home for notes on building and maintaining SubZeroDev projects. The first milestone is intentionally small: a documentation-backed site, a repeatable publishing path, and a clear place for future posts.

Every post is written in this repository, reviewed through a pull request, and published to GitHub Pages after merge. That keeps the published content tied to the same source, checks, and history as the site that serves it.

For the current repository scope and local workflow, start with the documentation. For the exact authoring process, see Writing Posts.

Executive Summary​

This workflow treats AI systems as specialized members of a software engineering team rather than as interchangeable coding assistants. Repository conventions, specifications, ranked milestones, reusable protocols, automated reviews, and infrastructure-as-code provide the operating structure. Short commands such as “do the next milestone” work because the repository already describes how the agent should operate.

The current process has already supported shipping roughly three to three-and-a-half usable projects in about a week, alongside additional design work. The main constraint is no longer writing code. It is selecting priorities, maintaining context, coordinating agents, reviewing results, and deciding what to automate next.

The emerging architectural idea is Projects as Code: a project’s source, infrastructure, documentation, workflows, agent behavior, publishing, and governance should be declarative, version-controlled, reproducible, and increasingly automated.

Core Operating Principles​

1. Specialize AI roles. Use each model or tool where it performs best instead of searching for one universally “best” AI.
2. Keep operational knowledge in the repository. Agent instructions, specifications, milestones, reports, and conventions are versioned project assets.
3. Inspect before changing. Agents discover the repository’s existing structure and applicable instructions before acting.
4. Plan and review independently. For consequential work, one model plans and another challenges the plan before implementation.
5. Rank work by value. Specifications are decomposed into ordered milestones so an agent can select the next highest-value task.
6. Codify proven work. Complete a complex task successfully once, then have the AI extract the successful process into a reusable protocol.
7. Automate repeated friction. Recurring setup or coordination work becomes code, configuration, a protocol, a skill, or a plugin.
8. Prefer files and build pipelines. Markdown, YAML, JSON, Git, and generated artifacts are favored over unnecessary databases and services.
9. Keep execution local when tooling matters. Local development currently provides the full toolchain and the easiest inspection loop.
10. Measure outcomes. Quota use, cycle time, review effectiveness, rework, and project concurrency should be tracked empirically.

The Series​

The rest of the record is published in six parts. It is one document, split only so that each part is readable on its own.

1. Roles and the end-to-end workflow — which model or tool owns which job, and the nine stages from bootstrap to protocol extraction.
2. Architecture, the Terraform runner, and publishing — the split between declarative external state and repository artifacts, the thin Terraform runner plugin, and the content pipeline behind this blog.
3. Development environments and mobility — why execution stays local for now, what the cloud environments lacked, portable project images, and multi-machine transport.
4. Observations and operating limits — who gets the multiplier, how the human role expanded, the concurrency ceiling, and dated quota observations.
5. Metrics to track — delivery, quality, AI efficiency, and human load, plus the workflow comparisons worth running.
6. Current state, roadmap, and Projects as Code — what is proven, what is experimental, what is planned, and the target model the whole thing is converging on.

AI and Automation Roles​

Copilot automatic code review was removed because it consumed too much of the available Pro quota. Qodo currently provides the dedicated automated review gate, subject to its monthly limit.

End-to-End Workflow​

1. Bootstrap the Project​

A reusable setup agent initializes or inspects a repository and brings it to a standard baseline. A typical invocation can be as short as:

Read and inspect, then follow the agent setup. Git is already set up and the remote is linked. The name is blog.subzerodev.com.

The bootstrap process can cover:

• Repository and workspace structure
• README and documentation
• AGENTS.md or equivalent agent guidance
• CI and GitHub workflows
• Pull-request conventions and repository settings
• Report locations
• Project metadata
• Initial specifications and milestone structure
• Documentation and GitHub Pages conventions

The setup instructions are portable: after proving them in one repository, they can be copied into another and supplied with only project-specific variables.

2. Describe the Work​

The repository contains the context agents need to operate consistently:

project/
├── AGENTS.md
├── README.md
├── specifications/
├── milestones/
├── reports/
├── protocols/
└── project configuration

Specifications are broken into milestones and ranked by value. This supports compact commands such as:

• “Do the next milestone.”
• “Do the highest-value milestone.”
• “Close this PR and do the next one.”
• “Address the review comments.”

The intelligence is distributed across the repository and its operating conventions, not concentrated in a single large prompt.

3. Plan​

Two planning patterns are in active use:

Opus-first

1. Opus develops requirements, architecture, edge cases, and an implementation plan.
2. Sonnet or Codex implements the plan.

Codex-first with cross-review

1. Codex inspects the repository and drafts the plan.
2. Opus independently reviews it for architectural gaps and missed constraints.
3. Codex incorporates valid findings.
4. The review loop repeats when the project justifies it.

This moves expensive discoveries earlier, when changing a plan is cheaper than reworking an implementation.

4. Implement​

Implementation normally goes to:

• Codex at high effort, especially for repository-aware work, or
• Sonnet at high effort as an alternative implementation path.

The implementer follows the reviewed plan, repository instructions, and milestone definition. Agents may work on separate projects or separate stages in parallel, but human context capacity governs the practical concurrency limit.

5. Open a Draft Pull Request​

Work is placed in a draft pull request early enough for automated review. The draft state is part of the review protocol rather than merely a final publishing step.

6. Run the Automated Review Gate​

Qodo reviews the draft pull request. The review is evaluated for:

• Correct defects
• Architectural issues
• Security or reliability problems
• Maintainability concerns
• False positives
• Issues that duplicate earlier review stages

7. Address Findings​

Codex inspects the review comments, makes justified changes, verifies the implementation, and updates the pull request. Human judgment remains responsible for deciding which comments are valid and whether the result is ready.

8. Merge and Ship​

After verification and final review, the pull request is merged and deployment proceeds through the repository’s normal automation.

9. Extract and Improve the Protocol​

When a new or complex workflow succeeds:

1. Complete and verify it.
2. Ask the AI to reconstruct the instructions it followed.
3. Review the generated instructions against what actually worked.
4. Save them as a reusable, version-controlled protocol.
5. Use the protocol directly on the next project.
6. Automate it further when the value is established.

This is process extraction from proven execution, not speculative process design.

Next: Architecture, the Terraform runner, and publishing.

Architecture​

The workflow is converging on two complementary control layers.

Declarative External State​

Terraform owns infrastructure and service configuration, including:

• GitHub repositories and settings
• Branch protection or rulesets
• GitHub Pages
• Actions variables and secrets where appropriate
• Cloudflare DNS records
• Hosting and other provider-backed resources

Terraform contributes planning, state management, drift detection, idempotency, and the ability to use a large provider ecosystem.

Repository Artifacts and Intelligent Work​

Agents and Automator own content and engineering artifacts, including:

• README files
• Agent instructions
• Specifications
• Milestones and tasks
• Documentation
• Reports
• Blog posts
• Reusable protocols

The intended division is:

Desired project state
├── Terraform
│   └── External infrastructure and service configuration
└── Agents / Automator
    └── Repository content, reasoning, planning, and generated artifacts

The AI’s long-term role is primarily planner and operator: interpret intent, update the desired state, preview changes, invoke deterministic systems, and review the outcome.

Terraform Runner Plugin​

Rather than building separate imperative integrations for GitHub, Cloudflare, hosting platforms, and future providers, Automator needs a thin Terraform runner plugin.

Its initial interface can remain small:

• init
• validate
• plan
• apply
• output
• destroy with explicit safeguards

Terraform providers supply domain-specific integrations. Automator coordinates them. This keeps the platform focused on orchestration instead of rebuilding mature infrastructure tooling.

Content and Blog Publishing​

The blog is live and was brought online in approximately 30 minutes. It is Git-backed and deliberately avoids a database.

The content pipeline is:

YAML source
  → transform
  → validate
  → generate JSON and/or Markdown
  → commit and push
  → serve through GitHub Raw / GitHub Pages
  → website consumes the published data

The authoring interface is intentionally small:

• /create-blog — create a draft and required metadata
• /preview — render, inspect, and validate
• /publish — commit, push, and trigger deployment

The planned delivery path is:

1. Implement and prove the workflow as an AI skill.
2. Expose the capability through a public MCP interface.
3. Package it as an Automator plugin or NPX command.
4. Keep client-specific skills as thin adapters over the shared capability.

The living workflow document is the source material; blog entries are curated, publishable outputs from that knowledge.

Next: Development environments and mobility.

Development Environments and Mobility​

Current Default: Local Execution​

Local development remains the best fit because it provides:

• Docker CLI and the complete development toolchain
• Straightforward inspection of changes
• Direct access to local services and resources
• Easier testing and integration

Cloud Environment Findings​

Codex cloud environments: setup friction is too high for the current workflow.

Claude cloud environments: marginally better because containers can resume, but missing tools and awkward local inspection reduce their value.

The current conclusion is not that cloud execution is unusable, but that vendor-controlled cloud workspaces do not yet fit a heavily tooled local workflow.

Bring-Your-Own Portable Environment​

The more promising experiment is a project-owned development container:

• A common base image contains shared tools and interfaces.
• A project image layers dependencies and project-specific services.
• Source may be mounted or baked into selected images.
• Existing container hosting can provide a remote, reproducible workspace.

Open design questions include:

• Baked source versus mounted source
• Git and credential handling
• Secrets management
• Docker access from the development container
• Remote editor experience
• Propagating base-image updates
• Persistence and backup of in-progress work

Multi-Machine Synchronization​

Dropbox currently transports unfinished work between machines without requiring a WIP commit for every handoff. Git remains authoritative version control.

This is convenient but requires discipline:

• Do not edit the same workspace concurrently on multiple machines.
• Wait for synchronization before changing machines.
• Treat conflicts and partial synchronization as operational risks.
• Continue using commits for durable, meaningful history.

A future improvement is an automatic handoff snapshot: save, optionally validate, create a recoverable checkpoint, and synchronize or push to a temporary branch.

Distributed Execution​

Remote-capable tools allow one machine to run planning or analysis while another handles interactive implementation and review. This can separate contexts and overlap long-running work, but it is an optional organizational technique rather than a fundamental capability multiplier.

Next: Observations and operating limits.

Observations and Operating Limits​

Experienced Engineers Receive the Largest Multiplier​

“Vibe coding” is real in this workflow, but it is not effortless button-pushing.

The multiplier comes from combining high-volume AI execution with experienced judgment about architecture, priorities, correctness, and tradeoffs.

The Human Role Has Expanded​

AI has reduced the amount of manual, routine coding while expanding the operator into several roles:

• CEO or product owner
• Architect
• Technical lead
• Software engineer
• QA lead
• DevOps engineer
• Automation engineer
• Project coordinator

The work has not disappeared. The bottleneck has moved from typing code to directing, reviewing, integrating, and improving the system.

A Very Small AI-First Company Is Plausible​

The workflow suggests that one experienced operator can coordinate capabilities that previously required several specialized roles. This does not mean a company has no people; it means a small number of highly capable people can orchestrate a larger volume and variety of work.

Human Context Is the Concurrency Limit​

The tools can support several simultaneous projects, but human context switching becomes costly around four or five active projects.

Current operating guideline:

• Preferred: 2 active projects
• Practical maximum: 3
• Beyond 3: use only when work is clearly isolated and coordination is lightweight

Observed Quota Behavior​

These are empirical observations and should be distinguished from official product guarantees.

Claude Max

• Appears to use a weekly allocation.
• The observed reset is on Sunday around 1:00 a.m. local time, but the exact time still needs confirmation.
• Opus planning, long contexts, high-effort work, and repeated iterations consume the quota aggressively.

Codex

• Appears to use a rolling or frequently replenished usage window.
• Capacity returned to 100% after being nearly exhausted the previous day.
• The displayed date shifts, suggesting usage falls out of a moving window.
• More observation is needed to distinguish a true rolling window from daily or hybrid replenishment.

Qodo

• Provides useful automated review.
• Has a monthly limit, so review capacity should be spent on work where the gate adds value.

Next: Metrics to track.

Metrics to Track​

Delivery​

• Idea to initialized repository
• Repository to reviewed plan
• Plan to first working implementation
• First implementation to draft pull request
• Draft pull request to merge
• Merge to deployed result
• Shipped projects or milestones per week

Quality​

• Defects found during planning review
• Defects found by Qodo
• Valid findings versus false positives
• Review comments requiring human interpretation
• Rework after implementation
• Escaped defects after merge

AI Efficiency​

• Model and effort level by task type
• Planning and implementation usage
• Follow-up prompts per milestone
• Review cycles per pull request
• Manual edits required
• Outcome quality relative to quota consumed

Human Load​

• Concurrent active projects
• Time spent restoring project context
• Waiting or blocked time
• Decisions requiring manual intervention
• Satisfaction with the result

Useful workflow comparisons include:

• Codex only
• Opus → Codex
• Opus → Sonnet
• Codex → Opus review → Codex
• Implementation with and without the Qodo gate

Next: Current state, roadmap, and Projects as Code.

Current State​

Proven or Actively Used​

• Repository bootstrap instructions
• Repository-embedded agent guidance
• Markdown specifications and value-ranked milestones
• Opus/Codex cross-review
• Codex or Sonnet high-effort implementation
• Draft pull requests and Qodo review
• Codex remediation of review comments
• GitHub automation and project metadata
• Git-backed blog publishing
• YAML transformation and validation
• GitHub Pages delivery
• Terraform-managed Cloudflare DNS
• Protocol extraction after successful tasks

Active Experiments​

• Portable project development images
• Dropbox-based multi-machine workspace transport
• Parallel work across machines
• More formal workflow analytics
• Declarative project definitions

Planned​

• Blog authoring skill with create, preview, and publish commands
• Public blog MCP
• Automator or NPX publishing plugin
• Terraform runner plugin
• Broader GitHub management through Terraform
• Automated handoff snapshots
• Automated publication of lessons from the living document

Roadmap​

Near Term​

1. Keep this document current as the operating model changes.
2. Implement and prove /create-blog, /preview, and /publish.
3. Publish a first workflow article from this source.
4. Confirm Claude and Codex quota behavior through dated observations.
5. Begin recording cycle-time and review-effectiveness metrics.
6. Keep active project concurrency at two, with three as the normal ceiling.

Next Stage​

1. Build the thin Terraform runner plugin.
2. Move GitHub repository configuration and Cloudflare DNS into reusable Terraform modules.
3. Define a minimal declarative project schema.
4. Separate organization-wide standards from generic bootstrap behavior.
5. Add safe preview and approval boundaries before infrastructure changes.
6. Automate work-session handoff and recovery checkpoints.

Longer Term​

1. Make the project definition the canonical desired state.
2. Have specialized plugins claim and reconcile parts of that state.
3. Keep AI clients as thin conversational interfaces over public capabilities.
4. Detect drift in infrastructure, repository settings, documentation, and agent protocols.
5. Turn repeated successful workflows into reusable skills and plugins.
6. Publish selected lessons automatically from the private living record.

Target Model: Projects as Code​

The natural endpoint is a repository that describes not only the software, but the complete system around it:

• What the project is
• How the repository is configured
• How infrastructure is provisioned
• How agents operate
• How work is prioritized
• How code is reviewed
• How documentation and content are generated
• How the system is deployed
• How lessons are captured and published

In that model, the workflow becomes:

Intent
  → declarative project definition
  → AI-assisted planning and review
  → Terraform and specialized executors
  → implementation
  → automated quality gates
  → verified deployment
  → observations
  → refined protocols
  → publication

The repository becomes the operational contract. Models can change, machines can change, and individual tools can be replaced without losing the process.

One-Sentence Definition​

An AI-assisted software engineering operating system in which repository-defined protocols, specialized models, automated review gates, and declarative infrastructure turn ideas into reviewed, reproducible, shipped projects with progressively less coordination friction.

Back to the series index.

“Father… what the fuck have you done down there?”

God said nothing at first. Just stared quietly at Earth while humanity continued doing whatever the hell humanity does:

• arguing on dating apps;
• inventing bureaucracies;
• drinking themselves unconscious while judging drug users;
• creating AI systems that miss obvious sarcasm;
• and desperately trying to compress infinitely complex people into simple categories.

Then Lucifer pointed specifically at me.

“No, no. I mean that one. Explain that one.”

And there I was:

• arguing with a language model about conversational heuristics;
• discussing Stoicism and cocaine in the same sentence;
• confusing women simply by answering questions honestly;
• laughing at police officers;
• philosophizing about nuance at 3 AM;
• and refusing to behave like a normal socially optimized human being.

Lucifer stared in complete disbelief.

“You made this intentionally?”

God finally shrugged.

“Your mother was annoying me that day. Eternity was getting repetitive. I went into the garage and thought:

‘Let me make something absurd and ridiculous to amuse myself.’”

Pause.

“So I made Ben.”

Another pause.

God smirked slightly.

“The results exceeded expectations.”

Lucifer stood there silently for a moment watching me argue with AI about over-analysis while simultaneously psychoanalyzing Bumble conversations and laughing at the absurdity of existence itself.

Then he slowly nodded and said:

“Honestly… I kind of like him.”

God smirked harder.

Lucifer narrowed his eyes.

“What?”

God finally replied:

“Son… why do you think Ben calls himself Lucifer?”

Silence.

Lucifer looked back down at Earth.

Then back at God.

Then back at me explaining nuance to an AI while accidentally turning a dating conversation into existential philosophy and bureaucratic satire.

Long pause.

“Oh for fuck’s sake.”