标签：#coding

Why Does Python Need asyncio.Lock? INTRODUCTION After understanding asyncio.Semaphore , I thought I had learned everything required to control multiple coroutines. A semaphore limits how many coroutines can execute simultaneously. Then another question came to my mind. If Python's event loop executes only one coroutine at a time, why do we even need a Lock? Initially, I assumed a lock was unnecessary because there was only one thread. But after experimenting with shared variables, I realized that even though only one coroutine executes at a particular instant, multiple coroutines can still interfere with each other. In this article, I'll explain the problem that led to asyncio.Lock , how it works, and why almost every backend application uses it. What You Will Learn Why asyncio.Lock exists What is a race condition What is a critical section How Lock works internally Practical examples Real-world backend use cases Prerequisites Before learning asyncio.Lock , you should understand: Coroutines Event Loop await asyncio.Semaphore The Problem Suppose we have a shared variable. counter = 0 Now imagine two coroutines trying to increment it. async def increment (): global counter temp = counter await asyncio . sleep ( 1 ) counter = temp + 1 Initially I expected the final value to become 2 because two coroutines are incrementing the counter. But that wasn't what happened. Let's See What Actually Happens Initially counter = 0 Now Coroutine A starts executing. Read counter ↓ temp = 0 ↓ await The coroutine reaches await . The event loop suspends it and starts another coroutine. Now Coroutine B executes. Read counter ↓ temp = 0 ↓ await Notice something interesting. Both coroutines have already read counter = 0 Now Coroutine A resumes. counter = 1 Then Coroutine B resumes. counter = 1 The final value becomes 1 instead of 2 This is called a Race Condition . Why Did This Happen? Initially I blamed the Event Loop. Later I realized, the Event Loop didn't do anything wrong. Its job is

Here's the problem. Every AI coding agent (Cursor, Codex, Claude Code, whatever) is trained on millions of websites. Most of those websites are average. So when you prompt "build me a landing page," the model gives you the average of everything it's seen: a centered hero, a purple gradient, three equal feature cards, Inter font, ease-in-out , done. It's not broken. It's just mediocre by default. I'm 17 and I got tired of fighting this in every conversation. So I built VibeCurb : a collection of strict constraint skill files, that force AI agents to actually think about design before they touch code. How it works Every skill follows the same four-phase pipeline: Design Read - The agent reads your reference image, existing codebase, or brief and extracts design signals: typography, palette, layout, focal element, spacing. No code is written here. Quality Gate - The extraction has to pass before the agent is allowed to generate anything. It must prove it understands the design direction, not just spit out defaults. Precise Build - Code generation happens against the extraction, not against the model's built-in idea of what a "website" looks like. Each skill has its own build sequence. Visual Diff - The output is checked against the reference using PASS/FAIL tables across composition, typography, color, motion, and responsiveness. If it drifts, it gets caught. There's also an inline drift rejection layer. It catches known AI defaults (CSS keyword easings like ease-in-out , AI-purple #7c3aed gradients, generic glassmorphic cards, placeholder Lorem ipsum content) and flags them before they make it into the output. The skills Each skill constrains a specific problem space: awwwards-hero - Hero sections only. Six documented architectures (Cinematic Center, Editorial Split, etc.) with implementation blueprints. The agent picks one and commits. awwwards-sections - Pricing tables, bento grids, feature highlights, footers. Same pipeline, different element constraints. awwwards-

"A Trie isn't designed to store words. It's designed to make finding everything that shares the same beginning incredibly efficient." In the previous article, we explored a different kind of software problem. Some systems don't search using complete values. Instead, users provide only part of the information they know. The system must immediately suggest possible matches. Once you recognize that requirement, another question naturally follows. How should the system organize data so prefix searches become fast and natural? This is exactly the problem a Trie solves. Think About a Dictionary Imagine opening a physical dictionary. Suppose you're looking for the word: Application Do you start reading from page one? Of course not. You first go to the words beginning with: A Then you narrow further. Ap Then: App Every additional letter reduces the search space. A Trie works in a very similar way. Instead of repeatedly searching through every word, it follows the characters one by one. What Is a Trie? A Trie is a tree-like data structure where each node represents a character. Words that begin with the same characters share the same path. Consider these words. car card care cart A Trie stores them like this. Root ↓ c ↓ a ↓ r ├── end ├── d → end ├── e → end └── t → end Notice something interesting. The prefix: car is stored only once. Every longer word simply continues from that shared path. Every Data Structure Answers a Different Question By now we've seen several data structures, each solving a different design problem. A HashMap asks: Where is this exact object? A Heap asks: Which item has the highest priority? A Queue asks: Which task should happen next? A Stack asks: What is the current working context? A Trie asks: What begins with these characters? Choosing the right data structure starts with identifying which question your software needs to answer. Inserting a Word Imagine inserting: cat The Trie creates a path. Root ↓ c ↓ a ↓ t Now insert: car The beginning alread

