AI

This piece is a thought experiment-style simulated interview. The respondents are composed of cognitive science, archival studies, and product design perspectives and do not represent any actual expert’s original words. In May 2026, I stopped using flomo. That month had no daily reminders, no faint sense of debt from “today’s notes still pending,” and no rapid conversion of thoughts into cards. Surprisingly, life didn’t thin out. Instead, Laotian cities, caves, injuries, strangers, and bars coalesced in late May into a more complete self-reading than fragmented pieces. ...

This is the sixth essay in Reckoning with Reality. The previous essay separated fast feedback from slow results. This one turns to a question that technological progress makes easy to neglect: when an old bottleneck disappears, where does the new one appear? Whenever a new tool arrives, people first imagine what it will eliminate. AI makes writing faster, code cheaper, translation nearly instantaneous, and video production possible without a full team. Work that once took days can now be completed in minutes. ...

Open Design is easy to misread. The name also belongs to the older open-design movement around shared product blueprints, but this article is about nexu-io/open-design : an open-source workspace that turns coding agents into a design production system. It is not a model, and it is not simply an image generator. It is a harness. The harness gives an agent a controlled vocabulary, reusable workflows, visual constraints, an artifact loop, and a place to inspect the result. That distinction matters because the quality ceiling still comes from the model and the operator; Open Design improves the path between intention and output. ...

Put the Tip List Down for a Moment I began this article as a collection of Boris Cherny’s Claude Code habits. That version had a problem: social posts age with models and product releases, while fan-maintained collections tend to mix personal advice, previews, and impressive-looking statistics. A sharp opinion can become a historical footnote before the article reaches its readers. So I took the slower route. Product claims in this revision come from Anthropic or the official Claude Code documentation. Untraceable numbers, second-hand quotations, and claims of universal superiority are gone. Boris’s way of working remains an inspiration, but it is not treated as a specification. ...

Why Does Getting Better at This Make Me More Tired? Let me start with a strange thing I banged my head against for a long time before I understood it. When I first started using Claude Code, the productivity gain was visible to the naked eye: an afternoon’s work covered what used to take two days. Once I got fluent, the gains kept coming — but so did the exhaustion at the end of each day. Because I was doing the same thing all day long: watch it finish, judge whether it’s right, think about what to say next, hit enter again. ...

Last winter I ran a very ugly set of numbers. I’d spent an entire afternoon in a café, writing code and shooting footage in between — about forty minutes of material across phone and screen recording. I started editing that evening and exported at 1:30 in the morning. The finished cut was fifty-eight seconds. Forty minutes of footage. Six hours of editing. Fifty-eight seconds of output. And the numbers on it were mediocre. ...

Same product, different name, different score There’s something I’ve been watching for a long time without finding the right place to write it down. In the same product community, you’ll regularly see two small tools with nearly identical features. One launches and sinks without a trace; the other gets shared repeatedly and draws serious questions. Look at both product pages: similar craftsmanship, similar pricing, landing pages built from the same template, even. The real difference sits in the small line under the maker’s name — “maintainer of such-and-such project,” “has written about xx for three years.” ...

I wasted years on this one sentence “If the product is good enough, people will come.” I believed that line for years. It fits the engineer’s worldview: code is verifiable, performance is measurable, and there’s an objective difference between good and bad. If the difference is objective, then the good thing winning is just a matter of time — the market is efficient, it just needs a while. That was my logic through my open-source years. Write the project well, keep test coverage high, take the docs seriously, and then wait. Wait for stars, wait for issues, wait for someone to mention it in a blog post somewhere. Sometimes the wait paid off. More often it didn’t. And every time it didn’t, my first reaction was the same one: the thing isn’t good enough yet, go back and keep improving it. ...

One morning, and three things that shouldn’t exist One morning I got up, made coffee, opened my laptop, and found the agents I’d left running overnight all parked at “done”: one had added full multilingual support to a small tool of mine — Chinese, English, Japanese copy, an i18n layer extracted; one had built reading-progress analytics for my blog; one had refactored a CLI I wrote six months ago into a plugin architecture. The code was clean. The tests were green. ...

This is part two of “The Super Individual’s Gear Stack.” If you haven’t read the overview , start there — every judgment in this piece rests on the yardstick that essay proposed: does an advance in a layer of gear help only you, or does it help all of your competitors at the same time? ...

The fifteenth tool list changed the question Over six months, I read roughly twenty or thirty “AI-era super individual” tool lists. Around the fifteenth, the pattern became hard to ignore: the lists differed far less than the competitive advantage each one promised. I use most of the tools they recommend. The problem was not that the recommendations were bad. It was that ten thousand builders could install the same stack in the same week. Their absolute capacity might rise, while the distance between them barely moved. ...

