I'm sharing 100 short posts on AI-powered second brains: tools, workflows, Obsidian, and the path from notes to knowledge to creation. If that loop is what you're exploring, follow along.

Turn Old Notes into Small, Reusable Drafts Imagine opening a folder of old notes to write an article. You have plenty of material, but the outline is still blank. “Finish the article” feels like the only meaningful next step. I'd recommend Tiago Forte's “Just-In-Time PM #4: Intermediate Packets.” He describes progress as tangible intermediate work: an outline, a set of examples, a prototype, or a draft. These give you something to examine and share before the whole project is finished. He also explains how work from one project can become material for another. What makes this piece worth reading is the step between collecting notes and completing a project: a small deliverable with a purpose, rather than another pile to organize. My takeaway: choose three relevant notes and turn them into one paragraph you could show someone. Keep the sources attached, and check whether the paragraph supports the argument you are making now. Reusable material still needs judgment.

Write Note Titles You Can Think With You named a note "Meeting." Months later you open it again, and the title still tells you nothing. You have to reread the whole thing to find out what you were thinking. Andy Matuschak's working note "Evergreen note titles are like APIs" argues that a title should do more than file a note. When notes are factored and titled well, "those titles become an abstraction for the note itself. The entire note's ideas can then be referenced using that handle." He points to a few "API design" techniques: keep each note to one concern, write sharp titles as complete phrases, and prefer positive framings. My take: test a title by asking whether future you would know what the note claims before opening it. "Meeting" fails. "Every meeting needs a clear owner" passes, and now it can drop straight into an outline without a reread. What's your worst note title? Rewrite it in the replies.

Let One Idea Travel Across Books You read two books that both touch on how to prepare for a meeting, and your notes go into each book's file. The next time the question comes up, you have to remember which book said what, and the two notes never meet. Andy Matuschak's working note "Evergreen notes should be concept-oriented" argues for filing notes by concept, "rather than by author, book, event, project, topic, etc." Notes filed by book don't accumulate: a second book on the same concept gets a new note, and you end up with "a scattered set of notes on the concept, perhaps referring to it by different names." Kept apart, nothing pushes you to combine them, or to ask, as he does, "Is there tension between them?" Filed by concept, notes can also link ideas from very different books that share only one point. He is upfront about the cost: it makes note-taking "a little harder, but in a useful way," because each new note has to find where it fits into the whole. My takeaway: ask what idea a note is about, not which book it came from. If one book says "plan every minute" and another says "leave room to improvise," one note on meeting prep can hold both, each still marked with its book, and the tension is right there to think about.

A Link Needs a Reason to Follow It Say two meeting notes link to the same note. A month later, you can't tell whether one was a counterexample and the other a condition. The links still point somewhere, but the reason to follow them is gone. Sascha's article "The Hidden Problem with Note Titles as Links (And How to Fix It)" names one thing that gets in the way. When a note's title doubles as its link, it nudges you to bend your sentence to fit that title. Yet, in his words, "the meaning of the link needs to change depending on the context in which you place it." His fix is to separate the ID from the title, and he shows two simple link-alias techniques that let your own words carry the link. He keeps it in proportion, too: it won't destroy your Zettelkasten, but it is an annoyance. My takeaway: write the reason where you link, not in the target's title. "A counterexample to this" and "true, but only for small teams" can point to the same note and still tell you why to follow each one.

How Small Should a Note Be? Say you split a book chapter into forty one-line notes. A week later, most of them don't make sense on their own, and linking them feels like guesswork. Andy Matuschak's working note "Evergreen notes should be atomic" sets a different target: a note should be about one thing, but capture as much of that thing as possible. Too broad, and links to it get muddied. Too fragmented, and your link network fragments with it. He also says there's no clear litmus test, just tradeoffs. My takeaway: before splitting, ask whether each piece could stand alone and still be worth linking to.

