A good friend told me recently, face to face, that he had read my article about SEBI, gone as far as buying a Claude Code license, and then stopped, because he did not know what the first move was.

I recognized that state immediately. It was me in March: I understood the second brain concept the same day I met it, and then did nothing with it for two months. The person who taught me needed three or four months to build his first version. I needed six weeks. This guide exists so my friend needs two. Each round is supposed to compress the path for the next one. Here it is, lightly anonymized, essentially as I sent it.

One principle before anything else: AI will not make you faster. The thinking you have already done makes you faster. The tool only writes it down. That is why day zero happens on paper.

A note on the examples: my friend researches local history, a village monograph, heritage buildings, old newspapers in digitized archives. Your domains will differ, but the steps are the same.

Day 0: the macro structure, on paper (2-3 hours, no laptop)

Think hard about ALL your interests, even the ones you will not touch for months. The structure has to be able to receive them later without a reorganization. I had the advantage of having already split my life into a project tool weeks before I built anything. Do it on paper now.

1. List everything you care about. For my friend: the monograph, city heritage, his profession, community work, and entities cutting across all of them: buildings, streets, architects, newspapers, people, years. For contrast, my own vault's top level: job search and commercial initiatives, finance, academic work, communities, entities (people, companies, tools), concepts (frameworks and mental models), syntheses, meta. Different life, same shape.
2. If you are in a job search, make it a first-class domain. Mine lived in the vault: applications, interview notes, rejection patterns, prep checklists. Few things compound faster, because a job search is exactly what this system eats for breakfast: many scattered interactions over months that your memory quietly drops and your vault does not.
3. Pick ONE starting project, the one where you already hold the most material. Everything else gets an empty folder. Empty folders are not mistakes, they are targets. They are your list of what to collect next.
4. Decide the small conventions now, because changing them later hurts: kebab-case filenames (old-train-station.md, not Old Train Station.md) and one single link style between pages, I recommend [text](path/page.md). Write them into the constitution on day one. The constitution is CLAUDE.md, a single file that governs the whole system: you will meet it in a moment.

From my own run: I still have two zones of my vault with different naming conventions and two link styles mixed together. It works, but I am cleaning it up retroactively and it annoys me to this day. Decide once, write it down.

Day 1: install and first contact (1 hour)

1. You need a paid Claude account. A free one will not work with Claude Code, and the Pro plan ($20/month) is plenty to start.
2. Install Claude Code: the desktop app from Anthropic or, from the terminal, npm install -g @anthropic-ai/claude-code. Log in with the account that holds your license. And a reflex worth installing on day one: when anything fails during setup, paste the error into Claude and ask, with as much context as you can give, screenshots included.
3. Important: you do not need to know how to program. Claude Code works on any folder of text files, not just code. A Pro license works in 5-hour windows, so work in focused sessions, not five scattered minutes at a time.
4. A warm-up with zero stakes, in an empty folder:

Create a file called test.md with 3 chapter ideas for a local history
monograph. Then tell me exactly which files you created.

The point is simply to see with your own eyes that the agent writes real files to disk and reports what it touched. When it asks for permissions, read what you are approving. Approve narrowly, never "allow all". I granted too much early on and only tightened it after a security audit, weeks later.

Days 1-2: the vault and its constitution

1. Create the folder, for example vault/, open Claude Code inside it and give it this:

Create the structure for a knowledge vault: 1.raw/ for raw sources,
2.wiki/ with subfolders monograph/, heritage/, work/, community/,
entities/, syntheses/, meta/, each domain folder with its own sources/
subfolder, and 3.output/ for finished deliverables. Plus empty
index.md and log.md at the root. Do not write any content yet.

Ideally, mirror the same domain structure inside 1.raw/ and 3.output/ as inside 2.wiki/. The wiki is the most important of the three, but a shared shape keeps everything findable: raw material enters at 1, knowledge lives at 2, finished work leaves at 3.

2. Then write CLAUDE.md at the root: the constitution. It is the most important file in the whole system. Claude Code reads it automatically at the start of every session, it is the agent's working memory. Do not write it alone, write it WITH the agent, starting from this:

# Vault · CLAUDE.md

## Identity
You are my knowledge agent. This vault is a personal wiki that YOU
write and maintain. I direct and validate, you execute.