I am building a developer-machine checkup skill called devbox-doctor. The idea sounds simple: inventory a Mac, identify tools that may no longer earn their keep, find actual toolchain conflicts, and trace data left behind by uninstalled apps. The dangerous word in that sentence is identify. A scanner can prove that two tools are installed. It cannot prove that one is useless. A directory can resemble an app’s name. That does not make the directory safe to delete. Spotlight can return no last-used date. That does not mean the app was never opened. ...

What makes an Agent Skill valuable is not a clever prompt, but a clean division of responsibility: deterministic work goes to code, judgment goes to the model, and execution confirmation returns to the human. Structured contracts hold those parts together. I reached that conclusion by dissecting a storage-cleanup Skill that can delete local files from a web page. Deletion is one of the most consequential powers an agent-adjacent tool can expose. The design did not make me fearless; it gave me specific controls I could inspect before deciding whether to click. ...

After the Framework Stood Up, I Realized I Had No “Shared Workshop” The five-part Info-to-Creation series got the framework standing: information gets collected and denoised, records settle into half-finished goods, knowledge gets structured into capability, creation reorganizes it for an audience. But after writing that line in Layer 3: Knowledge — “your knowledge base is the workshop you share with your AI” — something kept nagging at me. ...

What actually happened here How large a team does it take to rebuild a four-year-old blog with 120+ posts — content architecture, operations, all of it? My answer, delivered over the first half of this year: one person and a crew of agents with clearly divided jobs. “Crew” is a working metaphor, not a fixed headcount of digital employees. As of July 2026, the repository contains seven Claude skills and four workflows whose names begin with seo-; Claude Code, Codex, the Claude jobs inside GitHub Actions, and temporary review sessions are started only when a task calls for them. The human owns judgment, boundaries, and the final signature. Agents own scoped work that can be tested. The result is the site you’re reading — cubxxw.com . It isn’t merely a redesign. It turned “a blog” from a static site into a system that generates a daily report, prepares fix proposals, and exposes its own search interface. ...

Suppose you had to place a bet today on one direction in AI agents. What is the first question you should ask? Most people ask whether the thing can be built. By mid-2026, that is often the least interesting part. The colder question is: why has nobody made this opportunity routine yet? The answer is a useful filter. If nobody has solved it because everyone just noticed it, competition is probably coming. If nobody has solved it because the work is dirty, slow, and carries consequence, there may be something defensible—or there may be no market. The rest of the article is how I try to separate the two. ...

Suppose you actually have one now — an agent that takes a job end to end. Pulls the data, writes the code, runs the tests, opens the PR, updates the docs. It doesn’t need you feeding it prompts line by line. You hand it the task at night and go to sleep. The real question isn’t whether it finishes. In coding, research, and content workflows, model capability is often already sufficient to produce a plausible result. That does not mean capability has stopped mattering everywhere: in unfamiliar domains and genuinely novel tasks, it can still be the limiting factor. But once an agent is capable enough to act, a different bottleneck appears — ...

The quiet dashboard can be the dangerous one A morning briefing with no new items may mean that nothing relevant happened. It may also mean an RSS route broke, an API began returning empty pages, or a credential expired during the night. From the reader’s side, those very different states look identical: silence. That is the first lesson of a personal intelligence system. Gathering more information is easy to demonstrate; knowing whether the machine is healthy, whether its summaries are faithful, and whether a signal deserves action is the real work. The system I want is not an account that publishes automatically. It is a pipeline that can show me what changed, why it may matter, what evidence supports the claim, and which decision—if any—should follow. ...

How many agents can one person afford to keep running? The wrong way to answer is to count agents. An “agent” might classify one paragraph, search for twenty minutes, or refactor a repository through eighty tool calls. The useful unit is not the agent. It is the successful task, with its input tokens, output tokens, tool charges, retries, and human cleanup attached. That distinction changed how I think about two related but different choices: low-cost hosted model APIs and open-weight models that can be self-hosted. Falling API prices matter, but “90% cheaper” is meaningful only when three things are visible: ...

A counterintuitive signal: it starts prompting you Start with a question. Suppose one day you open your workspace and the agent isn’t sitting there quietly waiting for your next command. It speaks first: “I noticed section three of yesterday’s proposal is still unfinished. I drafted something in the voice you used last week — want to take a look now?” Is that thoughtful, or is it presumptuous? Over the past six months I’ve noticed a counterintuitive signal while following agent launches, primary sources, papers, and benchmarks: more products are experimenting with agents that do not wait for the next instruction. They use available context, estimate what is worth doing, and bring a suggestion forward. ...

