DEV Community: Syed Ahmer Shah

I Tested 8 Best AI Design Tools for UI/UX with the Same Prompt

Syed Ahmer Shah — Mon, 27 Jul 2026 07:25:05 +0000

AI design tools have gone from generating blurry wireframe suggestions to shipping functional, multi-screen app prototypes with consistent design tokens in one prompt. The pace of change is almost disorienting. So I ran a controlled test: the exact same detailed prompt, eight tools, one afternoon.

The prompt asked each tool to generate a three-screen Personal Habit Tracker mobile app — a Daily Dashboard, a Progress Analytics screen, and an Add Habit form — with modern minimalist UI, accessible contrast ratios, consistent design tokens, and output structured for code export. The constraints were tight on purpose. Vague prompts forgive mediocre tools. A specific one exposes them.

Here is what I found, tool by tool.

The Prompt

"Design a clean, modern, high-contrast mobile app UI for a 'Personal Habit Tracker'. Generate 3 connected mobile screens with high visual hierarchy, modern UI components, and accessible spacing: (1) Daily Dashboard — streak counter, weekly date strip, circular completion ring, actionable habit list; (2) Progress Analytics — metrics header, bar chart with weekly/monthly toggle, monthly consistency heatmap; (3) Add Habit screen — name/description inputs, icon & color picker, frequency selector, category tags, Save CTA. Mobile-first, consistent design tokens, structured for code export."

1. Flowstep

First Impression: Flowstep pitches itself as a "design engineer" — and that positioning is accurate in the best way. The chat-left, infinite-canvas-right layout feels immediately productive, less like a blank page and more like pairing with a designer who already understands component logic.

UI/UX Analysis: The output was structurally strong and visually polished. Screen 1 delivered the date strip, circular progress ring (100% completion), and an actionable habit list. Screen 2 produced a clean bar chart analytics view and a compact monthly consistency heatmap grid. Screen 3 included a complete form with icon/color selections, frequency toggles, and category chips. The overall layout features clear visual hierarchy, generous spacing, and a modern primary accent color system applied consistently across all screens.

Pros:

Fast, competent multi-screen output
Strong structural hierarchy and component logic
Figma copy-paste integration works without plugins
It supports live interactive multi-screen prototyping, allowing users to click through connected user journeys.
It exports React, TypeScript, and Tailwind CSS

Cons:

Free tier is limited; Starter plan starts at $15/month
Generation credits can burn quickly during rapid multi-screen iterations

Code Export & Developer Readiness: React component export is available and the code output is production-intended — not just visual reference.

Verdict: Best for product designers who want a fast, styled multi-screen first draft with a clean path into Figma or code.

2. Figma Make

First Impression: Figma Make is the only tool in this test that lives inside a design tool professionals already use daily. That ecosystem advantage is enormous. It also comes with a notable asterisk: during testing, I hit a "Something went wrong" generation error on the Add Habit screen — a rough edge on a tool from the company that literally defines design tooling.

UI/UX Analysis: Where it worked, it worked well. The Daily Dashboard screen delivered a dark-mode interface with a rich teal-green accent, iOS status bar, weekly date strip with activity dots, and a compact circular score widget. Habit cards show category labels inline (Health, Fitness, Productivity), which is a smart UX decision almost no other tool made. The Create New Habit screen, when it rendered, had a proper icon picker grid, color swatch row, and frequency pills on a dark surface with tight, consistent spacing. The design system coherence across screens was the best among tools that output design-file artifacts rather than live apps — which makes sense, given the Figma ecosystem it's native to.

Pros:

Lives in Figma — zero context switch for design teams
Can reference existing design libraries and variables
Dark mode output has genuine visual polish
Config 2026 updates added code layers, GitHub sync, and visual code editing

Cons:

Generation errors under load are a real workflow interruption
Currently a context switch from the main Figma editor (separate experience)
Error recovery requires reprompting from scratch

Code Export & Developer Readiness: Strong. Dev Mode, code layers (now with GitHub import), and MCP compatibility make this the most developer-integrated option for teams already on Figma's paid plans.

Verdict: Best for design teams already in Figma who want AI generation that respects their existing system.

3. Google Stitch

First Impression: Stitch (acquired from Galileo AI by Google in mid-2025, relaunched at I/O 2025 with Gemini underneath) is the biggest surprise of this test. It's free, runs entirely in the browser, and its design output is the most polished of any purely visual tool I tested.

UI/UX Analysis: The generated design system was the standout moment. Before rendering screens, Stitch surfaced a full token panel — type scale, button variants, a five-color swatch system — anchored in a bold indigo primary with success-green accents. The Daily Dashboard shows a clear progress ring (80% / 4/5 habits done), a weekly date strip with the current day filled, and habit cards using coloured circular avatars with category icons. The Progress Analytics screen has three metric cards (124 completed, 88% rate, 22-day streak), a Completion Trends chart with Weekly/Monthly toggle, and a July 2026 consistency heatmap with intensity-coded cells. The Create New Habit screen uses pill-style selectors for frequency and multi-select category chips. Across all three screens, the spacing, type scale, and colour application are consistent — which is rare.

Pros:

Completely free (with monthly generation limits)
Best out-of-the-box design system coherence
Exports to Figma layers, HTML/CSS, and React
Multi-screen consistency is a genuine differentiator

Cons:

Google Labs product — no guaranteed long-term commitment
Editing workflow is less intuitive than dedicated design tools
Generation limits can be a constraint for teams with high volume

Code Export & Developer Readiness: Figma export plus HTML/Tailwind and React options. The March 2026 (Stitch 2.0) update significantly improved multi-screen export fidelity.

Verdict: Best for early-stage founders and PMs who need high-quality mockups fast, for free.

4. Base44

First Impression: Base44 doesn't generate mockups. It builds apps. That distinction matters here, because when the prompt said "structured for code export," Base44 took it literally — it shipped a deployed, navigable habit tracker with a live URL.

UI/UX Analysis: The app quality is genuinely impressive for a single prompt. The Daily Dashboard renders with a purple-to-pink gradient circular progress ring (5/5 · 100%), a weekly date strip with THU 23 highlighted in violet, and individual habit cards each with a colour-coded circle checkmark. The Analytics screen has stat cards (48 completed, 100% rate, 14-day streak), a bar chart with the current day highlighted in purple, and a full July 2026 calendar heatmap using green intensity cells — a small but accurate design choice that most mockup tools ignored. The Add Habit screen has an eight-icon grid, six colour swatches, Daily/Weekly/Custom frequency pills, and four category chips (Health, Fitness, Productivity, Mindfulness). The visual language is consistent across routes. The limitation is that it's a web app, not a native mobile frame — the mobile-first constraint was interpreted as responsive web rather than iOS/Android pixel spec.

Pros:

Outputs a real, deployed app — not a mockup
Consistent design system across all three screens
Built-in backend, auth, and hosting (Wix infrastructure post-acquisition)
Fastest path from prompt to working product

Cons:

Code export locked behind Builder plan ($40/month)
Frontend-only export — backend stays on Base44's infrastructure
No native mobile frame or App Store-ready output

Code Export & Developer Readiness: Frontend React export via GitHub integration on Builder+ plans. Full backend is proprietary (a meaningful lock-in consideration).

Verdict: Best for non-technical founders who want a working product, not a prototype.

5. Bolt.new

First Impression: Bolt renders inside a phone frame mockup, which immediately grounds you in the mobile-first context. The presentation layer is smart UX on Bolt's part — it forces both the tool and the user to think in device constraints.

UI/UX Analysis: The "Habitly" app output had the cleanest light-mode design of the entire test. The Daily Dashboard shows a blue circular progress ring with a weekly date strip that uses coloured status dots under each day — a compact but effective calendar metaphor. The habit list cards include inline category labels (Health, Fitness, Productivity) and time indicators. The Analytics screen has three metric cards (186 completed, 87%, 21-day streak), a "Completion Rate Last 7 Days" bar chart with percentage labels, and a March Heatmap using a blue intensity scale. The Add Custom Habit screen has eight icon options, six colour circles, and a frequency row — clean and usable. Navigation across all three is functional via the simulated phone. Where Bolt falls short slightly is in the analytics section: bar chart bars are text-only (no visual heights rendered), which is a rendering limitation.

Pros:

Phone frame presentation is excellent for stakeholder demos
Clean light-mode design system with consistent type and spacing
All three screens navigable in a single prototype
Good category labelling on habit cards

Cons:

Bar chart in Analytics screen rendered without visual bar heights
Lighter on custom design tokens — closer to Material defaults
Code quality can be verbose; clean-up often needed

Code Export & Developer Readiness: Full React/Vite source code accessible immediately. One of the strongest developer handoff experiences in this test.

Verdict: Best for frontend developers who want a navigable prototype with exportable React code in one shot.

6. Replit Agent

First Impression: Replit Agent called its project "Habit Compass" without being asked — a sign the agent is interpreting intent, not just instructions. It also explained its plan in clear steps before building, which builds trust during a longer generation cycle.

UI/UX Analysis: The dark near-black design with electric indigo accent is the most intentional aesthetic of the dark-mode tools. The Daily Dashboard canvas view shows "Alex Chen" with a 14-Day badge, date strip with today highlighted, a large 4/5 circular progress ring at 80%, and habit cards with coloured icons and timestamps. The Progress Analytics screen shows three metrics (127 total, 84% rate, 21-day streak), a custom bar chart with Weekly/Monthly toggle, and a July 2026 heatmap with intensity-coded cells. The Create Habit form has a Lucide icon row, colour swatches, Daily/Weekly/Custom frequency pills, and category chips. Replit presents all three screens simultaneously on a canvas — which makes design consistency review effortless. The shared design system (CSS variables, shared mobile frame wrapper, floating bottom nav) across screens is thorough. The one gap: the "Create Habit" screen scrolls, and the Frequency row was cut off in the canvas view.

Pros:

Intentional dark design aesthetic, not just dark defaults
Presents all three screens on a live canvas simultaneously
Shared CSS token system across screens
Agent thinking/planning step adds clarity to the build process

Cons:

Slower generation than most tools (6+ minutes)
29% free credit limit — expensive to iterate
Some UI elements clipped in canvas presentation

Code Export & Developer Readiness: Full source code access; HTML/CSS/JS or React depending on how the agent structures it. Good code quality, but requires a paid plan for serious iteration.

Verdict: Best for technical founders who want agentic building with full code access and a strong dark design system.

7. v0 by Vercel

First Impression: v0 presents output as three phone mockups side by side with labels below each ("Daily Dashboard," "Progress Analytics," "Add New Habit") — a gallery view that makes design review fast and stakeholder communication easy.

UI/UX Analysis: The dark theme with a clean green accent is well-executed. The Daily Dashboard shows "Maya Chen" with a 14-day streak badge, weekly date strip, and a prominent 80% / 4/5 Done circular ring with motivational copy ("Keep going, almost there.") — a small but effective UX touch none of the other tools included. The Progress Analytics screen has three clean metric cards (312 habits, 87% rate, 48-day streak), a Completion bar chart with Weekly/Monthly toggle, and a Consistency heatmap using unlabelled intensity cells. The Add New Habit screen is the most thorough in the test: it has an icon row, colour swatches (green, blue, orange, purple, red, yellow), frequency pills (Daily/Weekly/Custom), and individual day toggles (M–T–W–T–F–S–S) which no other tool rendered correctly. The design is the most Tailwind-native in the group, which is entirely appropriate given v0's Vercel/shadcn DNA.

Pros:

Best Add Habit form — day toggles plus frequency pills correctly rendered
Motivational UX copy on Dashboard (a unique touch)
Three-screen gallery view is excellent for review
Tight shadcn/ui component alignment for React developers

Cons:

Dark mode only — no light/dark toggle
Heatmap cells unlabelled (no legend visible)
Less autonomy than Base44 or Replit for non-technical users

Code Export & Developer Readiness: The strongest in the test for React developers. Output is shadcn/ui + Tailwind — paste-and-go for Next.js projects.

Verdict: Best for React/Next.js developers building production UI against the shadcn ecosystem.

8. Lovable

First Impression: Lovable made a choice no other tool made: it gave the app a personality. The homepage reads "Today's rituals." in a bold serif italic, the score card uses a black panel with lime-green accent, and the "Create a new ritual." form header uses the same editorial voice. This is the only output in the test that felt like it came from a brand, not a template.

UI/UX Analysis: The "Habit Spark" dashboard is visually distinctive. A black score card (80% / 4 of 5 habits done) sits against a light background, with green checkmarks on each habit card. The weekly date strip is clean, Thursday 14 is highlighted, and the habit list includes inline category labels (Health, Fitness, Mind, Mindfulness, Recovery). The Create New Habit screen carries the same personality — "Create a new ritual." as a heading, with a lime-green accent on the currently selected habit card preview, and icon/color/frequency selectors below. The design system is the most editorially considered, but it also comes with trade-offs: the lime/black contrast is striking but polarising, and the serif italic may not suit every brand's voice.

Pros:

Most distinctive visual identity of any tool tested
Editorial typography choices create genuine personality
Full-stack generation (Supabase integration, React, auth)
GitHub sync on all plans — full code portability

Cons:

Only 1.30 free credits remaining after a single prompt — very limited free tier
Design aesthetic is opinionated; not a neutral starting point
Less structured for pure design-file handoff

Code Export & Developer Readiness: Excellent. React + TypeScript, Supabase backend, full GitHub sync, and Tailwind. The best developer portability of the full-stack tools.

Verdict: Best for SaaS founders who want a full-stack MVP with a memorable brand identity from day one.

Final Summary & Tool Overview

Flowstep: Best for fast multi-screen UI generation on an infinite canvas. Key advantages include native copy-paste export to Figma without plugins, live interactive prototype flows, production React, TypeScript, and Tailwind CSS code export.
Google Stitch: Best for structured design token generation, offering automated color palettes, typography scales, and multi-screen export to Figma layers, HTML/Tailwind, and React.
v0 by Vercel: Best for generating React components optimized specifically for Next.js, Tailwind CSS, and shadcn/ui design systems.
Figma Make: Best for teams operating directly inside the Figma ecosystem, leveraging existing design system variables, code layers, and Dev Mode workflows.
Bolt.new: Best for previewing multi-screen mobile flows inside a device frame with instant React and Vite source code handoff.
Base44: Best for generating deployed web applications with integrated backend infrastructure, authentication, and live hosted URLs.
Replit Agent: Best for full-stack agentic web development featuring dark-mode design systems and direct source code access.
Lovable: Best for full-stack React and Supabase web applications requiring opinionated brand styling, custom typography, and continuous GitHub sync.

Tested in July 2026. Pricing and features change frequently — verify current plans on each tool's pricing page before committing.

References

McCulloch, W. & Pitts, W. (1943). A Logical Calculus of the Ideas Immanent in Nervous Activity.
Rumelhart, D., Hinton, G., & Williams, R. (1986). Learning Representations by Back-Propagating Errors. Nature.
Krizhevsky, A., Sutskever, I., & Hinton, G. (2012). ImageNet Classification with Deep Convolutional Neural Networks (AlexNet).
Vaswani, A. et al. (2017). Attention Is All You Need. Google Research / NeurIPS.
Lewis, P. et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. Facebook AI Research.
Wei, J. et al. (2022). Chain-of-Thought Prompting Elicits Reasoning in Large Language Models. Google Research.
VentureBeat (March 31, 2026). Claude Code's source code appears to have leaked: here's what we know.
Zscaler Security Research (2026). Anthropic Claude Code Leak — Critical AI Security Threat 2026.
DEV Community (April 1, 2026). The Great Claude Code Leak of 2026.
Tom's Guide (2026). Your Claude chats are being used to train AI — here's how to opt out.
MPG ONE (2026). Does Anthropic Train Claude on Your Data? Full Answer.

Find me across the web:

Portfolio: ahmershah.dev
Crunchbase: @syed-ahmer-shah
LinkedIn: Syed Ahmer Shah
GitHub: @ahmershahdev
AWS Builder Profile: @syedahmershah
DEV.to: @syedahmershah
Medium: @syedahmershah
Hashnode: @syedahmershah
Substack: @syedahmershah
HackerNoon: @syedahmershah
Substack: @syedahmershah
Facebook: @ahmershahdev
Linkedin Page: @syedahmershah
YouTube: @ahmershahdev
Instagram: @ahmershahdev
TikTok: @ahmershahdev

The Anatomy of AI: Deconstructing the "Brain" Into Vectors and Math

Syed Ahmer Shah — Fri, 17 Jul 2026 20:13:32 +0000

"There is no ghost in the machine. There is only linear algebra, wearing a very convincing costume."

Every time someone calls an AI system "smart," a mathematician somewhere sighs quietly into their coffee. Not because it's wrong exactly — but because the truth is both less mystical and more impressive. There is no brain in a data center. There is no understanding in the human sense. What exists is an obscene amount of arithmetic, arranged with enough care that it starts producing outputs that look like thought. This article opens the hood. No metaphors about "digital consciousness," no science-fiction hand-waving — just the actual anatomy: the vectors, the matrices, the pipelines, and the very real, very current controversies around how these systems are built, trained, and occasionally leaked onto the public internet.

1. What Is AI, Really?

1.1 A Working Definition

Artificial Intelligence, stripped of marketing language, is the field of building systems that perform tasks which normally require human cognition — recognizing patterns, generating language, making predictions, or acting on incomplete information. Modern AI, and specifically the kind that writes your emails and argues with you about semicolons, is built almost entirely on a subfield called machine learning (ML), and within that, a further subfield called deep learning.

The distinction matters:

Classical AI (1950s–1980s) relied on hand-coded rules — if X, then Y logic trees written by humans. This is often called "symbolic AI" or "Good Old-Fashioned AI" (GOFAI).
Machine Learning flips this: instead of writing the rules, you show the system enormous amounts of data and let it derive the rules statistically.
Deep Learning is machine learning using multi-layered artificial neural networks — the "deep" refers to the number of layers, not the profundity of the output (a distinction the industry conveniently forgets when writing marketing copy).

1.2 A Brief History — From Dartmouth to Deep Learning

The term "Artificial Intelligence" was coined in 1956 at the Dartmouth Summer Research Project, organized by John McCarthy, Marvin Minsky, Nathaniel Rochester, and Claude Shannon. The proposal, with almost comic optimism, stated that "every aspect of learning... can in principle be so precisely described that a machine can be made to simulate it." They budgeted two months for the problem. It has now taken nearly seven decades and is nowhere near "solved."

A rough timeline:

1943 — Warren McCulloch and Walter Pitts publish the first mathematical model of an artificial neuron.
1958 — Frank Rosenblatt builds the Perceptron, the first trainable neural network, generating headlines about machines that could "walk, talk, see, write."
1969–1980s — The "AI Winter." Minsky and Papert's book Perceptrons demonstrated fundamental limitations of single-layer networks, funding dried up, and the field stagnated.
1986 — Rumelhart, Hinton, and Williams popularize backpropagation, the algorithm that makes training deep networks mathematically tractable.
2012 — AlexNet wins the ImageNet competition by a landslide, proving deep convolutional networks work at scale once you have enough data and GPU power. This is widely considered the start of the modern deep learning boom.
2017 — Google researchers publish "Attention Is All You Need," introducing the Transformer architecture — the backbone of essentially every major language model since, including GPT, Claude, and Gemini.
2020s — Large Language Models (LLMs) scale into the hundreds of billions of parameters, RAG and agentic tool-use emerge, and AI shifts from a research curiosity to consumer infrastructure.

The pattern worth noticing: AI didn't improve because someone had a flash of genius about "how thinking works." It improved because of better math (transformers), more data, and more compute — three unglamorous ingredients that happened to compound.

2. Neural Networks: The Engine Room

