TL;DR;

The blank page is a creative energy killer, especially when you’re trying to maintain a specific voice. I built an AI writing workflow using Cowork that turns messy notes into structured first drafts by pulling from two living documents:

• voice.md (how I sound) and

• audience.md (who I’m talking to).

You can learn more about How to Use Claude Cowork to Build Your AI Digital Twin.

Welcome👋🏻

I am a Software Engineer with 10+ years of experience. My goal is to close the gap between the technical and the non-technical, making AI accessible to everyone, regardless of their background.

Subscribe now

Earlier today, I was looking at a single bullet point in my Notes app and a voice memo I recorded while walking in the park. In my head, the idea was great. On the screen, it was a mess.

The problem isn’t the idea. It’s the gap between a “messy thought” and a “polished draft”.

For my newsletter, Becoming with AI, my subscribers aren’t looking for technical jargon. They want clarity and a human connection. But after 10+ years as a software engineer, my brain defaults to tech speak. When I try to fix it, I overcorrect into “generic robot”. Neither is my actual voice.

The Real AI Writing Problem: It's Not Ideas, It's Translation

Let me be specific about what was actually happening. I never struggled with having something to say. The struggle was translating a messy idea into a draft that matched the tone I’d spent months developing.

Every time I sat down, I was doing two jobs at once:

1. Figuring out what to say (the content)

2. Figuring out how to say it (the voice)

Doing both simultaneously is exhausting. It’s like trying to build furniture and paint it at the same time. You end up with a sticky mess.

What I needed was a way to separate those two tasks. Get the “how to say it” part handled well enough that I could focus entirely on “what to say”.

My AI Writing Workflow System: voice.md + audience.md

Here’s what I built.

The core of it is a Claude Cowork workflow that pulls from two files I maintain and update regularly. These aren’t static instruction files you write once and forget about. They’re living documents that evolve as the newsletter grows.

• voice.md: A profile of my rhythm, vocabulary, and structural patterns. It includes real examples of what I actually wrote.

• audience.md: A profile of who I'm writing for. Their experience level, what they care about, what confuses them, the language they use, and what they're actually trying to accomplish when they read my stuff.

When I have an idea, even if it’s just a few scattered bullet points or a messy paragraph of thoughts, I drop it into the Cowork. Then Cowork pulls from both files and produces a structured draft that matches my “human-first” vibe.

That's it. The output isn't a finished article. It's a first draft that sounds like me instead of sounding like a chatbot wearing my hat.

Why Showing AI Real Examples Beats Any Style Guide

Most people try to “describe” their voice to AI:

“Write in a warm, conversational tone”.

The AI nods, then produces a generic post that sounds like every "Thought Leader" on your feed.

I've found that showing AI real examples works far better than any style guide you could write. So instead of instructions, I give it evidence. My voice.md file isn't a list of adjectives about my tone. It's full of actual patterns pulled from actual articles I've written. Specific sentence structures. Real examples of my rhythm. The exact words I reach for and the exact words I avoid.

The difference is night and day. When you tell an AI “be warm but direct”, you get generic warmth. When you show it fifteen examples of what your version of warm-but-direct looks like in practice, you get something that actually sounds like you sat down and wrote it.

Try out this today:

1. Open your 3-5 most recent pieces of writing (articles, emails, whatever you’re proud of).

2. Copy 5-10 sentences from each that really sound like you. The ones where you’d say “yeah, that’s my voice”.

3. Paste them into a new document and look for patterns. Do you use short sentences for emphasis? Do you reach for metaphors? Do you start with stories or with statements?

4. Write those patterns down as observations, not instructions. “I tend to follow a long explanation with a short punchy sentence” is better than “use short sentences sometimes.”

5. Save that document. That’s the beginning of your voice.md.

How to Build Your voice.md File (Step by Step)

Here's a starting point you can steal and adapt:

Sentence Rhythm: [Describe the pattern. Short then long? Long then short? Do you use fragments? Single sentence paragraphs?]

Vocabulary: [Words you actually use. Words you never use. Do you reach for metaphors or stay literal? Do you use jargon or translate everything?]

Structure: [How do you open articles? How do you close them? Do you use lists, subheadings, both?]

Tone: [Not adjectives. Examples. Paste 3-5 sentences that capture your exact tone.]

Things I Never Do: [This is actually the most useful section. Knowing what to avoid is more actionable than knowing what to aim for.]

Real Examples: [Paste 10-15 of your best sentences. The ones that really sound like you. This is the evidence the AI needs.]

The Things I Never Do section is where a lot of the magic happens. For me, that includes things like: “I don’t prefer to use em-dashes for dramatic effect, I never open with rhetorical questions, I never use words like ‘harness’ or ‘landscape’ or ‘delve’”, etc.

Constraints are more useful than aspirations when you're teaching a system to mimic your voice.

How to Build Your audience.md File

Your voice file tells the AI how you sound. Your audience file tells it who you’re talking to. Both matter.

Here is the starting point you can steal:

Who they are: [Job titles, experience level, what they know, what they don’t]

What they’re trying to do: [Not “learn about AI”. Be specific. “Figure out how to use AI at work to increase productivity.”]

What frustrates them: [What have they tried that didn’t work? What makes them feel lost?]

Language they use: [How do they describe their own problems?]

What they don’t need: [Technical depth? Hype? Knowing what to skip is as important as knowing what to include.]

For Becoming with AI, my audience is non-technical but intellectually curious. They don't need to understand how something works under the hood. They need to be able to do something useful in 20 minutes.

That single insight shapes every draft the workflow produces.

The Exact AI Writing Prompt I Use (Copy This)

Put your voice.md and audience.md file into a folder called, let’s say, “AI Cowriter”. Add your notes to notes.md file and put it into the same folder. We will let Claude Cowork do the rest for us.

Here’s the exact prompt structure I use when I drop my messy notes into the workflow:

I'm writing an article for my newsletter 'Becoming with AI'.
Read all files in this folder carefully before you start:
voice.md: how the writing should sound
audience.md: who my audience is
notes.md: my notes on a Substack article

Produce a structured first draft with:

- A TL;DR section at the top
- Clear subheadings for each major section
- Practical prompts, templates, or step-by-step guidance wherever I'm describing a process
- A closing section that connects the practical to the personal

This is a first draft, not a final piece. Prioritize getting the voice and structure right. I'll handle the sharpening.

That last line matters. It sets the expectation correctly; for me and for the AI.

This isn't about generating a finished article. It's about getting past the blank page with something that already feels like mine.

What This AI Workflow Actually Changed (Not What I Expected)

The impact has been huge for my creative energy, but probably not in the way you’d expect.

The “blank page” problem is mostly gone. That’s real. I’m no longer starting from zero, fighting with a blinking cursor for thirty minutes before I have anything usable. Instead, I sit down and I’m immediately in editor mode; sharpening, rearranging, adding the details only I can add. That’s a completely different kind of creative work. It’s energizing instead of draining.

But here’s the part that surprised me.

This is definitely not a “set it and forget it” system.

The quality of the draft depends entirely on how much effort I put into updating those two files. If I write a great article and don’t pull the best patterns from it back into voice.md, the next draft will be slightly less “me”. If my audience evolves and I don’t update audience.md, the framing starts to drift.

And that actually keeps me more connected to my own writing process. Not less. I’m constantly asking myself: “What worked about that piece? Why did that paragraph land? What would my readers actually need here?”

Those are exactly the questions a writer should be asking. The system forces the reflection.

The Human Element

I want to be honest about something. When I first started building this, there was a part of me that felt weird about it. Like I was outsourcing something that should be purely mine.

But here’s what I’ve come to understand: the AI isn’t writing for me. It’s giving me a running start. Every draft still needs my eyes, my judgment, my experience, my willingness to cut the stuff that sounds right but isn’t true. The messy notes are mine. The voice profile is built from my actual writing. The audience profile comes from real conversations with real readers.

The system doesn’t replace the human work. It moves where the human work happens. Instead of spending my energy on the mechanical translation from “messy idea” to “structured draft”, I spend it on the part that actually matters: making the piece honest, useful, and specific.

I’m still the one deciding what to say. The workflow just helps me say it faster in a way that already sounds like me.

And I’m still updating those files. Still refining. Still learning what my voice actually is by paying close enough attention to write it down. That’s the unexpected gift of the whole thing: building the system taught me more about my own writing than years of just doing it.

Which part clicked for you? Or which part still feels fuzzy? Drop it below; your question might be the next article!

Leave a comment

PS: If you're new here and wondering why a software engineer is writing about all this - here's why I started Becoming with AI."

TL;DR;

We all feel “AI fatigue” from time to time.

By March 2026, the average professional is paying for four or more AI subscriptions; most of which are quietly draining your bank account while doing exactly nothing for your workflow. The fix isn’t “better” tools. It’s building a Minimal AI Stack: the absolute fewest tools required to cover your entire lifecycle of your work, organized into three layers.

• Layer 1 - The Brain (Research)

• Layer 2 - The Studio (Creation)

• Layer 3 - The Hands (Action)

Welcome👋🏻

I am a Software Engineer with 10+ years of experience. My goal is to close the gap between the technical and the non-technical, making AI accessible to everyone, regardless of their background.

Subscribe now

If you feel like you are drowning in “productivity”, you aren’t alone.

I’ll be honest with you: I’ve been going through the same digital exhaustion myself lately. Every morning, I wake up to three new “game-changing” newsletters, four “must-have” browser extensions, and a nagging feeling that I’m falling behind. Creating this system, this Minimal Stack, was my way out of the noise. This article isn’t just a guide for you; it’s a necessary reminder for me.

By March 2026, the novelty of AI has worn off, replaced by a persistent, low-grade weight. Your browser probably has thirty tabs open; three different chatbots, a research tool you saw on a reel, two image generators, and a PDF summarizer you’ve used exactly once. You are likely paying for at least four AI subscriptions, most of which are quietly draining your bank account while doing exactly nothing for your actual workflow.

The irony of 2026 is that while AI was promised to save us time, we are spending more time than ever “managing” our tools. We’ve become operators of a digital factory rather than creators of work.

To find our way back, we have to stop collecting tools and start building a System.

Why AI Tool Fatigue Is Costing You Time (and Money)

Before we look at the apps, we have to talk about mindset.

Most people approach AI like a hobby, they “play” with it when a new version drops. To actually get work done, you must treat AI like a hire. If you hired a human assistant and they didn’t show up for work for two weeks, you’d fire them. You should do the same with your AI subscriptions. If a tool hasn’t moved a project toward the finish line in a week or two, it is clutter. It is taking up “mental shelf space”.

To build a minimalist stack, we are going to organize your digital life into three distinct layers:

1. The Brain: Where you find facts and organize your own information.

2. The Studio: Where you draft, design, and build the final product.

3. The Hands: Where you take action or automate the “boring stuff” so you don’t have to click.

Layer 1 - The Brain: How to Research Smarter with Perplexity and NotebookLM

Everything starts with information. But in 2026, the internet is a minefield of AI-generated noise and “slop”. You need a “Brain” that doesn’t just talk, but provides receipts.

The Explorer: Perplexity

Perplexity is the single greatest replacement for the Google Search. We used to search, click a link, realize it was SEO spam, go back, click another link, and repeat.

In 2026, Perplexity’s Deep Research does this for you. You ask a complex question; say, “What are the current tax implications for digital nomads in Portugal as of March 2026?”and the AI acts as an agent. It clicks through dozens of sources, reads the fine print, and compiles a cited report.

