Wednesday, October 7, 2026ArchiveSearchAsk the paper

The Computomatix Times

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

Edition of Friday, April 3, 2026

4 stories

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 ↗

Open-Multi-Agent Framework Reimplements Claude Code Orchestration Patterns

Open-Multi-Agent Framework Reimplements Claude Code Orchestration Patterns

Ivan Burazin highlights an open-source, model-agnostic multi-agent framework built from scratch by a former PM after the Claude Code source leak, with in-process orchestration deployable to serverless, Docker, or CI/CD.

Original post · 1 min read
After the Claude Code source code leak, a former PM extracted its multi-agent orchestration system into an open source model agnostic framework.

He studied the architecture, focused on the multi-agent orchestration layer (the coordinator that breaks goals into tasks, team system, message bus, task scheduler with dependency resolution), and reimplemented these patterns from scratch as a standalone open source framework without infringing on Anthropic's code.

The result is what @JackChen_x calls an "open-multi-agent." Unlike claude-agent-sdk, which spawns a CLI process per agent, this runs entirely in-process and can be deployed anywhere (serverless, Docker, CI/CD)

Check it out: github.com/JackChen-me/open-multi-agent
♥ 3.4K · ⟲ 538 · 👁 555.9KView on X ↗
AI7/10

Levelsio Warns Vibe-Coded Apps Pose Production Security Risks

Developer @levelsio says vibe coding into production is dangerous and plans to revoke database access and run apps with minimal privileges. He quotes a post reporting that LLMs hallucinate package names about 18-21% of the time, enabling 'slopsquatting' attacks.

Original post · 1 min read
Okay honestly this makes vibe coding into production very dangerous, you guys were all right

I think what I'll do is cut off all access to DBs and run it as a user with almost no privileges
Basel Ismail @BaselIsmail
URGENT PSA - New supply chain attack vector that I found WILD > AI LLMs hallucinate package names roughly 18-21% of the time.

Hackers have started pre-registering those hallucinated names on PyPI and npm with malicious payloads; they call it "slopsquatting"

You can only imagine what's next
♥ 1.6K · ⟲ 72 · 👁 430.8KView on X ↗

Tony Fadell Argues Product Management and Marketing Should Be One Job

Former Apple engineer Tony Fadell argues that splitting product management and product marketing is a mistake, citing Steve Jobs and Greg Joswiak's customer empathy as the model for owning both the product and its story.

Original post · 1 min read
Most tech companies break out product management and product marketing into two separate roles: Product management defines the product and gets it built. Product marketing wires the messaging- the facts you want to communicate to customers- and gets the product sold. But from my experience that's a grievous mistake. Those are, and should aways be, one job.

There should be no separation between what the product will be and how it will be explained- the story has to be utterly cohesive from the beginning. Your messaging is your product. The story you're telling shapes the thing you're making.

I learned story telling from Steve Jobs. I learned product management from Greg Joswiak. Joz, a fellow Wolverine, Michigander, and overall great person, has been at Apple since he left Ann Arbor in 1986 and has run product marketing for decades. And his superpower- the superpower of every truly great product manager- is empathy. He doesn't just understand the customer. He becomes the customer.

So when Joz stepped into the world with his next-gen iPod to test it out, he fiddled with it like a beginner. He set aside all the tech specs- except one: battery life.

The numbers were empty without customers, the facts meaningless without context.

And, that's why product management has to own the messaging. The spec shows the features, the details of how a product will work, but the messaging predicts people's concerns and finds way to mitigate them.

- #BUILD Chapter 5.5 The Point of PMs
♥ 2.7K · ⟲ 255 · 👁 949.4KView on X ↗