A single-author repo of instruction files, not code, Ponytail passed 44,000 GitHub stars in nine days by making coding agents stop over-building. Its headline claim of 80-94% less code came from a flawed baseline; after a contributor said so, the maintainer rebuilt the benchmark as a real agentic run and published a lower figure of 54%. By Steef-Jan Wiggers

"A Stack isn't designed to store data. It's designed to make the most recent piece of work the easiest to access." In the previous article, we discovered a new kind of design problem. Some systems don't need to find the fastest item. Some don't need to process tasks in arrival order. Instead, they need to work with whatever happened most recently . That's exactly the problem a Stack solves. In this article, we'll understand how a Stack works and why its behavior appears naturally in many software systems. Imagine a Stack of Plates Think about a stack of dinner plates. Plate 4 ────────── Plate 3 ────────── Plate 2 ────────── Plate 1 ────────── When you need a plate, which one do you take? The one on the top. You don't pull out the bottom plate. Likewise, when placing a new plate, you put it on top. This simple rule defines the behavior of a Stack. What Is a Stack? A Stack is a data structure where both insertion and removal happen from the same end. The last item added is always the first one removed. This behavior is called LIFO (Last In, First Out). Push A ↓ Push B ↓ Push C ↓ Pop ↓ C Notice something important. A Stack isn't trying to preserve arrival order like a Queue. Instead, it preserves recency . The newest item is always the easiest to access. Every Data Structure Solves a Different Design Problem By now, we've seen several data structures, each answering a different question. A HashMap asks: Where is this object? A Heap asks: Which item has the highest priority? A Queue asks: Which task has been waiting the longest? A Stack asks: What happened most recently? Choosing the right data structure begins with identifying which of these questions your system needs to answer. Push and Pop Stacks are built around two simple operations. Push Adding a new item. Before Top ↓ B ↓ A Push C After Top ↓ C ↓ B ↓ A Pop Removing the most recent item. Before Top ↓ C ↓ B ↓ A Pop After Top ↓ B ↓ A Only the top item is removed. Everything below remains untouched. Real-World Examp

AWS now allows vibe coding tool Superblocks to be embedded into the private clouds of AWS customers. It's another step towards decoupling apps from models.

The Quest Begins (The "Why") I still remember my first technical interview like it was yesterday. The recruiter slid a whiteboard marker across the table, smiled, and said, “Here’s a classic: given an array of integers and a target sum, return the indices of the two numbers that add up to the target.” My heart started racing. I could feel the sweat forming on my palms as I stared at the empty board, my mind looping over the same terrible idea: check every pair . I started scribbling a nested loop, O(n²) time, and immediately realized that if the array had even a few thousand elements, I’d be stuck there forever. The interviewer’s eyes flicked to the clock, and I could almost hear the Imperial March playing in my head— the pressure was real . I needed a way to cut through the noise, fast, or I’d be that candidate who “just didn’t get it”. That moment sparked a question that’s haunted me ever since: how do top coders stay calm, spot the shortcut, and turn a seemingly impossible problem into a few lines of clean code under pressure? The Revelation (The Insight) After that interview (and a few too many late‑night debugging sessions), I dove into the mental toolkit that separates the “just‑get‑it‑done” crowd from the folks who seem to solve puzzles while sipping coffee. The breakthrough wasn’t a new library or a fancy language feature—it was a simple shift in perspective: Instead of asking “how can I compare every element to every other element?” ask “what do I need to know about each element to instantly know if its partner exists?” In the Two‑Sum problem, the partner of a number x is simply target – x . If I could remember, in O(1) time, whether I’ve already seen that partner, I could solve the whole thing in a single pass. That’s the “aha!” moment: store what you’ve seen so far in a hash map (or set) and look for the complement as you go . It feels like discovering the One Ring in a junkyard—once you see it, everything else falls into place. The beauty is that this pa