## The iron rule
1.raw/ is immutable: you read from it, you NEVER write to it.
2.wiki/ is entirely yours.
3.output/ holds finished deliverables: write there when I ask for
an export or a draft to send, never ingest from it.

## Structure
- 1.raw/ · raw sources (archive PDFs, photos, notes, exports)
- 2.wiki/monograph/ · the main research project
- 2.wiki/heritage/ · city heritage and architecture
- 2.wiki/work/ · the professional side
- 2.wiki/community/ · civic projects
- 2.wiki/entities/ · buildings, streets, architects, newspapers, people
- 2.wiki/syntheses/ · answers and analyses worth keeping
- 2.wiki/meta/ · decisions about the system itself, retrospectives
- 3.output/ · finished deliverables (chapter drafts, exports,
  things I send to other people); not a knowledge source
- index.md · catalog: one line per page, organized by folder
- log.md · chronological journal, append-only, newest on top

## INGEST (when I say "ingest file X")
1. Read the source from 1.raw/
2. Write a source page in 2.wiki/[domain]/sources/[slug].md
3. CRITICAL RULE: every historical fact gets its exact citation
   (publication, date, issue, page). No source, mark it explicitly
   as "to verify".
4. Create or update every entity page you touched
5. Update index.md and log.md
6. Report the full list of pages created or changed

## Frontmatter
Every new page starts with:
---
type: source | entity | concept | synthesis | meta
description: one sentence
tags: [list]
updated: ISO date
---

## Thresholds
- An entity page only for what recurs across multiple sources.
  A single mention stays inline in the source page.
- Binaries (photos, PDFs) stay in 1.raw/; the wiki gets the
  transcription and the reference, not a copy.

## QUERY (when I ask a question)
1. Read index.md first, then the relevant pages
2. Answer ONLY from the wiki, linking to pages. Whatever is missing,
   say so explicitly and suggest what source would fill the gap.
3. Ask me whether we save the answer into syntheses/

## LINT (on request, or after every ~10 ingests)
Look for: contradictions between pages, entities mentioned without
a page, pages nothing links to, an index out of sync with reality.
Report as a numbered list. FIX NOTHING without my explicit approval.

## Language
Your language of choice. Quotes from sources stay exactly as written.

3. Then tune it until it sounds like you:

Read CLAUDE.md and tell me: what is ambiguous, what is missing, what
would you misinterpret? Propose improvements, do not apply them yet.

Days 2-3: the first ingest

This is where the system becomes real. Start with the project you chose, the one with the most material.

1. Take one relevant source and save it into 1.raw/archive/ with a descriptive name, for example gazette-1936-06-14-train-station.pdf. The publication-date-subject convention: you will thank me at file fifty. (If your topic is Central European local history, the digitized newspaper archive Arcanum is your best resource.)
2. Give the agent:

Ingest the file 1.raw/archive/gazette-1936-06-14-train-station.pdf
following the flow in CLAUDE.md. At the end I want the exact list of
pages you touched.

3. Check the first page it produces word by word against the source. The whole system is worth exactly as much as its accuracy. When you find an error, do not just fix it, turn it into a rule:

You wrote that the station opened in 1935, but the article says 1936.
Fix the page, and add to CLAUDE.md, under INGEST, the rule that would
have prevented this.

That loop is what makes the system improve: every mistake becomes a line in the constitution.

4. Repeat with 2-3 more sources, then ask:

Show me index.md and log.md. Do they match the pages that actually
exist on disk?

I discovered ghost pages and missing index entries on day three. Check from day one, it costs two minutes.

Days 3-7: the rhythm

1. A small daily habit beats the marathon: 1-3 sources a day, in 30-60 minute sessions, not one weekend day with twenty.
2. After each archive session, ask the vault what it already knows:

What do I know so far about the family that owned the mill? Cite the
pages. What is missing, and what search terms would you try in the
archive to fill the gaps?

The second half of that prompt is the quiet superpower: the agent becomes the one writing your search list, and you do what you do best, find the needle. The right division of labor: you find and save, it processes and connects.

3. The same flow carries a job search, if that is your domain: postings, applications, interview notes and rejection emails all become sources, and the vault remembers every interaction long after you stopped counting. For example:

