Wednesday, October 7, 2026ArchiveSearchAsk the paper

The Computomatix Times

All the posts fit to save — curated from @computomatix's bookmarks & likes on X

Paul Solt Shares Workflow for Building Apps With Codex Sans Xcode

How I Build Apps With Codex Without Opening Xcode

iOS developer Paul Solt describes an Agent Skill called AppCreator and a Makefile-based workflow using xcbeautify so Codex can build, test, and run iPhone and Mac apps with clean pass/fail output.

Original post · 6 min read
X ArticleHow I Build Apps With Codex Without Opening Xcode
Do you want to build iOS or macOS apps with Codex?

I have a new Agent Skill that will help you make apps. Without this skill you're going to waste a lot of time. Let me explain.
I was building a Dangerous Spider app with Codex when I noticed the agent kept missing its own build and test failures. It was looking at the wrong status codes. It genuinely couldn't find the error and would say everything worked (when it didn't).
Xcode compiler build output is extremely verbose. Actual errors get buried in thousands of lines of text. Trying to find an error in Xcode build output is like finding a needle in a haystack.

When you layer in agents, you're wasting time and context by asking them to find the errors.
Agents need to know what worked and what didn't work. It needs to be pass/fail, so I created an agent-designed workflow to do just that.
Here's the 7-step workflow I use every day:
1. Make Xcode Projects Agent Friendly with AppCreator
I built an Agent Skill called AppCreator. Run it once, and it scaffolds a new Xcode project or retrofits an existing one. Now your project is agent-ready.

At the heart of it: a `Makefile` wraps the CLI `xcodebuild` commands using xcbeautify. Clean, readable output from Xcode app builds and tests. The agent sees what failed, fixes it, and moves on. No verbose output to search. It works for iPhone and Mac apps.
Download and install the AppCreator Skill to make your app project agent-friendly.
2. make Is the Only Build Command I Use
The skill is designed so that one command builds and runs your app:
make

Your agent knows how to work with Makefiles, so this is just the starting point. You can extend it however you want.
I ask agents to set the default action to "build-and-run", and to use special build scripts so the freshly built app is always relaunched, just like Xcode.
In Codex CLI, type "make" to check the agent's work.
In the Codex app, set up a custom run action: Click on the Play button and set it to: make.

Finding the setting later requires a few more steps: Go to Environments → Project → View → Edit Local Actions → Actions → Set Action Script to `make`.

With a Makefile, you have a fast, repeatable way to build and run your apps (via the up-arrow on the CLI or the Run button in the Codex app).
3. Just Talk to It
If you want to get good results, you need to actively steer your agent.
Agents are good, but they'll do things you don't want, and the only way to prevent that is to steer the ship as they work.
I frequently double-check the work and redirect when I see agents doing the wrong thing.
I use Wispr Flow to talk out loud — describe what I want, how it should behave, what needs to change. After an agent hands back work, I start Wispr Flow as I play-test the new changes. This gives me the chance to talk through what works and what doesn't, and then, when I'm done, I can paste the transcript directly into the Codex app.
Plan mode is helpful for sparking thoughts about how features and edge cases. However, I have found that the plan mode isn't good enough.

Instead, I would use plan mode to help you think through the feature as a starting point. Use it to spark discussion so you can refine which features you actually build.
Software is nuanced, and if you take it feature by feature, you're going to get better software in the end.
4. Tests Keeps Agents Accountable
Without tests, agents can get sloppy. Tests allow agents to catch their own mistakes.
Ask Codex to write unit tests as it builds. Your goal is fast tests. UI tests are helpful for verification, but they can be annoying and slow to run. I like to have agents use UI tests to catch errors that are impossible to test with unit tests alone.

