DEV Community: Syed Ahmer Shah

The New Era of Software Engineering

Syed Ahmer Shah — Fri, 04 Sep 2026 12:52:17 +0000

I'm Syed Ahmer Shah. I'm 19, I'm from Pakistan, and I'm still an undergraduate studying Software Engineering. I want to say that clearly before anything else, because I'm not writing this as some expert looking down from a mountain of experience. I'm writing this as someone who is in it right now, watching the ground shift under his own feet while still learning how to walk on it.

This is not a "10 years from now, robots will take your job" article. I don't know what happens in 10 years. Nobody does, not even the people running the biggest AI labs in the world, no matter how confident they sound on stage. What I do know is what happened to me in the last year, what I saw happen to a senior developer I worked under during my internship, and what I've watched happen across the entire industry I'm trying to build a career in. That's what I want to tell you about.

How It Used to Work

Before I get into AI, I want you to understand what software engineering actually was, because a lot of non-technical people imagine it as some kind of typing wizardry — fingers flying across a keyboard, green text on a black screen, hacker-movie stuff.

It was never that. Software engineering was closer to construction work, except the building was invisible.

You start with a problem. A bank wants an app so people can send money without visiting a branch. A restaurant wants a system to manage orders. A hospital wants patient records that don't get lost in a filing cabinet. The engineer's job was to take that vague human need and turn it into thousands, sometimes millions, of precise instructions that a machine could follow without ever getting confused, because machines don't tolerate confusion. A single misplaced comma could crash the entire system.

This meant a developer spent years learning the "grammar" of programming languages — Python, Java, JavaScript, C++ — the same way you'd spend years learning a foreign language before you could write a novel in it. Then on top of that grammar, you had to learn logic: how to break a huge problem into small enough pieces that a computer could handle each piece one at a time. Then you had to learn the tools around it — databases to store information, servers to run your program, version control so ten people could work on the same project without overwriting each other's work.

And then, once all of that was written, you had to test it, break it on purpose, find where it failed, and fix it. Debugging — hunting for the one wrong line in ten thousand — was often the most painful and most respected skill in the field. Senior engineers weren't senior because they typed fast. They were senior because they had, over years, built an instinct for where problems hide and how systems fail.

That was the job. Slow, deliberate, deeply manual. You earned your competence one bug, one late night, one confusing error message at a time. That was the world I entered when I chose this degree.

That world is not gone. But it is no longer the whole story.

Then the Machines Started Writing Code Too

Somewhere in the last two or three years, something changed that most people outside tech still haven't fully registered. AI coding tools stopped being toys that could autocomplete a line of code, and started becoming something closer to junior engineers you could actually talk to.

GitHub Copilot was one of the first tools that showed people this was even possible — it sat inside your code editor and suggested entire chunks of code as you typed, trained on an enormous amount of publicly written code. Then came tools like Cursor, which is basically an entire code editor rebuilt around AI from the ground up, letting you describe what you want in plain English and watch it write, edit, and restructure real files across a real project. Then Claude Code and OpenAI's Codex arrived, and these went even further — they don't just suggest code, they can plan a task, write across multiple files, run commands in a terminal, test what they built, notice their own mistakes, and fix them, almost like an actual teammate sitting next to you.

This is the part I need you to sit with for a second, especially if you're not from a tech background: these tools are no longer just "helping you type faster." They can take a task like "add a login page with email verification" and actually go do it — write the files, connect the pieces, and hand you something that mostly works, in minutes.

And the people who built this world are the ones telling us how far it's already gone. Google's CEO, Sundar Pichai, has said that well over 30% of the code at Google is now written by AI. Microsoft's CEO, Satya Nadella, has said something similar about his own company's codebase. Anthropic's CEO, Dario Amodei, predicted in early 2025 that the vast majority of code could be AI-written within a matter of months. Google's own AI leadership has talked about AI performing like a junior software engineer within a year. These aren't random influencers making noise for clicks. These are the people who literally run the companies building this technology, telling us — in public, on the record — that the ground has already moved. [1][2][3]

And then there's Ryan Dahl. If you're not from tech, that name might mean nothing to you, but in this industry it means a lot. Dahl created Node.js in 2009, a piece of technology that quietly powers a massive chunk of the modern internet — it's one of the reasons so many websites and apps you use every day even work. This isn't some junior developer with a hot take. This is one of the most respected engineers alive. And in early 2026, he posted something that spread across the entire developer world within hours: that the era of humans writing code by hand, line by line, is effectively over. He was careful to say this doesn't mean engineers have nothing left to do — but that the "writing syntax word by word" part of the job, the part most of us spent years training for, is no longer where the real work lives. [4][5]

When I read that, sitting in my hostel room in Pakistan, I felt something between excitement and a small, quiet panic. Because I knew exactly what he was talking about. I had already started feeling it myself.

My Own Trap

I want to be completely honest here, because I think this is the part that actually matters for anyone reading this who is learning to code right now, anywhere in the world.

When these tools got good, I got lazy. Not lazy in the sense of not working — I was working all the time, shipping code, finishing assignments, building projects fast. But lazy in a much more dangerous way. I would open an AI tool, describe what I wanted, and let it write the whole thing. It worked. It ran. I moved to the next task. I didn't read the code line by line. I didn't ask myself why a particular function was structured that way, or what a specific keyword was actually doing under the hood, or why the AI chose this approach over another one that might have existed.

For a while, this felt like progress. I was building things faster than my classmates. I was getting things done. But somewhere in the back of my mind, a quiet alarm kept going off. If someone asked me to explain the code I had just "written," could I actually explain it? Sometimes I could. But more and more often, the honest answer was no. I would stare at my own project and realize I understood what it did, but not how or why, not really — because I hadn't done the thinking. The AI had done the thinking. I had just done the asking and the copying.

That is a terrifying place to be as an engineer. Because the moment something breaks in a way the AI can't fix — and it will happen, because AI still makes confident mistakes, still misunderstands context, still writes code that looks correct but hides a subtle flaw — you're stuck. You don't have the foundation to even know where to start looking. I remember one specific night where a project I'd mostly "AI-built" broke in production-like conditions, and I sat there for almost two hours completely lost, not because the problem was that hard, but because I had never built the muscle to think through it myself. I had outsourced the muscle before I'd even built it.

That night was my turning point. I understood, very clearly, that if I kept going like this, I wasn't becoming a software engineer who uses AI. I was becoming a person who prompts AI and hopes for the best. And those are not the same thing, even if they can look identical from the outside for a while.

So I changed how I worked, deliberately and stubbornly. Now, before I let an AI tool write a single line for me, I make it explain itself first. What is it about to do? How is it planning to do it? Why this approach and not another? I go through this with it — sometimes it takes thirty, forty minutes before any actual code gets written — until I genuinely understand the plan well enough that I could, in theory, write it myself, just slower. Only then do I let the AI generate the code, and even then, I read every part of it like I'm grading someone else's homework, because in a sense, I am. It's slower. It's less flashy. But I walk away from every session actually knowing something I didn't know before, instead of just having a folder full of code I can't defend.

What I Saw During My Internship

This brings me to something that crystallized all of this for me — my internship at a software house called XCL.

There was a senior Laravel developer there, someone with real years of experience, working on a genuinely large, complicated codebase — the kind of project with so many moving parts that a beginner would get lost just trying to find where one feature lived. One day I asked him if he could walk me through how he actually works now, day to day. He said sure, and showed me.

What I watched was, honestly, a little surreal. He used Cursor almost constantly to write the actual code — describing what he needed, letting it generate large sections, adjusting as he went. Then, once a chunk of work was done, he would switch over to Claude specifically to review it — hunting for bugs, logic errors, things that didn't quite fit the rest of the system. He told me straightforwardly: this is what works for him now. Write with one tool, review with another, move fast, ship fast.

I remember standing there thinking two things at the same time, almost fighting each other in my head. The first was pure amazement — this man was moving through a massive codebase at a speed that would have taken a team of people years earlier. The second feeling was something closer to dread. Because if this is how a senior engineer with real, hard-earned experience works now — AI writes, AI reviews, AI fixes — then what exactly is left for someone like me, who's still learning, still building that foundation? Are we all just going to become prompt engineers, typing instructions into a box and hoping the box understands us well enough?

I sat with that question for a long time. I still don't have a perfect answer. But I've come to believe something, and I want to explain why.

Will Engineers Be Replaced?

Here's what I actually think, based on what I've read, what I've watched with my own eyes, and what I've lived through myself: software engineers are not being replaced. But the way we work is already changing, and it started changing a while ago, not in some far future.

Think about it like this. When calculators became common, accountants didn't disappear — but an accountant who could only add and subtract by hand, with nothing else to offer, became far less valuable than one who understood what the numbers actually meant for a business. The tool didn't remove the need for judgment. It removed the need for manual labor that judgment used to require. Something similar, but far more dramatic, is happening in software.

The parts of the job that were pure manual labor — typing out boilerplate code, remembering exact syntax, writing repetitive functions that follow known patterns — are being absorbed by AI, and honestly, good riddance to some of it. What's rising in value instead is exactly what AI still can't reliably do on its own: understanding what a business or a person actually needs and translating vague, messy human wants into a real system; making architectural decisions about how a large system should be structured so it doesn't collapse under its own weight two years later; knowing when the AI-generated solution is subtly wrong even when it looks perfectly fine on the surface; and taking responsibility when something breaks, because AI cannot be held accountable — you can.

Ryan Dahl himself made this same point when his statement went viral — he wasn't saying engineers are finished, he was saying the part of the job tied to typing syntax by hand is finished, and what remains is design thinking, decision-making, and reviewing and steering what the machine produces. That distinction matters enormously. [5][6]