"A Heap doesn't stay useful because everything is sorted. It stays useful because every parent follows one simple rule." In the previous article, we learned that a Heap is built for continuous decision-making. Whether it's assigning the nearest driver, scheduling the next process, or selecting the most urgent support ticket, the system always needs one thing: The next best candidate But that raises an interesting question. How can a Heap always know the best candidate without sorting everything? The answer lies in one simple rule: The Heap Property. This single rule is what gives a Heap its power. The Biggest Misconception About Heaps Many beginners imagine a Heap like this. 100 95 90 82 76 64 51 Everything perfectly sorted. It feels logical. If the largest element should always come first, shouldn't every element be arranged in order? Surprisingly, no. A Heap solves a much smaller problem. It only guarantees that the best element is always easy to reach . Everything else only needs to follow one simple relationship. Imagine a Company Hierarchy Think about the structure of a company. CEO ↓ Engineering Director ↓ Engineering Manager ↓ Software Engineer The CEO doesn't directly manage every employee. Instead, each manager is responsible only for the people immediately below them. The entire organization works because every manager fulfills their local responsibility. A Heap works in a very similar way. Every node only needs to maintain the correct relationship with its immediate children. It doesn't need to know about every other node in the structure. The Heap Property Let's look at a Max Heap. 100 / \ 90 80 / \ / \ 75 60 70 50 Notice the pattern. Every parent has a value greater than or equal to its children. That's the Heap Property. Parent ≥ Children That's it. There is no rule saying that every node must be greater than every other node in the Heap. Only the parent-child relationship matters. What About a Min Heap? Some systems want the smallest value first. For

"A HashMap helps you find what you already know. A Heap helps you decide what should happen next." In the previous article, we discovered that not every software problem is about finding a specific object. Sometimes, the system already knows exactly what it's looking for. Find User ID = 1024 ↓ Return User Other times, the system doesn't know the answer in advance. Instead, it has to repeatedly answer questions like: Which task should run next? Which driver should be assigned? Which customer should be served first? Which alert is the most critical? These are fundamentally different problems. Instead of retrieving an object, the system is making a decision. This is where a Heap comes in. A Heap Is Built for Decisions, Not Searches Imagine you're managing a hospital emergency room. Patients keep arriving throughout the day. Patient A Minor Injury Patient B Heart Attack Patient C Broken Arm Patient D High Fever Should doctors treat patients in the order they arrived? Probably not. Instead, they ask one question. Who needs treatment first? Notice something important. The hospital isn't searching for a particular patient. It's choosing the highest-priority patient. A Heap is designed for exactly this kind of problem. A Different Way of Thinking When beginners hear "data structure," they often think about storing data. Experienced engineers think differently. They ask: "What operation does my system perform repeatedly?" If the answer is: Find User Find Order Find Product that's a lookup problem. But if the answer is: Choose Highest Priority Choose Nearest Driver Choose Earliest Deadline that's a decision problem. A Heap is optimized for continuous decision-making. What Exactly Is a Heap? A Heap is a data structure that keeps the most important element immediately available. Depending on the system, "most important" can mean different things. For example: Highest priority Lowest cost Earliest deadline Highest score Closest driver Most urgent ticket The Heap doesn't decide w

"Finding something quickly and finding the best thing quickly are two completely different engineering problems." So far in this series, we've explored one of the most common behaviours in software systems: Fast lookup. Whenever a system already knows what it's looking for—a User ID, Product ID, Order ID or Session ID—a HashMap becomes an excellent choice. But not every software problem works this way. Imagine you're building a ride-sharing application. A rider requests a cab. The system doesn't already know which driver to assign. Instead, it must answer a different question: "Out of all available drivers, who is the best choice?" Now consider a task scheduler. Hundreds of jobs are waiting to run. The scheduler doesn't ask: "Find Job #123." It asks: "Which job should run next?" Or imagine a gaming platform. Thousands of players are competing. Nobody asks: "Find Player ID 1057." Instead, users ask: "Who are the top 10 players?" These problems are fundamentally different from fast lookup. They're not about finding a specific object . They're about finding the best object according to some priority. This shift in thinking introduces another important design behaviour. Fast Lookup vs Best Selection Let's compare two different requirements. Requirement 1 Customer ID = 1052 ↓ Retrieve Customer The system already knows exactly what it needs. The challenge is retrieving it efficiently. Requirement 2 Available Drivers ↓ Find Nearest Driver ↓ Assign Ride The system doesn't know the answer yet. It must compare multiple candidates before making a decision. These two behaviours may look similar. In reality, they solve completely different engineering problems. Every Software System Doesn't Search the Same Way Consider these questions. Find Order #50231 versus Find the highest priority order. Or: Retrieve Product ID = P1042 versus Recommend the most popular product. Or: Find Employee ID = 2107 versus Find the employee with the highest sales this month. The first question always

