DEV Community: Eric Marchand

Debugging is also clicking 🖱️

Eric Marchand — Mon, 10 Aug 2026 03:50:10 +0000

In the last couple of posts I let agents debug over DAP —
breakpoints, step over, continue. That's real debugging. But it's only half of it.
When I debug something for real, I also click: I press the button and watch what
happens, read the dialog, notice the toggle is greyed out. No backtrace ever tells
you the Save button never enabled. So — can the agent do that half too?

The web is the easy case

Browsers are automatable by design. Most agent tools ship their own browser or
drive an external one; point Playwright at a page and
every element has a stable, queryable handle. The DOM is an accessibility tree
wearing a different hat — roles, labels, structure, all there for the reading. For
the web, this half of debugging is close to solved.

Native apps are another game

There's no DOM. When the agent has nothing to go on, it falls back to the eyeball
approach: take a screenshot, let the model look, maybe run OCR or a pre-analysis
pass to label what's on screen. It works — and sometimes it's the only option — but
it's brittle (a few pixels off and the click misses) and it burns tokens describing
pictures.

I ran into this by accident. I once wrote a tiny skill whose only job was to
screenshot a running 4D form and stitch an animated GIF for a README —
4d-capture-gif.
Then I noticed Claude Code reaching for it to debug: the skill also reports a bit
of the form's structure — where the buttons are — so the agent knows where to
click. For simple cases it genuinely works. But screenshots-plus-coordinates is not
the thing I want to build on.

The cleaner path: read the tree, don't look at pixels

Instead of staring at the screen, read the UI tree directly. On macOS you can
script the Accessibility API from Python (pyobjc), and there are automation
libraries to help. Now you're clicking element #37, the "Save" button instead of
coordinate (412, 260), and hope.

A couple of open-source tools are pushing exactly here:

agent-desktop — a native CLI that exposes any app's accessibility tree as snapshot / click / type / press with structured JSON. No screenshots, precise element references. Its progressive skeleton mode drills down the hierarchy instead of dumping it whole, cutting prompt tokens dramatically (they cite 78–96% on dense apps). And it ships a C-ABI library, so Python, Swift, Go or Node can call it in-process instead of shelling out per action. (macOS today, more platforms in progress; needs Accessibility and Screen Recording permissions.)
Open Interface — the other end of the spectrum: an LLM (GPT-4o/4V, Gemini…) reads your request, drives the real mouse and keyboard, and re-screenshots to course-correct. Demos include solving Wordle and editing a Google Doc. End-to-end agentic desktop use, screenshots in the loop.

Faire d'une pierre deux coups

Here's the thing I keep circling back to. If you build a native macOS or iOS app and
you draw your own components, there's nothing underneath them — the agent has no
tree to grab, so it's back to pixels. But if you implement the accessibility tree
for those custom components, you get faire d'une pierre deux coups — kill two birds
with one stone:

an AI agent can drive your UI by real element references, and
— the one that actually matters — people using VoiceOver, Switch Control or Voice Control can use your app.

The automation win comes for free, riding on the accessibility win. That's a rare
kind of alignment: the boring, decades-old right-thing-to-do turns out to be the
same work that makes your app agent-ready.

And Apple already tells you how, for Cocoa, UIKit and even SwiftUI. The WWDC26
session Refine accessibility for custom controls
walks through labels, values, adjustable actions and custom actions for exactly this
case — their example turns a custom coffee-dispenser control that assistive tech
could only read as a bare "button" into an adjustable one you swipe to change.
There's written guidance too — AppKit's
custom controls documentation —
and a whole library of accessibility sessions
behind it.

A 4D aside, and a note to self: I suspect that in 4D a form window is drawn as
essentially one big view, with no accessibility tree exposed underneath — which
would explain why the agent has to fall back to screenshots. That's something I want
to investigate.

Something will emerge

LLM-driven desktop automation is a moving space — open tooling and academic interest
are both growing, and I'd bet the right abstraction hasn't shown up yet. Something
will. Meanwhile, if you're drawing custom UI, the move is clear enough: give it an
accessibility tree. The people who rely on it need it — and it happens to be exactly
what an agent needs to help you debug your own app. 🖱️

Debugging with agents, à l'envers: MCP in, or DAP out? 🐛

Eric Marchand — Sun, 09 Aug 2026 06:14:43 +0000