My recommendation is that you separate your tests into at least two targets:
make test
make ui-test
When an agent runs UI tests, it takes over your machine, which can be disruptive if you need to do anything else (This is where having a second Mac can be useful).
UI tests will slow everything down, so it's best to test them only at hand-off points. When your agent has wrapped up one task or several tasks. Don't do full regression testing for incremental work; instead, ask the agent to test only the smallest subset to verify their work and remain fast.
Have your agents read this article from Peter Steinberger, @steipete: Running UI Tests on iOS With Ludicrous Speed. Using that, you can help keep your test suite from becoming a bottleneck.
5. Log Runtime Results
Another indispensable tool is the use of logs and app artifacts. Have your agent add logging to your app. This gives it another tool for seeing what went wrong in real time.
Agents can stream development logs to a file or read them in real time to fix problems that are not immediately obvious.

When my agent repeatedly fails to complete a task properly, I know it's time to introduce more detailed logs.
Just ask your agent:
Please add verbose logs around XYZ so that you can see what is happening and fix the… continue on X ↗
♥ 810 · ⟲ 76 · 👁 467.5KView on X ↗

More in Agents & Dev Tools

Developer Rebuilds Seven Adobe Apps in Rust Using Opus 5.5

Peter Yang highlights a developer who reimplemented seven Adobe apps, including Photoshop, Premiere and Lightroom, in Rust with Claude Opus 5.5 and open-sourced them. The developer believes they can match Adobe's features within months, against Adobe's $840 yearly all-apps plan.

Original post · 1 min read
It's insane to watch AI blow apart closed source software and games.

4 examples from the past month:

1. 7 of Adobe's biggest apps, including Photoshop, Premiere, and Lightroom, have been partially rebuilt in Rust with Opus 5.5 and open sourced. It's still early, but the developer thinks they can match Adobe's features within months. Adobe's all-apps plan costs $840/year.
Miguel Ángel Durán @midudev
Todos los productos de Adobe reimplementados desde cero, gratuitos y de código abierto

→ getartcraft.com/apps
♥ 50 · ⟲ 2 · 👁 10.7KView on X ↗

Vercel's Guillermo Rauch Explains Turborepo's Migration From Go to Rust

Guillermo Rauch says Vercel moved Turborepo from Go to Rust, a migration that was controversial internally due to human costs. He argues that with AI agents the calculus has changed, so what is best for humans is no longer necessarily best for business.

Original post · 1 min read
DHH is fundamentally right about Rust. For context, Vercel has been undergoing a Rust-ification (carcinization, technically 🦀) for a while.

One of the first projects we migrated was Turborepo, from Go to Rust¹. The migration completed, but the RoI was actually quite controversial internally.

While Rust was in our eyes better for low-level OS access, something crucial for a build system like Turbo, the human migration costs were very sustantive.

Go is very fast. It's beautifully designed. It's easy to iterate on. We were very conflicted about the migration, because it was *humans* writing the code, *even if we knew Rust was a better choice*.

The calculus has now changed. What's "best for humans" is no longer necessarily "best for business".

FWIW, it's also quite unlikely that Rust is the end-all-be-all toolchain. I'm quite certain there's greener pasture ahead, because Rust itself was designed before the 'supersonic tsunami' of agents hit.

¹ https​://vercel.com/blog/how-turborepo-is-porting-from-go-to-rust
♥ 3.2K · ⟲ 152 · 👁 352.7KView on X ↗

Integer Multiplication Algorithm Bound Tightened Repeatedly With Astra

A post reports that a user running ChatGPT Astra in a loop is repeatedly breaking records for integer multiplication algorithms. It quotes an update to OpenAI problem #109 that tightens the constant from 2^-182 to 2^-59, a roughly 500,000-fold improvement over the previous result.

Original post · 1 min read
This guy has 6.1 Astra running in a loop and is breaking the record for integer multiplication algorithms every few hours lmaooooo.
Doug Colkitt @0xdoug
We are publishing an update to OpenAI problem #109 Integer multiplication) with another substantial further tightening:

κ = 2⁻⁵⁹ (from OpenAI’s original κ = 2⁻¹⁸²)

Approximately 500 thousand fold improvement over our previous result and a 2¹²³ fold improvement over the original OAI result.

