Inspiration
AI makes it easier to build an idea. I wanted to explore what happens before we choose one.
When builders give similar hackathon briefs to similar AI agents, how often do they arrive at similar projects? And what gets lost when the starting point comes entirely from a model?
Dark Space grew from that concern. I wanted a tool that makes familiar suggestions visible and asks builders to bring in something models cannot know: their own experience, observations, and reasons for caring.
The name comes from the less crowded regions of an idea map: places worth questioning and exploring, without assuming that unexplored automatically means valuable.
What it does
Dark Space helps builders examine an idea before carrying it into project scoping.
Its workflow is simple:
- Explore the map. See clusters of ideas and the patterns they share.
- Place your idea. Enter a sentence and find its nearby ideas and relative crowding.
- Question the defaults. Answer open-ended questions about common choices in that neighborhood.
- Revise in your own words. Update your idea and compare its placement.
- Take your thinking forward. Download a Markdown hand-off containing your ideas, answers, and placement history.
Personal idea placement runs on the user's device. No account or personal inference server is required.
An optional terminal companion brings the same reflection process into the Build With AI workflow, between onboarding and scoping.
The public demo uses clearly labeled, made-up sample data. It demonstrates the interaction and measurement pipeline. Whether model samples can predict real hackathon submissions remains an open research question.
How we built it
I used the Build With AI Skill Pack to move from scope to product requirements, technical specification, and incremental implementation.
Dark Space has three main parts:
- A Python sampling and analysis pipeline with frozen configurations, cached model responses, recorded failures, and reproducible artifacts.
- A shared TypeScript core for idea placement, crowding measurements, interview state, and Markdown exports.
- A static SvelteKit interface with a Canvas map and an on-device embedding model running through WebAssembly in a browser worker.
The browser and terminal companion use the same embedding contract, keeping their placement calculations consistent.
An initial sampling run across four model families completed 384 attempts, producing 383 valid ideas. These are generation counts, separate from any claim about predicting entrants.
I also separated public sample bundles from local research artifacts and added checks to prevent collected gallery material from entering publication paths.
Challenges we ran into
Making an interesting visualization scientifically honest. A cluster can look convincing before its meaning has been established. Dark Space distinguishes semantic proximity, relative crowding, and actual evidence of matching real projects. A less crowded placement is never presented as a better idea.
Keeping personal thinking private. Running placement locally required managing model assets, browser workers, loading states, cancellation, and consistent calculations across environments.
Respecting other builders' work. Gallery data needed a separate local collection path, provenance records, and publication safeguards. The public demo uses invented examples while real-data evaluation remains pending.
Preserving the builder's authorship. It would have been easy to generate polished answers for users. Instead, the interview asks questions and preserves their exact words in the hand-off.
Accomplishments that we're proud of
- Turning an abstract concern about similar AI suggestions into an interactive reflection workflow.
- Running personal placement on-device while sharing the calculation core between browser and terminal.
- Recording an actual multi-model sampling run with explicit success and failure counts.
- Building a hand-off that carries the builder's own reasoning into scoping.
- Keeping an unfavorable sample result visible: the demonstration's forecast and control both match 6 of 8 made-up projects, producing zero lift.
That last result matters to me. The interface should report what the experiment produced, even when it does not support the hoped-for story.
What we learned
Building Dark Space made the distinction between a working system and a supported claim concrete.
A reproducible sampling run establishes what the models generated. It does not establish what people will build. A similarity score can help retrieve nearby ideas, but it does not prove that two projects solve the same problem.
I also learned that privacy and data permissions shape architecture from the beginning: where inference runs, what gets stored, and what can appear in a public demo.
The product insight I keep returning to is that a useful question can contribute more than another generated suggestion. Dark Space creates room for builders to explain what they know and decide what belongs in their project.
What's next for Dark Space
The next priority is to connect the existing model-sampling work to a fully verified forecast experience, then evaluate the entrant-prediction hypothesis using permitted data.
That means freezing the evaluation rules, comparing against a control prompt, checking automated judgments against human labels, and reporting uncertainty alongside the results.
I also want to complete broader usability, accessibility, and device testing across the map, interview, recovery, and export journey.
The goal is to help builders recognize the defaults and make deliberate choices about what they want to build.
Log in or sign up for Devpost to join the conversation.