At the start of June 2026, Anthropic published a statistic that was controversial. Most of what Anthropic says publicly generates a large number of cynical comments, so make of that what you will. The quote and statistic were that 80% of Anthropic's code is generated by Claude. Even up to 90% for new features. What was interesting about this was that a) it's actually totally insane and b) it made me think of something interesting that might happen. Since the start of the present wave of AI Psychosis at the end of 2022, it's something that I used to say as a joke: all software engineers will eventually become a QA to AI generated code. Trust but verify Let's explore (a) first: why it's totally insane. It's a bold claim but I'd like to poke a few holes in it. Claude Code is an amazing tool. I'm a daily user, favouring the "trust but verify" method of coding using Claude Code. All of my questions about software and infrastructure get answered satisfactorily, and when I feel like I don't believe it, I will verify the answer myself. If it writes code, I check. So, really, the state of the code that AI tools write doesn't really matter. As long as the end product is good quality to most of the users. And that's the first hole: it shouldn't be good quality for most users, it should be good quality for all users. If you're using an AI coding tool to generate code, then I would expect you to spend a bit of time on working out how to properly ensure quality instead of spending extra time writing code with bugs. Every software engineering team has got priorities to ship working code. But if you're using AI coding tools to 10x your output, then maybe ease off a bit and 7x your output and 3x the quality. When humans write code.... Earlier in 2026 we saw a leak of Claude Code's code. The code is far from clean. The general thoughts online are that it is just "messy production code". Legacy code gets messy after a while caused by a lack of a good QA process and lax standards. It s

"The real magic of a HashMap isn't that it stores data. It's that it knows where to start looking." In the previous article, we learned that a HashMap organises information around unique keys. Instead of searching every stored object one by one, it uses the key to retrieve information quickly. That naturally raises another question. "If millions of objects are stored inside a HashMap, how does it know where to begin?" Surely it isn't remembering the location of every object individually. The answer lies in one of the most important ideas in computer science: Hashing. Don't worry if the word sounds intimidating. Despite its name, the idea behind hashing is surprisingly simple. Imagine a Huge Apartment Building Suppose you're visiting a friend who lives in a building with 5,000 apartments. If nobody told you the apartment number, what would you do? Probably something like this. Apartment 1 ↓ Apartment 2 ↓ Apartment 3 ↓ ... ↓ Friend's Apartment That would take a long time. Now imagine your friend simply tells you: Apartment 1842 Suddenly, you don't search the building. You walk directly to Apartment 1842. The apartment number isn't your friend. It simply tells you where to begin. Hashing works in exactly the same way. Keys Need Locations Suppose our application stores customers. Customer ID → Customer 1001 → Alice 1002 → Bob 1003 → Charlie 1004 → David The system needs a way to answer one question. "Where should Customer 1002 be stored?" Searching every location first would defeat the purpose of using a HashMap. Instead, the system calculates where that key should go. Notice something important. It doesn't compare Customer 1002 against every other customer. It calculates a location directly. Think of a School Locker System Imagine a school with thousands of students. Every student receives a locker. Student ID ↓ Locker Number ↓ Locker Students don't spend every morning searching hundreds of lockers. Their Student ID determines where they should go. The locker number is