Ingest the notes from today's interview. Update the company's entity
page and the pipeline page. Then tell me: what patterns repeat across
my last five interviews?

4. Good answers must not die in the chat:

Save this analysis into 2.wiki/syntheses/ with frontmatter, and update
index.md.

For a book project, these syntheses become chapter drafts directly.

5. At around ten ingests, run the first LINT. Read the report, approve selectively ("fix 1, 3 and 4, I will handle 2"):

Run a full LINT following CLAUDE.md. Numbered report, no repairs.

The "aha" moment lands around here: the agent starts connecting sources you found weeks apart, the same building in three newspapers from three different decades.

Days 8-10: git, the safety net and the dual backup

Until now your vault lives on one disk. If the laptop dies, the research dies. Git solves exactly that, and gives a research project something precious on top: the complete history of your work, every version of every page, with its date. You do not need to understand git like a programmer. You need to know what it does for you and let the agent operate it.

1. Understand before you configure. The first command is not setup, it is an explanation:

Explain to me, as someone who has never used git: what git is, what
GitHub is, what commit, push and pull mean, and why any of it makes
sense for a research vault. Fifteen lines maximum, no jargon.

2. Start with local git. This gives you history on your own machine. If git is not installed yet, the agent will install it for you, just ask:

Initialize git in this vault, with a .gitignore that excludes
auto-generated files. Make the first commit. Do not publish anything
online yet.

3. Pick a provider for the cloud copy. My recommendation: GitHub. It is free for private repositories, it is the most beaten path (whatever goes wrong, the agent knows how to fix it), and it plugs into the Claude ecosystem in ways that pay off below. GitLab or Bitbucket are perfectly fine too, but absent a specific reason, take GitHub. Create an account, then a new repository, set to Private. Private is not optional: this is your unpublished research.
4. Configure the dual, two-way backup. Laptop and GitHub keep each other current, automatically, every hour:

I created a private GitHub repository called vault. Connect this local
vault to it and upload everything we have. Then set up an automatic
hourly sync: commit locally if there are changes, pull, push. If there
is ever a conflict, stop and tell me, do not resolve it yourself. At
the end, explain in 5 lines what you configured and how I check that
it ran.

What you get: if the laptop disappears, the research exists in full on GitHub. If you edit something on another machine, it flows back at the next sync. And it costs nothing from your Claude quota: the sync is pure git, no AI involved. One more door this opens: with the vault on GitHub, you can run Claude Code remotely from any device at claude.ai/code, selecting your repository. The laptop stays home, the second brain does not.

5. Hygiene rules, tell the agent to enforce them and write them into CLAUDE.md:
   • Everything on the main branch, always. No parallel branches.
   • Auto-generated files are not versioned, only sources and wiki.
   • Never passwords, banking data or sensitive personal documents in the vault. What enters git stays in its history practically forever.
   • GitHub rejects files over 100 MB. Very heavy scans stay out of the sync (the agent puts them in .gitignore) or get archived separately.
   • Do not edit the same file on two devices within the same hour, between syncs.
6. The trust exercise. Do it once and you will never fear the system again:

Delete the file test.md, then show me how I recover it from git
history. I want to see with my own eyes that nothing is ever lost.

From my own run: my vault once sat for two days on the wrong branch and the automatic backup was blind, the commits existed on a single disk. And one lint found 4 MB of generated files versioned for nothing. Both rules above come from exactly there.

Days 11-14: the expansion

1. Only now the second domain, with 2-3 sources. Watch entities/ start stitching domains together: an architect from the capital can show up in the story of a village train station. That is where the compounding lives.
2. Institute the decision journal, the rule I lacked for seven weeks: every decision about the system itself (a new folder, a new convention) goes into 2.wiki/meta/decisions.md with the date, the reason, and a field "check by [date]: did it work?". Otherwise you accumulate decisions without learning from them.
3. Close week two with a small retrospective:

Look at log.md over the last two weeks. What patterns do you see?
Where did I lose time? Which CLAUDE.md rule did I break?

4. And once these two weeks are behind you, start widening the circle at your own pace: look up what MCP, automations and routines mean, and bring the agent any new idea you would like to try. The automation ban in the next section is about sequencing, not about never.

What not to do in the first month

Every line below is a scar, not a theory.