The Citations Rule: Why Unverifiable AI Is a Liability

In Perplexity, every claim has a footnote. Clicking that takes you directly to the original source. For a professional, this is non-negotiable. If an AI tells you a statistic but can’t show you the source, it might get you into trouble.

The Librarian: NotebookLM

While Perplexity explores the world, NotebookLM organizes your world. It is a private library where the only books on the shelf are the ones you put there.

The 2026 Use Case: You can now upload YouTube links, PDFs, and even voice memos. The Cinematic Video Overview feature can turn several pages of messy notes into a narrated video or a “Deep Dive” podcast where two AI hosts discuss your ideas. You can listen to your own research on your commute. It is the ultimate tool for “internalizing” information rather than just storing it.

Subscribe now

Layer 2 - The Studio: Draft Branded Work Faster with Claude Cowork and Gemini

Once you have your facts, you need to produce something. This is where most people get overwhelmed by prompting. In a minimal stack, we move away from chatting and toward Coworking.

Claude (Cowork & Skills)

As of early 2026, Claude Cowork is the gold standard for drafting. It isn’t just a chat bot; it’s a dedicated space on your computer where Claude acts as a “Desktop Colleague”.

Teaching Claude a Skill: Your AI Digital Twin

The biggest friction in AI is repeating yourself: “Use my brand colors”, “Keep it professional”, “Use my bio”. In 2026, you teach Claude these as a Skill. You upload your brand guidelines or past work once. From then on, you simply say, “Claude, use my ‘Consultant Skill’ to turn this research into a slide deck”. It handles the fonts, the tone, and the layout automatically.

Claude Code: For the non-technical person who has big ideas, Claude Code is the “Technical Teammate”. You don’t need to know how to code; you just describe the tool you want; like a custom calculator for your clients or a personal dashboard, and Claude builds for you.

The Efficiency Play: Gemini (Google Workspace)

If you live in Google Docs and Gmail, Gemini is your shortcut. It lives in your sidebar, summarizing 100 email threads and drafting responses that align with your actual calendar availability, no switching tabs required. It is the best tool for the “Logistical” side of creation.

Layer 3 - The Hands: Automate Repetitive Tasks with Claude and Zapier

The final layer is Automation. This is the “glue” that connects your Brain to your Studio so you stop being a “Copy Paste” person.

Claude in Chrome

Anthropic has a browser extension called Claude in Chrome that turns Claude from a chatbot that answers questions into an assistant that takes action in your browser. Claude works directly in a side panel while you browse, seeing what you see and taking actions when you ask.

Record a workflow

Think of it like showing a new hire exactly how you do something, once. You perform the steps, Claude watches, and from that point on it can repeat the whole thing without you lifting a finger. Click record, do your thing, stop, save it. That’s your shortcut.

This isn’t about automating complex systems. It’s about getting the ten minute tasks, the ones you do the same way every single time, off your plate for good.

Claude Cowork Scheduler

Cowork's scheduler is the closest thing to hiring an assistant who never forgets. You describe the task once; a weekly competitor roundup, a daily email briefing, a recurring report from your Google Drive and Claude runs it on whatever rhythm you set, delivering a finished output every time.

No reminders, no setup friction, no starting from scratch. But here's the caveat: scheduled tasks only run while your computer is awake and the Claude Desktop app is open. If either is off when the task is due, Cowork skips it and runs it once you're back.

The Connector (Zapier & n8n)

Claude is remarkable at thinking. It reasons, writes, summarizes, and executes tasks on your computer. But it doesn’t live inside your other apps. It can’t watch your inbox and react when something arrives. It doesn’t know when a new row lands in your spreadsheet, when a form gets submitted, or when a Slack message needs routing somewhere else. It just waits for you to show up and ask.

That’s the gap Zapier and n8n fill. They don’t think, but they watch, trigger, and connect. A new lead comes in, a file gets uploaded, a calendar event is created; these tools catch that moment and set the chain in motion, with or without you at the keyboard. At that point, you can bring Claude into the middle of the flow to do the reasoning work. But the trigger, the routing, the delivery to the right destination? That’s Zapier and n8n’s job.

Zapier is the easy to use; prebuilt connections, visual setup, no technical background required. n8n gives you more control and runs cheaper at scale, especially if you’re self-hosting. I haven’t used Zapier, I’ve been trying out n8n, but they are fundamentally doing the similar things: if you want automation that runs while you sleep, you need something that watches the world for you. Claude alone doesn’t do that.

Do you want to know more about the automation? Let me know in the comments!

Leave a comment

How to Stop Adding AI Tools and Start Getting Work Done

The most dangerous thing about AI in 2026 isn’t that it’s “smarter” than us; it’s that it’s faster. It can generate noise faster than your brain can process it. If you don’t build a system to filter that noise, your minimal stack will quickly become a maximal mess.

To stay minimalist, you need a “Tool Gatekeeper” System:

The “One-In, One-Out” Rule

Treat your AI stack like a crowded closet. If you want to add a new “cool” tool you saw on social media, you have to delete one you already have. This forces you to ask: “Is this new tool actually better than my current Studio, or am I just bored?”

The Friction Test

Before signing up for any tool, ask:

• Does it provide citations? (If not, it’s for play, not work).

• Can I teach it a “Skill”? (If not, I’ll spend too much time repeating myself).

• Does it have “Hands”? (Can it talk to Zapier or move my mouse? If it’s just a chat bot, it’s adding more copy-pasting to my life).

The “Output First” Routine

Never start your day by “playing” with AI. Start by identifying the Output you need (e.g., “A drafted report”). Then, and only then, pick the tool from your stack that handles that layer. AI should be a response to a problem, not a search for one.

Weekly Maintenance

Every Sunday, look at your browser tabs and your subscriptions. If you haven’t used a tool to finish a project in the last week or two, close the tab and cancel the subscription. The goal is to reach a state of Flow, and you can’t flow when you’re constantly toggling between ten different “assistants”.

Simplicity Is Your AI Superpower: Build Your Stack Today

The promise of AI in 2026 wasn’t to turn us all into “AI engineers”. It was to give us back our time. But you only get that time back if you are willing to say “no” to the noise.

The most productive people I know in 2026 aren’t the ones with the most apps. They are the ones who have mastered three tools. They have a Brain they can trust, a Studio that knows their voice, and Hands that handle the repetitive clicks.

I’m still working on this myself. I still get tempted by the shiny new “Agent” of the week. But every time I feel that fatigue creeping back in, I return to these three layers. This article is my reminder as much as it is yours.

Build your minimal stack today, set up your “Gatekeeper” system, and then, most importantly, use that extra time to go do something that doesn’t involve a screen.

Which part clicked for you? Or which part still feels fuzzy? Drop it below; your question might be the next article!

Leave a comment

PS: If you're new here and wondering why a software engineer is writing about all this - here's why I started Becoming with AI."

TL;DR;

Most people open Claude Chat, paste one document, get one answer, then repeat, manually, for every other file. That’s not a workflow. That’s copy-paste with extra steps.

Claude Cowork fixes this. It’s not a chatbot. It’s an AI coworker that reads your entire folder, writes in your voice, and delivers board-ready documents — while you grab a coffee. ☕ No coding required.

What’s inside this guide:

• Claude Cowork vs. Regular Chat: Why pointing AI at a folder changes everything — and why it’s the professional upgrade non-technical users have been waiting for.

• The Nina Case Study: How one Head of Ops turned 3 pages of messy meeting notes into a polished board presentation in minutes — without touching PowerPoint.

• Build Your AI Digital Twin: The voice.md and working-style.md system that makes Claude sound like you, not a generic assistant.

• The Master Prompt Formula: The exact briefing format that gets Claude Cowork to nail the task on the very first try.

• Pro Tips for Non-Techies: Why plain text files are your secret weapon — and how to set up your Skills folder for maximum speed.

• The Bottom Line: You don’t need to be a developer to automate your job. You just need the right context — and this guide gives it to you.

Already comfortable with Cowork? My vibe coding guide shows you how to go one level further: building real tools with AI.

Welcome👋🏻

I am a Software Engineer with 10+ years of experience. My goal is to close the gap between the technical and the non-technical, making AI accessible to everyone, regardless of their background.

Subscribe now

It's Monday morning, you have 3 pages of messy notes from last week's meetings, a presentation due by Thursday, and a to-do list that didn't shrink over the weekend. You open Gemini or regular Claude.

You paste one document.

You get one answer. Then you repeat, manually, for the next file.

However, this is just a copy paste with extra steps, not a workflow.

If you feel like you're working for your AI instead of the AI working for you, there is a new solution: Claude Cowork.

What Is Claude Cowork? (And How It Differs from Regular Claude Chat)

When Anthropic released Claude Code, the developer tool, they started to see that developers started to use it for everything: including to keep a plant alive, without human intervention.

Because of its potential, non-technical users also wanted to use Claude Code. The problem with that is terminal interface was intimidating for some.

Cowork is the answer to that problem. It takes that high-level “coding power” and puts it into a clean, friendly interface (Claude Desktop app) that anyone can use.

The Game-Changer: How Claude Cowork Reads Your Entire Folder

The biggest difference between regular Chat and Cowork is access.

In a regular chat, Claude can only see what you upload to that specific window. With Cowork, you point it at a folder on your computer. This is the game-changer. Once you give Claude permission to look at a folder, it can:

1. Read every file in that folder at once.

2. Edit those files.

3. Create brand new files (like spreadsheets or outlines) directly onto your hard drive.

4. Delete

Claude Cowork Setup: Plans, Devices, and What You Actually Need

• Cowork is available for Pro ($20/month), Max, Team, and Enterprise plan subscribers using the Claude Desktop app on macOS or Windows.

• Open Claude Desktop, look for the mode selector that includes “Chat” and the Cowork tab, and click “Cowork” to switch to Tasks mode.

• You point it at a folder on your computer. That's the key step. Claude can then read, edit, or create files in that folder.

Pro Tip:

The Claude Desktop app must remain open while it’s working.

Real-World Example: Automating a Board Presentation with Claude Cowork

To see how this works in real life, let’s look at FakeCo Coffee Company.

The Player: Nina, Head of Operations.

The Challenge: Nina just finished a marathon meeting with Product Managers about the Quarterly Roadmap. She has a folder full of messy transcripts and rough notes. She needs to turn these into a polished Board Presentation by April 3rd.

Instead of spending five hours summarizing and typing, Nina uses Cowork.

Step 1: The Setup

Nina puts all her meeting notes and data.csv into a dedicated folder called FakeCo Coffee.

Step 2: The Command

She opens Claude Desktop, switches the mode to Cowork, and points it to that folder. She gives one simple prompt:

Read the meeting notes in this folder. Create a PowerPoint presentation for the board 
meeting on April 3rd. Cover what we achieved last quarter, what went wrong, 
what we're focusing on next quarter, and key risks. 10 slides max. 
Professional but warm tone - this is a coffee company, not a bank.

Step 3: The Execution

Nina watches as Claude “thinks”. She can follow the progress while Claude Cowork does its job.

Step 4: The Result

In minutes, Nina has a structured outline and a summary of the data saved directly to her computer. She didn't copy and paste a single word.

Congratulations to Nina, she made her presentation in a couple minutes instead of spending hours!

However, there is a small catch.

Because Nina gave Claude a broad instruction, the AI had to fill in the blanks. It “guessed” the tone, the structure, and the formatting. While the content is accurate, the presentation might feel a bit generic. It doesn’t yet sound like Nina, and it certainly doesn’t look like FakeCo.