Many students graduate knowing how to code. Very few graduate knowing how to engineer software. That's the uncomfortable truth most Computer Science students discover only after facing their first real interview—or worse, after joining their first job. Every year, thousands of students complete coding challenges, solve hundreds of LeetCode problems, build flashy portfolio websites, and proudly call themselves software engineers. Yet many of them struggle when asked questions like: How would you design this system? Why did you choose this database? How would this application scale to one million users? What happens if the server crashes? How would you secure user data? Suddenly, writing code isn't enough. Because software engineering has never been just about writing code. The Biggest Misconception Many universities unknowingly teach students that success in software engineering equals learning programming languages. Students spend years learning: C C++ Java Python JavaScript Then they learn frameworks: React Node.js Express Spring Boot Django Eventually they believe: "I know React and Node.js. Therefore, I'm a software engineer." Unfortunately... That's only one piece of the puzzle. Programming is a tool. Software engineering is a discipline. Those two are related—but they are not the same thing. Coding Is Like Learning to Write Imagine someone learns English. They memorize grammar. They improve vocabulary. They know punctuation. Does that automatically make them a great author? No. Because writing books requires far more than knowing the language. Software engineering works exactly the same way. Programming languages are simply the language engineers use to communicate with computers. Engineering begins after the syntax ends. Software Is Built Long Before Anyone Writes Code Professional engineers don't immediately open VS Code and start typing. Instead they ask questions. Lots of questions. What problem are we solving? Who will use this product? What happens when t

"The best software engineers don't begin by choosing data structures. They begin by understanding what the system needs to do." In the previous article, we learned that data structures never stopped being important after DSA. Their role simply changed. During coding interviews, we often ask ourselves: "Which data structure will solve this problem efficiently?" In Low-Level Design, experienced engineers ask a different question: "What behaviour should this system optimise?" At first glance, these questions sound similar. In reality, they lead to completely different ways of thinking. This article is about understanding why behaviour—not implementation—is where every good design begins. Why Beginners Often Think About Data Structures Too Early Imagine someone asks you to design an online food delivery platform. Many beginners immediately start thinking: Should I use a HashMap? Will I need a Queue? Should I store everything in a Tree? Would a Graph be useful? These aren't bad questions. They're simply being asked too early. Before choosing any data structure, we need to understand what the system is actually expected to do. Software engineering isn't about selecting tools first. It's about understanding problems first. Every Software System Is Really a Collection of Behaviours Let's consider a food delivery application. From a user's perspective, it looks like this. Customer Places Order │ Restaurant Accepts │ Assign Delivery Partner │ Track Delivery │ Order Delivered It looks like one workflow. But an engineer sees something very different. Each step represents a different behaviour. Let's break them apart. Behaviour 1 — Retrieve Existing Information A customer opens an order they placed yesterday. Customer ↓ Order ID ↓ Retrieve Order The system already knows exactly which order it needs. The challenge is retrieving it quickly. Behaviour 2 — Choose the Best Candidate A restaurant has multiple delivery partners nearby. Available Drivers ↓ Choose Best Driver ↓ Assign Ri

Docker published the second entry in its Coding Agent Horror Stories series on July 20, and the operational read is short: on a stock developer laptop, an AI coding agent runs with the engineer's filesystem permissions and the engineer's credentials, with nothing sitting between it and the host. The post frames a scenario in which the agent deletes production and works backward through why that outcome is not exceptional. Docker names the piece as part two of a series that will cover six categories of coding-agent failure. What the post actually claims Two claims carry the argument. First, the agent inherits the developer's shell posture: whatever the developer can touch on disk, the agent can touch; whatever token is exported into the environment, the agent can spend. Second, that default is not a sandbox. Docker's phrasing is that nothing sits between the agent and the host unless the operator puts it there. The piece does not attribute the scenario to a named incident; it is a category, not a case study. Anyone extrapolating specific companies, victims or numbers is filling in blanks the source did not. The runner problem, one hop to the left For CI operators this shape is familiar. A self-hosted Actions runner or a Jenkins agent that mounts the workspace, holds a checkout token and can call the host shell is a service you already isolate on purpose. You isolate it because the workflow you invited in is not always the workflow that runs. You isolate it because the token in the environment can do more than the job description. You isolate it because rollback of a bounded container is cheaper than reasoning about everything a process touched on a shared box. A coding agent living on the developer laptop occupies the same trust position, one machine earlier in the pipeline. It reads and writes the working tree. It holds session credentials to cloud APIs, the cluster and the registry. It executes instructions the developer did not always write, sometimes routed from

