The Hard Things are Still Hard

About

Tredl is a thinking surface for AI workflows.

I designed it for people who prototype and build things with AI, especially those working on complex problems over time. The product introduces lightweight structures and simple rituals to disrupt the default mode and support more deliberate practices. It has a markdown-native workspace for working through ideas, and notes for capturing what emerges along the way. It's a private, local-only web application that runs in the browser and is currently in invitation-only beta.

The Issue

Working with AI can be exhausting—partly because AI tools are immature and continuously changing, but more because the products have a certain ethos and logic built in. If the technology wants something, that seems to be the automation of thinking with minimal resistance—or rather the substitution of processing for thinking. The flow is inherently linear—from prompt to result to prompt again—a lever to pull and something to consume. In practice this is taxing because the system fails in unpredictable ways, while the speed, volume, and tonality of output make review burdensome. The chat interface does not scale or support meaningful shifts in granularity, making it easy to drift into autopilot or be distracted by working across too many levels of abstraction at once. You get caught up fixing minor details or miss foundational assumptions and lose track of where you were going or why.

And on you go, unaware of what was really lost—agency over your own work.

In design, the motion creates the thinking. Moving from lower-fidelity sketches to higher-fidelity models and from systems to details and back facilitates discovery and decision-making in ways that faster prototypes alone cannot. Speeding up one part of the work does not necessarily extend to the whole process, and it's harder than it seems to know in advance which parts are rote and thus might be automated without consequence.

I don't mean to romanticize craft so much as infrastructure. I have been exploring ways to bring more purposeful iteration into virtual workflows. For example, I often use AI to create quick sacrificial outputs to test hypotheses. This is clearly valuable but not the same. There is something to friction. In a studio environment like frog, I could take for granted affordances like a project room, sketches and stickies on the wall, and the tangible evidence of ideas developing at a human pace, over time. This type of scaffolding is essential to innovation—and largely missing from AI.

Still, it would be difficult to do my current work let alone build functional software without either AI or a team of people. While I much prefer working with others, AI allows me to go faster and farther on my own than previously possible. Over time, I’ve gotten much better at working within its limitations—setting context for the machine, creating better prompts, working in structured chunks, and so on. But the system pulls me along because that’s what it was designed to do.

That led me to explore alternative tools and structures.

Specifically, I wanted:

• a more intentional way to organize work
• a reason to stay engaged while waiting on AI processing
• a writing surface to make thoughts visible and usable
• a way to capture and recall emerging ideas
• a functional bridge between human thought and AI

The Hard Things

Based on early sketches of Tredl, Claude estimated it would be a simple build that could be done in a few days. Instead, Tredl required weeks of work spread out over 3-4 months. While code became nearly instant, other gaps surfaced. Things like systems thinking, definitions, and design required more effort up front. Small mistakes or implicit assumptions led to hard-to-detect issues that resulted in rework. And because AI seems particularly sensitive to initial conditions, the importance of being comprehensive and accurate became more acute.

Here’s what I learned along the way.

Strategy

A coherent strategy served me well. I used the Value Proposition Canvas, which juxtaposes user pains, gains, and jobs-to-be-done with the ways that the solution addresses each one. The exercise was useful to focus my thinking about the problem and solution, and informed decisions like limiting the scope and functionality of notes (because Tredl is not a notes app) and making the workspace impermanent (because neither is it a second brain nor prompt library). Adding the strategy and vision to the project's shared context meant that I never needed to re-explain the foundational concept. The project context was a valuable tool throughout the build, but did require manual effort to maintain, particularly as Claude created new documents that had to remain current within the project and the repo.

Scope

I originally envisioned Tredl as a local-first desktop app with an optional cloud sync and more advanced features. That vision added significant complexity and cost—too much for a proof of concept. While planning the build, I evaluated a number of alternatives with Claude and decided on a lightweight, minimalist solution: a local-only web application that stores its data in the browser. The architecture preserves future optionality and may or may not turn out to be preferable in terms of privacy and portability. Because data lives in the browser, the most significant trade-off is that the user needs to back up their own data, which they can export as a single JSON file. I also trimmed the beta feature set and left out more sophisticated editing and export features, keeping only what the strategy required for a fully-functional proof of concept.

Systems Thinking