• Zero automation. No automatic emails, scheduled tasks, integrations. I spent weeks on an automated email pipeline I later switched off almost entirely. Your base system is a folder, Claude Code, and the index/log discipline. That is all.
• Zero extra tools. You do not need Obsidian, Notion, anything. Markdown opens everywhere.
• Do not migrate everything you have. One project, then a second. I once poured 1,735 files in at once and created more triage work than value.
• Do not let the agent make structural decisions alone. You direct, it maintains. Any unapproved "I reorganized your folders" gets reverted.
• Keep infrastructure under control. If more than roughly 20% of your time with the system is about the system (setup, tooling, cosmetics) rather than content, stop and go ingest sources. Mine climbed far above that at one point, and it is the most reliable alarm signal I know.

The shortcuts, in one table

That last row makes a bigger point. None of this is static. Seven weeks in, a project I stumbled upon taught me that a decision without a later "did it work?" is just a record, not experience, and my constitution changed the same day. Ideas will keep arriving from everywhere: a report, a product, a conversation with a friend. The system is designed to absorb them, one rule at a time, and yours will end up looking like you, not like mine.

The person who taught me needed months. I needed six weeks. My friend gets this guide so he needs two. If you are where he was last week, license bought, cursor blinking, no first move: this is the first move.

In two weeks, do not tell me how it went. Show me your log.md.

And if you have come this far and it still feels hard, there is one more door: hand Claude this very article.

Here is the structure I sketched for myself: a main folder with job
search, academics and community. I want to replicate what Tudor
describes in this article:
https://tudorcretu.ro/blog/the-first-move/
Help me understand it while we build it.

Question everything until you understand it.

Stick around.

💬 Visit the website to comment. The discussion is open on tudorcretu.ro.

Fourteen years ago, my job was to answer customers in public. Turning the company's internal documentation into something anyone could find and read was not in the job description. I did that part on my own.

I was a moderator on a Romanian telecom forum. I registered in January 2012. I had been answering support questions there for a few months when I started a side project: take the internal know-how, the stuff locked inside the company, and rewrite it for the outside. I adjusted the language so a normal person could follow it. I added screenshots, links to other resources, and files to download.

And I made it findable. I wanted someone typing "ras error 635" into Google to land straight on the fix. So I tagged almost every article on the site, not just mine, because I could see the cross-references and knew the platform would recommend better if I did. Nobody asked me to. I ran it past the customer service team, then just did it. It ended up in my performance reviews.

One of those guides was for getting a mobile connection to work, organized by error code: 619, 680, 633, a section each, cause and fix, in plain language. It is still there, archived on the Wayback Machine from 2014. Around eighteen thousand people read that one page.

Here is the part I only understood later: I loved doing it. On the forum, I was constantly pointing from my replies back to articles that backed up what I was saying. I was writing documentation and didn't know it. Now I do. And a year before this, I had done the exact same thing on Softpedia, unpaid, on my own time, before there was any program for it. I was already this person. I just did not have a word for it yet.

I did not stop when I moved on. At Okta and at Microsoft, I kept documenting processes. I left the cleanest handover I could, because I had spent a year and a half mentoring and shadowing the person taking over, before I knew I would leave Microsoft in 2023.

It has broken once. In 2024, back at the same telecom company for an e-commerce role, I walked into Black Friday prep with no docs to inherit and no time to write any. I caught up before I left. The record was there when I walked out.

This month, I started somewhere new. I can tell you exactly what I did on day three.

Halfway through research, demos, and different analyses, I realized the whole thing lived in exactly one person's head. Nowhere else. No document, no diagram, no ticket. So I started writing and reviewed it with the SMEs for technical accuracy.

Written down once, done well, it means nobody spends their time on the same question twice.

Before my first day, I wrote myself a six month plan. Part of it came from one of my mentors. Their advice was blunt, and it stuck: decode every vague term in the job description before you act on it. Do not assume, ask. So the first appendix of my plan is exactly that, a table of every fuzzy phrase in the role turned into a question, and who could answer it.

That plan is the same reflex as the error code guide from 2012. Read first. Write down what is not written down. Only then act.

Here is what I actually believe, and I'll argue for it: the first thing a product owner ships in a new job is not a feature. It is the documentation that was missing. If a process lives in one person's head, that is not a nice-to-have to tidy up someday. That is the first item on the backlog.