So here's the honest, unglamorous truth I've landed on, and I say this as someone still figuring it out, not as someone who has it all solved: AI will not replace the engineer. But it will absolutely replace two specific kinds of people. First, it will replace the engineer who refuses to touch it at all, who insists on doing everything the old manual way out of pride or fear, because they will simply be too slow compared to everyone else in the industry. And second — and this is the one that scares me more, because I almost became this person — it will replace the engineer who depends on it completely, who never builds real understanding, who can prompt but can't think, and who becomes helpless the moment the AI gets something wrong, which it still does, regularly.

The survivors, I think, will be the people in the middle. People who use AI aggressively, without guilt, because refusing to use a tool this powerful would be its own kind of foolishness. But people who never let it replace the actual understanding in their own heads — who still ask why, who still read the code line by line, who still know enough to catch the AI when it confidently walks off a cliff.

What I'm Telling Myself, and Maybe You Too

I don't know exactly what software engineering will look like in five years. I don't think anyone genuinely does, no matter how certain they sound in interviews or on X. But I know what I'm choosing to do with my own hands, right now, at 19, while I still have time to build the right habits before they calcify into bad ones.

I use AI every single day. I'm not going to pretend otherwise, and I don't think anyone in this field honestly can anymore. But I use it after I understand the plan, not instead of understanding it. I let it write the boring parts fast, so I have more time to think about the parts that actually require thinking. And when something feels like magic — when the AI produces something that just works and I don't quite know why — I stop and I dig until I do know why, even if it costs me an extra half hour I didn't plan for.

That senior developer at XCL wasn't wrong to work the way he does. He's fast, he's effective, and he ships real, working software for real clients. But he got to that speed after years of understanding what "good code" even means, after years of debugging things by hand, after building the judgment that now lets him trust and check an AI's work in seconds instead of hours. I think that's the actual lesson hiding underneath all of this. The tools have changed. The starting point has not. You still have to understand before you can supervise. You just get to supervise something a lot faster and more capable than yourself, if you've earned the right to.

We're not becoming obsolete. We're becoming something else — something that doesn't fully have a name yet. Call it what you want. I just know I'd rather walk into that future understanding every step I take, even if it's slower, than sprint into it blind and find out too late that I never actually learned to walk on my own.

References

Reuters/company statements on AI-generated code at Google and Microsoft, as reported via CEO remarks from Sundar Pichai and Satya Nadella (2025).
Dario Amodei, Anthropic CEO, public remarks on projected AI coding capability, March 2025.
Jeff Dean, Google AI leadership, public remarks on AI performing at a junior-engineer level, May 2025.
Ryan Dahl (creator of Node.js and Deno), public post on X, January 2026 — reported by OfficeChai, "Era Of Humans Writing Code Is Over: Node.js Creator Ryan Dahl," https://officechai.com/ai/era-of-humans-writing-code-is-over-node-js-creator-ryan-dahl/
Reading.sh, "The creator of Node.js says the era of writing code is over," https://reading.sh/the-creator-of-node-js-says-the-era-of-writing-code-is-over-8320c868043b
EducationPost, "Era of humans writing code is over, says NodeJS creator Ryan Dahl," https://educationpost.in/news/technology/era-of-humans-writing-code-is-over-says-nodejs-creator-ryan-dahl

Tools referenced: GitHub Copilot (GitHub/Microsoft), Cursor (Anysphere), Claude Code (Anthropic), OpenAI Codex (OpenAI).

Find me across the web:

Portfolio: ahmershah.dev
Crunchbase: @syed-ahmer-shah
Crunchbase Company: @syedahmershah
Clutch: @syed-ahmer-shah
Tech Behemoth: @syed-ahmer-shah
Design Rush: @syed-ahmer-shah
Edverise: @syed-ahmer-shah
Trust Pilot: @ahmershah.dev
LinkedIn: Syed Ahmer Shah
GitHub: @ahmershahdev
AWS Builder Profile: @syedahmershah
DEV: @syedahmershah
Medium: @syedahmershah
Hashnode: @syedahmershah
Substack: @syedahmershah
HackerNoon: @syedahmershah
Substack: @syedahmershah
Facebook: @ahmershahdev
Linkedin Page: @syedahmershah
YouTube: @ahmershahdev
Instagram: @ahmershahdev
TikTok: @ahmershahdev

How Databases Work: From Tables to Query Execution

Syed Ahmer Shah — Fri, 28 Aug 2026 23:25:51 +0000

Introduction: The Library Analogy

Imagine you walk into a massive library with millions of books. You need to find every book written by Stephen King that was published after 2000. If the library had no organizational system, you'd have to physically walk through every shelf, picking up each book to check the author and publication date. That would take forever.

But if the library has a catalog system — an organized, searchable index — you can find what you need in seconds. That catalog system is essentially what a database is. It's not just storing information; it's storing it in a way that makes retrieval incredibly fast and efficient.

Let's dive into how this works, from the ground up.

Part 1: The Foundation — What Databases Actually Are

Before we talk about complex concepts, let's establish what we're dealing with.

A database is an organized collection of structured data. Think of it as a digital filing cabinet where information is arranged in a very specific, deliberate way. But unlike a physical filing cabinet, a database can instantly search through billions of records in milliseconds.

Why Not Just Use Files?

Your computer's file system (the folders and files on your hard drive) could technically store data. Microsoft Excel files, CSV files, JSON files — these all store data. So why do we need databases?

Consider this scenario: You run an e-commerce store with 10 million customers. Every second, hundreds of people are placing orders, updating their profiles, and viewing products.

If you stored everything in Excel files, they'd become too large to even open on a normal computer.
If two customers try to buy the last item simultaneously, how do you prevent both from getting the same product?
If the system crashes while saving, how do you ensure no data is corrupted?

A database management system (DBMS) solves these problems. It's the software that manages how data is stored, retrieved, and modified safely and efficiently. MySQL, PostgreSQL, and MongoDB are all examples of DBMSs.

Relational vs. NoSQL: Two Different Approaches

Relational databases (like PostgreSQL, MySQL) organize data in tables — rows and columns, just like a spreadsheet. Each row represents a single record, and each column represents a property of that record.

NoSQL databases (like MongoDB, Firestore) store data differently — often as documents or key-value pairs. Instead of rigid tables, they're more flexible.

Think of it this way:

Relational: A filing system with strictly labeled folders and alphabetically organized documents.
NoSQL: A more flexible system where you can store documents however makes sense to you.

For most people starting their journey with databases, relational databases are the standard choice. They're predictable, powerful, and have been refined for decades.

Part 2: Designing a Database — The Blueprint

Let's say you're building that e-commerce platform. Where do you start?

Understanding Relationships

A database isn't just a random pile of tables. Tables are connected in meaningful ways.

In our e-commerce system:

A Customer places multiple Orders
Each Order contains multiple Products
Each Product belongs to a Category

These connections are called relationships, and they're fundamental to database design.

Primary keys uniquely identify each record. For customers, it might be customer_id. Foreign keys create the connection — an Order table would have a customer_id field that references the Customer table.

This is where one-to-many relationships come in. One customer has many orders. To represent many-to-many relationships — where orders have many products and products appear in many orders — you need a junction table. This middle table links them together.

The Art of Normalization

Imagine a spreadsheet where you store everything about orders in one massive table: customer name, address, phone number, order date, product name, product price, and so on. If a customer places 10 orders, their name, address, and phone appear 10 times. That's wasteful and creates problems.

Normalization fixes this. It's the process of breaking data into separate tables and connecting them logically. By separating the Customer table from the Order table, you store each customer's information once. Updates become easier, storage becomes efficient, and data integrity improves.

However, denormalization is sometimes strategically used in the real world. If you frequently query customer names alongside order details, constantly joining two tables might be slow. Copying the customer's name into the order table (denormalization) makes those queries faster — though it introduces redundancy.

The key insight: Good database design is about balance. Structure your data to prevent redundancy and errors, but not so much that querying becomes inefficient.

Part 3: SQL — The Language of Databases

Now that you have a well-designed schema, how do you actually talk to the database?

SQL (Structured Query Language) is the standard language. It's remarkably readable — you can almost understand a query by reading it like English.

The Four Operations: CRUD

Every database interaction falls into four categories:

Create: INSERT INTO customers VALUES (1, 'John', 'john@example.com')
Read: SELECT * FROM customers WHERE age > 30
Update: UPDATE customers SET email = 'newemail@example.com' WHERE customer_id = 1
Delete: DELETE FROM customers WHERE customer_id = 1

Getting Smarter: Joins

Here's where SQL becomes powerful. Imagine you want to see every customer's name alongside their orders. That data lives in two separate tables. You need to join them:

SELECT customers.name, orders.order_date
FROM customers
INNER JOIN orders ON customers.customer_id = orders.customer_id

Different join types answer different questions:

INNER JOIN: Only return matches from both tables (customers who have placed at least one order)
LEFT JOIN: Return all from the left table, matches from the right (all customers, whether they've ordered or not)
RIGHT JOIN: The opposite
FULL OUTER JOIN: Everything from both tables

Aggregations and Grouping

What if you want to know how many orders each customer placed? You'd use GROUP BY:

SELECT customers.name, COUNT(orders.order_id) as order_count
FROM customers
LEFT JOIN orders ON customers.customer_id = orders.customer_id
GROUP BY customers.name

This groups all orders by customer and counts them. Powerful, right?

Part 4: Making Databases Fast — Indexes and Query Execution

Here's the hard truth: As data grows, queries slow down.

You have 100 million customers. A simple query like SELECT * FROM customers WHERE email = 'john@example.com' would normally require checking all 100 million records one by one. That's a full table scan, and it's slow.

This is where indexes save the day.

How Indexes Work

An index is like the back of a textbook. Instead of reading page by page to find mentions of a topic, you flip to the index, find the topic, and jump directly to the relevant pages.

A database index works the same way. If you create an index on the email column, the database builds a data structure (usually a B-tree) that maps email addresses to their corresponding row locations. Now, finding a customer by email is nearly instant — even with 100 million records.

Trade-offs

But indexes aren't free.

Storage: An index takes up disk space.
Write speed: Every time you insert or update a customer, the database must also update the index on that column.

This is why you don't index everything. You strategically index columns that are frequently searched.

Query Optimization

Most databases include an optimizer — a smart system that figures out the fastest way to execute your query. You can see its plan using EXPLAIN:

EXPLAIN SELECT * FROM customers WHERE email = 'john@example.com'

This shows whether it's using your index (good) or doing a full table scan (bad). If your queries are slow, the optimizer's plan is the first place to look.

Part 5: Transactions — Safety in a Chaotic World

Here's a dangerous scenario: A customer transfers $100 from one account to another.

The database needs to:

Deduct $100 from Account A
Add $100 to Account B

What if the system crashes after step 1 but before step 2? Money disappears.

Transactions prevent this. A transaction is a guarantee: either all steps succeed, or none of them do.

ACID: The Database's Promise

Atomicity: The transaction is all-or-nothing.
Consistency: The database always stays in a valid state.
Isolation: Concurrent transactions don't interfere with each other.
Durability: Once committed, data survives crashes.

Locks and Concurrency

When two users modify the same data simultaneously, conflicts arise. Databases use locks to prevent this.

Imagine two customers trying to buy the last item in stock:

Customer A reads: "5 items available"
Customer B reads: "5 items available"
Customer A buys 1: "4 items available"
Customer B buys 1: "4 items available"

Both succeeded, but you only had one item! A lock would prevent this. While Customer A's transaction is active, Customer B would wait for it to complete, see the true inventory count, and act accordingly.

The risk is deadlocks — a circular wait where Transaction A waits for B, and B waits for A. Modern databases detect and resolve these automatically.

Part 6: Real-World Performance Challenges

Understanding databases academically is one thing. Building fast systems is another.

The N+1 Query Problem

Here's a subtle but devastating mistake:

customers = database.query("SELECT * FROM customers")
for customer in customers:
    orders = database.query("SELECT * FROM orders WHERE customer_id = ?", customer.id)
    # process orders

If you have 100,000 customers, this executes 100,001 queries (one to get all customers, then 100,000 to get each customer's orders). This crawls.

The fix? One query with a join, or a more advanced technique like query batching.

Connection Pooling

Every time an application connects to a database, there's overhead. Connection pooling maintains a pool of reusable connections, dramatically improving performance under load.

Pagination and Keyset Pagination

Showing 100,000 rows on a single page is ridiculous. Pagination breaks results into pages. But there are two approaches:

Offset pagination (LIMIT 10 OFFSET 200): Simple but slow with large datasets, as the database counts and skips the first 200 rows every time.
Keyset pagination: Uses the value of the last row to fetch the next page. Faster at scale, but requires sorted, unique columns.

Database Migrations

Your schema isn't permanent. As your product evolves, you'll add columns, remove fields, or restructure tables. Migrations are scripts that safely transform your schema without losing data.

Caching

Repeatedly querying the same data is wasteful. Caching stores frequently accessed data in memory (using tools like Redis), reducing database load and improving response times.

Part 7: Choosing the Right Database

Not all databases are created equal. Your choice depends on your needs.

Relational Databases

PostgreSQL is incredibly powerful and open-source. It supports complex queries, advanced features (like JSON data types), and scales well. Ideal for most applications.

MySQL is simpler and faster for basic operations, making it popular for web applications.

SQL Server (Microsoft) is feature-rich and widely used in enterprise environments.

NoSQL Databases

MongoDB stores documents (JSON-like objects) instead of rows. Great for unstructured or rapidly changing data, but sacrifices the safety guarantees of relational databases.

Firestore (Google's cloud offering) is serverless and scales automatically, perfect for mobile and web applications where you don't want to manage infrastructure.

The Decision Framework

Ask yourself:

Do I need strict consistency? Relational databases are better.
Is my data highly structured? Relational.
Does my schema change frequently? NoSQL might be better.
Do I need complex queries and joins? Relational.
Am I building a simple, fast-scaling app? Consider NoSQL.

For our e-commerce example, a relational database like PostgreSQL is the clear choice. The data is structured, relationships are complex, and consistency is critical (you can't have duplicate orders or corrupted inventory counts).

The Mental Model

After understanding all of this, here's what a database fundamentally is:

A database is a disciplined, organized system for storing data in a way that makes retrieval fast, updates safe, and relationships clear.

It prevents data corruption through transactions. It makes queries blazingly fast through indexes. It connects related data through foreign keys. It keeps multiple users from stepping on each other through locks. And it's been refined over decades to handle millions of simultaneous operations reliably.

The complexity you see in real-world databases isn't overengineering — it's the accumulated solution to real problems that arise at scale.

Conclusion: From Theory to Practice

Whether you're building a startup or joining an existing team, databases are the backbone of modern applications. Understanding how they work transforms you from someone who writes queries to someone who understands why their queries are fast or slow.

The journey doesn't end here. Each topic we've covered — normalization, indexing, transaction isolation, optimization — has depth. But with this foundation, you understand the core concepts that everything else builds upon.

Start with PostgreSQL. Design your schema thoughtfully. Write clear queries. Monitor performance. And remember: the best database design is often the simplest one that solves your problem.

References & Sources

C.J. Date. "An Introduction to Database Systems" (11th Edition). Pearson, 2019. — The foundational textbook on relational database theory and design.
Designing Data-Intensive Applications by Martin Kleppmann. O'Reilly Media, 2017. — Essential reading for understanding real-world database challenges, consistency models, and distributed systems.
PostgreSQL Official Documentation. https://www.postgresql.org/docs/ — Comprehensive guide to PostgreSQL features, indexing strategies, and query optimization.
Use The Index, Luke! Markus Winand. — Free online resource specifically about database indexing and query optimization. https://use-the-index-luke.com/
Database Internals by Alex Petrov. O'Reilly Media, 2019. — Deep dive into how databases work internally, covering B-trees, LSM trees, and transaction processing.
ACID Transactions in Distributed Systems. Research papers on MVCC and isolation levels. ACM Transactions on Database Systems. — Academic foundation for understanding transaction handling.
MongoDB Documentation. https://docs.mongodb.com/ — Reference for NoSQL database design patterns and when to use document-based systems.
Google Cloud Firestore Documentation. https://cloud.google.com/firestore/docs — Modern approach to serverless databases and their trade-offs.
Transaction Processing and Recovery in Databases. Ramakrishnan & Gehrke. "Database Management Systems" (3rd Edition). McGraw-Hill, 2003. — Definitive source on how databases handle transactions and ensure durability.
The Anatomy of a Database Query. SQL query optimization techniques as documented by major DBMS vendors including PostgreSQL, MySQL, and SQL Server optimization guides.

Author's Note: This article synthesizes fundamental concepts from decades of database research and industry best practices. The examples and analogies are designed to make these concepts accessible to those encountering databases for the first time, while maintaining technical accuracy grounded in how production systems actually work.

Find me across the web:

Portfolio: ahmershah.dev
Crunchbase: @syed-ahmer-shah
Crunchbase Company: @syedahmershah
Clutch: @syed-ahmer-shah
Tech Behemoth: @syed-ahmer-shah
Design Rush: @syed-ahmer-shah
Edverise: @syed-ahmer-shah
Trust Pilot: @ahmershah.dev
LinkedIn: Syed Ahmer Shah
GitHub: @ahmershahdev
AWS Builder Profile: @syedahmershah
DEV: @syedahmershah
CoderLegion: @syedahmershah
Medium: @syedahmershah
Hashnode: @syedahmershah
Substack: @syedahmershah
HackerNoon: @syedahmershah
Substack: @syedahmershah
Facebook: @ahmershahdev
Linkedin Page: @syedahmershah
YouTube: @ahmershahdev
Instagram: @ahmershahdev
TikTok: @ahmershahdev

5 Best AI Wireframe Generators in 2026: Tested for Wireframing, UI, and Code Export

Syed Ahmer Shah — Fri, 21 Aug 2026 14:15:27 +0000

AI wireframe generators have evolved from producing crude sketches to delivering production-ready dashboard mockups with cohesive design systems, realistic data, and structured code output—all from a single detailed prompt. The transformation is remarkable. To cut through the noise, I ran a controlled benchmark: the same comprehensive prompt across five leading tools in a single afternoon.

The challenge was specific: generate a three-screen SaaS dashboard called "Luma" with premium visual design, complete data visualization, and export-ready structure. The constraints were intentional—vague prompts hide weak tools. Tight specs expose them.

Here's what I found, tool by tool.

The Prompt

"Design and build a premium, modern SaaS business dashboard called 'Luma'. Create 3 connected desktop-first screens with a luxurious, high-end visual style: (1) Dashboard — monthly revenue, total customers, conversion rate, revenue trend chart, recent transactions, top-performing products, and a compact activity feed; (2) Analytics — revenue and customer-growth charts with daily/weekly/monthly filters, traffic sources, conversion funnel, customer segments, and key performance metrics; (3) Settings & Profile — company profile, user information, notification preferences, billing plan, and security settings. Use a sophisticated deep-purple and violet color palette with subtle gradients, dark surfaces, premium typography, soft shadows, rounded cards, and strong visual hierarchy. Keep spacing consistent and use a unified design system across all screens. Make the layout responsive and professional enough for a real SaaS product. Include realistic sample data and interactive UI elements where supported. Structure the output for easy UI refinement and code export."

Flowstep: Best AI Wireframe Generator for Fast Multi-Screen UI & Code Export

" width="800" height="409">

Generation Time: ~1.2 minutes ⚡

First Impression

Flowstep positions itself as a "design engineer" tool, and that framing is accurate. The split-screen interface—chat on the left, infinite canvas on the right—feels collaborative rather than transactional. The rendering speed is immediately impressive. Before competitors even started generating, Flowstep had delivered three polished desktop screens.

UI/UX Analysis

The output demonstrates strong structural understanding. The Dashboard screen features a purple gradient header with key metrics displayed in card format ($284,590 monthly revenue, 18,240 total customers, 4.85% conversion rate, $3,210 average revenue per user). The revenue trend chart uses a violet line against the dark surface, and the Recent Transactions table shows transaction data with status indicators (completed in green, pending in neutral). The Top Performing Products section ranks items with revenue values.

The Analytics screen delivers complexity without visual noise. Multiple metric cards sit at the top (displaying growth percentages), and dual charts dominate the lower area—a revenue growth trend line with purple/pink gradients and a comprehensive traffic sources breakdown. The custom filter system for daily/weekly/monthly views is functional and subtly implemented. The conversion funnel appears as a cascading visual, and the customer segments pie chart uses the primary purple with complementary accent colors.

The Settings & Profile screen maintains consistency while shifting focus to configuration. The company profile section, user information, notification preferences, billing plan selector, and security settings are logically grouped with clear visual separation. The color hierarchy remains consistent—purple for active states and primary actions.

Pros

Fastest generation: Completed in 1.2 minutes, enabling rapid iteration
Strong visual hierarchy: Clear distinction between primary metrics and supporting data
Figma integration: Direct copy-paste to Figma without requiring plugins
Code export ready: React/TypeScript/Tailwind CSS output is production-intended
MCP integration: Connects directly to coding agents like Cursor and Claude Code, allowing generated designs to flow into development workflows.
Interactive prototyping: Screens connect with functional navigation

Cons

Free tier is limited: The free plan is useful for testing, while the Starter plan costs $15/month for 80 messages.
Limited free exploration: Free tier credits deplete after a few full prompts

Code Export & Developer Readiness

Verdict: React/TypeScript with Tailwind CSS. The output includes component props, state management suggestions, and is structured for immediate developer pickup. Not just visual reference—actionable code scaffolding. Flowstep also connects via MCP to coding agents like Cursor and Claude Code.

Summary Verdict

Best for product designers who need fast, polished multi-screen drafts with a clean handoff path into Figma or React codebases. Flowstep's speed and design quality make it the top choice when time is critical.

2. Google Stitch: Best AI Wireframe Generator for Design Systems

Generation Time: ~2 minutes

First Impression

Google Stitch (acquired from Galileo AI in mid-2025, relaunched at Google I/O 2025 with Gemini) is the surprise performer of this test. It's free, browser-native, and produces output that rivals paid competitors. Loading Stitch feels lighter than its paid alternatives—no account overhead, instant start.

UI/UX Analysis

Stitch's first deliverable is a design token panel—a structured color palette, typography scale, button variants, and spacing system—before rendering any screens. This is unusual and valuable. The system shows:

Primary violet (#7C3AED) with secondary purples
A clean type scale (16px base)
Rounded corner tokens (8px, 12px, 16px)
Spacing scale (4px, 8px, 12px, 16px, 24px)

The Dashboard renders with high fidelity. The header metric cards ($284,590 revenue, 18,240 customers, 4.85% conversion) use subtle background gradients. The revenue trend chart is a smooth line graph with gradient fill. The Recent Transactions table has striped rows with color-coded status badges. The Top Products section uses a mini bar chart with purple bars and value labels.

The Analytics screen is comprehensive. The design shows four major sections: metric cards at the top, a dual-axis chart (revenue and customer growth), a traffic sources donut chart, and a conversion funnel visualization. The daily/weekly/monthly filter toggles are implemented as pill-style buttons. Customer segments appear as a horizontal breakdown with percentage labels.

The Settings & Profile screen uses a two-column layout—navigation sidebar on the left, content area on the right. Company Profile section, User Information fields, Notification Preferences checkboxes, Billing Plan selector, and Security Settings are clearly separated with visual dividers.

Pros

Completely free with generous monthly limits
Design system-first approach: Token panel surfaced before mockups
Multi-screen consistency: Color application and spacing are uniform
Figma export: Layers export directly to Figma files
React/HTML/CSS export: Multiple output formats supported
Browser-native: No installation or account friction

Cons

Google Labs product: No guaranteed long-term support
Generation limits: Monthly quota can constrain high-volume teams
Editing workflow: Less intuitive than specialized design tools
Limited customization: Token overrides require regeneration

Code Export & Developer Readiness

Verdict: Figma layers + HTML/Tailwind + React. The March 2026 update (Stitch 2.0) significantly improved code export fidelity. React components use semantic HTML and Tailwind utility classes.

Summary Verdict

Best for early-stage startups and founders who need high-quality mockups without budget constraints. Stitch offers surprising depth for a free tool, making it ideal for rapid prototyping and validation.

3. Figma Make: Best AI Wireframe Generator for Figma Teams

Generation Time: ~5 minutes ⏱️

First Impression

Figma Make is the only tool in this test that operates inside the design platform your team already uses daily. That native integration is significant—zero context switching for design teams on Figma's paid plans. However, this test revealed a notable edge: generation errors under load.

During testing, the Settings & Profile screen generation failed with a "Something went wrong" error on the second attempt. The tool eventually recovered, but this workflow interruption is rougher than competitors.

UI/UX Analysis

Where Figma Make succeeded, the output is refined. The Dashboard presents a dark-mode interface with a deep purple (#6D28D9) primary accent and rich teal-green (#14B8A6) for secondary elements. The metric cards show clean typography (Figma's system typeface) with percentage change indicators in red/green. The revenue trend chart uses a curved line with subtle grid lines. Recent transactions display as a bordered table with category labels inline (Enterprise, Pro, Premium status tags).

A notable UX decision: Figma Make included category labels directly on transaction rows, reducing cognitive load compared to tools requiring separate reference. The Recent Transactions section shows company names, transaction amounts, status badges, and timestamps in a compact but readable layout.

The Analytics screen (when it rendered without errors) included a bar chart for revenue trends with month labels, a conversion funnel as a cascading flow, and a customer segments breakdown. The traffic sources visualization uses a donut chart with colored segments and a legend. The interface maintains dark-mode sophistication—subtle shadows, careful color contrast, rounded components.

The Settings & Profile screen uses a clean sidebar-plus-content layout. Profile picture placeholder, user name, email, notification preferences as toggle switches, billing plan selector with plan descriptions, and security settings are logically grouped. The design system coherence is the strongest among design-file outputs.

Pros

Native Figma integration: No export friction for design teams
Design system preservation: References existing Figma variables and libraries
Design Mode + Dev Mode: Seamless handoff from design to development
Dark-mode polish: Visual sophistication in color and typography choices
Inline labeling: Smart UX decisions (category tags on transactions)
Config 2026 updates: GitHub sync and visual code editing now available

Cons

Generation errors: Tool fails under load, requiring reprompting
Slowest generation: ~5 minutes vs. competitors' 1-3 minutes
Error recovery friction: Must restart from scratch on failure
Separate experience: Still a distinct interface from main Figma editor
Paid plan requirement: Full features locked behind Figma's pricing

Code Export & Developer Readiness

Verdict: Figma Dev Mode + Code Layers. The Config 2026 update introduced code layers and GitHub import, enabling visual code editing. MCP compatibility adds programmatic integration. Strong developer integration for teams already on Figma Enterprise or Pro plans.

Summary Verdict

Best for design teams embedded in Figma who can tolerate occasional generation errors in exchange for seamless design-system preservation and native integration. The workflow advantage for Figma teams outweighs the speed and reliability drawbacks.

4. Replit Agent: Best AI Wireframe Generator for Full-Stack Prototyping

Generation Time: ~3.4 minutes

First Impression

Replit Agent names its projects without being asked—it called this one "Luma Dashboard," interpreting intent rather than just following instructions. The agent also explains its build plan in clear steps before generation, building confidence during the longer creation cycle. This narrative clarity is a genuine UX advantage.

UI/UX Analysis

The aesthetic is intentionally premium: a dark purple/slate background (#0F172A) with vivid violet accents, rounded cards, subtle gradients, and high-contrast white typography. The Dashboard has a strong visual hierarchy, starting with the "Good morning, Maya" greeting and "+ Add transaction" CTA, followed by four prominent KPI cards for Monthly Revenue, Total Customers, Conversion Rate, and Average Order Value. The Revenue Overview area chart takes the main visual position, while the Top Products card and recent Activity feed provide secondary information without overwhelming the screen.

The Analytics screen increases information density while keeping the layout organized. Four headline metrics appear at the top, followed by a dual-line Revenue & Customer Growth chart, a Traffic Sources donut chart, and a Conversion Funnel visualization. The different chart types make the sections easy to distinguish, while the consistent purple accent system keeps the screen visually connected to the Dashboard.

The Settings & Profile screen follows the same application structure and includes workspace navigation for Settings, Customers, and Billing. The third generated frame sits partially outside the initial canvas viewport, so it requires panning to inspect fully. The generated screens otherwise maintain a consistent visual language across the dashboard.

Pros

Agentic planning: Explains build strategy before execution
Shared CSS token system: Unified design variables across screens
Intentional dark aesthetic: Not a default, but deliberately chosen
Full source code access: HTML/CSS/JavaScript or React depending on agent structure
Good code quality: Production-intent structure despite agent generation

Cons

Slow generation: 3.4 minutes vs. Flowstep's 1.2 minutes
Expensive to iterate: 29% free credit limit; rapid iteration is costly
Paid plan dependency: Serious iteration requires Replit credits

Code Export & Developer Readiness

Verdict: Full source code with HTML/CSS/JS or React. Code quality is strong; the agent structures output for both front-end frameworks and vanilla implementations. Good scaffolding for technical founders, though iteration cost is high.

Summary Verdict

Best for technical founders who want agentic building with transparent planning, full code access, and intentional dark design. The planning narrative and comprehensive code export appeal to developers, though the iteration cost and generation speed are drawbacks.

5. Base44: Best AI Wireframe Generator for Working SaaS Apps

Generation Time: ~3.7 minutes

First Impression

Base44 doesn't generate mockups—it builds deployed applications. When the prompt asked for "structure the output for code export," Base44 takes an application-first approach: instead of producing a static mockup, it builds a working SaaS application with navigable routes and a live preview. The distinction matters: you don't get a design file; you get a working app.

UI/UX Analysis

Base44 takes a more application-oriented approach than traditional wireframe tools. The Dashboard opens with an "Executive Overview" heading, a date filter, and three prominent KPI cards with green trend indicators. A wide Revenue Trend chart creates the main visual focus, while Live Activity, Recent Transactions, and Top Products form the supporting information layer. The hierarchy feels close to a real executive analytics dashboard rather than a simple generated mockup.

The Analytics and Settings & Profile screens were built as separate application routes rather than displayed simultaneously in the main preview. This keeps the interface closer to a real SaaS product, but makes side-by-side visual comparison less immediate. The sidebar provides clear navigation between Dashboard, Analytics, and Settings & Profile, while the top bar combines search with the administrator profile.

The visual system stays consistent throughout: deep luxury-purple and midnight surfaces, subtle borders, rounded cards, and glowing violet chart elements. The overall result feels polished and product-like, although the route-based structure means users need to navigate between screens instead of reviewing all three at once.

Pros

Outputs a real, deployed app: Not a mockup—a functioning product with a live URL
Consistent design system: Color tokens, spacing, and typography are unified
Integrated backend: Wix infrastructure post-acquisition provides auth and storage
Fastest path to working product: No design-to-code handoff required
Responsive web design: Mobile-first approach, though rendered as responsive web
Realistic data: Sample transactions, metrics, and user information are coherent

Cons

Web app, not native mobile: Mobile-first interpreted as responsive web, not iOS/Android frame
Code export locked behind paywall: Builder plan ($40/month) required for GitHub export
Backend proprietary: Infrastructure stays on Base44; significant vendor lock-in
No design file export: Can't import into Figma or other design tools
Limited customization post-generation: Design changes require regeneration or manual code editing

Code Export & Developer Readiness

Verdict: Frontend React export via GitHub (Builder+ plans). Backend remains proprietary on Base44 infrastructure (Wix backend). Full-stack is locked in; only frontend can be exported. This is a meaningful consideration for teams wanting long-term code portability.

Summary Verdict

Best for non-technical founders who want a working SaaS product immediately, not a prototype or design file. Base44 eliminates the design-to-development gap entirely, but the vendor lock-in on backend and paywall on code export are trade-offs to consider.

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 prototypes, 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.
Figma Make: Best for teams operating directly inside the Figma ecosystem, leveraging existing design system variables, code layers, and Dev Mode workflows.
Replit Agent: Best for full-stack agentic web development featuring dark-mode design systems and direct source code access.
Base44: Best for generating deployed web applications with integrated backend infrastructure, authentication, and live hosted URLs.

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

Find me across the web:

Portfolio: ahmershah.dev
Crunchbase: @syed-ahmer-shah
Crunchbase Company: @syedahmershah
Clutch: @syed-ahmer-shah
Tech Behemoth: @syed-ahmer-shah
Design Rush: @syed-ahmer-shah
Edverise: @syed-ahmer-shah
Trust Pilot: @ahmershah.dev
LinkedIn: Syed Ahmer Shah
GitHub: @ahmershahdev
AWS Builder Profile: @syedahmershah
DEV: @syedahmershah
Medium: @syedahmershah
Hashnode: @syedahmershah
Substack: @syedahmershah
HackerNoon: @syedahmershah
Substack: @syedahmershah
Facebook: @ahmershahdev
Linkedin Page: @syedahmershah
YouTube: @ahmershahdev
Instagram: @ahmershahdev
TikTok: @ahmershahdev

Change One Number. Take Everything.

Syed Ahmer Shah — Tue, 11 Aug 2026 10:49:45 +0000

Picture This

You're checking into a hotel. The receptionist hands you a key card and says, "Room 204, third floor." You take the elevator, swipe the card, and walk in.

But what if that key card worked on every room in the building?

What if instead of being locked to Room 204, it opened 205, 206, 301 — any door you tried?

You didn't pick the lock. You didn't break a window. You just tried other doors.

That is IDOR.

And it's the single most widespread vulnerability in web applications today — not because it's sophisticated, but because it's devastatingly easy to miss when you're building fast.

The Hack Hollywood Never Shows You

If you've seen a hacking scene in a movie, you know the formula:

A programmer typing furiously in a dark room
Green text cascading down a black screen
Someone saying "I'm in" over dramatic music
The audience gasps

Real-world hacking is almost never like that.

The most damaging breaches in recent years didn't require genius, exotic exploits, or nation-state resources. They required one thing: someone patient enough to change a number in a URL.

The Vulnerable URL

Original (yours):

https://app.example.com/api/profile?user_id=101

Modified (someone else's data):

https://app.example.com/api/profile?user_id=102

What Happens

If the developer didn't check whether you actually own that profile — if the server just pulls the data and returns it — you now have access to someone else's private information.

Their name
Their address
Their private messages
Their payment methods
Whatever that user_id unlocks

This is Insecure Direct Object Reference (IDOR). And it's not theoretical. It's the backbone of some of the most impactful security failures this decade.

OWASP Said It First. The Industry Ignored It.

The Open Web Application Security Project (OWASP) is a non-profit foundation that tracks and documents the most critical security risks in web applications.

Every few years, they release the OWASP Top 10: a research-backed list of vulnerabilities actively destroying real systems and real user data.

The Shift That Should Alarm You

Year	Rank	Vulnerability
2017	#5	Broken Access Control
2021	#1	Broken Access Control

What moved to #1? Access control failures. IDOR lives here.

What didn't?

Nation-state malware
AI-assisted intrusions
Zero-day exploits

The Statistic That Should Stop Every Developer Mid-Commit

94% of applications were tested for some form of broken access control, with an average incidence rate of 3.81%.

— OWASP Top 10, 2021

Translation: Security auditors test for Broken Access Control in nearly every application they scan (94% coverage). While only 3.81% of tests trigger a vulnerability, Broken Access Control still holds the #1 spot on the OWASP Top 10. The category maps to 34 separate CWEs (the highest of any group), with IDOR (Insecure Direct Object References) remaining one of the most frequently exploited flaws.

Why IDOR Is Effortless to Exploit

Doesn't require cracking encryption
Doesn't require breaking authentication
Requires curiosity
Requires a willingness to change a parameter

That's the entire attack surface.

An Analogy That Makes It Clear: The Hospital Filing System

The Intended Flow

A nurse has access to her own assigned patients' files — say, Tab 101.

She logs in
Pulls Tab 101
Does her job
Logs out

Perfect. This is how it should work.

The Broken Flow

The system is poorly designed. Once logged in, she can type any tab number — 102, 103, 500 — and pull any patient's private medical history from anywhere in the hospital.

She didn't steal credentials. She didn't hack anything. She used her own valid, legitimate access.

The system just forgot to ask one critical question:

"Do you have the right to see this specific record?"

The Core Flaw

The system authenticated her perfectly — confirmed she was who she said she was.

The system completely forgot to authorize what she could actually touch.

Authentication vs. Authorization (Critical Difference)

Concept	Question	Function
Authentication	"Are you who you say you are?"	Confirms identity
Authorization	"Here's what you're allowed to do"	Controls access

IDOR Happens When: Developers nail authentication but forget authorization entirely.

This is the entire vulnerability.

What the Vulnerable Code Actually Looks Like

Here's a simplified API route. You don't need to be a developer to follow the logic — just read it like English.

VULNERABLE CODE (Node.js/Express)

app.get('/api/orders/:orderId', async (req, res) => {
  const orderId = req.params.orderId;

  const orders = await db.query(
    'SELECT * FROM orders WHERE id = ?', [orderId]
  );

  res.json(orders);  // Returns the order without checking ownership
});

What's wrong here?

The API takes orderId from the URL and returns the result. Full stop.

Missing: A check asking "Does the person making this request actually own this order?"

The Attack:

User logs in as themselves
User requests /api/orders/1001 (their order)
User changes URL to /api/orders/1002 (someone else's order)
Server returns it anyway
Repeat: 1003, 1004, 1005...
Entire orders table exposed (every receipt, address, payment method)

FIXED CODE

app.get('/api/orders/:orderId', async (req, res) => {
  const orderId = req.params.orderId;
  const sessionUserId = req.session.userId;  // Who's actually logged in?

  const orders = await db.query(
    'SELECT * FROM orders WHERE id = ? AND user_id = ?',
    [orderId, sessionUserId]  // Two conditions required
  );

  if (!orders || orders.length === 0) {
    return res.status(403).json({ error: 'Access denied' });  // Deny if not owner
  }

  res.json(orders[0]);  // Return the single matched order
});

What changed?

One line: Get the logged-in user's ID from the session
One condition: Query now requires BOTH order ID AND matching user ID
One check: Return 403 (Forbidden) if the order doesn't belong to this user

The Result:

If someone tries to access Order 1002 while logged in as User 45, but Order 1002 belongs to User 89 — the query returns nothing. Forbidden.

That's the entire fix. That's what prevents a breach that could expose your entire customer database.

Note on HTTP Status Codes: The example uses 403 Forbidden (user exists but lacks access). Some teams prefer 404 Not Found to avoid revealing resource existence. Choose based on your threat model — 403 is more informative for legitimate users, while 404 adds obscurity.

Real-World Catastrophe: Parler, January 2021

The Disaster

In January 2021, Parler — a social media platform that had grown to 15+ million users — suffered one of the most complete data exposures in recent memory.

What Researchers Found

Issue	Impact
Publicly accessible API endpoints	Attackers could request any data
Sequential, predictable post IDs	Easy to guess and enumerate
No rate limiting	Could scrape at scale without detection
No authorization validation	APIs returned data to anyone

How It Was Exploited

Researchers wrote simple scripts that:

Cycled through post IDs (1, 2, 3, 4...)
Retrieved every post ever made on the platform
Including "deleted" posts (still accessible via ID)
Including GPS metadata embedded in media files
Scraped videos, photos, messages in bulk

No server room break-in. No encryption cracked. No sophisticated exploit.

Just predictable IDs + missing authorization checks + no rate limiting = complete platform exposure.

The Consequences

The breach didn't just damage Parler's reputation.

Millions of users had their location data, private messages, and deleted content exposed. The archived data became evidence in federal investigations related to events at the U.S. Capitol.

Real legal consequences. Real harm to millions of users. Driven by a logic gap.

Why Smart Developers Keep Getting This Wrong

IDOR isn't a failure of intelligence. It's a failure of habit under pressure.

The Pressure Trap

Most developers understand authorization conceptually. Ask them to explain it and they'll give you a solid answer.

But when you're:

40 hours into a sprint
Racing toward a deadline
Writing endpoint after endpoint
Focused on the happy path (user logs in, gets their data, flow works)

The authorization check slips.

You move to the next feature. The adversarial path — what happens when someone deliberately probes your system — rarely makes it onto a sprint board when product launch is three days away.

The Invisibility Problem

IDOR is insidiously silent.

A missing authorization check doesn't:

Throw an error
Break tests
Crash staging
Fail CI/CD

A missing authorization check:

Passes your test suite
Works perfectly in staging
Behaves exactly as intended for every legitimate user
Remains completely invisible until exploited

Why Automated Tools Miss It

You can't run a linter and catch it. Static analysis tools won't flag it. It's a logic gap.

Logic gaps require deliberate human review, not automated tooling.

This is why OWASP classifies it as critical: it's a problem that tooling can't solve.

Enforce It at the Architecture Level, Not the Endpoint Level

The Wrong Way

Writing an authorization check into each individual endpoint fails the moment a developer forgets once.

Under deadline pressure? It will happen.

The Right Way (Level 1: Middleware)

Middleware = code that intercepts every request before it hits your endpoint handler, checking permissions upfront.

const requireOwnership = (resourceType, paramName) => async (req, res, next) => {
  const resourceId = req.params[paramName];
  const userId = req.session.userId;

  const isOwner = await checkOwnership(resourceType, resourceId, userId);

  if (!isOwner) {
    return res.status(403).json({ error: 'Forbidden' });
  }

  next();  // Only proceed if authorized
};

// Applied to any protected route
app.get('/api/documents/:id',
  requireOwnership('document', 'id'),  // Permission check first
  getDocument                           // Only execute if allowed
);

Benefits:

One reusable function
Attach to every protected route
Authorization impossible to accidentally omit
Baked into the pattern, not scattered across endpoints

Level 2: Rate Limiting (Prevent Bulk Enumeration)

IDOR attacks often involve trying many resource IDs in rapid succession to discover valid ones.

const rateLimit = require('express-rate-limit');

const apiLimiter = rateLimit({
  windowMs: 15 * 60 * 1000,  // 15 minutes
  max: 100,                    // 100 requests per IP per window
  message: 'Too many requests from this IP'
});

app.use('/api/', apiLimiter);

Why it matters:

Sequential IDs (1001, 1002, 1003...) become trivial to brute-force without rate limiting
A resourceful attacker can scrape thousands of records in seconds
Rate limiting creates friction — makes bulk enumeration time-prohibitive

Three-layer effect:

Layer 1: UUIDs make enumeration hard (can't guess)
Layer 2: Rate limiting makes enumeration slow (requests blocked)
Layer 3: Middleware makes enumeration pointless (requests denied anyway)

The Best Way (Level 3: Row-Level Security)

Teams at larger scale go further: Row-Level Security (RLS) at the database level.

Here's why this matters:

Application-layer middleware is solid, but it's still software you wrote. One refactor, one mistake, one callback that skips middleware = gap created.

Row-Level Security moves enforcement to the database itself.

Layer	Who Enforces?	Weakness
Application Middleware	Your code	Humans forget
Database RLS	Database engine	No human variable

How Database RLS Works

Your database enforces the rule: "For this session user, only return rows where user_id matches this session's userId."

Even if you:

Forget the middleware
Write a raw SQL query
Connect through a different application
Bypass application logic entirely

The database still won't hand over data that doesn't belong to that user.

RLS Support by Database

PostgreSQL (True Native RLS):

ALTER TABLE orders ENABLE ROW LEVEL SECURITY;

CREATE POLICY user_orders ON orders
  FOR SELECT USING (user_id = current_user_id());

Oracle (Virtual Private Database): Implemented via VPD context and predicates.

MySQL Limitation: MySQL does NOT have native RLS. To achieve row-level security in MySQL, you must filter at the application layer using middleware (Layer 1 approach), use views with row-level filtering (brittle because views are easily bypassed if application logic changes), or consider PostgreSQL if row-level security is critical for your use case.

Queries execute at the row level in PostgreSQL/Oracle, filtered by the database engine itself before results return. An attacker bypassing your application layer still can't extract data the database layer won't allow.

This is why PostgreSQL with RLS is the gold standard for teams handling sensitive data at scale.

The Architecture Principle

Authorization should be structurally enforced, not manually remembered.

Four-layer defense:

Application Middleware — Primary defense (hard to bypass)
Rate Limiting — Prevents bulk enumeration (limits friction)
Database RLS — Last line of defense (bulletproof, PostgreSQL/Oracle only)
Code Review — Catches logical errors (human layer)

One Small Tweak to Make It Bulletproof: Sequential IDs vs. UUIDs

Here's a practical—and often overlooked—layer of defense-in-depth: switch from sequential IDs to non-predictable identifiers.

CRITICAL: UUIDs Are NOT a Replacement for Authorization

UUIDs are an enhancement that makes attacks harder, not impossible.

This is where teams mess up.

The Problem with Sequential IDs

The Parler breach worked because attackers could simply increment post IDs:

/api/posts/1
/api/posts/2
/api/posts/3
/api/posts/4
... (script the rest)

Your API returned results for every number. Bulk scraping was trivial with basic scripting.

UUIDs (v4) Are Different

/api/posts/550e8400-e29b-41d4-a716-446655440000
/api/posts/6ba7b810-9dad-11d1-80b4-00c04fd430c8
/api/posts/f47ac10b-58cc-4372-a567-0e02b2c3d479

An attacker:

Can't guess the next UUID
Can't script a counter loop
Can't enumerate your entire database with for-loop + curl

But they CAN still exploit the system if authorization checks are missing.

Why Developers Ask: "Why Not Just Use UUIDs?"

Because IDs alone don't control access.

An attacker who knows a valid UUID but doesn't own it can still request it.

The Trap:

A team:

Switches to UUIDs
Celebrates the "security improvement"
Weakens authorization checks ("now IDs are unpredictable, we're safer")
Ends up with worse security than they started with

It feels safer (harder to guess IDs) but it's actually more vulnerable (no authorization check).

The Correct Mental Model: Layered Defense

UUIDs solve enumeration. Authorization solves access control. You need both.

Together, they create four layers of defense:

Layer 1: Enumeration Defense
↓ Attacker can't guess valid resource IDs
↓ IDs are cryptographically random, not sequential

Layer 2: Access Control
↓ Attacker can't access IDs they don't own
↓ Middleware validates ownership before returning data

Layer 3: Rate Limiting
↓ Attacker can't probe resources at scale
↓ API rejects rapid successive requests

Layer 4: Database Enforcement
↓ Even if app-layer middleware fails, RLS blocks unauthorized access
↓ Database enforces "you can only see your own rows"

The Security Spectrum

Scenario	Vulnerability	Exploitability
Sequential IDs + No Auth	Critical	Easy (simple loop)
UUIDs + No Auth	Critical	Hard (need valid ID)
Sequential IDs + Middleware	Secure	Requires auth bypass
UUIDs + Middleware	Very Secure	Requires auth + ID guess
UUIDs + Middleware + RLS	Extremely Secure	Requires 3 breaches
UUIDs + Middleware + Rate Limit + RLS	Bulletproof	Requires 4 breaches

Why This Matters in Practice

Auto-incrementing integers (1001, 1002, 1003):

Designed for usability and storage efficiency
Scream "try the next number" to attackers
Enable trivial bulk scraping

UUIDs (v4):

Designed to be globally unique and unpredictable
Defeat enumeration attacks that make IDOR trivial
Require attackers to know valid IDs first

Together with proper architecture:

Layer 1: UUIDs prevent guessing
Layer 2: Middleware prevents access
Layer 3: Rate limiting prevents bulk enumeration
Layer 4: RLS prevents leakage

This isn't security through obscurity—it's defense-in-depth.

Make the attack surface materially harder to exploit, paired with proper access controls. Use UUIDs alongside, never instead of, proper ownership validation.

Testing for IDOR in Your Own Systems

You can't wait for external penetration testers to find this. Here's how to catch it before it reaches production.

Basic Manual Test (5 minutes)

Steps:

Create two test accounts — User A and User B
Log in as User A, perform an action (create an order, document, post)
Note the resource ID from the URL or API response (e.g., /api/orders/1234)
Copy the full request (using browser dev tools, Postman, or curl)
Log in as User B in a different browser/incognito window
Paste the request, changing only the resource ID to one you know User B doesn't own
If you get access, you have IDOR
Repeat with 5-10 different resources to be thorough

Example with curl:

# User A requests their order (authorized)
curl -H "Cookie: session=user_a_token" https://app.com/api/orders/1001

# Attacker (with User B token) requests User A's order
curl -H "Cookie: session=user_b_token" https://app.com/api/orders/1001

# If this works: IDOR vulnerability confirmed

Automated Testing (For CI/CD)

Add to your Jest/Mocha test suite:

describe('IDOR Protection', () => {
  it('should not allow User B to access User A resources', async () => {
    // User A creates a document
    const userAToken = await login('user_a@test.com', 'password');
    const res = await api.post('/documents', 
      { title: 'Secret' }, 
      { headers: { Authorization: `Bearer ${userAToken}` }}
    );
    const docId = res.data.id;

    // User B tries to access it
    const userBToken = await login('user_b@test.com', 'password');
    const accessAttempt = await api.get(`/documents/${docId}`, 
      { headers: { Authorization: `Bearer ${userBToken}` }, validateStatus: () => true }
    );

    // Should be denied
    expect(accessAttempt.status).toBe(403);
  });
});

What to Test

Single-resource access (GET /documents/123)
Batch operations (GET /documents?ids=1,2,3 — can attacker filter others' IDs?)
Nested resources (GET /users/123/posts/456 — is both owner checked?)
Update operations (PUT /documents/123 — can attacker modify others' docs?)
Delete operations (DELETE /documents/123 — can attacker delete others' docs?)
Export/Download (GET /documents/123/export — does permission checking apply here too?)

Common blind spots:

Admin endpoints often skip authorization ("if (req.user.isAdmin)...")
File upload/download endpoints ("just serve the file")
Reporting endpoints ("aggregate data, no need to filter")
Export features ("CSV download, should be open")

Test these especially carefully.

Nested and Chained Resources

IDOR doesn't stop at single-level access. For hierarchical APIs, check authorization at every level.

Example: Nested Resource

GET /users/123/posts/456/comments/789

An attacker might:

Know User 123 exists
Try User 124, 125, 126... to enumerate users
For a user they don't know, try accessing their posts
For a valid post, try changing the comment ID

Each ID in the path needs independent validation:

app.get('/users/:userId/posts/:postId/comments/:commentId', 
  requireOwnership('user', 'userId'),      // User must own the user record
  requireOwnership('post', 'postId'),      // User must own the post
  requireOwnership('comment', 'commentId'), // User must own the comment
  getComment
);

Without this chaining, an attacker only needs to guess one ID to cascade access.

The Myth That's Getting People Hacked

The Persistent Belief: "Serious threats require serious technical sophistication."

Attackers running server farms
AI-assisted intrusion kits
Reverse-engineering firmware for weeks
Nation-state-level resources

Reality: Some do this. Most don't.

What Actually Happens

OWASP's research tells a consistent story: The vulnerabilities doing the most damage are simple.

Changing a number in a URL ← Parler
Sending a request your account shouldn't allow
Accessing a file path nobody thought to restrict
Missing an authorization check

The Bounty Platform Truth

HackerOne — the world's largest vulnerability disclosure platform — reports:

IDOR and broken access control consistently represent a major portion of valid, high-severity submissions.

Companies are paying researchers thousands of dollars to find issues that would have taken a developer ten minutes to prevent at build time.

The economics are completely backwards.

And the people bearing the cost aren't just companies. They're users who trusted those companies with their data.

The Question You Should Be Asking

If You're a Developer

The question isn't whether your application has an IDOR vulnerability.

Given OWASP numbers, probability is not on your side.

The question is: Do you have a process that would catch one before it's exploited?

Ask yourself:

Do you audit your API routes for ownership validation?
Do you test your application like an adversary would?

*   Not as a logged-in user with good intentions

*   But as someone **acting maliciously, trying to access data you shouldn't allow them to access**

Do you enforce authorization at the architecture level?

*   Or trust individual developers to remember it?

Are your resource IDs predictable?

*   Sequential integers invite enumeration

*   Would UUIDs meaningfully change your attack surface?

Do you have rate limiting in place to prevent bulk enumeration?
For sensitive data, do you use database-level RLS (PostgreSQL)?

If You're Not a Developer

You still live with the consequences.

Broken Access Control sitting at #1 on OWASP's list for multiple cycles is not an anomaly.

It's a signal that the industry is consistently prioritizing shipping over securing.

The Final Truth

The most dangerous exploits are not the ones requiring genius.

They're the ones requiring a curious person and one moment of developer oversight.

References & Further Reading

Additional Learning

Want to test your understanding? Try:

PortSwigger's interactive IDOR labs (free)
HackTheBox vulnerable applications
OWASP WebGoat project

For your team:

Add IDOR testing to your security code review checklist
Include authorization validation in your API design guidelines
Implement middleware patterns as defaults, not options
Add automated IDOR tests to your CI/CD pipeline
If using PostgreSQL, enable Row-Level Security on sensitive tables

Implementation Checklist by Team Size

For Small Teams / Early Stage

Priority:

Implement UUID resources (not sequential IDs)
Add reusable authorization middleware on all protected routes
Add basic rate limiting to API endpoints

Why: Fast to implement, covers 95% of IDOR attacks, patterns are portable

Implementation time: 2-3 days

Code template:

// Middleware
const auth = (req, res, next) => {
  if (req.user?.id !== req.params.userId) return res.status(403).send('Forbidden');
  next();
};

// Route
app.get('/users/:userId/data', auth, handler);

For Growing Teams

Add to small team setup:

UUID resources ✓
Middleware patterns ✓
Rate limiting ✓
Database-level row filtering (view-based or app-enforced)
Automated IDOR tests in CI/CD

Why: Data complexity growing, multiple code paths to protect

Implementation time: 1-2 weeks

For Security-Conscious/Enterprise Teams

Full implementation:

UUIDs (enumeration defense)
Middleware (access control)
Rate limiting (bulk enumeration prevention)
PostgreSQL with RLS (database enforcement)
Automated testing + penetration testing
Security audit of all endpoints

Why: Eliminates IDOR as realistic attack vector, defense-in-depth, audit-ready

Implementation time: 2-4 weeks

Key Quotes for Your Team

For developers:

"Authorization should be structurally enforced, not manually remembered."

For architects:

"The database enforces the rule. It's physics, not policy."

For security teams:

"The most dangerous exploits are not the ones requiring genius. They're the ones requiring a curious person and one moment of developer oversight."

For managers:

"A developer forgetting one authorization check takes ten minutes to prevent, thousands of dollars to remediate, and immeasurable time to recover reputation."

Find me across the web:

Portfolio: ahmershah.dev
Crunchbase: @syed-ahmer-shah
Crunchbase Company: @syedahmershah
Clutch: @syed-ahmer-shah
Tech Behemoth: @syed-ahmer-shah
Design Rush: @syed-ahmer-shah
Edverise: @syed-ahmer-shah
Trust Pilot: @ahmershah.dev
LinkedIn: Syed Ahmer Shah
GitHub: @ahmershahdev
AWS Builder Profile: @syedahmershah
DEV: @syedahmershah
Medium: @syedahmershah
Hashnode: @syedahmershah
Substack: @syedahmershah
HackerNoon: @syedahmershah
Substack: @syedahmershah
Facebook: @ahmershahdev
Linkedin Page: @syedahmershah
YouTube: @ahmershahdev
Instagram: @ahmershahdev
TikTok: @ahmershahdev

The Kimi K3 Paradox: The World's Most Powerful Open AI Model Nobody Can Actually Run

Syed Ahmer Shah — Mon, 03 Aug 2026 12:12:48 +0000

When Freedom Meets Impossibility

In July 2026, Moonshot AI dropped something remarkable: Kimi K3, a 2.8 trillion-parameter artificial intelligence model released with full open weights. This wasn't just another AI update. It was a statement. While OpenAI and Anthropic guard their most powerful models behind closed doors, charging premium prices, Moonshot said "here, take it all—even the recipe."

But there's a catch so massive it swallows the promise whole. Kimi K3 is simultaneously the most impressive open AI model ever released and completely inaccessible to anyone without a data center. It's powerful and helpless. Revolutionary and impractical. Welcome to the Kimi K3 paradox.

What Is Kimi K3 Actually?

Think of K3 as an impossibly large brain. It contains 2.8 trillion parameters—roughly 28 times more than GPT-4, if you're trying to visualize it. Parameters are the digital equivalent of neural connections. More connections mean more nuance, better reasoning, and sharper answers. K3 handles text, images, and even video. It can read an entire novel in its 1-million-token context window (that's about 750,000 words—several novels at once).

The Architecture That Makes It Special

K3 uses something called Sparse Mixture-of-Experts (Sparse MoE). Instead of using all 2.8 trillion parameters for every question, K3 activates only 104 billion per token. It's like having an enormous library but only pulling out the specific books you need, rather than reading every page of every book. This makes it slightly less computationally impossible than it would be otherwise.

It also uses Kimi Delta Attention (KDA), Moonshot's hybrid attention mechanism designed to make long-context processing 6 times cheaper than older methods. For comparison, Claude models and GPT-5.6 still struggle with thousand-page documents. K3 laughs at them.

The model was trained using quantization-aware MXFP4 weights—a compression technique that squeezes the full 2.8 trillion parameters into 1.56 TB of storage. That sounds manageable until you realize 1.56 TB is roughly the size of 300 feature-length movies.

Head-to-Head Benchmarks: The Truth in Numbers

Here's what independent testing reveals when you strip away the marketing hype:

Overall Intelligence (Artificial Analysis Index)

Claude Fable 5: 59.86
GPT-5.6 Sol: 58.89
Kimi K3: 57.11
Claude Opus 4.8: 55.69

K3 lands fourth overall. Not last, but not first. Claude Fable 5 still reigns as the smartest frontier model for broad reasoning tasks. The gap is roughly 2-3 points—what AI researchers call "tight by historical standards." Three years ago, this gap would have been decisive. Today, it's noise.

Where Kimi K3 Actually Dominates

But the aggregate leaderboard tells only half the story. In specific domains, K3 crushes:

Frontend Code Arena (Real Developers Voting)

K3: 1,679 Elo points (#1)
Claude Fable 5: 1,631 Elo (#2)
GPT-5.6 Sol: 1,618 Elo (#3)

Real developers, voting blind on which model wrote better code, chose K3 seventeen places higher than its predecessor in just one generation. This matters because it's not a synthetic benchmark—it's humans saying "I'd actually use this for production work."

Programming Bench

K3: 77.8
GPT-5.6 Sol: 77.6
Fable 5: 76.8

Terminal-Bench 2.1 is one of K3's few losses (88.3 vs 88.8 to GPT-5.6 Sol), but the difference is half a point—statistically meaningless.

The Cost-Per-Task Reality

This is where K3 becomes genuinely interesting:

Kimi K3: ~$0.94 per completed task
Claude Opus 4.8: ~$1.80 per task
Claude Fable 5: ~$2.80 per task
GPT-5.6 Sol: ~$2.60 per task

K3 costs 50-65% less while delivering frontier-level performance on coding and reasoning. If your company runs a thousand AI tasks per month, K3 saves you tens of thousands of dollars.

The Hardware Trap: Why Most of Us Can't Use It

Here's where K3's promise collapses into ironic tragedy.

What Moonshot Says You Need

The official minimum: 4 NVIDIA H100 GPUs with 80 GB of memory each (320 GB total VRAM) to run K3 at reduced precision with a shortened context window. At $40,000 per H100, that's $160,000 just for GPUs, before servers, cooling, power infrastructure, and networking hardware.

What You Actually Need for Production

Reality is darker:

Minimum viable cluster: 8-16 H100s ($320,000-$640,000)
System RAM: 1.5-2 TB of DDR5 ECC registered memory per node ($30,000+)
CPU: Dual AMD EPYC 9654 processors (96 cores each) per node ($15,000+)
Storage: 2+ TB fast NVMe to actually hold the model weights ($10,000+)
Networking: NVIDIA ConnectX-7 or DGX Spark for GPU interconnect ($20,000+)
Cooling and power: $50,000+
Linux expertise: Priceless (K3 doesn't run on Windows or Mac)

A realistic self-hosted K3 setup costs $500,000 to $2 million. The most advanced edge deployment validations use 32×H100 clusters, which puts us squarely in the multi-million-dollar range.

The Open Weights Paradox

Moonshot released the weights "open source" on July 27, 2026. You can download them from HuggingFace right now. But "open" doesn't mean "usable." It's like releasing the architectural blueprints for a nuclear power plant. Technically public. Practically accessible to perhaps 0.01% of humanity.

Who Actually Benefits from "Open" K3?

Tech giants: Google, Microsoft, Amazon—they already own data centers. K3 costs them nothing extra.
Wealthy Chinese organizations: Moonshot's state backing means Beijing-affiliated institutions get free access to frontier AI.
Rich entrepreneurs: If you have $1+ million lying around and want to run cutting-edge AI, K3 is now an option.
Everyone else: Use the API ($3 per million input tokens, $15 per million output tokens).

For 99.9% of users, K3's "openness" is theatrical. It matters for the record books. For actual adoption, most people pay Moonshot to run K3 on their servers.

The Allegations: Anthropic Fires Back (Then Gets Burned)

In July 2026, the White House accused Moonshot AI of intellectual property theft. Specifically: creating K3 by distilling Anthropic's Claude Fable 5 model. Michael Kratsios, director of the White House Office of Science and Technology Policy, claimed Moonshot conducted "large-scale covert distillation" using a "sophisticated internal platform" to steal American technology.

The evidence? Timing. Claude Fable 5 launched July 1, 2026. Kimi K3 appeared July 16, 2026. Two weeks later. The US Treasury Secretary suggested sanctions.

Moonshot's Response?

Silence. Then skepticism from independent AI researchers, who noted that two weeks isn't enough time to distill a frontier model, even with unlimited compute. The white paper dropped with full technical details—architecture, training methodology, everything—available for scrutiny.

But Here's Where It Gets Complicated

Elon Musk's response flipped the entire narrative. On X, he wrote: "Anthropic is guilty of stealing training data at massive scale and has had to pay multi-billion dollar settlements for their theft. This is just a fact."

He's not entirely wrong.

The Uncomfortable Truth: Everyone's Hands Are Dirty

Anthropic built its reputation as the "privacy-first" AI company. Constitutional AI. Safety-focused. No training on customer data. It was true—for a while.

Then September 2025 happened.

Anthropic's Quiet Privacy Pivot

In late August 2025, Anthropic quietly announced a policy change to its consumer terms. Claude users—the free tier, Pro, Max—would now be asked to opt-in to having their conversations used for model training. The deadline was September 28. Millions of users got a popup with a black "Accept" button, pre-set to "on," buried in terms of service nobody reads.

Those who clicked through unknowingly extended their data retention from 30 days to 5 years. A 60x increase in how long Anthropic keeps your conversations.

The policy explicitly carved out commercial users (Claude for Work, Enterprise, API access). Those accounts remain protected. The privacy shift only applies to regular people using the consumer version.

The Irony Is Exquisite

Anthropic accused Moonshot of stealing its technology. But Moonshot operated within the terms of service—they created accounts and queried Claude, just like anyone else could. Anthropic's response was to... change its terms of service to let it train on more data.

Neither company's hands are clean. The difference is Anthropic had better PR.

What About OpenAI?

OpenAI's privacy policy is even less stringent. ChatGPT data training is opt-out, not opt-in. They also train on user data by default, which is one reason ChatGPT's privacy advocates prefer Claude despite Anthropic's recent pivot.

The Real Question: Why K3 Matters (Even If You Can't Use It)

Kimi K3 shouldn't matter. The hardware is impossible. The cost is ridiculous. 99% of users will never run it locally.

Yet it's the most important AI release of 2026.

Here's why: It proves frontier capability doesn't require a closed model.

For five years, OpenAI and later Anthropic argued that the most advanced AI systems had to stay proprietary. Safety, security, cost—the reasoning varied. But the implication was clear: only massive corporations could build frontier models.

K3 shattered that myth. A Beijing startup with Chinese government backing built the world's largest open-weight model, delivered it to technical standard, and released it for anyone with the infrastructure to use.

Whether you agree with Moonshot's methods or Anthropic's accusations, you can't un-see this. Open frontier models are now possible. The genie won't go back in the bottle.

For Developers and Businesses

K3 enables something closed models can't: complete control. Run it on your infrastructure. Fine-tune it for your tasks. Audit exactly what it does. No vendor lock-in. No unexpected policy changes. No Anthropic deciding next month to train on your data.

That's worth something, even if you access it via API.

The Bottom Line: K3 Is Good and Bad Simultaneously

Why Kimi K3 Is Genuinely Good

✓ Frontier-level reasoning and coding performance without corporate control ✓ 1 million token context window (industry leading) ✓ Open weights available for audit and modification ✓ 50-65% cheaper per task than Claude Fable 5 ✓ Number-one ranked model for frontend code development ✓ Breaks the OpenAI/Anthropic duopoly on cutting-edge AI

Why Kimi K3 Is Simultaneously Bad

✗ Self-hosting requires $500K-$2M+ infrastructure investment ✗ Inaccessible to 99.9% of users despite being "open" ✗ Training methodology and funding sources not fully transparent ✗ Distillation allegations (proven or not) cast doubt on independence ✗ Requires Linux expertise that most organizations don't have ✗ Control by a Beijing-based company (geopolitical implications)

The honest take: K3 is revolutionary for the AI industry and impractical for regular people. It's a statement about what's possible, funded and usable primarily by the wealthy and well-resourced. It's both the most democratic AI release ever and the most elitist.

How to Actually Access K3 (Without Selling Your House)

Option 1: The API (Recommended for 99% of Users)

Visit platform.kimi.ai. Create an account. Top up with credits. Use it like Claude or GPT. Pricing: $3/million input tokens, $15/million output tokens. A thousand queries costs roughly $5-20.

Option 2: OpenRouter

OpenRouter aggregates multiple AI APIs. You can access K3 through them without creating a separate Moonshot account. Add it to your app with five lines of code.

Option 3: Local if You're Insane (or Rich)

Download the model from huggingface.co/moonshotai/Kimi-K3. Follow the deployment guides at sglang.io or vllm.io. Budget $1+ million. Hire Linux engineers. Write a resignation letter in advance.

References and Further Reading

Moonshot AI. "Kimi K3 Technical Report." July 27, 2026.
Artificial Analysis. "LLM Intelligence Index v4.1." July 2026. www.artificialanalysis.ai
White House Office of Science and Technology Policy. Statement by Michael Kratsios re: Moonshot AI. July 22, 2026.
Arena.ai. "Frontend Code Arena Leaderboard." July 2026. www.arena.ai/leaderboard
Northflank. "Kimi K3: Benchmarks, pricing, hardware requirements, and self-hosting." July 2026.
Anthropic Privacy Center. "Consumer Terms Update and Data Training Opt-In." September 2025.
Bitdefender Security Blog. "Anthropic Shifts Privacy Stance, Lets Users Share Data for AI Training." September 2025.
Elon Musk (@elonmusk). Statement re: Anthropic data theft allegations. July 24, 2026. (X/Twitter)
Coders Era. "Kimi K3 Benchmarks: How It Stacks Up vs Fable 5, GPT-5.6 Sol." July 2026.
Yotta Labs. "Kimi K3 Model Size, Open Weights, and Hardware Requirements." July 2026.

Final Thought

The Kimi K3 debate isn't really about one company stealing from another. It's about power: who gets to control the tools that increasingly control civilization.

Anthropic accused Moonshot of theft. Fair criticism. But then Anthropic pushed out a policy that lets it train on millions of consumer conversations without explicit prior consent. OpenAI does the same. Google does the same. Every tech company tells you they're privacy-first while building sophisticated data pipelines.

Moonshot released an open model that nobody can actually use without becoming a corporation-sized operation. That's not exactly democracy.

Maybe the real story is simpler: everyone's playing the same game with slightly different marketing. And Kimi K3 is just the reminder that frontier AI belongs to whoever can afford it—whether that's measured in dollars or access to state resources.

The question isn't which company is most ethical. The question is: do you want AI controlled by Silicon Valley or Beijing? Because one way or another, those are your options in 2026.

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

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