The View Is Not the Data

Most tools were built for human eyes. That used to be fine.

A few weeks ago I wrote about context being the new constraint for AI tools. The short version: the models keep getting smarter, but if the information they need isn't available, or isn't in a form they can actually read, the intelligence doesn't matter much. I found two problems. Information never written down at all. And information that exists but is stuck in formats machines struggle to parse.

The first problem is behavioral. I don't have a good answer for it yet.

The second one I've been trying to actually do something about.

"The tools weren't designed wrong. They were designed for a world where humans were the only audience. That world is changing."

The problem isn't proprietary. It's expressive.

It's easy to frame this as a vendor lock-in issue: closed systems, data you can't get out. But Google Docs is reasonably extractable. The real problem is different.

Most tools were designed to maximize what humans can express. Color carries urgency. Position implies hierarchy. Arrows show relationships. Spatial layout communicates structure that no one bothered to write down because everyone in the room could see it.

That meaning doesn't survive extraction. An AI reading your roadmap in Google Sheets sees rows and formatting, not the urgency in the red cells, not the grouping you implied by indenting. It sees pixels where you left a signal.

The tools weren't designed wrong. They were designed for a world where humans were the only audience. That world is changing.

So I built something

I'm in a mode lately where when I have a question, I try something. I learn by doing.

The hypothesis: what if I built tools designed around the data first, and treated the interface as something separate? Something disposable? Not feature-rich replacements for existing software. Just enough to do the job, constrained enough that the underlying files stayed clean and readable by anything.

I built three apps. It took about two days.

Simple Kanban reads a folder of markdown task files and renders them as a four-column board: Backlog, Priority, In Progress, Done. Drag a card to move it. That's a one-field update in the underlying file, nothing more. Click to open the full note in a side drawer. The board stays live with Obsidian or Claude Code; if either changes a file, the board updates without a reload.

Simple Roadmap reads a single JSON file and renders a Gantt chart with swimlanes. You can drag bars to shift dates, draw new ones by clicking in empty space, or ask questions through an embedded chat panel. The AI chat panel reads the roadmap but never writes to it. Anything structural happens through the UI or through Claude Code editing the JSON directly.

Simple Write opens a single markdown file in a focused editor. Markdown syntax hides when you're not on that line and shows itself when your cursor moves there. Metadata lives in a side panel rather than inline in the document. The file is always plain markdown. The editor adds no proprietary structure.

"It sees pixels where you left a signal."

In all three, the file is the source of truth. The app is a view. Close the browser; the files are still there, still readable, unchanged.

I've been using all three every day since I built them.

The same data file, two different tools

The best way I can describe what this unlocks is two things that happened in the same week.

I was in a 1:1 with my manager, going through my roadmap. She suggested moving the AI guides work up a few weeks. The timing mattered for the team. While we were still talking, I clicked the bar and dragged it. Done. I could have described that to Claude, but it would have taken more thought, more words, and more time than we had. The drag took less than a second.

The day before, I was rethinking the roadmap's structure. I had six broad initiatives I wanted to break into more specific, movable pieces I could sequence more deliberately. I asked Claude to do it. It had full context (how the roadmap was built, what each initiative was trying to accomplish, the organizational thinking behind it) and direct access to the JSON file. Instead of manually creating dozens of tasks, naming each one, writing descriptions, choosing dates, Claude handled the whole restructure. I made minor adjustments in the UI afterward.

Same data file. Two completely different interfaces. Neither approach would have worked as well the other way around.

In Google Sheets, where a lot of people build roadmaps manually, this split isn't possible. The data and the view are one thing. There's no file for Claude to just edit.

"The constraint isn't a bug. It's the whole point."

What the constraint actually costs

I left features out on purpose. No colored text. No freeform formatting that can't be represented cleanly in the underlying file. The apps do less than the tools they're loosely replacing.

Let's be honest, two days of work alone is noticeable. There's no undo/redo yet. There's a missing cursor in the kanban drawer. A bunch of small things you only notice when they're missing. They'll get fixed, but they're still a bit painful in the meantime.

The intentional constraints are a different category. I can't add colored fonts without potentially breaking the machine-readability the whole thing depends on. That trade-off is real. I don't know yet if it holds for people who rely more on visual formatting, people for whom color isn't decoration but signal. That's one of the things I'm still working out.

The constraint isn't a bug. It's the whole point. But it has a cost, and I don't want to pretend otherwise.

"The schema is designed to last. The view can be replaced."

Where my head is

My theory is that if a team aligned on a small set of data schemas, this is what a task looks like, this is what a roadmap item looks like, the interface becomes a personal choice rather than a team mandate. Share the schemas, share the skills that let AI work with those formats, and let everyone decide how they want to interact with the data. Custom view, an existing tool that reads the format, or just asking Claude directly.

I've put the existing apps in a repository so others can pull and customize them. The adoption problem right now is mostly GitHub fluency, not interest. That's a separate thing to solve. I have more views in mind: a spreadsheet, a deck builder, something for service blueprints. Together they'd cover most of what a product team reaches for on any given day.

I suspect the longer-term answer is that AI will get good enough to generate these interfaces on demand, and the specific views I built will matter less. But the clean, machine-readable data underneath fits that future better, not worse. Better to already have your information in a form AI can read directly than to spend time transforming messy formats later and losing signal in the process.

The schema is designed to last. The view can be replaced.

For now, I built three things. I'm using them. I'm still figuring out what they're teaching me.

If you're trying something similar, or have a different approach to the same problem, I'd be curious to hear it.