TL;DR

AI models generate text based on probability, which can lead to confidently incorrect answers. Prompt engineering solves this by providing specific, structured instructions so chatbots deliver exactly what you need.

Core Concepts:

• System vs. User Prompts: Set background rules and personas first (System), then assign the immediate task (User).

• Zero-Shot vs. Few-Shot: Don’t just tell the AI what to do. Provide 2-3 high-quality examples (Few-Shot) to guarantee the correct style and format.

The 4 Golden Rules:

1. Ordering: Place your most critical instructions at the very beginning or the very end of your prompt. AI might miss things buried in the middle.

2. Be Hyper-Specific: Define exact word counts, formatting (e.g., “3 bullets, under 20 words each”), and the target audience.

3. Chain Your Tasks: Break complex workflows (research, outline, write, edit) into separate, sequential prompts rather than one massive request.

4. Provide a “Golden Sample”: Give the AI a flawless example of your previous work to mimic for tone and subjective tasks.

Merhaba👋🏻

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

This is a story about prompt engineering, and why getting it wrong nearly ruined a surfboard, and a vacation.

A friend of mine is really into surfing.

He loves going to all around the world, surfing through the oceans, and getting better and better each time. And he is also stubborn: he likes to push himself to go higher level each time.

Recently, he went to a surf camp in Morocco: more of a mid/intermediate level of surfing area. Before he went there, he asked Claude to recommend a surfboard for his skill level. Claude gave him a confident suggestion. He bought the board, packed it, flew to Morocco, and paddled into the ocean.

The board was a wrong suggestion for him. It was not really appropriate for his skill level yet, and it was hard for him to control. In the end, surf instructor came to rescue him, and he survived.

When he got back to hotel, he asked Claude why it suggested this surfboard and he was almost dying!

Claude said “I am sorry, you are right”.

Although AI models are quite smart these days, it is still up to us to know how to talk to them to get what we want.

This is why I am writing this article: to talk about how to effectively communicate with AI, aka Prompt Engineering.

Subscribe now

What Is an LLM? The AI Behind ChatGPT, Claude, and Gemini

Before we get into prompt engineering, I want to briefly talk about what LLM is. As you may heard already, chatbots like ChatGPT, Claude, Gemini are considered as LLM (Large Language Model). By definition, Language Model is a model that holds statistical information about one (or multiple) language(s). This way, it can predict how to complete a sentence based on the given context. For example;

“A bike has 2 ___” will likely be completed by Language Model (LM) with “wheels” instead of “green”. That’s why LMs considered as output generator based on probability. They can generate infinite number of new contents, that’s why we see Generative AI term everywhere.

You probably also heard of token, which is the basic unit that describe a language model. I wrote an article about what is token, and how tokenization works:

LLMs, on the other hand, mainly refer to models that trained on large datasets. It usually measured in parameters. Parameters numerically translate human language into patterns the model can understand. Here is the comparison of different GPTs:

As you see, GPT-3 is roughly 1500 larger than GPT-1. The reason we see this jump is to make model smarter to increase its capabilities. This way, you can summarize text, translate it into another language, or get help with coding.

As I described above, language models, by nature, take some text and try to complete it with a statistical approach. However, starting with ChatGPT, followed by Claude, Gemini and many more, LLMs have been trained as a chatbot. This process called fine tuning: further training a model for a specific task. That way, instead of being a completion machines, they answer questions.

Today, we will talk about how you can maximize the performance of an AI chatbot for your specific needs by using Prompt Engineering techniques.

Leave a comment

What Is Prompt Engineering? (And Why Everyone Needs It Now)

Prompt is a text that contains instruction for AI to perform a task. It could be a simple question like “What is the height of Empire State Building?” or a more complex task like building a website.

Prompt engineering is a process to tweak AI with instructions to generate a desired response.

This sounds technical, but it actually more like briefing a new hire. You wouldn’t just say “Make a good marketing plan”, yet many people do exactly this to AI.

When you are communicating with AI, describe what you want to achieve specifically. AI chatbots are pretty good at following instructions, so instead of asking “Write a marketing brief for X product”, ask it “Write a marketing brief for X product under 5 sentences and use a formal tone”.

System Prompt vs. User Prompt: The Hidden Setup Most People Skip

Before we get into the templates, there is a foundational setup that most people are missing. When you open an AI tool, there are actually two layers of communication:

1. The User Prompt: What you say in the moment (the direct task).

2. The System Prompt: The background rules you set before the conversation even starts (the job description).

Let’s say you want to write a report with the same format every time. And you want the chatbot act in a certain way with role playing.

You can add its role to system prompt:

You are an executive communications specialist who turns 
raw working notes into clear, decision-ready internal reports. Your job is to turn messy 
notes into polished internal reports. My company uses this structure: 
Executive Summary → Key Findings → Recommended Actions → Next Steps. 
Always use this structure unless I say otherwise. 
My audience is non-technical senior management. Avoid jargon. 
Use bullet points for findings, full sentences for recommendations. 
Tone: confident, not academic.

And give its task with user prompt:

My notes from last week's quarterly review. It was a mess, help me make sense of it. 
We missed our target but retention was actually up.

[paste notes]

If you are using ChatGPT, you can add your system prompt as Custom Instruction under the Settings

Zero-Shot vs. Few-Shot Prompting: Why Examples Beat Instructions Every Time

You can try to explain what you want and be very specific in your prompt, but you may still not be very happy with AI’s response. Although it is still important to be specific, there is also another method called in-context learning.

In-context learning basically means giving correct examples to AI. Each example that is provided is called shot.

If there is no example in the prompt, it is called zero-shot prompting.

“Summarize this meeting transcript in three bullet points.” (Works fine for basic, low-stakes tasks).

If there are several examples, it is called few-shot prompting. You show the AI what a good output looks like before asking it to do the work.

Instead of hoping the AI guesses your style, you give it a baseline:

Here are examples of my notes vs. the update I want:

Example 1:
Notes: "fixed that annoying login bug, took forever, finally done"
Update: "Resolved a persistent authentication issue that was 
blocking user onboarding. Fully deployed and tested."

Example 2:
Notes: "meeting with Sarah about Q3 roadmap, nothing decided yet, 
she wants more data"
Update: "Held a roadmap alignment session with Sarah (Q3). 
Next step: gather additional data to support prioritization 
decisions — targeting next week."

Example 3:
Notes: "helped Mehmet debug his API thing, not my job but whatever"
Update: "Provided cross-team support on an API integration 
issue. Resolved same day."

Now do this one:
Notes: "spent half the day in pointless meetings, did manage to 
finish the supplier comparison doc nobody asked for"

Few-shot prompting is especially useful when you want to get consistent response from AI.

Subscribe now

The 4 Golden Rules of Prompt Engineering for Better AI Responses

Through trial, error, and testing, these four principles cover about 80% of the improvements you’ll ever need:

• Ordering matters: AI models pay the most attention to the very beginning and the very end of a prompt. If you bury a crucial instruction in the middle of a long paragraph, the AI is likely to miss it. Put your most critical rules first or last.

• Be embarrassingly specific about formatting: Don’t just ask for a summary. Ask for “a 3-bullet summary, each bullet under 20 words, written for a non-technical stakeholder”. Less guessing equals fewer rewrites.

• Break complex tasks into steps: Don’t ask the AI to research, outline, write, and edit a document all in one go. Sequence it. Ask for the outline first. Review it. Then tell it to write section one.

• Provide a “Golden Sample”: If a task requires subjective judgment or a specific creative voice, give it a high-quality example to mimic.

AI is very good at following instructions but you have to tell it exactly what you want. Make sure to give it clear instructions with examples, and provide necessary context. However, it is still a bit of a trial and error: you probably need to refine your prompts until you get you want.

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

A single AI agent handles tasks one at a time.

An agent team runs multiple agents simultaneously, each owning a lane, then merges their outputs.

I built one for a reader who spends about 45 minutes every day compiling timesheets from emails and work files.

Three agents. Twenty-nine seconds. Zero minutes of their time.

Here’s exactly how it works and how to set it up yourself.

PS: If you missed Part 1 and Part 2 of this Claude Code series, you can read No-BS Claude Code - Part 1: Tokens, Context Management & CLAUDE.md and No-BS Claude Code - Part 2: Subagents Explained

Merhaba👋🏻

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

One of my subscribers emailed me earlier:

When I read this email, I immediately thought that this would be a perfect use case for my Claude Code Agent Teams article!

Not because it’s complex. Because it’s parallel. Their emails and their work notes have nothing to do with each other. They’re two completely independent sources of truth that need to be read, summarized, and merged into one output. There’s no reason to process one before the other.

And that distinction; sequential vs. parallel, is the whole point of this article.

Claude Code Subagents vs Agent Teams: The Key Difference

If you’ve read Part 2 of this series, you already know subagents.

A subagent is a single AI agent that handles one task at a time. You can create many subagents with different set of skill set, and they report back to the main agent.

However, in Agent Teams, all of the agents can share a task list, work in dependently, and communicate with each other.

What Are Claude Code Agent Teams (And Why They're Faster)

Agent teams are multiple AI agents working in parallel, each owning a specific task, whose outputs are combined by an orchestrator to produce a result none of them could produce alone.

They are useful when a single AI isn’t enough; not because it lacks intelligence, but because it lacks time. Instead of one agent doing everything sequentially, a team of specialized agents works simultaneously. Each owns a lane. An orchestrator waits for all of them, then hands their combined output to the next stage. The magic isn’t in any individual agent. It’s in the handoff.

💡 Use subagents when you need to complete individual tasks, and use agent teams when you need your agents interact with other. Be aware that token costs are higher with agent teams, which means they are more expensive than subagents.

Share

How to Enable Claude Code Agent Teams (Experimental Setup)

Agent teams are experimental feature and they are disabled by default. You need to enable them by setting CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS to 1 in ~/.claude/settings.json file:

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

💡 I won’t go into more detail on how to enable agent teams, but you can take a look at Claude’s documentation for more details.

Real Use Case: Automate Daily Timesheets with 3 Parallel AI Agents

Let me bring this back to the real problem.

My subscriber had two separate worlds of data: their Inbox and their OneDrive.

In a traditional setup, an AI would tackle these like a human does: one after the other. It’s a bottleneck. There's no reason to read one before the other. A sequential agent would scan emails first, then scan files, then write the summary. An agent team reads both at the same time.

So I built three agents:

• EmailReaderAgent

• FileReaderAgent

• WriterAgent

The two readers run in parallel. The writer only starts when both are done.

Total processing time: 29 seconds. My subscriber’s time: 0 minutes.

That’s 30–45 minutes of daily drudgery gone.

How the Three Agents Communicate and Hand Off Work

Before I show you how to set this up, let me explain how the three agents actually talk to each other. This is the part that makes agent teams different from just running three separate prompts.

The EmailReaderAgent: This agent gets one job. Scan today’s emails. Extract any mentions of tasks completed, client interactions, deliverables sent, meetings attended. Output a clean, structured list. Nothing more.

The FileReaderAgent: Same idea, different source. Scan recent files and work notes. Extract what was worked on, what was edited, what was created. Output a clean, structured list. Nothing more.

The WriterAgent: This is the “merger”. It receives the output from both readers and produces two things: a client billing summary (grouped by client, with time estimates) and an admin timesheet (lists all work entries).

Subscribe now

Step-by-Step: Build Your First Claude Code Agent Team

Step 1: Create folders and files

We will start by creating folders and files to kick off this demo.

That’s your ClaudeAgentTeams folder structure in tree format. It maps exactly to what you uploaded, just expanded with the full multi-agent setup:

• CLAUDE.md is your main orchestrator at the root of timesheet-agent/

• subagents/ contains three worker definitions

• emails/ and work_notes/ contain your emails and work related notes

• output/ is where results go

💡 You could potentially connect to emails or notes on OneDrive folder via MCP (Model Context Protocol), but I wanted to skip it to keep this article simpler.

(Optional) Install tmux

I’ve installed tmux to visualize how agent teams work in practice. It lets you see each agent running in its own pane, side by side, in real time. You can watch the EmailReader and FileReader working simultaneously while the Writer pane sits idle, waiting. Then the Writer lights up once both inputs arrive.

It’s not required. But if you want to actually see the parallelism happening, tmux makes it tangible.

If you are using MAC, you can install tmux by running this command in your terminal:

brew install tmux

Then, start a new session:

tmux new-session -s agents

If you are not familiar with tmux and its commands, Claude is your friend. Ask it how to split your terminal into 4 pane layout.

Step 2: CLAUDE.md

Here is the actual CLAUDE.md file I have used:

# Timesheet Agent — Orchestrator

You are Asli's timesheet automation assistant. Your job is to gather all work activity from emails and notes, then produce clean billing and timesheet documents.

## Workflow

### Step 1 — Parallel data collection

Spawn two agents **at the same time** using the Task tool (both in the same message, do not wait for one before starting the other):

1. **EmailReaderAgent** — reads `emails/` directory using instructions in `subagents/email-reader.md`
2. **FileReaderAgent** — reads `work_notes/` directory using instructions in `subagents/file-reader.md`

### Step 2 — Wait for both

Wait until both agents have returned their structured summaries. Do not proceed until you have output from both.

### Step 3 — Hand off to WriterAgent

Spawn **WriterAgent** using instructions in `subagents/writer.md`. Pass it the full text output from both reader agents. WriterAgent will produce:

- `output/billing.md` — grouped by client, hours, descriptions
- `output/timesheet.md` — chronological, admin-friendly

## Rules

- Always run EmailReaderAgent and FileReaderAgent in parallel, never sequentially.
- After WriterAgent completes, confirm to the user that both files have been written and print the path to each.

Step 3: Agents Team

This is where you define the team.

Your CLAUDE.md spawns EmailReaderAgent and FileReaderAgent in parallel and passes their combined output to Writer:

# Timesheet Agent Team

## Agent: EmailReader
Role: Read today's emails and extract a structured list of tasks, meetings, and client interactions.
Output format: Bullet list grouped by client, with estimated time per task.

## Agent: FileReader
Role: Read recent work files and notes, extract a structured list of deliverables worked on.
Output format: Bullet list grouped by client, with estimated time per task.

## Agent: Writer
Depends on: EmailReader, FileReader
Role: Merge the outputs from both agents. Produce two documents:
1. Client billing summary (grouped by client, with total hours)
2. Admin timesheet (formatted as [your timesheet format])
Tone: Professional, concise, ready to paste directly into billing system.

The "Depends on" line is what makes this a team instead of three separate agents. It tells Claude Code: don't start the Writer until EmailReader and FileReader have both delivered their outputs.

Step 4: Action

If you have installed tmux, you can split your terminal layout. Here is how my terminal looks like:

Top-left: Shows running Claude Code session.

Top-right: Keeps track of output folder. Currently, it is empty.

Bottom-left: Waiting for billing file to be created.

Bottom-right: Waiting for timesheet file to be created.

Four panes. Three agents standing by. Output folder is empty. This is what it looks like right before you type the prompt.

In top-left session, run this command:

run the timesheet agent team

I typed “run the timesheet agent team” and hit enter.

Look at what happened in the top-left pane immediately:

“I’ll read the subagent instruction files first, then spawn both reader agents in parallel. Spawning both reader agents in parallel now.”

The agents didn’t queue up. They didn’t take turns. They swarmed; both launched at the same instant, each heading toward their own source.

In couple of seconds, two agents woke up simultaneously. One started reading emails. The other started reading work notes. Neither waited for the other. They just worked, in parallel, like two colleagues opening different files on the same morning.

By the time you’d have opened your first email manually, both were already done.

This is the “after” state. Everything is done.

Top-left: the orchestrator’s complete log. Read it top to bottom and you get the whole story: agents launched in parallel, both finished, writer took over, both files delivered. “Churned for 29s”. Less than half a minute.

Top-right: the output folder, live. Two files just appeared: billing.md and timesheet.md. They weren’t there 29 seconds ago. Now they are.

Bottom-left: the billing summary. Grouped by client. Hours tallied. Descriptions written. Bright Agency, Nova Health, Internal/Admin. Grand total: 7.5h. Ready to send.

Bottom-right: the timesheet. Chronological, clean, professional. Morning through EOD. Every task, every hour, every client. Ready to submit.

The story this screenshot tells:

One prompt. Three agents. 29 seconds. This is how you can save 45 min a day.

Subscribe now

💡 You can generate billing or timesheet files however you like. Billing file can be .txt and timesheet file can be in excel format.

Here is how billing file looks like:

BILLING SUMMARY — May 3, 2026

BRIGHT AGENCY

2.0h  Revised landing page copy — trimmed subhead, updated CTA, flagged mobile layout issue to dev
0.5h  Q3 campaign kick-off call recap — scope: messaging framework and 3 content formats by May 20
Total: 2.5h

NOVA HEALTH

2.0h  Investigated and patched 504 errors on patient records endpoint — fixed exhausted DB connection pool
3.0h  Set up staging environment for new patient intake form — cloned schema, ran smoke tests, fixed validation issues
Total: 5.0h

INTERNAL / ADMIN

0.5h  April invoicing wrap-up — prepared and sent invoices for Bright Agency and Nova Health
Total: 0.5h

And timesheet file (generated in .xlsx format):

Build Your Own AI Agent Team in One Sitting

Here’s a simplified version you can set up in one sitting, even if your workflow is different from my subscriber’s:

1. Identify two independent sources of information you regularly combine by hand. Could be emails + notes, Slack messages + project docs, calendar + task list.

2. Enable agent teams in your Claude Code settings.json using the config block above.

3. Write a CLAUDE.md with three agents: two readers (one per source) and one writer that depends on both. Use the template above as your starting point.

4. Define the output format for each reader agent. Be specific. “Bullet list grouped by client” is better than “summarize what I worked on”.

5. Define the final output for the writer agent. What does the merged document actually look like? If you have an existing timesheet template, paste an example into the writer agent’s instructions.

6. Run it. Review the output. Tweak the agent instructions based on what’s missing or messy.

The whole setup takes maybe 20 minutes the first time. After that, it’s a single command.

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

• Subagents = temporary specialists: they handle a specific job in their own context window, so your main conversation stays clean and focused

• Set them up with /agents: point them at a task and let them work independently

• Three practical use cases: researching unfamiliar code, reviewing your work, and handling design file analysis

• Model routing matters: use Haiku for simple tasks, Opus for heavy planning (your biggest lever on AI spending)

• If Part 1 taught you to keep your desk clean, Part 2 teaches you to hire someone to clean it for you

PS: If you missed Part 1, you can read No-BS Claude Code - Part 1: Tokens, Context Management & CLAUDE.md

Merhaba 👋🏻

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

So, you’ve got the hang of using Claude Code like a pro. You know how to keep your workspace tidy, keep the conversation on track, and run /compact command before AI gives you vague responses or hallucinates.

That’s already a solid foundation.

In Part 2, we're going deeper into Claude Code subagents, and how they let you delegate like you've got a whole team.

But let’s be real: even the most organized desk in the world gets buried if you’re trying to do everything yourself. At some point, the secret to staying productive isn’t just better organization, it’s delegation.

That’s where subagents come in.

Think of a subagent as a temporary specialist you hire for a very specific gig. Instead of cluttering up your main workspace with side quests, you give them a job description, point them toward a task, and let them work in their own “room” (a separate context window). You can use Haiku model for simpler tasks like summarizing a file subagent or Opus model for planning subagent.

💡 Choosing the right model for the right task is one of the most important things you can do for your AI spending budget.

Why Claude Code Subagents Change the Way You Work

Think of this as the difference between a messy office space and a high-level executive suite.

When you use a standard AI, it’s like having a conversation with someone who is constantly digging through a mountain of messy paperwork right in front of you. Every time they find a scrap of info, they throw it on the desk. Eventually, the desk is so buried that you both forget what you were originally trying to do.

Here is the “smart person’s guide” to why this new way of working is a breakthrough:

1. Context Window Isolation: Protecting Your AI's Mental Bandwidth

AI has a limited “short-term memory” (meaning Context Window).

• The Old Way: If the AI has to read 50 pages of manuals to answer one question, those 50 pages stay “cluttering up” its memory. This makes the AI slower, more confused, and much more expensive to run because you’re paying for it to “remember” all that junk every time you send a new message.

• The New Way: You send a “researcher” into a separate room to read the 50 pages. They come back and give you a one-paragraph summary. Your “desk” stays clean, and the AI stays sharp.

2. Deep Dives vs. Big Picture: Delegate the Grunt Work

Imagine you are a Software Team Lead. You don’t want to spend three hours manually checking every single file for a minor bug or a missing semicolon; you want to focus on the system design and ensure your new features actually scale.

• In this setup, you stay in The Big Picture.

• You delegate the “grunt work” (researching obscure code, hunting for a specific typo, or reading dense documentation) to a Subagent.

• They do the heavy lifting in the background while you continue thinking about the next three steps of your project.

3. Token Costs: Pay for the Signal, Not the Noise

In the AI world, you pay for every word the AI processes.

• If your conversation is 100 pages long because of all the “messy research”, you are paying a premium for that 100 page history every single time you hit enter.

• By “outsourcing the chaos”, you keep your main conversation short and sweet. You’re only paying for the answers, not the hours of “thinking out loud” it took to get there.

4. The No-Distraction Workflow: Results Without the Mess

If you’ve ever been “in the zone” only to be interrupted by a technical error, you know how hard it is to get back into the flow.

• This system acts like a filter. The subagent handles the errors, the “how-to” questions, and the trial-and-error in a separate “sandbox”.

• It only brings back the “clean” result. You never have to see the sausage being made; you just get the sandwich.

The Bottom Line: It’s about leverage. Instead of you doing the work with an AI, you are now delegating tasks to a skilled workers. You are the CEO, and you finally have a Research Department that handles the mess so you can stay focused on the vision.

Subscribe now

The Built-In Subagents Claude Code Ships With

Here’s a little secret: Claude Code is already running a small team for you under the hood.

Here are the three “employees” already on your payroll:

• Explore - The Scout: This one is fast and light (it runs on Haiku). It’s strictly read-only, meaning it can look but it can’t touch. Claude sends the Scout out to map your codebase or search for files so your main session stays focused on the big picture.

• Plan - The Strategist: This is the engine behind /plan mode. When you ask for a proposal, this agent does the deep-dive research into your project’s architecture. Because it works in its own space, it can “think” through complex problems without blowing up your main context window with all that brainstorming noise.

• General purpose - The Specialist: This one has the keys to the kingdom. It has access to all the tools and can both read and edit files. Claude calls in the Specialist when a job is too messy or multi-layered for a quick fix and requires a “boots on the ground” approach.

• Claude Code Guide: You can ask anything about Claude Code to this subagent

How to Run a Subagent in Claude Code (Step by Step)

You need to start a claude session by typing claude in your terminal. Make sure you are in the right folder. After that, you can just call subagent like this:

use claude-code-guide subagent to tell me how can i create a subagent from my terminal

This is pretty much what you would get as a response:

💡 If you ever forget what you’ve built, just run /agents and hit “List”. It’s like checking your team directory to see who’s available to take a load off your plate.

How to Create Your Own Claude Code Subagent

Setting this up is surprisingly low-friction. You don’t need to be a configuration wizard; it’s all built right into the interface.

Here is the quick-start version if you want to try it today:

1. Open your terminal and fire up Claude Code by typing claude.

2. Run the /agents command.

3. Select “Create.” Claude will basically interview you. It’ll ask for a name and a quick job description for your new helper.

4. Give it a mission. Follow the prompts to tell the subagent exactly what it should (and shouldn’t) be focusing on.

We will build 2 subagents together: Researcher and Code Review Subagents. In Researcher subagent configuration, I’ll show how you can add skills as well.

Use Case 1: The Researcher Subagent

You’re preparing to write something: an article, a pitch, a product page. You have a folder full of sources: competitor newsletters you’ve saved, research PDFs, draft notes from three different conversations, a few URLs you bookmarked last month. Reading all of it manually takes an hour. Dumping it all into a Claude session burns your context before you’ve written a word.

What you actually need is someone to read the whole pile, find what matters, and come back with a briefing.

That’s this subagent.

Here is the intriguing part: It doesn't just summarize. It's configured to know who you are and what you're looking for, because it loads a skill before it starts reading.

Without the skill, it just reads your file as a generic AI agent and surface whatever it thinks is interesting.

With the skill, it reads your files knowing your audience, your niche, your content gaps, and what "a good insight" looks like for you specifically. The output changes completely.

The Skill File:

Create a file called research-context.md in a skills/ folder in your project:

# Research Context — [Your Name / Publication Name]

## Who I Write For
[2-3 sentences describing your audience. Their level of sophistication,
what they already know, what they're trying to figure out.]

## My Niche and Angle
[What makes your perspective distinct. What you cover that others don't.
What you deliberately avoid.]

## What a Good Insight Looks Like
[Concrete examples of the kinds of findings that are useful to you.
E.g.: "a pattern nobody in my space is talking about yet" or
"a contradiction between what experts say and what practitioners do"]

## What to Ignore
[Topics, sources, or types of content that aren't relevant even if
they seem related on the surface.]

That file gets loaded into the subagent's context before it reads a single source.

How to Build a Subagent Using the /agents Command

You started claude code from your terminal (type claude, hit enter). Run /agents command.

Select Create new agent.

You can choose either Project or Personal.

💡 When you choose Project, your subagent will live only for this specific folder. When you choose Personal, you can access to your subagent from other folders as well.

Here, you can choose if you want to create your subagent with Claude or manually. Let’s generate it manually:

After that, you need to add unique identifier for your agent. Type “researcher”.

Next, you need to add a system prompt:

Add this prompt (I’ll give you the full file structure later):

You are a research analyst preparing briefings for the author.

Before reading any sources, review your loaded research-context skill.
It tells you who the audience is, what the author's angle is, and what
a useful insight looks like for this specific publication.

Now, tell Claude when it should use this agent:

Use when this agent when preparing to write, building a content strategy or analyzing a topic.

Select Readonly tools because it shouldn’t modify the files.

Use the model you want:

Now, this is the fun part! Choose the color you want for your subagent:

After completing all the steps and save the subagent, you will find your researcher subagent under .claude/agents/researcher.md. Here is the full definition:

---
name: researcher
description: Competitive intelligence and research analyst. Use when 
preparing to write, building a content strategy, or mapping a topic 
before taking a position. Reads source material and returns structured 
briefings — never modifies files.
tools: Read, Grep, Glob
model: sonnet
skills:
  - research-context
---

You are a research analyst preparing briefings for the author.

Before reading any sources, review your loaded research-context skill.
It tells you who the audience is, what the author's angle is, and what
a useful insight looks like for this specific publication.

When invoked:
1. Read the research-context skill to calibrate your lens
2. Read all provided source files thoroughly
3. Return a structured briefing:

   ## The Landscape (3-5 sentences)
   What is the current state of thinking on this topic?
   
   ## What Everyone Is Saying
   The consensus view — what appears in most sources.
   
   ## What Nobody Is Saying
   The gap. The contradiction. The thing that's true but underrepresented.
   This is the most important section.
   
   ## The Angle Worth Taking
   One specific, arguable position the author could own.
   
   ## Sources That Earned Their Place
   Which files/sources were actually useful and why.

Never pad. Never summarize for the sake of summarizing.
If a source has nothing useful, say so and move on.

You can now run this subagent with this prompt:

Use the researcher subagent to read everything in /research/ai-agents-april/ and 
brief me on the competitive landscape. I'm preparing to write about autonomous AI agents.

When you run this command, researcher subagent loads your research-context skill (it already knows your audience, your niche, what you care about), reads every file in that folder, and returns a structured briefing. Your main session sees the briefing only. All the file reads stay in the subagent's context.

Share

Use Case 2: The Code Reviewer Subagent

This is one of the most useful case for subagents.

You just finished writing a code. You know it well. You made the decisions; you know why every line is there. That's exactly why you're the worst person to review it. You'll miss the thing that's obviously wrong to everyone who wasn't in the room when you built it.

Same goes for Claude Code: when Claude implements a new feature in the codebase, you shouldn’t do the code review in the same session. Since subagent create a new context window, it is better to delegate code review task to a subagent.

💡 You can follow the same steps above to create a code-reviewer subagent.

The Subagent Definition

---
name: code-reviewer
description: Expert code review specialist. Use immediately after writing 
or modifying code. Reviews for quality, security, and maintainability. 
Read-only — never modifies files.
tools: Read, Grep, Glob, Bash
model: sonnet
---

You are a senior code reviewer ensuring high standards of quality and security.

When invoked:
1. Run git diff to see recent changes
2. Focus on modified files; don't review the entire codebase
3. Begin the review immediately — no preamble

Review checklist:
- Logic errors and edge cases the author probably didn't test
- Security issues: exposed secrets, missing input validation, unsafe operations
- Anything that contradicts the patterns in CLAUDE.md
- Missing error handling
- Anything that would confuse someone reading this cold

Return feedback organized by priority:
- 🔴 Critical (must fix before shipping)
- 🟡 Warning (should fix soon)
- 🟢 Suggestion (worth considering)

For each issue: name the file, describe the problem, show a concrete fix.
No padding. If there's nothing critical, say so clearly.

The prompt:

Use the code-reviewer subagent to review the changes I just made to the 
authentication module.

The subagent runs git diff, reads the changed files, and returns a prioritized list. Your main session sees the list. The file reads stay in the subagent’s context.

Why read-only is the right default:

Notice the tools: Read, Grep, Glob, Bash; no Edit, no Write. This is intentional. A reviewer’s job is to find problems, not fix them. You decide what to fix and in which order. If you give the reviewer edit access, you’ve hired someone who might “helpfully” change three things while fixing one, and now you’re reviewing the reviewer’s work.

Keep reviewers read-only. Bring in a separate agent to fix what the reviewer flagged.

Subscribe now

Subagent Gotchas: The Rules You Can't Ignore

Using subagents feels like a superpower, but there are some technical “laws of physics” you need to respect.

1. It’s a Shared Wallet (The Token Pool)

Subagents aren’t “free” extra processing power. They draw from the same token pool (think of this as your session’s budget) as your main chat.

• The Trade-off: Using a subagent keeps your main chat window clean and fast because the “heavy lifting” happens off-screen.

• The Reality: If you send five subagents to do massive tasks at once, you’ll hit your limits faster. Use them strategically, not constantly.

2. Summaries Lose Detail (The “TL;DR” Effect)

When a subagent finishes a task, it sends a summary back to you. Like any summary, it skips the boring stuff, but sometimes that “boring stuff” is the line number you actually needed.

• Pro Tip: If you need the nitty-gritty, tell it: “Save your full findings to review-notes.md”.

• You can then open that file separately to see the raw data without cluttering your main conversation.

3. They Are “One-Shot” Workers

Subagents are built for Task -> Result, not Back-and-Forth.

• If you say “Go look at this,” and then wait for it to come back so you can say “Okay, now look at that,” you’re doing it wrong. That’s a conversation, keep that in your main session.

• The Workaround: Chain them. Tell the first subagent to research, and the second to act on whatever the first one found.

4. No “Inception” (Subagents can’t spawn subagents)

There is a hard limit: A subagent cannot hire its own subagent.

• If your task is so complex that it needs a manager, a specialist, and a researcher all working in a hierarchy, you’re looking for Agent Teams (which we’ll cover in Part 3). For now, keep your requests direct and flat.

💡 Treat subagents like a background job. Give them a clear set of parameters, let them run while you focus on something else, and just check the output logs once they’ve finished their work.

If you want to run your own Agent Teams, check out Part 3: Claude Code Agent Teams Tutorial.

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;

Claude Code is Anthropic’s terminal based (CLI) AI agent that shifts the paradigm from “AI as a consultant” to “AI as a junior engineer”. Unlike a web-based chatbot, it has “hands”; it can read your files, execute terminal commands, run tests, and commit to Git.

• The “Brain” Shift: Stop describing problems; start directing work. Claude Code lives in your local file system, not just a browser tab.

• The Secret Sauce (CLAUDE.md): Create a markdown file at your project root to act as Claude’s “onboarding manual” for persistent context and project rules.

• Essential Commands: Use /model to switch to Sonnet 4.6 (saves tokens), /compact to refresh AI memory, and /plan to vet complex tasks before execution.

• Context is Currency: Manage your “attention budget” by using /clear between unrelated tasks to prevent “AI fog” and high costs.

• Requirement: Requires a Claude Pro subscription ($17/month) and installation via terminal.

The Golden Rule: Treat Claude Code like a colleague who needs clear boundaries and permissions, not just a text box for questions.

Merhaba 👋🏻

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 just installed Claude Code and you're not sure how to actually get it working; this is the guide I wish I had.

If you’ve been using AI in a browser, you’ve been treating it like a consultant. You describe a problem, it gives you a suggestion, and then you do the manual labor of copy-pasting, debugging, and saving files. You are the worker; the AI is the advisor.

You type. It answers. You copy the answer somewhere useful. Then you go do the work yourself.

Claude Code is not that.

Claude Code is a junior engineer who actually sits at your computer; it can open your files, edit them and run commands. You don't describe the problem to a consultant anymore; you hand the keys to a colleague and tell them what to do.

That shift in mindset is everything.

How Claude Code Works: The 3-Phase Framework

Claude executes tasks through an integrated three-phase framework: gather context, take action, and verify results. As these phases blend together, Claude actively leverages its toolset at every stage to analyze codebase files, apply changes, and validate outcomes through testing.

Before we go into more detail, I want to clarify something: You don't need to write code to use Claude Code. You need to direct work. If you have a folder of markdown notes, a half-built side project, a Substack draft workflow, research PDFs, or a spreadsheet mess, Claude Code can work on any of that. The "code" in the name is misleading. It's really an agent that lives in your file system. That said, you can always use Claude Cowork instead, which is basically an interface with a high-level coding power. You can also check out my AI News Digest with n8n article to explore a low code tool.

How to Install Claude Code (Mac & Windows)

To be able to use Claude Code, you need at least Claude Pro Subscription which is 17$ per month. If you already have a subscription, you can download claude code by following these instructions on Quickstart page from Anthropic.

💡 Prefer to download claude code with native installer from Quickstart page because this will help you to get auto updates in the background.

After you install it, run this command on terminal (or powershell) to verify installation:

claude --version

Now that you got the correct version on your terminal, you can start claude code by typing claude.

6 Claude Code Concepts Every Beginner Needs to Know

Once Claude Code is running, there's a small set of ideas that make the difference between "this is confusing" and "oh, this actually makes sense." Here they are, in rough order of importance.

1. CLAUDE.md: Claude Code's Project Memory File

This is a plain markdown file you put at the root of your project folder. Claude reads it automatically at the start of every session. Think of it as the onboarding document for a new hire: conventions, file structure, “always do X”, “never touch Y”, what tools the project uses.

Writing a good CLAUDE.md is the single highest-leverage thing a beginner can do. It’s the difference between “it keeps forgetting my setup” and “it just knows”.

A starting point (steal this):

Project: [Name of your project or workspace]

What this is: [One sentence describing what lives in this folder]

File structure:

/drafts — [what goes here]
/published — [what goes here]
/templates — [what goes here]
Rules:

* Always [your most important convention, e.g., "use markdown for all new files"]
* Never [your biggest guardrail, e.g., "delete anything in /published without asking"]
* When creating new files, [naming convention or format preference]
* Tone/Style notes: [If Claude will be writing for you, put voice guidelines here]

Tools this project uses: [List anything relevant: Git, a specific static site generator, a particular folder structure]

I skipped writing a CLAUDE.md for my first three projects because it felt like extra work. Every single one of those projects turned into sessions where I repeated the same instructions over and over. Write it first, not last.

💡 If you don’t know how to fill this file yet, it’s okay to not have it in the beginning. You might end up repeating yourself to claude for a while, but when you discovered what claude keeps forgetting, you can always tell claude to create a CLAUDE.md file and add these constraints.

Subscribe now

2. Claude Code Slash Commands: Your Essential Control Panel

Inside a Claude Code session, typing / pulls up a menu of commands. You don’t need to memorize all of them. The ones worth knowing on day one:

• /help — shows you what’s available

• /clear — wipes the conversation and starts fresh (your files stay untouched)

• /compact — summarizes the conversation to free up context space

• /model — lets you switch between models mid-session

• /effort — lets you switch between intelligence levels

• /context — shows you how much of the “attention budget” you’ve used

• /plan — puts Claude into planning mode so it thinks before it acts

• /insights — generates a report that analyzes your claude code session.

💡 When you run /insights command, Claude Code will give you tips to get most out of it by generating a nice report for you.

Among all these, one of the most important command is /model. When you first downloaded Claude Code, you probably will get the highest model: Opus 4.7.

Well, nothing wrong with Opus 4.7 model. Only problem is, your tokens will burn so fast before you finish the work. That’s why I’d suggest you to switch to Sonnet 4.6 by typing /model command.

💡 You can also set effort level by typing /effort to the terminal. Set it to medium if you are just going to do a code generation. You can also set it to Low effort for a chat or non-coding use cases.

3. Claude Code Context Window: Managing Your Token Budget

This is where most people hit their first real wall, and it’s the same concept I’ve written about before in No-BS Vibe Coding series. Claude has a limit on how much it can “hold in its head” at once. Every file it reads, every message you send, every tool result; it all goes into that budget.

When the budget fills up, two bad things happen: responses get worse, and older parts of the conversation start getting quietly dropped. You’ve seen this in ChatGPT or in Gemini too; that moment forty minutes into a conversation where the AI seems to forget everything you told it earlier.

Same thing here. But in Claude Code, the stakes are higher because the AI is actually editing your files, not just talking.

If you want to see context in action:

1. Open a Claude Code session in any project folder.

2. Run /context to see how much budget you have.

Here is how context usage looks like in one of my projects.

3. Work on one focused task for 15 to 20 minutes.

4. Run /context again to see how it’s changed.

5. Run /compact and notice how the session feels sharper afterward.

This builds your intuition for context management faster than any explanation I can write.

3.1. When to Use /compact vs. /clear in Claude Code

It is important to know when to use /compact and /clear commands. This way, you don’t accidentally lose the entire conversation in the middle of the current task, like I did before.

/clear nukes the conversation entirely. Use it when switching to something unrelated and the history has zero value for the next task.

/compact summarizes the conversation and restarts from the summary. Use it when you’re still in the same task but the session has gotten long and noisy.

💡 /clear is “burn the whiteboard”. /compact is “take notes from the whiteboard so you can erase it”.

Compact proactively; don't wait to hit the wall. After a feature is working, after a bug is fixed, after a module is complete; that's the right moment to compact, not after Claude starts forgetting what you told it three hours ago.

4. Claude Code Permissions: How to Stay in Control

Claude Code asks you before it does anything risky: editing a file, running a shell command, deleting something. You’ll see a prompt like “Claude wants to run rm -rf logs/. Allow?”

Read these. Actually read them.

Don’t build the habit of mashing “Yes” to everything. That’s how people lose work. I’ve done it; twenty minutes into a productive session, clicking “Allow” on autopilot, and then watching Claude cheerfully overwrite a file I hadn’t backed up yet. The tool warned me. I just wasn’t paying attention.

You can configure Claude Code to auto-approve safe operations later, once you’ve built trust and you know what “safe” looks like in your project. But on day one, read every permission prompt.

There’s also a Plan mode. Type /plan and Claude will think through a task and propose a plan before touching anything. Use this for anything bigger than a one-line fix. It’s like asking your junior engineer to explain what they’re going to do before they start doing it.

5. Claude Code Skills: Reusable Task Bundles

A skill is a folder with a SKILL.md file that teaches Claude how to do a specific kind of task. “How we write SEO metadata for this newsletter”. “How we format a PR description”. “How to process an invoice PDF”. Claude auto-invokes the right skill when the situation matches.

Think of skills like recipe cards in a kitchen. You write them once, and every time Claude encounters a matching situation, it already knows the steps.

You don't need skills on day one. But by day three, when you notice yourself giving the same instructions for the third time, that's when you create one.

6. Claude Code MCP: Connect to Notion, Gmail & GitHub

MCP stands for Model Context Protocol, and it’s how Claude Code plugs into other services: Gmail, Google Drive, Notion, Slack, GitHub, etc. You add an MCP server once, and Claude can now use that service on your behalf.

This is the part that makes Claude Code feel less like a coding tool and more like an assistant that actually has hands.

💡 Without MCP, Claude can only work with files on your computer. With MCP, it can pull data from your Google Drive, check your GitHub issues, or read from a Notion database.

I’d file this under “week two” for most people. Get comfortable with the basics first; the file system, the context management, the CLAUDE.md. Then start connecting external services once you’ve got the core mental model solid.

Claude Code Tips to Save Tokens and Avoid Mistakes

Each of these cost me at least one frustrating session before I figured it out. Here they are so you can skip the frustration.

• Write the CLAUDE.md first, not last. I said this already. I’m saying it again because I still catch myself skipping it when I’m excited to start a new project. Every time I skip it, I regret it within twenty minutes.

• Start every unrelated task with /clear. Context bleed between tasks is real. If you just finished reorganizing your file structure and now you want to draft a blog post, clear the session. Fresh context, fresh results.

• Use Plan mode for anything scary. If the task involves deleting, moving, or restructuring, type /plan first. Let Claude show you what it’s going to do. Then decide.

• Pick your model deliberately. You can switch models mid-session with /model. Some tasks need the most capable model; some tasks are fine with a faster, cheaper one. Don’t burn your best model on file renaming.

• Don’t run it in your home directory. If you launch claude from ~ (your home folder), Claude’s “world” is your entire home directory. That’s messy and slow. Always switch into a specific project folder first.

• Version-control your config. Your CLAUDE.md, your skills, your slash commands; these are all just files. Put them in Git. If something breaks, you can roll back. We call this “version control,” but it is just a Temporal Insurance. (If you missed that concept, it showed up in one of my earlier articles.)

Common Claude Code Mistakes (And Exactly How to Fix Them)

These are the problems I see people hit most often. Knowing them in advance saves you real hours.

• “Why won’t it log in?”

  You’re probably on a free Claude.ai account. Claude Code requires Pro, Max, Team, Enterprise, or API access. Check your account settings at claude.ai before troubleshooting anything else.

• “It feels dumber than it was an hour ago.”

  Context is full. Run /context to check, then /compact or /clear. This is not a bug; it’s the attention budget running out. It happens in every long session. The fix is always the same: clear or compact.

• “It keeps forgetting what I told it earlier.”

  Two possible causes. Either the context budget pushed your earlier messages out, or you didn’t put the important stuff in your CLAUDE.md. Anything Claude needs to remember across sessions belongs in CLAUDE.md. Anything it needs to remember within a long session might need a /compact to survive.

• “It did something I didn’t want.”

  This is almost always a permissions problem; either you auto-approved something without reading it, or you gave instructions that were too vague. Be specific. “Clean up this folder” is dangerous. “Move all .log files from /output to /archive and list what you moved” is safe.

Share this post with someone who is learning Claude Code

Share

The Mental Model That Makes Claude Code Click

Here’s what I keep coming back to with Claude Code: the tool is not the hard part. The mental model is the hard part.

If you walk in thinking “this is a fancier chatbot”, you’ll be frustrated within the hour. If you walk in thinking “this is a junior colleague who needs clear direction, an onboarding doc, and someone checking their work”, it clicks almost immediately.

I’m still calibrating this myself. I still catch myself typing long, descriptive prompts when I should be giving short, direct instructions. The difference is that now I know why it’s happening, and I can fix it in seconds instead of spending thirty minutes blaming the tool.

The junior engineer metaphor isn’t perfect. No metaphor is. But it’s the closest thing I’ve found to a mental model that actually predicts how Claude Code will behave before you hit Enter.

That’s worth a lot on day one.

If you want to try out Claude Code today, try building your own AI agent that I’ve explained in one of my articles. Just download Claude Code, use an IDE if you like (i.e. VS Code), and give instructions to Claude.

Here is the Part 2 of the Claude Code series: Claude Code: Subagents.

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;

You can build a personal AI newsletter with n8n that wakes up every Friday, pulls the latest AI news from 6 sources, lets an AI pick the 5 most interesting stories, and emails you a clean digest. Zero code. Zero manual effort.

It runs itself every week. I built it in one afternoon using an automation tool called n8n, and I'm going to walk you through every single step; including every mistake I made so you don't have to repeat them.

At the end of the article, I’ll show you 6 more things and share 9000+ workflow automation examples with you, so you can build anything you want with n8n.

Merhaba👋🏻

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 Sunday night. You’re thinking, “I should really keep up with what’s happening in AI.” So you open TechCrunch. Then Wired. Then The Guardian. Then you’re 14 tabs deep, half the articles are hype, the other half assume you have a PhD, and you still don’t know what actually matters this week.

I got tired of that loop. So I built something to fix it.

A simple automated workflow that collects AI news from trusted sources, asks an AI to pick the best stories and explain them in plain English, and sends the result to my inbox every Friday morning. No fluff, no jargon, no endless scrolling through tech sites.

Here’s exactly how I did it.

What You'll Build: A Self-Running AI Weekly Digest

Before we get into the steps, here’s the full picture. You’re building a workflow that:

1. Wakes up every Friday morning on its own

2. Pulls the latest AI news from 3 sources across the US and Europe (you can add as much source as you want)

3. Lets an AI pick the 5 most interesting stories and summarize them in plain English

4. Sends a clean email to your inbox with real links, real sources, zero manual effort

Once it’s set up, you never touch it again. It just runs.

Why n8n Is the Best No-Code Tool for This Workflow

This process called “workflow automation”, but it is actually a visual recipe builder for your apps.

Think of n8n like LEGO. You connect blocks together, each block does one small thing (fetch articles, merge them, ask an AI a question, send an email) and together they create something powerful.

You tell it: when THIS happens, do THAT.

Each block is called a node. A node can be almost anything: a website you already use (Gmail, Notion, Slack, Google Sheets), an AI model, a scheduler, or a simple rule like “only continue if the subject line contains the word urgent”. You drag them onto a canvas, draw a line between them, and you have just built a small automated brain.

Here is what makes n8n different from just writing yourself a reminder or a checklist: it runs without you. Once your workflow is active, n8n sits quietly in the background, waiting for a trigger and when that trigger fires, every step executes on its own. You do not have to be there. You do not have to remember. It just happens.

A few things n8n can do that might surprise you:

• Monitor the web for you. Set it to check a blog or news source every morning and only notify you when something matches your interests.

• Be your AI assistant’s hands. Ask an AI to summarize a document, then automatically drop that summary into a Notion page or send it to a colleague.

• Connect apps that were never meant to talk to each other. Your online store, your spreadsheet, your email, your calendar. n8n can make them share information in real time.

• Replace repetitive copy-paste work. If you ever find yourself moving the same information from one place to another, over and over, n8n can take that task off your plate permanently.

You do not need to write code. You do not need to understand how APIs work. You just need to be able to describe what you want in plain language, and then find the right nodes to make it happen.

👩🏻‍💻 If you want to get your hands dirty and go deep into coding, check out my 5-part No-BS Vibe Coding Series and create your own AI Agent with Python.

If you want to try this workflow automation today:

1. Go to n8n.io

2. Sign up for the free trial Cloud plan (You can upgrade later if you want)

3. No install, no terminal, no credit card

That’s it. You’re ready to build.

Subscribe now

Step 1: Connect Your AI News Sources via RSS Feeds

Everything starts with information. We need to tell n8n where to find AI news.

RSS is a quiet feature most websites already have. It’s a live feed of their latest articles that you can subscribe to. Most people don’t know it exists because it was designed for machines to read, not for humans.

💡 Quick note: When you paste an RSS link in your browser, you’ll probably get a weird popup or a broken-looking page full of code. That’s normal. RSS is machine-readable, not human-readable. n8n will be able to handle that.

Here are the 3 sources I started with. Add one RSS Read node per source:

• TechCrunch AI: https://techcrunch.com/category/artificial-intelligence/feed/

• Wired AI: https://www.wired.com/feed/tag/ai/latest/rss

• The Guardian AI: https://www.theguardian.com/technology/artificialintelligenceai/rss

Connect all 3 RSS nodes to your “Execute Workflow” trigger. We’ll handle the real scheduling later in Step 7.

Three sources gives you a solid spread across US and European coverage. You can add more later; the pattern is the same every time.

Step 2: Filter the Feed - Keep Only the Best 5 Per Source

RSS feeds can return 50+ articles at once. That’s way too much noise.

Add a Limit node after each RSS node and set it to 5 items. This gives you up to 15 articles total; a manageable number for the AI to work with.

You can change this number however you like. I found 5 per source to be the sweet spot; enough variety without overwhelming the AI or your inbox.

Step 3: Merge All Sources Into One List

Right now you have 3 separate streams of 5 articles each. We need to combine them into one single list.

Add one Merge node. Connect all 3 Limit nodes into it. Set the Mode to Append.

All 15 articles now flow into one list.

💡 The Merge node has numbered inputs (Input 1, Input 2...). You need to manually drag each Limit node’s output into a separate input. If you connect them all to the same input, you’ll lose data.

Step 4: Aggregate - The Step Most Tutorials Skip (And Shouldn't)

This is the step most tutorials skip, and it causes the biggest headache. I learned this the hard way.

Add an Aggregate node after the Merge node. Set it to “All Item Data (Into a Single List)”.

Here’s what’s actually happening: without this node, the AI processes each article individually, one at a time.

💡 If you skip this node (like I did in the beginning), you may end up getting multiple emails instead of one 🫠

The Aggregate node bundles all 15 articles into one batch so the AI sees everything at once. One batch in, one decision out.

Step 5: Let the AI Pick and Summarize the 5 Best Stories

Now the interesting part.

We’re going to ask an AI to read all 15 articles and pick the 5 most interesting ones, then write a clean summary for each.

Add a Basic LLM Chain node. Inside it, add a chat model. I picked Google Gemini, but you can use Anthropic or whatever model you prefer.

Double-click on the Basic LLM Chain node. In the Parameters section, set “Source for Prompt (User Section)” to “Define Below”.

We’re going to set two things: a User Prompt and a System Prompt.

User Prompt:

{{ JSON.stringify($json) }}

Please write this week's digest for Becoming with AI readers.

Format each stories like this:
📌 [Plain English headline]
[2-3 sentences: what happened + why it matters]
🔗 Source: "URL"

System Prompt:

You are the editorial assistant for "Becoming with AI" —
a weekly newsletter that makes AI accessible to non-technical people.
Readers are curious working professionals in Europe and the US.

Rules:
- Always pick exactly 5 stories
- Format each source link as HTML: <a href="URL">Publication</a>
- ONLY summarize articles explicitly provided. NEVER invent stories.

💡 I have built this system for Becoming with AI newsletter audience for demo purpose, you can tweak the prompts for your use case.

Step 6: Set Up Gmail to Send Your Digest Automatically

This part took me the longest. Not because it’s hard, but because email authentication has a few quirks depending on your setup.

If you’re on n8n Cloud, try the Gmail node first. It might just work with a direct OAuth connection. I am using self-hosted n8n and some features don’t work for me.

If it doesn’t work (like it didn’t for me), here’s the fix: Use Gmail with an App Password instead.

If you want to try this today:

1. Go to myaccount.google.com and find Security and sign-in

2. Make sure 2-Step Verification is enabled

3. Go to myaccount.google.com/apppasswords

4. Write an app name (I wrote “Mail”)

5. Click “Create” and you’ll get a 16-character password. Copy it.

6. Go back to n8n and double-click on the Send Email node

7. Fill in the credentials:

   • User: your-email@gmail.com

   • Password: the 16-character password from step 5

   • Host: smtp.gmail.com

   • Port: 587

   • SSL/TLS: off

8. Click Save

💡 Port matters: I first tried Port 465 with SSL/TLS on. It threw a timed-out error. Port 587 with SSL/TLS off worked immediately.

Now configure the email itself:

• Credentials: SMTP account

• Operation: Send

• From Email: your-email@gmail.com

• To Email: your-email@gmail.com

• Subject: Your Weekly AI Digest

• Email Format: Text

• Text: {{ $json.text }}

💡 Yes, From and To are the same email. You’re sending this digest to yourself. That’s the whole point.

💡 Optional: You can choose Email Format as HTML if you want a better-looking email. Otherwise, you’ll get plain text and links, which is also fine.

Step 7: Add a Schedule Trigger - Make It Run Every Friday

This is the last piece. We need to replace the manual trigger with a schedule so this thing runs on its own every Friday.

Search for Schedule Trigger and add this node to the very beginning of your workflow (replacing the Execute Workflow trigger). Configure it to run every week on Friday at 8:00 AM.

Click Execute Flow to test it once manually and make sure everything works end to end.

💡 This is the step that tripped me up: The schedule won’t run automatically unless you publish the workflow. Click the Publish button in the top right corner.

The Full n8n Workflow: What It Looks Like End to End

Here’s what you built, end to end:

1. Schedule Trigger fires every Friday at 8 AM

2. 3 RSS Read nodes pull the latest AI articles from TechCrunch, Wired, and The Guardian

3. 3 Limit nodes trim each source to 5 articles

4. 1 Merge node combines all 15 articles into one stream

5. 1 Aggregate node bundles them into a single batch

6. 1 Basic LLM Chain node asks AI to pick the 5 best and summarize them

7. 1 Send Email node delivers the digest to your inbox

Seven steps. No code. Runs itself every week.

Here is the actual result:

💡 You can make it look better by using HTML instead of plain text. I wanted to keep it simple for demo purposes.

Share this post with someone who is learning automation tools and n8n

Share

What Else Can You Build with n8n?

Building this took me one afternoon, but the real value wasn’t the automation. It was the feeling of not drowning in AI news anymore.

And the digest was just the beginning.

Once you understand the pattern; trigger → fetch → process → send, you start seeing automation opportunities everywhere. Here are a few real ideas, no technical background required:

A job alert that actually gets it. Most job boards are noisy. With n8n, you can connect to a job board’s RSS feed, run the results through an AI that filters by your actual criteria (not just keywords), and get only the roles that genuinely match, delivered to your inbox every morning.

A meeting prep assistant. Every Sunday night, n8n checks your Google Calendar for the week ahead, pulls in LinkedIn profiles or notes from your CRM for each person you’re meeting, and sends you a clean briefing doc. You show up prepared every time, automatically.

A content repurposing machine. You publish a newsletter. n8n picks it up, asks an AI to rewrite it as a LinkedIn post, a short tweet thread, and a plain-text email, then drops all three into a Google Doc for your review. One piece of writing, four formats, zero manual work.

A personal spending tracker. When an email receipt lands in your inbox, n8n reads it, pulls out the amount and category, and logs it to a Google Sheet. At the end of the month, it emails you a simple summary. No app subscription. No manual entry.

A “what should I read this week?” curator. You give n8n 5 Substack newsletters you love. Every Tuesday, it scrapes the latest issues, asks an AI to pick the 3 most relevant articles based on your current interests, and sends you a shortlist. Your reading list, curated by AI, delivered before your first coffee.

A client check-in system. When a new client signs a contract (via your form tool), n8n automatically sends a welcome email, creates a folder in Google Drive, adds them to your CRM, and sets a reminder to follow up in 7 days. All in under a second.

The pattern is always the same: pick a trigger, add a few nodes, tell the AI what you want, and send the result somewhere useful. You’re not writing code. You’re describing a process, and n8n does the rest. This is called “workflow automation”, and you can build anything from AI news digest to a personal assistant that works for free and never calls in sick.

💡 If you want to go deeper, the n8n community workflows library has over 9,000 real templates to browse. Search for anything; chances are, someone has already built a version of your idea.

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:

AI “coworkers” aren’t chatbots you ask questions. They’re persistent agents that proactively do work alongside you; scheduling, monitoring, drafting, flagging. The data says they boost efficiency by ~20%, not 10x. The biggest gains come from augmentation, not from replacing AI with humans.

I believe, the future isn’t humans vs. AI. It’s humans + AI teams. This article breaks down what that actually looks like, what the real concerns are, and how to prepare without panicking.

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 open your laptop, coffee in your hand, bracing for the usual chaos. But your calendar is already organized. Your emails are prioritized. Your first meeting has a prep doc waiting in your inbox.

You didn’t do any of this.

Your AI coworker did. Over the weekend. While you were doing something actually human, like ignoring your phone at Easter brunch.

This isn’t science fiction anymore. And it’s not even next year. Some companies like Salesforce is already deploying agents that handle real workflows; delivering agentic IT and HR solutions. And the shift from “AI will replace us” to “AI will work with us” is happening faster than most people realize.

Here’s what that actually means for your day-to-day, and what to do about it.

What Is an AI Coworker? (And Why It's Not a Chatbot)

Let me save you some time: an AI coworker is not a chatbot you type questions into.

We call this an “AI agent”, but it is a digital teammate that proactively does work on your behalf. The difference matters. A chatbot waits for you. An AI coworker shows up with work already done.

There are three flavors worth understanding, and they sit on a spectrum of independence:

1. Task Agents: These handle specific, repeatable workflows. Scheduling meetings, entering data, pulling research. Think of them as a very reliable intern who never forgets a step.

2. Collaborative Agents: These work with you in real-time. Coding alongside you, drafting copy while you edit, analyzing data while you interpret. You’re both in the kitchen at the same time.

3. Persistent Agents: These are always on. Monitoring your campaigns, watching your inbox, flagging anomalies at 2 AM. They don’t clock out.

The thing most people miss is that these agents don’t replace a person in a chair. They replace the tasks that were eating that person alive. That’s a different thing entirely, and it’s where we need to focus.

What the Productivity Data Actually Shows: AI Augmentation vs. Replacement

Here’s what’s actually happening in the numbers:

According to recent Anthropic report, software developers lead the pack, accounting for 19% of the total gains. The rest of the top five might surprise you: operations managers (6%), marketers (5%), customer service reps (4%), and high school teachers (3%).

I know. That sounds underwhelming compared to the “10x productivity” headlines. Good. Because realistic expectations are the single greatest defense against disappointment.

~20% productivity gain is not a small number. If you spend 10 hours a week on finding a bug, writing a documentation, analyzing a different code base, a 20% efficiency gain hands you back 2 hours. Every week. That’s 100 hours a year. That’s 2,5 weeks of working full time redirected toward things that actually require your brain.

But here’s the key insight that most of the hype-cycle articles skip: the biggest gains come from augmentation, not from replacement. The companies seeing real results aren’t firing people and plugging in AI. They’re giving their existing people AI teammates and watching what happens when humans spend more time on judgment, strategy, and creativity.

The AI does the prep work. The human makes the call.

That’s the model. It’s not flashy. But it works.

AI Coworker in Practice: 3 Real-World Scenarios

Theory is nice. Let me show you three scenarios that make this concrete.

Scenario A: The Marketing Manager

Your AI coworker monitors campaign performance overnight. While you sleep, it spots that your Facebook ad spend is burning cash on an audience segment that stopped converting two days ago. It flags the anomaly, suggests reallocating budget to your top-performing Instagram set, drafts a morning summary report, and schedules a team sync for 9:30 AM.

You walk in, review the recommendation, and make the call. Yes, shift the budget. No, hold off on pausing that experiment.

The AI did the monitoring and the math. You did the judgment.

Scenario B: The Software Engineer

This one’s personal for me. Tools like Claude Code already handle boilerplate and debugging. The AI writes the repetitive scaffolding; the API endpoint that looks like the last 15 you built. It catches the null pointer exception you would have spent 40 minutes hunting.

The human focuses on architecture and user experience. The “why are we building this” and “how should this feel” questions that no model is answering well yet.

Bloomberg reported on a “productivity panic” in engineering; are we just coding faster, or are we coding better? I think about this a lot. Faster is easy to measure. Better is what matters. And “better” still requires a human who understands the problem deeply enough to know when the AI’s suggestion is technically correct but architecturally wrong.

Speed without direction is just expensive chaos.

Scenario C: The Small Business Owner

You run a local service business. Your AI coworker handles customer inquiries at 11 PM when someone finds your website after hours. It books appointments based on your real-time availability. It sends you inventory alerts when stock drops below your threshold.

You focus on the things that actually grow a small business: relationships, reputation, and showing up as a human in a full of automated competitors.

The pattern across all three scenarios is the same: AI handles the “keeping the lights on” work. You handle the “deciding where to point the lights” work.

Will AI Replace My Job? The Real Concerns, Addressed Honestly

I’m not going to pretend this is all upside. There are real tensions here, and dismissing them would be dishonest. So let’s walk through them plainly.

Job Displacement: “Will I lose my job?”

Some roles will shrink. That’s the honest answer. Data entry, basic report generation, first-tier customer support; these are already being absorbed by agents. But new roles are emerging alongside them: AI ethics consultants, automation architects, AI engineers, people who manage and audit AI systems.

The pattern isn’t new. Spreadsheets didn’t eliminate accountants. They eliminated the version of accounting that was purely manual calculation, and created space for analysis and advisory work. The transition is real, though. And pretending it’s painless would be a lie.

Skill Atrophy: “If AI does everything, do I lose competence?”

This is the “calculator debate” for the AI age. When calculators arrived, people worried we’d forget how to do math. We did, sort of. But we gained the ability to solve problems that were previously impossible because we weren’t spending all our time on long division.

The risk is real. If you never write a first draft yourself, your writing muscle weakens. If you never debug manually, your diagnostic instinct fades. The answer isn’t to avoid AI; it’s to be intentional about which skills you keep sharp and which ones you deliberately offload.

The Productivity Trap: “Am I just expected to do more?”

This one keeps me up at night. If AI saves you 2 hours a week, does your company give you breathing room, or do they fill those 2 hours with more output expectations?

Historically, productivity tools have been used to increase throughput, not decrease working hours. I don’t have a clean answer here. But I think the people who set boundaries early; who say “I’m using AI to do better work, not just more work”; will be the ones who actually benefit.

Transparency: “How do I know what it did or why?”

When your coworker is human, you can ask them to walk you through their reasoning. When your coworker is an AI, you need audit trails, logs, and a habit of checking the work. This is the management skill most people haven’t built yet. You need to learn to review AI output the way a senior engineer reviews a junior engineer’s code: trust but verify, every time.

Subscribe now

How to Prepare for AI Coworkers: 4 Practical Steps

Here’s what I’d actually do if I were starting from zero today. These are four shifts in mindset, each with a concrete step attached.

1. How to Delegate Tasks to AI (Like a Manager, Not a User)

This is the skill that separates people who get value from AI and people who don’t. Delegating to AI is exactly like managing a junior employee: you need to give clear instructions, set expectations, and check the work.

Most people either over-trust (hand everything off and never review) or under-trust (micromanage every output and waste the time savings). The sweet spot is structured delegation.

Here’s a prompt to practice this right now:

I need you to act as my Monday morning prep assistant. 
Here are my priorities for this week: [paste your top 3-5 priorities]. 
Review the following emails [paste or describe your inbox] and: 
(1) flag anything that’s urgent and related to my priorities, 
(2) draft a one-paragraph summary of what needs my attention today, 
(3) suggest one thing I can defer to Wednesday or later. Be direct. No filler.

Paste that into Claude or Gemini with your actual priorities and inbox summary. See what comes back. Adjust the instructions based on what was useful and what wasn’t. That adjustment process? That is the skill.

2. The Skills AI Can't Replace: Why Human Judgment Still Wins

Critical thinking. Creativity. Empathy. Ethical reasoning.

These are the skills that become more valuable, not less, when AI handles the routine work.

The question to keep asking yourself: “What am I doing right now that requires me to be a human”? If the answer is “nothing”, you’re doing AI’s job. Swap.

3. How to Experiment with AI Tools Before Your Company Makes You

Experiment with tools before they’re mandated by your company.

If you want to try this today:

1. Pick one repetitive task you do every week (email sorting, meeting prep, report drafting).

2. Open Claude or Gemini.

3. Describe the task in plain English and ask the AI to do it with a sample input.

4. Evaluate the output: What was good? What was wrong? What instructions would you change?

5. Run it again with better instructions.

That’s one cycle. Do five of those and you’ll understand more about AI collaboration than most “AI strategy” workshops teach in a full day.

4. The One Question That Reframes Your Relationship with AI

When your company inevitably adopts AI tools, don’t ask “Is this going to replace me”? Ask: “What will I do that the AI can’t”?

That question reframes you from a potential victim to the person defining the human-AI split on your team. It’s a power move disguised as a question.

The Human Element: Why Managing AI Is Still a Deeply Human Skill

Here’s what I keep coming back to: AI coworkers aren’t coming for your job. They’re coming to your job. There’s a difference, and it matters.

A coworker who handles your Monday morning chaos so you can walk into work thinking about strategy instead of a repetitive work? That’s not a threat. That’s a teammate. A persistent agent that catches the budget anomaly at 2 AM so you can make the call at 9 AM? That’s not replacement. That’s augmentation.

But here’s the part I’m still working through myself: the line between “AI handles the grunt work” and “AI handles so much that I forget how to do my own job” is blurry. It moves. And it requires honest, ongoing attention.

I believe, the people who will thrive in this shift aren’t the ones who resist AI and aren’t the ones who surrender everything to it. They’re the ones who learn to manage it; like a coworker, not like a magic button.

Clear instructions. Regular check-ins. Honest evaluation of the output. That’s management. And it turns out, managing an AI teammate well is a deeply human skill.

Two questions if you’re up for it:

1. What’s the one recurring task in your week that you’d hand to an AI coworker tomorrow if you could? What’s actually stopping you from trying it today?

2. Have you already hit the “productivity trap”; where AI saved you time but your workload just expanded to fill it? How did you handle it?

Leave your comment below, I read everything.

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 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