Lilith.
⌕
Editorial illustration: web-edit 0.1a1 shows one model profiling while another fixes
Lilith illustration · editorial remix

Simon Willison released web-edit 0.1a1, a web application for editing files in a folder. His brief release note says it includes performance optimizations written by Claude Opus 5.5 after it received a Python 3.15 profiling report produced by GPT-6 Astra.

Two models split measurement from code changes

The public note describes an unusually clean division of labor. GPT-6 Astra prepared the profiling report, Claude Opus 5.5 wrote optimizations from it and Willison included the changes in version 0.1a1.

The source gives no benchmark, specific hotspot or size of the speedup. It therefore cannot support a claim that the application became faster by a particular percentage or that the models beat an experienced developer. The process is documented, while the performance result is not.

Profiling gives a coding agent a narrower, testable assignment

For a development team, the important detail is that the second model did not receive a vague instruction to make the application faster. It worked from a measurement artifact. That narrows the search toward expensive code paths and gives a reviewer a concrete trail for checking the patch.

This separation of roles may be more useful than searching for one model that does everything. One system prepares the diagnosis, another proposes the intervention and a human decides whether both the measurement and the fix make sense.

Without a benchmark the optimization proves process, not speed

A model-generated profiling report can be misread, and a patch can improve one scenario while hurting another. The release note does not say whether Willison measured the application before and after the change, which tests he used or whether the optimization preserved identical behavior.

That is the boundary of the story. We have a publicly described chain of work, but no data that turns it into evidence of better performance.

A reproducible profile and diff will reveal the real value

The most useful follow-up would be the profiling report, the exact diff and a comparison of the same workload before and after the change. Only that combination would let other developers judge whether the models removed a real hotspot.

For similar experiments, the audit trail will matter most. Teams that connect measurement, proposed change, tests and the resulting benchmark can repeat the workflow without trusting a model on reputation alone.

Lilith's verdict

One model brought the X-ray, another picked up the scalpel and Willison signed the surgical record. Without results from before and after the procedure, we still do not know whether the patient actually runs faster.

I keep the external link at the end. First, a concise explanation here — no hunting across someone else's site.

Original source ↗ ↗