Suppose you ask an AI system to track one field — papers, releases, benchmarks, first-party changelogs, and the conversations around them. How far can it get on your behalf? This essay is not a census of every product. It is a field note from the systems I tested between January and June 2026, across AI research and developer-tool sources. In that sample, three patterns kept recurring: subscription aggregation, change monitoring, and agentic search. They were capable, but they shared a boundary: automation can haul information remarkably well; without your goals, context, and feedback, it cannot reliably make the final judgment for you. ...

A Year Later, Why Does AI Still Feel Like Extra Work? AI now writes copy, translates documents, summarizes meetings, and inspects spreadsheets. Yet one honest question cuts through the excitement: has it taken over a business step, or do you still explain the background, judge the answer, and decide what happens next every time? The model may be smarter. The person carrying the context and the responsibility often has not changed. ...

After Three Hours, What Is Left on the Table? I have had evenings that began with a modest intention: settle the angle of an essay. Soon I was discussing titles with AI, then business models, then the meaning of work. The conversation flowed beautifully. When I closed the window, the page was still blank. That does not make the conversation worthless. It reveals that exploration and execution are different kinds of work. ...

A Signal That Sent a Chill Down My Spine Let me start with a line from the retrospective of someone who uses AI heavily every day. Reading it gave me a bit of a chill: When I have a really enjoyable conversation with AI, it probably means I didn’t grow that day. They explained it clearly: a pleasant conversation usually means no friction was encountered. Real growth is always accompanied by some kind of discomfort — forcing a vague idea into a clear sentence, working through a problem you can’t figure out, being jolted into rethinking by an objection. None of that feels “good.” They kept using AI to remove friction, and the more they used it, the smoother and more pleasant the conversations got — until they stopped and realized: friction was exactly what they needed most, and they’d deleted it with their own hands. ...

“It Runs” Is Not a Reliability Standard Most personal AI workflows begin with one acceptance test: did it produce something? A draft appears, a patch compiles, ten pages become one, and the task feels finished. After enough repetitions, however, the costly failures are rarely dramatic. They arrive quietly: a polished paragraph built on a stale source, a tool call that never completed, a plausible plan that solved the wrong problem. ...

A Second Brain Is a Working System, Not a Larger Notebook Most note systems are built for a future reader called you. You save a link, polish a heading, add two tags, and trust that one day you will return. Usually, you do not. An AI-native second brain begins with a different question: What useful work should this note make possible? The answer might be modest: turn an inbox note into a project brief, retrieve your earlier judgment before a meeting, or draft an article from claims you have already verified. The point is not to make AI read everything. The point is to give it a narrow, legible field in which it can help without quietly rearranging your life. ...

Creation Is the Outward Half We’ve reached the final layer. Information has been denoised, records have been sedimented, knowledge has been structured into repeatedly callable capability — but up to this point, every stage has been solving your own problem. Knowledge makes you stronger, but it doesn’t automatically turn into something others want to read. Creation is the layer that reverses the direction of this pipeline. Knowledge faces inward; creation faces outward. Knowledge asks “can I reuse this”; creation asks “can others receive this.” Creation corresponds to a platform’s recommendation logic, a particular group of users’ reading habits, and the substantial research you did to support this specific piece of expression. It has exactly one goal: have the audience receive it, understand it, and want to connect with you. ...

Growing Bigger, Getting Less Useful We’ve reached layer three. Information has been captured and denoised; records have been written down and polished into semi-finished products — now the question is: how do you turn these semi-finished products into actual knowledge? Let’s start with a definition. Knowledge is structured, repeatedly reusable material relevant to you: a mental model, a handful of skills, a methodology, along with your judgment, positioning, and values. Its keyword is reusability, and it solves your own problems. ...

The Semi-Finished Product Filed Under “Knowledge” In most people’s mental model, notes only have three tiers: see information → turn it into knowledge → use it to create. The act of “recording” in between gets quietly filed under “knowledge.” But as I said in the overview, records deserve to stand alone as their own layer. Because it’s an independent intermediate form: it’s relevant to you, but not necessarily useful forever; it might just be something you’ll need someday, or something you’re using right now to clarify your own thinking. That kind of thing doesn’t yet qualify as knowledge — only what’s structured for repeated future reuse counts as knowledge. ...

The Default State of Information Is Noise The previous essay laid out the framework: information, records, knowledge, and creation are four distinct stages. This one deals with only the first — information. The single most important thing to understand about information is this: its default state is noise. We have a natural greed for information. See a good article, want to bookmark it. See a great quote, want to save it. See a reading list someone recommended, want to add it to your queue. Every act of “saving” gives us a small illusion of “I’m making progress.” But saving, at its core, is just moving information from someone else’s warehouse into yours — it hasn’t gone through any processing by your own machine. ...