Build Your AI Digital Twin: The voice.md and working-style.md System

This is where we move from “cool AI trick” to “professional-grade workflow”.

By default, Claude Cowork is a bit of a guesser. If you don’t give it specific instructions, it will pick generic colors, standard fonts, and a “helpful assistant” tone that might not sound like you at all.

To get a board-ready result, you need to provide the Guardrails and the DNA.

The Two Ingredients for a Perfect Draft

To turn a generic outline into a masterpiece, Nina adds two types of files to her FakeCo Coffee folder:

1. The Corporate Guardrails (Brand Guidelines)

Most companies have a “Brand Guidelines”. It’s the PDF that tells you which hex codes (colors) to use, which fonts are allowed, and how the company logo should be placed. It ensures that whether a document is created in London or Los Angeles, it always looks like FakeCo.

2. The Digital DNA (Personal Identity Files)

This is the secret sauce that makes the presentation sound like Nina, not a robot. Nina keeps three small text files in her folder to act as a manual for her AI:

• about-me.md: Her role, expertise, and the specific perspective she brings to the team.

• voice.md: Her linguistic style (e.g., “I prefer data over fluff,” “Use short, punchy sentences,” or “Never use the word ‘synergy’”).

• working-style.md: How she structures her thoughts (e.g., “I always start with the biggest challenge first”).

This setup will help you to onboard Claude Cowork so that it can do exactly what you said.

about-me.md

By creating this simple text file, Nina has essentially given Claude a blueprint of who she is.

# About Me

## Who I Am
My name is Nina Hartman. I am the Head of Operations at FakeCo Coffee,
a Dutch coffee shop chain with 34 locations across the Netherlands.
I have been with the company for 6 years.

## What I Do
I run the quarterly planning process and own the relationship with the
leadership board. My job is to turn what the product team knows into
something the board can act on. I sit between the people doing the work
and the people making the big decisions.

## My Audience
The people I write for are busy executives. They do not want to read long
documents. They want to know: what happened, what are we doing about it,
and what do they need to decide. If I give them a wall of text, I have
already failed.

## What Good Work Looks Like for Me
- A document that gets to the point in the first paragraph
- Clear headings so people can scan before they read
- Numbers where possible — not "sales improved" but "sales up 18%"
- Action items that say who does what by when
- An executive summary at the top of anything longer than one page

voice.md

In a standard chat, Claude is a generalist. It tries to please everyone, which often results in that "too-polite AI" tone. By adding a voice.md file to her folder, Nina does something radical: she gives the AI a personality filter.

# My Voice & Communication Style

## The Feeling I Want
Warm but professional. We are a coffee company — we have personality.
But I am writing for a board, so it still needs to feel serious and
trustworthy. Think: a confident manager giving a clear update, not a
consultant writing a report.

## Tone
- Direct. Say the thing. Do not bury it.
- Human. Write like a real person, not a press release.
- Honest. If something went wrong, say so clearly and say what we are
  doing about it. Do not hide bad news behind vague language.
- Confident but not arrogant. We know what we are doing, but we are
  also learning as we grow.

## Language Rules
- Short sentences. If a sentence has more than 20 words, split it.
- No jargon. If I would not say it out loud in a meeting, do not write it.
- No filler phrases. Avoid: "It is important to note that...",
  "As previously mentioned...", "In conclusion..."
- Active voice. "We launched the app" not "The app was launched."
- Numbers over vague claims. "31% fewer drop-offs" not "significantly fewer."

## Words I Like
clear, honest, simple, on track, real, practical, next step, decision

## Words to Avoid
synergy, leverage, holistic, deep dive, circle back, bandwidth,
move the needle, at the end of the day, going forward

## Format Preferences
- Start with the most important thing, not background context
- Use bullet points for lists of 3 or more items
- Bold the key word or number in each bullet, not the whole sentence
- Tables for comparisons and status updates
- One idea per paragraph

Most people spend 30 minutes editing an AI response to make it sound like them. Nina spends 30 seconds updating her voice.md file once, and every document Claude creates from that point forward arrives already sounding like her.

working-style.md

If voice.md gives Claude a personality, working-style.md gives it a workflow.

Look closely at Nina’s rules. She isn’t just asking for a summary; she is setting professional boundaries that prevent the “AI hallucinations” and “over-explaining” that drive most users crazy.

# How I Like to Work With Claude

## Before You Start Any Task
1. Read about-me.md and voice.md first, every time.
2. Ask me 2 to 3 clarifying questions if anything about the task is unclear.
   Do not guess and produce something wrong. It wastes both our time.
3. Show me your plan in plain language before you start writing or creating files.
   I want to approve the approach, not just the output.

## While You Work
- Save your output directly into the "outputs" subfolder in this project folder.
- Name files clearly: use the format YYYY-MM-DD-description
  (example: 2026-03-14-board-presentation.pptx)
- If you are unsure about something mid-task, stop and ask. Do not fill gaps
  with invented content.
- Never delete any of my files. Only create new ones or edit files I
  specifically ask you to edit.

## Output Format Defaults
- Presentations: PowerPoint (.pptx), maximum 12 slides unless I say otherwise
- Documents: Word (.docx) with an executive summary at the top
- Summaries and notes: Markdown (.md) saved in the outputs folder
- Spreadsheets: Excel (.xlsx) with clear column headers and totals

## How I Like to Review
When you finish, give me a short summary (3 to 5 sentences) of what you made,
what decisions you made along the way, and if there is anything you are
unsure about. Do not just say "Done." Tell me what I am looking at.

## What I Do Not Want
- Long explanations of what you are about to do — just do it
- Apologies or disclaimers at the start of every response
- Generic filler content — if you do not have the information, ask me for it
- More than one version of the same thing unless I ask for options

Setting up a working-style.md file is the difference between a “Chatbot” and an Agent. You are training Claude to work the way you work. If you like to see a plan before the writing starts, put it in the file. If you hate Excel but love Markdown, put it in the file.

By combining these three identity files; About Me, Voice, and Working Style, Nina has created a digital twin that doesn't just “help” with the work; it executes the work exactly the way she would.

Do you want to know more about how to create your own Digital Twin? Let me know in the comments!

Leave a comment

Pro Tip:

You only have to write these files once. You can then copy them into every new project folder you create. It’s like bringing your best assistant with you to everyday.

Claude Skills: How to Give Your AI Institutional Memory

If the .md files we discussed earlier are Nina’s “Digital DNA”', Claude Skills are her Professional Toolkit.

A “Skill” is the difference between telling a new employee, “Make a presentation,” and giving them the company brand book, the official slide template, and three examples of board decks the CEO actually liked. It’s the same person, but the output is on a completely different level.

The FakeCo “Brand Skill”

To ensure her work is never generic, Nina adds the FakeCo Brand Skill to her folder. This isn’t just a list of colors; it’s a comprehensive guide that tells Claude exactly how to behave as a representative of the company.

The FakeCo Brand Skill includes:

• Visual Identity: The exact Hex codes (like Espresso Brown and Oat Cream) so every chart and slide background matches the brand.

• The “One-Sentence” Mission: “FakeCo is the coffee company that takes quality seriously without taking itself too seriously”. This gives Claude a “North Star” for the tone of every sentence.

• Structural Rules: Hard constraints like “Always lead with the conclusion” and “Never write a paragraph longer than four sentences in a board document”.

Why “Skills” Change the Game

When you use a Skill in Cowork, you are effectively giving Claude Institutional Memory.

Instead of Nina having to remind the AI to use “Leaf Green” for positive numbers every single time she starts a new chat, she simply points it at the Brand Skill. Claude now “knows” FakeCo. It understands that “Warm White” is for backgrounds and “Charcoal” is for body text.

Do you want to know more about Claude Skills? Let me know!

Leave a comment

Summary: The Nina + FakeCo Formula

Nina has now built a perfect environment for high-level work. By combining her Personal Identity Files with the FakeCo Brand Skill, she ensures her work is:

1. Personal: It sounds like her voice.

2. Professional: It follows her working style.

3. On-Brand: It looks and feels like FakeCo Coffee Company.

Pro-Tip: Choosing the Right File Format

You don’t have to use .md (Markdown) files, Claude can read PDFs and Word docs just fine. However, there is a “secret” advantage to using Markdown for your instructions:

• For Context & Skills (voice.md, about-me.md, etc): Use .md or .txt. These are “plain text,” which means Claude can read them instantly and perfectly without having to “extract” text from a complex layout. Think of it as giving Claude a clean, typed note instead of a photocopied page.

• For Source Material (Meeting notes, PDFs, data): Use whatever you have. If your notes are in a .docx or your data is in a .pdf, just drop them in. Cowork is built to handle the heavy lifting of processing those files for you.

The Master Prompt Formula for Claude Cowork

With her “Context Files” in place and her data ready, Nina is ready for the finish line. She doesn't just ask Claude to “write a deck”. She gives a Master Command that points to everything she has prepared:

Read all files in this folder carefully before you start:

- about-me.md — who I am and who my audience is
- voice.md — how the writing should sound
- working-style.md — how I want you to work
- fakeco-brand-skill.md — how FakeCo documents look and feel
- meeting-notes-fakeco.md — the source content
- fakeco-data.csv — the numbers behind the story

Once you have read everything, ask me 2-3 clarifying questions before you start.

Then create a PowerPoint presentation (.pptx) for the FakeCo board meeting on 
April 3rd, 2026.

The presentation should:

* Be 10 to 12 slides maximum
* Follow the slide order in the brand skill exactly
* Use FakeCo colors, fonts, and formatting from the brand skill
* Tell a clear story: here is what we achieved, here is what went wrong and why, here is 
what we are betting on next quarter, here is what we need from you today
* Include at least 3 charts or visual data callouts from the CSV — focus on revenue trend,
location growth, and staff costs
* Flag any missing information with [CONFIRM WITH NINA] rather than inventing it

Save the finished file to the outputs folder as: 2026-03-10-board-presentation-v1.pptx

When done, give me a 3-sentence summary of what you built and flag anything you were 
unsure about.

The Moment of Truth: Claude Becomes a Consultant

This is the part that usually shocks new users. In standard AI, you hit “Enter” and it starts talking. In Cowork, Claude stops to think.

Because Nina’s working-style.md told it to “Ask 2-3 clarifying questions,” Claude doesn’t just guess. It scans her notes, notices a drop in the revenue, and asks: "Nina, how do you want to frame this revenue drop from previous quarter?"

This is the shift from “Tool” to “Teammate”. By clarifying first, Claude ensures that the final presentation isn't just fast, it’s correct.

The Result: A Board-Ready Deck in Minutes

As Nina watches, Claude doesn’t just generate text, it builds. Looking at the final output, you can see the FakeCo Brand Skill in action. The slides aren’t just some generic backgrounds; they use the “Espresso Brown” headers, the “Oat Cream” accents, and clear, data-driven charts that reflect the CSV data Nina provided.

She didn’t spend her morning struggling with PowerPoint’s “Design Ideas” tool. She spent it as a Director, and Claude acted as her .

How to Brief Claude Cowork Like a Pro (Not Just Prompt It)

If you want these results, you have to move past “talking” to the AI and start “briefing” it. Think of Cowork like a highly talented intern: they are brilliant, but they can’t read your mind.

Use this simple formula for every task:

[What you have] + [What you want] + [How to format it] + [Constraints]

The Contrast:

• ❌ The Bad Prompt: “Make a presentation.”

  • Result: Claude will guess your colors, guess your audience, and guess your data. You’ll spend more time fixing it than if you’d done it yourself.