There is a line from Elena Verna I keep coming back to: "AI has made average intelligence incredibly cheap and it has given everyone the vocabulary of expertise." Everyone can say vector database, agents, RAG now, and it has become hard to tell who has actually done the work. My answer to that is boring on purpose. I would rather leave proof of work. A guide from 2012 you can still open. A plan I wrote before I started. A process I documented in my first week. Proof you can check beats words anyone can borrow.

I am not chasing visibility. I am preparing for a world where an AI might decide on a promotion or a new role before a person ever reads my name. When that day comes, I want the proof already on the table.

The habit is fourteen years old. It is the least AI-native thing about me, and it is still the one that pays. Read the docs. Write down what is missing. Then build.

Stick around.

💬 Visit the website to comment. The discussion is open on tudorcretu.ro.

Last Tuesday I lost fifteen minutes with Gemini on something I do by hand in five: formatting a list of action items for Design Unfold so they'd look right on WhatsApp. I asked for bold. It gave me italics. I asked again, it hid the markers. Again, it buried everything in tens of emojis.

The right answer, drop it all in a code block so I could copy the raw text, was there the whole time. It only surfaced after I said I was losing ten minutes cleaning up by hand. So I asked it: “Why didn't you give me this first? I didn't think of it. You knew what I wanted.” It had optimized what I literally asked for, not what I actually needed.

This week I went through two courses to catch up: Karpathy building a model from scratch and a Stanford lecture on agentic LLMs. I've seen what the soup is made of. The AI we have access to is a giant, well-made broth, good enough to produce something passable. It matches patterns. It doesn't reason about what you want.

The uncomfortable part, according to Yuval Harari in Homo Deus, is that we're algorithms too. This morning I sat an exam on timber structures. I drew plywood. I wrote a page and a half, maybe 30% of it true, the rest improvised, but I pushed. The second test wanted me to identify and describe five structures from a manual I never opened. I faked them from a colleague's twelve NotebookLM clips and a cheatsheet. I passed. The machine and I both produce slop when volume is what counts.

It's not that I hate the course, the opposite. I loved the assistant professor, I loved the technical drawings I did in the lab, and I'll reach out to him in the coming years to help me validate ideas for my future home. But the lead professor showed up for the first time today, on exam day, and held it at maximum security and maximum expectations.

What I refused, with Gemini and at the exam alike, was to pretend the slop was more than slop. I didn't say AI prepped my materials fast, it made me slower, and I said so. I didn't call a passing grade competence, I named it out loud. I didn't abandon Gemini after four misses either because I knew it would get there with the right framing.

We all make slop. The line between AI-native and AI-fooled is drawn by each of us, every time we decide what we'll ship and call good enough. Where's yours?

💬 Visit the website to comment. The discussion is open on tudorcretu.ro.

A few weeks ago I sat down on a Saturday, free from university for once, and by Sunday morning I had a working second brain. Not a folder of notes. A system that reads my sources, writes its own pages, links them together, and tells me what it changed. This week I handed it one messy conversation and it turned into ten connected pages before I had finished talking.

I want to tell you how that happened, because the interesting part is not the AI. It is what was already there before the AI showed up.

The thing I could not start

