Writing code has become cheap. A coding agent can produce a plausible change to a real project in seconds. What has not become cheap is knowing whether the change is right. The value of a coding agent in 2026 lies less in how much it writes than in how clearly it shows what it did and what happened when the tests ran.
Use is near universal; trust is not
The Stack Overflow Developer Survey for 2025 asked tens of thousands of developers about AI. 84% use or plan to use AI tools in their development process, and 47.1% use them daily. Yet only 32.7% trust the accuracy of what those tools produce, while 45.7% distrust it. The most common frustration, cited by 66%, is AI solutions that are almost right, but not quite.
Agents are arriving too: 30.9% of respondents use AI agents at work at least monthly, and 17.4% more plan to.
Those figures describe a gap between adoption and confidence. Developers are using the tools heavily and checking them heavily, because an answer that is almost right costs time to find and fix.
Perceived speed and measured speed can diverge
The sharpest measurement of that cost came from METR. In a randomised trial published in July 2025, 16 experienced open-source developers completed 246 real issues in their own repositories, with and without AI tools of the early-2025 generation. With AI allowed, they took 19% longer. Before the study they had expected a 24% speedup, and afterwards they still believed they had been sped up by about 20%.
METR has since said those results are out of date. In February 2026 it reported that developers are likely more sped up by AI tools in early 2026 than in early 2025, while cautioning that selection effects in its newer data make it only very weak evidence for the size of the increase. Developers increasingly declined to work without AI at all, which is itself a measure of how embedded the tools have become.
The lasting lesson from both reports is about evidence. A developer's sense of how much an agent helped can be badly wrong in either direction. What settles it is a measurement: did the change work, and how do we know?
Done means the tests ran
Livgens Programmer is built around that measurement. It is a coding partner in the terminal and in the browser. It reads your project, writes and edits files, runs your tests and shows its work.
Its four capabilities, all available now, follow the order a careful engineer works in. Read: your project, as it is, before it changes anything. Change: files written and edited, each change shown. Verify: your tests run after the change, and the result reported. Reach: Blender, Unreal Engine, Ableton Live and the rest, only through Render and Looper, each step gated by what it does.
The rule that governs them is short. Done means the tests ran. A change is reported with what passed and what did not.
That rule answers the frustration in the survey directly. An almost-right change that is reported as finished costs the reader a search. An almost-right change reported with the failing test beside it costs the reader a glance. The report is the representation of what happened, and its value is that it is exact, including about failure.
Reading before changing
The first capability is easy to skip and expensive to miss. An agent that edits a project it has not read produces changes that compile against its assumptions and fail against the codebase. Programmer reads the project as it is before it changes anything.
This is the same discipline Livgens applies everywhere else. Render reads a scene before it touches it, makes one change and checks the change is what it said. Looper reads Live again after every change and compares. Programmer reads the code, makes the change, runs the tests and reports. Look, act, look again.
How much it may do on its own
Different work deserves different latitude. Programmer offers modes: ask, or let it act. You choose how much it may do on its own, and change it any time. A careful refactor of payment code and a sweep of formatting fixes call for different settings, and the choice stays with the person.
Reach beyond the codebase is gated more tightly still. When Programmer works with Blender, Unreal Engine or Ableton Live, it does so only through Render and Looper, and each step is gated by what it does. The tools that touch scenes, sessions and stages carry their own rules, and Programmer inherits them.
Why the browser matters
A coding agent in the terminal is powerful for the person at that terminal. A coding agent in the browser changes who can review the work and from where.
On the web, Programmer keeps your workspace between visits, with its file tree and every change to review. Work started in one session is there in the next. The changes are laid out to be read, one by one, alongside the result of the tests. That turns the agent's output into something that can be inspected at leisure and from any machine, which is exactly what the trust gap calls for.
Sign-in uses the same Living Worlds account that runs across Livgens and Living Worlds Lab, by password or passkey.
What good looks like
The state of coding agents in 2026 points to a clear standard. An agent should read before it writes. It should show every change. It should run the tests and report the result as it is, failures included. It should let a person decide how much it may do alone. And its work should be reviewable wherever the person reviewing it happens to be.
Each of those is a way of making the agent's work measurable. Measured work can be trusted to the degree the measurement allows, and no further, which is the right amount.
Where Livgens fits
Livgens represents the thing exactly, in sound, light, matter and motion, and Living Worlds runs it forward through its lifecycle. Livgens Programmer writes code with you on the same API and SDK, in the terminal and in the browser, and is in early access. It works under the same rules as the rest of Livgens: the same checks, and the same person asked before anything real happens. Sign in with your Living Worlds account; if Programmer is not yet open to the account, request access.