• ✅ The Good Prompt: “Turn these meeting notes into a 10-slide PowerPoint for a leadership update. Use our brand colors. Include key decisions, next steps, and exactly one slide per department.”

  • Result: You get a professional, structured document that requires minimal tweaking.

From Chatting to Building: What Claude Cowork Actually Changes

The true power of Claude Cowork isn’t that it can write; it’s that it can execute. By moving your work into folders and providing a bit of “Digital DNA” (your voice and style), you stop the endless cycle of copy-pasting.

Tomorrow morning, don’t start with a blank chat window. Start with a folder, a few .md files, and a clear goal.

Let Cowork handle the how so you can focus on the why.

Which part clicked for you? Or which part still feels fuzzy? Drop it below; your question might be the next article!

Leave a comment

PS: If you're new here and wondering why a software engineer is writing about all this - here's why I started Becoming with AI."

TL;DR:

What AI agents are: Not sentient robots, not AGI - just a simple formula: Brain (an LLM like Claude) + Hands (tools like search or a calculator) + Loop (the ability to keep trying until the job is done).

How AI agents work vs. chatbots: The difference isn't tools - modern chatbots like Claude already use them. It's who drives the loop: with a chatbot, you prompt every step. An agent takes a goal, chains its own steps, checks its own work, and finishes the task without you prompting it each time.

When you actually need one: Use Claude for quick answers. Build a custom AI agent when you want to automate a multi-step process using your own data - something that runs in the background while you sleep.

Welcome👋🏻
I am a Software Engineer with 10+ years of experience. My goal is to close the gap between the technical and the non-technical, making AI accessible to everyone, regardless of their background.

Subscribe now

Everyone’s talking about AI agents. Your LinkedIn feed is likely drowning in posts about “autonomous AI agents that will replace your entire team.” VCs are throwing money at anything with the word “agent” in the pitch deck. Every second tutorial starts with: “In this revolutionary guide...”

Let me save you some time: An AI agent is not magic.

It’s not “AGI” (Artificial General Intelligence). It’s not a some sort of a robot living in your cloud drive. And despite the hype, it’s not going to replace your entire department by Tuesday.

At its core, an AI agent is just three things: a brain, a set of tools, and a loop.

That’s it. Once you understand this simple recipe, 90% of the hype evaporates, and you’re left with something actually useful.

You're Already Using AI Agents (And Didn't Know It)

If you ask a modern AI like Claude, “What’s the weather in Amsterdam?” it will give you a real-time answer.

But here’s the secret: The AI doesn’t actually “know” the weather. That information wasn’t in its original training data. To give you that answer, the AI has to stop being a “chatbot” for a second and act like an agent.

Here is what’s happening under the hood:

The Prompt:

what is the current weather in Amsterdam? show me your thinking process

Answer:

Thinking process:

- Tool selection — Weather is real-time data that changes constantly, so I can't rely on my training knowledge. I used the weather_fetch tool with Amsterdam's coordinates (52.3676°N, 4.9041°E).
- Unit conversion — The API returned temperature in Fahrenheit (52.9°F). Since you're based in Amsterdam, I converted to Celsius: (52.9 - 32) × 5/9 ≈ 11.6°C.
- Data interpretation — The response included current conditions + a 5-day forecast. I surfaced the most relevant bits: current temp, sky condition, and notable changes ahead.

Result: It's currently sunny, ~11.6°C in Amsterdam. The week stays mild (around 13°C highs), with rain probability picking up on Wednesday (~40%).

The difference is this: A “Standard” AI is like a library. It’s a massive collection of books. It can tell you what’s inthe books, but it can’t leave the building.

• An AI Agent is the librarian who can actually walk out the front door, check the mail, make a phone call, and come back with an answer that isn’t in any of the books.

When you see an AI “browsing the web” or “checking a live price,” you aren’t just seeing a smarter chat, you are seeing an agent in action.

The Three Ingredients Every AI Agent Needs: Brain, Hands, Loop

Every agent, from a simple calendar bot to a complex coding assistant, is built from the same three pieces:

The Brain (The Language Model): Your Agent's Reasoning Engine

This is the “thinking” part (like Claude or Gemini). It reads your request and decides what to do. Its key skill is reasoning. You tell the AI, “You have access to these tools,” and it figures out which one to grab and when.

The Hands (The Tools): What Your Agent Can Actually Do

Without tools, an AI is just a brain in a jar. Tools are things the AI can actually do: search the web, read a spreadsheet, send an email, or check a database. The more tools you give it, the more “capable” it becomes.

The Loop (The Autonomy): What Makes It an Agent

This is what makes it an agent. The loop allows the AI to say: “Okay, I finished Step 1. Does the answer look right? No? Let me try Step 2.” It keeps going until the task is complete.

Brain + Hands + Loop = Agent. That’s the formula.

How to Build an AI Agent in Python (30 Lines of Code)

Enough theory. Let’s build a “Date & Deadline Agent.” It will be able to check today’s date and calculate exactly how many days are left until a specific deadline.

Even if you aren’t a developer, look at the code below. You’ll see it reads almost like English.

What you’ll need:

• Python installed.

• An Anthropic API key (from console.anthropic.com).

• In your terminal, run: pip install pydantic-ai

Create a file called my_agent.py to give the AI its instructions in VS Code and paste this in:

Do you want me to explain this part in more detail? Let me know in the comments!

Leave a comment

from pydantic_ai import Agent
from dotenv import load_dotenv
import datetime

load_dotenv() # Pulls your API key from a .env file

# 1. THE BRAIN: Give it a model and a personality
agent = Agent(
    model="anthropic:claude-sonnet-4-5",
    system_prompt="You are a helpful assistant. Use the available tools when you need current information."
)

# 2. THE HANDS: Define what the agent can actually DO
@agent.tool_plain
def get_current_time() -> str:
    """Returns the current date and time."""
    return datetime.datetime.now().strftime("%Y-%m-%d %H:%M:%S")

@agent.tool_plain
def calculate_days_until(target_date: str) -> str:
    """Calculates days until a date (format: YYYY-MM-DD)."""
    target = datetime.datetime.strptime(target_date, "%Y-%m-%d")
    delta = target - datetime.datetime.now()
    return f"{delta.days} days until {target_date}"

# 3. THE RUN: Give it a task and let the loop take over
result = agent.run_sync(
    "What is today's date, and how many days until 2026-12-31?"
)

print(result.output)

When you run the code above, you will see a result like this:

Today's date is **March 8, 2026**, and there are **297 days** until December 31, 2026.

What just happened?

You didn't tell the agent which tool to use first. You just gave it a goal. The "Brain" saw your question, realized it didn't know the date, used the "get_current_time" tool, then used the "calculate_days_until" tool, and finally summarized the answer for you.

What AI Agents Can't Do: Cutting Through the Myths

Now that you’ve seen the “engine,” let’s kill some common myths:

• “Agents think for themselves.” Not really. They are pattern-matching engines with superpowers. They don’t have “desires”; they just follow the loop you set up.

• “Agents are dangerous.” An agent is only as powerful as the tools you give it. If you give it a calculator, it can do math. If you give it your credit card and a login to Amazon... well, that’s on you. You set the boundaries.

• “I need to be a genius to use them.” If you can follow a recipe, you can build an agent. The ecosystem is getting simpler every single day.

AI Agent vs. Claude: When Do You Actually Need One?

If Claude and Gemini can already check the weather, search the web, and run code, why do you need to know how to build your own?

Think of it like the difference between a Smartphone and a Smart Home System.

1. Use the “Built-in” AI (The Smartphone) when:

• You have a one-off question (”What’s the best flight to Tokyo?”).

• You need a quick summary or a brainstorm session.

• You’re using tools manually - you open the app, you take the photo, you send the text.

• The Vibe: “I just need a quick assist while I’m at the controls.”

2. Build a Custom Agent (The Smart Home) when:

• It needs to follow “Your Rules”: A smart home doesn’t just have a lightbulb; it knows to turn that light on only when you walk into the room after 6:00 PM. A custom agent follows your specific business logic.

• It needs to be “Always-On”: You want something running in the background - monitoring your emails, updating a spreadsheet, and pining your Slack - without you having to manually prompt it every ten minutes.

• It needs to connect “Hidden” Data: You want the AI to look at your private project files or your specific customer history, not just the general internet.

• The Vibe: “I want to build a system that works for me while I sleep.”

The Rule of Thumb: If you are the one typing every step and waiting for the answer, a regular AI chat is perfect. The moment you want the AI to orchestrate a process - connecting different apps and making decisions based on your specific “house rules”; that’s when you need a custom agent.

Which part clicked for you? Or which part still feels fuzzy? Drop it below; your question might be the next article!

Leave a comment

PS: If you're new here and wondering why a software engineer is writing about all this - here's why I started Becoming with AI."

TL;DR: The final stage of vibe coding isn't about writing more code; it's about managing the code you already have, owning where it lives, and building systems that work even when you're not watching.

Welcome👋🏻
I’ve decided to start this Vibe Coding series to share my perspective as a software engineer. My goal is to close the gap between the technical and the non-technical, making these concepts accessible to everyone, regardless of their background.

Enjoy the Part 5 of a 5 part series!

Subscribe now

Managing Vibe Debt: Why You Need a Cleanup Sprint Every 3 Features

AI is incredibly good at adding things. It is notoriously bad at keeping things simple.

When you ask an AI to add five different features, it will often write redundant logic, create duplicate variables, or “hallucinate” complex solutions where simple ones would work. In engineering, we call this Technical Debt. In our world, let’s call it Vibe Debt.

If you just keep stacking features, your codebase will become so “noisy” that the AI’s context window will eventually collapse (If you missed how context windows work, go back to Part 3).

The fix is simple: every three features, stop building. Run a Cleanup Sprint instead.

I am not adding new features today. Look at src/components/UserDashboard.tsx. 
It has become too large. Simplify the logic, remove redundant variables, and 
reduce the line count by 20% without changing the functionality. 
Make the code more ‘readable’ for yourself.

A lean codebase is an AI-friendly codebase. This is the habit that separates people who build things that last from people who start over every few months.

Do You Actually Own Your Vibe Coded App?

Here’s a question most vibe coders never ask until it’s too late: where does your app actually live?

Platforms like Lovable are wonderful because they handle this for you. You get a link; something like your-project.lovable.app, and it just works. No setup, no thinking about servers.

But there’s a hidden cost most people don’t see until later.

Lovable is like renting a furnished apartment. You move in instantly, everything works, no setup. But you can’t knock down walls, you pay monthly forever ($25–50/month from day one), and if the landlord raises prices or shuts down; you’re out, and your app goes with them.

GitHub + Vercel is like buying a house. More to set up initially, but you own it. You can renovate it, hire any developer to work on it, sell it, scale it. And crucially; Vercel’s free tier can host a real app with real users for $0 until you’re at a scale where paying makes complete sense.

“But wait; Lovable connects to GitHub. Doesn’t that mean I own my code?”

Good question. And this is where a lot of people get confused.

Yes, Lovable can push your code to GitHub. But most people use this as a backup button, not an actual workflow. They’re still living inside Lovable - generating, previewing, deploying - all through Lovable’s interface. The real question isn’t whether your code is in GitHub. It’s whether you can continue building without Lovable. For most people, the answer is no.

Owning your code and owning your pipeline are two different things.

From Localhost to Live: Deploying Your Vibe Coded App to Vercel