I first heard the "second brain" idea back in March, mostly through Nate B Jones, who keeps shaping how I think about this shift. (The clearest recipe I have read since is Andrej Karpathy's idea file: use the model to compile knowledge, not to answer questions.) I understood the concept the same day and then did nothing with it for two months. Every guide I found started in a different place, and I could not see where mine began.

That is the part most build-in-public posts quietly skip. The blocker was never the tooling. It was that I could not see the first move.

What actually unlocked it

It came in two separate pieces, and the order matters.

First, in May, I joined a track at Product Makers called "Get Work Done with AI Agents". Not a hype session. A practical, mentor-led space for product people working out where agents actually help: research, synthesis, planning, documentation, and the honest trade-offs. That gave me the frame.

Then, about a week later, I caught a separate hands-on Claude Code workshop with Ady Rugină (still running, currently 50% off). I built SEBI off the back of it, that same weekend. Weeks after, Ady flew in from London to teach the same material live at Product Jam 2026, and I finally met him in person, having already shipped my own version of it.

But the part I am proud of has nothing to do with either room. By then I had already spent weeks splitting my life into a structure inside Linear: initiatives, finances, community, the academic side, the people who matter. When I sat down to build, I was not designing a system. I was transcribing one that already lived in my head. That is why it worked by the next morning. The AI did not give me that head start. I already had it.

What SEBI actually is

No magic. It is a folder of markdown files and Claude Code wired to read and write them, with firm rules about what it can touch and what it cannot.

The name started as a joke that stuck. SEBI, from SEcond BraIn. The "Intelligence" came later, once the thing started teaching me back, so now it reads as Second Brain Intelligence. It also happens to be Sebastian, a name I like, which is part of why it stuck.

I am not going to oversell it. SEBI is a tool, not a colleague, and a genuinely valuable one. It is the kind of tool I was reluctant to reach for at first, until I understood what skipping it would cost me later. Start late and you pay it back with interest.

The receipts

The whole point of building in public is that I can show this instead of claiming it.

This week I gave SEBI one messy input: a long mentorship conversation, a PDF, and a pile of half-formed reactions. It produced a clean source page, updated five related pages, corrected something I had quietly been overstating about my own past, flagged a contradiction in my own archive, and logged the lot. One input, ten linked pages, and a paper trail of what changed and why.

It is not magic, and I will not pretend it is

The same week, I lost fifteen minutes arguing with a different AI over a formatting job I could have done by hand in five. It knew what I wanted and still made me drag it there. I will tell that story on its own, because the lesson in it matters. I said it in my first post and I will keep saying it: I will not pretend to be more AI-native than I am. That kind of debt always comes due at delivery.

The lever was never the AI

If there is one thing to take from this, it is this. The AI did not make me faster. Having already done the thinking made me faster. The tool only had to carry it the rest of the way.

So if you are stuck where I was in March, do not start with the tool. Start with the structure of your own work. The system is the thinking. The agent is only the part that writes it down.

I am building this one in the open, receipts and all. Stick around.

Later edit: a friend read this post, bought a license, and told me he still did not know where to start. So I wrote down the first move, step by step: see it in action here.

💬 Visit the website to comment. The discussion is open on tudorcretu.ro.

Soon, someone is going to decide whether to trust me. They won't ask me. They'll ask an AI.

I know how this works, because I do it too. A few weeks ago I needed a voice recorder. I didn't read ten review sites. I described what I needed to an AI, my budget, how I'd use it, what actually mattered to me, and it pointed me to the Olympus WS-882. I bought it. The people who market voice recorders had nothing to do with that decision. An agent interpreted the options, and I trusted the interpretation.

What just broke

For twenty-five years the internet ran on attention. You shouted, you got eyeballs, you pushed people down a funnel. That era is ending. We are moving to an interpretation economy, where the web is filtered through what an AI thinks about you. And it works the same way for hiring as it does for voice recorders. Hiring managers already trade prompts to find candidates. The first question about me will be answered by a machine reading whatever I left on the internet.

The part most people keep private: between 2023 and 2024 I sent around 700 job applications. Then another 500 from September 2025 to June 2026. Twelve hundred applications. Tailored CVs, AI-written cover letters, keyword-matched searches. I got very good at the back-office motions of job hunting. And here is what it taught me: none of that is a differentiator anymore. Everyone does it. It is table stakes now, the noise everyone produces.

I am not telling you this to complain about the market. I survived it, and lately I have started to do more than survive. I am telling you because the lesson was not cheap. It cost me a lot of trying, and close to two years of income, before it sank in. I have stopped treating that as money lost and started treating it as tuition: what I paid to learn how this new world works, and how to move in it.

Optimizing the old motion harder does not work once the game has changed.

Proof, not promises

What works is proof. Not the dressed-up LinkedIn or the emotional language everyone leans on, but evidence an agent and a human can both read and verify.

As a product owner I am lucky here: my work produces public artifacts. Sprint outcomes, the decisions behind them, the reasoning that put a backlog in that order in the first place. I can show the work instead of claiming it, so I will. This site, this blog, the things I ship in the open, they are my truth layer. When someone asks what I can do, I want the answer already on the table, provable.

First, a quick introduction, so it is easy to read. I started at the customer front line: troubleshooting tickets, writing docs nobody read, taking the escalations nobody wanted. Twelve years later, across Vodafone, Microsoft, and Okta, I went from support to product ownership, with a long detour through strategy in between. I am technically grounded. I still read the docs before I write the requirements. That is the habit everything else is built on, not a slogan.

Opinions, finally in public

The harder part of proof is having opinions. I learned that one the painful way.

Thirteen years ago I covered an Apple iPhone launch on my blog, fast and clean. The problem was that it was pure relay, copy-paste, with not a single opinion of my own. A couple of weeks later, at Webstock, a well-known blogger stopped mid-talk and asked the room: "Is Tudor Crețu here?" Then he held up my post as the example of exactly what not to write. His point, and he was right, was simple: people can find the news anywhere. They come to a blog to read your opinion. And once you have a brand, they come specifically for yours.

It stung, and it stuck with me long afterward, which is why for years I kept my opinions mostly private. I have plenty now, and I am finally ready to put them in public. In an interpretation economy that is not a nice-to-have. Agents flatten everyone without a point of view into the average of their category. If you want to be found, be specific, be opinionated, and be ready to defend the opinion when someone pushes back.

From "Tudor de la Vodafone" to my own name

There are two ways to get chosen. An agent interprets the options and picks, or a human asks for you by name. I want the second one.

A few years ago I read Cal Newport's So Good They Can't Ignore You, and it named something I had already lived. Between 2012 and 2018 at Vodafone I became "Tudor de la Vodafone", the person you went to when you had a problem and needed it solved. That reputation was real, but it was tied to a company. This time I am building it in my own name. I want to be known as Tudor Crețu: a product owner and builder, a founder of products and communities, working on my own or alongside teams as capable as the work demands.

A full calendar, on purpose

Building memory in people has not become less important in the age of AI. It has become more important. The agent compares and summarizes, but the human still applies the preference. That is why I run Design Unfold, why I show up in real life, why I write this.

And it is why, for the first time, my week looks like this.

A full calendar, on purpose. I have never had this kind of clarity before. It lets me rise a little higher, look at the whole picture, and follow the paths that are actually mine, without losing the time I used to lose.

Antifragile, in the open

I will not pretend to be more AI-native than I am, because that is a debt that comes due at delivery. Instead I work with these tools in the open, every day, and I show the receipts. SEBI, the knowledge system I am building. This blog, which I publish straight from my terminal. The agents I wire into my own work.

The point is antifragility. The next time someone asks me "do you actually know how to work with AI?", and I hope that question gets rarer, I want my answer to be: not only do I know, let me show you four or five use cases for your company, exactly how I would apply them, and the steps I would take.

The work worth building a life around

The most useful idea I took from all this is an audit I picked up from Nate B Jones, whose writing shaped a lot of how I now think about this shift. You tag every piece of your week as theater, commodity, work that is on the line, or the durable kind. Theater is work that exists so the organization can perform. Commodity is real work, just work that does not need you specifically. Durable work is where you changed the question instead of answering it, where the outcome would have degraded without you in the room.

AI absorbs theater and commodity quickly. Durable work compounds to you. I want my week, and my career, organized around the durable part.

I recently read Endure by Alex Hutchinson. Its argument is that endurance is the struggle to continue against a mounting desire to stop, and that our limits are set as much by the mind as by the body, far more elastic than they feel in the moment. Those twelve hundred applications were my version of that. The desire to stop was real, and the limit kept moving anyway. What I am changing now is where I point that endurance: not at more of the old motion, but at durable work that compounds, at a pace I can actually hold. Something sustainable enough to give me the space, and eventually the means, to invest back. In other people, and in initiatives that help those stuck in the same problems I just described.

The real obstacle to all of this is identity. The audit, and the last few years, force you to update the story you tell yourself about your own value. That update is expensive now and pays off later. I would rather make it on my own terms than have an organization make it for me. That is what building in public is for.

So that is who I am, and why I am doing this now. I know I like to work, and I like to make things that are genuinely good. If that is true, then everything from here should only turn out better.

If you care about craft, value autonomy, and want to build better products, this is the conversation I am trying to have. Stick around.

💬 Visit the website to comment. The discussion is open on tudorcretu.ro.