When Is a Note Worth Organizing? Imagine opening your notes to start a proposal, then spending the session sorting what you saved. I'd recommend Tiago Forte's 2020 essay, “The Automation of Note-Taking and the Just-In-Time Future of Work.” Its closing section asks when a captured note deserves further effort: its future use may not be clear when you save it. My takeaway: work on the notes your proposal needs first. Keep enough context to revisit the rest.

Capture an Idea Before Choosing Its Folder An idea shows up mid-meeting. Before typing a word, you're picking a folder, a title, a tag. By then, half of it is gone. I'd recommend Maggie Appleton's “Daily Notes Pages.” She treats this as a design problem: how do you keep capture effortless and still find notes later? She walks through the daily notes page, a fresh dated page each day, and is honest about what it costs. My take: worth reading for how clearly it explains one pattern and what it trades away.

Saving an Article Is Only the Beginning Ever saved an article, then struggled to explain it? In “The Collector’s Fallacy,” Christian Tietze argues that collecting isn’t learning. My takeaway: revisit one saved piece and write what you make of it.

Starting with Obsidian: How Notes Become Part of Your Thinking Andy Matuschak's “Writing forces sharper understanding” is worth reading. He argues that explaining an idea in writing can reveal gaps and connections. My takeaway: give one note a question to explore.

so cool！

Opus 5.5 brings a new standard.

If the AI flood is unavoidable, traceability and new formats and tools that let people verify and review quickly will become essential.

The hard part never leaves your head. It just moves somewhere you aren't looking. I handed my container scripts to a CLI agent and let it write the spec and the code. Output got faster. But the difficulty didn't vanish — it relocated to the two spots I used to cover almost for free: deciding what "correct" even means, and judging whether the agent actually did it. What I offloaded wasn't the hard part. It was the part that surfaced the hard part. I keep finding the same thing in practice. The gap between people who get real value out of AI coding tools and people who don't isn't tool mastery — it's judgment: being able to evaluate what the machine produced. If you drop the docs and tests just because the agent writes the code, the cost doesn't shrink; it compounds where you stopped looking. The bottleneck never left the human. It just took a seat you weren't watching. So don't pick tools by how much difficulty they save you. That number is a mirage — the hard part moved, it didn't go away. Ask who owned the difficulty you offloaded, and whether you can carry the one that grows back in its place. One caveat: if the task stays fixed and someone else sets the goal, the difficulty can genuinely feel gone. That isn't the hard part disappearing. That's your cognition being asked for less — a very different trade than most people realize.

I keep a public catalog of research tools I find on GitHub. The point for readers is simple: checkable options, not hype names. I wanted a new AI helper to sort and fact-check listings — without tearing up that whole desk every time a model demo drops. So I tried one this week (Jev under the hood). Quality was fine. It did not make me faster. I left it off by default. I still turn it on when I need it.

Weird that a launch this capable still makes us shop the menu. Faster and cheaper is fine. The sticky tax is still "which model today." If the models are that smart, stop pushing model choice onto the human.

When a field quietly moves under code, the old guild rules are already late. Five years ago people treated "science becomes computer science" as hype. Labs now run on simulation, big data, and models as the default desk — the same next-stage shift research notes already name. Rewrite the training and credit rules for that move. Do not wait until the old pushback looks foolish.

One way Jev can immediately save money and boost efficiency in legacy workflows: 1. Find the points in the original workflow where LLM calls are very frequent and the output format is fixed. 2. Replace them by using a single LLM call to generate a set of options, then swap in Jev to execute all of them.

We already have too many benchmarks. What is scarce is a process other people can reproduce and trace. Another private scoreboard does not fix that. A trail they can rerun does.

Calling it a cofounder hides who still pays when things go wrong. Old rules protect you until they stop fitting. Then they trap you. "Partners share the risk" only works with someone who can actually lose money with you. The model can't. So when it argues back, write down which bets still sit under your own name. A keyboard never ate a bad launch.