Localhost is just a nickname for your computer. It’s a private “Lab” where you can break things without the world seeing. But because it’s private, you can’t share that link. To make your app “real” on your own terms, you need to understand the jump from your private lab to a public server (like Vercel).

Getting your app from your private lab to a public URL is called deployment. And once real users are depending on your app, you can’t just “vibe” and break things carelessly anymore. You need a system that catches mistakes before they reach your users.

That system is called a CI/CD pipeline; and it’s the last piece of the puzzle.

Subscribe now

CI/CD for Vibe Coders: How GitHub Actions + Vercel Catch Broken AI Code

In Part 2 and Part 4, we talked about Git and Testing. If you didn’t already read them:

Now, it’s time to connect them.

CI/CD stands for Continuous Integration / Continuous Deployment. Ignore the jargon. Here’s what it actually means:

Every time you save a change and push it to GitHub, two things happen automatically:

GitHub Actions (the Security Guard) wakes up and runs all the tests you wrote in Part 4. If the AI accidentally broke your login screen or scrambled the math in your shopping cart, the tests catch it. GitHub Actions puts a big red X on the code and stops everything. It says: “This is broken. I won’t let it go any further.”

Vercel (the Conveyor Belt) is listening. If GitHub Actions gives the green checkmark, meaning everything passed, Vercel automatically grabs the code, builds it into a website, and updates your live URL in seconds. You never manually upload files. You just write, push, and if it’s safe, it’s live.

Using tools like GitHub Actions and Vercel, you are setting up a “No-Fail” rule:

• When you “Commit” your code to GitHub, an automated script runs all the tests you wrote in Part 4.

• If the tests pass: The app deploys to the web automatically.

• If the tests fail: The deployment is blocked.

This matters especially when you’re vibe coding, because AI moves fast and breaks things quietly. A “fix” can look fine and still shatter something else. CI/CD is your automated quality filter. You can move as fast as you want, knowing the machine is watching the machine for you.

This is how you ship with confidence. You no longer have to worry if a late night AI prompt accidentally broke your login screen. The machine is watching the machine for you.

The Mindset Shift: From Vibe Coder to Systems Builder

Five parts ago, vibe coding felt like magic. You were someone who asked AI to build things.

Now you’re someone who builds systems that make AI reliable. You manage Vibe Debt before it manages you. You own your infrastructure instead of renting it. You ship with confidence because you’ve put guardrails in place that work even when you’re not watching.

Which part clicked for you? Or which part still feels fuzzy? Drop it below; your question might be the next article!

Leave a comment

When I started this series, my goal was simple: I didn't want you to feel left out of a conversation that's reshaping the world. Technical people have had a head start, but that gap is closing, and you're proof of it. You now think about code the way engineers do: not just "does it work?" but "will it still work tomorrow, when it's bigger, when it breaks?" That's the mindset. Keep it. And if you ever feel lost again, come back. We'll figure it out together.

FAQ: Your Questions, Answered

What is Vibe Debt?

Vibe Debt is what happens when you keep asking AI to add features without ever stopping to clean up. The code gets messy, the AI gets confused, and eventually your whole project starts breaking in ways that are hard to fix. Think of it like never doing the dishes, it works fine for a while, until suddenly it really doesn’t. The solution is simple: every three features, dedicate one session purely to cleanup, not building.

Is Lovable or GitHub + Vercel better for vibe coding?

It depends on where you are in your journey. Lovable is better when you’re just starting out and you want to move fast without thinking about infrastructure. GitHub + Vercel is better when you’re building something real that needs to survive real users; because you own it, your costs are predictable, and you’re not dependent on one platform’s pricing decisions.

The honest answer: start with Lovable if you need to, but plan your exit early.

Do I need CI/CD as a non-technical founder?

Not on day one. But the moment real users are depending on your app, you need something watching for mistakes; because AI-generated code breaks in quiet, unexpected ways. Github and CI/CD is that safety net. It’s not as complicated to set up as it sounds, and once it’s running, you never have to think about it again. It just works in the background, catching problems before your users do.

What’s the difference between owning my code and owning my pipeline?

Owning your code means your files are saved somewhere you control, like GitHub. Owning your pipeline means you control how that code gets tested and deployed to the internet. Lovable can give you the first without the second; your code is in GitHub, but Lovable is still the one deciding how and when it goes live. True ownership means both. That’s when you’re genuinely independent.

PS: I’ve been refining these 'vibe' workflows over 10 years in engineering. You can find more about my journey and other AI experiments on my About page.

Vibe Rot is a state where an AI-built app appears to work on the surface, but the underlying logic is broken; you see the change, but the database never actually updated.

TL;DR: Before we dive into the 'Test-Driven' mindset, make sure you've built your foundation using the PRD strategy I shared in Part 1: Why Your First Prompt is a Trap.

The biggest danger in vibe coding is “Vibe Rot”; when your app looks functional but the underlying logic is broken under the hood.

Part 4 introduces Test-Driven Vibing (TDV). We’ll cover:

• The “Verification First” mindset,

• Automating Unit & Integration tests, and

• The “Manual Audit” to ensure your vibe matches reality.

Welcome👋🏻
I’ve decided to start this Vibe Coding series to share my perspective as a software engineer. My goal is to close the gap between the technical and the non-technical, making these concepts accessible to everyone, regardless of their background.

Enjoy the Part 4 of a 5 part series!

Subscribe now

What Is Vibe Rot? (And Why Your AI App Is Probably Broken)

There is a specific feeling in vibe coding: You ask the AI to add a “Delete” button. It adds the button. It looks beautiful. You click it, and the item disappears from the screen. Success!

But then you refresh the page, and the item is back.

The AI updated the UI (user interface), but it forgot to update the Database (backend). This is “Vibe Rot.” Because you didn’t write the code yourself, you don’t actually know if it works; you only know that it looks like it works.

To build professional software, you have to move from “I hope this works” to “I have proof this works.”

Unit Tests for Vibe Coding: How to Make the AI Prove It Works

A Unit Test checks one tiny piece of logic in isolation (like a calculator function or a currency formatter). When you’re vibe coding, the AI loves to take shortcuts. Unit tests force it to be honest.

The Practical Workflow: Before you let the AI write a complex function, tell it to write the test first:

I need a function that calculates the discount for my shopping cart. 
Before you write the function, write the unit tests that checks for: 
1) A standard 10% discount, 
2) A case where the cart is empty, and 
3) A case where the discount code is expired. 
Only after the tests are written, write the function code.

Integration Tests: Catching the Bugs Your Unit Tests Miss

While unit tests check the parts, Integration Tests check how those parts work together. This is where most vibe-coded apps fail: the “Delete” button looks fine, but the connection to the database is broken.

The Practical Workflow: Ask the AI to write a “happy path” integration test:

Write an integration test that simulates a user logging in, adding an item to the cart, 
and checking out. Ensure the database updates correctly at the end. If it fails, 
explain why the connection between the Auth and the Database is breaking.

By making the AI run these tests, you aren’t just checking code; you’re checking the whole system.

The Manual Audit: Your Personal QA Checklist for Vibe-Coded Apps

Even with 100% test coverage, AI can still “hallucinate” success. You must be your own QA lead.

The “Skeptic’s Rule”: Every time you add a feature, try to break it in three ways:

1. The “Refresh” Test: Do the changes persist after a page reload?

2. The “Empty State” Test: What happens if there is no data to show?

3. The “Bad Input” Test: What happens if you type letters into a number field or leave a required field blank?

Practical Tip: Once a week, do a “Clean Run.” Open your website in an Incognito window and go through your entire user flow from scratch. You will be surprised at how many “vibes” only work because of old data sitting in your browser cache.

Subscribe now

Breaking the AI Loop of Doom: When Your Chatbot Keeps Failing

We’ve all been there. The AI makes a mistake. You tell it to fix it. It tries, but it fails again. Three prompts later, it’s suggesting the exact same “fix” it tried at the beginning.

This happens because the AI is stuck in a loop of its own previous context:

How to break it:

1. The Git Reset: Revert to your last working commit:

2. The “Explain the Error” Prompt: Instead of asking for a fix, ask for an analysis:

   Stop trying to fix the code. Explain to me in plain English exactly WHY this error 
   is happening. What is the conflict between File A and File B?

3. Be Precise: Once the AI explains the logic error, then give it the instruction to fix just that specific piece.

You're the Lead Auditor: Why Human Oversight Still Matters in Vibe Coding

We call this “test driven vibing” but in reality, it is Quality Assurance. The AI is the builder; you are the building inspector. If you don’t check the plumbing before you close the walls, you’re going to have a leak later.

By using TDV, you’re not just building faster; you’re building permanently. You’re ensuring that the “vibe” isn’t just a surface-level feeling, but a structural reality.

The Pause and Pivot: You are building the evidence you need to eventually launch your project to real users without fear.

See you in Part 5!

PS: I’ve been refining these 'vibe' workflows over 10 years in engineering. You can find more about my journey and other AI experiments on m About page.

TL;DR: Before we dive into Context Management, make sure you've already set your Part 1: PRD Strategy and your Part 2: Git Safety Net. Without those, your context will collapse into chaos anyway.

As your project grows, the AI starts to get "foggy." It forgets your database schema, hallucinates variables, and begins breaking its own code. To stop this Context Collapse, you need to move from a "giant ball of clay" to "LEGO bricks." In Part 3, we cover:

• Modularization to keep files clean,

• Global Project Rules for consistency, and

• Minimum Cost Vibe Coding by rotating between AI agents and different models to build professional systems without burning your budget.

Welcome👋🏻
I’ve decided to start this Vibe Coding series to share my perspective as a software engineer. My goal is to close the gap between the technical and the non-technical, making these concepts accessible to everyone, regardless of their background.

Enjoy the Part 3 of a 5 part series!

Subscribe now

In the beginning, vibe coding is pure magic. You ask for a feature, and it appears. But around the 30th file, something shifts.

The AI starts suggesting “fixes” that undo the work you did yesterday. It uses an old database schema you specifically told it to abandon. It starts introducing bugs in parts of the app you haven’t touched in hours.

No, you are not failing, and no, AI’s intelligence is also not failing.

It’s a failure of Context Management.

In engineering, we know that the more “state” a system has, the harder it is to reason about. In vibe coding, the “Context Window” is the AI’s current field of vision. If you fill that vision with noise, the AI loses the signal.

To move from “weekend toy” to “real product,” you have to stop dumping everything into the chat and start curating the vibe.

What Is Context Collapse in Vibe Coding?

The LLM (Large Language Model) doesn’t “know” your project the way a human does. It reads a slice of it every time you send a prompt.

When your project gets too big, two things happen:

1. The Middle is Lost: LLMs are great at remembering the beginning and end of a prompt, but they get “foggy” in the middle.

2. Noise Overload: If you have 50 files and 10 of them are outdated prototypes, the AI might grab code from the wrong file to solve a new problem.

The Solution: You must treat your codebase like a set of LEGO bricks, not a giant ball of clay.

Or, in software engineering, we call it “monolith”, but you really need to make it modular, which brings us to our next topic.

Modular Code: Keep Files Under 200 Lines

A “No-BS” rule for vibe coding: If a file is more than 200 lines long, it’s a liability.

When the AI generates a “monolith”, it becomes impossible for the AI to “read” the whole thing without hitting its limit.

The Pivot: Break your code into small, single-purpose files.

• Auth.tsx should only handle login.

• PricingCard.tsx should only handle the visual card.

• database.ts should only handle the connection.

