Alien Authors

How I build software in mid-November 2025

Imagine a distant alien planet, on which a single individual produces thousands of books a year. We’ll call this planet, Epyhia. The individual responsible for making books on Eyphia is called the director.

The process of making a book on Epyhia begins with the director writing a detailed description of the type of book he wants written and sending it off to two competing alien authors. The description varies depending on the type book being written. For children’s books, the description might just be a few sentences describing the setting and a high level plot. But for science-fiction or biographies, the description is much longer, detailing everything from characters traits to how it should end.

The competing alien authors receive this description and draft a detailed, step-by-step outline of the book they plan to write. They then present their plan to the director and eagerly await his feedback with their joyful alien tentacles wagging in anticipation.

The director reads both outlines and selects the one he feels will result in the most captivating story. The alien author whose story wasn’t selected is promptly killed.

Again, for simpler books, the director may accept the author’s outline without any feedback. But for more complex books, there is usually considerable back and forth between the director and the author, revising the outline into something more in line with the director’s vision. Once the director is satisfied with every detail in the outline and he has approved every character, plot line, conflict, and setting detail, he commands the author to get to work.

The alien authors on Epyhia work at a rapid pace that would put even the most prolific human authors, like Isaac Asimov, to shame. In a matter of minutes, the alien author returns to the director to present his first draft.

The director always has feedback on the first draft. He starts by pointing out plot holes, requesting dialogue be refined, and most importantly, ensuring that all of the points mentioned in the outline are covered in the book. Upon receiving the director’s feedback, the alien author immediately gets back to work, lest he end up like his recently deceased competitor. He returns several minutes later with the feedback incorporated, only to have the director promptly shout at him again to “Add this!” or “Change that!” This ferocious back and forth goes on for 10s of iterations.

Finally, when the director is satisfied that the requirements in outline are met, he begins the most important process of writing on Eyphia, editing.

You see, the alien authors of Epyhia write with volcanic verbosity. What can be said in two sentences, they say in two pages. Although they have managed to craft a book that covers everything in the director’s outline, it’s 2,000 pages too long. They’ve given the director the Wheel of Time but what he wants is Harry Potter.

The director pulls out his megaphone and resumes his commands of the alien author. “Remove this!”, “Shorten that!”, “Filter those!” he bellows. And after 10 or so more iterations, the giant marble stone of an initial draft is chiseled into an elegant little statue. Without spending so much as a minute to admire the author’s work, the directory ships it off to a panel of alien literary critics.

The alien critics review every aspect of the produced work. They check for grammatical errors and a consistent writing style. They provide feedback on the dialogue between characters and the clarity of the plot. They ensure citations are accurate and credible. When they’re done their work, there is always something to be improved.

The feedback of the review panel is then sent back to the alien author whom rapidly addresses their concerns and submits the revised work for re-review. After several exchanges, the critics sign off on the book and approve its release.

Lastly, the director does one final review of the book before it’s released. Usually he finds nothing, but occasionally he uncovers missing details or some more unnecessary fluff that can be removed. Once he’s done his manual review, the director releases the book the masses.

Each day the director is simultaneously working on 2-3 books, repeating the same process with another group of authors and critics all throughout the day. He jumps frequently from planning session, to draft review, to book review. One moment he is providing feedback on illustrations of a red dinosaur in a children’s book and the next he is critiquing the historical accuracy of a fantasy novel set in ancient Greece. He reviews every line of text that is written by his army of authors and has absolute control over the direction of every narrative. The director is the consummate micro-manager, a god-like figure amongst his employees who heed his every command with absolute obedience. He’s the type of person that Elon Musk thinks he is.

This is an analogy for how I write software in 2025. Eyphia is the company I’m CTO of (Moovs), books are the features of our product (a SaaS for ground transportation companies), I am the director, and my employees are coding agents.

I start each feature by converting the ticket for that feature into a planning prompt that I then feed into both Claude Code and Codex CLI. The “planning prompt” is usually a prompt structured like “Come up with a plan for... <high level description of the ticket + acceptance criteria>”. I ensure Claude Code is in plan mode for this stage (at the time of writing this Codex CLI doesn’t have a plan mode so I just enter the plan as you would any other prompt). For models I use Sonnet 4.5 for Claude Code and gpt-5-codex medium for Codex CLI (99% chance these models are outdated within a week of publishing this.)

I then review both plans and choose the one I like more. Claude Code wins this battle about 70% of the time. The rest of the feature is then implemented using the model whose plan was selected.

For simple features that have detailed specs I can usually accept the plan verbatim. But for more complex tasks with a higher level of ambiguity I have to iterate on the plan substantially before accepting it. “substantially” meaning 2-10 exchanges with the coding agent.

I then tell the coding agent to get to work.

For net-new features, I always go with the auto-accept edits mode, in which the agent makes changes without asking my permission. I find it’s easier to iterate and modify the code after it has all been written rather than try to steer the models implementation as it’s writing the code. This is partly because for net new features, lots of code is being written and it’s hard to make intelligent suggestions on parts of the model’s solution without seeing the whole thing. For modifications to existing features where I have a pretty good mental model of the change I want to be made, I set the agent to manual approval mode and synchronously observe and approve each change the model makes.

After the agent (especially Claude) has confidently asserted that everything is “Absolutely right!” and functioning, I perform an E2E test on the feature. Often times, It’s not actually working, or at least not working as I would expect and I have to iterate with the coding agent to get the feature working. At this point I still haven’t actually dove into the code that was written.

After I’ve confirmed the code works as expected, I have the model create a detailed commit explaining the changes made and put up a pull request. I then run the /review command to kick off a review of the pull request while simultaneously beginning to perform a manual review of the code myself. I make a somewhat concerted effort to not look at the coding agents review until I’ve finished my own manual review both to not bias my review and as a learning opportunity for both myself and the coding agent.

After finishing my manual review, I compare it with the coding agent’s review. If I find something the the coding agent missed, I try to update the claude.md/agents.md file in a way that would enable the agent to find the issue next time. If the agent finds something that I missed (which happens almost every time), I try to internalize the finding to improve my own code reviewing skills. I can usually disregard a substantial portion of the agents comments, as they are either unnecessary, premature optimizations, or not real issues.

Lastly I instruct the agent to address the comments I’ve deemed legitimate, then request a review from one of my real human teammates. Usually, because there has already been such a rigorous self and agent review, they find few issues and approve the change with no suggestions. I suspect that the industry best practice of having 1-2 humans reviewing each pull request will soon go the way of the dinosaurs and we are already beginning to experiment with this for less critical changes at Moovs.

With the mind-boggling pace of innovation in AI augmented software development right now, It’s likely that my methodology will be completely outdated in a few months (or maybe even weeks). But I’ve found my current workflow to be stable for the last 2 months, and 2 months in 2025 developer time is like 2 years in 2022 developer time. In that time I’ve shipped an entirely new product line and dozens of features, all while having zero regressions or outages in production(!!!)

An important caveat to all of this is that I work on an enterprise web application written in typescript with a react front-end, nodejs backend, and sql database. This domain and my tech stack is very much so on the “data distribution” of today’s coding models, meaning they’ve been trained on an enormous amount of code that does similar things. People working in more complex domains that have less training data available, like Karpathy’s nanochat or Geohot’s comma.ai, will not get near the results that I do working on enterprise software for transportation companies.