Tana is the first genuine innovation in note-taking since Roam Research, and the most dangerous tool ever built for a developer with ADHD.
These two facts are connected. Tana is innovative because it is configurable. Tana is dangerous because it is configurable. The innovation and the danger are the same feature, viewed from two different angles — one at the start of the evening when you sit down to write a grocery list, and one three hours later when the supermarket has closed and you have built a supply chain management system instead.
The Innovation
This section is not ironic. Tana’s supertags are genuinely, positively amazing.
A supertag is a tag that carries structure. In every other tool, a tag is a label — you tag a note #project or #recipe or #person, and the tag is just a word, a string, a way to group things. The tag knows nothing about what it tags. The tag is a Post-it note stuck to a filing cabinet: it identifies, it does not understand.
Tana’s supertags understand. Tag a node with #person and the node gains fields: name, email, company, role. Tag it with #meeting and it gains: date, attendees (linked to #person nodes), action items (linked to #task nodes), agenda. Tag it with #recipe and it gains: ingredients (each an inline node that can be tagged #ingredient with its own fields for quantity, unit, and seasonal availability).
The supertag transforms a plain text node into a structured object. Not a database row in a spreadsheet — a live object in your notes, with fields that are themselves nodes, which can themselves have supertags, which can themselves have fields, recursively, infinitely, until your grocery list has become an ontology.
This is genuinely new. Roam Research had pages and blocks. Obsidian has files and links. Notion has pages and databases. Tana has nodes that know what they are. A node tagged #task is not just a task — it is a task with a due date, an assignee, a project, and a status, all defined by the supertag, all queryable, all live. The structure lives in the tag, not in the template. The template travels with the concept.
No other tool does this. No other tool has copied this successfully. Supertags are the best idea in PKM since bidirectional links, and they deserve to win.
The ADHD Trap
A developer with moderate (ahem) amounts of ADHD sat down to write a grocery list in Tana.
The list had three items: tomatoes, onions, milk.
The developer typed “tomatoes.” Tana, being Tana, offered to tag it. The developer thought: “I could create a #grocery-item supertag.” The developer created the supertag. The supertag needed fields. Category — produce, dairy, pantry. Aisle number — useful for optimising the shopping route. Seasonal availability — because tomatoes in December are a different proposition than tomatoes in July. The developer configured the fields.
The developer typed “onions.” Onions is a #grocery-item. The supertag applied. The fields appeared. The developer filled them in. Then the developer thought: “I could create a #recipe supertag that links ingredients to meals.” The developer created the supertag. The #recipe supertag has an ingredients field, which is a list of inline nodes, each tagged #grocery-item. Now the grocery list is generated from the recipe. Now the developer needs to enter the recipes for the week. Now the developer is configuring a meal planning system.
The developer looked up. The supermarket had closed.
This is not a joke. This is not an exaggeration for comedic effect. This is the literal, documented experience of the developer in question, who went to Tana to write down three vegetables and emerged three hours later with a structured ontology of grocery management and no vegetables.
Tana is configurable while writing a note. This is the critical design decision that makes Tana brilliant for architects and lethal for anyone whose brain treats configuration as a more interesting problem than the task at hand. In Obsidian, the configuration happens in Settings, which is a separate mode, which requires a deliberate context switch. In Tana, the configuration happens inline, in the same space as the writing, with the same keyboard, in the same flow state. There is no boundary between “writing a note” and “designing the system.” The absence of that boundary is Tana’s innovation and Tana’s trap.
For a person with ADHD, this is not a tool. This is a Squirrel delivery mechanism. Every note is an opportunity to configure. Every configuration is more interesting than the note. The note never gets written. The system gets built. The vegetables do not get bought.
The 100-Line Limit
A developer discovered Tana’s other problem while trying to paste code into a note.
The paste succeeded. Partially. Tana accepts a maximum of 100 lines in a code block. If you paste more than 100 lines, Tana keeps the first 100 and discards the rest. To be fair — and this fairness is noted with the specific tone of someone who has been fair about this for three years and is running out of fairness — Tana warns you. A small toast notification appears. The remaining lines vanish.
100 lines of code.
A note-taking tool that cannot hold more than 100 lines of code in a code block. Not a 5-gigabyte log file. Not a database dump. Not an unreasonable request. 100 lines. A single function in most languages. A short configuration file. Half a React component. A modest shell script. The kind of thing a developer pastes into a note ten times a day because the note is where the developer thinks about the code, and thinking about code requires looking at the code, and looking at the code requires the code to be there, all of it, not the first 100 lines of it.
riclib discussed this in the Tana Slack. With team members. Multiple times. Over years. The question “why 100 lines?” was asked with genuine curiosity, not hostility. The answers were never satisfying. The limit remained. The last time riclib checked — approximately a year ago — the limit was still 100 lines.
The foundational contract of a note-taking tool is: you can put things in it. Things you write. Things you paste. Things you capture. The tool holds them. This is the minimum. This is the floor. A note-taking tool that silently truncates what you paste — even with a warning — has broken the foundational contract. The user cannot trust that what they put in will be what they get out. The user cannot trust the tool with the most basic act of note-taking: keeping what was written.
100 lines. The Lizard’s notes.txt has 340 lines. The Lizard’s note-taking tool — vi — has no line limit. vi was written in 1976. The line limit was not a problem in 1976. It should not be a problem in 2026.
The Departure
riclib left Tana for one cultural reason and one structural reason.
The cultural reason: every note became a configuration session. The tool was so interesting to configure that using it for its intended purpose — writing things down — became secondary to designing the system that would hold the things written down. This is the Squirrel’s paradise and the Lizard’s nightmare. The tool optimised for building the tool. The vegetables were never purchased.
The structural reason: 100 lines. A developer who cannot paste code into a note-taking tool cannot use the note-taking tool. The code is half the developer’s thinking. The note without the code is a sentence without a subject. riclib cannot think about code he cannot see, and Tana would not show him more than 100 lines of it.
Together, the reasons told the same story: Tana is a tool for people who think about systems. riclib is a person who thinks about systems. The match sounds perfect. The match is catastrophic, because the person who thinks about systems needs a tool that resists the urge to systematise, not a tool that rewards it. riclib needs NotePlan, which has no supertags, no inline configuration, and no limit on how many lines of code you can paste. NotePlan is boring. Boring is safe. Boring buys vegetables.
What Tana Got Right
Everything except the two things that made riclib leave.
Supertags are the best idea in PKM since bidirectional links. The inline node model is natural and powerful. The team is thoughtful and responsive (they discussed the 100-line limit, even if they didn’t change it). The product is ambitious in the best sense — it is trying to be genuinely new, not a clone of Roam or a reskin of Notion.
Tana deserves to succeed. Tana’s ideas deserve to spread. If supertags appeared in NotePlan or Obsidian, the PKM landscape would be better for it. The innovation is real. The execution is, for one specific developer with ADHD and a code-heavy workflow, incompatible with buying groceries and storing code.
"The Lizard does not have supertags. The Lizard has lines in a text file. The lines do not know what they are. The Lizard knows what they are. This is sufficient."
— The Lizard, who has never failed to buy vegetables
Measured Characteristics
- Year launched: 2022 (private beta)
- Innovation level: highest since Roam
- Supertag quality: genuinely amazing
- Time to write a grocery list (normal tool): 2 minutes
- Time to write a grocery list (Tana): 3 hours (grocery list not completed)
- Supertags created instead of buying vegetables: 3
- Commands configured instead of buying vegetables: 2
- Vegetables purchased: 0
- Supermarket status at end of session: closed
- Code block line limit: 100
- Lines of code in a typical function: 50-300
- Lines of code riclib needs to paste: more than 100
- Years the 100-line limit has been discussed: ~3
- Satisfying explanations received: 0
- Lines in The Lizard’s notes.txt: 340 (no limit)
- ADHD compatibility: negative (configuration is the content)
- The innovation: real
- The trap: also real
- The vegetables: still needed
