A Note on Possibility
Sylvia Plath’s fig tree has always stuck with me. Early in my career, I treated opportunities as mutually exclusive: choose one fig and all the others disappear. So when someone asked, “What do you want to be when you grow up?” it felt less like an invitation and more like a commitment. Whatever came out of my mouth seemed to close off everything else. I’m still not sure I can answer that question definitively.
But life rarely works that way. You can have a fig, then reach for another. You can take a bite and decide it isn’t for you. A choice can be meaningful without being permanent. There’s a lot of doomerism floating around the abyss we call the internet, and staring into it for too long has a way of shaping what you expect to find. I’d rather believe there are still plenty of us imagining different lives, changing our minds, and reaching for what might come next.
I made this experiment as a small artifact of that collective hope. If you added a response, thank you for leaving a little evidence that it’s still out there.
Building The Unfallen Fig Index with AI
The Unfallen Fig Index began as a small participatory experiment about unrealized professional possibilities. Visitors answer a weekly question about how often they imagined another life, then see their response become part of a shared visual object.
I used AI throughout the project, but the process was less “generate an app” and more an evolving collaboration. I set the concept, visual direction, interaction rules, and standards for factual integrity. AI helped me explore implementations, diagnose failures, write and test code, and maintain continuity across a long-running project.
One important decision was separating real data from visual amplification. Every submission creates one primary point surrounded by deterministic satellite particles. The satellites make a small dataset visually expressive, but they never count as additional respondents or affect the statistics. Selecting any satellite still resolves to the one real response that produced it.
The visualization itself required substantial iteration. It began as a decorative two-dimensional splatter and evolved into the Fig Volume: a projected three-dimensional field with depth, rotation, recency color, cluster selection, tooltips, and a persistent “YOUR RESPONSE” annotation. To finesse it without repeatedly editing Framer, I built a local Fig Volume Lab with synthetic datasets, tuning controls, saved configurations, and tests at different participation levels. This became a focused design instrument rather than a separate renderer.
The stack combined:
Framer and React/TypeScript for the experience
Canvas2D for the interactive Fig Volume
Cloudflare Workers and D1 for the anonymous API
Cloudflare Browser Rendering for versioned social-preview images
Vite for the local visualization lab
Vitest, TypeScript, and Wrangler for targeted testing and deployment checks
Some of the hardest problems were not visual. Framer occasionally retained stale code-component references, producing misleading missing-export errors. At another point, newer work existed only in a generated file, so running the generator restored an older experience. I repaired the source pipeline so there was once again a clear path from canonical source to generated Framer component, with idempotence checks to prevent another silent regression.
Other friction points included browser CORS failures that looked like API outages, D1 authorization errors, brittle editor saves, and keeping a canvas interaction accessible and performant. A useful working rule emerged: diagnose build, browser, data, and design failures independently instead of treating them as one problem.
The AI workflow evolved alongside the product. Early work involved more exploratory prompting and broad inspection. Later, I introduced project context files, decision records, verified-state labels, narrow task boundaries, targeted tests, and a two-attempt circuit breaker for failing tools. This reduced repeated investigation and made long sessions much more token-efficient.
I also began routing work by complexity: lightweight models for mechanical edits, balanced models for normal React and Worker implementation, and deeper-reasoning models only for consequential architecture, privacy, or rendering problems. Previously verified state was trusted unless the underlying source changed.
The final result is both an experiment and a record of how I learned to work with AI more deliberately. The interesting part was not that AI wrote code. It was learning how to preserve authorship, design judgment, factual integrity, and system coherence while the implementation—and the collaboration model itself—continued to evolve in real time.