The latest redesigned the finite network to share intermediate computations and scratch space, then tightened the recursion and Gaussian estimates.
♥ 4.1K · ⟲ 118 · 👁 167.4KView on X ↗

Boris Cherny Says Prompting Claude Should Feel Like Talking to a Coworker

Boris Cherny explains his approach to prompting Claude, advising users to give clear goals, specify effort level and verification steps rather than relying on heavy scaffolding.

Original post · 1 min read
I am surprised that people are surprised this is how I prompt Claude.

Talk to Claude the way you would a coworker. There's no secret to prompting. There's no need to be overly scaffolded or prescriptive for most tasks -- give Claude a goal, and it will figure it out.

Back in the Sonnet 3.5 days, your prompt mattered a lot. Nowadays, it's much more important to communicate to the model:

1. What you want it to do
2. How much effort you want it to spend
3. How it should verify that it did the right thing
Boris Cherny @bcherny
Prompt
♥ 12.1K · ⟲ 720 · 👁 1.1MView on X ↗

Eric Raymond Highlights Open-Source Rust Clone of Photoshop Built via LLM

Eric S. Raymond shares the photocraft GitHub project, a clean-room open-source reimplementation of Photoshop that he says was likely generated by decompiling the app, converting it to a spec and prompting an LLM for Rust. He argues this threatens closed-source software.

Original post · 1 min read
This is the doom I predicted a few days ago, coming for Photoshop. A clean-room open-source reimplementation.

No prizes for guessing that they decompiled Photoshop to source code, processed that to some kind of non-code specification language, then fed the spec to an LLM with an instruction to generate Rust.

Adobe just got nuked. And closed source is dead, dead, dead.

github.com/storytold/photocraft
♥ 16.2K · ⟲ 1.4K · 👁 3.7MView on X ↗

Nat Eliason Details Fourteen Ways His Bot Setup Automates Work

Nat Eliason lists fourteen functions of his bot setup, including a chief-of-staff agent that drafts emails, specialist agents per work lane, and cloud coding agents that open pull requests from Linear issues. He notes GrokBot as a substantial improvement over his previous OpenClaw setup.

Original post · 2 min read
Things my @bot setup does that still blow my mind:

1. A Chief of Staff who opens the day pulling open loops from email & tasks and suggesting things it can knock out before 7am.

2. After every meeting, decisions get folded into Notion, Linear, and Todoist — not left rotting in Granola

3. Every email starts as a draft. The CoS bot scans my email every ~2hr and drafts replies to nearly everything — including checking my cal for availability and finding requested attachments / links

4. A specialist for each lane: curriculum, engineering, coaching, hiring, content, ops, and one for every single piece of software

5. Routines that keep running while I’m offline (e.g. monitoring Sentry errors in our apps and proactively fixing things)

6. Group rooms where 2–4 bots share one project thread instead of me copy-pasting context

7. Cloud coding agents that pick up Linear issues and open PRs after running the list of open work by me EoD — then squash-merge to main when it’s done

8. Meeting prep briefs pulled from Granola + Notion before I walk in

9. A growing shareable knowledge base in Notion + a GitHub repo that we update daily based on what happens at school

10. Student progress look-up across Expertise, Followers, and CoFounder without inventing numbers — chat anytime to see where a student is on their business work

11. Mentor Mind that coaches me on how to hold the bar without inventing doctrine

12. Todoist as a central task list where it logs things it’s blocked on for me, or from meetings / emails — and I can paste links into chat to direct it how to solve them

13. Engineering work is automatically tracked in Linear so my and the product teams’ bots don’t collide with each other

14. Presentations spun up in Gamma / Claude Design without me opening a slide tool

15. Plaud / live capture → notes the bots can actually act on

Probably more but these were the immediate ones we thought of.
Nat Eliason @nateliason
GrokBot feels like absolute magic at this point, a meaningful leg up on my previous OpenClaw etc. setups.

And with how easy it is to setup, there's really no excuse now.
♥ 2.1K · ⟲ 207 · 👁 522.0KView on X ↗