Last month I built acpdbg: a debugger that hands
its stopped state to a coding agent over ACP, so the agent can look at the crash
and even drive lldb. I liked it. And while playing with an agent living inside the
debugger, the obvious next thought showed up.

I already have a Claude Code or a Copilot session open most of the day. So: why
not have my debugging session expose a few MCP tools — bt, frame variable,
p some_expr, step — and let the agent I already have open just call them? The
debug session becomes an MCP server; my chat agent picks up debugging superpowers.

It's tempting. It's also, I think, backwards.

Thinking à l'envers

À l'envers — "the wrong way round." Here's the tell. In acpdbg the debugger
reaches out to the agent: the debugger is the ACP client, it wakes the agent up
when the program stops. The MCP-server idea keeps that same shape — I, sitting
at a stopped process, push tools up to whatever chat agent happens to be open.
It's human-in-the-loop, and it's per-agent: I'd wire an MCP surface for Copilot,
then again for Claude, then again for the next one.

But an agent that debugs autonomously doesn't want to be handed tools by me. It
wants to reach into the debugger itself — set a breakpoint, run to it, read a
frame — on its own initiative. That's the arrow flipped: the agent as the
client, the debugger as the server it drives.

And I don't need to invent a protocol for that. It exists.

DAP already did the hard part

The Debug Adapter Protocol
is what VS Code and friends use to talk to any debugger without knowing anything
about it. Write one adapter per debugger, one client per editor, and they all
interoperate — the same N×M collapse I liked about ACP for editors and MCP for
tools, but pointed at debuggers.

If the agent speaks DAP, it isn't tied to my open session or to one vendor's tool
list. Every language with a debug adapter is suddenly reachable — LLDB for
native code, Delve for Go, debugpy for Python — through one interface. The
debugging capability lives in the agent, not in a bridge I re-bolt onto each chat.

Agents already speak it

This isn't hypothetical. oh my pi (omp,
omp.sh) is a terminal coding agent with native DAP support —
around twenty-seven operations — so it can attach to a real debugger, set
breakpoints, pause, inspect frames, read locals, evaluate expressions and step,
all on its own. For the usual suspects it works well.

So I did the obvious thing: I pointed it at an unusual language.

The 4D try

4D Server ships its own DAP server — it just listens on a fixed port (19815),
while omp likes to pick DAP ports dynamically. So the whole thing came down to a
tiny (~120-line) TCP bridge: omp-4d-dap.
Point omp at a port of its choosing, forward to 4D's, and the agent is talking DAP
to a live 4D application.

And it works. With the bridge I got real live debugging of a running 4D app,
driven by the agent: set breakpoints, step line by line, pull stack traces, and
read state — the way you're supposed to on this platform — through evaluate with
context:"watch", which returns both the value and its 4D datatype.

The agent's own Debug threads call: adapter 4d, session running, real threads
listed — then it goes for the stack trace. No editor, no me in the loop.

…with honest gaps

