Magistr and Maps
blog

The IDE is a text editor with extras: a map and a reading list

803 words4 min

Disclaimer: the research behind this page was AI-generated: gathered and written by Claude using swamp workflows and Exa search. Check the linked sources before relying on a summary.

Developers spend more than half their time working out how a system behaves before they can decide what to change (Girba & Wardley, Rewilding ch. 2). The mainstream IDE still puts most of its effort into writing code: a text editor over files, plus a language server and a debugger. Writing code is also the part that coding LLMs now push toward commodity. That leaves understanding the system as the open problem, and two industries are trying to solve it from opposite directions.

其ノ壹 01 / 08

The map

wardley-beta
title Developer environments: understanding vs. writing code
size [1100, 720]
anchor Developer [0.97, 0.55]
component Changing a system safely [0.89, 0.50]
component Understanding the system [0.80, 0.25]
component Writing code [0.78, 0.82]
component Agent orchestration workspace [0.70, 0.30]
component Generated views [0.64, 0.10]
component Moldable views [0.60, 0.24]
component Spatial code canvas [0.47, 0.14]
component Notebooks [0.52, 0.66]
component Text editor [0.60, 0.95] label [-95, 4] (inertia)
component Language server [0.50, 0.88] label [-125, 4]
component Debugger [0.42, 0.74]
component Generic object inspector [0.34, 0.82] label [-195, 4]
component Live object environment [0.34, 0.28]
component Coding LLM [0.28, 0.62]
component Source as text files [0.20, 0.94] label [-165, 4] (inertia)
component Compute [0.06, 0.96] label [-70, 4]
Developer -> Changing a system safely
Changing a system safely -> Understanding the system
Changing a system safely -> Writing code
Understanding the system -> Moldable views
Understanding the system -> Generated views
Understanding the system -> Spatial code canvas
Understanding the system -> Debugger
Understanding the system -> Notebooks
Writing code -> Text editor
Writing code -> Agent orchestration workspace
Agent orchestration workspace -> Coding LLM
Generated views -> Coding LLM
Moldable views -> Live object environment
Moldable views -> Generic object inspector
Spatial code canvas -> Source as text files
Text editor -> Language server
Text editor -> Source as text files
Language server -> Source as text files
Debugger -> Generic object inspector
Generic object inspector -> Compute
Live object environment -> Compute
Coding LLM -> Compute
evolve Writing code 0.95
evolve Moldable views 0.42
evolve Agent orchestration workspace 0.55
evolve Coding LLM 0.85
note "Glamorous Toolkit, Clerk, Portal" [0.565, 0.25]
note "Roer" [0.70, 0.03]
note "Code Bubbles, Debugger Canvas" [0.425, 0.03]
note "Intent, Cursor 2.0, Agor" [0.665, 0.33]

How to read it:

  • Writing code is moving to commodity. Agents write a growing share of it.
  • Understanding the system sits in genesis and custom. It needs a different tool for each question.
  • Moldable views (Glamorous Toolkit, Clerk, Portal) make those tools cheap to write by hand, on top of a live object environment.
  • Generated views (JetBrains Roer) let an LLM draw the tool on demand. They are cheaper still, but there is no live object graph underneath.
  • Agent orchestration workspaces (Intent, Cursor 2.0, Agor) bet on the opposite: you write the spec, and you read less of the system.
  • Source as text files and Text editor carry inertia. Spatial canvases (Code Bubbles, Debugger Canvas) showed measurable gains and still did not replace them.
其ノ貳 02 / 08

Moldable development

其ノ參 03 / 08

Moldable ideas outside Smalltalk

其ノ肆 04 / 08

Frameworks for comparing systems

其ノ伍 05 / 08

Spatial code environments

其ノ陸 06 / 08

Live programming

其ノ柒 07 / 08

Malleable software and end-user programming

其ノ捌 08 / 08

The other bet: agentic workspaces

wardley mappingidemoldable developmentglamorous toolkitreading list