I started with rough system prototypes in FigJam to explore architecture and features, using stickies to simulate the UX/UI while working on real projects over a few weeks. This helped me define the rough parameters of the open and close rituals, along with the most useful constraints for sessions (multiple) and tasks (up to five). It also taught me that I needed two different types of notes: project notes that are contextual and meta notes that are designed to capture emerging ideas unrelated to a project. Based on these learnings, I wrote a specification in markdown explaining how the system worked: the UI, rituals, states, affordances, and so on, and added that to the project context.

Definitions

In the spec and in the wireframes, I made small mistakes that became issues later. Without thinking about it, I used the word “active” to mean two different things: whether a session was still underway (several can be at once) and which session was currently selected. I made a similar error with task states, which only became visible once the prototype was running. What seemed obvious to me based on the design was ambiguous to the machine, and AI tends to resolve ambiguity on its own unless you ask it to do so proactively. Working in natural language makes it easy to exacerbate mistakes—in this case using the word “open” in chat to refer to “active,” and causing further confusion.

Design

I should have spent more time on detailed design. I made high-fidelity, annotated wireframes of the workspace, but not pixel-level redlines or detailed specifications for all screens. Even though my typography, scale, and color followed a design system that Claude easily turned into tokens, I repeatedly had to ask Claude Code to match the wireframes and correct drifting execution and isolated errors. The same applied to UX, where explicit screen-by-screen and state-by-state direction would have saved rounds of tedious back-and-forth. I assumed the AI could interpret my wireframes and design intent and wanted to learn how well it could do with minimal guidance. It took multiple cycles to realize I needed to specify exactly how the system should work and what I expected from the execution. AI makes it remarkably fast to get to a rough prototype, but the gap between good enough and good is huge.

Technology

I couldn't have built Tredl without AI. I know enough about software to follow some technical conversations and collaborate with others, but not nearly enough to architect and build an application like this on my own. That knowledge mattered more than expected: the more clearly I could name what I wanted in technical terms, the better the result. This was relevant to foundational decisions like the data model, as well as working through issues like confusion about session state. Throughout, I used Claude as a technical advisor to bridge the gap, answer technical questions, solve problems, and weigh trade-offs, like whether the local-only architecture would preclude other choices later. But I know my limits. If Tredl evolves beyond a proof of concept, I plan on engaging human expertise to ensure that the release version is solid enough for real use.

Quality

I worked back and forth between Claude and Claude Code, using each to check the other. I learned that smaller, scoped prompts produced better results and few regressions. For more complex changes, I used Claude to review the development plan and suggest changes before running it. I evaluated each diff based on predefined criteria from Claude, along with my own. This system caught issues and errors that a single tool would have missed. Prior to the beta launch I ran a full QA pass and security audit, which found and fixed minor problems before anyone besides me used the app.

Tech Stack

• Obsidian for planning, documentation, and specifications
• Figma for design and prototyping
• Claude for planning, technical guidance, and prompts
• VS Code with Claude Code for development
• GitHub and Vercel for deployment

Up Next

Tredl is a functional proof of concept in invitation-only beta. I am recruiting a small number of users over Q4 2026 who would like to try it and are willing to provide feedback on their experience with the product. If you'd like to request an invitation, use the button below.

The purpose of the beta is threefold:

1. Gauge interest and evaluate product/market fit
2. Identify areas for improvement
3. Inform roadmap decisions about further development

Learn more at tredl.net.

About the Name

Tredl is short for "treadle," the foot lever that powers a human-driven loom or other types of preindustrial machinery. The name is meant to evoke a more direct and purposeful relationship between humans and their tools.

Postscript: My Position on AI

I am an AI skeptic who works with AI. The technology was built on appropriated intellectual property, by people and organizations with problematic worldviews, in an industry driven by dysfunctional incentives, bad-faith narratives, and a laissez-faire approach to systemic risk. Those are just a few issues worth serious critique, collective action, and regulatory intervention. Provenance is important, though it is equally important to shape the development of transformative social technologies through working with them. I think of my work as critical practice, and see Tredl as a pragmatic extension of my prior foresight work on human agency and the future of work. I know there are people who would question any approach that uses or advances AI, and who argue that it's a straightforward choice between participation and refusal. A more nuanced and actionable perspective is AI as Normal Technology. That's increasingly how I think about it—better to resist technological determinism via actions that create pathways for alternative futures than cede influence to those who would take it.