![](https://cdn-images-1.medium.com/max/1600/1*-MIBhQQXcCoFkZASy7pRJw.png)

Generated by the author with AI.

**Two months ago, I thought I had perfected my AI coding workflow.**

I posted a blog breaking down how I used Cursor and its AI agent features to build productivity apps faster than ever before. Developers resonated. But here I am again, because *everything changed.*

This isn’t just an update. This is a total replacement. I dropped Cursor’s AI tools almost entirely. And after using Claude Code for just one week, I don’t think I’m ever going back.

***

### Why I Switched to Claude Code (And Stopped Using Cursor Agents)

I used Cursor religiously for over a year. It’s a powerful AI pair-programming experience. But after Claude Code’s pricing shift, I gave it a shot. And what I found blew me away:

* **Claude Code lives in the terminal.** No GUI. No editor. Just an agent that can drop into any repo and work.
* **It solved complex bugs Cursor agents couldn’t.**
* **It generates more thoughtful, higher-quality solutions.**

Cursor still runs in my dev environment, but only as a basic code editor now. All AI work? That’s Claude Code.

***

### Getting Started with Claude Code

Before diving into the workflow, here’s how simple it is to set up Claude Code:

[**Claude Code SDK - Anthropic**
*Learn about programmatically integrating Claude Code into your applications with the Claude Code SDK.*&#x64;ocs.anthropic.com](https://docs.anthropic.com/en/docs/claude-code/sdk "https://docs.anthropic.com/en/docs/claude-code/sdk")

1. **Install via NPM:**

```
npm install -g @anthropic-ai/claude-code
```

2\. **Authenticate (on first run):**

```
claude
```

Follow the prompt to log into your Anthropic account (Pro or Max plan required).

3\. **You’re ready to go.** Now you can run the `claude` command in any terminal, in any codebase, and just start chatting with it:

```
claude
```

From there, ask it questions, request features, or give it tasks like:

```
> add a login form using React> fix the bug in UserController
```

Now, let’s get into the actual workflow I use every day.

***

### My Claude Code Workflow:

Here’s exactly how I work with Claude Code to ship features, debug issues, and build complex systems faster than ever.

#### 1. Start in Plan Mode (Always)

Claude Code has a special mode called *plan mode*. Activate it with `Shift + Tab` inside the terminal interface.

![](https://cdn-images-1.medium.com/max/1600/1*ZzBeioS-KIm2dhXYjlvjWw.png)

> ***Why it matters:** Plan mode doesn’t touch your files. It just thinks.*

When you submit a request — like “Add user authentication to this project”, Claude won’t start writing code right away. Instead, it outlines a comprehensive plan:

* What files it will modify
* The logic it intends to add or delete
* Potential edge cases or limitations

**How I use it:**

* I always begin in plan mode
* Review the plan line-by-line
* Give it a go/no-go decision based on clarity and scope
* Ask clarifying questions if anything feels off

This one habit alone has prevented dozens of unnecessary file changes and costly bugs. It’s like a dry run for your request.

#### 2. Generate and Maintain a [`claude.md`](https://claude.md) File

Think of [`claude.md`](https://claude.md) as the operating manual Claude follows while working in your repo.

Use the `/init` command and it will automatically generate this file. But don’t stop there:

**What I include in mine:**

* Frameworks used (e.g. “This is a [Next.js](https://Next.js) project”)
* Styling rules (e.g. “Use Tailwind utility classes only”)
* Naming conventions (e.g. “All components must use kebab-case”)
* Architectural notes (e.g. “State management handled via Redux”)

You can also add to it conversationally:

> *“Hey Claude, remember that we never mutate props directly in React.”*

It will update the file on its own. This is *way* more reliable than ad-hoc reminders.

#### 3. Use Git as Your Checkpoint System

Claude Code doesn’t offer a restore feature like Cursor.

**My workaround:**

* Commit *constantly*
* Use descriptive commit messages
* Treat commits like time-stamped checkpoints

Before allowing Claude to execute a plan, I make a commit:

```
$ git commit -am "Pre-Claude change: added placeholder login logic"
```

Then if Claude’s change introduces regressions or breaks unrelated parts of the codebase:

```
$ git reset --hard HEAD~1
```

No risk. No stress. And yes — it saved me at least 5 times in one week.

#### 4. Feed It Screenshots (Seriously)

You can drag & drop screenshots into the Claude terminal interface.

**Use cases I’ve tested:**

* Console error messages (e.g. “Uncaught TypeError”)
* Web app UI bugs (e.g. layout breaks)
* Design handoffs (e.g. Figma previews, mockups)

Claude parses the image and incorporates that context into its response, often better than I expect. It’s basically doing visual debugging *and* frontend development off of JPEGs.

#### 5. Drag and Drop Entire Folders for Context

Want to supercharge Claude’s understanding of your stack? Just drag in another codebase.

**Real example:**

* I was working on the web app front end
* I dragged in the `backend/` folder from another repo
* Asked Claude: “Use this to understand the API endpoints available, don’t modify it.”

Claude parsed the whole thing. Later, it used that knowledge to:

* Build more accurate API integration logic
* Avoid asking redundant questions
* Even warn me when a backend method didn’t exist

**Important:** It won’t modify the external folder unless you explicitly say so.

#### 6. Use URLs Like Bookmarks, It Can Browse

Claude Code has built-in web browsing capabilities. Paste a URL to official documentation, and it will read and cite from it.

But here’s the wild part:

* You *don’t even need* to paste links.
* You can just say: “Use the latest Notion API v2.4.”
* Claude goes and fetches the relevant docs, reads them, and executes accordingly

This has completely eliminated my need to babysit it through external documentation.

#### 7. Use Sub-Agents for Massive Tasks

Claude can fork itself. Literally.

If you’re running a giant task — like porting an iOS app to Android — you can say:

> *“Break this up into subtasks and spin up sub-agents to handle them in parallel.”*

And it will.

**Use cases I’ve tested:**

* UI migration + business logic separation
* Component-by-component translation between frameworks
* Background optimization while I do something else

The first time I tried this, it spun up 10 agents concurrently. A task that should’ve taken 60+ minutes? Done in under 15.

#### 8. Ask It to QA Its Own Work

After every major change, I ask Claude:

> *“Double-check everything. What might this have broken?”*

It often:

* Detects dependency conflicts
* Warns about cascading failures
* Suggests edge-case handling (like empty state fallbacks)

This step catches the 5% that even senior devs can overlook.

#### 9. Review the Output Like a Real PR

This step is *critical.*

Claude Code is *so good* that you’ll be tempted to just trust it. Don’t.

I treat it like a human teammate:

* Read every modified file
* Run unit tests
* Use linters + TypeScript to catch structural issues
* Compare diffs against original functionality

Even when it’s right, it’s good to *know why.*

***

### So Why Is Claude Code Better?

Cursor *uses the same models* (Sonnet 4, Opus).

So what gives?

Here’s my hypothesis:

* Cursor aggressively compresses context to save tokens
* Claude Code does not, it maximizes context and quality
* Claude Code *loses money* on heavy users like me

Someone even built a script to measure token usage. In one week, I used $300 worth of API tokens, for $20.

> ***Claude Code is probably running at a loss to win devs.***

Will this last? Probably not. But for now, it’s an insane value.

***

### The Catch (Because of Course There’s One)

Claude Code isn’t perfect.

* **$200/month is steep** if you’re not a professional dev
* **No built-in checkpointing** (manual Git commits only)
* **Slow execution times** on big tasks (30+ mins sometimes)

But if you make money from software? The ROI is ridiculous.

***

### Who Should Use This

**Use Claude Code if:**

* You build apps full-time
* You care about speed and quality
* You can afford $200/mo for a 10x boost

**Stick with Cursor if:**

* You’re a hobbyist
* You’re just learning
* You need a cheaper (still great) tool

Cursor is still excellent. But for now? Claude Code is in a different league.

### A message from our Founder

**Hey,** [**Sunil**](https://linkedin.com/in/sunilsandhu) **here.** I wanted to take a moment to thank you for reading until the end and for being a part of this community.

Did you know that our team run these publications as a volunteer effort to over 3.5m monthly readers? **We don’t receive any funding, we do this to support the community. ❤️**

If you want to show some love, please take a moment to **follow me on** [**LinkedIn**](https://linkedin.com/in/sunilsandhu)**,** [**TikTok**](https://tiktok.com/@messyfounder), [**Instagram**](https://instagram.com/sunilsandhu). You can also subscribe to our [**weekly newsletter**](https://newsletter.plainenglish.io/).

<img src="https://cdn-images-1.medium.com/max/1600/1*-MIBhQQXcCoFkZASy7pRJw.png" alt="">
Generated by the author with AI.
Two months ago, I thought I had perfected my AI coding workflow.
I posted a blog breaking down how I used Cursor and its AI agent features to build productivity apps faster than ever before. Developers resonated. But here I am again, because everything changed.
This isn’t just an update. This is a total replacement. I dropped Cursor’s AI tools almost entirely. And after using Claude Code for just one week, I don’t think I’m ever going back.
<hr>
<h3 id="why-i-switched-to-claude-code-and-stopped-using-cursoragents">Why I Switched to Claude Code (And Stopped Using Cursor Agents)</h3>
I used Cursor religiously for over a year. It’s a powerful AI pair-programming experience. But after Claude Code’s pricing shift, I gave it a shot. And what I found blew me away:
<ul>
<li>Claude Code lives in the terminal. No GUI. No editor. Just an agent that can drop into any repo and work.</li>
<li>It solved complex bugs Cursor agents couldn’t.</li>
<li>It generates more thoughtful, higher-quality solutions.</li>
</ul>
Cursor still runs in my dev environment, but only as a basic code editor now. All AI work? That’s Claude Code.
<hr>
<h3 id="getting-started-with-claudecode">Getting Started with Claude Code</h3>
Before diving into the workflow, here’s how simple it is to set up Claude Code:
<a href="https://docs.anthropic.com/en/docs/claude-code/sdk" title="https://docs.anthropic.com/en/docs/claude-code/sdk">Claude Code SDK - Anthropic
Learn about programmatically integrating Claude Code into your applications with the Claude Code SDK.docs.anthropic.com</a>
<ol>
<li>Install via NPM:</li>
</ol>
<pre><code class="code-highlight">npm install -g @anthropic-ai/claude-code
</code></pre>
2. Authenticate (on first run):
<pre><code class="code-highlight">claude
</code></pre>
Follow the prompt to log into your Anthropic account (Pro or Max plan required).
3. You’re ready to go. Now you can run the <code>claude</code> command in any terminal, in any codebase, and just start chatting with it:
<pre><code class="code-highlight">claude
</code></pre>
From there, ask it questions, request features, or give it tasks like:
<pre><code class="code-highlight">> add a login form using React> fix the bug in UserController
</code></pre>
Now, let’s get into the actual workflow I use every day.
<hr>
<h3 id="my-claude-code-workflow">My Claude Code Workflow:</h3>
Here’s exactly how I work with Claude Code to ship features, debug issues, and build complex systems faster than ever.
<h4 id="1-start-in-plan-modealways">1. Start in Plan Mode (Always)</h4>
Claude Code has a special mode called plan mode. Activate it with <code>Shift + Tab</code> inside the terminal interface.
<img src="https://cdn-images-1.medium.com/max/1600/1*ZzBeioS-KIm2dhXYjlvjWw.png" alt="">
<blockquote>
Why it matters: Plan mode doesn’t touch your files. It just thinks.
</blockquote>
When you submit a request — like “Add user authentication to this project”, Claude won’t start writing code right away. Instead, it outlines a comprehensive plan:
<ul>
<li>What files it will modify</li>
<li>The logic it intends to add or delete</li>
<li>Potential edge cases or limitations</li>
</ul>
How I use it:
<ul>
<li>I always begin in plan mode</li>
<li>Review the plan line-by-line</li>
<li>Give it a go/no-go decision based on clarity and scope</li>
<li>Ask clarifying questions if anything feels off</li>
</ul>
This one habit alone has prevented dozens of unnecessary file changes and costly bugs. It’s like a dry run for your request.
<h4 id="2-generate-and-maintain-a-claudemd-file">2. Generate and Maintain a <a href="https://claude.md"><code>claude.md</code></a> File</h4>
Think of <a href="https://claude.md"><code>claude.md</code></a> as the operating manual Claude follows while working in your repo.
Use the <code>/init</code> command and it will automatically generate this file. But don’t stop there:
What I include in mine:
<ul>
<li>Frameworks used (e.g. “This is a <a href="https://Next.js">Next.js</a> project”)</li>
<li>Styling rules (e.g. “Use Tailwind utility classes only”)</li>
<li>Naming conventions (e.g. “All components must use kebab-case”)</li>
<li>Architectural notes (e.g. “State management handled via Redux”)</li>
</ul>
You can also add to it conversationally:
<blockquote>
“Hey Claude, remember that we never mutate props directly in React.”
</blockquote>
It will update the file on its own. This is way more reliable than ad-hoc reminders.
<h4 id="3-use-git-as-your-checkpoint-system">3. Use Git as Your Checkpoint System</h4>
Claude Code doesn’t offer a restore feature like Cursor.
My workaround:
<ul>
<li>Commit constantly</li>
<li>Use descriptive commit messages</li>
<li>Treat commits like time-stamped checkpoints</li>
</ul>
Before allowing Claude to execute a plan, I make a commit:
<pre><code class="code-highlight">$ git commit -am "Pre-Claude change: added placeholder login logic"
</code></pre>
Then if Claude’s change introduces regressions or breaks unrelated parts of the codebase:
<pre><code class="code-highlight">$ git reset --hard HEAD~1
</code></pre>
No risk. No stress. And yes — it saved me at least 5 times in one week.
<h4 id="4-feed-it-screenshots-seriously">4. Feed It Screenshots (Seriously)</h4>
You can drag &#x26; drop screenshots into the Claude terminal interface.
Use cases I’ve tested:
<ul>
<li>Console error messages (e.g. “Uncaught TypeError”)</li>
<li>Web app UI bugs (e.g. layout breaks)</li>
<li>Design handoffs (e.g. Figma previews, mockups)</li>
</ul>
Claude parses the image and incorporates that context into its response, often better than I expect. It’s basically doing visual debugging and frontend development off of JPEGs.
<h4 id="5-drag-and-drop-entire-folders-forcontext">5. Drag and Drop Entire Folders for Context</h4>
Want to supercharge Claude’s understanding of your stack? Just drag in another codebase.
Real example:
<ul>
<li>I was working on the web app front end</li>
<li>I dragged in the <code>backend/</code> folder from another repo</li>
<li>Asked Claude: “Use this to understand the API endpoints available, don’t modify it.”</li>
</ul>
Claude parsed the whole thing. Later, it used that knowledge to:
<ul>
<li>Build more accurate API integration logic</li>
<li>Avoid asking redundant questions</li>
<li>Even warn me when a backend method didn’t exist</li>
</ul>
Important: It won’t modify the external folder unless you explicitly say so.
<h4 id="6-use-urls-like-bookmarks-it-canbrowse">6. Use URLs Like Bookmarks, It Can Browse</h4>
Claude Code has built-in web browsing capabilities. Paste a URL to official documentation, and it will read and cite from it.
But here’s the wild part:
<ul>
<li>You don’t even need to paste links.</li>
<li>You can just say: “Use the latest Notion API v2.4.”</li>
<li>Claude goes and fetches the relevant docs, reads them, and executes accordingly</li>
</ul>
This has completely eliminated my need to babysit it through external documentation.
<h4 id="7-use-sub-agents-for-massivetasks">7. Use Sub-Agents for Massive Tasks</h4>
Claude can fork itself. Literally.
If you’re running a giant task — like porting an iOS app to Android — you can say:
<blockquote>
“Break this up into subtasks and spin up sub-agents to handle them in parallel.”
</blockquote>
And it will.
Use cases I’ve tested:
<ul>
<li>UI migration + business logic separation</li>
<li>Component-by-component translation between frameworks</li>
<li>Background optimization while I do something else</li>
</ul>
The first time I tried this, it spun up 10 agents concurrently. A task that should’ve taken 60+ minutes? Done in under 15.
<h4 id="8-ask-it-to-qa-its-ownwork">8. Ask It to QA Its Own Work</h4>
After every major change, I ask Claude:
<blockquote>
“Double-check everything. What might this have broken?”
</blockquote>
It often:
<ul>
<li>Detects dependency conflicts</li>
<li>Warns about cascading failures</li>
<li>Suggests edge-case handling (like empty state fallbacks)</li>
</ul>
This step catches the 5% that even senior devs can overlook.
<h4 id="9-review-the-output-like-a-realpr">9. Review the Output Like a Real PR</h4>
This step is critical.
Claude Code is so good that you’ll be tempted to just trust it. Don’t.
I treat it like a human teammate:
<ul>
<li>Read every modified file</li>
<li>Run unit tests</li>
<li>Use linters + TypeScript to catch structural issues</li>
<li>Compare diffs against original functionality</li>
</ul>
Even when it’s right, it’s good to know why.
<hr>
<h3 id="so-why-is-claude-codebetter">So Why Is Claude Code Better?</h3>
Cursor uses the same models (Sonnet 4, Opus).
So what gives?
Here’s my hypothesis:
<ul>
<li>Cursor aggressively compresses context to save tokens</li>
<li>Claude Code does not, it maximizes context and quality</li>
<li>Claude Code loses money on heavy users like me</li>
</ul>
Someone even built a script to measure token usage. In one week, I used $300 worth of API tokens, for $20.
<blockquote>
Claude Code is probably running at a loss to win devs.
</blockquote>
Will this last? Probably not. But for now, it’s an insane value.
<hr>
<h3 id="the-catch-because-of-course-theresone">The Catch (Because of Course There’s One)</h3>
Claude Code isn’t perfect.
<ul>
<li>$200/month is steep if you’re not a professional dev</li>
<li>No built-in checkpointing (manual Git commits only)</li>
<li>Slow execution times on big tasks (30+ mins sometimes)</li>
</ul>
But if you make money from software? The ROI is ridiculous.
<hr>
<h3 id="who-should-usethis">Who Should Use This</h3>
Use Claude Code if:
<ul>
<li>You build apps full-time</li>
<li>You care about speed and quality</li>
<li>You can afford $200/mo for a 10x boost</li>
</ul>
Stick with Cursor if:
<ul>
<li>You’re a hobbyist</li>
<li>You’re just learning</li>
<li>You need a cheaper (still great) tool</li>
</ul>
Cursor is still excellent. But for now? Claude Code is in a different league.
<h3 id="a-message-from-ourfounder">A message from our Founder</h3>
Hey, <a href="https://linkedin.com/in/sunilsandhu">Sunil</a> here. I wanted to take a moment to thank you for reading until the end and for being a part of this community.
Did you know that our team run these publications as a volunteer effort to over 3.5m monthly readers? We don’t receive any funding, we do this to support the community. ❤️
If you want to show some love, please take a moment to follow me on <a href="https://linkedin.com/in/sunilsandhu">LinkedIn</a>, <a href="https://tiktok.com/@messyfounder">TikTok</a>, <a href="https://instagram.com/sunilsandhu">Instagram</a>. You can also subscribe to our <a href="https://newsletter.plainenglish.io/">weekly newsletter</a>.

And why you might want to do the same (if you’re a serious builder).

I Replaced Cursor Agent with Claude Code, Here’s What Happened

![](https://cdn-images-1.medium.com/max/1600/1*kL3ilZSFElPb20j9mEO-SQ.jpeg)

Photo by [Google DeepMind](https://unsplash.com/@googledeepmind?utm_content=creditCopyText\&utm_medium=referral\&utm_source=unsplash) on [Unsplash](https://unsplash.com/photos/a-close-up-of-a-green-object-on-a-white-surface-SrLwQZP0_Ec?utm_content=creditCopyText\&utm_medium=referral\&utm_source=unsplash)

It’s been almost 2 years since I first encountered the [“Attention is all you need”](https://arxiv.org/abs/1706.03762) paper by Vaswani et al. (2017). I’ve mentioned it confidently in a few conversations, but I only just came to understand it *enough* this month.

> We listen, we don’t judge.

In all fairness to me, I only started taking my NLP journey seriously late last year, and I’ve had to wade through information overload, *hype* and a lot of foundational stuff just to get to a point where papers like this finally make proper sense. I even wrote about [Word2Vec in my last article](https://medium.com/ai-in-plain-english/word2vec-my-rookie-thoughts-on-the-landmark-nlp-paper-5536967a93e2); you can check it out.

Before this latest attempt, I had tried several times to read the paper, but it never fully clicked. This time around, I used the [3-pass technique I saw on Madukoma Blessed’s blog](https://mblessed.hashnode.dev/research-that-sticks-the-strategic-framework-for-studying-technical-papers), and I finally got the core message and technical parts.

If you’ve also been putting off reading “scary papers,” maybe this method might help you. Walk with me.

***

### **The strategy**

The 3-pass method is pretty straightforward.

* First, you skim and note the overall idea;
* Then, you dig a bit deeper for key ideas;
* Finally, you go all in on the technical details.

It helps to ease into tough papers without burning out. And that’s exactly what I did. As you read further, I’ll detail my learnings in bullet points under each pass.

***

### Some information…

To help you understand the notes in the rest of the article, you need to be familiar with a few things, like RNNs, CNNs and Sequence transduction models (like Seq2Seq). You don’t have to cram the math. Just get the general idea.

* **RNNs (Recurrent Neural Networks):**
  They process data *step by step*, passing information from one step to the next. Think of them like reading a sentence one word at a time, remembering what came before. They’re great at handling sequences, but they can be slow and struggle with long sequences.
* **CNNs (Convolutional Neural Networks):**
  Originally built for images, but sometimes used for text too. They focus on learning *local patterns. F*or example, detecting small chunks or phrases in text. They’re faster than RNNs in some cases, but still have limits with longer dependencies.
* **Sequence transduction models (like Seq2Seq models):**
  These models take in a sequence and produce another sequence. Classic examples? Translation and summarisation. You give it a sentence, and it outputs a new sentence in another language or a shorter version.

If these still feel confusing, it might be helpful to pause and brush up a little more on NLP basics first. And that’s perfectly okay. Been there, done that. 2 years *hello*?!

> Maybe still a little there to be honest.

***

### Pass 1: Skimming and “Wait, that’s why?!”

* The whole point of the paper is this: What if we stopped using complicated stuff like *RNNs* and *CNNs* to build sequence transduction models and just used *attention* instead?
* To prove this idea, they introduced a new architecture called the *Transformer*, which was built solely with the attention mechanism, without any recurrence or convolutions.
* It worked and proved to be more efficient than the State-of-The-Art (SOTA) models at the time, using *BLEU scores* as the evaluation metric.
* Hence, attention is all you *really* need. How did I not get that since?!

> PS. Weirdly enough, I finally learnt the meaning of **SOTA,** and I’m feeling like a cool “kid”. Time to not-so-casually throw it around in conversations.

***

### Pass 2: Key Ideas & Takeaways

#### **The Old Way (Before This Paper)**

* Sequence models (like for translation) were usually built using *encoders* and *decoders* made up of RNNs (like LSTMs or GRUs), sometimes in combination with CNNs or the *attention* mechanism.
* While they worked, they had a major bottleneck: They processed data step by ste&#x70;**,** meaning one word at a time.
* This was not-so-great for modern hardware (GPUs, TPUs) designed for parallel processing. Longer sequences meant more memory, more time, and endless waiting.
* Even with *tricks*, you were stuck in a step-by-step loop.

#### **The New Way (The Transformer)**

This improved architecture meant:

* Full parallelisation during training: You can process everything at once, instead of waiting for previous steps.
* Faster training and better performance.

#### Their Results?

* The transformer beat older models on English-to-German and English-to-French translation tasks.
* They used multiple attention heads (8 in the base model), which helped capture different patterns in the data.
* Dropout helped prevent overfitting.
* They also tested a version of the model on an English parsing task, showing it could generalise beyond translation.

#### Side Note

Although training is now fully parallel, generating text (output) still happens one word at a time (sequentially). They mentioned this as a future challenge. The authors also acknowledged that it’s text-based only (no multimodal *yet,* or at least, *as at the time*).

![](https://cdn-images-1.medium.com/max/1600/1*HRAkxXY1eXLD-pii7Mt8SQ.jpeg)

Figure 1: This was my understanding after pass 2

***

### Pass 3: Breaking Down the Model Architecture

I focused on Sections 3 and 4 of the paper, which describe the components of the architecture in detail. The Transformer, like older seq2seq models, has an **encoder** and a **decoder**. Both are made of layers, and those layers have sublayers. A formula for calculating the output of a sublayer of either the encoder or decoder is:

```
Output = LayerNorm(x + Sublayer(x))
```

where:

* ***x*** is the input to the sublayer.
* ***Sublayer(x)*** is the actual computation (e.g., attention, feed-forward network).
* ***x + Sublayer(x)*** is called a **residual connection**, a fancy term for adding the input back to the output of the sublayer. It's crucial for stable training and optimisation in deep networks.
* ***LayerNorm()*** is Layer Normalisation, which is applied for stability after adding the input back.

#### Now, let’s look at the core components of the Transformer

![](https://cdn-images-1.medium.com/max/1600/1*LFw8HnqV1ddxAZ0Kv38ngw.png)

Figure 2: The Transformer architecture with its components — Vaswani et al. (2017). One encoder layer on the left, one decoder layer on the right. The Nx represents the fact that there are multiple (N=6) layers.

#### **1. Attention (Star of the show)**

Attention is essentially a way to map a query and a set of key-value pairs to an output. It helps the model “focus” or “pay attention” to a specific part of a sequence. The paper focuses on two key types:

![](https://cdn-images-1.medium.com/max/1600/1*i9kOSH57xZZ11HodlHiQTw.png)

Figure 3: Screenshot from my Notion notes

**Why the emphasis on self-attention in the paper?**

1. Faster and more parallelisable.
2. Learns long-distance relationships better.
3. Easier to visualise and interpret.

**In the paper, they also discussed two techniques to calculate attention:**

* **Scaled Dot-Product Attention:** 
  This is the core mathematical operation. It takes three matrices: **Q** (queries), **K** (keys), and **V** (values). Each row of the matrices represents a token in the sequence. The formula is as follows:

```
Attention(Q, K, V) = softmax(QKᵀ / √dₖ) · V
```

* **Multi-head Attention:**
  Instead of just one *attention* calculation, it runs multiple scaled dot-product attentions in parallel,**** called *heads*. It doesn’t just split the input; it creates *different learned projections* (like different “views” or “perspectives”) of Q, K, and V for each “head.”

  Each head focuses on different patterns in the input. Finally, the results from all these parallel heads are combined. This gives the model a much richer understanding of the relationships within the data.

![](https://cdn-images-1.medium.com/max/1600/1*xyfZvm85Psu1pm3eo_UDqQ.png)

Figure 4: Scaled Dot Product and Multi-head Attention — Vaswani et al. (2017). The “h” in multi-head attention represents the number of heads running in parallel.

#### **2. The Encoder**

This has 6 layers, and each layer is made up of 2 sublayers (see figure 2):

* **Multi-head self-attention:** This means each word looks at all the other words in the sentence, including itself, to figure out which ones matter most. This helps the model understand the full context of the input.
* **Feed-forward network (FFN):** A mini neural network applied to each word separately.

The formula `Output = LayerNorm(x + Sublayer(x))` applies to both of these sublayers with the “Sublayer(x)” function either being the multihead self-attention or the FFN.

#### 3. The Decoder

The decoder also has **6 layers**, but with 3 sublayers per layer (also see figure 2):

1. **Masked multi-head self-attention:** Just like the encoder’s, but with a small twist: *masking*. Each word can only look at itself and the ones before it, not the ones ahead. This way, the model doesn’t cheat by seeing future words when generating a sentence.
2. **Cross-attention:** This allows the decoder to look at the *output of the encoder*. This is how the input sequence (e.g., the English sentence) informs the generation of the output sequence (e.g., the German translation).
3. **Feed-forward neural network:** Again, it is an independent network applied to each position in a sequence.

The mathematical representation for one layer of the decoder would be:

```
z1 = LayerNorm(x + MultiHeadMaskedSelfAttention(x))z2 = LayerNorm(z1 + MultiHeadCrossAttention(z1, EncoderOutput))z3 = LayerNorm(z2 + FeedForward(z2))
```

With z3 being the output of the layer. As you can see, it’s still built on the general formula.

#### Other Components (Still Important!)

1. **Feed-forward networks:** Small neural networks that refine the outputs after attention.
2. **Embeddings:** Turn input words into vectors so the model can work with them. The same embedding weights are reused at the end to help predict the output words.
3. **Positional Encoding:** Adds position information to the words/tokens because transformers *process everything in parallel*, and this makes them not take note of order (unlike RNNs, which naturally know/encode order).

***

### Wrapping Up

That’s essentially the summary of the paper. It’s a dense paper, but breaking it down using the *3-pass method* made it much more manageable and, dare I say, enjoyable.

This article is by no means *exhaustive,* as you can still get into the finer details of the paper, but I hope it helps you do that a little easier.

If you’ve been putting off reading this paper or a similar one like I did, here’s your sign to try. Use the *3-pass method*, and feel free to let me know how it goes.

Until next time!

***

### References

1. Attention is all you need [https://arxiv.org/abs/1706.03762](https://arxiv.org/abs/1706.03762)
2. Research That Sticks: The Strategic Framework for Turning Technical and Academic Papers into Lasting Knowledge [https://mblessed.hashnode.dev/research-that-sticks-the-strategic-framework-for-studying-technical-papers](https://mblessed.hashnode.dev/research-that-sticks-the-strategic-framework-for-studying-technical-papers)

<img src="https://cdn-images-1.medium.com/max/1600/1*kL3ilZSFElPb20j9mEO-SQ.jpeg" alt="">
Photo by <a href="https://unsplash.com/@googledeepmind?utm_content=creditCopyText&#x26;utm_medium=referral&#x26;utm_source=unsplash">Google DeepMind</a> on <a href="https://unsplash.com/photos/a-close-up-of-a-green-object-on-a-white-surface-SrLwQZP0_Ec?utm_content=creditCopyText&#x26;utm_medium=referral&#x26;utm_source=unsplash">Unsplash</a>
It’s been almost 2 years since I first encountered the <a href="https://arxiv.org/abs/1706.03762">“Attention is all you need”</a> paper by Vaswani et al. (2017). I’ve mentioned it confidently in a few conversations, but I only just came to understand it enough this month.
<blockquote>
We listen, we don’t judge.
</blockquote>
In all fairness to me, I only started taking my NLP journey seriously late last year, and I’ve had to wade through information overload, hype and a lot of foundational stuff just to get to a point where papers like this finally make proper sense. I even wrote about <a href="https://medium.com/ai-in-plain-english/word2vec-my-rookie-thoughts-on-the-landmark-nlp-paper-5536967a93e2">Word2Vec in my last article</a>; you can check it out.
Before this latest attempt, I had tried several times to read the paper, but it never fully clicked. This time around, I used the <a href="https://mblessed.hashnode.dev/research-that-sticks-the-strategic-framework-for-studying-technical-papers">3-pass technique I saw on Madukoma Blessed’s blog</a>, and I finally got the core message and technical parts.
If you’ve also been putting off reading “scary papers,” maybe this method might help you. Walk with me.
<hr>
<h3 id="the-strategy">The strategy</h3>
The 3-pass method is pretty straightforward.
<ul>
<li>First, you skim and note the overall idea;</li>
<li>Then, you dig a bit deeper for key ideas;</li>
<li>Finally, you go all in on the technical details.</li>
</ul>
It helps to ease into tough papers without burning out. And that’s exactly what I did. As you read further, I’ll detail my learnings in bullet points under each pass.
<hr>
<h3 id="some-information">Some information…</h3>
To help you understand the notes in the rest of the article, you need to be familiar with a few things, like RNNs, CNNs and Sequence transduction models (like Seq2Seq). You don’t have to cram the math. Just get the general idea.
<ul>
<li>RNNs (Recurrent Neural Networks):
They process data step by step, passing information from one step to the next. Think of them like reading a sentence one word at a time, remembering what came before. They’re great at handling sequences, but they can be slow and struggle with long sequences.</li>
<li>CNNs (Convolutional Neural Networks):
Originally built for images, but sometimes used for text too. They focus on learning local patterns. For example, detecting small chunks or phrases in text. They’re faster than RNNs in some cases, but still have limits with longer dependencies.</li>
<li>Sequence transduction models (like Seq2Seq models):
These models take in a sequence and produce another sequence. Classic examples? Translation and summarisation. You give it a sentence, and it outputs a new sentence in another language or a shorter version.</li>
</ul>
If these still feel confusing, it might be helpful to pause and brush up a little more on NLP basics first. And that’s perfectly okay. Been there, done that. 2 years hello?!
<blockquote>
Maybe still a little there to be honest.
</blockquote>
<hr>
<h3 id="pass-1-skimming-and-wait-thatswhy">Pass 1: Skimming and “Wait, that’s why?!”</h3>
<ul>
<li>The whole point of the paper is this: What if we stopped using complicated stuff like RNNs and CNNs to build sequence transduction models and just used attention instead?</li>
<li>To prove this idea, they introduced a new architecture called the Transformer, which was built solely with the attention mechanism, without any recurrence or convolutions.</li>
<li>It worked and proved to be more efficient than the State-of-The-Art (SOTA) models at the time, using BLEU scores as the evaluation metric.</li>
<li>Hence, attention is all you really need. How did I not get that since?!</li>
</ul>
<blockquote>
PS. Weirdly enough, I finally learnt the meaning of SOTA, and I’m feeling like a cool “kid”. Time to not-so-casually throw it around in conversations.
</blockquote>
<hr>
<h3 id="pass-2-key-ideas--takeaways">Pass 2: Key Ideas &#x26; Takeaways</h3>
<h4 id="the-old-way-before-thispaper">The Old Way (Before This Paper)</h4>
<ul>
<li>Sequence models (like for translation) were usually built using encoders and decoders made up of RNNs (like LSTMs or GRUs), sometimes in combination with CNNs or the attention mechanism.</li>
<li>While they worked, they had a major bottleneck: They processed data step by step, meaning one word at a time.</li>
<li>This was not-so-great for modern hardware (GPUs, TPUs) designed for parallel processing. Longer sequences meant more memory, more time, and endless waiting.</li>
<li>Even with tricks, you were stuck in a step-by-step loop.</li>
</ul>
<h4 id="the-new-way-the-transformer">The New Way (The Transformer)</h4>
This improved architecture meant:
<ul>
<li>Full parallelisation during training: You can process everything at once, instead of waiting for previous steps.</li>
<li>Faster training and better performance.</li>
</ul>
<h4 id="their-results">Their Results?</h4>
<ul>
<li>The transformer beat older models on English-to-German and English-to-French translation tasks.</li>
<li>They used multiple attention heads (8 in the base model), which helped capture different patterns in the data.</li>
<li>Dropout helped prevent overfitting.</li>
<li>They also tested a version of the model on an English parsing task, showing it could generalise beyond translation.</li>
</ul>
<h4 id="side-note">Side Note</h4>
Although training is now fully parallel, generating text (output) still happens one word at a time (sequentially). They mentioned this as a future challenge. The authors also acknowledged that it’s text-based only (no multimodal yet, or at least, as at the time).
<img src="https://cdn-images-1.medium.com/max/1600/1*HRAkxXY1eXLD-pii7Mt8SQ.jpeg" alt="">
Figure 1: This was my understanding after pass 2
<hr>
<h3 id="pass-3-breaking-down-the-model-architecture">Pass 3: Breaking Down the Model Architecture</h3>
I focused on Sections 3 and 4 of the paper, which describe the components of the architecture in detail. The Transformer, like older seq2seq models, has an encoder and a decoder. Both are made of layers, and those layers have sublayers. A formula for calculating the output of a sublayer of either the encoder or decoder is:
<pre><code class="code-highlight">Output = LayerNorm(x + Sublayer(x))
</code></pre>
where:
<ul>
<li>x is the input to the sublayer.</li>
<li>Sublayer(x) is the actual computation (e.g., attention, feed-forward network).</li>
<li>x + Sublayer(x) is called a residual connection, a fancy term for adding the input back to the output of the sublayer. It's crucial for stable training and optimisation in deep networks.</li>
<li>LayerNorm() is Layer Normalisation, which is applied for stability after adding the input back.</li>
</ul>
<h4 id="now-lets-look-at-the-core-components-of-the-transformer">Now, let’s look at the core components of the Transformer</h4>
<img src="https://cdn-images-1.medium.com/max/1600/1*LFw8HnqV1ddxAZ0Kv38ngw.png" alt="">
Figure 2: The Transformer architecture with its components — Vaswani et al. (2017). One encoder layer on the left, one decoder layer on the right. The Nx represents the fact that there are multiple (N=6) layers.
<h4 id="1-attention-star-of-theshow">1. Attention (Star of the show)</h4>
Attention is essentially a way to map a query and a set of key-value pairs to an output. It helps the model “focus” or “pay attention” to a specific part of a sequence. The paper focuses on two key types:
<img src="https://cdn-images-1.medium.com/max/1600/1*i9kOSH57xZZ11HodlHiQTw.png" alt="">
Figure 3: Screenshot from my Notion notes
Why the emphasis on self-attention in the paper?
<ol>
<li>Faster and more parallelisable.</li>
<li>Learns long-distance relationships better.</li>
<li>Easier to visualise and interpret.</li>
</ol>
In the paper, they also discussed two techniques to calculate attention:
<ul>
<li>Scaled Dot-Product Attention: 
This is the core mathematical operation. It takes three matrices: Q (queries), K (keys), and V (values). Each row of the matrices represents a token in the sequence. The formula is as follows:</li>
</ul>
<pre><code class="code-highlight">Attention(Q, K, V) = softmax(QKᵀ / √dₖ) · V
</code></pre>
<ul>
<li>
Multi-head Attention:
Instead of just one attention calculation, it runs multiple scaled dot-product attentions in parallel,**** called heads. It doesn’t just split the input; it creates different learned projections (like different “views” or “perspectives”) of Q, K, and V for each “head.”
Each head focuses on different patterns in the input. Finally, the results from all these parallel heads are combined. This gives the model a much richer understanding of the relationships within the data.
</li>
</ul>
<img src="https://cdn-images-1.medium.com/max/1600/1*xyfZvm85Psu1pm3eo_UDqQ.png" alt="">
Figure 4: Scaled Dot Product and Multi-head Attention — Vaswani et al. (2017). The “h” in multi-head attention represents the number of heads running in parallel.
<h4 id="2-theencoder">2. The Encoder</h4>
This has 6 layers, and each layer is made up of 2 sublayers (see figure 2):
<ul>
<li>Multi-head self-attention: This means each word looks at all the other words in the sentence, including itself, to figure out which ones matter most. This helps the model understand the full context of the input.</li>
<li>Feed-forward network (FFN): A mini neural network applied to each word separately.</li>
</ul>
The formula <code>Output = LayerNorm(x + Sublayer(x))</code> applies to both of these sublayers with the “Sublayer(x)” function either being the multihead self-attention or the FFN.
<h4 id="3-thedecoder">3. The Decoder</h4>
The decoder also has 6 layers, but with 3 sublayers per layer (also see figure 2):
<ol>
<li>Masked multi-head self-attention: Just like the encoder’s, but with a small twist: masking. Each word can only look at itself and the ones before it, not the ones ahead. This way, the model doesn’t cheat by seeing future words when generating a sentence.</li>
<li>Cross-attention: This allows the decoder to look at the output of the encoder. This is how the input sequence (e.g., the English sentence) informs the generation of the output sequence (e.g., the German translation).</li>
<li>Feed-forward neural network: Again, it is an independent network applied to each position in a sequence.</li>
</ol>
The mathematical representation for one layer of the decoder would be:
<pre><code class="code-highlight">z1 = LayerNorm(x + MultiHeadMaskedSelfAttention(x))z2 = LayerNorm(z1 + MultiHeadCrossAttention(z1, EncoderOutput))z3 = LayerNorm(z2 + FeedForward(z2))
</code></pre>
With z3 being the output of the layer. As you can see, it’s still built on the general formula.
<h4 id="other-components-still-important">Other Components (Still Important!)</h4>
<ol>
<li>Feed-forward networks: Small neural networks that refine the outputs after attention.</li>
<li>Embeddings: Turn input words into vectors so the model can work with them. The same embedding weights are reused at the end to help predict the output words.</li>
<li>Positional Encoding: Adds position information to the words/tokens because transformers process everything in parallel, and this makes them not take note of order (unlike RNNs, which naturally know/encode order).</li>
</ol>
<hr>
<h3 id="wrapping-up">Wrapping Up</h3>
That’s essentially the summary of the paper. It’s a dense paper, but breaking it down using the 3-pass method made it much more manageable and, dare I say, enjoyable.
This article is by no means exhaustive, as you can still get into the finer details of the paper, but I hope it helps you do that a little easier.
If you’ve been putting off reading this paper or a similar one like I did, here’s your sign to try. Use the 3-pass method, and feel free to let me know how it goes.
Until next time!
<hr>
<h3 id="references">References</h3>
<ol>
<li>Attention is all you need <a href="https://arxiv.org/abs/1706.03762">https://arxiv.org/abs/1706.03762</a></li>
<li>Research That Sticks: The Strategic Framework for Turning Technical and Academic Papers into Lasting Knowledge <a href="https://mblessed.hashnode.dev/research-that-sticks-the-strategic-framework-for-studying-technical-papers">https://mblessed.hashnode.dev/research-that-sticks-the-strategic-framework-for-studying-technical-papers</a></li>
</ol>

I Finally Understood “Attention is All You Need” After So Long. Here’s How I Did It.

## **The Hidden Fragility of AI Side Projects**

AI side projects have become the modern developer’s hobby: quick prototypes, clever tools, small automations, and experimental agents built on weekends. Yet despite the creativity behind them, **the vast majority never progress beyond a demo**. Developers frequently underestimate the complexity of scaling AI systems, overestimate model reliability, and misjudge the long-term maintenance cost.

Industry data illustrates this clearly: according to a 2024 GitHub study, **over 82% of AI hobby projects are abandoned within the first three months**. Failures rarely stem from lack of talent; they emerge from structural misconceptions about what it takes to turn an AI idea into a stable, usable product.

This article examines these failure points through the lens of real engineering practice, incorporating technical insights and operational lessons that experienced developers learn through hard-won experience.

## **Misunderstanding the Core Problem**

### **AI Projects Fail When They Solve the Wrong Thing**

Most side projects begin with excitement rather than a validated problem. Developers often think in terms of “what model can I build?” instead of “what pain point deserves solving?” As a result, early enthusiasm produces interesting prototypes that don’t actually map to a consistent use case.

Typical examples include:

* Tools that duplicate features already solved better by existing platforms
* Chatbots that don’t serve a repeatable audience need
* Niche automations used only by the creator
* “Cool ideas” that collapse under real-world complexity

The first expert lesson: **AI is not the product — the problem is the product**.

Without a validated use case, no amount of fine-tuning, vector search, or prompt engineering will matter. Developers often write more code and build more features, hoping the project will find its direction later. It never does.

## **Over-Reliance on Model Output**

### **When Developers Trust AI More Than They Should**

Models appear magical in demos because demos are controlled. The moment an AI tool reaches real-world inputs — messy, ambiguous, or adversarial — the weaknesses appear. Developers frequently underestimate model fragility in five critical areas:

1. **Hallucination risk**
2. **Inconsistent reasoning across similar queries**
3. **Sensitivity to small changes in phrasing**
4. **Dependency on incomplete context**
5. **Silent failure modes**

This is why seasoned developers emphasize strict guardrails, deterministic fallbacks, and structured error handling.

Around the midpoint of many AI workflow discussions, engineers often compare tools for output verification. For example, some developers test their pipelines with solutions such as[ *https://overchat.ai/chat/ai-answer-generator*](https://overchat.ai/chat/ai-answer-generator) to stress-test consistency across prompts. The point is not the tool itself — the point is the engineering principle: **never trust LLM output without controlled evaluation**.

Without these safeguards, seemingly “working” prototypes break instantly when exposed to real users.

## **The Data Problem**

### **When Good Intentions Meet Bad Data**

Another core reason AI side projects fail is that developers underestimate how crucial data quality is. Unlike traditional software, where logic is deterministic, AI systems depend on:

* Clean inputs
* Well-structured context
* Consistent formatting
* Representative examples

Side projects often rely on whatever data the developer has at hand. This leads to issues such as:

* Poor retrieval precision
* Irrelevant context loading
* Outdated datasets
* Lack of domain examples
* Mismatched formats between inputs and expected model behavior

As a result, the model’s performance collapses outside ideal scenarios.

Expert commentary:

In production ML systems, **60–80% of engineering time is spent on data preparation, evaluation, and monitoring** — not on model selection. Developers frequently forget this when building side projects that operate with incomplete or low-quality data.

This mismatch between expectation and reality causes performance to degrade rapidly, leaving the developer unsure where the issue lies.

## **Lack of Proper Evaluation**

### **AI Without Metrics Is a Guessing Game**

Most AI side projects rely on subjective evaluation — “It works for my examples.” This is insufficient for anything beyond a demo.

AI systems require measurable evaluation criteria such as:

* Response accuracy
* Hallucination rate
* Latency under load
* Context window efficiency
* Retrieval relevance (R@k)
* Consistency across paraphrased queries

Without these metrics, developers cannot detect regressions, model drift, or edge cases. A side project that “seems fine” becomes unusable as soon as the input distribution changes.

Experienced AI engineers use standardized testing methods:

* Benchmark datasets
* Monte Carlo prompt variations
* Pinned evaluation queries
* Scenario-based testing
* Golden output sets
*

Because AI behavior is non-deterministic, evaluation is a continuous requirement — not a one-time check.

## **Architectural Mistakes**

### **Poor Foundations Create Unscalable Tools**

AI side projects often begin as single-file scripts or loosely connected utilities. This works initially, but as soon as complexity increases, these projects become impossible to maintain.

Common architectural failures include:

* Hard-coded prompts
* No abstraction layers
* Context-building scattered across files
* Inability to swap models or vectors
* Lack of separation between logic and retrieval
* Manual API calls without error handling
* Prompt chains without observability

AI requires architecture.
&#x20;Without it, even simple tools become fragile.

Expert note:

Every successful AI product has a retrieval layer, a formatting layer, a validation layer, and a feedback layer — even if the prototype didn’t.

Side projects that skip these layers collapse the moment new features are added.

## **Unrealistic Assumptions About Model Costs**

### **AI Projects Fail Financially Long Before They Fail Technically**

Developers often assume they can scale an AI project cheaply, but reality quickly proves otherwise. API usage grows unpredictably as:

* User queries increase
* Context windows expand
* Retrieval calls multiply
* Logging and reranking become essential

A model that costs $20/month to run at low volume can easily cost **$600–$2000/month** when usage grows.

This is why production ML teams monitor:

* Token usage patterns
* Peak vs sustained load
* Context growth over time
* Caching opportunities
* Model selection and downgrading

Side projects fail because developers hit cost ceilings they never anticipated.

## **The Real Killer: Lack of Maintenance Commitment**

### **AI Tools Require More Ongoing Care Than Traditional Software**

Typical software systems degrade slowly; AI systems degrade quickly. Models evolve, APIs change, embeddings shift, and user expectations grow.

AI projects require continuous maintenance:

* Updating prompts as requirements evolve
* Retesting after model updates
* Rebuilding embeddings
* Refreshing datasets
* Monitoring output drift
* Adjusting retrieval pipelines

Most side projects aren’t designed with maintenance in mind, and after a few months, developers lose track of what needs fixing.

According to a 2024 HuggingFace survey, **over 70% of AI projects break at least once due to external changes**, such as model deprecations or API updates.

Side projects fail because their creators never planned for recurring work.

## **Underestimating UX**

### **A Great Model With a Terrible UX Is Still a Failed Project**

Developers love the engine but forget the car. AI output quality matters — but so does everything surrounding it:

* Onboarding experience
* Error messaging
* Response speed
* Input constraints
* User expectations
* Clear instructions
* Interface predictability

Many AI tools fail simply because users don’t know what to input or how to interpret the output.

Even the best reasoning model will disappoint users if the UX makes it difficult to use.

## **Feature Overload**

### **Building Too Much Instead of Building the Right Thing**

Developers frequently build increasingly complex features to impress themselves rather than serve real users. This leads to:

* Fragile prompt chains
* Overly broad capabilities
* Unmaintainable code
* Slow iteration cycles
* Toolkits no one needs

Expert engineering rule:

The more an AI tool tries to do, the worse it becomes at everything.

Side projects succeed only when they solve **one problem extremely well**.

## **The Psychological Factor**

### **Why Developer Motivation Dies Midway**

Finally, the most human reason side projects fail: motivation loss. AI projects feel exciting early on but quickly become tedious as:

* The novelty wears off
* Bugs appear
* Architectural limitations surface
* Edge cases accumulate
* Real users produce unpredictable behavior

This shift from exploration to engineering is where most developers quit.
&#x20;The project stops being fun and starts being work.

## Conclusion: AI Side Projects Don’t Fail — They Fade

AI side projects rarely fail in a dramatic way; they slowly decay. What begins as an exciting experiment becomes a burden of maintenance, evaluation, cost monitoring, and user support.

Yet the developers who succeed are those who:

* Validate their problem early
* Build proper architecture
* Evaluate model behavior systematically
* Plan for ongoing maintenance
* Prioritize UX
* Focus on one clear use case

Turning an AI side project into a real product requires not just creativity, but discipline.
&#x20;That discipline — not the model — is what separates abandoned prototypes from successful tools.

<h2 id="the-hidden-fragility-of-ai-side-projects">The Hidden Fragility of AI Side Projects</h2>
AI side projects have become the modern developer’s hobby: quick prototypes, clever tools, small automations, and experimental agents built on weekends. Yet despite the creativity behind them, the vast majority never progress beyond a demo. Developers frequently underestimate the complexity of scaling AI systems, overestimate model reliability, and misjudge the long-term maintenance cost.
Industry data illustrates this clearly: according to a 2024 GitHub study, over 82% of AI hobby projects are abandoned within the first three months. Failures rarely stem from lack of talent; they emerge from structural misconceptions about what it takes to turn an AI idea into a stable, usable product.
This article examines these failure points through the lens of real engineering practice, incorporating technical insights and operational lessons that experienced developers learn through hard-won experience.
<h2 id="misunderstanding-the-core-problem">Misunderstanding the Core Problem</h2>
<h3 id="ai-projects-fail-when-they-solve-the-wrong-thing">AI Projects Fail When They Solve the Wrong Thing</h3>
Most side projects begin with excitement rather than a validated problem. Developers often think in terms of “what model can I build?” instead of “what pain point deserves solving?” As a result, early enthusiasm produces interesting prototypes that don’t actually map to a consistent use case.
Typical examples include:
<ul>
<li>Tools that duplicate features already solved better by existing platforms</li>
<li>Chatbots that don’t serve a repeatable audience need</li>
<li>Niche automations used only by the creator</li>
<li>“Cool ideas” that collapse under real-world complexity</li>
</ul>
The first expert lesson: AI is not the product — the problem is the product.
Without a validated use case, no amount of fine-tuning, vector search, or prompt engineering will matter. Developers often write more code and build more features, hoping the project will find its direction later. It never does.
<h2 id="over-reliance-on-model-output">Over-Reliance on Model Output</h2>
<h3 id="when-developers-trust-ai-more-than-they-should">When Developers Trust AI More Than They Should</h3>
Models appear magical in demos because demos are controlled. The moment an AI tool reaches real-world inputs — messy, ambiguous, or adversarial — the weaknesses appear. Developers frequently underestimate model fragility in five critical areas:
<ol>
<li>Hallucination risk</li>
<li>Inconsistent reasoning across similar queries</li>
<li>Sensitivity to small changes in phrasing</li>
<li>Dependency on incomplete context</li>
<li>Silent failure modes</li>
</ol>
This is why seasoned developers emphasize strict guardrails, deterministic fallbacks, and structured error handling.
Around the midpoint of many AI workflow discussions, engineers often compare tools for output verification. For example, some developers test their pipelines with solutions such as<a href="https://overchat.ai/chat/ai-answer-generator"> https://overchat.ai/chat/ai-answer-generator</a> to stress-test consistency across prompts. The point is not the tool itself — the point is the engineering principle: never trust LLM output without controlled evaluation.
Without these safeguards, seemingly “working” prototypes break instantly when exposed to real users.
<h2 id="the-data-problem">The Data Problem</h2>
<h3 id="when-good-intentions-meet-bad-data">When Good Intentions Meet Bad Data</h3>
Another core reason AI side projects fail is that developers underestimate how crucial data quality is. Unlike traditional software, where logic is deterministic, AI systems depend on:
<ul>
<li>Clean inputs</li>
<li>Well-structured context</li>
<li>Consistent formatting</li>
<li>Representative examples</li>
</ul>
Side projects often rely on whatever data the developer has at hand. This leads to issues such as:
<ul>
<li>Poor retrieval precision</li>
<li>Irrelevant context loading</li>
<li>Outdated datasets</li>
<li>Lack of domain examples</li>
<li>Mismatched formats between inputs and expected model behavior</li>
</ul>
As a result, the model’s performance collapses outside ideal scenarios.
Expert commentary:
In production ML systems, 60–80% of engineering time is spent on data preparation, evaluation, and monitoring — not on model selection. Developers frequently forget this when building side projects that operate with incomplete or low-quality data.
This mismatch between expectation and reality causes performance to degrade rapidly, leaving the developer unsure where the issue lies.
<h2 id="lack-of-proper-evaluation">Lack of Proper Evaluation</h2>
<h3 id="ai-without-metrics-is-a-guessing-game">AI Without Metrics Is a Guessing Game</h3>
Most AI side projects rely on subjective evaluation — “It works for my examples.” This is insufficient for anything beyond a demo.
AI systems require measurable evaluation criteria such as:
<ul>
<li>Response accuracy</li>
<li>Hallucination rate</li>
<li>Latency under load</li>
<li>Context window efficiency</li>
<li>Retrieval relevance (R@k)</li>
<li>Consistency across paraphrased queries</li>
</ul>
Without these metrics, developers cannot detect regressions, model drift, or edge cases. A side project that “seems fine” becomes unusable as soon as the input distribution changes.
Experienced AI engineers use standardized testing methods:
<ul>
<li>Benchmark datasets</li>
<li>Monte Carlo prompt variations</li>
<li>Pinned evaluation queries</li>
<li>Scenario-based testing</li>
<li>Golden output sets</li>
<li></li>
</ul>
Because AI behavior is non-deterministic, evaluation is a continuous requirement — not a one-time check.
<h2 id="architectural-mistakes">Architectural Mistakes</h2>
<h3 id="poor-foundations-create-unscalable-tools">Poor Foundations Create Unscalable Tools</h3>
AI side projects often begin as single-file scripts or loosely connected utilities. This works initially, but as soon as complexity increases, these projects become impossible to maintain.
Common architectural failures include:
<ul>
<li>Hard-coded prompts</li>
<li>No abstraction layers</li>
<li>Context-building scattered across files</li>
<li>Inability to swap models or vectors</li>
<li>Lack of separation between logic and retrieval</li>
<li>Manual API calls without error handling</li>
<li>Prompt chains without observability</li>
</ul>
AI requires architecture.
Without it, even simple tools become fragile.
Expert note:
Every successful AI product has a retrieval layer, a formatting layer, a validation layer, and a feedback layer — even if the prototype didn’t.
Side projects that skip these layers collapse the moment new features are added.
<h2 id="unrealistic-assumptions-about-model-costs">Unrealistic Assumptions About Model Costs</h2>
<h3 id="ai-projects-fail-financially-long-before-they-fail-technically">AI Projects Fail Financially Long Before They Fail Technically</h3>
Developers often assume they can scale an AI project cheaply, but reality quickly proves otherwise. API usage grows unpredictably as:
<ul>
<li>User queries increase</li>
<li>Context windows expand</li>
<li>Retrieval calls multiply</li>
<li>Logging and reranking become essential</li>
</ul>
A model that costs $20/month to run at low volume can easily cost $600–$2000/month when usage grows.
This is why production ML teams monitor:
<ul>
<li>Token usage patterns</li>
<li>Peak vs sustained load</li>
<li>Context growth over time</li>
<li>Caching opportunities</li>
<li>Model selection and downgrading</li>
</ul>
Side projects fail because developers hit cost ceilings they never anticipated.
<h2 id="the-real-killer-lack-of-maintenance-commitment">The Real Killer: Lack of Maintenance Commitment</h2>
<h3 id="ai-tools-require-more-ongoing-care-than-traditional-software">AI Tools Require More Ongoing Care Than Traditional Software</h3>
Typical software systems degrade slowly; AI systems degrade quickly. Models evolve, APIs change, embeddings shift, and user expectations grow.
AI projects require continuous maintenance:
<ul>
<li>Updating prompts as requirements evolve</li>
<li>Retesting after model updates</li>
<li>Rebuilding embeddings</li>
<li>Refreshing datasets</li>
<li>Monitoring output drift</li>
<li>Adjusting retrieval pipelines</li>
</ul>
Most side projects aren’t designed with maintenance in mind, and after a few months, developers lose track of what needs fixing.
According to a 2024 HuggingFace survey, over 70% of AI projects break at least once due to external changes, such as model deprecations or API updates.
Side projects fail because their creators never planned for recurring work.
<h2 id="underestimating-ux">Underestimating UX</h2>
<h3 id="a-great-model-with-a-terrible-ux-is-still-a-failed-project">A Great Model With a Terrible UX Is Still a Failed Project</h3>
Developers love the engine but forget the car. AI output quality matters — but so does everything surrounding it:
<ul>
<li>Onboarding experience</li>
<li>Error messaging</li>
<li>Response speed</li>
<li>Input constraints</li>
<li>User expectations</li>
<li>Clear instructions</li>
<li>Interface predictability</li>
</ul>
Many AI tools fail simply because users don’t know what to input or how to interpret the output.
Even the best reasoning model will disappoint users if the UX makes it difficult to use.
<h2 id="feature-overload">Feature Overload</h2>
<h3 id="building-too-much-instead-of-building-the-right-thing">Building Too Much Instead of Building the Right Thing</h3>
Developers frequently build increasingly complex features to impress themselves rather than serve real users. This leads to:
<ul>
<li>Fragile prompt chains</li>
<li>Overly broad capabilities</li>
<li>Unmaintainable code</li>
<li>Slow iteration cycles</li>
<li>Toolkits no one needs</li>
</ul>
Expert engineering rule:
The more an AI tool tries to do, the worse it becomes at everything.
Side projects succeed only when they solve one problem extremely well.
<h2 id="the-psychological-factor">The Psychological Factor</h2>
<h3 id="why-developer-motivation-dies-midway">Why Developer Motivation Dies Midway</h3>
Finally, the most human reason side projects fail: motivation loss. AI projects feel exciting early on but quickly become tedious as:
<ul>
<li>The novelty wears off</li>
<li>Bugs appear</li>
<li>Architectural limitations surface</li>
<li>Edge cases accumulate</li>
<li>Real users produce unpredictable behavior</li>
</ul>
This shift from exploration to engineering is where most developers quit.
The project stops being fun and starts being work.
<h2 id="conclusion-ai-side-projects-dont-fail--they-fade">Conclusion: AI Side Projects Don’t Fail — They Fade</h2>
AI side projects rarely fail in a dramatic way; they slowly decay. What begins as an exciting experiment becomes a burden of maintenance, evaluation, cost monitoring, and user support.
Yet the developers who succeed are those who:
<ul>
<li>Validate their problem early</li>
<li>Build proper architecture</li>
<li>Evaluate model behavior systematically</li>
<li>Plan for ongoing maintenance</li>
<li>Prioritize UX</li>
<li>Focus on one clear use case</li>
</ul>
Turning an AI side project into a real product requires not just creativity, but discipline.
That discipline — not the model — is what separates abandoned prototypes from successful tools.

Explore why many AI side projects collapse despite strong ideas. Learn how data issues, weak architecture, poor evaluation, and high maintenance demands lead developers to abandon promising tools.

Why Most AI Side Projects Fail — A Developer’s Perspective

Discover 7 top generative AI development services that deliver custom AI solutions to streamline operations, cut costs, and drive innovation

7 Generative AI Development Services That Help Maximize Efficiency

7 Generative AI Development Services That Maximize Efficiency

Why Developers Should Stop Fearing AI and Start Building With It

 How Developers Can Take Their First Steps Into AI-Powered Apps

Access the Nano Banana API on Kie.ai, powered by Google's Gemini 2.5 Flash Image, with affordable pricing for AI image generation, editing, and seamless integration.

Kie.ai's Nano Banana API: Affordable AI Image Generation and Editing for Developers

How to Use AI: A Beginner's Guide

Talking photos are a massive leap in digital expression, completely changing how we create, consume, and interact with entertainment. From making historical figures speak to generating dynamic marketing content and pushing comedy boundaries, their impact is clear. Platforms like JoggAI are showing us just how much creative freedom and accessibility this tech brings.

Talking Photos: The Wild New World of Entertainment

VocaTalk is an innovative app for learning English with the help of artificial intelligence. It offers real-time dialogues tailored to the user's language level, feedback after each session with AI evaluation of the conversation, and multilingual interface and hints in the 7 most widely spoken languages.

Artificial Intelligence

I Replaced Cursor Agent with Claude Code, Here’s What Happened

I Finally Understood “Attention is All You Need” After So Long. Here’s How I Did It.

Why Most AI Side Projects Fail — A Developer’s Perspective

7 Generative AI Development Services That Maximize Efficiency

Why Developers Should Stop Fearing AI and Start Building With It

How Developers Can Take Their First Steps Into AI-Powered Apps

Kie.ai's Nano Banana API: Affordable AI Image Generation and Editing for Developers

How to Use AI: A Beginner's Guide

Talking Photos: The Wild New World of Entertainment

VocaTalk: How an Experienced iOS Engineer Built an AI-Powered English Speaking Trainer Using Google Gemini

Main Menu

Follow Us

Artificial Intelligence

I Replaced Cursor Agent with Claude Code, Here’s What Happened

I Finally Understood “Attention is All You Need” After So Long. Here’s How I Did It.

Why Most AI Side Projects Fail — A Developer’s Perspective

7 Generative AI Development Services That Maximize Efficiency

Why Developers Should Stop Fearing AI and Start Building With It

How Developers Can Take Their First Steps Into AI-Powered Apps

Kie.ai's Nano Banana API: Affordable AI Image Generation and Editing for Developers

How to Use AI: A Beginner's Guide

Talking Photos: The Wild New World of Entertainment

VocaTalk: How an Experienced iOS Engineer Built an AI-Powered English Speaking Trainer Using Google Gemini