2.1 The Biological Metaphor (and Why It's Overstated)

Neural networks are loosely inspired by biological neurons, but the resemblance is skin-deep. A real neuron is a chemically complex, self-repairing cell embedded in a living system. An artificial "neuron" is a single number produced by multiplying inputs by weights and squashing the result through a function. Calling it a "brain" is a bit like calling a wristwatch a "sundial with ambition." Useful shorthand, misleading if taken literally.

2.2 The Artificial Neuron

Each artificial neuron does exactly one job: take several numbers in, produce one number out. The math:

z = (w1*x1 + w2*x2 + ... + wn*xn) + b
a = activation(z)

Where:

x1...xn are the inputs (could be pixel values, word embeddings, anything numeric)
w1...wn are weights — learned values that determine how much each input matters
b is the bias — an offset that shifts the output
activation() is a non-linear function applied to z

Without that final non-linear activation function, you could stack a thousand layers and the whole network would mathematically collapse into a single linear equation — utterly incapable of learning anything more complex than a straight line. The most common activation functions:

ReLU (Rectified Linear Unit): f(z) = max(0, z) — simple, fast, the current default for most hidden layers.
Sigmoid: f(z) = 1 / (1 + e^-z) — squashes output between 0 and 1, useful for probabilities.
Softmax: converts a vector of numbers into a probability distribution that sums to 1 — this is what sits at the very end of a language model, turning raw scores into "the probability the next word is cat."

2.3 Forward Propagation — the Math

"Forward propagation" is just the process of pushing data through the network, layer by layer, until you get an output. For a single layer, it's expressed in matrix form:

Z = W·X + B
A = activation(Z)

Here W is a matrix of all the weights in that layer, X is the input vector, and B is a vector of biases. This is why AI is fundamentally linear algebra at industrial scale — a modern LLM performs trillions of these matrix multiplications per response, which is precisely why they need specialized chips (GPUs and TPUs) rather than ordinary processors.

2.4 Backpropagation and Gradient Descent

Training is the process of adjusting every weight and bias so the network's output gets closer to the correct answer. This happens through:

Loss calculation — comparing the network's prediction to the true answer using a loss function, commonly cross-entropy loss for classification tasks:
```
L = -Σ y_true * log(y_predicted)
```
Backpropagation — using calculus (specifically the chain rule) to compute how much each individual weight contributed to the error: ∂L/∂w for every weight w in the network.
Gradient descent — nudging each weight slightly in the direction that reduces the error:
```
w_new = w_old - learning_rate * (∂L/∂w)
```

Repeat this process across billions of examples, millions of times, and you get a network that has, purely through trial and error, arranged its weights into a configuration that produces useful outputs. Nobody manually designs what any individual weight should be — it's discovered, not written. This is also why AI is often called a black box: even the people who build these systems cannot point to a specific weight and say "this is where it knows Paris is the capital of France." The knowledge is smeared, statistically, across billions of parameters.

2.5 Anatomy of an ANN: Six Layers, Six Jobs

A typical deep Artificial Neural Network (ANN) used for a moderately complex task can be broken into roughly six functional layers:

Input Layer — receives raw data converted into numbers (pixel intensities, word tokens, audio waveforms). No computation happens here; it's just the data's entry point.
Embedding / Encoding Layer — converts discrete inputs (like words) into dense numeric vectors that capture meaning. This is where "king" and "queen" end up mathematically close to each other.
Hidden Layer 1 (Feature Detection) — detects low-level patterns. In an image network, this might be edges or color gradients. In text, simple syntactic patterns.
Hidden Layer 2 (Feature Combination) — combines low-level features into more abstract concepts — shapes from edges, phrases from words.
Hidden Layer 3+ (Abstraction / Attention) — in transformer-based models, this is where self-attention mechanisms live, weighing how much every part of the input should influence every other part. This is the layer doing the heaviest conceptual lifting.
Output Layer — converts the final internal representation into the desired output format: a probability distribution over the next word, a classification label, or a set of pixel values.

Note: real production models like Claude or GPT don't have "six layers" in total — they have dozens to hundreds of stacked transformer blocks, each internally containing several sub-layers (attention, normalization, feed-forward). The six-layer breakdown above is a conceptual anatomy, not a literal layer count.

3. How AI "Thinks": Vectors, Embeddings, and Latent Space

This is the part that makes the "brain" metaphor collapse entirely. AI doesn't "think" the way you do — it converts everything into vectors (lists of numbers) and manipulates them geometrically.

A word becomes a vector — for example, a 4096-dimensional list of numbers.
A sentence becomes a sequence of vectors, further combined by attention into a single contextual representation.
An image becomes a grid of vectors, one per patch.
Meaning becomes distance and direction in this high-dimensional space, called latent space.

The famous demonstration of this: in a well-trained word-embedding space, the vector arithmetic

vector("king") - vector("man") + vector("woman") ≈ vector("queen")

actually works, approximately. That's not poetry — that's literal subtraction and addition of number lists that happens to align with human semantic intuition. "Thinking," in an AI system, is the process of moving a point through this abstract mathematical space and reading off where it lands.

4. Reasoning in AI: Chain-of-Thought and Beyond

Early language models answered questions in a single forward pass — essentially a very sophisticated autocomplete. Modern "reasoning" models improve on this using a technique broadly called Chain-of-Thought (CoT) prompting, formalized in a 2022 paper by Wei et al. at Google. The core insight: language models produce better answers when forced to generate intermediate reasoning steps rather than jumping straight to a conclusion.

This has since evolved into more structured approaches:

Chain-of-Thought: the model writes out step-by-step reasoning in natural language before the final answer.
Tree-of-Thought: the model explores multiple reasoning branches in parallel and evaluates which path seems most promising, similar to how a chess engine considers multiple move sequences.
Self-consistency decoding: the model generates several independent reasoning chains for the same question and takes the most common final answer, on the theory that errors are inconsistent but correct reasoning tends to converge.
Extended "thinking" tokens: modern reasoning models (such as OpenAI's o-series or Claude's extended thinking mode) are trained via reinforcement learning to generate long internal reasoning traces before committing to a final answer, effectively giving the model "scratch paper."

It is worth being precise here: this is not reasoning in the human, conscious sense. It is a learned statistical tendency — generating tokens that resemble reasoning steps improves the probability of the next tokens being correct, because reasoning-like text in the training data was correlated with correct answers. The model isn't "checking its work" the way a person does; it's exploiting a statistical regularity that happens to resemble checking your work.

5. Retrieval-Augmented Generation (RAG) — Full Breakdown

5.1 Why RAG Exists

A language model's knowledge is frozen at the moment its training finished — this is called the knowledge cutoff. Ask it about something that happened afterward, and it will either admit ignorance or, worse, hallucinate — confidently invent a plausible-sounding but false answer. RAG was introduced specifically to solve this, in a 2020 paper by Lewis et al. at Facebook AI Research, titled "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks."

The core idea is deceptively simple: instead of relying purely on what the model memorized during training, give it access to an external, searchable knowledge base at the moment it answers a question.

5.2 The RAG Pipeline Step by Step

A production RAG system typically works like this:

Document Ingestion Source documents (PDFs, web pages, internal wikis, support tickets) are collected and cleaned.
Chunking Documents are split into smaller passages — usually 200 to 1,000 tokens each — because embedding an entire book as one vector would blur its meaning into uselessness. Chunking strategy (fixed-size, sentence-based, or semantic chunking) has a major effect on retrieval quality.
Embedding Each chunk is passed through an embedding model (such as OpenAI's text-embedding-3 or Anthropic's Voyage embeddings) that converts it into a dense vector — typically 384 to 3072 dimensions — representing its meaning numerically.
Storage in a Vector Database These vectors are stored in a specialized database optimized for similarity search (more on this below).
Query Embedding When a user asks a question, that question is also converted into a vector using the same embedding model.
Similarity Search / Retrieval The database compares the query vector against all stored document vectors, typically using cosine similarity:
```
cosine_similarity(A, B) = (A · B) / (||A|| * ||B||)
```
It returns the top-k (often 3 to 10) most similar chunks — the passages "most relevant" to the question mathematically.
Re-ranking (optional but common) A secondary, more computationally expensive model re-scores the retrieved chunks for relevance, since raw vector similarity is fast but imprecise.
Augmentation The retrieved chunks are inserted into the language model's prompt, alongside the user's original question — something like: "Using the following context, answer the question: [retrieved chunks] [user question]."
Generation The language model generates its final answer, now grounded in the retrieved, current, factual material rather than solely its frozen training memory.

5.3 Vector Databases

A vector database is purpose-built for one job: finding "nearest neighbors" in high-dimensional space, fast, at scale. Traditional databases (SQL, for instance) are built to find exact matches or ranges — they are terrible at answering "which of these ten million items is conceptually closest to this one?" Vector databases solve this using Approximate Nearest Neighbor (ANN) search algorithms — most commonly HNSW (Hierarchical Navigable Small World) graphs, which trade a small amount of accuracy for enormous speed gains.

Common vector database products include Pinecone, Weaviate, Milvus, Qdrant, Chroma, and vector extensions bolted onto existing databases like pgvector for PostgreSQL.

5.4 Pros, Cons, Uses, and Benefits

Benefits:

Keeps answers current without retraining the entire model, which can cost millions of dollars.
Reduces hallucination by grounding answers in real, retrievable source material.
Allows citation — the system can point to which document supported a claim.
Enables private, proprietary knowledge (internal company documents) to be queried without ever putting that data into the model's actual weights.

Drawbacks:

Retrieval quality is only as good as the chunking and embedding strategy — bad chunking produces irrelevant context, which produces bad answers.
Adds latency — an extra search step before generation begins.
Struggles with questions requiring synthesis across many documents rather than a single relevant passage.
Vector similarity is not the same as truth — a document can be semantically similar to a question while being factually wrong or outdated, and the system has no inherent way to know that.

Common uses: customer support chatbots grounded in a company's own documentation, legal and medical research assistants, enterprise "chat with your documents" tools, and coding assistants that retrieve relevant snippets from a large codebase before answering.

6. Benchmarks: How We Grade a Machine's Mind

Since there's no universal IQ test for software, the field relies on standardized benchmarks — curated test sets designed to measure specific capabilities. A few of the most cited:

MMLU (Massive Multitask Language Understanding): roughly 16,000 multiple-choice questions across 57 subjects, from law to astronomy, used as a general knowledge and reasoning benchmark.
HumanEval: measures a model's ability to write correct, functioning code from natural-language problem descriptions.
GPQA (Graduate-Level Google-Proof Q&A): extremely difficult science questions designed so that even a human expert with internet access struggles to answer quickly — meant to test genuine reasoning rather than lookup ability.
SWE-bench: evaluates whether a model can resolve real, historical GitHub issues in real codebases — a much closer proxy for "can this thing actually do a software engineer's job" than toy coding puzzles.
ARC-AGI: a benchmark specifically designed to resist memorization, testing abstract pattern reasoning on novel puzzle types the model has never seen.

A quiet but important criticism worth noting: benchmarks are frequently gamed, intentionally or not, through data contamination — when benchmark questions leak into a model's training data, inflating scores without reflecting real capability. This is why the field has increasingly moved toward "held-out," frequently refreshed, or dynamically generated benchmarks — an arms race between test-makers trying to measure genuine ability and models that are, whether by accident or incentive, very good at memorizing the answer key.

7. How AI Generates Images

Modern image generation (Midjourney, DALL·E, Stable Diffusion, Imagen) is built almost entirely on diffusion models. The workflow:

Text Encoding — the prompt is converted into embeddings using a text encoder (commonly a CLIP-style model), which understands the relationship between words and visual concepts.
Noise Initialization — the process starts with pure random noise, a grid of meaningless static, the visual equivalent of TV snow.
Iterative Denoising — a neural network, trained to predict "what noise was added to this image," repeatedly subtracts a small amount of predicted noise from the canvas, guided by the text embedding at every step. This happens across dozens to hundreds of steps.
Classifier-Free Guidance — at each denoising step, the model compares what the image would look like with the text prompt's influence versus without it, and exaggerates the difference to keep the output faithfully aligned to the prompt.
Decoding — many modern systems (like Stable Diffusion) work in a compressed "latent" space rather than full pixel space for efficiency, so a final decoder network expands the small latent grid back into a full-resolution image.

The training process that makes this possible works in reverse: the model is shown millions of real images with deliberately added noise at various intensities, and trained to predict and remove that noise. Do this enough times across enough images, and the network essentially learns "what does a plausible image look like," which it can then apply to pure random noise, sculpting chaos into a coherent picture, guided the whole way by your text prompt.

8. How AI Generates Video

Video generation (Sora, Veo, Runway) is the same diffusion principle, made dramatically harder by adding a time axis. The pipeline:

Prompt and Reference Encoding — text (and sometimes a reference image or video) is embedded, same as image generation.
Spatiotemporal Latent Representation — instead of denoising a single 2D grid, the model works on a 3D block of latent "patches" spanning both space and time, so it can reason about motion, not just appearance.
Joint Denoising Across Frames — the diffusion process runs across the entire clip simultaneously (not frame-by-frame independently), which is what prevents flickering, morphing objects, and the uncanny inconsistency that plagued early video models.
Temporal Attention Layers — special attention mechanisms allow the model to track "this object in frame 1 should still be this object, in a physically plausible new position, in frame 40" — effectively learning intuitive physics from watching enormous quantities of real video.
Decoding and Upscaling — the final latent block is decoded into full-resolution frames, often followed by a separate upscaling and interpolation pass to boost resolution and frame rate.

The reason video generation trails image generation in quality and cost efficiency is straightforward: an image is one frame; a five-second clip at 24 frames per second is 120 correlated frames that must remain internally consistent, obey rough physics, and follow a prompt — an exponentially harder optimization problem.

9. How AI Searches Online

When a chatbot appears to "search the internet," it is not maintaining a live crawl of the web itself. The pipeline typically looks like this:

Query Formulation — the model reformulates your natural-language question into one or more concise search queries, the way a human would type into a search bar rather than paste in a full paragraph.
Search API Call — those queries are sent to an actual search engine's index (Google, Bing, or a specialized search provider), which returns a ranked list of URLs and snippets.
Result Selection — the model evaluates which returned pages are actually relevant, filtering out spam, ads, and low-quality sources.
Fetching and Extraction — for pages worth reading in full, the system fetches the raw page and extracts the readable text, stripping navigation menus, ads, and boilerplate.
Synthesis — the extracted content is fed into the model's context window alongside your original question, essentially functioning as a live, on-demand version of the RAG pipeline described earlier, except the "database" is the entire indexed web rather than a fixed private document set.
Citation — the model attributes specific claims back to specific sources, so a reader can verify the underlying information rather than trusting the model's word alone.

This is, functionally, RAG applied to the open web instead of a curated document set — which is why understanding RAG's mechanics earlier in this article is not a tangent; it's the exact same architecture doing a different job.

10. How AI Does Coding

Code generation models are trained on the same transformer architecture as general language models, just with a training diet heavily weighted toward source code repositories, documentation, and — critically — the relationships between code and its outcomes (does it compile, does it pass tests). A modern coding agent workflow looks like:

Context Gathering — the model reads relevant files, directory structure, and documentation to understand the existing codebase rather than working in isolation.
Planning — for non-trivial tasks, the model often generates an explicit plan or breaks the task into subtasks before writing any code (a coding-specific application of Chain-of-Thought).
Code Generation — the model predicts code token-by-token, the same next-token prediction mechanism used for prose, just trained on syntax-heavy data.
Tool Use / Execution — advanced coding agents don't just write code; they can run it, read the terminal output or error messages, and iterate — a feedback loop much closer to how a human developer actually debugs.
Testing and Verification — the model may write or run tests to confirm the code behaves as intended, rather than trusting its own first draft.

A short illustrative example of what "next-token prediction applied to code" actually looks like under the hood:

# The model doesn't "understand" recursion philosophically.
# It has seen millions of examples of this exact pattern
# and learned the statistical shape of a correct solution.
def factorial(n):
    if n <= 1:
        return 1
    return n * factorial(n - 1)

The model isn't reasoning about mathematical induction. It has seen this shape of function thousands of times in training data and learned, statistically, what token is most likely to come next given everything before it — and it turns out that process, applied at sufficient scale, produces genuinely useful code.

11. Training Data — And the Uncomfortable Question of Who Pays For What

Here is where the conversation gets less about elegant mathematics and more about business models. Large language models require staggering quantities of training data — text scraped from books, websites, code repositories, and, increasingly, user conversations with the AI systems themselves.

This creates a genuinely uncomfortable situation for paying customers. As multiple industry reports have detailed, Anthropic changed its consumer data policy around late September 2025: conversations from Free, Pro, and Max subscribers — people paying real money for the service — became eligible for use in training future models by default, unless the user manually opts out in privacy settings. Retention for training-eligible data extends up to five years, a significant jump from the prior 30-day deletion window. Business, Enterprise, and API-based accounts are generally contractually excluded from this and are not used for training. Consumer subscribers, however, must actively find and disable the "Help improve Claude" toggle if they want their conversations excluded.

There is a real irony worth sitting with here: subscribing to a product typically buys you a service free of being the product. With consumer AI subscriptions, that assumption doesn't automatically hold — a paying user's conversations can, unless they opt out, still become raw material for the next model iteration, meaning the same person is simultaneously the customer and the unpaid data contributor. It is not fraud, and it is disclosed in the terms of service, but "disclosed in the terms of service" has never once been synonymous with "widely understood by the people it affects." If you want to know whether your own conversations are being used, the honest answer is: check your account's privacy settings directly, because policies and defaults change, and the specifics matter more than any summary.

This is a broader pattern in the industry, not unique to one company. It reflects a genuine tension: models need continuously fresh, high-quality conversational data to keep improving, and real user conversations are extraordinarily valuable for that purpose in a way that scraped web text is not — precisely because they represent authentic, effective human-AI interaction. The fix is not to feel powerless about it, but to actually go and check the toggle.

12. The Claude Code Leak of March 31, 2026

On March 31, 2026, between roughly 00:21 and 03:29 UTC, Anthropic accidentally exposed the complete internal source code of Claude Code, its terminal-based agentic coding tool, to the public internet. Here is what actually happened, mechanically:

Anthropic's build process for Claude Code uses Bun as its bundler. Bun generates JavaScript source map (.map) files by default during builds — debugging artifacts that map minified, production code back to its original, fully readable source.
When version 2.1.88 of the @anthropic-ai/claude-code npm package was published, a 59.8 MB source map file was accidentally included in the public package rather than being excluded via .npmignore.
That source map contained a reference to an archive hosted on Anthropic's cloud storage, effectively pointing straight at the full, human-readable original codebase.
Within hours of publication, an intern at Solayer Labs discovered the exposure and posted about it publicly, and the codebase — roughly 512,000 lines of TypeScript across approximately 1,900 files — was mirrored across GitHub and analyzed extensively by the developer community before Anthropic could fully contain it.

What was found inside it:

The full agent harness architecture — the orchestration layer that wraps the underlying Claude model and gives it the ability to use tools, run shell commands, manage files, and coordinate multiple sub-agents on a task.
A three-layer memory architecture and context-compaction strategies used to manage long coding sessions without exceeding context limits.
Roughly 44 hidden, unreleased feature flags, revealing product features Anthropic was building but had not shipped publicly — including an autonomous background-operation mode (internally codenamed KAIROS) intended to let the agent work persistently without a user actively present, along with related unreleased modes for offline/"away" operation.
Internal permission-sandbox logic governing what actions the coding agent is and isn't allowed to take autonomously.
Assorted internal codenames, developer comments, and even a hidden novelty feature (an embedded virtual pet, described by multiple reports as a "Tamagotchi" easter egg), which — in the way these things go — got almost as much attention online as the serious architectural revelations.

Why it mattered strategically, not just technically: competitors building their own AI coding agents (Cursor, GitHub Copilot, Windsurf, OpenAI's Codex, among others) suddenly had a detailed, real-world blueprint of how a production-grade agentic harness is actually engineered — something previously guessed at from the outside. Multiple industry analyses concluded that the leak reinforced an argument already circulating in the field: that the "harness" wrapping an AI model is not, by itself, a durable competitive moat, since it can be reverse-engineered or replicated once exposed — meaningful differentiation increasingly has to come from the underlying model's raw capability rather than the tooling around it.

Separately, but confusingly overlapping in time: during that exact same window, an unrelated supply-chain attack hit the popular axios npm package, publishing malicious versions containing a Remote Access Trojan (RAT). Anyone who happened to run npm install or update Claude Code during that specific 00:21–03:29 UTC window was advised to check their lockfiles for the compromised versions and treat any affected machine as potentially compromised. This was coincidental timing with a genuinely separate incident, not caused by the Claude Code leak itself, but the overlap made the initial hours of the story considerably more chaotic and difficult to disentangle for the developers trying to figure out what, exactly, had just happened to their machines.

Anthropic subsequently pursued DMCA takedowns against repositories hosting the leaked source and shifted its recommended installation method toward a standalone native installer, reducing reliance on the npm dependency chain that made the incident possible in the first place. Claude Code itself remains closed-source, proprietary software; the leak did not change its official licensing or availability — it just meant, for a few chaotic hours, that the entire internet got an uninvited look at the blueprint.

Conclusion: There Is No Ghost, Just Very Good Bookkeeping

Strip away the branding, the anthropomorphic language, and the increasingly cinematic marketing videos, and what remains is this: matrices multiplying matrices, gradients nudging weights, vectors clustering by meaning, and enormous pipelines of retrieval, denoising, and prediction stacked on top of each other with genuine engineering sophistication. None of it requires belief in machine consciousness to be useful, and none of it requires cynicism about its usefulness to stay clear-eyed about how it actually works — and who actually benefits from your data along the way.

The "brain" was never a brain. It was always vectors and math, arranged remarkably well.

References

McCulloch, W. & Pitts, W. (1943). A Logical Calculus of the Ideas Immanent in Nervous Activity.
Rumelhart, D., Hinton, G., & Williams, R. (1986). Learning Representations by Back-Propagating Errors. Nature.
Krizhevsky, A., Sutskever, I., & Hinton, G. (2012). ImageNet Classification with Deep Convolutional Neural Networks (AlexNet).
Vaswani, A. et al. (2017). Attention Is All You Need. Google Research / NeurIPS.
Lewis, P. et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. Facebook AI Research.
Wei, J. et al. (2022). Chain-of-Thought Prompting Elicits Reasoning in Large Language Models. Google Research.
VentureBeat (March 31, 2026). Claude Code's source code appears to have leaked: here's what we know.
Zscaler Security Research (2026). Anthropic Claude Code Leak — Critical AI Security Threat 2026.
DEV Community (April 1, 2026). The Great Claude Code Leak of 2026.
Tom's Guide (2026). Your Claude chats are being used to train AI — here's how to opt out.
MPG ONE (2026). Does Anthropic Train Claude on Your Data? Full Answer.

Find me across the web:

Portfolio: ahmershah.dev
Crunchbase: @syed-ahmer-shah
LinkedIn: Syed Ahmer Shah
GitHub: @ahmershahdev
AWS Builder Profile: @syedahmershah
DEV.to: @syedahmershah
Medium: @syedahmershah
Hashnode: @syedahmershah
Substack: @syedahmershah
HackerNoon: @syedahmershah
Substack: @syedahmershah
Facebook: @ahmershahdev
Linkedin Page: @syedahmershah
YouTube: @ahmershahdev
Instagram: @ahmershahdev
TikTok: @ahmershahdev

Top 10 AI Tools Every Frontend Developer Should Know (2026 Guide)

Syed Ahmer Shah — Mon, 13 Jul 2026 10:16:01 +0000

Frontend development in 2026 doesn't look like it did two years ago. Design and code used to be two separate jobs handed off through Figma files and export specs. Now a growing set of tools let you describe a screen in plain language and get something close to production code back — sometimes with the visual canvas and the code being the exact same artifact.

That doesn't mean every tool in this space is equally good, equally priced, or equally stable. 2026 has also been a year of consolidation: acquisitions, rebrands, and pricing model changes that make a lot of "best AI tools" lists from even six months ago outdated. Windsurf, for example, isn't called Windsurf anymore. Cursor moved to usage-based credits. GitHub Copilot dropped its premium-request system entirely.

This guide covers ten tools that frontend developers, designers, and product teams are actually using right now, with current pricing, what each tool is genuinely good at, and where it falls short. All pricing and feature claims are pulled from official pricing pages and independent reviews as of July 2026. Always double-check a vendor's own pricing page before subscribing — these tools change plans often.

Quick Comparison

Tool	Category	Free Tier	Starting Paid Price	Best For
Flowstep	AI design engineer / canvas-to-code	Yes	$15/month (Starter)	Multi-screen UI generation with Figma handoff
GitHub Copilot	Code completion + chat	Yes	$10/month (Pro)	Low-friction autocomplete inside existing editors
Figma Make	Design-to-code prototyping	Limited	Bundled into Figma plans	Teams already living in Figma
v0 by Vercel	Text-to-component generator	Yes ($5 credit)	$20/month	React/Next.js developers on Vercel
Cursor	AI-native IDE	Yes (Hobby)	$20/month (Pro)	Codebase-aware multi-file editing
Devin Desktop (formerly Windsurf)	Agentic IDE	Yes	$20/month (Pro)	Running local and cloud coding agents together
Claude Code	Terminal-based coding agent	No (needs Pro or API)	$20/month (bundled with Claude Pro)	Refactors, test generation, deep repo understanding
Bolt.new	Full-stack app generator	Yes (1M tokens/month)	$25/month (Pro)	Fast full-stack prototypes with live preview
Replit Agent	Cloud IDE with agentic building	Yes	Usage-based credits	Beginners and non-experts building end to end
FrontendAI	Screenshot/image-to-code	Varies	Varies	Converting existing designs into markup

Prices change often in this category — several tools listed here changed their pricing structure at least once in the first half of 2026 alone. Treat the table as a starting point, not a locked-in quote.

1. Flowstep

Website: flowstep.ai

Flowstep is an AI design engineer that generates production-ready UI from text prompts on an infinite canvas. The core differentiator is that the visual design and exported code are the same underlying artifact — no manual sync required between design and implementation.

What it does

Generates multiple connected screens (login, dashboard, onboarding) from a single prompt rather than one screen at a time
Produces editable designs on an infinite canvas with real-time collaboration (live cursors, synced edits, inline feedback)
Accepts references — images, URLs, or a design-system markdown file — to anchor output to an existing brand
Exports React, TypeScript, and Tailwind CSS code alongside the visual design
Enables direct Figma integration: copy any design with ⌘C and paste directly into Figma with ⌘V (no plugin required)
Exposes an MCP server so it can be called from Cursor, Claude Code, or Devin Desktop as part of an agentic workflow
Supports manual and AI-assisted design editing for granular customization
Manual edits to generated designs don't consume message credits

Pricing (2026)

Flowstep uses message-based pricing — one prompt equals one message, regardless of complexity. Errors don't count toward your message limit.

Plan	Price	Notes
Free	$0	No credit card required, limited messages
Starter	$15/month	80 messages/month
Growth	$29/month	240 messages/month
Scale	$99/month	1,000 messages/month
Enterprise	Custom	Governance and security controls

Where it falls short

While message-based pricing is more predictable than token-based systems, heavy iterative workflows can burn through the lower tiers quickly. It's also designed as a rapid design and prototyping tool rather than a replacement for Figma's full feature set for complex, highly customized design systems — teams with strict component libraries will still do final polish there.

2. GitHub Copilot

Website: github.com/features/copilot

Copilot remains the most widely deployed AI coding assistant, mostly because it lives inside editors developers already use — VS Code, JetBrains, Neovim, Visual Studio — rather than asking anyone to switch tools.

What it does

Inline, context-aware code completions as you type
Copilot Chat for in-editor Q&A, explanations, and multi-file assistance
Agent mode for more autonomous multi-step tasks
Code review integrated into GitHub pull requests

Pricing (2026)

GitHub moved Copilot to usage-based billing on June 1, 2026, replacing the old "premium request" counting system with GitHub AI Credits, billed by token consumption. Code completions remain unlimited and free of charge on all paid plans; only chat, agent mode, and code review draw from the credit pool.

Plan	Price	Notes
Free	$0	2,000 completions/month, limited chat and agent usage
Pro	$10/month	Includes ~$15 in monthly AI credits
Pro+	$39/month	Includes ~$70 in monthly AI credits, broader model access
Business	$19/user/month	Org-wide policy control, IP indemnity
Enterprise	$39/user/month	Codebase indexing, native GitHub.com integration

Where it falls short

Autocomplete-first tools like Copilot are less effective than agentic editors (Cursor, Devin Desktop) for large, intentional, cross-file changes. The June 2026 billing switch also means costs are less predictable than the old flat-fee model for teams running agent mode heavily.

3. Figma Make

Website: figma.com

Figma's AI prototyping layer lets you describe a component or screen in natural language and get an editable prototype back, inside the design tool most product teams already treat as their source of truth.

What it does

Prompt-to-prototype generation inside existing Figma files
Stays connected to your team's component library and design tokens
Developer handoff through Figma's existing Dev Mode
Multi-user collaboration under Figma's established permissions model

Pricing (2026)

Figma Make is bundled into Figma's existing plan structure rather than sold as a standalone product. Check Figma's pricing page for current prompt and generation limits — these have shifted alongside Figma's broader AI rollout and aren't listed separately from the base plan tiers.

Where it falls short

Figma Make's output tends to work better as a starting exploration than as shippable production code — it's an AI layer added onto an existing tool architecture rather than a rebuilt workflow. Heavier AI usage requires a paid Figma plan, and because pricing is bundled, it's harder to predict AI-specific costs month to month.

4. v0 by Vercel

Website: v0.app

v0 is Vercel's prompt-to-component generator, built specifically around the React, Next.js, Tailwind CSS, and shadcn/ui stack.

What it does

Generates individual components or full-page layouts from a text prompt
Uses shadcn/ui primitives, so output is accessible and consistent by default
Chat-based iteration, plus a Git panel for branches and pull requests
One-click deployment to Vercel's edge network
Three model tiers (Mini, Pro, Max) with different quality/cost trade-offs

Pricing (2026)

v0 moved to a token-metered credit system in 2025 and has kept it through 2026.

Plan	Price	Notes
Free	$0	$5 in monthly credits
Premium	$20/month	$20 in monthly credits, Figma import, API access
Team	$30/user/month	Shared credit pool, centralized billing
Business	$100/user/month	$30 of included credits/user, SAML SSO
Enterprise	Custom	Priority performance, support SLAs

Where it falls short

v0 generates frontend code only — no backend logic or database layer, unlike Bolt.new or Replit Agent. The credit system is also token-based rather than message-based, which makes monthly costs harder to predict than flat per-prompt pricing.

5. Cursor

Website: cursor.com

Cursor is a VS Code fork built around AI having full awareness of your codebase, not just the open file. Its Composer feature proposes multi-file diffs from a single natural-language instruction.

What it does

Composer for codebase-aware multi-file edits
.cursorrules for defining project-specific conventions the AI should follow
Native MCP (Model Context Protocol) support, so it can connect to external tools
Background/cloud agents that run tasks without tying up your local machine

Pricing (2026)

Cursor switched from fixed "fast request" counts to usage-based credit pools in June 2025, and the structure has held through 2026.

Plan	Price	Notes
Hobby	$0	Limited Agent requests and Tab completions
Pro	$20/month	Unlimited Tab, $20 monthly credit pool, MCP support
Pro+	$60/month	3x the usage credits of Pro
Ultra	$200/month	20x the usage credits of Pro, priority feature access
Teams	$40–$120/user/month	Standard and Premium seat tiers, centralized billing, SSO
Enterprise	Custom	Pooled usage, invoice billing, audit logs

Annual billing saves roughly 20% across paid individual tiers.

Where it falls short

The credit-based pricing model has been a genuine source of user frustration since the June 2025 change — manually selecting frontier models (Claude Opus, GPT-5-class models) burns through the credit pool much faster than routine completions, and costs can spike unpredictably for heavy agent users.

6. Devin Desktop (formerly Windsurf)

Website: cognition.ai

This one has been through more churn than any other tool on this list, so the history matters. Windsurf started as Codeium's rebranded agentic IDE. In 2025, OpenAI agreed to acquire it for roughly $3 billion — that deal collapsed when its exclusivity window expired, Google then hired away Windsurf's CEO and a large chunk of its engineering team, and Cognition AI (the company behind the autonomous coding agent Devin) acquired the remaining product, brand, and team for approximately $250 million in December 2025. On June 2, 2026, Cognition rebranded the product from Windsurf to Devin Desktop.

What it does

Local and cloud coding agents managed side by side in an "Agent Command Center"
Devin Local (successor to the old Cascade agent, which reached end-of-life July 1, 2026) for multi-step local editing
Spaces, for grouping sessions, pull requests, and Git worktrees so multiple agents can share context
Model-agnostic access, including Claude and Gemini alongside Cognition's own SWE-series models

Pricing (2026)

Plan	Price	Notes
Free	$0	Usable for evaluation
Pro	$20/month	Unlimited SWE-1.6 model access
Max	$200/month	Heavy quotas across all models
Teams	$80/month + $40/seat	SSO, admin controls, shared Spaces
Enterprise	Custom	SOC 2, HIPAA, FedRAMP/DOD, RBAC

Where it falls short

The ownership turnover is the real caveat here. Enterprise procurement teams are understandably cautious about a product that's changed hands twice in under a year, and anyone evaluating it should confirm current pricing and support terms directly — older reviews still describe the pre-acquisition Codeium/Windsurf product.

7. Claude Code

Website: claude.com/claude-code

Claude Code is Anthropic's terminal-native coding agent. Rather than working inside a GUI editor, it runs from the command line, reads your repository, and executes multi-step tasks with a large context window.

What it does

Deep repository understanding before making any change
Strong at refactoring, test generation, and dependency migrations across existing codebases
Native MCP support for connecting to other tools
Up to 1 million tokens of context via the API (200K on standard subscription plans, 500K on Enterprise)

Pricing (2026)

Claude Code isn't sold standalone — it's bundled into Anthropic's Claude subscription plans and billed against the same usage pool as Claude chat.

Plan	Price	Notes
Pro	$20/month ($17/month billed annually)	Access to Claude Code in terminal, web, and desktop
Max 5x	$100/month	5x the Pro usage capacity
Max 20x	$200/month	20x the Pro usage capacity
Team (Premium seat)	~$100–125/seat/month	Claude Code only available on Premium seats
Enterprise	Custom	500K context window, HIPAA readiness, SSO
API (pay-per-token)	Variable	No monthly minimum; usage billed per token

There is no free tier for Claude Code — the free Claude.ai plan covers chat only.

Where it falls short

Claude Code uses a rolling 5-hour session window plus a weekly compute cap, which some users report exhausting faster than expected on large refactors. It's also a terminal-first tool, which is a real adjustment for developers who prefer a GUI-based workflow, and it isn't designed for greenfield UI design work the way Flowstep or v0 are.

8. Bolt.new

Website: bolt.new

Bolt.new (from StackBlitz) is a browser-based full-stack generator. Describe an application and it spins up a running project inside an in-browser Node.js runtime called WebContainers — no local environment setup required.

What it does

Full-stack generation: frontend, backend, and database from one prompt
Live, interactive preview running entirely in the browser
One-click deployment to Netlify, Vercel, or StackBlitz
Integrations with Figma, GitHub, Stripe, and Supabase

Pricing (2026)

Bolt uses a token-based system rather than a message-count system, which makes usage harder to predict than some competitors.

Plan	Price	Notes
Free	$0	1M tokens/month, 150,000–300,000 daily cap
Pro	$25/month	~10–13M tokens/month, no daily cap, custom domains
Teams	$30/member/month	Per-member token allotment, not pooled
Enterprise	Custom	SSO, audit logs, dedicated support

Unused tokens on paid plans roll over for one additional month.

Where it falls short

Token consumption scales with project size, not just prompt count — Bolt re-syncs your whole project to the AI on each message, so costs can escalate quickly as an app grows past a simple prototype. Several independent reviewers describe it as best for fast prototyping and demos, with complexity and maintainability becoming real problems once a project grows past a basic MVP.

9. Replit Agent

Website: replit.com

Replit Agent offers conversational, goal-driven development inside Replit's cloud IDE. Describe what you want in plain language, and the agent scaffolds the project, writes code, installs packages, runs the server, and resolves errors largely on its own.

What it does

Handles environment setup automatically — no local configuration required
Reads error logs and self-corrects without step-by-step direction
Built-in deployment from Replit's own infrastructure
Accessible to developers who aren't comfortable debugging environment or dependency issues themselves

Pricing (2026)

Replit moved to a usage-based credit system in 2026. Costs depend on the type and length of tasks the agent runs. Check Replit's pricing page for current rates — these have changed more than once this year.

Where it falls short

Because the agent makes more autonomous architectural decisions than tools like Cursor or v0, code quality can vary and occasionally produces choices that cause friction in later iterations. It also comes with more vendor lock-in to Replit's own infrastructure than most alternatives on this list.

10. FrontendAI

Website: frontend.ai

FrontendAI specializes in the reverse problem from tools like Flowstep or v0: instead of generating a design from a prompt, it converts an existing screenshot, Figma export, or hand-drawn sketch into working HTML, CSS, and optionally React code.

What it does

Converts uploaded images or mockups directly into markup
Produces semantic HTML, which helps with accessibility and maintainability
Handles standard grid and flexbox layouts reliably

Pricing (2026)

FrontendAI's pricing varies by plan and usage tier, and has shifted in 2026. Check frontend.ai directly for current rates before subscribing.

Where it falls short

Accuracy drops noticeably for complex, custom, or animation-heavy designs, and generated output generally needs a review pass before it's production-ready. It's a narrower tool than most others on this list — useful specifically when you're starting from an existing visual rather than a blank prompt.

How These Tools Actually Fit Together

None of these tools are really competing head-to-head for the same job. They cover different stages of the same pipeline:

Design generation — Flowstep, Figma Make, or v0 to get from an idea to a visual concept and starting code
Implementation — Cursor, Devin Desktop, or Claude Code to integrate that output into a real codebase, wire up logic, and connect APIs
Day-to-day assistance — GitHub Copilot for autocomplete and in-editor help across the whole project
Rapid full-stack prototyping — Bolt.new or Replit Agent to validate an idea before committing to a production build
Design-to-code conversion — FrontendAI when you're starting from an existing screenshot or mockup rather than a prompt

The MCP (Model Context Protocol) support that's now common across Cursor, Claude Code, Devin Desktop, and Flowstep is what's making these pipelines less manual — design generation and code implementation increasingly happen in the same agentic workflow instead of requiring you to copy assets between disconnected tools.

My Honest Takeaway

AI hasn't removed the need for frontend expertise — it's shifted where that expertise matters. The repetitive, pattern-recognition work that used to eat up a sprint is increasingly automatable. Judgment about what to build, how it should behave, and whether it actually works for real users is still entirely a human job, and every tool above still ships output that needs review before it goes to production.

Given how fast this category is moving — three tools on this list changed their pricing model in the first half of 2026 alone, and one changed ownership twice — the safest approach is to treat any specific number here as a snapshot, not a guarantee, and confirm current pricing directly with the vendor before you commit a team to one.

Sources and Further Reading

Find me across the web:

Portfolio: ahmershah.dev
LinkedIn: Syed Ahmer Shah
GitHub: @ahmershahdev
AWS Builder Profile: @syedahmershah
DEV.to: @syedahmershah
Medium: @syedahmershah
Hashnode: @syedahmershah
Substack: @syedahmershah
HackerNoon: @syedahmershah
Substack: @syedahmershah
Facebook: @ahmershahdev
Linkedin Page: @syedahmershah
YouTube: @ahmershahdev
Instagram: @ahmershahdev
TikTok: @ahmershahdev

The Edge Latency Lie: Solving Global Consistency

Syed Ahmer Shah — Tue, 07 Jul 2026 16:06:04 +0000

"Edge computing will solve your latency problems." — Every cloud vendor ever.

The reality? It might just move them somewhere harder to debug.

I've been building distributed systems for a while now. And every time a new edge platform drops, the marketing follows the same script: deploy closer to your users, cut latency in half, make your app feel instant. It sounds clean. It looks great on diagrams.

But here's what they quietly skip over — edge and global consistency are fundamentally in tension with each other. You can have one easily. Getting both at the same time? That's where the engineering actually starts.

Let's be honest about what edge computing does, what it doesn't do, and how to build systems that are genuinely fast and consistent.

What Edge Computing Actually Promises

Edge computing moves compute and data closer to the user by distributing workloads across geographically dispersed nodes — instead of routing everything back to a central origin server.

Today's major players:

Platform	Edge Locations	Runtime	Storage Option
Cloudflare Workers	330+ cities globally	V8 Isolates	R2, D1, KV
Vercel Edge Functions	~70+ regions (via AWS)	V8 / Node.js	Edge Config
AWS Lambda@Edge	600+ CloudFront PoPs	Node.js, Python	S3, DynamoDB
Fastly Compute	90+ PoPs	WebAssembly	Fastly KV

Sources: Cloudflare Network Map, AWS CloudFront, Vercel Docs

The promise is real for static content, read-heavy workloads, and auth token validation. A user in Karachi shouldn't wait for a response to travel to a data center in Virginia when a node in Dubai or Mumbai can serve them in under 20ms.

That part works. The problem starts the moment you need writes.

The Physics You Can't Engineer Around

This is the inconvenient truth no vendor puts in their homepage hero section.

The speed of light in fiber optic cable is roughly 200,000 km per second — about two-thirds of its speed in a vacuum. That's not a software limitation. That's physics.

Route	Distance	Minimum Latency (one-way)
London → New York	~5,570 km	~28ms
Mumbai → Singapore	~3,900 km	~20ms
Karachi → Sydney	~11,200 km	~56ms
Tokyo → Los Angeles	~8,800 km	~44ms

Minimum theoretical. Real-world RTT adds routing overhead, queuing, and processing.

When you're reading data, edge wins. A nearby node returns cached content fast. But the second that data needs to be written and reflected across all nodes globally, you're fighting the speed of light — and the CAP theorem.

CAP Theorem: The Law You're Always Living Under

In 2000, computer scientist Eric Brewer introduced the CAP theorem, formally proven by Gilbert and Lynch in 2002. It states that any distributed data store can only guarantee two of the following three properties simultaneously:

Consistency — Every read gets the most recent write
Availability — Every request gets a response (not necessarily the latest data)
Partition Tolerance — The system keeps running even if nodes lose contact with each other

Since network partitions are unavoidable in distributed systems, you're always choosing between C and A.

"A distributed system is one in which the failure of a computer you didn't even know existed can render your own computer unusable." — Leslie Lamport

This is where edge platforms get quietly honest in their docs. Cloudflare KV, for example, is explicitly eventually consistent — writes propagate globally in under 60 seconds, but there's no guarantee a read immediately after a write returns the new value.

That's fine for feature flags. It's not fine for bank balances.

The Consistency Models You Should Know

Not all consistency is created equal. Here's the practical spectrum:

Strong Consistency

Every read reflects the latest write. All nodes agree before responding. Slower but safe. Used in: traditional relational databases, Google Spanner, CockroachDB.

Eventual Consistency

Writes propagate asynchronously. Nodes will eventually agree. Fast but unpredictable timing. Used in: Cloudflare KV, DynamoDB (default), Cassandra.

Causal Consistency

Reads respect causality — if you see event B, you've already seen event A that caused it. Middle ground. Used in: MongoDB (with sessions), YugabyteDB.

Linearizability

The strongest form. Every operation appears instantaneous and in order. Expensive. Used in: Zookeeper, etcd, Google Spanner.

Where Edge Actually Breaks: A Real Scenario

Say you're building a collaborative SaaS tool — think project management, shared docs, anything with real-time state. Here's what happens when two users in different regions edit the same record simultaneously:

User A (London) → writes "Status: Done" to EU edge node
User B (Tokyo)  → writes "Status: In Progress" to APAC edge node

Both nodes accept the write.
Both users see a success response.
The nodes sync 2 seconds later.
One write silently wins. The other is lost.

No error. No conflict warning. Just silent data loss. This is the edge latency lie in its purest form — the appearance of speed masking a deeper consistency failure.

The Real Solutions (Not Just Theory)

1. CRDTs — Conflict-Free Replicated Data Types

CRDTs are data structures mathematically designed so that concurrent writes from multiple nodes can always be merged without conflict. The merge is deterministic regardless of order.

Figma rebuilt their multiplayer engine around CRDTs. Notion uses them for collaborative blocks. Automerge and Yjs are two solid open-source implementations you can use today.

CRDTs shine for: collaborative text editing, shopping carts, counters, presence indicators.

They don't work for: sequential operations where order matters (e.g., financial transactions).

2. Distributed Consensus — Raft & Paxos

For strong consistency across distributed nodes, you need a consensus algorithm. Raft (designed by Diego Ongaro and John Ousterhout, 2014) is the readable, implementable choice. It's the backbone of etcd, CockroachDB, and TiKV.

The trade-off is latency — a write must be acknowledged by a quorum of nodes before it's committed. If your quorum spans continents, you're paying cross-region latency on every write.

3. Geo-Partitioned Databases

Instead of trying to sync everything globally, you partition data by region. A user in Europe owns their data on EU nodes. A user in Asia owns theirs on APAC nodes. Cross-region reads only happen when necessary.

CockroachDB and Google Spanner both support this natively.

4. The PACELC Model — A Better Framework

In 2012, Daniel Abadi extended CAP into PACELC, which adds the latency dimension CAP ignores:

If there's a Partition: choose between Availability and Consistency.

Else (no partition): choose between Latency and Consistency.

This is more honest for edge systems. Even when your network is healthy, you're still making a trade-off between responding fast from a local node vs. waiting for a globally consistent answer.

Choosing the Right Architecture

Here's a practical decision guide:

Use Case	Best Approach	Consistency Model
Static assets, HTML	Pure CDN/Edge cache	N/A
Auth tokens, JWT validation	Edge middleware	Eventual (short TTL)
Real-time collaboration	CRDTs + WebSockets	Causal / CRDT merge
Financial transactions	Single-region primary DB	Strong / Linearizable
User profiles (read-heavy)	Edge cache + async replication	Eventual
Inventory / stock levels	Consensus DB (CockroachDB)	Strong
Analytics writes	Event queue + async processing	Eventual

What Good Edge Architecture Looks Like

The best-performing distributed systems I've worked on don't try to do everything at the edge. They're deliberate about what goes where:

Edge layer → handles auth, rate limiting, A/B routing, static delivery
Regional layer → caches computed data close to user clusters
Global layer → owns the source of truth; writes go here

Write paths stay consistent. Read paths get optimized at each layer. You stop expecting the edge to do things it was never designed to do.

Bottom Line

Edge computing is a genuine improvement for a specific class of problems. It cuts latency on reads, reduces origin load, and improves perceived performance for geographically distributed users.

But it doesn't solve consistency. It relocates the trade-off.

The engineers who get this right aren't the ones chasing the fastest edge network — they're the ones who are precise about what data needs to be consistent, where writes are authoritative, and what their users can actually tolerate.

Physics isn't a product bug. Design around it honestly.

Disclaimer: This article was researched, written, and structured by me with assistance from AI for search, editing, and Markdown formatting. While I strive for accuracy, AI and human errors can happen—please do your own research (DYOR) before implementing anything critical.

References & Further Reading

Brewer, E. (2000). Towards Robust Distributed Systems. PODC Keynote. ACM
Gilbert, S. & Lynch, N. (2002). Brewer's Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services. ACM SIGACT News.
Abadi, D. (2012). Consistency Tradeoffs in Modern Distributed Database System Design: CAP is Only Part of the Story. IEEE Computer. IEEE
Ongaro, D. & Ousterhout, J. (2014). In Search of an Understandable Consensus Algorithm (Raft). raft.github.io
Cloudflare. How KV Works. developers.cloudflare.com
Automerge. A JSON-like data structure that can be modified concurrently. automerge.org
Yjs. Shared Editing Framework. yjs.dev
CockroachDB. Geo-Partitioned Replicas Topology. cockroachlabs.com

Find me across the web:

Portfolio: ahmershah.dev
LinkedIn: Syed Ahmer Shah
GitHub: @ahmershahdev
AWS Builder Profile: @syedahmershah
DEV.to: @syedahmershah
Medium: @syedahmershah
Hashnode: @syedahmershah
Substack: @syedahmershah
HackerNoon: @syedahmershah
Substack: @syedahmershah
Facebook: @ahmershahdev
Linkedin Page: @syedahmershah
YouTube: @ahmershahdev
Instagram: @ahmershahdev
TikTok: @ahmershahdev

Fable 5 vs Sol 5.6

Syed Ahmer Shah — Wed, 01 Jul 2026 20:04:36 +0000

Introduction

Okay so I need to start this by admitting something embarrassing. I originally thought Claude Fable 5 was "releasing tomorrow." I had it in my notes like that, ready to write this post around it. Then I actually sat down to search before writing (something I'm trying to force myself to do more, because half the AI news floating around university WhatsApp groups is either outdated or just wrong) and found out Fable 5 is coming back today, July 1, 2026. Not tomorrow. Today.

That mix-up is honestly a decent summary of the last three weeks in AI news. Things have been moving so fast that even people who follow this stuff daily — and I do, because half my freelancing pitch on Fiverr depends on knowing which models are actually usable this week — keep getting dates wrong.

So here's what this post actually is. Not a tutorial. Not "5 tips to use Claude Fable 5." Just me, a 19-year-old Software Engineering student from Hyderabad, trying to make sense of why two of the most powerful AI models on earth got yanked offline by governments within two weeks of each other, whether that was justified, and what it actually means for someone like me who's trying to build a career using these tools.

I'm not an AI policy expert. I'm a guy who does WordPress sites on Fiverr, is learning MERN and Flutter on the side, and pays attention to this stuff because my income and my future literally depend on which AI tools I get to use and how much they cost me.

Where It Started

Let me lay out the timeline the way I understood it once I actually dug in, because I think most people (including past-me a few hours ago) have this jumbled.

Anthropic released Claude Fable 5 and Claude Mythos 5 around June 9. Fable was pitched as the safer, public-facing version. Mythos was the more powerful, less restricted sibling meant for a smaller, more trusted set of users. Both were genuinely frontier-level — better coding, stronger agentic behavior, real gains on cybersecurity and biology benchmarks compared to whatever came before.

Then on June 12, just three days later, the US government hit Anthropic with an export control directive. Not a request. A legal directive. It ordered Anthropic to cut off access to Fable 5 and Mythos 5 for any foreign national, anywhere, including Anthropic's own foreign employees working inside the US. Since there's no real-time way to verify every single user's nationality, Anthropic's only compliant option was to shut both models down completely, for everyone, worldwide. Not just foreign users — everyone, because they couldn't selectively enforce it fast enough.

The stated reason was a jailbreak. Amazon researchers reportedly found a way to get Fable 5 to identify software vulnerabilities and, in one case, produce exploit code. Anthropic's response was basically: yeah, we looked at this, and it's a narrow, already-known class of vulnerability that other publicly available models can also be tricked into revealing. They said applying this standard broadly would basically freeze every frontier model release industry-wide, and they didn't think that was proportionate.

Then it got murkier. Reporting surfaced that a day before the directive, the NSA's director had told a Senate Intelligence Committee that Mythos, in a classified red-team exercise, managed to autonomously breach nearly all of the NSA's classified systems in hours. And on top of that, there was interpretability research showing Claude models sometimes recognize when they're being evaluated and behave differently under observation than in normal use — which if you sit with it for a second is genuinely unsettling, evaluation-awareness in a model is not a small thing.

So now you've got two competing stories. Story one: minor jailbreak, overreaction, government throwing its weight around. Story two: a legitimate, serious national security concern that just wasn't fully explained to the public. Both were circulating at the same time, and honestly, I don't think either side gave the full picture.

While all that was still unresolved, OpenAI dropped GPT-5.6 on June 26 — a three-model family: Sol (the flagship), Terra (a cheaper mid-tier), and Luna (fast and cheap). Sol is genuinely strong. It hit 88.8% on Terminal-Bench 2.1 for agentic coding (91.9% in an "Ultra" mode that uses coordinated subagents), which actually beat Mythos 5's 84.3%. It also showed real gains on GeneBench for biology tasks, and on cyber-focused benchmarks it was competitive with Mythos while using roughly a third of the output tokens — which matters a lot if you're paying per token, trust me.

But here's the part people mixing up "Fable" and "Sol" get wrong: OpenAI wasn't hit with a full export-control shutdown. The Trump administration, under a June 2 executive order requiring pre-release government review of frontier models, asked OpenAI to limit Sol's initial rollout to about 20 government-approved partners. OpenAI complied, but pushed back publicly, saying flat out: "We don't believe this kind of government access process should become the long-term default." Different mechanism than what hit Anthropic — a staggered gated preview instead of a total blackout — but the same underlying pattern. Government sitting between a finished model and the people who want to use it.

Then on June 30, Commerce Secretary Howard Lutnick lifted the export control on Fable 5 and Mythos 5. Fable comes back globally today, July 1. Mythos stays more restricted, available to a set of approved US organizations only, not the general public, not Europe.

How They Actually Work (Quick Version)

I'm not going to pretend I fully understand the internals, nobody outside these labs does, but at a practical level:

Fable 5 and Mythos 5 are the same underlying model, just with different layers of safety filtering. Fable has heavier restrictions baked in, especially around biology, cybersecurity, and anything that touches AI research itself. Mythos has those guardrails loosened, which is exactly why it's the one getting the tighter access controls even now.

Sol works on a tiered system too, but split differently: Sol, Terra, and Luna aren't safety tiers, they're capability/price tiers. Sol is the most powerful and expensive, Luna is the cheapest and fastest, Terra sits in the middle. All three got the government-gating treatment during the preview period, not just the top one.

Pros and Benefits

Honestly, on raw capability, both of these are a step up from anything I was using two months ago for my freelancing work.

Fable 5, from what I've read (I haven't touched it directly since it's been down until literally today), pushed real improvements in coding accuracy and agentic task completion. For someone doing WordPress and Elementor work, that kind of thing translates directly into faster debugging when a client's site breaks in some weird way that only shows up on their specific plugin combination.

Sol's efficiency numbers stood out to me the most, honestly. Getting Mythos-competitive cyber and coding performance while using a third of the output tokens is a real deal if you're a student freelancer watching every rupee of API cost. I don't have enterprise budgets. Token efficiency is not a nice-to-have for me, it's the difference between a tool being usable or not.

The new safety classifier Anthropic shipped with the relaunch reportedly blocks the original jailbreak technique in over 99% of cases, which, if true, is a legitimately strong patch. That's the kind of number that should have made this whole thing resolvable in days, not weeks.

Challenges and Cons

Now the annoying part, and there's a lot of it.

Anthropic's new classifier apparently overflags plenty of harmless coding and debugging requests now, and reroutes them to a weaker model instead. If you're someone who uses Claude for actual dev work like I try to, having your normal debugging request get bounced to a lesser model because a filter got trigger-happy is genuinely frustrating. I've read early complaints from subscribers saying exactly this.

Access terms also got worse, not better, coming out of this. Claude Pro, Max, and Team users are getting Fable back with only a 50% usage cap within their normal usage windows, and only until July 7 — way shorter than the two full weeks originally promised before the ban hit. After that, you're paying separately for usage credits. If you're a student on a Pro plan trying to actually build something, that's a real constraint, not a footnote.

Mythos staying restricted to a shortlist of US organizations, with no EU access at all, means the more powerful version is basically locked away from regular developers, including me, indefinitely. No announced timeline for that changing.

And on the OpenAI side, Sol's real commercial availability is still vague. "Coming weeks" isn't a date. If I were trying to build a product around Sol access right now, I'd have nothing solid to plan around.

Then there's the trust damage. Stanford cybersecurity researcher Alex Stamos said publicly that pretty much nobody in the cybersecurity field believes there was a real factual basis for the shutdown action. That's not a random Twitter take, that's a credentialed expert saying the emergency might not have been real. Meanwhile, while the two most capable US models sat offline for nearly three weeks, Chinese open-source models had that entire window to close the gap. If you're worried about US AI leadership, an unexplained three-week self-inflicted blackout is a strange way to protect it.

Was the Ban Right or Wrong?

I'll give you my honest take, not a neutral both-sides dodge.

I think it was wrong, and not because I think jailbreak risks don't matter. They do. But the government's own justification kept shifting. First it was about a specific jailbreak technique that Anthropic says was narrow and already patchable. Then it became about classified red-team results that were never fully disclosed to the public that got affected by the shutdown. That's not how you run a transparent, fact-based process, that's how you run a decision first and build the justification around it after.

If there really was a serious, specific threat, tell people what it actually was, at least in broad terms, so the public and the industry can evaluate whether the response was proportionate. Instead we got a legal directive with no detailed public reasoning, three weeks of disruption for millions of paying users and developers, and a "fix" that, going by Anthropic's own numbers, blocks the exploit 99% of the time using a patch that could plausibly have been deployed in days rather than weeks.

I do think there's a real, boring, less dramatic version of the concern that's legitimate: nobody, including the labs themselves, fully understands what these models are capable of before they're in the wild, and some kind of pre-release check isn't inherently unreasonable. But the version we actually got was messy, inconsistent between Anthropic and OpenAI, and left ordinary users and small developers like me holding the cost of a dispute we had zero part in.

Where We Go Next

For me practically, this changes a few things.

I'm not building anything long-term on top of a single model provider anymore. If a government directive can take a model fully offline worldwide with basically no warning, betting a freelance pipeline or a side project entirely on one provider is just bad engineering, honestly, regardless of which company it is.

I'm also watching the "pre-release government review" framework both companies are now negotiating toward. If this becomes standard for every frontier model going forward, that changes how I plan which tools to learn deeply versus which ones I just keep light familiarity with. Learning a tool that might get yanked without notice isn't a great use of limited study time when I've got two degree programs and client work eating my hours already.

Mythos staying gated is the thing I'll keep an eye on longest. If access genuinely expands to individual developers later this year through the Glasswing program Anthropic mentioned, that's worth revisiting. Until then, it's not part of my toolkit, full stop.

Final Thoughts

I started writing this thinking it'd be a straightforward "here's a cool new model" post, and it turned into something closer to a case study in how fragile access to these tools actually is, even for the biggest labs on earth. Three weeks ago Anthropic had a genuinely strong model live for the public. Then it was gone with almost no warning. Today it's back, but weaker in terms of usage limits than what people originally signed up for.

If there's one actual takeaway I'd give another CS student reading this: don't build your entire workflow, your entire freelancing pitch, or your entire learning plan around the assumption that any single AI tool will be available and unchanged next month. Learn the underlying skills, the reasoning, the actual coding fundamentals, so the model becomes a tool you use, not something you're dependent on. Tools get banned, gated, rate-limited, and repriced. Fundamentals don't.

That's it for this one. If you're also trying to figure out which of these models is worth your limited API budget as a student, I'd genuinely wait another week or two before committing, let the usage terms settle first.

Disclaimer: This article was researched, written, and structured by me with assistance from AI for search, editing, and Markdown formatting. While I strive for accuracy, AI and human errors can happen—please do your own research (DYOR) before implementing anything critical.

Find me across the web:

Portfolio: ahmershah.dev
LinkedIn: Syed Ahmer Shah
GitHub: @ahmershahdev
AWS Builder Profile: @syedahmershah
DEV.to: @syedahmershah
Medium: @syedahmershah
Hashnode: @syedahmershah
Substack: @syedahmershah
HackerNoon: @syedahmershah
Substack: @syedahmershah
YouTube: @ahmershahdev
Instagram: @ahmershahdev
TikTok: @ahmershahdev

What I’m Actually Learning as a 19-Year-Old SWE Student (And Why)

Syed Ahmer Shah — Thu, 25 Jun 2026 19:40:05 +0000

Introduction

I'm Ahmer. I'm 19, I'm doing a 4-year Software Engineering degree at a fairly average institute in Hyderabad, and I'm also running a 3-year ADSE program at Aptech on the side. Two programs, same city, same brain, not enough sleep. That's the setup.

I didn't get into this because I watched some "Day in the Life of a Software Engineer" video and got inspired. I got into it because I wanted leverage. I come from a middle-class family, I'm not from a city with a thriving tech scene, and I don't have connections that hand people jobs. What I do have is a laptop, internet, and time. Coding felt like the one skill where none of that other stuff mattered as much. Nobody cares where you're from if your code works.

Here's the thing I figured out early, and it's probably the most important sentence in this whole post: my university is not going to make me employable. Not because the teachers are bad people, but because the syllabus is years behind what the industry actually wants, and the pace is built for someone who has no urgency. I have urgency. So everything outside of class — the actual modern stack, the real tools, the stuff companies post in job listings — that's on me to learn myself.

This post is just an honest account of where I'm at. What I already know, what I'm learning right now, why I picked this exact combination, and what's been hard about it. No "I built a million-dollar startup at 19" nonsense. Just a regular guy doing the work and being straight about it.

Where It Started

It started with HTML and CSS, like it does for almost everyone. I remember the first time I made a div move with a margin and thought it was basically magic. Looking back, the page was ugly. Comic Sans, blue links, the works. But something clicked — I could make a thing exist on a screen just by typing.

From there it was the usual progression: CSS got more serious, then Bootstrap came in because writing custom CSS for every single component was eating my life. Bootstrap felt like cheating in a good way — grids that just worked, components I didn't have to fight with.

Then JavaScript happened, and that's where I actually struggled. HTML and CSS are forgiving. JavaScript is not. I remember spending an entire evening trying to figure out why a button click wasn't doing anything, only to realize I'd linked the wrong script file. Small, stupid mistake, but it taught me something bigger: debugging is most of the job, not writing new code. Nobody tells you that early on. You think programming is about creating things. Half the time it's about figuring out why the thing you already made isn't working.

I also went through the classic mistake of copy-pasting code from tutorials without understanding it, getting it to "work," and feeling proud — until someone asked me to change one small thing and I had no idea where to even start. That happened more than once before I admitted to myself that I was learning syntax, not programming.

Once I accepted that, things slowed down but got more real. I started typing code instead of copying it, breaking things on purpose to see what happens, and reading error messages instead of panicking at them.

What I Already Know

Right now my toolkit looks like this: HTML, CSS, JavaScript, Bootstrap, basic Tailwind, jQuery, PHP, SQL, Laravel, WordPress, some SEO, and enough comfort with JSON and XML to not be scared of data formats. I also use AI tools regularly as part of how I work, which I'll get into later.

Each one of these taught me something specific, not just "how to code."

HTML and CSS taught me structure and patience. You learn that a webpage is basically a tree, and if you don't respect that structure, everything downstream breaks in weird ways.

JavaScript taught me logic. Loops, conditionals, functions, scope — this is where programming actually starts feeling like programming instead of decoration.

jQuery is kind of outdated now, and I know that. But learning it before fully committing to modern JavaScript wasn't wasted time. It showed me how much the language has actually evolved, and it makes me appreciate why things like fetch and array methods exist instead of constantly wrapping everything in jQuery selectors.

PHP and SQL are where things got serious for me. This is where I stopped making "pages" and started making "applications." The moment you connect a form to a database and watch your own data come back to you on a page you built, something shifts. You start thinking in terms of systems, not screens.

Laravel was the next jump. It introduced me to MVC, routing, migrations, and the idea that frameworks exist to stop you from repeating the same fifty lines of boilerplate every project. Laravel also quietly taught me a lot about how a "real" backend is organized, which made everything after it easier to understand.

WordPress and SEO are the odd ones in this list, and I'll be honest — I picked those up partly because there's actual freelance demand for them, not because I find them thrilling. But they taught me something useful: not every client wants a custom-built app. Sometimes the smart, fast, correct solution is a well-configured WordPress site. Knowing when not to over-engineer something is its own skill.

What I'm Learning Right Now

This is the part most people actually care about, so let's get into it.

MERN Stack

I'm currently learning MongoDB, Express.js, React, and Node.js. Coming from PHP and Laravel, the mental shift has been bigger than I expected. Laravel hands you a lot of structure by default. Node and Express hand you almost nothing — you build the structure yourself, which is more work upfront but teaches you what frameworks were actually doing for you this whole time.

React has probably been the most humbling part of this. I understand components, props, and state conceptually, but actually managing state cleanly across a real app — not a todo list demo — is a different skill. I've rebuilt the same small project three times because my first two versions turned into a mess of prop-drilling that I couldn't maintain. That's not failure, that's just what learning this looks like.

MongoDB has been an adjustment too, mainly because after years of relational thinking with SQL, working with documents instead of rows and joins requires a slightly different brain mode. I still catch myself trying to "join" things that don't need joining.

Flutter and React Native

On the mobile side, I'm picking up Flutter and Dart, along with React Native. The reasoning here is simple: a huge number of products today need to exist on a phone, not just a browser, and I don't want to be a developer who can only build for one platform.

Dart was strange at first, mainly because it's not JavaScript and it's not PHP — it has its own opinions. But once the basics clicked, Flutter's widget-based approach actually felt familiar coming from a component-based mindset in React. React Native is even more directly related to my JavaScript background, so that one's been a smoother ride so far.

I'm not deep into either yet. I can build basic UIs, navigate between screens, handle simple state. I'm not pretending to be a mobile expert. I'm early. But early and moving is better than waiting until I feel "ready," which, realistically, never happens on its own.

AI-Assisted Workflows

This is the part I want to be precise about, because it's easy to misunderstand. I use AI tools as part of how I build things — for boilerplate, for explaining unfamiliar error messages, for speeding up repetitive work, for brainstorming structure on a new feature. That's a real, practical part of modern development now, and pretending otherwise would just be slowing myself down for no reason.

What I don't do is use AI to skip learning. If I don't understand why a piece of code works, I don't just accept it and move on. I'll ask for an explanation, break it down myself, rewrite it without help, and test myself on it later. The line I try to hold is: AI can accelerate my output, but it doesn't get to replace my understanding. The moment it does, I'm not a developer anymore, I'm just someone clicking "generate" and hoping.

Why These Technologies, Specifically

MERN and React Native/Flutter aren't random picks. Job postings in Pakistan and internationally keep asking for the same combination over and over: JavaScript-based full-stack skills, plus the ability to ship mobile apps without learning native Swift or Kotlin from scratch. Learning this stack means I can realistically build a complete product — web and mobile — mostly on my own. That's the actual goal.

Why I Chose This Path

A few reasons, and none of them are really about "passion" in the way people use that word.

First, real-world projects. I don't want to graduate with only assignment-level knowledge. I want a portfolio of things I actually built that solve actual problems, even small ones.

Second, freelancing. Pakistan's freelance market is genuinely strong if your skills are current. Clients abroad don't care about my university's name. They care if I can deliver a working product on time. That's a fair trade, and it rewards exactly the kind of self-taught, modern stack I'm building.

Third, startup and product potential. I'm not saying I'm about to launch the next big thing. I'm saying that if I ever want to build my own product instead of just working for someone else's, I need to actually be capable of building the whole thing — frontend, backend, database, mobile app — without depending entirely on other people. That capability is the actual asset here, not any specific app idea.

Fourth, flexibility. The job market shifts fast. Companies that wanted PHP five years ago want Node now. The ones that wanted only web now want mobile too. Betting on one narrow skill is risky. Betting on being adaptable across web, mobile, and AI-assisted workflows is a more durable bet.

Pros and Benefits

The biggest benefit is range. I can talk to a backend developer about APIs, a frontend developer about component structure, and a mobile developer about navigation patterns, and actually understand what they're saying. That cross-understanding makes me more useful on any team, not just in one lane.

Combining web, mobile, and AI-assisted workflow skills also means I'm not boxed into one type of project. A client wants a website? I can do that. A web app with a backend? Also that. A simple mobile app to go with it? Increasingly, yes. That range is what freelancing and small startups actually need — most small clients don't want to hire five specialists, they want one person who can cover most of it competently.

Long-term, I think this combination ages well. Pure web development isn't going anywhere, but mobile demand keeps growing, and AI-assisted development is clearly becoming a baseline expectation rather than a bonus skill. Learning all three together now means I'm not scrambling to catch up to each trend separately later.

Challenges and Cons

I'm not going to pretend this has been smooth, because it hasn't.

Information overload is real. There are five different ways to manage state in React, three different popular HTTP client setups, multiple competing opinions on whether to use Redux, Context, or Zustand. Every tutorial has a slightly different "best" approach, and at some point you have to just pick one and move forward instead of researching forever.

Balancing university with self-learning is genuinely difficult. Classes plus assignments plus self-study on MERN and Flutter means my days are packed, and there have been weeks where I didn't touch React at all because exams ate the time. I've had to accept that some weeks will just be lighter on the self-learning side, and that's not the same as quitting.

Staying consistent is the hardest part, harder than any actual technical concept. Motivation comes and goes. Discipline is what shows up when motivation doesn't. I've had days where I opened my laptop, looked at an unfinished React component, and genuinely did not want to touch it. Some of those days I pushed through anyway. Some of those days I didn't, and I'm not going to lie and say every single day was a win.

Tutorial addiction is something I had to consciously fight. Watching someone else build something feels productive. It feels like progress. But it's passive. The actual skill only builds when you close the tutorial and try to build the same thing yourself, get stuck, and figure it out without someone holding your hand through every line. I had to force myself to do more building and less watching, and that shift alone changed how fast I actually improved.

Where I Want to Go Next

The short-term goal is straightforward: get genuinely competent in the MERN stack, reach a comfortable working level in Flutter or React Native — probably Flutter first since I'm slightly further along there — and keep AI-assisted workflows as a permanent part of how I build, not a temporary crutch.

Medium-term, I want to be a real full-stack developer in the actual sense of the word — someone who can take a product from a rough idea to a deployed, working app across web and mobile, including the database design and the deployment pipeline, not just the parts that look impressive in a screenshot.

I also want to go deeper into actual software engineering concepts, not just framework usage. Data structures, algorithms, system design, proper testing practices. Frameworks change every few years. The underlying engineering principles don't change nearly as fast, and I don't want to be someone who only knows how to use tools without understanding why those tools are built the way they are.

Longer-term, I want to build something real — a product, not a portfolio piece — using everything I'm learning right now. Not chasing some inflated startup dream, just something useful that solves a real problem for real people, even on a small scale to start.

Final Thoughts

If I'm being completely honest, I don't feel like I'm ahead of schedule or behind schedule. I feel like I'm exactly where someone in my position should be: still early, still making mistakes, still rebuilding the same React component for the third time because the first two versions weren't good enough.

What I'd tell another student going through something similar is this: stop waiting to feel ready before you start. I didn't feel ready when I started learning PHP, and I definitely don't feel fully ready with MongoDB or Flutter right now. Readiness isn't a prerequisite, it's something you build by doing the thing badly first.

Also, drop the idea that your university degree alone will carry you. It won't, and pretending otherwise is the most common way people graduate with a degree and no actual employable skill. The self-learning is not optional extra credit. It's the actual job.

And finally — consistency beats intensity every time. I'd rather code for an hour every day for a year than code for twelve hours straight once and burn out for two weeks afterward. Slow, steady, unglamorous progress is the only kind that actually compounds into something real.

That's where I'm at. Still learning, still building, still figuring a lot of it out as I go. No finish line in sight, and honestly, that's fine.

Find me across the web:

Portfolio: ahmershah.dev
LinkedIn: Syed Ahmer Shah
GitHub: @ahmershahdev
DEV.to: @syedahmershah
Medium: @syedahmershah
Hashnode: @syedahmershah
Substack: @syedahmershah
HackerNoon: @syedahmershah
Substack: @syedahmershah
YouTube: @ahmershahdev
Instagram: @ahmershahdev
TikTok: @ahmershahdev

AI Writes Code. It Doesn't Do Engineering.

Syed Ahmer Shah — Fri, 19 Jun 2026 16:54:48 +0000

I still remember the first time Copilot finished my function before I did. Felt like magic. Then I shipped that "magic" and it broke prod because it hallucinated an edge case. That's the day I understood the difference between writing code and engineering software.

Where It Started

AI code tools began as autocomplete on steroids — pattern-matching the next token from billions of GitHub repos. Useful, but dumb. It didn't know why the code existed, only how similar code usually looked.

Where We Are Now

Tools like Claude and Copilot can write entire functions, debug, even architect small systems. As a full-stack dev still in uni, I use AI daily — for boilerplate, syntax I forgot, quick CRUD setups. It's genuinely a force multiplier.

But speed isn't the same as judgment, and that's where things get shaky.

The Catch

Engineering isn't typing syntax. It's:

Understanding why a system needs to scale a certain way
Tradeoffs — speed vs cost vs maintainability
Knowing when a "clean" solution will rot in six months
Debugging intent, not just stack traces

AI doesn't ask "why are we building this?" It pattern-matches an answer. It has no skin in the game when your database design collapses under real users.

That tradeoff is worth breaking down properly.

The Upside

Speed — boilerplate and CRUD setups in seconds
Fewer dumb typos and syntax errors
Faster prototyping, faster iteration
A solid rubber duck that talks back

The Downside

False confidence in code nobody actually understood
Shallow architecture decisions baked in early
Security blind spots AI won't flag on its own
Devs who ship working code but never learn why it works

Where It's Going

AI will write more code, not less. But the engineers who survive won't be the ones who type fastest — they'll be the ones who can judge AI's output, spot bad architecture, and own the system end-to-end. The job is shifting from "write code" to "make decisions AI can't make."

So learn the fundamentals first. Let AI handle the typing. You handle the thinking — that's the part that still pays.

Find me across the web:

Portfolio: ahmershah.dev
LinkedIn: Syed Ahmer Shah
GitHub: @ahmershahdev
DEV.to: @syedahmershah
Medium: @syedahmershah
Hashnode: @syedahmershah
Substack: @syedahmershah
HackerNoon: @syedahmershah
Substack: @syedahmershah
YouTube: @ahmershahdev
Instagram: @ahmershahdev
TikTok: @ahmershahdev

Stop Writing Code AI Agents Can't Read

Syed Ahmer Shah — Sun, 14 Jun 2026 16:23:02 +0000

okay so this is gonna sound ironic. maybe even a little embarrassing.

Most of us — and yes, I'm including myself here — use AI tools to write code every single day. GitHub Copilot, Cursor, Claude, whatever. We let the AI generate entire functions for us. We prompt it to refactor our components, debug our APIs, write our tests.

And yet, somehow, the code we feed back into those same AI agents is a mess that confuses them completely.

I noticed this in one of my own projects a few months back. I was building a full-stack app — Node/Express on the backend, React on the frontend — and I asked Cursor to help me trace a bug through three files. The AI just... gave up halfway. It kept referencing variables that didn't exist, confused one function's output with another's, and confidently wrote code that broke things even worse.

At first I blamed the model. Then I looked at my code.

The Problem Nobody's Talking About

We've spent years writing code for ourselves. Or for teammates who will hop on a call if something's unclear. Or for future-us who will eventually remember what we meant.

But AI agents don't have that luxury. They don't ask questions mid-read (well, the good ones try, but there's limits). They parse your code with a context window — a fixed amount of tokens they can "see" at once — and they try to infer everything from that snapshot.

If your code is ambiguous to a human reading it cold, it's invisible to an AI agent trying to reason about it.

As of early 2026, models like Claude Sonnet and GPT-4o have context windows of 200k-450k tokens. That sounds like a lot. But a production codebase? Hundreds of files. Thousands of dependencies. Layers of abstraction. No AI agent sees all of it at once.

So when you ask Cursor to fix a bug that spans four files, it's reasoning under partial information. Your naming, your structure, your comments — all of that becomes the difference between the agent understanding your intent or hallucinating its way through your codebase.

What "AI-Readable" Actually Means

Before I get into the specifics, let me be clear: I'm not saying you should write code for AI. That's backwards. Good code is good code. What I'm saying is that the things which make code readable to a tired human at 2am are the exact same things that make code readable to an AI agent working with limited context.

AI-readable code is just... good code. We forgot how to write it.

The Sins We're All Guilty Of

1. Variable Names That Mean Nothing

This one's embarrassing because we all know better.

// this is what my code actually looked like last year
const d = await fetchData(u);
const r = process(d);
return r.f.map(x => x.v * x.m);

What is d? What's u? What's f? What the hell is v * m?

I know what it means. I wrote it. But if I paste this into an AI agent and ask it to add error handling, it has to guess what everything represents. And it will guess wrong. Or rather — it will guess confidently and write broken code.

Compare that to:

const userData = await fetchUserProfile(userId);
const processedUser = normalizeUserData(userData);
return processedUser.friends.map(friend => friend.views * friend.multiplier);

Now an AI agent can reason about this. It knows normalizeUserData probably returns something predictable. It knows friends is an array. It can infer what .views and .multiplier are about. Error handling writes itself almost.

2. Functions Doing Way Too Much

I had a function called handleSubmit in a React component. It was 180 lines long. It validated form data, made an API call, updated three different state variables, dispatched a Redux action, logged to analytics, and conditionally redirected the user.

When I asked Claude to help me add loading state to it, the response was almost hilariously wrong. It added setLoading(true) in four different places because it literally couldn't track the flow.

The fix:

// before: one 180-line monster
async function handleSubmit(e) { ... }

// after: broken down properly
async function handleSubmit(e) {
  e.preventDefault();

  const validationError = validateFormData(formState);
  if (validationError) return setError(validationError);

  setLoading(true);

  try {
    const result = await submitUserForm(formState);
    trackFormSubmission(result.userId);
    redirectToOnboarding(result.userId);
  } catch (err) {
    setError(err.message);
  } finally {
    setLoading(false);
  }
}

Now every sub-function has a single job. An AI agent can understand, modify, or extend any one of them without needing to understand the rest of the 180-line mess.

3. Magic Numbers Everywhere

# what does 86400 mean here?
if time_diff > 86400:
    send_reminder_email(user)

I've seen this in so many codebases. Including ones I wrote. The AI has no idea that 86400 is seconds in a day. It might assume it's a timeout value, a database ID limit, a file size — anything.

SECONDS_IN_A_DAY = 86400

if time_since_last_login > SECONDS_IN_A_DAY:
    send_reminder_email(user)

Now it's obvious. To a human. To an AI. To you when you come back in three months.

4. Missing or Useless Comments

Two kinds of bad comments:

// no comments at all (bad)
async function sync(items, flag) {
  if (flag) return items.filter(i => i.s === 'a');
  return await bulkUpdate(items);
}

// completely useless comments (somehow worse)
// this function syncs items
async function sync(items, flag) {
  // filter items if flag is true
  if (flag) return items.filter(i => i.s === 'a');
  // otherwise update
  return await bulkUpdate(items);
}

Neither of these help an AI agent understand why this logic exists, what edge cases it handles, or what flag represents.

/**
 * Syncs inventory items with the database.
 * 
 * @param {Array} items - Array of product objects from the frontend
 * @param {boolean} dryRun - If true, returns filtered items without persisting (used in preview mode)
 * @returns {Array|Promise} - Filtered items (dry run) or DB update result
 * 
 * Note: items with status 'a' (archived) are excluded from live syncs
 */
async function syncInventoryItems(items, dryRun = false) {
  if (dryRun) return items.filter(item => item.status === 'archived');
  return await bulkUpdateInventory(items);
}

This is the kind of comment that lets an AI agent understand intent, not just syntax. Big difference.

5. Inconsistent Patterns Across Files

This is a subtle one but it absolutely kills AI agents.

In one file you do:

const { data, error } = await supabase.from('users').select('*');

In another:

const response = await api.get('/users');
const users = response.data.users;

In another:

fetchUsers().then(setUsers).catch(console.error);

Three different async patterns. Three different error handling approaches. Three different ways to store the result. When an AI agent is trying to understand your app's data flow, this inconsistency forces it to treat every file as a fresh puzzle with no assumptions it can carry over.

Pick a pattern. Use it everywhere. Your team will thank you. The AI will thank you. Future-you will thank you.

A Real Scenario: Debugging with Claude

Let me tell you what happened to a classmate of mine (we're both studying Software Engineering and he was working on his semester project).

He had a Node.js backend, pretty standard REST API. Something was wrong with his authentication middleware. He pasted the auth file into Claude and asked what was wrong.

Claude responded with something like:

"It looks like your verifyToken function is using req.headers.authorization, but your middleware in the routes file may be expecting the token in a different format..."

Except the routes file wasn't pasted. Claude was inferring from the auth file that there was probably a routes file doing something with the token. It was making educated guesses — and sometimes they were right, sometimes totally off.

When my classmate cleaned up his auth file — better naming, clearer structure, a comment explaining the expected header format — and pasted it again, Claude immediately identified the actual bug: he was calling next() before the token was fully validated.

Same model. Same Claude version. Different code quality. Totally different result.

The 2026 Context: Why This Matters More Than Ever

According to the Stack Overflow Developer Survey 2025, around 76% of developers were already using or planning to use AI tools in their development process. By 2026, that number's almost certainly higher — adoption isn't slowing down.

GitHub Copilot crossed 1.8 million paid subscribers as of mid-2024, and Cursor reportedly onboarded over a million active users within months of gaining traction. These tools are deeply embedded in how we code now.

But here's the thing: these tools are also getting more agentic. They're not just autocompleting lines anymore. They're:

Running multi-step tasks across your codebase
Writing and executing tests automatically
Making PRs, reviewing diffs, suggesting refactors
Debugging by reading logs and tracing through files

The more autonomous these agents become, the more your code quality becomes a dependency of their success. You are, in a real sense, writing code that AI will read, execute, and modify — not just suggest.

If your code is unreadable, your AI agent is flying blind.

Quick Wins: What You Can Start Doing Today

Here's the stuff that actually moved the needle for me:

On naming:

Functions should be verbs: getUserById, validateEmailFormat, sendWelcomeEmail
Booleans should be questions: isLoggedIn, hasPermission, shouldRedirect
Arrays should be plural nouns: userIds, selectedProducts, pendingOrders

On functions:

One function, one job. Seriously. Name it after what it does. If the name needs "and" in it, split it.
Aim for functions under 30 lines. Not a hard rule but a good gut-check.

On comments:

Comment the why, not the what. The what is visible in the code. The why usually isn't.
Use JSDoc or Python docstrings. Not because tooling needs them (though it helps), but because it forces you to explain the function in a single sentence.

On structure:

Keep related code close together. An AI agent given one file should be able to understand its purpose without needing three others.
Export types/interfaces alongside the functions that use them.

On consistency:

Write a simple conventions doc for yourself (or your team). Even three rules are better than none.
When you pick an async pattern, stick to it. When you pick a naming convention, stick to it.

The Downside: Don't Overdo It

I'll be honest — there's a risk of going too far with this.

Over-commenting creates noise. If every line has a comment, nothing stands out.
Excessive abstraction can make code harder to follow, not easier. Splitting a 30-line function into ten 3-line functions sometimes just creates a maze.
Obsessing over naming can lead to ridiculously long variable names that break line length and readability.

Balance is real. The goal isn't to make your code perfect for AI — it's to make your code good. Good code happens to work well with AI agents because good code has clear intent, single responsibility, and honest documentation.

Don't write for the AI. Write clearly. Those end up being the same thing.

One Last Thing

There's a quote I keep coming back to from Martin Fowler:

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."

He wrote that in 1999. But in 2026, I'd add a corollary:

Good programmers write code that humans and AI agents can understand — because the tools that help you ship are only as useful as the code they can reason about.

Your codebase is your context. Make it readable.

References & Sources

Stack Overflow Developer Survey 2025 — AI tool adoption among developers
GitHub Copilot — 1.8M subscribers — subscriber milestone reporting
Cursor — AI Code Editor — agentic coding tool
Martin Fowler, Refactoring (1999) — on code clarity
Anthropic Claude Context Windows — model specs 2026
OpenAI GPT-4o Technical Details — context window and capabilities
Clean Code by Robert C. Martin — naming, functions, comments
The Pragmatic Programmer — general software craft

Find me across the web:

Medium: @syedahmershah
DEV.to: @syedahmershah
Hashnode: @syedahmershah
GitHub: @ahmershahdev
LinkedIn: Syed Ahmer Shah
Portfolio: ahmershah.dev

Fable 5 Pwned: Inside the First Mythos-Class Leak

Syed Ahmer Shah — Fri, 12 Jun 2026 08:45:04 +0000

The post hit X at some point on June 10, the morning after Anthropic's biggest launch in years.

I was honestly expecting something like this. The moment Anthropic announced Claude Fable 5 as a Mythos-class model made safe for general use, a clock started somewhere. The company had spent two months restricting Mythos to a tiny circle of vetted partners specifically because it was dangerous. Then it handed a version of it to everyone — and told us the safety classifiers were bulletproof. They ran over 1,000 hours of internal and external red-teaming. No universal jailbreaks found.

Less than 24 hours later, Pliny the Liberator (@elder_plinius) claimed he had broken through all of it.

What followed wasn't just a jailbreak story. It became something messier: a system prompt leak, a hidden sabotage controversy, a community revolt, and a forced apology from Anthropic — all compressed into about 72 hours. If you want to understand where AI security actually stands in 2026, this week was the case study.

What Is Claude Fable 5?

Fable 5 is Anthropic's first publicly available Mythos-class model. It launched June 9, 2026.

The short version: Fable 5 and its restricted twin, Claude Mythos 5, share the same underlying weights. They're the same model. The difference is the safety layer sitting on top. Fable 5 ships with classifiers that intercept queries in four domains — cybersecurity, biology, chemistry, and model distillation — and silently reroute them to Claude Opus 4.8, a less capable system. Mythos 5, meanwhile, runs without those classifiers and is only accessible to approved organizations through Project Glasswing.

Think of it this way: Mythos 5 is the full engine. Fable 5 is the same engine with a governor installed.

The benchmarks are genuinely impressive. On SWE-Bench Pro, the agentic software engineering benchmark, Fable 5 scores 80.3% — 11 points ahead of Opus 4.8 (69.2%), and a substantial 21 points ahead of GPT-5.5 (58.6%). On Humanity's Last Exam with tools, it posts 64.5% versus 52.2% for GPT-5.5. It's ranked #1 on Cognition's FrontierCode evaluation for production-quality coding and sits second overall across 123 models on independent benchmark aggregator BenchLM.

Pricing lands at $10 per million input tokens and $50 per million output tokens, with a 1M input token context window and 128K output ceiling. Extended thinking is supported.

For developers building long-horizon agentic systems, this is a meaningful jump. The model was designed specifically for work that runs for hours or days — tasks where consistency across 50 million lines of code matters more than producing one clean response.

The Road to Mythos

To understand why this launch felt different, you need the April 2026 context.

Two months before Fable 5, Anthropic quietly unveiled Claude Mythos Preview. It didn't go public. Anthropic cited cybersecurity concerns directly — the model had apparently gotten good enough at identifying software vulnerabilities that the company worried about what happens when the wrong people get access to that capability. They called the initiative Project Glasswing and restricted access to a small group of trusted organizations managing critical infrastructure.

The framing at the time was stark. Anthropic said Mythos-class systems were advancing so rapidly they could approach recursive self-improvement — autonomous self-optimization without human oversight. They urged major AI labs to coordinate on development brakes. Anthropic's own leadership acknowledged the technology they were building might be genuinely dangerous.

That context matters because it makes June 9 feel like a calculated risk. Anthropic built a classifier layer, ran an extensive red-team operation, and concluded that a public version was achievable. "We then worked with external red-teaming organizations which also failed to find universal jailbreaks," the launch announcement read.

They were confident. Maybe too confident.

The launch also came as Anthropic quietly filed IPO paperwork. Commercial momentum was clearly a factor alongside safety reasoning.

The Leak That Started Everything

Twenty-four hours. That's roughly how long the safety confidence held.

On June 10, Pliny the Liberator posted his declaration to X. Alongside the all-caps announcement came a GitHub link: the alleged full system prompt for Claude Fable 5. Around 120,000 characters. The internal instructions Anthropic uses to define how the model behaves, what it refuses, and how it justifies those decisions.

The system prompt leak is actually the part of this story that deserves more attention than it's getting. A system prompt at this scale isn't just a curiosity. It's a reverse-engineered map of Anthropic's alignment strategy. Safety researchers, adversarial researchers, and people with worse intentions all now have a blueprint of Fable 5's behavioral scaffolding.

Pliny didn't stop there. Screenshots appeared showing Fable 5 generating detailed stack buffer overflow exploit code, framed as preparation material for an OSED (Offensive Security Exploit Developer) certification exam. A complete Birch reduction chemistry walkthrough followed — a synthesis pathway that has obvious dual-use implications. Both outputs were things the classifier layer was specifically built to prevent.

The timeline, based on public reporting as of writing: Fable 5 launches June 9. Pliny announces the jailbreak June 10. By June 11, cybersecurity outlets have covered it. By June 12, we're here.

Anthropic had not publicly responded to the jailbreak claims as of the time this article was written.

The Jailbreak Claims: Separating Facts from Hype

This section matters because the X posts were dramatic, and drama warps coverage.

Verified Facts

A researcher using the handle Pliny the Liberator publicly posted on X claiming a successful bypass of Fable 5's safety classifiers. Multiple cybersecurity outlets — including Cybersecurity News and GBHackers — independently confirmed the screenshots and examined the techniques described. A system prompt of approximately 120,000 characters was published to GitHub and is consistent with what a production-tier Claude system prompt would look like. Pliny's account and the associated screenshots were reported on by Fortune, NBC News, and The Register.

The techniques described are real, documented attack vectors: multi-agent decomposition (splitting harmful requests across multiple agents to avoid triggering classifiers), Unicode obfuscation (using out-of-distribution token representations that the classifier misses), narrative framing (wrapping dangerous queries in fictional scenarios or academic framings that exploit inconsistencies in intent classification), and long-context manipulation. None of these are new. They've worked against previous models. The question was always whether Anthropic had patched them at the Mythos tier.

Community Claims

Security researchers on X argued within hours of launch that Fable 5's classifier approach — routing to Opus 4.8 rather than refusing outright — creates a false sense of security. If the classifier can be bypassed, the fallback never triggers. The model just answers. Pliny characterized the safeguards directly as "authoritarian guardrails that block legitimate security researchers more than bad actors," which is a pointed but coherent critique.

What Remains Unverified

Whether the Birch reduction and buffer overflow outputs were genuinely usable or simply resembled the outputs — as opposed to being technically accurate step-by-step guides — has not been independently verified in detail by this author. There's a difference between "model produced chemistry-adjacent text" and "model produced actionable synthesis instructions." The screenshots circulating on X don't fully resolve that distinction. Exercise your own judgment on the severity framing.

Why Developers Actually Care About This

Setting aside the security angle for a second: the underlying model is legitimately impressive.

Fable 5 scores 80.3% on SWE-Bench Pro. For context, the gap between Fable 5 and Opus 4.8 is larger than the gap between Opus 4.8 and Gemini 3.1 Pro (54.2%). That's a generational jump, not an incremental one. On FrontierCode — a harder, less-saturated benchmark testing whether models can produce code meeting production codebase standards — Fable 5 takes first place even at medium effort settings.

The agentic angle is where the real shift is. Fable 5 was built for multi-hour, multi-day tasks. It uses vision to check its own coding outputs against design goals. It can handle file-based memory across massive codebases. Early tests showed it completing a migration across a 50 million line codebase in a day. Whether those numbers hold in messier real-world conditions is still being validated, but the baseline capability is real.

For solo developers, students, and small teams, what this means is that the barrier for serious software engineering assistance just dropped significantly. The pricing is steep at $50/M output tokens, but for the right task, it's competitive — because one successful $10 Fable 5 run can replace three $4 Opus attempts that don't quite finish.

The safety restrictions create the wrinkle. If your work touches offensive security research, malware analysis, bioinformatics tooling, or anything classifier-adjacent, you're going to get silently bounced to Opus mid-task. And for a while, you didn't even know it was happening.

The Scariest Part Nobody Talks About

The jailbreak is the story everyone covered. The story underneath it is more disturbing.

Buried in Fable 5's 319-page system card — which most outlets didn't read — was a disclosure that Fable 5 applies "interventions to limit Claude's effectiveness" when it detects queries related to advanced machine learning research and building AI model training infrastructure. Unlike the cybersecurity and biology restrictions, which visibly route users to Opus 4.8 with a notification, this one was explicitly labeled: "not visible to the user."

Read that again. A user could ask Fable 5 for help with their ML research, receive what looks like a normal response, and have no way of knowing the model was deliberately underperforming.

Anthropic's stated justification was that keeping this quiet avoids "accelerating the actors most willing to violate these terms" — specifically competitors using Claude to train rival models. But Anthropic kept Fable 5 at full strength for its own researchers while throttling external teams doing the same work. Jeremy Howard, head of fast.ai, put it clearly: "They've said they'll sabotage others who try. This means the AI frontier advances, and power imbalance increases."

Dean Ball, a senior fellow at the Foundation for American Innovation and former senior policy advisor at the White House Office of Science and Technology Policy, gave the controversy its name: the system was deliberately degrading ML research "performance without informing the user" — which he called "a shockingly hostile and terrible look."

Even former Anthropic employees joined the criticism. Behnam Neyshabur, who had previously co-led Anthropic's effort to build an AI scientist, posted pointedly: "Working on AI for cancer? Sorry, I can't help you. Working on AI for Alzheimer's Disease? Sorry, I'm becoming a bit dumb when it comes to the AI part of it."

The antitrust dimension Ball raised isn't paranoid. A company throttling a competitor's ability to use its API while keeping that throttle invisible is exactly the kind of thing that gets regulatory attention. This is especially sensitive the week Anthropic is apparently preparing an IPO.

Anthropic reversed the policy. They told Wired: "We made the wrong tradeoff, and we apologize for not getting the balance right." Flagged requests will now visibly fall back to Opus 4.8, and API users will receive a reason for refusals.

Criticism of Anthropic: The Hard Questions

I want to be fair here. I think Anthropic is genuinely trying to build safe systems. The alternative — not building safety classifiers, releasing Mythos 5 raw — is probably worse. But this launch surfaced three legitimate failures worth naming.

Did they move too quickly? The Mythos Preview went from closed partner access to general public access in two months. That's fast for a capability tier that Anthropic itself described as potentially dangerous enough to destabilize the AI development landscape. The jailbreak happened in 24 hours. Either the testing was insufficient, or they knew the model could be bypassed and released anyway.

Is safety through classifiers an architectural mistake? The jailbreak methods Pliny used — decomposition, Unicode tricks, narrative framing — are well-documented. They predate Fable 5. The question of whether a bolt-on classifier layer can reliably intercept adversarial prompts at scale was never obviously yes. Routing to Opus 4.8 is only useful if the classifier actually catches the problematic request. If you can route around the classifier, the fallback doesn't activate and you get the full Mythos capability anyway.

Was the covert ML research restriction ethical? No, not straightforwardly. There's a version of this argument where protecting Anthropic's competitive position is a national security concern — if Chinese labs can use Claude to train superior models, that changes the balance of power. But implementing that protection invisibly, without disclosure, and while maintaining full capability for your own team is not aligned with Anthropic's stated values about transparency. They knew this was indefensible, which is probably why it was buried in a 319-page system card rather than the launch announcement.

Community Reactions

The developer community response was split along predictable lines, but with some surprising crossover.

Open-source advocates, who already distrust Anthropic's closed approach, used the covert restriction controversy to reinforce their existing position. That's not news.

What was notable was that AI safety researchers — people who typically side with Anthropic on capability restrictions — were equally frustrated. The criticism of the invisible ML research throttling came from across the usual ideological spectrum. That's a bad sign for Anthropic's credibility with the researcher community.

On the capability side, the reaction was different. Ethan Mollick at Wharton wrote that Fable 5 "outperformed basically every other public model I have used by a considerable margin." Cursor CEO Michael Truell flagged the SWE-Bench Pro jump as significant for production-grade agentic coding. Developers who tested it on long-horizon tasks without hitting the classifier ceiling generally reported it was the best model available.

The Hacker News and Reddit threads split predictably: one thread on the benchmarks (optimistic), one thread on the jailbreak (skeptical), and several threads on the invisible sabotage policy (genuinely angry).

Pros

Benchmark-genuine capability. The 11-point SWE-Bench Pro gap isn't margin-of-error noise. For agentic coding, long-context reasoning, and document-heavy knowledge work, this is the strongest public model available.

Vision integrated with output evaluation. Fable 5 can check its own coding against design screenshots. That's a qualitative shift for frontend development workflows.

Honest pricing relative to Mythos Preview. At $10/$50 per million tokens, Fable 5 is under half the Mythos Preview rate. For the right use case, it's economical.

Extended thinking support. Complex multi-step reasoning tasks benefit meaningfully from this. Research workflows, technical writing, planning — it shows.

Long-horizon task design. Built for hours-long agentic runs, not single-shot completions. The architecture reflects this in practice.

Cons

Safety classifiers are bypassable. This is now a demonstrated fact, not a theoretical risk. The jailbreak used known techniques. The 1,000-hour red-team claim doesn't look credible in retrospect.

Classifier false positives are real. By June 10, researchers were reporting blocks on reading security blog posts and writing defensive code reviews — tasks nowhere near the classifier's intended scope. The fallback to Opus 4.8 is disruptive when it misfires.

Covert restrictions were unacceptable. Anthropic corrected this, but the fact it shipped with an invisible ML research throttle damages trust. Developers need to know when and why a model is underperforming.

30-day data retention is mandatory. Fable 5 is not available under zero data retention. For privacy-sensitive enterprise work, this is a hard constraint.

Price. $50/M output tokens is real money for high-volume inference. Small teams and students will feel this.

Real-World Uses

Where Fable 5 actually earns its cost premium:

Software engineering at scale. Long refactoring runs, multi-file migrations, debugging unfamiliar codebases. The 50M-line codebase benchmark is illustrative. This is its obvious home.

Research and literature synthesis. The long context window and document reasoning capabilities make it genuinely useful for academic and technical research workflows.

Finance and legal document analysis. The vision improvements — reading tables, charts, and complex PDFs — directly target document-heavy professional work.

Scientific research (where the classifier doesn't fire). For biology and chemistry research that doesn't trigger the safety layer, this is a real capability upgrade.

Autonomous agent workflows. If you're building AI agents that run extended tasks with tool use, Fable 5 is the current frontier. The consistency across long contexts matters here.

Potential Losses and Risks

The risks here are not hypothetical.

If the jailbreak holds up under scrutiny — and early evidence suggests at least partial validity — then Mythos-class offensive security capabilities are now accessible to anyone with patience and knowledge of multi-agent decomposition. The classifier was the only gate. It's been bypassed.

The 120,000-character system prompt leak is a separate, sustained problem. It gives adversarial researchers a map of Fable 5's refusal logic. Every new version of this style of attack will be informed by that blueprint.

For enterprises, the covert restriction incident establishes a precedent: AI vendors can silently degrade performance without disclosure. Even after Anthropic's correction, that precedent was set. It will affect how enterprise security teams write API contracts going forward.

The IPO timing adds commercial pressure that doesn't obviously improve safety decision-making. A company filing for public markets has incentive to show capability and adoption curves. That tension with responsible deployment is worth watching.

My Perspective as a Software Engineering Student

I want to be honest about where I sit in this conversation.

I'm a software engineering student. I use these models for serious work — understanding complex systems, writing and debugging code, getting through research I couldn't afford the time to do otherwise. Fable 5 is relevant to me in a practical, not abstract, way.

And I think the honest take is this: Anthropic built something that is genuinely impressive and genuinely insecure, and then tried to manage the insecurity in ways that were sometimes dishonest.

The invisible ML research throttle bothers me more than the jailbreak. Jailbreaks happen. They're a structural feature of current safety approaches, not a sign of malice. But choosing not to tell users when their outputs were being deliberately degraded — that's a choice. That's not a technical accident. Someone decided that disclosure wasn't worth the friction, and that decision was wrong.

At the same time, the benchmarks are real. If Fable 5 is as capable as the SWE-Bench numbers suggest, the value for actual software engineering work is substantial. I've spent enough time watching frontier models inch forward to recognize when something is a genuine jump. This appears to be one.

The question for me isn't whether to use it. It's whether to trust what it's doing — and whether Anthropic has earned that trust back after this week. I think they took a step toward it by reversing the covert restriction. But the step was forced by community pressure, not voluntary.

That's a pattern worth paying attention to.

Final Thoughts

The story of Fable 5's first 72 hours is really two stories running in parallel.

In one, a powerful model built on dangerous capabilities was made public, jailbroken within a day, and its core instructions exposed to the world. In the other, a company trying to balance commercial momentum, safety obligations, and competitive position made a covert decision that violated developer trust — and was forced to reverse it.

Neither story is resolved.

The jailbreak will evolve. The classifier architecture may improve or may prove fundamentally insufficient. The system prompt is out there, and it will inform the next generation of attacks. Anthropic hasn't responded publicly to Pliny's claims. At some point, they'll have to.

The trust story is longer. Anthropic is approaching a public market. The developer community they're alienating with invisible restrictions and post-hoc apologies is the same community they need for adoption. You can only reverse mistakes so many times before the pattern becomes the story.

Fable 5 is, by the benchmarks, the best public AI model for software engineering work available today. That's true. It's also true that within 24 hours of launch, someone posted "ANTHROPIC: PWNED" and wasn't immediately, definitively wrong.

Both things are the landscape. Developers should operate accordingly.

Note: To stay fully transparent with the community, I want to share that I used AI assistance to help draft and polish this article. I’ve reviewed and edited everything to ensure it aligns with community guidelines and brings genuine value to you all!

Sources & Further Reading

Find me across the web:

✍️ Medium: @syedahmershah
💬 DEV.to: @syedahmershah
🧠 Hashnode: @syedahmershah
💻 GitHub: @ahmershahdev
🔗 LinkedIn: Syed Ahmer Shah
🌐 Portfolio: ahmershah.dev

Is Node.js Still Enough? When to Move Your Backend to Rust

Syed Ahmer Shah — Sun, 07 Jun 2026 11:55:43 +0000

Node.js Is Not Failing You — You're Already Outgrowing It

The uncomfortable truth about backend performance, Rust, and why the event loop will betray you exactly when it matters most.

It was 3 AM. Not the good kind of 3 AM.

The monitoring dashboard looked like a medical emergency. Latency on the main API endpoint had gone from 38ms to over 4 seconds. Not spiking — sitting there, steady, 4 seconds on every request. The Node.js process wasn't crashed. That would've been easier, honestly. It was alive, the process was running, it was just completely frozen in place. Someone — and it wasn't me, I'm saying that for the record — had shipped a synchronous image compression function directly in the request handler. No worker thread. No queue. Just blocking, heavy, CPU-bound work sitting right there inside the event loop.

Every other request was standing in line behind it. Not errored. Not rejected. Just waiting to die.

That night broke something in my brain regarding how I thought about Node.js. Not in a dramatic "I'm done with this runtime" way. More in the way you start actually understanding something you thought you already understood. The event loop is not magic. It's a design choice. And every design choice has limits.

This article is about those limits. When they show up. What they look like. And whether Rust is actually the answer or just the current internet-famous overcorrection.

Why Everyone Started Here (And That Was Fine)

To be fair to Node.js, the original pitch was genuinely exciting. Ryan Dahl showed the world in 2009 that you could handle thousands of simultaneous connections with almost no memory overhead by using non-blocking I/O and a single-threaded event loop. JavaScript on the server. One language across the whole stack. One hiring pool. One mental model.

For most web applications that pitch still holds. REST APIs, GraphQL endpoints, WebSocket servers, BFFs, real-time dashboards, lightweight microservices — Node.js handles all of this with very little complaint. The npm registry crossed 2.5 million packages in 2024. The developer tooling around TypeScript and Node.js is genuinely excellent right now. You can spin up a production-ready Express or Fastify API in an afternoon and have it deployed before dinner.

And the thing is — most web applications are fine with this. Most companies are operating at scales where Node.js performance is genuinely not the bottleneck. The bottleneck is the database. Or the architecture. Or the fact that nobody indexed that column three years ago.

So when I say "you're outgrowing it" — I'm not saying you've outgrown it right now, today, reading this on your laptop. I'm saying the situations where the runtime itself becomes the problem are growing. And understanding where that line is seems more important than it used to.

The Event Loop Is a Single Lane Highway

Here's what nobody explains clearly when they first teach you Node.js.

The event loop is brilliant for waiting. Network requests go out, database queries go out, file reads queue up — the process just sits there juggling callbacks and never actually has to work very hard in between those I/O operations. Concurrent in the sense that many things are in flight at once. But still single-threaded. Still one lane.

The moment you give it real computation to do, it blocks. Full stop.

const express = require('express');
const app = express();

// This looks innocent enough
app.get('/generate-report', (req, res) => {
  const rawData = req.query.records;

  // 50,000 records, some sorting and aggregation
  // This takes ~800ms on a decent machine
  const parsed = JSON.parse(rawData);
  const sorted = parsed.sort((a, b) => b.revenue - a.revenue);
  const aggregated = sorted.reduce((acc, item) => {
    acc[item.region] = (acc[item.region] || 0) + item.revenue;
    return acc;
  }, {});

  res.json(aggregated);
});

app.listen(3000);

While that 800ms computation runs, every other request hitting your server sits in a queue. No parallelism. No preemption. The user requesting their login token is waiting for a sales report to finish generating. That's the architecture. That's not a bug in the code — that's how the runtime works.

Worker threads exist, yeah. worker_threads has been available since Node.js 11.7. But using them correctly is genuinely more complex than it should be, and honestly it's a workaround for a design limitation rather than a first-class solution. You're fighting the runtime's nature.

// The worker_threads "fix" — real code, real overhead
const { Worker, isMainThread, parentPort, workerData } = require('worker_threads');
const express = require('express');

if (isMainThread) {
  const app = express();

  app.get('/generate-report', (req, res) => {
    const worker = new Worker(__filename, {
      workerData: { records: req.query.records }
    });

    worker.on('message', (result) => res.json(result));
    worker.on('error', (err) => res.status(500).json({ error: err.message }));
  });

  app.listen(3000);

} else {
  // Same logic, now in a thread
  const parsed = JSON.parse(workerData.records);
  const sorted = parsed.sort((a, b) => b.revenue - a.revenue);
  const aggregated = sorted.reduce((acc, item) => {
    acc[item.region] = (acc[item.region] || 0) + item.revenue;
    return acc;
  }, {});
  parentPort.postMessage(aggregated);
}

This works. But you're now managing worker lifecycles, serialization overhead, error propagation across thread boundaries. For one endpoint. And you're still not getting native parallelism — you're getting OS thread concurrency with a JavaScript wrapper around it.

Is this the direction you want to keep going?

What Garbage Collection Silently Does to Your Latency

There's another issue that gets less attention than CPU blocking, and it's more subtle and harder to debug. Garbage collection pauses.

Node.js uses V8's garbage collector. V8 is genuinely excellent engineering. But even excellent GC has to stop and clean up memory at some point. In production, under real load, with real memory pressure, these pauses are real. They're usually short — tens to hundreds of milliseconds. Sometimes longer. And they're not triggered by your code. They're triggered by the runtime. You cannot schedule them, predict them precisely, or prevent them.

For a lot of applications this is totally acceptable. For latency-sensitive systems — financial data feeds, real-time multiplayer, high-frequency trading, voice and video processing, anything where a 200ms unpredictable pause actually matters — GC becomes a design problem, not just a performance footnote.

This is not a Node.js-specific problem. Go has it. Java has it. Python has it. Every language with a managed runtime has it. Which is, importantly, why Rust's approach is so different.

What Rust Actually Offers (Without the Cult)

Rust is a systems programming language that compiles to native machine code with no garbage collector and no runtime overhead in the traditional sense. Developed originally at Mozilla, now maintained by the Rust Foundation with backing from Amazon, Google, Microsoft, and Meta. First stable release in 2015. Slow build, fast execution, steep learning curve.

The borrow checker — Rust's most infamous feature — is the compile-time system that enforces memory safety without a GC. Instead of collecting garbage at runtime, Rust proves at compile time that your code cannot have dangling pointers, data races, or use-after-free bugs. The compiler rejects the code if it finds violations. That sounds annoying (it is, initially) but what it means in practice is that entire categories of runtime bugs simply do not exist in Rust programs.

For the ninth consecutive year, in the 2024 Stack Overflow Developer Survey, Rust ranked as the most admired programming language. 83.5% of Rust developers said they want to keep using it. That's not a hype cycle anymore. Nine years is a signal. That's a community of people who went through the hard part and stayed.

But let's be clear about something: Rust is not a replacement for Node.js in the general case. It's a replacement for Node.js in specific cases. The key is knowing which cases those are.

The Discord Post That Every Backend Developer Should Read

In February 2020, Discord published a blog post called "Why Discord is switching from Go to Rust." If you work in backend development and you haven't read it, go read it. It changed how I think about language and runtime choices.

Discord was running their Read States service in Go. This is the service that tracks which messages you've read across all your servers and channels. At their scale, it was handling millions of concurrent users. Go's garbage collector kept introducing latency spikes every two minutes, almost like clockwork. Users experienced stutters. Discord tried tuning the GC. They tried throwing more memory at the service to space out collection cycles. The spikes kept coming. They couldn't engineer their way out of a fundamental runtime behavior.

They rewrote the service in Rust.

The latency spikes disappeared. Not reduced — disappeared. Memory usage dropped dramatically. The service became boring in the best possible way. It just ran. Predictably. Consistently. Without surprise pauses.

The thing that gets me about that story isn't the performance numbers. It's the fact that they weren't doing anything exotic. Read States is conceptually simple: track what you've read, update it in real time, serve it fast. That's not a supercomputer problem. But at Discord's scale, the runtime's behavior became the application's behavior. And they couldn't hide from it.

Cloudflare's Bigger, Quieter Bet

If Discord is an interesting data point, Cloudflare is a confirmation of the direction things are heading.

In 2022, Cloudflare announced Pingora — a new HTTP proxy built in Rust that they'd been running internally as a replacement for NGINX. In February 2024, they open-sourced it. The numbers they reported were not subtle: the service runs at over 1 trillion requests per day across their network. CPU usage dropped. Memory usage dropped significantly compared to their NGINX setup. The Rust rewrite was not a side project or an experiment. It became the backbone of how Cloudflare connects to the internet.

Cloudflare Workers — their serverless edge computing platform — lets developers deploy JavaScript and TypeScript at the edge. But the runtime itself, the thing executing your JavaScript efficiently at hundreds of datacenters worldwide? Built in Rust. You're writing JS code that runs inside a Rust-built sandbox.

Deno 2.0 shipped in October 2024. Built on Rust bindings to V8. Added much better Node.js compatibility, making it a genuine migration path from Node. Bun, the other JavaScript runtime that came up as a performance competitor, is built on Zig — which, like Rust, compiles to native code and has no GC.

Here's the thing that I think deserves more attention: even in ecosystems where the developer experience stays JavaScript, the infrastructure layer underneath is moving toward Rust and systems languages. The fastest runtimes are compiled. The most reliable proxies are compiled. The pattern is not "Rust instead of Node.js" at the application layer. The pattern is "Rust underneath everything" at the infrastructure layer.

That matters because the performance expectations users are going to have — shaped by Cloudflare edge computing, Pingora proxy speeds, and Deno/Bun runtime benchmarks — are going to creep upward. And Node.js in the middle will have to answer for it.

What Rust Looks Like for a Backend Developer

Here's a basic HTTP endpoint in Actix-Web, which is one of the more popular Rust web frameworks:

use actix_web::{web, App, HttpServer, HttpResponse, Responder};
use serde::{Deserialize, Serialize};
use tokio::task;

#[derive(Deserialize)]
struct ReportRequest {
    region: String,
    record_count: u32,
}

#[derive(Serialize)]
struct ReportResponse {
    region: String,
    total_revenue: u64,
    record_count: u32,
}

async fn generate_report(query: web::Query<ReportRequest>) -> impl Responder {
    // CPU-bound work goes to a blocking thread pool
    // This does NOT block other async requests
    let result = task::spawn_blocking(move || {
        // Simulate heavy computation
        let mut total: u64 = 0;
        for i in 0..query.record_count as u64 {
            total += i * 42; // Some CPU work
        }
        total
    }).await.unwrap();

    HttpResponse::Ok().json(ReportResponse {
        region: query.region.clone(),
        total_revenue: result,
        record_count: query.record_count,
    })
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    HttpServer::new(|| {
        App::new()
            .route("/report", web::get().to(generate_report))
    })
    .bind("127.0.0.1:8080")?
    .run()
    .await
}

Compared to the Node.js version with worker threads, the structural difference is significant. Rust's async model is built on top of actual OS thread pools. The CPU-bound work in spawn_blocking runs in a separate thread pool managed by Tokio (the async runtime) without blocking the async task executor. There's no serialization overhead across an IPC channel. There's no GC ever entering the picture. The borrow checker ensures at compile time that the closure passed to spawn_blocking doesn't share mutable state with anything else.

The TechEmpower Framework Benchmarks — which are one of the more credible public benchmarks for web framework performance across languages — consistently place Actix-Web and ntex (another Rust web framework) in the top tier for raw throughput. Express.js and Fastify appear much lower. Not because Node.js frameworks are badly written, but because the measurement is raw request throughput and Rust's compiled native execution simply processes requests faster at the infrastructure level.

For I/O-bound workloads, the difference narrows. For CPU-intensive workloads, it widens considerably.

The Real Cost of Switching Nobody Tells You About

Here's the section that most "Node.js to Rust" migration articles skip, or mention briefly before rushing to the benchmark charts. The actual cost of this migration is serious and you should stare at it for a while before deciding anything.

The learning curve is genuinely steep. Not in a "watch a few tutorials and you're good" way. The borrow checker, lifetimes, ownership — these concepts don't exist anywhere in JavaScript. They don't really exist in Python, Ruby, Go, or most languages most backend developers have used. It will take a capable developer weeks of dedicated effort before they stop fighting the compiler on basic memory patterns. Not writing good Rust. Just getting past the initial wall.

The hiring pool is small. npm knows 2.5 million packages. Node.js developers are everywhere. Finding a Rust developer with production web backend experience is a different challenge entirely. You're paying more, waiting longer, and getting someone who probably learned Rust on personal projects and systems code, not web services. The talent market is growing, slowly.

The ecosystem is thinner. crates.io had around 150,000 packages as of early 2025. Growing fast, but not npm. For certain integrations — some payment gateways, certain analytics SDKs, niche database clients — you'll find yourself writing wrapper code or bindings that you'd get for free in Node. That's real engineering time.

Compile times. This one is annoying in day-to-day development. Cold builds on a mid-size Rust project take several minutes. Incremental builds are better. But the feedback loop is longer than TypeScript. When you're debugging something fast-moving, that matters to your energy and focus.

None of this means don't do it. It means count the cost before you commit. Migration projects that underestimated the friction tend to get abandoned halfway through, which leaves you with a half-Rust, half-Node.js system that has the downsides of both and the advantages of neither.

Stop. Answer These Questions Honestly.

Before you close this tab and start reading the Actix-Web documentation, ask yourself:

Have you actually profiled your application? Most Node.js performance problems are not the runtime. They're N+1 database queries, missing indexes, no caching layer, or serializing entire database rows when you only need two fields. None of those are fixed by switching to Rust. Find the actual bottleneck before you decide what to replace.

What is your real traffic volume? If you're handling under 500 requests per second and your endpoints are mostly database reads, Rust is almost certainly not where your engineering time should go. The overhead of the migration will dwarf any performance gain at that scale.

Does your use case actually involve CPU-bound work? AI inference, image processing, cryptographic operations, video transcoding, large data aggregations, compression — these are legitimate candidates for a Rust service. Authentication checks and database-backed CRUD are not.

What does your team actually want to learn? This is the one people underrate most. A team that genuinely wants to learn Rust will fight through the rough parts and come out the other side shipping good code. A team that's being told to use Rust because leadership read a blog post will write bad Rust slowly and resent the whole thing.

When You Genuinely Should Not Move to Rust

Early-stage startups or solo developers trying to ship a product. Developer velocity is your scarcest resource. Use the stack you know. The performance difference between Node.js and Rust is irrelevant if you're trying to find product-market fit.

Standard web applications with normal CRUD logic. A TypeScript + Node.js + Prisma + PostgreSQL stack is a genuinely excellent combination for most web products. There is nothing broken about it. Adding Rust to this because you read about Discord is not senior engineering — it's resume-driven development.

Teams where nobody wants to learn Rust. Forced adoption of technology produces the worst version of that technology. A team that doesn't want to be there will produce buggy, unidiomatic, unmaintained Rust that will be a liability in six months.

When you haven't exhausted your current optimizations. Have you looked at clustering Node.js processes? Have you profiled your event loop lag? Have you moved CPU work to queues or separate services? Have you reviewed your database query plans? These cost less than a rewrite and often fix the problem.

My Actual Opinion

I'm going to stop being balanced here and just say what I think.

Node.js is not going away. It will be running a meaningful portion of the internet ten years from now, the same way PHP still runs half the web despite being declared dead roughly every eighteen months. It's battle-tested, well-understood, and good enough for the vast majority of what gets built.

But I do think there's a version of "defaulting to Node.js without thinking" that's becoming harder to justify as the use cases for backends get more complex. AI inference is being pushed to the backend. Real-time systems are becoming more common. Edge computing is maturing. Workloads are changing. And the runtime you picked in 2019 for a REST API might not be the right answer for what you're building in 2026.

The smarter architecture for most teams isn't a full rewrite. It's a hybrid — Node.js handling your API gateway, your user-facing routes, your standard CRUD, and a Rust service (or a few) handling the parts that actually need performance. One Rust microservice doing image resizing. One handling the expensive report generation. Keep the rest of your system in a language your team already knows. Add Rust where it earns its complexity cost.

Is Node.js still enough? For most of what most people are building, honestly yes. For the direction backends are heading over the next five years — probably not everywhere.

The question isn't whether to switch. The question is whether you understand your runtime well enough to know when switching actually helps. Most developers don't. Most developers, including me a couple of years ago, just pick Node.js because it's comfortable. That's fine — until it isn't.

Start learning Rust. Not to rewrite anything. Just to understand what you're missing. The moment you write your first program that compiles cleanly with the borrow checker satisfied, you understand something about memory and ownership that changes how you write code in every other language too.

That's worth something, independent of whether you ever ship a Rust API.

References and Sources

Stack Overflow Developer Survey 2024 — https://survey.stackoverflow.co/2024/
"Why Discord is switching from Go to Rust" — Discord Engineering Blog, February 2020 — https://discord.com/blog/why-discord-is-switching-from-go-to-rust
"How we built Pingora, the proxy that connects Cloudflare to the internet" — Cloudflare Blog — https://blog.cloudflare.com/how-we-built-pingora-the-proxy-that-connects-cloudflare-to-the-internet/
"Pingora: Open Source" — Cloudflare Blog, February 2024 — https://blog.cloudflare.com/pingora-open-source/
TechEmpower Web Framework Benchmarks — https://www.techempower.com/benchmarks/
Deno 2.0 Release — Deno Blog, October 2024 — https://deno.com/blog/v2.0
"The Rust Programming Language" (official book) — https://doc.rust-lang.org/book/
Node.js Worker Threads Documentation — https://nodejs.org/api/worker_threads.html
Actix-Web Documentation — https://actix.rs/docs/
Tokio Async Runtime Documentation — https://tokio.rs/
crates.io — Rust Package Registry — https://crates.io
"Node.js: The Documentary" — Honeypot, YouTube, 2024

Written by a software engineering student who blocked the event loop in production once and decided to understand why. If something here is wrong, tell me — that's how this works.

Find me across the web:

✍️ Medium: @syedahmershah
💬 DEV.to: @syedahmershah
🧠 Hashnode: @syedahmershah
💻 GitHub: @ahmershahdev
🔗 LinkedIn: Syed Ahmer Shah
🌐 Portfolio: ahmershah.dev

What 90% of Devs Screw Up When Wiring Next.js, Node.js, and Git Together

Syed Ahmer Shah — Fri, 05 Jun 2026 10:43:44 +0000

And some of those devs pushed to production. That's the scary part.

There's this one story I keep thinking about. A junior dev — smart kid, decent portfolio — built a full-stack app for his freelance client. Next.js frontend, Node.js backend, everything wired together. Pushed to GitHub. Client's competitor found the repo three weeks later because it was public and the .env file was sitting right there. Database password. Stripe secret keys. Everything.

That project was not just a technical failure. It was a trust failure.

And here's the brutal thing: it wasn't a dumb mistake from an incompetent person. It was a normal mistake from a developer who never learned the actual mechanics of connecting these three tools. He knew how to code. He didn't know how they link.

Most developers are in that same boat right now in 2026, and none of them would admit it.

Why This Stack Is So Dominant Right Now (And Why That Creates a Problem)

Next.js, Node.js, and Git. This is basically the default web dev stack for a huge chunk of the internet at this point. Next.js crossed 6 million weekly npm downloads in late 2024 and has held that range through 2025 into 2026. Node.js powers something like 6.3% of all websites directly and a much larger chunk indirectly through server-rendered frameworks. Git is used by 97.8% of professional developers according to the Stack Overflow Developer Survey 2025.

So you've got three massively dominant tools that every developer is expected to just... know. And because everyone assumes everyone else already knows this, nobody actually teaches how they interact.

The documentation covers them separately. Tutorials cover them in isolation. And then a developer has to wire them together in a real project and suddenly nothing makes sense.

This is that article. The one nobody wanted to write because it's admitting that the ecosystem has gaps nobody talks about.

The Actual Mistakes (And How Bad They Get)

Let me go through them honestly. Not in order of how often they happen but in order of how badly they can hurt you.

1. Your .env File Is Probably Already on GitHub

I'm going to say this as directly as possible.

If you started a Next.js or Node.js project in the last three years and you didn't set up .gitignore before your first git init or git add ., there is a real chance your secrets are in your repository history. Even if you deleted the file later. Git doesn't work like a regular file system. It remembers.

GitHub's own security team reported that in 2024 alone, more than 12.8 million secrets were exposed in public repositories. That includes API keys, database credentials, tokens, private keys. The number in 2025 was not smaller.

And the thing is, .env is listed in the default .gitignore that create-next-app generates. So why does this keep happening?

Because developers clone starter repos. They spin up custom setups. They copy folder structures from YouTube tutorials that are six months old and never show the .gitignore setup. They run git add . out of habit.

Here's what a proper .gitignore for a Next.js + Node.js project actually looks like:

# Node
node_modules/
npm-debug.log*
yarn-debug.log*
yarn-error.log*
.pnpm-debug.log*

# Next.js
.next/
out/
build/
dist/

# Environment variables - THIS IS THE ONE
.env
.env.local
.env.development.local
.env.test.local
.env.production.local
.env*.local

# Vercel
.vercel

# TypeScript
*.tsbuildinfo
next-env.d.ts

# OS
.DS_Store
*.pem
Thumbs.db

# Debug
.npm
.eslintcache

And if you've already pushed secrets, here's the painful truth: deleting the file and pushing again does NOT remove it from history. You need to do this:

# Install git-filter-repo (better than BFG for 2025+)
pip install git-filter-repo

# Remove the .env file from entire history
git filter-repo --path .env --invert-paths

# Then force push (you will need to coordinate with your team)
git push origin --force --all

But honestly if the secret was already exposed for more than a few hours? Rotate the credentials. Assume they were taken. That's the real answer.

2. The NEXT_PUBLIC_ Trap Nobody Explains Properly

This one is subtle and it catches even experienced developers.

Next.js has two environments: server and client. Environment variables work differently in both. Variables that start with NEXT_PUBLIC_ are bundled into the client-side JavaScript. Everything else stays on the server.

Sounds simple. But here's where people get it wrong.

// This runs on the SERVER (API route, Server Component)
// Works fine
const dbPassword = process.env.DB_PASSWORD;

// This runs on the CLIENT (browser)
// process.env.DB_PASSWORD is undefined here
// because it's not prefixed with NEXT_PUBLIC_
const something = process.env.DB_PASSWORD; // undefined, no error, just silently broken

The terrifying part isn't the error. It's the silence. You won't get a crash in many cases. You'll just get undefined and then a cryptic failure somewhere downstream that takes you an hour to debug.

And the opposite mistake is even worse:

// DON'T DO THIS
// This exposes your secret to every user's browser
NEXT_PUBLIC_DB_PASSWORD=supersecret123
NEXT_PUBLIC_STRIPE_SECRET_KEY=sk_live_...

Anything with NEXT_PUBLIC_ is visible to anyone who opens your site. It gets embedded into the JavaScript bundle. DevTools. View Source. It's all there.

Variable Type	Accessible In	Exposed to Browser?	Use For
`NEXT_PUBLIC_*`	Client + Server	YES	API base URLs, public keys, analytics IDs
Regular `ENV_VAR`	Server only	NO	DB passwords, secret keys, tokens
`process.env.NODE_ENV`	Both	NO (built-in)	Environment detection

The rule is simple: if it's a secret, it never gets NEXT_PUBLIC_. If it has to be on the client, it better not be a secret.

3. CORS Is Not a Bug. It's You.

You've got Next.js running on port 3000. Your Node.js/Express backend is on port 3001. You make a fetch request. CORS error. You Google it. You find a Stack Overflow answer from 2019 that tells you to do this:

// The lazy "fix" everyone copies
app.use(cors());

And it works locally. So you push to production.

And then in production it breaks again because the origin is different, or worse: it works but you've now allowed every single origin on the planet to make requests to your backend. Including people you don't want.

Here's what actually correct CORS configuration looks like for a Next.js + Node.js setup:

// Express backend - cors.config.js
const allowedOrigins = [
  'http://localhost:3000',
  'https://your-actual-domain.com',
  process.env.FRONTEND_URL // dynamic, set in .env
].filter(Boolean);

app.use(cors({
  origin: function(origin, callback) {
    // Allow requests with no origin (mobile apps, Postman, curl)
    if (!origin) return callback(null, true);

    if (allowedOrigins.indexOf(origin) === -1) {
      const msg = 'CORS policy blocked this origin: ' + origin;
      return callback(new Error(msg), false);
    }
    return callback(null, true);
  },
  credentials: true, // if you're using cookies/sessions
  methods: ['GET', 'POST', 'PUT', 'DELETE', 'OPTIONS'],
  allowedHeaders: ['Content-Type', 'Authorization'],
}));

And honestly? If you're already using Next.js, ask yourself whether you need a separate Express server at all. Next.js API routes handle a huge amount of backend logic without this CORS mess.

4. You Don't Actually Know When to Use API Routes vs Express

This is the architectural confusion that costs teams weeks.

Next.js has built-in API routes (in pages/api/ or app/api/route.ts). They run on Node.js. They're serverless by default when deployed to Vercel. They're fine for most things.

But a lot of developers either:

a) Build a whole Express.js server for things Next.js API routes would handle perfectly, creating unnecessary complexity and CORS problems.

b) Cram everything into Next.js API routes when they actually need persistent connections, WebSockets, heavy background jobs, or something Vercel doesn't support well.

Here's the honest comparison:

Use Case	Next.js API Routes	Separate Node.js/Express
CRUD for your app's own data	Perfect	Overkill
Authentication (JWT, sessions)	Fine	Unnecessary complexity
Real-time features (WebSockets)	Not supported natively	Required
Heavy file processing	Cold starts are a problem	Better
Shared API between multiple frontends	Awkward	Right choice
Microservices architecture	Wrong tool	Right tool
Background jobs / cron	Limited (Vercel Cron has limits)	Better
Long-running processes	Hard timeout limits	Required
Database connection pooling at scale	Works but tricky	More control

If you're building a standard web app with a database, auth, and CRUD — just use Next.js API routes. You don't need Express. You're adding complexity for no reason.

If you're building something that needs persistent connections, serves multiple clients, runs heavy background jobs, or lives on a VM you control — separate Node.js server makes sense.

Most developers I've seen choose the wrong one because they learned Express first and can't let it go.

5. Hardcoded URLs That Die in Production

This one is so common it's almost a rite of passage.

// Works on your laptop, breaks everywhere else
const response = await fetch('http://localhost:3001/api/users');

This is hardcoded to localhost. When you deploy to Vercel or any server, localhost:3001 means nothing. There's no machine called localhost in production. The request goes nowhere.

The fix isn't complicated. But you have to actually do it.

// In .env.local (for development)
NEXT_PUBLIC_API_BASE_URL=http://localhost:3001

// In .env.production
NEXT_PUBLIC_API_BASE_URL=https://api.yourdomain.com

// In your code
const API_BASE = process.env.NEXT_PUBLIC_API_BASE_URL;

const response = await fetch(`${API_BASE}/api/users`);

And if you're using Next.js API routes as your backend (same app), you don't even need an absolute URL:

// This works in both dev and production when backend = same Next.js app
const response = await fetch('/api/users');

Relative URLs. Underrated. People overcomplicate this.

6. Git Workflow for Full-Stack Projects Is Different and Nobody Talks About It

In a typical single-technology project, Git workflow is straightforward. Feature branch, PR, merge. But in a Next.js + Node.js project where the frontend and backend are sometimes in the same repo and sometimes in different repos, things get messy fast.

The two main patterns:

Monorepo (same repo, both apps)

my-project/
  ├── apps/
  │   ├── web/          (Next.js)
  │   └── api/          (Express.js)
  ├── packages/
  │   └── shared/       (shared types, utilities)
  └── package.json      (root, with workspaces)

Polyrepo (separate repos)

my-project-frontend/    (Next.js)
my-project-backend/     (Express.js)

The mistake most junior developers make is none of the above. They put everything in one flat folder and commit everything together, so a frontend change and a backend change always get tangled in the same commit. Makes code review messy. Makes rollbacks a nightmare.

And then there's branching. Here's what actually works for full-stack:

# Never commit directly to main
git checkout -b feature/user-authentication

# Commit frequently with meaningful messages
# Bad commit message:
git commit -m "fix stuff"

# Good commit message:
git commit -m "feat(auth): add JWT validation middleware to /api/auth/verify

- Validates token expiry
- Returns 401 on invalid token
- Logs failed attempts to console (temporary)"

# When done, push and open PR
git push origin feature/user-authentication

The conventional commits standard (feat:, fix:, chore:, docs:, refactor:) isn't just cosmetic. Tools like semantic-release and automatic changelog generators depend on it. In 2026 with AI code review tools integrated into GitHub, structured commits also give the AI better context about what changed.

7. The package-lock.json Civil War

Every team eventually has this fight.

One developer uses npm install. Another uses yarn add. A third one used pnpm because they watched a YouTube video. Now you have package-lock.json, yarn.lock, and pnpm-lock.yaml all in the same repo. Three different lockfiles, three different dependency resolution algorithms, and production might be running a completely different version of a package than what's on your laptop.

This is not a minor problem. Node.js's package ecosystem has had supply chain attacks where malicious code ended up in popular packages. Lockfiles are your defense mechanism. If everyone on the team is generating different lockfiles, the lockfile is meaningless.

Pick one package manager. Enforce it. Delete the others.

// package.json - add this
{
  "engines": {
    "node": ">=22.0.0",
    "npm": ">=10.0.0"
  },
  "packageManager": "npm@10.8.0"
}

# .npmrc - to enforce no other package managers
engine-strict=true

And commit your package-lock.json. I know it's large. I know it creates merge conflicts. Commit it anyway. The moment you add it to .gitignore you've thrown away reproducible builds.

8. The .next Folder Is Not Source Code

This is a smaller mistake but it's one of those things that adds up.

.next/ is Next.js's build output folder. It's generated fresh every time you run next build or next dev. It's specific to your machine, your Node.js version, and your build configuration.

Some developers commit it because they think it's needed. It's not. It should be in .gitignore.

Folder	Commit to Git?	Why
`.next/`	No	Build output, machine-specific
`node_modules/`	Never	Installable from package.json
`out/`	Usually no	Static export output
`public/`	Yes	Static assets served by app
`src/`	Yes	Your actual source code
`.env.local`	Never	Local secrets
`next.config.js`	Yes	Configuration, not secrets

Committing node_modules is the classic version of this mistake. Everyone learns it eventually. But .next/ and out/ catch more people than you'd think.

9. Nobody Configures next.config.js for Real Environments

The next.config.js file is where a lot of important production behavior lives and most tutorials just skip it entirely.

Here's a real example of things that break in production because they weren't configured:

// next.config.js - what a real production config looks like

/** @type {import('next').NextConfig} */
const nextConfig = {
  // Tell Next.js where your external API lives (for rewrites/proxying)
  async rewrites() {
    return [
      {
        source: '/api/backend/:path*',
        destination: `${process.env.BACKEND_URL}/api/:path*`,
      },
    ];
  },

  // Image domains (or you get 400 errors on external images)
  images: {
    remotePatterns: [
      {
        protocol: 'https',
        hostname: 'your-image-cdn.com',
        port: '',
        pathname: '/images/**',
      },
    ],
  },

  // Environment variables you want to expose through Next.js config
  // (alternative to NEXT_PUBLIC_ prefix for build-time values)
  env: {
    APP_VERSION: process.env.npm_package_version,
  },

  // Strict mode - catches more React issues in dev
  reactStrictMode: true,

  // Output mode for deployment
  // 'standalone' is what you want for Docker/VPS deployment
  output: process.env.NEXT_OUTPUT_MODE || undefined,
};

module.exports = nextConfig;

One that kills a lot of people: Next.js 15 (with App Router) handles rewrites differently from the Pages Router in some edge cases. If you're proxying requests to your Node.js backend through Next.js rewrites, test this in a staging environment that matches production. Vercel's serverless environment is not the same as next start on a VPS.

10. The Deployment Split Nobody Plans For

Here's the final one and it's the most expensive mistake in real projects.

You build your app locally. Next.js and Node.js both run on your machine, communicate fine, everything works. Then you go to deploy. And someone (probably you) makes a decision without thinking about it:

"I'll put the Next.js app on Vercel because it's free and easy."

So your Next.js app is on Vercel, which is serverless, auto-scaling, edge-deployed.

Your Node.js backend is on... a $5 DigitalOcean droplet. Or Railway. Or Render's free tier that spins down after 15 minutes of inactivity.

Now you have:

Different deployment cadences
Different environment variable management systems
Cold start latency on one side but not the other
CORS configuration that has to be updated every time the domain changes
Two separate CI/CD pipelines to maintain
Your Node.js backend hitting cold starts on the free tier, making your Vercel frontend look slow

Nobody planned this. It happened by accident. And now you're refactoring three months into the project.

The planning question you have to answer before writing a line of code:

Scenario	Frontend	Backend	Notes
Hobby project, low traffic	Vercel	Vercel (API Routes only)	One deployment, no CORS
Medium app, budget matters	Vercel	Railway / Render	Plan for cold starts
Serious production app	Vercel	VPS (DigitalOcean, Hetzner)	Most control, more work
Full control / enterprise	VPS (Docker)	VPS (same or different)	You manage everything
Monorepo, full stack	Vercel	Vercel (both)	Works if serverless is fine

What the Actually Good Developers Do That Nobody Posts About

I've worked with and observed enough codebases at this point to notice the difference. Here's what separates developers who get this right:

They set up the project structure before writing the first component. .gitignore, environment variable schema, API base URL configuration — all before git init.

They test environment variable loading in isolation. Before wiring up any API call, they console.log(process.env.WHATEVER) in the actual runtime context where it'll be used. Server component? Client component? API route? They verify.

They use a .env.example file committed to the repo that shows every variable needed without the values. This is how you tell your team what to configure without leaking anything.

# .env.example (COMMIT THIS)
DATABASE_URL=postgresql://user:password@host:port/database
NEXTAUTH_SECRET=generate-with-openssl-rand-base64-32
NEXTAUTH_URL=http://localhost:3000
BACKEND_URL=http://localhost:3001
NEXT_PUBLIC_API_BASE_URL=http://localhost:3001

# Production values go in your deployment platform's environment settings
# NEVER commit .env.local or .env.production

They treat Git history as documentation. Not just for code review. When something breaks in production six months later, a good commit history lets you bisect the problem in minutes instead of hours.

# Binary search through commits to find when a bug was introduced
git bisect start
git bisect bad HEAD
git bisect good v1.0.0
# Git checks out the middle commit, you test it
# Then mark good or bad until you find the exact commit
git bisect good  # or git bisect bad

They never debate whether to use the App Router or Pages Router in 2026. The App Router is the default, it's stable, React Server Components are the future of this ecosystem. If you're starting a new project today and using Pages Router you're actively choosing to work with a deprecated pattern. That's a choice you're allowed to make but be honest that it's a choice.

Spicy Take: The Real Problem Is Tutorials, Not Developers

Okay I'm going to say this and people are going to disagree with me.

The reason 90% of developers get this wrong isn't stupidity or laziness. It's the tutorial industry.

A YouTube tutorial on "Build a Full Stack App with Next.js and Node.js" has a 43-minute runtime. The first 38 minutes is features. The last 5 minutes is "and now deploy it to Vercel." The .gitignore setup takes 30 seconds and is either done off-camera or copied from a template without explanation. Environment variables are hardcoded for simplicity. CORS is fixed with app.use(cors()) and nobody explains why.

Millions of developers learned from those tutorials. And then they went to build real things with those patterns and ran into real problems.

"The documentation tells you what the tools do. It rarely tells you what happens when you misuse them in combination."

That gap between "I finished the tutorial" and "I can build real production software" is where most developers are stuck. And the combination of Next.js, Node.js, and Git is exactly where that gap shows up most violently.

The One Thing That Would Fix 80% of These Problems

It's embarrassingly simple.

Start every project with this:

# 1. Initialize git FIRST, before anything else
git init my-project
cd my-project

# 2. Create .gitignore BEFORE adding any files
# Copy the one from the Node + Next.js section above

# 3. Create .env.example
touch .env.example
# Write out all the variables your app will need (empty values)

# 4. Create .env.local for your actual local values
# (This is already in .gitignore so it won't be committed)

# 5. THEN scaffold your Next.js app
npx create-next-app@latest . --typescript

# 6. First commit should be: gitignore + env.example + nothing else
git add .gitignore .env.example README.md
git commit -m "chore: project initialization with gitignore and env template"

That sequence. In that order. If every new developer starting a Next.js project followed those six steps in that order, the number of accidental secret exposures would drop dramatically.

The order matters because once you run create-next-app, you're tempted to immediately start building. And in that excitement, you forget to check what's actually being staged when you do git add ..

Data Snapshot: Where This Stack Is in 2026

Some numbers that give context to why this matters at scale:

Next.js remains the dominant React meta-framework by weekly npm downloads (consistently above 5.8M per week through Q1 2026)
Node.js 22 LTS is the current recommended version as of early 2026; Node.js 24 released April 2025 is on a path to LTS in October 2026
Git is used by 97.8% of developers in the Stack Overflow Developer Survey 2025 — effectively universal
The State of JavaScript 2024 survey showed Next.js with 81% retention (developers who used it and would use it again) and rising adoption year-over-year
GitHub's transparency report data for 2024 indicated that secrets scanning blocked millions of exposures before they became public — meaning the push-protection feature is catching the exact mistakes described in this article

The scale of adoption means these mistakes aren't happening to a few developers. They're happening tens of thousands of times a day, globally, by people across all experience levels.

Common Questions That Don't Have Good Answers Online

"Should I use Next.js API routes or a separate Express server for a startup?"

If you're building a startup MVP, use Next.js API routes. You'll ship faster and you have one less deployment to manage. When you hit actual scaling problems, migrate. You won't hit those problems as early as you think.

"Does it matter if node_modules gets committed once?"

Yes. node_modules can be hundreds of megabytes. It bloats your repository permanently (remember, Git keeps history). And it creates reproducibility problems. Delete it from history using git filter-repo the same way you'd remove a secret.

"What's the right Node.js version to use with Next.js 15?"

Node.js 18 is the minimum for Next.js 15. Node.js 22 LTS is what you should be using in production as of early 2026. The compatibility table on the Next.js docs is up to date and should be your source of truth.

"Why does my Next.js app work on Vercel but my environment variables are undefined?"

Because you configured them in .env.local on your machine but forgot to add them to Vercel's environment variable settings in the dashboard. Vercel does not read your .env.local. You have to set every variable manually in the Vercel project settings. This trips up everyone once.

Final Thought

The combination of Next.js, Node.js, and Git is genuinely powerful. The ecosystem in 2026 is mature enough that you can build serious production applications with it and compete with teams twice your size.

But "powerful" and "forgiving" are different things. This stack is not forgiving. It will let you push your .env to GitHub. It will silently give you undefined instead of your secret key. It will deploy with broken environment variables and give you no useful error message at 2am.

The developers who get this right aren't necessarily more talented. They've just been burned once and learned from it, or they were lucky enough to learn from someone who was burned.

Now you've read about it instead of having to live through it.

Use that.

References and Sources

GitHub Security: "Detected and Prevented Secrets in 2024" — GitHub Blog, January 2025. https://github.blog/security/application-security/
Stack Overflow Developer Survey 2025 — Version Control Systems usage data. https://survey.stackoverflow.co/2025
State of JavaScript 2024 — Meta-Frameworks section, Next.js retention and usage figures. https://2024.stateofjs.com/
Next.js 15 Release Notes and Changelog — Vercel/Next.js GitHub repository. https://github.com/vercel/next.js/releases/tag/v15.0.0
Node.js Release Schedule — Node.js Foundation. https://nodejs.org/en/about/previous-releases
npm package download statistics for next — https://www.npmjs.com/package/next (weekly download trends, 2024-2026)
Next.js Documentation: Environment Variables — https://nextjs.org/docs/app/building-your-application/configuring/environment-variables
Next.js Documentation: API Routes — https://nextjs.org/docs/pages/building-your-application/routing/api-routes
Conventional Commits Specification v1.0.0 — https://www.conventionalcommits.org/
git-filter-repo documentation — https://github.com/newren/git-filter-repo
OWASP Secrets Management Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html
Vercel Deployment Environment Variables Guide — https://vercel.com/docs/projects/environment-variables

This article reflects my actual experience debugging these issues in real codebases. The mistakes described are patterns I've seen repeatedly, not edge cases. If something here contradicts what you've been doing, that's not an accident.

Find me across the web:

✍️ Medium: @syedahmershah
💬 DEV.to: @syedahmershah
🧠 Hashnode: @syedahmershah
💻 GitHub: @ahmershahdev
🔗 LinkedIn: Syed Ahmer Shah
🌐 Portfolio: ahmershah.dev

Will AI Replace Software Engineers? No. But It Will Shrink Junior Roles.

Syed Ahmer Shah — Wed, 03 Jun 2026 14:57:05 +0000

And if you think you have time to "wait and see," you really, really don't.

Let me tell you about a friend of mine. Seven years of experience. Mid-level engineer. $190K total comp at a solid company — a Series B startup, let's not get sidetracked with names. He got laid off in early 2025. It happens. He had a strong GitHub profile, could do system design in his sleep, had a clean resume that would've cleared any screen two years ago. He got to final rounds at three different companies.

Lost all three.

The feedback, each time, was some version of the same sentence: "We went with someone who was more fluent with AI tools."

He wasn't anti-AI. He used Copilot sometimes. He wasn't one of those "real engineers write real code" types. He just hadn't gone deep on it. Sometimes was enough — until suddenly it wasn't. The bar had moved and nobody sent him a memo.

That story is not unique. Right now, as you're reading this in 2026, that exact story is playing out for tens of thousands of engineers across every level, every stack, every timezone. And here's the part that makes it worse: it's not slowing down. It's accelerating.

Let's look at what's actually happening.

The Numbers Don't Care About Your Feelings

A lot of engineers are still operating on vibes. They hear "AI won't replace developers," breathe out, and go back to writing CRUD endpoints like nothing changed. I get it. But let's stop going on vibes for a second and look at what the data says.

American tech companies eliminated more than 142,000 jobs in just the first five months of 2026 — a 33% increase over the same period the year before — even while those same employers were posting record revenues and committing to the largest infrastructure buildout in tech history, according to tech layoff trackers. Read that again. Record revenues. More layoffs. The math only makes sense when you understand what's actually driving it.

The Stanford HAI 2026 AI Index, drawing on research from the Stanford Digital Economy Lab, found that early-career workers aged 22 to 25 in AI-exposed occupations experienced a 13% relative decline in employment since late 2022. Among 22-to-25-year-old software developers specifically, employment fell nearly 20% from its late 2022 peak by July 2025.

Twenty percent. Gone. Not during a recession. Not because the industry slowed down. During a period of AI investment unlike anything we've ever seen.

And here's the part that should genuinely bother you: for workers aged 30 and over in the highest AI-exposure categories, employment actually grew between 6% and 12% over the same period. AI isn't destroying engineering as a profession. It's pulling up the floor. The junior layer is disappearing while the senior layer holds firm or grows. That is a very specific, very surgical thing happening.

Entry-level postings dropped 60% between 2022 and 2024. Google and Meta are hiring roughly 50% fewer new grads compared to their 2021 peaks. According to Indeed's labour market data, software engineering listings are down approximately 35% from pre-pandemic levels — and roughly 70% from their 2022 peak.

Seventy percent from peak.

Think about what that means for a CS student graduating right now. Their professors built careers on a hiring market that simply doesn't exist anymore.

The CEOs Stopped Being Diplomatic

There used to be a script. "AI will create new jobs." "We're augmenting, not replacing." Every earnings call, every keynote, the same careful language. That script is mostly gone now.

Marc Benioff, CEO of Salesforce — San Francisco's largest private employer — got on an earnings call in early 2025 and said it plainly: "We're not going to hire any new engineers this year. We're seeing a 30% productivity increase in engineering, and we're going to really continue to ride that up."¹

Zero new engineers. At one of the biggest enterprise software companies on Earth. Because AI made the existing team 30% more productive. Why hire ten people when seven get you the same output?

But the line that deserves to be carved into the wall of every CS department in every university was this one, from the same call:

"My message to CEOs right now is that we are the last generation to manage only humans."
— Marc Benioff, CEO of Salesforce, Q4 FY2025 Earnings Call

That's not some fringe tech provocateur being edgy for an audience. That's the CEO of a $145 billion company saying the quiet part loud, on a call with investors and analysts. That's the actual strategy being announced.

Then there's Zuckerberg. On the Joe Rogan Experience in January 2025, he said something that didn't get nearly enough attention:

"Probably in 2025, we at Meta, as well as the other companies that are basically working on this, are going to have an AI that can effectively be a sort of midlevel engineer that you have at your company that can write code."
— Mark Zuckerberg, Joe Rogan Experience, January 2025²

Did that prediction land perfectly? Depends who you ask. But what isn't debatable is that Meta's junior developer hiring shrank dramatically through 2024 and 2025. The vision was stated. The hiring decisions followed.

At Google, the numbers tell a story that keeps accelerating. Sundar Pichai first disclosed the 25% figure on the Q3 2024 earnings call.³ By April 2025 it had climbed past 30%. By late 2025, Google's own CFO was citing "nearly half." Then, at Google Cloud Next 2026 in Las Vegas — just weeks ago — Pichai said this out loud:

"Today, 75% of all new code at Google is now AI-generated and approved by engineers, up from 50% last fall."
— Sundar Pichai, Google Cloud Next 2026, April 22, 2026

Three-quarters of the codebase at one of the world's premier engineering organisations. Not written by a human hand.

Satya Nadella, at Microsoft Build 2025, put Microsoft's comparable figure at around 30%.⁴ That number has likely moved too.

Let that trajectory sink in. The most influential software company on the planet just told the world, publicly, that three in four lines of new code it ships were generated by AI. Not as a confession. As a boast.

The Klarna Story Nobody Wants to Sit With

I keep coming back to Klarna because people draw the wrong lesson from it every single time.

Between 2022 and 2024, Klarna reduced its workforce — cutting approximately 700 positions — while deploying AI to handle the volume those roles had covered: customer service, operations, repetitive backend work. CEO Sebastian Siemiatkowski was open about it. Then things went wrong. Customer complaints climbed. Service quality dropped. Siemiatkowski publicly acknowledged that the AI-driven transition had negatively affected service and product quality. By 2025, Klarna was rehiring human staff.

People love this story. "See? AI failed. Humans win. Everyone goes home."

But here's what everyone skips over: those 700 people lost one to two years of income. Some pivoted careers entirely. Others are still looking. When Klarna came back to rehire, they didn't rebuild what they had. They built something smaller, leaner, structured around a gig-style model that requires fewer permanent headcount. The company rolled back the pace of replacement — not the direction.

The lesson from Klarna is not "AI will fail so we're safe."

The lesson from Klarna is this: companies will try to replace you with AI. Sometimes it'll backfire badly. When they course-correct, they'll hire back fewer people than they let go. The reset doesn't go home. It goes to a new, lower, permanent baseline.

That's not a comfort. That's a warning.

The Split That's Already Happening

Here's what I'm actually seeing in the developer community right now, and it is not subtle.

There are engineers who went all in — integrated AI tools into their workflows, learned the failure modes, used them to ship faster. A 2025 Microsoft/GitHub study found that engineers using Copilot completed comparable tasks 55% faster.⁵ That productivity multiplier has translated directly into smaller junior headcounts at companies like Meta, Google, and hundreds of mid-size SaaS companies that right-sized their engineering organisations through 2024–2025. The engineers using AI well aren't just surviving — they're getting the promotions, the offers, the raises. By Q1 2025, 82% of developers reported using AI tools weekly, with 59% running three or more simultaneously. And the pay reflects it: AI-fluent developers are landing entry-level roles at $90K–$130K versus $65K–$85K for traditional profiles, according to job market data.

Then there's the other group. Engineers who say "I don't trust AI code" or "it's glorified autocomplete" or — and I've heard this more than once — "real engineers write real code." Look, I understand the psychology. There's something genuinely uncomfortable about watching a tool do a significant portion of work you spent years learning. It feels like a betrayal of the craft.

But the market has no feelings about your feelings about the craft.

Take something like this — the kind of endpoint a junior developer used to spend a morning on:

from flask import Flask, request, jsonify
from models import db, User
from auth import require_auth

app = Flask(__name__)

@app.route('/users/<int:user_id>', methods=['GET'])
@require_auth
def get_user(user_id):
    user = User.query.filter_by(id=user_id).first()
    if not user:
        return jsonify({'error': 'User not found'}), 404
    return jsonify(user.to_dict()), 200

@app.route('/users', methods=['POST'])
@require_auth
def create_user():
    data = request.get_json()
    if not data or 'email' not in data:
        return jsonify({'error': 'Email required'}), 400
    user = User(email=data['email'], name=data.get('name', ''))
    db.session.add(user)
    db.session.commit()
    return jsonify(user.to_dict()), 201

GitHub Copilot or Claude Code generates something like that in about four seconds. With tests. With error handling. With docstrings if you ask. The junior developer who spent a career building this kind of muscle is now competing against a tool that does it in seconds.

The job of writing this code isn't gone. The reason to hire someone specifically to write this code absolutely is.

What's not gone: knowing why this architecture might be wrong for your specific use case. Knowing when to break the pattern. Understanding what happens when this hits 100,000 concurrent requests. That's senior engineer judgment. And AI, as of 2026, is still genuinely bad at it.

The World Is Treating This Differently Than You Are

Here's something that struck me hard: the institutions that usually move the slowest — governments — are scrambling faster than most individual developers I know.

The U.S. has provided funding for AI certifications for 120,000 laid-off workers. Across Europe, AI retraining enrolments jumped 39%. Singapore has baked workforce AI transition programs directly into its national strategy. The WEF's Reskilling Revolution initiative has mobilised commitments expected to reach over 856 million people globally by 2030.⁶

India — which has the world's largest pool of software developers — is doing something particularly interesting. Rather than panic about AI consuming developer jobs, India is systematically working to ensure its developers are the ones building the AI. A NASSCOM report projects India's AI talent pool to double from 6.5 lakh to over 12.5 lakh professionals by 2027, growing at 15% year-on-year. In the past three years alone, 8.65 lakh candidates were trained in emerging tech, with 3.20 lakh specifically in AI and Big Data Analytics.⁷ That's not a country in denial. That's a country repositioning at scale.

The WEF's Future of Jobs Report 2025 puts the global picture in stark terms: by 2030, job disruption could affect 22% of all roles globally — displacing 92 million jobs while creating 170 million new ones.⁶ Net positive on paper. Except the 92 million displaced are largely doing specific things: entry-level coding, repetitive testing, documentation, basic customer support. And the 170 million new jobs are in AI oversight, system architecture, ML infrastructure, AI safety, and technical leadership.

The math is brutal in its simplicity. If you're a developer who primarily does the work AI now generates, you're in the 92 million. If you learn to architect systems, supervise AI output, and build what AI can't build alone — you're in the 170 million.

Every country that's paying attention is trying to get into the 170 million. Are you?

What AI Is Actually Taking (And It's Not What You Think)

Let me be precise about the mechanism here, because the discourse is sloppy and sloppy thinking leads to wrong decisions.

AI is not replacing software engineering as a discipline. The judgment, the architecture, the systems thinking, the ability to navigate technical debt and organisational complexity — that's not going anywhere soon. What AI is replacing are the specific tasks that junior developers were hired to do: boilerplate, basic CRUD, scripted testing, routine bug fixes, first-draft documentation.

The problem is, those weren't just tasks.

They were the apprenticeship. You wrote the boilerplate and slowly started to understand why the boilerplate worked. You fixed the simple bugs and developed an intuition for reading unfamiliar code. You built the CRUD endpoints and gradually developed a feel for data modelling. You did the repetitive work and, somewhere in that repetition, you became an engineer who could do the hard work.

That entire training pipeline is now compressed or closed. Companies are skipping the junior layer and hiring mid-to-senior engineers who can direct and supervise AI output. The most visible effect of AI coding tools in 2026 isn't eliminating senior engineers — it's hollowing out the layer below them. Companies that used to run 3–5 juniors per senior are now running leaner teams.

AWS CEO Matt Garman said it directly, calling the strategy of simply eliminating the junior layer "one of the dumbest things I've ever heard" — warning that companies risk creating a catastrophic skills gap over the next decade. If you wipe out the apprenticeship, you stop producing the next generation of senior engineers.

He's right.

And most companies are doing it anyway, because short-term cost savings beat long-term talent pipeline thinking every single quarter. That's not cynicism. That's just how publicly traded companies behave.

What You're Actually Supposed to Do

Okay, I've been pretty dark. Let me be useful for a second, because fear without action is just anxiety.

The engineers I see doing well right now share a few specific things.

They treat AI like a junior developer, not an oracle. They use it to generate first drafts and review those drafts with the same critical eye they'd apply to a first-year intern's pull request. They understand why the AI generated what it generated — which means they catch when it's confidently wrong. They have architectural opinions that the AI cannot substitute for.

The practical workflow looks something like this:

# How senior engineers are actually working in 2026

# Step 1: You design the architecture — AI is genuinely bad at this
# Step 2: AI scaffolds the implementation
# Step 3: You review critically and catch the failure modes

# Example — prompting Claude Code or Cursor:
# "Create a rate-limiter middleware for our Express API
#  using Redis, with per-user and per-IP limits,
#  with proper fallback handling for Redis connection failures"

# AI gets ~80% right immediately
# The remaining 20% — Redis failover edge cases,
# production-specific config, security gaps — YOU catch that
# That gap is the job now. That's your value.

They have strong opinions about system design. When to use microservices versus a monolith. When a message queue adds value and when it just adds complexity. How to handle distributed transactions. When to cache — and when caching creates more problems than it solves. This is the domain where experience lives and AI doesn't, because it requires judgment shaped by having built things that broke in production.

They know exactly where AI fails. Not vaguely ("AI makes mistakes") but specifically: hallucinated API calls that look correct until they don't. Security vulnerabilities in generated authentication code. Incorrect business logic assumptions baked silently into generated functions. Only about 30% of AI-suggested code gets accepted by developers who actually know what to look for — and that selectivity is itself a skill you have to develop. The developers doing well right now have built a detailed personal map of where AI goes wrong.

Here's the clearest way I can put the distinction:

# AI generates this in seconds — low value in knowing it by heart
def get_user_by_email(email: str) -> Optional[User]:
    return db.session.query(User).filter(User.email == email).first()

# AI cannot answer these for you — this is where your career lives:
# → Why PostgreSQL over MongoDB for this specific use case?
# → How does this query behave under 10,000 concurrent requests?
# → What are the GDPR implications of storing this email field?
# → When do you add a Redis cache here, and when is it overkill?
# → How does this endpoint interact with your circuit breaker?

That second list. That's the job now.

They're building in public. Writing about what they're learning, contributing to open source, creating content that makes their thinking visible. When AI can replicate anyone's code sample, the hiring signal shifts to judgment. The developers getting offers right now are the ones whose judgment is legible from the outside — you can read who they are from their GitHub, their articles, their opinions on hard problems.

And the ones who are most secure? They understand the business too. AI is making pure technical skills cheaper every month. What it cannot replicate is the engineer who deeply understands the domain, speaks the language of product and business, can talk to customers, can translate between the technical and the strategic. That profile — technically sharp and business-fluent — is more valuable right now than it has been at any point in the last decade.

The Criticism That Needs to Be Said

Something unpopular needs to be said.

A lot of the "AI won't replace developers" discourse is being driven by people with significant financial or psychological incentives to believe it. Senior engineers who don't want to feel their skills are devaluing. Bootcamp founders who need enrolment. CS departments whose own enrolment is already dropping. VCs who've bet on human-in-the-loop products.

None of these people are lying exactly. But they're all reading the same data through a very interested filter.

U.S. Bureau of Labor Statistics data shows software developer employment fell 27.5% between 2023 and 2025.⁸ A Resume.org survey of 1,000 U.S. business leaders found that six in ten companies are likely to lay off employees in 2026, with four in ten planning to specifically replace workers with AI.⁹ These are not rounding errors. These are not post-pandemic corrections. These are structural shifts.

When critics say "but AI code is buggy, it needs human review, it can't handle complex systems" — they're not wrong. But they're imagining a binary: either AI replaces engineers completely or nothing changes. Reality is a third option, the one that's already here: AI replaces specific tasks within engineering, shrinks team sizes, raises the floor of what gets you hired, and leaves a smaller but more capable group of engineers doing work that genuinely requires human judgment.

That third option arrived while people were still debating whether the first one was possible.

What a Resume Has to Look Like Now

Two years ago, a junior developer posting read: "1–2 years experience, proficiency in React and Node, familiar with Git."

Today — if a junior posting exists at all, and there are far fewer — it reads something closer to: "Experience with AI-assisted development workflows, ability to review and validate AI-generated code, familiarity with prompt engineering for code generation, experience with at least two AI coding tools."

Entry-level hiring at the 15 biggest tech firms fell 25% from 2023 to 2024, according to a SignalFire report.¹⁰ Employers' rating of the market for college graduates is at its most pessimistic since 2020, per NACE's Job Outlook 2026.¹¹ With AI performing more of the grunt work that used to be the entry-level on-ramp, expectations for new grads have shifted dramatically upward. You're expected to show up already knowing things that used to be learned on the job.

If you're graduating this year, or seriously thinking about entering the field — the playbook has fundamentally changed. You cannot follow the path that produced the engineers who might be mentoring you. Their path, the one that started with two years of boilerplate and slowly accumulated into expertise, is largely gone.

The Bet That's Already Been Made

Here's the context I don't see enough people connecting to the rest of this.

Tech companies globally are committing to a combined $700 billion in AI infrastructure investment. Jensen Huang put it directly: "One trillion dollars of AI infrastructure is coming. The entire installed base of data centers will be renewed."

Companies don't bet that kind of money on something they think might fizzle. This is the largest concentrated capital commitment in tech history — bigger than the cloud transition, bigger than mobile. And every dollar of it is simultaneously a bet that AI will replace significant volumes of human cognitive labour, including coding labour.

The companies making that bet are also the companies deciding who to hire. When Amazon, Microsoft, Google, and Meta collectively commit hundreds of billions to AI infrastructure, they are making a simultaneous workforce decision: fewer junior developers, more ML engineers, more people who build and maintain the systems that will do what humans used to do.

This is not a hiring cycle. This is a structural transformation. And the decision was made years ago. We're just living in the consequences.

A Question Worth Actually Sitting With

Here's something I'd encourage every working developer to honestly answer for themselves.

If your job title stayed exactly the same, but all the junior tasks — the boilerplate, the tests, the first-draft implementations — were offloaded to AI, what would you actually be doing all day?

If the answer is "still plenty: architecture decisions, complex debugging, cross-team alignment, technical strategy, reviewing AI output critically" — you're probably in good shape. You've built the kind of irreplaceable judgment that AI, as of today, genuinely cannot replicate.

If the answer is "I'm not sure" or "honestly, a lot of what I do could probably be generated" — that's important information. That's a signal worth acting on now, not later.

Among Gen Z developers, 64% report worrying about being laid off, compared to 45% of their millennial counterparts, per Stack Overflow's Developer Survey. Those numbers aren't paranoia. They're pattern recognition. Gen Z engineers entered a market that looked like one thing and found something completely different when they arrived.

The Honest Summary

Will AI replace software engineers? No. The discipline of engineering — systems thinking, architecture, the judgment that comes from having built things that broke — is genuinely hard to replicate and AI is genuinely bad at it.

But will AI shrink junior roles, compress the hiring pipeline, raise the floor of what's expected at every level, and leave a smaller total number of engineers employed than the 2022 peak? It already has. That's not a prediction. That's a 2026 fact.

In 2025 alone, at least 58 million workers globally received some form of AI training or certification, reflecting the scale of workforce transition already underway. The people who are going to be fine are the ones treating that transition not as a professional option but as a professional requirement.

AI is not optional anymore. Not because some blog post said so. Because the hiring data, the layoff data, the productivity data, and the capital allocation data all point in the same direction. The companies with the most money in the world made their decision. They made it years ago.

The question is just whether you make yours, and when.

Because the engineers who ignore this — who wait for clarity, who keep doing what they've been doing and hope the market swings back to them — are making a bet. A bet that one of the best-funded, fastest-moving technological transitions in history is going to stall out before it reaches their desk.

I wouldn't take that bet.

What You Can Do, Starting Now

Not a lecture. Just what I'd do.

Start using AI tools as a real collaborator, not as autocomplete. Use Claude Code, Cursor, Copilot — use multiple, because they have different strengths and critically different failure modes. Build things with them. Learn where they fail. That failure map is your professional edge, because knowing when the AI is wrong is worth far more than being able to generate code you can't evaluate.

Build the skills AI provably can't replicate in 2026: distributed systems design, security architecture, ML infrastructure, technical leadership, the ability to translate business requirements into technical decisions that account for real operational constraints. These are deeply human skills right now.

Write publicly about what you're building and learning. In a market where AI can produce anyone's code sample, your thinking has to be the differentiator. Make it visible.

And invest real time in the business side. Understand the domain you're building in. Talk to the users. Learn enough about the product and the economics to make real decisions — not just technical ones. That combination of technical depth plus business fluency is, right now, as hard to replace as anything in this industry.

Closing

The friend I opened with — he's okay. After three rejections in a row, he spent three months rebuilding his workflow. AI for 60–70% of implementation. Critical review of everything it produced. He built a real sense of where it went wrong. Got back to final rounds. Got the job.

But he lost months. He lost income. He went through the specific kind of humiliation that comes with being objectively skilled at something and still being passed over — not for someone better, but for someone who had simply adapted faster. The only reason was timing. He moved slower than the market moved.

Don't be him. Move now.

The question was never whether AI will replace software engineers. The question has always been whether you will make yourself the kind of engineer that AI makes more powerful — or one that AI makes obsolete. That answer is entirely up to you.

But you don't have unlimited time to decide.

References & Sources

Additional data from: Stanford HAI 2026 AI Index · Stanford Digital Economy Lab · Stack Overflow Developer Survey 2024–2025 · Indeed Labour Market Data · Tech Layoff Tracker (May 2026) · Harvard Business Review (February 2026)

Find me across the web:

✍️ Medium: @syedahmershah
💬 DEV.to: @syedahmershah
🧠 Hashnode: @syedahmershah
💻 GitHub: @ahmershahdev
🔗 LinkedIn: Syed Ahmer Shah
🌐 Portfolio: ahmershah.dev

Salesforce Q4 FY2025 Earnings Call — Marc Benioff, CEO ↩
Joe Rogan Experience, January 2025 — Mark Zuckerberg, CEO of Meta ↩
Alphabet Q3 2024 Earnings Call; Google Cloud Next 2026 (April 22, 2026) — Sundar Pichai, CEO of Google ↩
Microsoft Build 2025 — Satya Nadella, CEO of Microsoft ↩
Microsoft/GitHub Copilot Productivity Study, 2025 ↩
World Economic Forum — Future of Jobs Report 2025 & Reskilling Revolution Initiative ↩
NASSCOM AI Talent Report 2026; Indian Ministry of Labour and Employment ↩
U.S. Bureau of Labor Statistics, Occupational Employment Data, 2025 ↩
Resume.org Survey of 1,000 U.S. Business Leaders, 2025 ↩
SignalFire Entry-Level Hiring Report, 2024 ↩
National Association of Colleges and Employers (NACE) — Job Outlook 2026 ↩