Practical Tip: If you see the AI writing a massive file, stop it. Say:

Break this feature into modular components. Create separate files for the logic and the UI.

Small files are easier for the AI to ingest, understand, and fix without side effects.

Project Rules: Your AI's Configuration File

Whether you are using Claude Code or Cursor, you need a way to enforce “Constitutional Law” for your project. Instead of telling the AI “use Tailwind CSS” in every single prompt, you write it once in a configuration file.

When I use Claude Code, I add the rules in Claude.md file. You can also tell Claude to not add API Keys to codebase in Claude.md file, but there are more robust ways to protect them, you can check it out my other article about safe vibe coding.

What to enforce:

• Tech Stack: “Always use Next.js with TypeScript.”

• Coding Style: “Prefer functional components. No classes.”

• Project Structure: “Always put API routes in the /api folder.”

By setting these global rules, you “pre-load” the AI with the correct context before you even type a word. It keeps the “vibe” consistent across every file it generates.

Curate AI Context with Claude Code Prompts

The biggest mistake vibe coders make is letting the AI “read everything” for every single small change. If you’re fixing a typo on the Landing Page, the AI doesn’t need to see your Stripe integration logic.

If you are using Claude Code, you have surgical control over what the AI sees.

How to Curate:

• Be Specific in Your Command: Instead of saying “fix the landing page”, which might cause the agent to wander through your entire directory, use:

  Refactor the header in src/components/LandingPage.tsx. Do not look at other files unless necessary.

• The “ReadOnly” Guardrail: If you want Claude to use a specific file as a reference but not change it, tell it explicitly. This prevents the AI from “hallucinating” improvements on code that is already working perfectly.

• The Context Reset: Conversations in Claude Code can get bloated with terminal outputs and previous failed attempts. If you’ve spent 20 minutes stuck on one bug, exit and restart the session. This wipes the “fog” of previous errors and lets the AI look at the current state of the files with fresh eyes.

Subscribe now

Cost-Effective Vibe Coding: The Model Rotation Strategy

Vibe coding can be really expensive. If you treat every bug fix like a high-stakes architectural decision, you will burn money quite fast.

To stay sustainable, you need to match the tool’s “IQ” to the task’s complexity.

The “Free” Giant: Google Antigravity

As of early 2026, Google Antigravity is the ultimate hack for cost-effective vibing. Because it’s in Public Preview, Google is offering it for free with incredibly generous rate limits.

• The Vibe: It’s an “agent-first” platform. Instead of just autocompleting lines, it spawns agents to handle the “dirty work”: testing, browsing, and multi-file refactoring without you paying for every token.

• When to use it: Use it for the heavy lifting that would normally drain your Claude or OpenAI credits. It’s perfect for the “middle phase” of a project where you need a lot of autonomous execution.

I have recently started to use Google Antigravity, I find it quite good on UI-related works, rather than backend.

The Claude “Token Arbitrage” Tier List

When you aren’t using Antigravity, or if you prefer the “surgical” reasoning of Claude, use this rotation to save money:

The No-BS Bottom Line:

If you’re on a budget, your workflow should look like this:

1. Plan with Claude Opus (The Architect).

2. Execute the bulk work in Google Antigravity (The Free Workforce).

3. Refine or fix small bugs with Claude Haiku or Gemini Flash.

By rotating your tools, you move from “spending money to code” to orchestrating resources to build.

PS: If you want to understand more about how AI tokens work, you can read They say AI is for Everyone. But It Thinks in English.

The Human Element: You are the Information Architect

We call this “vibe coding,” but really, it is Information Orchestration. The AI is a Ferrari, but context is the road. If the road is full of potholes (messy files) and dead ends (outdated code), the Ferrari can’t go fast.

Your job isn’t just to “prompt”; your job is to clean the workspace. By keeping files small, rules clear, and context focused, you ensure the AI is always operating at its highest “IQ.”

But managing context is only half the battle. To prevent your app from decaying into Vibe Rot, you must adopt the practices I’ve outlined in Part 4: Test-Driven Vibing (TDV). This is where we bridge the gap between 'vibing' and real engineering.

TL;DR: As we discussed in Part 1: Why Your First Prompt is a Trap, the goal is to build fast without losing control.

In vibe coding, one bad AI prompt can destroy your entire project. Here's how Git - your ultimate undo button - becomes your safety net. Also, I’ll show you how you can protect your API Keys.

Welcome👋🏻
I’ve decided to start this Vibe Coding series to share my perspective as a software engineer. My goal is to close the gap between the technical and the non-technical, making these concepts accessible to everyone, regardless of their background.

Enjoy the Part 2 of a 5 part series!

Subscribe now

In the early hours of a vibe coding project, there is a specific kind of silence that occurs right after you realize you’ve broken everything.

You were in the “flow state.” You asked the AI to add a simple payment button, and instead, it refactored your entire authentication logic, deleted three files you didn’t know were important, and left you staring at a blank white screen filled with console errors.

This is the moment most people give up. They feel they’ve lost their “save game.” They try to ask the AI to “undo,” but the AI is like an overconfident junior developer with amnesia: it doesn’t remember what the codebase looked like five minutes ago.

To bridge the gap between “fragile experimentation” and “confident building,” you need a Safety Net. In engineering, we call this Git. For you, let’s call it the Ultimate Undo Button.

Why Vibe Coders Lose Their Work (The Point of No Return)

Most vibe coders treat their project like a single document. If you make a mistake, you hit Cmd+Z, but that only reverts the text in your active window—not the structural changes the AI made across ten different files simultaneously.

Without a safety net, you are always one prompt away from a total system collapse. The gap is moving from linear progress (where every step could be fatal) to checkpointed progress (where you can always jump back in time).

How to Use Git Snapshots to Save Your Vibe Coding Progress

You don’t need to be a command-line wizard to use Git. In 2026, tools like Cursor or GitHub Desktop make version control as easy as a “Save” icon.

Step-by-Step: Git for Non-Technical Vibe Coders

1. The “Before” Snapshot: Before you give the AI a high-risk prompt—like “Refactor my database”, you need to commit your changes. If you are using Cursor, check out this Git Guide.

2. The “Vibe” Phase: Let the AI run wild. If it works, great! Create another commit: “Payment button works.”

3. The Great Undo: If the AI breaks the app, stop prompting. Do not try to fix the error with more instructions. You need to revert to your last commit. There are several ways to do it, depending on which tools you are using.

My advice as a dev:

Sometimes, it might be a pain in the a** to rollback some changes, and Cursor or whatever vibe coding tool you are using, may not help as you want.

I suggest you to always take control of your Git: either with Terminal by using Git commands (that’s what I prefer), or with a Git Visualizer Tool like Github Desktop or GitKraken. If you are not really familiar with coding, I suggest you to use a Git Visualizer Tool: you can create your branches easily, commit and push your changes or revert your committed changes when needed.

Subscribe now

How to Protect Your API Keys with .gitignore

As you build, you will eventually use “Secrets.” These are API keys for things like Supabase, OpenAI, or Stripe, etc. If you are using AI, these keys are the “digital cash” that powers your app.

The Golden Rule: Never, ever commit secrets to your code. Ever.

When you commit your code to a platform like GitHub, it is often visible to the world. If you commit your API keys, bots will find them in seconds and drain your account.

Remember what happened to a student who pushed that API Key to GitHub?

To prevent this, we use a file called .gitignore.

The Pause and Pivot: We call this a “config file,” but really, it is a Privacy Filter. It tells Git: “Watch these files, but don’t share them (ignore them).”

How to stay safe:

• The .env file: Put all your secrets in a file named .env.

• The .gitignore: Ensure your project has a file named .gitignore. Inside that file, the very first line should be .env.

• The Result: Git will now “ignore” your secrets. Even if you commit your code, your keys will stay safe.