Not everything is there yet, and I keep a running list in the
supported-operations doc.
The short version: scopes/variables time out (hence the evaluate/watch detour),
there's no pausing a running debuggee, 4D Server never emits a clean termination
event (the client learns it's done by timing out), and the REPL runs code but
hands back an empty result. You also have to set every breakpoint before you let
the code run. Live debugging, with caveats.

But most agents don't speak DAP — yet

Here's the catch that brings my "backwards" idea back from the dead: omp has DAP
inside. Claude Code and Copilot don't. So the clean, universal path only works
today for the handful of agents that ship a DAP client.

For everyone else, the pragmatic bridge is exactly the thing I called à l'envers
— you meet the agent where it already is. Two ways to do that right now:

Documented skills — teach the agent how to debug in prose: the commands, the workflow, the platform's quirks (on 4D: set breakpoints first, read state through evaluate/watch). The agent runs a debugger through the shell it already has.
An MCP debug server — expose set_breakpoint, step, evaluate, backtrace as MCP tools, and any MCP-speaking agent picks them up. Which, yes, is my original idea — only now framed as the fallback for DAP-less agents rather than the main event.

So it's not one arrow or the other. It's: DAP when the agent has it, MCP or skills
to bridge the ones that don't — ideally over the same debug backend underneath.

So which way round?

I lean toward DAP for anything autonomous: an agent that has it shouldn't wait for
me to hand it a debugger. But most of the agents I actually use don't have it yet,
so the MCP-tools-and-skills bridge is what gets Claude Code or Copilot debugging
today. And I'm not throwing acpdbg away either — when I'm at the crash, the
debugger-drives-the-agent loop still feels right. It's a try, in every direction.

Bridge and caveats: github.com/mesopelagique/omp-4d-dap.
Tell me which way round you'd build it. 🐛

acpdbg: let the agent sit at the debugger 🐛

Eric Marchand — Sat, 11 Jul 2026 11:08:35 +0000

I had an idea, and it starts from a habit.

LLM agents are genuinely good at static analysis: give them a backtrace and
the source around it, and they usually spot the bad pointer before I do. So what
do I actually do when a native program crashes? I copy the stack trace from the
debugger, paste it into the agent's context, then copy the source of the
functions involved, paste again… I'm the transport layer between two programs
that both live on my machine.

That's the idea: why not let the agent look at the lldb debug data itself —
and even control the debugging?

I already wrote about ACP, the Agent Client Protocol —
the standard that lets any agent talk to any client. Usually the client is an
editor. But nothing says it has to be. A debugger is a perfectly good ACP client
too. So I built one.

acpdbg

acpdbg is an LLDB assistant. When your
C/C++/Rust/Swift program stops — crash, signal, or breakpoint — it captures an
enriched snapshot (backtrace, every frame's live arguments, surrounding source)
and hands it to your coding agent over ACP: GitHub Copilot CLI, Gemini CLI, or
Claude Code through its ACP adapter.

The part I like most: the agent doesn't just read a frozen report. Through a
small MCP tool bridge it can run live debugger commands against the stopped
process — bt, frame variable, p some_expr — to confirm its hypothesis
instead of guessing. And with the opt-in control mode, it gets step_over,
continue_execution, set_breakpoint… so it can debug like a human would:
set a breakpoint, run to it, step, watch the state evolve.

Try it fast

The whole loop works offline with a bundled mock agent, nothing else to install:

pip install acpdbg
git clone https://github.com/phimage/acpdbg && cd acpdbg/samples
make                # builds ./crash with -g
acpdbg -- ./crash   # runs it; on the crash the agent explains

Swap in a real agent for real analysis:

acpdbg --agent copilot -- ./crash

Real output from that command:

acpdbg → copilot (investigating…)

Confirmed live: `s` is 0x0000000000000000 — a NULL pointer — right where
strlen(s) dereferences it.

Root cause: in main, `name` is NULL when the program runs with no arguments,
and describe() hands it to strlen() with no check.

One-line fix: return s ? strlen(s) : 0;

Inside lldb — and inside Xcode

It's also a plain LLDB plugin. Install it once:

acpdbg --install-lldbinit --agent copilot

and every lldb session — including Xcode's debugger console — gets new
commands. Stop anywhere (a crash, a breakpoint, a watchpoint) and just type:

(lldb) ask why is `retry_count` already 3 here?
(lldb) copilot in one sentence, why did this stop?
(lldb) claude what would you change to fix it?

Each installed agent gets its own command, so you can get a second opinion from
another model without touching the config.

It's a try

I don't claim this is the way to debug. It's an experiment: the interesting
part for me is that ACP made it cheap to build — I wrote a client once, and
every ACP-speaking agent works with it, today's and tomorrow's. The same
N×M collapse I liked about the protocol in editors, applied to a debugger.

Code, docs, and caveats: github.com/phimage/acpdbg.
Tell me where it breaks. 🐛

Pipeline, Flow, or Chain? Picking the Right Tool to Wire LLM Calls Together

Eric Marchand — Sat, 11 Jul 2026 09:44:51 +0000

In the previous post I argued that agents are great
planners and DAGs are great executors. This one is the practical follow-up: when
you actually sit down to wire several LLM calls together, what tool do you reach
for?

Because the moment one prompt's output feeds the next, you've built a workflow —
whether you call it that or not.

download transcript → summarize → translate
       (tool)          (LLM)       (LLM)

That tiny pipeline is already the whole problem in miniature: a non-LLM step (fetch a
YouTube transcript), then a model call, then another model call that depends on the
first. Run it as one giant prompt and you lose visibility; split it into steps and you
gain debuggability — at the cost of more calls and more state to manage.

The naming trap

Half the confusion is vocabulary. The same idea ships under a dozen labels:

Name	What it whispers
Chain	sequential, output → input
Pipeline	stages, data flowing through
Flow	branches and conditions
Workflow	general orchestration
Agent workflow	the model also decides

The word sets expectations. "Chain" promises a straight line; "agent workflow"
promises the thing might re-plan on you mid-run. Pick the label that matches how much
autonomy you're actually handing over — calling a deterministic two-step pipeline an
"agent" only invites disappointment.

The real choice: library or orchestrator?

There are two families of tools, and they solve different problems.

LLM-native chaining libraries — LangChain,
LlamaIndex Workflows,
Azure Prompt Flow,
or visual layers like Flowise. These understand
LLM-specific concerns out of the box: prompt templating, passing context between
steps, token budgets, streaming, retries on a flaky model.

General orchestrators — Airflow,
Prefect, AWS Step Functions,
Azure Logic Apps. These treat
each LLM call as just another task in a DAG, and give you the heavyweight reliability
machinery: durable state, scheduling, checkpointing, audit trails, human approval.

The rule of thumb that falls out of the last post:

Few prompts, mostly LLM glue   → chaining library
Many steps, must not fail      → orchestrator (LLM call = one task)
The model decides the path     → agent, with one of the above underneath

When you don't need either

Don't reach for a framework reflexively. If the task is genuinely simple, one
well-crafted prompt (few-shot or chain-of-thought) often beats a three-step pipeline
— fewer calls, less latency, nothing to orchestrate. Chaining earns its keep when
subtasks are distinct enough that isolating them actually improves accuracy and lets
you debug each one independently. The cost is real: every extra hop adds latency, and a
weak early step poisons everything downstream.

A concrete chain

To get a feel for the moving parts I built PromptKit,
a small 4D toolkit where a chain is just named prompts piped together — the YouTube
example above, minus the download step:

var $result:=$runner.newChain().prompt("summarize").prompt("translate").run($transcript)

// $result.text     -> final translated summary
// $result.outputs  -> each step's output, for inspection

Nothing exotic — but writing it made the trade-offs tangible: where state lives, what
happens when step two fails, how you'd add a branch. Which is really the point. You
don't pick the tool by reading the marketing; you pick it by knowing whether your
problem is LLM glue or reliable execution — and most of the time, it's a bit of
both.

My take: "chain vs. workflow vs. agent" is less an architecture question than an
honesty question — how deterministic is your process, really? Name it accordingly,
then pick the lightest tool that survives the day you actually need a retry.

When Agents Become Planners, What Remains of Workflow Orchestration?

Eric Marchand — Sat, 11 Jul 2026 09:44:44 +0000

For years, software automation has been built around a simple idea: define the
process, then execute it. Whether using a script, a workflow engine, or a DAG, the
principle is always the same:

A → B → C → D

The developer knows the steps in advance.

AI agents challenge this model. Instead of defining how to achieve a goal, we
increasingly define what we want and let the agent figure out the steps.

This reminds me of the difference between traditional programming and agentic
programming.

Traditional Programming	Agentic Programming
Define the algorithm	Define the objective
Deterministic execution	Probabilistic execution
Every path is known	Paths emerge dynamically
Optimized for reliability	Optimized for adaptability

When the process is well known, code is often the best solution. When the process is
uncertain, constantly changing, or requires exploration, agents start to shine.

A useful way to think about it is:

Known problem    → Code
Known process    → Workflow
Unknown process  → Agent

This is why some people argue that traditional orchestrators such as
Apache Airflow or
AWS Step Functions are not well suited for
agentic systems. AI agents are fundamentally non-deterministic. They may decide to use
different tools, follow different paths, or even change their plan while executing it.

A static DAG cannot describe every possible future path.

But does that mean workflow orchestration is becoming obsolete?

I don't think so.

Even the most advanced agents still need:

State persistence
Retries
Checkpointing
Human approval
Scheduling
Audit trails
Observability

In other words, they still need many of the things workflow engines have solved for
years.

The architecture is simply evolving.

Yesterday we had:

Workflow Engine
       ↓
      Tasks

Tomorrow we may have:

Agent
  ↓
Execution Engine
  ↓
Tools

The agent becomes responsible for planning. The orchestration layer becomes
responsible for reliable execution.

This is why I don't believe DAGs are disappearing. They are simply moving down a layer.

The mistake is thinking agents eliminate workflows. What they really eliminate is the
need to define every workflow in advance.

Agents are excellent planners. Workflows are excellent executors.

The future may not be Agents vs DAGs. It may simply be:

Agents for planning. DAGs for execution.

Worth reading

Advanced LangGraph Orchestration — Enterprise-Ready AI Workflow Management
Agentic AI and Temporal Orchestration — pairing agents with Temporal for durable execution
Apache Airflow · AWS Step Functions — the classic DAG-based orchestrators
GraphBit: A Graph-based Agentic Framework for Non-Linear Agent Orchestration — agents and graphs, together
Observability for Delegated Execution in Agentic AI Systems — the execution-layer concerns that don't go away

As a side project, and to better understand what happens inside a workflow engine, I'm
also experimenting with implementing a DAG engine in 4D. It started as a task scheduler
but evolved into a good opportunity to explore orchestration concepts from the inside.

The project is available here:
mesopelagique/Scheduler — Dag.md

A quick word on where I'm coming from: my hands-on experience with DAGs proper is
limited to Airflow for ML pipelines — pulling data from
the data warehouse, cleaning it, transforming it, and feeding the next stage. Beyond
that, as a developer I mostly live in CI tooling —
GitHub Actions,
GitLab CI,
TeamCity — which share a lot of common ground
with workflow engines: stages and dependencies, retries, caching/artifacts,
conditional steps, and approvals. Different vocabulary, same orchestration instincts.

macOS 27's AI dev ecosystem — and pointing 4D AIKit at a local model 🍎

Eric Marchand — Sat, 11 Jul 2026 09:44:36 +0000

For a year, Apple's on-device model was walled off — reachable only from Swift,
only inside an app you built in Xcode. macOS 27 tears that wall down. The same
Foundation Models are now scriptable from the terminal and from Python, and there's
a real framework story forming around them. Three pieces worth your attention.

Two models: System and PCC

There's now a hybrid setup with two tiers:

system — the on-device Apple Foundation Model. Default, free, fully private, nothing leaves the Mac.
pcc — a larger model on Private Cloud Compute. More capable, but subject to daily usage limits (higher caps come with paid iCloud+ tiers).

You pick per call, so the cheap private one is the default and you reach for PCC
only when a task needs the extra horsepower.

The `fm` CLI

fm comes pre-installed with macOS 27 — no install, just update and type fm.
It's built for scripting and automation, not just chatting:

The commands cover the obvious ground — one-shot generation, interactive chat,
token counting, JSON schema generation, plus availability and quota checks:

fm respond 'What is Swift?'
fm respond --model pcc --stream 'Summarize this article'
fm chat --instructions 'You are a coding assistant'
fm token-count 'Hello world'
fm schema object --name Person --string name --int age

The part that matters: `fm serve`

Here's the one most WWDC recaps skipped. fm serve starts an
OpenAI-compatible Chat Completions server, loopback-only:

url     http://127.0.0.1:1976
access  loopback-only

  · POST /v1/chat/completions
  · GET  /v1/models
  · GET  /health

OpenAI-compatible is the magic word. It speaks the same /v1/chat/completions dialect
as every other provider, so any software or library that already talks to an
OpenAI-style API can point straight at it — your existing client, SDK, agent
framework, or tool, unchanged beyond swapping the base URL to
http://127.0.0.1:1976/v1. Whatever you've already wired up for OpenAI now drives an
Apple Foundation Model (on-device or PCC), with no API key and no cloud bill.

For me that lands on 4D AIKit: point its base URL at
the local server and the same 4D code I'd aim at a remote provider runs against a local
model, no new component. But the point is general — anything OpenAI-compatible gets a
free local backend. That's a genuinely useful default for prototyping, and for anything
privacy-sensitive, maybe the production default too.

For the Python crowd, there's also an official
Foundation Models SDK for Python.

Core AI + a maturing Foundation Models framework

Alongside the CLI, Apple shipped Core AI —
a framework for running AI models directly in your app on Apple silicon — and a
solid round of upgrades to
Foundation Models.
The framework now has the pieces that were missing: tool calling, context and
conversation history, multimodal input (images, vision), and server-model access
behind the same Swift API. It's starting to look like something you'd actually
ship on, not just demo.

Worth reading

The pattern, again: a model that used to be locked inside one language and one app
becomes a local server speaking a standard dialect — and the moment it does, every
tool that already speaks that dialect (AIKit included) gets it for free. 🍎

EDIT — wait, I had `fm` first 😅

Funny postscript: I'd already built my own fm. Back when I wrote the
Apple Foundation Models post (mid-2025), I made a
little command-line tool — phimage/FoundationModelCli
— specifically so I could type fm and poke at Foundation Models from the terminal.
A year later Apple shipped a CLI with the exact same name. No collision, no hard
feelings… but for the record, I was running fm first. 🙂

ACP: Copilot in Xcode, without the plugin 🔌

Eric Marchand — Sat, 11 Jul 2026 09:44:24 +0000

There's a new standardization layer in the agentic-coding stack, and it's a good
one: the Agent Client Protocol (ACP). After MCP standardized what tools an
agent can reach, ACP standardizes how editors and agents talk to each other —
local or remote — so any ACP agent drops into any ACP editor with no bespoke,
per-vendor glue. It's developed in the open (JetBrains and Zed), and there's a
clean introduction if
you want the protocol view.

The reason this matters today: Xcode 27 speaks ACP. (It's in the developer
beta, and it's already turning up in the
26.6 RC.)

MCP vs ACP, in one line

Xcode 27 actually has two protocol layers, and it's worth keeping them straight:

MCP decides what an agent can do inside Xcode — read files, build, run tests, pull diagnostics.
ACP decides which agents are even allowed to connect in the first place.

So ACP is the front door, MCP is the toolbox once you're inside. Apple shipped
GitHub and Figma as launch plugin partners — but because the door is a standard,
you don't actually need their plugin. Any ACP-speaking agent can knock.

The trick: register Copilot CLI as a raw ACP agent

Copilot CLI can run as an ACP server, so you can wire it straight into Xcode
instead of installing the official plugin. In Xcode → Settings → Intelligence →
Coding Intelligence → Add an Agent…:

Name: Copilot
Executable: /opt/homebrew/bin/copilot (wherever Homebrew put it — which copilot)
Arguments: --acp

That's the whole registration. Xcode notes that ACP agents get full use of Xcode
and your project context, and it asks for consent before a new agent connects —
the protocol is permissioned by design, not a backdoor.

Pick your model with an env var

The fun part: you're not locked to one model. Add an Environment Variable to
the agent and pin whichever model you want — for example:

COPILOT_MODEL=claude-sonnet-4.6

So you get Copilot's harness and auth, driving the model of your choice, inside
Apple's IDE. "Use any LLM in Xcode" is barely an exaggeration.

Under the hood

If you want to see what Xcode is launching, the CLI flag is documented. --acp
defaults to stdio mode (ideal for an IDE spawning the process); add --port
for TCP instead:

copilot --acp --stdio      # stdio (default when --acp is passed)
copilot --acp --port 3000  # TCP

One caveat worth flagging: ACP support in Copilot CLI is still public preview,
so flags and behavior may shift. Tool-filtering and reasoning-effort flags, if you
pass them, apply per session started by the client.

Worth reading

The bigger picture: the N×M integration problem — every editor needing a custom
connector for every agent — collapses to N+M once both sides speak a shared
protocol. MCP did it for tools; ACP is doing it for the agents themselves. Xcode
adopting it this fast is the surprise. 🔌

DEV Community: Eric Marchand

Debugging is also clicking 🖱️

The web is the easy case

Native apps are another game

The cleaner path: read the tree, don't look at pixels

Faire d'une pierre deux coups

Something will emerge

Debugging with agents, à l'envers: MCP in, or DAP out? 🐛

Thinking à l'envers

DAP already did the hard part

Agents already speak it

The 4D try

…with honest gaps

But most agents don't speak DAP — yet

So which way round?

acpdbg: let the agent sit at the debugger 🐛

acpdbg

Try it fast

Inside lldb — and inside Xcode

It's a try

Pipeline, Flow, or Chain? Picking the Right Tool to Wire LLM Calls Together

The naming trap

The real choice: library or orchestrator?

When you don't need either

A concrete chain

When Agents Become Planners, What Remains of Workflow Orchestration?

Worth reading

macOS 27's AI dev ecosystem — and pointing 4D AIKit at a local model 🍎

Two models: System and PCC

The fm CLI

The part that matters: fm serve

Core AI + a maturing Foundation Models framework

Worth reading

EDIT — wait, I had fm first 😅

ACP: Copilot in Xcode, without the plugin 🔌

MCP vs ACP, in one line

The trick: register Copilot CLI as a raw ACP agent

Pick your model with an env var

Under the hood

Worth reading

The `fm` CLI

The part that matters: `fm serve`

EDIT — wait, I had `fm` first 😅