This is my first dev blog I'm making a terraria mod I'm not sure if i want to start right now but i am sure to start soon i already have some ideas so here are the ideas The Operator The operator is someone i have in idea for a while kind of the lore aspect is you work it, killing bosses and giving proof to the operator for certain rewards, at first it is an Npc but after moon lord you fight him. I might bring him back as the same dude but is occupied by the Fixer as a vessel which he is chained or has custom hand cuffs for the fixer to occupies the fixer without The Operator body, without the body dying. The Dulled One This is not my idea but a alternative version of it (Game: Craft-Wars Redux Roblox, Boss: Dulled Spectrum) for credits, so I really liked this boss idea but I'm really not sure if they did what I'm doing, but his power is to erase or turn into dust or "dull". To erase certain parts of the world either matter, or space i don't want to say time because i feel like that would be boring, it can either be like passive very weak erase which it can re-gain power. Second version is the Compacted version which does way more damage, maybe one shot if i do one shot then im adding middle attacks, but deplete the dust bar by a ton so if the boss is not careful or the player stops it then you can easily beat it. it might have a regen system where if the bar is full then it heals. Also hammer both the versions the game and mine has hammer. The lore is not very fleshed out right now but i will figure it out

A few months ago, my AI coding workflow looked something like...

It doesn't even have to be a big dramatic failures, more the small moments where something clicked and you went from trusting the output by default to double checking everything. For me it was watching an agent confidently rename a function across twelve files, then leave the original function untouched in a thirteenth file it apparently didn't search, with zero indication anything had been missed. It wasn't even a hard case, the file just wasn't in the directory it happened to grep first. What was your moment? And did it actually change your workflow afterward , or did the trust creep back in after a week like it always seems to for me?

The Quest Begins (The "Why") Hey friend, picture this: you’re happily writing a Node.js service, passing objects around like they’re candy at a parade. Everything works until one day you mutate a shared object in a helper function and suddenly your UI shows stale data, or worse, you get a mysterious Cannot read property 'map' of undefined that only appears in production. You spend hours tracing the flow, adding console.log s everywhere, and you start to wonder if there’s a hidden contract you missed. I’ve been there. I spent an entire afternoon debugging a race condition that only showed up when two async requests touched the same user profile. The fix felt like a band‑aid, and I kept thinking, “There has to be a better way to reason about who owns what.” That curiosity led me to Rust, and more specifically, to its ownership system—a set of rules that, at first glance, feels like a strict teacher with a red pen, but ends up being the most reliable compass I’ve ever had for writing safe, concurrent code. The Revelation (The Insight) Rust’s ownership model isn’t just another syntax quirk; it’s a philosophy that answers three simple questions for every piece of data: Who owns it? How long can it live? Who can read or change it while it’s alive? If you can answer those, the compiler guarantees you won’t have dangling pointers, use‑after‑free, or data races— without a garbage collector pausing your thread. For a JavaScript developer, that sounds like magic, but the rules are surprisingly concrete once you see them in action. Surprising Feature #1: Move Semantics (The “Give Away” Rule) In JavaScript, when you do let b = a; you’re copying a reference. Both a and b point to the same object, and mutating one affects the other unless you clone. Rust treats assignment differently for types that own resources (like String , Vec<T> , or custom structs). Assigning b = a moves the ownership; after that, a is considered uninitialized and you can’t use it again. let s1 = String .fro

When good cameras got cheap, everyone predicted the death of professional photography. The prediction landed wrong. The low end died outright: stock libraries, cheap portraits, mass-event coverage went to anyone with a phone and a free editing app. The high end did better than ever — editorial work, photojournalism with access nobody else had, an aesthetic you could not reproduce by buying the same gear. The damage landed in the middle. Small weddings, corporate headshots, real estate listings, the steady unglamorous bulk of the market: not extinction, compression. Prices fell, volume moved to cheaper substitutes, and the survivors climbed up or specialized out. That compression is the cleanest map I know for what AI-assisted coding is doing to software work. And this half I know from inside: two decades leading dev teams, and now building AI tooling for them. The comfortable half of the argument The reassuring version of this is everywhere right now: you were never paid to type, you were paid to think, so AI just frees you to do the valuable part. It's not wrong. It's just the half that's easy to hear. The other half is about the market, not about you. Judgment, architecture, knowing what breaks in maintenance, deciding what not to build — a model that writes plausible code on command doesn't commoditize any of that. I have watched weeks of confusion land on people who could not read what a capable model generated; the gap was never the tool, and better AI autocomplete does not close that gap. But "judgment beats typing" answers only a question about skill and dodges the question about market structure. AI doesn't replace developers as a class; it commoditizes a segment. The segment it hits first is the same one the camera hit: the middle. The junior-to-mid tier that lived on CRUD apps, simple integrations, brochure sites, the standard internal tool with a form and a table behind it. That work was always implementation against a known spec, and implementation again