Vibe Coding Git Best Practices (The Intentional Builder's Checklist)

1. Atomic Commits: Save every time a single thing works. If the button turns blue: commit. If the math is right: commit. Small saves are easier to revert than giant ones.

2. The “Revert First” Mentality: If a prompt fails, don’t ask the AI to “fix it.” Revert the change to your last working state, refine your prompt, and try again from a clean slate.

3. No Secrets in History: Once a secret is committed to Git history, it is there forever, even if you delete the file in a later version. If you accidentally commit a key, you must rotate it (delete the old key and get a new one) immediately.

4. Descriptive Labels: Avoid labels like “fix” or “stuff.” Use “Added local storage for expenses.” This makes your “Time Machine” a.k.a commit history searchable.

Why Git Gives Vibe Coders Psychological Safety

By implementing Git and a proper .gitignore, you are creating Psychological Safety. When you know you cannot “nuke” your project or expose your bank account, you become more courageous. You move from a state of friction to a state of flow.

It requires structure, a little discipline, and restraint.

The Pause and Pivot: We call this “version control,” but really, it is Temporal Insurance. It is the technical guarantee that your past success is protected from your future mistakes.

The Human Element: Why You're the Curator, Not the AI

The AI provides the computational labor, but you provide the “Save Points.” By deciding when a version is stable enough to keep and what information is too sensitive to share, you are exercising Judgment. You aren’t just a user; you are a curator of working states.

With this foundation, you can safely start vibe coding. You have a solid toolset, and a way to undo mistakes before they become disasters.

Technical skills can be learned, but intentionality is a choice. By setting up these guardrails, you’ve already done the hardest part of engineering.

Git protects your files, but as your project grows, you'll hit 'Context Collapse.' Check out Part 3: Context Management & Cost-Saving Tips (2026 Guide) to learn how to keep your AI smart as the codebase expands.

TL;DR: This is Part 1 of the No-BS Vibe Coding Series. After you've set your strategy here, move to Part 2: Safety with Git, Part 3: Context Management, and Part 4: Test-Driven Vibing

Before you start vibe coding, you need three things:

• A tech stack decision,

• The right AI tool for the job,

• A PRD document.

Skip these, and you’re building on sand.

Welcome👋🏻
I’ve decided to start this Vibe Coding series to share my perspective as a software engineer. My goal is to close the gap between the technical and the non-technical, making these concepts accessible to everyone, regardless of their background.

Enjoy the Part 1 of a 5 part series!

You're ready to try vibe coding for the first time. Coffee's hot, you open your favorite AI coding tool—Claude, Cursor, maybe Lovable—and type a single hopeful sentence:

Build me a personal finance tracker app.

In a few minutes—and in exchange for a few thousand tokens—an app appears. It feels like magic. It feels like pure speed. But in reality, it is a trap.

At that moment, you have just handed over 100% of the architectural decisions—the language, the database, and the underlying logic—to an AI that doesn’t know if you’re building a weekend hobby, a gift for a friend, or the foundation of a future startup.

To bridge the gap between your intent and the AI’s capability, you must start not with a prompt, but with Analysis.

In my day job as a developer, we don’t just start typing. Before a single line of code is written, we spend hours, sometimes days, on System Design. We draw diagrams, we argue over data flow, and we weigh every trade-off.

In “Vibe Coding,” we tend to skip this because the AI is so fast that we mistake its speed for intelligence. But without a plan, the AI defaults to whatever is easiest for it to write in the moment, not what is easiest for you to maintain in the long run.

If you don’t choose the structure, the AI will choose it for you. Often, it will build a “monolith”—a single, giant block of code that is nearly impossible to change without breaking everything else. It works for the first five minutes, but it collapses the moment your project grows beyond 30 files.

Before you write a single line of code, you must design the system.

Subscribe now

1- How to Choose Your Tech Stack for Vibe Coding

What is a Tech Stack?

You don’t need to be a senior engineer, but you do need to know which “flavor” of technology you want to inhabit. We call this a Tech Stack, but really, it is just the environment where your idea lives.

As a backend developer, my specialty is designing scalable systems that don’t break under heavy traffic. However, a full app needs more than just a “brain” (the backend); it needs a body and a face.

Recommended Stacks for Web Apps vs Mobile Apps

If I were building a web app today, I’d use Next.js + Vercel to ship it in 48 hours. If you want a mobile app, you might look at Flutter to target iOS and Android at once. The point isn’t to learn the code—it’s to pick the path so the AI knows what it is doing.

Prompt Template: Get Your Custom Tech Stack Recommendation

If you are not sure where to start, copy and paste this into your favorite LLM (Claude, GPT-4, etc.) to get your custom recommendation:

I have an idea for an app, but I need to choose the right tech stack to ‘vibe’ with my goals. I am a [Beginner / Intermediate / Expert] at coding.

My App Idea: [Describe your idea here—e.g., ‘A personal finance tracker’]

My Priorities (Rank these 1-3):
Speed of shipping (I want it live in 48 hours).
Scalability (I expect 5,000 users soon).
Visual Polish (It needs to look high-end and custom).

The Goal: Please recommend a modern tech stack that fits this ‘vibe.’ Explain why these tools work together, which hosting provider I should use (like Vercel or Supabase), and provide a ‘Day 1’ checklist to get the environment set up.

2- Claude Code vs Cursor vs Lovable: Which AI Coding Tool Should You Use?

Not all AI tools are built for the same job. You need to match the tool to the specific task. You wouldn’t use a sledgehammer to hang a picture frame.

• Claude Code (Terminal/Agentic): This is the “Deep Thinker.” It is agentic, meaning it can perform multiple steps on its own. It’s best for complex logic and structural changes where the AI needs to “think” across your whole project.

• Cursor (The IDE): This is your “Daily Driver.” It’s a visual editor that lets you see the code as it changes in real-time. It’s best for the user interface (UI), styling, and adding features quickly.

• v0 / Lovable: These are the “Sketchpads.” These tools are where you prototype your ideas at light speed. Use them to generate the look and feel—the visual vibe—before you move the code into its permanent home.

Personally, I lean toward Claude Code because I like being hands-on. If you’re a complete beginner, I’d recommend starting with Cursor. It provides the most visual clarity as you build.

3- What is a PRD? Writing Your Product Requirements Document

Before you open your editor, you need to draft a Product Requirements Document (PRD). This isn’t just paperwork; it is the physical manifestation of what your app needs to do.

If we are building that personal finance tracker app, your PRD should look like this:

Project: Personal Finance Tracker App

The Core Verb: Users capture daily expenses and visualize monthly trends.

The User Flow:

1. User opens app (defaults to “Quick Add”).

2. User enters amount and category.

3. User views a simple “Remaining Balance” donut chart.

Technical Constraints:

• Mobile First: Optimized for mobile screens.

• Offline Capable: The app must allow entries even without Wi-Fi.

• Zero Friction: No login screen for the MVP (Minimum Viable Product). Use LocalStorage.

The “No-Go” List:

• No bank integrations (manual entry only).

• No complex investment tracking.

• No social sharing features.

Honestly, this is just an example. Your actual PRD document would probably more comprehensive than this. I wanted to keep it simple for this article.

I suggest you to use ChatGPT’s Deep Research mode or Claude’s Opus 4.5 to create a comprehensive Product Requirements Document. After you create this document, add it to your project’s folder. AI will analyze it and implement the features based on this PRD document.

Why Planning Before Prompting Prevents Technical Debt

By defining the Stack, the Tool, and the PRD, you are building a Context Container. You are setting the technical constraints the AI needs to avoid spaghetti code and circular dependencies. By narrowing the scope, you prevent the model from guessing—which is where 90% of technical debt begins.

It requires data, logic, and constraint.

We call this “vibe coding,” but really, it is Requirement Engineering. The AI functions as your execution engine; you function as the logic provider. If the system architecture is flawed, we don’t blame the generator—we audit the specification.

The Human Element: Why AI Can't Replace Your Judgment

Choosing your tools and constraints is the highest-leverage part of the build. The AI can generate 1,000 lines of code in seconds, but it cannot define the business logic or the system requirements.

Your judgment in these first ten minutes determines whether your project becomes a production-ready application or a pile of unmaintainable technical debt. You aren’t just “vibing” with a machine; you are Engineering with Intent. The AI provides the computational labor, but your specification provides the system logic.

It requires a stack, a spec, and discipline.

The groundwork is now laid. You have a stack, a set of tools, and a clear requirement document. You’ve successfully moved from "hoping the AI understands" to "ensuring the AI follows."

Now that you have your PRD and tech stack, don't start prompting yet. You need a safety net. Read Part 2: How to Undo AI Mistakes Safely with Git to ensure one bad prompt doesn't ruin your project

We are currently living through a storm of noise.

Open any tech newsletter or social feed, and you are bombarded with hyperbole. We are told that AI is either “saving the world” or “destroying it”. We are promised tools that will “10x our productivity” overnight.

But if you are like me, sitting at the intersection of engineering and creative work, you don’t feel “10x’d.” You feel overwhelmed.

This brings me to the rebrand.

Previously, I wrote under the name The Cognitive Stack.

That publication was a necessary space for deep thinking, an exploration of how human and machine intelligence layer together. But I realized that while the ideas were sound, they were often too abstract.

We don’t just need to understand the “stack.” We need to get our work done.

That is why I am renaming this newsletter “Becoming with AI.”

My mission is to turn that technical noise into something practical.

I want to move away from the high-level theory and offer you strategies you can actually use on a Tuesday morning. I want to help you bridge the gap between human intent and AI capability.

Subscribe now

The Mirror, Not the Magic Wand

We often treat AI like a magic wand - we wave it at a problem and hope for a solution. But I have found that AI is actually a mirror:

It reflects our input with brutal accuracy.

• If our thinking is messy, the output is messy.

• If our intent is vague, the result is generic.

• If we lack clarity, the machine cannot give it to us.

“Becoming with AI” is about learning to stand in front of that mirror.

Yes, we will discuss prompts. But we will also build workflows, design products, and forge tools.

Whether we are writing code or natural language, the core skill is the same: clear communication. It requires logic, syntax, and empathy.

A Gift: Buying Back Your Time

To do this practical work, to actually think clearly, we need space. And right now, most of us don’t have it. We are drowning in what I call the “Grind Zone”: low-value, high-energy tasks that eat away at our day .

We cannot become better engineers, writers, or creators if we are burnt out.

So, to mark this new chapter, I am releasing a resource I originally built to help myself to find stillness in the storm.

It is called Automate the Boring: The Anti-Burnout Guide.

It is not a technical manual for building complex systems. It is a guide to spotting your “Energy Leaks” and handing the robotic work over to the robots, so you can get your brain back.

I’m sharing this $19 guide for free. If it helps you reclaim even one hour of your week, it means it did its job.

Download the FREE Guide

What Comes Next?

Going forward, this newsletter will move at a measured pace. I value depth over speed.

But a bridge cannot be built from only one side.

I don’t want to guess what you need. I want to build this roadmap based on where you are actually getting stuck.

So, help me shape the next few issues.

Leave a comment below, or send me a DM:

1. Are you struggling with the technical tools (the code, the agents)?

2. Are you struggling with the workflow (how to fit it into your day)?

3. Or is it something else?

I read every response. Your friction points will determine what we build next.

AI is not here to replace us. It is a tool we must learn to wield.

Thank you for being here for the pivot.

Let’s build something that matters.

PS: If you want to learn more about me, please visit my About page.

Recently, I came across an app that helps non-English speakers build apps in minutes.
When I looked at their About section, one sentence stood out:

“We want to democratize app creation for people who don’t speak English.”

I genuinely liked that mission.
But it also made me think.

Because if that’s the goal, then, what exactly is broken in the current system, and what does “democratizing AI” actually mean?

How AI Tokenization Actually Works

Before we talk about fairness, access, or democratization, we need to talk about something much more basic: how large language models process text at all.

If you’ve ever worked with LLMs before, you probably know this:

AI doesn’t understand words.
It doesn’t understand characters.

It understands tokens.

And almost everything — pricing, limits, latency — is based on them.

Tokenizers break text into pieces that models can work with and tokenizers are not neutral.

Why English Is the Cheapest Language for AI

English has a “superpower”: it expresses meaning using very few tokens.

To make this concrete, I took the same content and wrote it in three languages that I am most familiar with:

• English

• Dutch

• Turkish

Then I ran them through the same tokenizer (https://platform.openai.com/tokenizer) .

Here’s what came out:

Same idea, same intent, same information. Very different token counts.

The result is actually not random:

• Dutch uses a lot of compound words, which tokenizers often split apart.

• Turkish is an agglutinative language, where meaning is built by stacking suffixes, and each stack adds more tokens.

• English, on the other hand, gets a smooth ride.

  Subscribe now

This Isn't a Bug. It's How Tokenizers Are Designed

It’s easy to call this unfair or broken. But technically speaking, nothing is “wrong“.

English dominates high-quality training data.
So tokenizers are optimized for English frequency patterns.

That means:

• common English words → single tokens

• common English suffixes → single tokens

• common English constructions → efficiently compressed

As a result:

English expresses meaning with fewer tokens than almost any other natural language.

The system is doing exactly what it was designed to do.

That means, English is the cheapest language to think in.

The Hidden Language Tax in AI Pricing

Most AI pricing today is token-based, directly or indirectly.

Which means non-English users hit limits faster, burn their credits sooner, or become “expensive” users without realizing why.

And none of this is visible at the UI level.

From the outside, everything looks inclusive.
From the inside, the system is quietly optimized around one language.

English dominates AI not only because of data, but because most large AI systems are built in the United States, where English is the default language for research, infrastructure, and early users.

That default shapes what gets optimized and what becomes expensive. Other languages work, but they are not the center of the system.

This is why it matters for other countries (especially non-English speaking ones) to build their own LLMs: not to replace global models, but to ensure their languages, costs, and ways of thinking are first-class citizens rather than afterthoughts.

If AI systems:

• think most cheaply in English

• price based on tokens

• and scale globally

Then we have to ask:

Who is actually paying the language tax?

Is it the user?
The company?
Or the people who never get to build at all?

Because real democratization will start when we design systems that don’t punish people for the language they think in.

And right now, we’re not quite there.

Many people’s first interaction with AI looks like this.
They open the chat, type something broad like “Help me think about my next article”: skim the response, and feel a quiet sense of dissatisfaction.

The output is fluent. Technically fine.
But nothing really moves.

I’ve had that reaction myself. Not because the AI failed, but because I hadn’t decided what I actually needed from it. The conclusion is usually the same: this is impressive, but not for me.

Subscribe now

Over time, I’ve noticed that clarity matters more than capability when it comes to using AI. To ask well, you first have to decide what kind of help you’re looking for: exploration or evaluation, support or resistance, speed or depth. That decision requires a certain kind of self-awareness, the ability to name:

• where you are

• and what you’re trying to reach

When people struggle to get value from AI, it’s rarely a tooling issue. It’s a hesitation to commit to a point of view. The sharper the intent, the more useful the response becomes. In that sense, AI doesn’t just help you think. It quietly reflects how much responsibility you’re willing to take for your own thinking.

I’ve found it helpful to distinguish between using AI as a tool and using it as a thinking partner.

When it’s treated as a tool, the interaction stays transactional. You ask, it answers, you move on.

When it’s treated as a thinking partner, something different happens. The exchange slows down. The responses push back a little. Weak framing becomes visible. Sometimes the reply isn’t helpful in itself, but it shows me what I was really trying to say, or what I was avoiding.

A thinking partner isn’t there to replace judgment. It engages with it. It surfaces assumptions, questions framing, and reflects reasoning back with less emotional attachment.

Used this way, AI becomes a kind of cognitive mirror. It doesn’t just respond to inputs; it reveals patterns in how you think. For leaders, writers, and people who build things, that distinction matters.

Tools optimize execution, thinking partners improve decision quality

Once that shift happens, the question changes. It’s no longer “What should I ask?” but “How do I invite better thinking?” and that’s where prompts start to matter.

A weak prompt sounds like this:

Help me write an article about AI and leadership.

It asks the AI to decide the angle, the depth, the audience, and the point of view, all things the writer should probably sit with first. The result is often polished and inoffensive, and easy to forget.

A stronger prompt takes responsibility before asking for help:

I’m writing for leaders who feel overwhelmed by AI hype. I believe AI is most useful as a thinking partner, not a productivity shortcut. Challenge this idea. Tell me where it’s naive. Help me sharpen it without softening it.

The difference isn’t the wording. It’s the posture.

One prompt hands thinking away.
The other invites collaboration.

Using AI this way also changes how it feels to create. The shift is subtle but important: from performing to exploring. When writing or making decisions in public-facing contexts, there’s often pressure to sound confident, decisive, and finished. That pressure leaks into how AI gets used. We ask for answers when what we really need is space.

Exploration asks for a different posture. It makes room for half-formed thoughts, contradictions, and early drafts that aren’t meant to impress anyone. AI lowers the cost of being unfinished, which makes it easier to stay with a question a little longer.

There’s something deeper underneath this that I don’t see talked about very often. When people create; write, decide, build, they’re not just assembling information. They’re bringing their values, experiences, doubts, and personal stakes into the work. That inner participation is what gives creation its weight.

You can call it judgment. Or intuition. Or, maybe even, soul.

Whatever you call it, it’s the part of thinking that can’t be automated. It’s what allows someone to stand behind an idea rather than simply present it. When AI is used to bypass that part, the output may still look fine, but it often feels strangely empty. Not wrong. Just… Ownerless.

When leaders and writers stop using AI to polish outcomes and start using it to explore ideas, the interaction becomes safer and more honest. In that space, clarity doesn’t come from sounding right. It comes from staying with a question long enough to understand it.

If AI reflects how you think, then the real question isn’t how good the tool is.
It’s how willing you are to stay present with unfinished thoughts.

The next time you open the chat, notice what you’re asking it to do:
think for you, or think with you.

I sat there confused. Communication skills? I’d just proposed implementing proper observability. I’d suggested refactoring that would make our codebase cleaner. I’d offered to improve our logging.

I was being a good engineer.

Wait.. What?

Subscribe now

I came to the Netherlands with 5.5 years in Turkish tech. I knew how to build systems. I understood the why behind patterns, not just the how. I once wrote a whole article about implementing the State Machine pattern from scratch, not because someone asked me to, but because that’s what serious engineers do. We go deep.

In Turkish tech culture, engineering excellence isn’t a goal. It’s the goal.

You don’t ship half-ass solutions. You don’t compromise on code quality. At one company, we had two-day planning sessions. Two full days. Database schema. API contracts. Error handling strategies. Deployment approach. Everything mapped out before writing a single line of code.

And you know what? Even after two days, there were still things unclear during implementation. Because you can’t plan away all uncertainty.

But we tried. Because that’s what good engineers do.

This system creates something real: engineers who understand tradeoffs, who can explain why they chose one pattern over another, who care about craft. I’m proud I learned to think this way.

But here’s what nobody told me: I had confused engineering excellence with business value.

I didn’t see it until the Netherlands showed me.

When I proposed observability improvements to my Dutch team, they asked: “What problem are we solving?”

When I wanted to refactor for cleaner abstractions, they asked: “Is this blocking us from delivering?”

I thought they were being short-sighted. Careless about quality.

They weren’t.

They were asking a question I’d never learned to ask: Why does this matter right now?

Dutch tech culture cares about quality. But they filter everything through a different lens:

Business impact over technical elegance. Fast user feedback over perfect first version. “Does it fit the requirements?” over “Is it flawless?”

The planning sessions here? High-level system design. How it connects to requirements. Implementation details? Up to the developer.

That’s it. No two-day deep dive.

At first, this felt sloppy. Underprepared. How can you make good decisions without thinking through every detail?

But it’s not sloppiness. It’s a different bet on where uncertainty lives.

The Dutch approach says: we can’t plan away uncertainty, so let’s not pretend we can. Design the structure, trust engineers to solve problems as they emerge.

The Turkish approach says: we can minimize uncertainty through thorough planning. Think through everything upfront.

Same fundamental truth. Different timing on where to place your bets.

There’s something else I noticed that goes beyond philosophy. It’s structural.

Subscribe now

In the Netherlands, when I proposed a feature, the first question wasn’t “Is the architecture clean?” It was “How does this handle user data deletion requests?”

GDPR isn’t a nice-to-have here. It’s foundational. You design with compliance from day one. Privacy by design isn’t a buzzword, it’s baked into every technical decision because the regulatory environment requires it.

In Turkey, we were less rigorous about this. Not because we were careless or didn’t care about users. The regulatory environment was different. Less enforced. Less immediate.

This reshapes how engineers think about architecture from the start. When Dutch engineers ask “does this meet requirements?”, those requirements include regulatory compliance in a way Turkish requirements often didn’t.

It’s not that one culture cares more about doing the right thing. The definition of “right thing” is shaped by different constraints.

So that feedback about communication skills. I think I finally get it.

I was walking into meetings with solutions. Technical solutions. “Here’s what we should do because it’s technically better.”

But I wasn’t asking what mattered in that business context:

What problem are we actually trying to solve? What’s the business impact? What do we need to learn? Is this even the right problem to solve right now?

I was performing “good Turkish engineer”: deeply technical, focused on excellence, ready to build the right thing.

The context needed “good Dutch pragmatist”: business-aware, outcome-focused, willing to ship imperfect solutions to learn faster.

Neither was wrong. I was just in the wrong mode.

And nobody told me directly because... how do you explain to someone that their entire framework for what “good engineering” means is contextual?

I’m 10 years into my career now. Almost exactly split between these two cultures.

And I can’t fully be either anymore.

But I know this now: the real skill isn’t mastering one approach. It’s learning how to be adaptable. Recognizing which context you’re in. Seeing tradeoffs both sides make, even when they can’t see them themselves.

Being caught between two worlds is uncomfortable.

But at least now I can see the blind spot.

What’s your experience working across different tech cultures? I’d love to hear if you’ve noticed similar patterns or completely different ones.

I was listening to Tristan Harris on the Diary of a CEO podcast yesterday, and it sparked my curiosity about the AI race. He was talking about how companies are racing to build uncontrollable AI and what kind of future is ahead of us. I see that people are divided into two sides when it comes to the AI debate: those who see salvation and those who see extinction. Companies are investing a huge amount of money into AI to get ahead in this AI race, saying “if we don’t do it, they will” to rationalize their actions.

But what is this race all about? Finding solutions to every human problem, like curing cancer or making the world a better place? Or destroying the world by creating the most intelligent thing ever and not being able to control it at all? People are either on one side or the other. The answer, though, is not so simple.

When GPT-3 came out, it blew everybody’s mind about what AI could do. It helped with coding bugs, created fantastic reports for companies, and helped with school presentations. That was all great, but it didn’t show AI’s real potential, did it? Companies and governments started to discover that AI could do more than just help you write a 1000 word blog post. It can help detect cancer cells in mammogram results, help surveil citizens, or even kill people by targeting them automatically. It’s all so powerful, yet we’re not at AI’s full potential today.

The most important breakthrough hasn’t happened yet (Harris also mentioned this in the podcast): Recursive Self-Improvement. Imagine AI being aware of itself, recognizing its own weaknesses to complete a task at hand, and improving on those weaknesses. After this happens, which some experts expect that it could happen within 2 to 10 years, the world will change dramatically. Big companies leading the AI race, especially in the USA, believe this change is inevitable. On the other hand, critics say these AI labs should be regulated and companies should make sure AI is safe and won’t harm people. There’s an existential crisis for humanity in the shadow of AI.

Here, I raise two questions: Why would AI likely be more harmful than good? And is “controlling AI” even the real problem?

Subscribe now

Let’s look at the first question: If people are creating AI, why would it become potentially bad? Does that mean people are bad?

This question reminded me of the Sufi perspective on the creation of the world. They use a “mirror metaphor” to explain that creation is like a reflection of God. It appears inverted or reversed, which is why what is perfect and purely good in God can appear as imperfect or containing evil in the created world. I think what humans are trying to create with AI is similar to this analogy, with one key difference: God is perceived as perfect, but humans are not. We contain the capacity for both deep love and unspeakable cruelty.

Now we’re creating AI, a reflection of a reflection. Think about it: we’re creating something in our image, and we get to choose what to reflect. We can code in our problem solving abilities and our logic. But can we code in empathy? Grief? The ability to know that some things matter even when they don’t make logical sense?

The question isn’t whether AI will be “good” or “bad” but rather, what aspects of humanity are we coding into it, and what are we leaving out?

Now for the second question: Is “controlling AI” even the real problem? Let’s step back and think: why do we want to control AI? Because it can be harmful. But harmful to whom? Humans, right?

In the world we live in, we, humans, are the smartest of all creatures, at least until AI becomes self-aware and improves itself on its own. Then there are animals, which we sometimes use as a food source, make into shoes and coats, or love and adopt. We’re able to do that because we’re smarter than them. So what happens when something even smarter than us comes along? Do we become the “animals” of this world? Why would the world need humans anyway? I think this question is deeply shaking our most fundamental instinct: to be alive. No matter what, we want to live and we want to exist. That’s why some people see AI as an existential threat to humanity.

Humans may not be the smartest in the world anymore, but we have emotions, consciousness, and ethics that AI, we believe, can only mimic. I’m living in Amsterdam where the housing is a huge problem. I recently visited a cemetery with my boyfriend to see the graves of his grandparents and great-grandparents. If AI ran the city of Amsterdam, what would stop it from building houses on cemeteries and just burning all the dead bodies? From a pure logical perspective, this could make sense on paper while completely missing what makes Amsterdam Amsterdam: the layers of memory, grief, tradition, and meaning that can’t be quantified.

So where does this leave us?

This is the hardest part of the whole article. And honestly, I am not sure.

I believe in the world we’re living in, we need to hold onto our “human side” even more. Critical thinking and decision-making are more important than solving mathematical problems or knowing how to write an if statement in Python. We should be even more aware of our biases, the ones that make us blind to some facts or shape our thoughts about others.

I know we might not have time to figure this out before AI surpasses us. But I believe that a better future is possible with AI, only if we collectively work towards improving ourselves while the race is happening, not after it’s already over.

• Diary of a CEO: AI Expert: We have 2 years before Everything Changes! We Need To Start Protesting! — Tristan Harris

• https://www.bowdoin.edu/news/2025/10/keep-expressing-yourself-and-stay-human-urges-ai-expert-and-author-brian-christian.html

• The Alignment Problem: Machine Learning and Human Values