Balaji Srinivasan

Surviving the Flood: A Guide to Software Craftsmanship in 2026

9 minutes (2313 words)

We are witnessing the industrial revolution of software development. But to understand where we are going, we must first understand what we have lost.

For the last few decades of software engineering, code was a scarce resource. It was expensive to produce. It required deep expertise, intense concentration, and hours of manual labor to produce even a few hundred lines of working logic. Because code was expensive, we treated it with reverence. We optimized for conciseness. We built entire philosophies—DRY (Don't Repeat Yourself), YAGNI , SOLID, Clean Code predicated on the idea that writing code was the bottleneck, so we should write as little of it as possible to solve the problem.

Today, that bottleneck has shattered.

Generative AI and agentic workflows have inverted the economics of software. We have moved from an economy of scarcity to an economy of abundance. A junior engineer with Copilot can generate more lines of code in an afternoon than a senior architect could write in a month few years back.

But history teaches us that abundance is not always a blessing. When the printing press was invented, it didn't immediately lead to a golden age of literature; it led to a century of noise, propaganda, and conflicting information. Society had to invent new institutions—editors, publishers, peer review—to filter the signal from the noise.

We are at that same inflection point for code. When code is cheap, its value drops, but its cost of ownership remains the same—or even rises. The challenge of the AI era is not how to write software; it is how to survive the software we have written.

This is not the end of Software Craftsmanship. It is the beginning of its most critical era.

🔗1. The High Interest Rate of "Vibe Coding" (Cognitive Leakage)

There is a seductive nihilism spreading through the industry. You see it in tweets and Discords: "Why learn design patterns? The AI writes the code. Just vibe with it." This is the era of "Vibe Coding"—if it runs, ship it. If it breaks, let the AI fix it.

But this speed comes with a hidden tax, a phenomenon I call Cognitive Leakage.

In traditional development, the act of writing code forced a Cognitive Shift Left. You had to understand the problem before you typed the solution. You stared at the whiteboard. You modelled the domain. You argued about naming. This high upfront cost was painful, but it meant that by the time the code was written, the understanding was baked into your brain. You had "digested" the complexity.

With AI tools, we perform a Cognitive Shift Right. We can generate a complex feature in seconds without truly understanding the underlying abstractions. We skip the digestion phase. We get the feature (the asset) without the understanding (the liability coverage).

🔗A Tale of Two Engineers

Let's look at two engineers, Alice and Bob, tasked with adding a "context-aware discount engine" to an e-commerce platform.

Bob (The Vibe Coder) prompts his agent: "Add a discount system where premium users get 10% off, but only on weekends." The agent churns out 200 lines of Python. It works. Bob ships it in 15 minutes. He feels like a god. Three months later, the marketing team asks for a change: "Make the discount stackable with holiday sales, but capped at 20% total." Bob opens the file. He doesn't recognize the code. The agent used a weird nested confusing logic for the date checks. The variable names are generic (calc_val_1, res). Bob asks the agent to fix it. The agent patches it, but breaks the weekend check. Bob effectively has to reverse-engineer his own feature, paying a Cognitive Repurchase Cost that is 10x higher than the time he saved.

Alice (The Craftsman) spends the first hour not coding, but modelling. She prompts the agent: "I want to define a DiscountPolicy interface. It should be composable. Let's create a Strategy pattern where DateRule and UserTierRule are separate strategies." The agent generates the code. It takes longer—maybe 2 hours total. Three months later, when the change request comes, Alice knows exactly where to look. She asks the agent: "Create a new CappedStackablePolicy that implements the DiscountPolicy interface." The agent generates code that fits perfectly into the existing slot.

Bob optimized for Writing Speed. Alice optimized for Maneuverability. In the AI era, writing speed is irrelevant. Maneuverability is everything.

🔗2. The Apprentice Paradox: How Do We Build Seniors?

If writing code is the gym where we build our mental muscle, what happens when we stop going to the gym?

This is the Apprentice Paradox. Senior engineers are good at "Editing" AI code because they spent 10 years "Writing" bad code. They recognize a code smell because they’ve created that smell themselves in 2015.

But if a Junior Engineer starts their career by reviewing AI output, they never build that muscle. They are learning to critique a painting without ever having held a brush. This leads to a "Hollow Seniority"—engineers with 5 years of experience who can prompt claude-3.5-sonnet to build a React app, but cannot debug a race condition or understand why a database lock is happening.

The Solution? The Flight Simulator Approach. Engineering Managers must change how they train.

🔗3. Why Clean Code Matters More to Robots

A common misconception is that "Clean Code" is for humans. "Why should I care about variable naming or folder structure if I'm just going to paste it into Claude?"

This is dangerously wrong. In an AI-driven world, your codebase is not just a set of instructions; it is the Context Window.

Large Language Models (LLMs) are, at their core, correlation engines. They predict the next token based on the patterns they see in the context you provide.

Refactoring is Prompt Engineering. When you rename a class to be more specific, you are fine-tuning the model on your specific domain. When you break a 1000-line function into 10 small ones, you are creating "retrieval chunks" that a RAG (Retrieval-Augmented Generation) system can find and use more effectively.

🔗Code as a Knowledge Graph

Think of your repository structure as the Ontology of your AI agent. If you dump everything into utils/ or common/, you are lobotomizing your agent. You are telling it that these concepts have no relation.

But if you structure your code by domain:

/src
  /checkout
    /pricing
    /domain
    /services
  /catalog
    /search

You are teaching the agent the relationships between concepts. When it needs to modify "pricing," it knows implicitly that it is part of "checkout" and distinct from "catalog." Clean code is the Schema of the agent's mind.

🔗4. The Ferrari in the Jungle (Context Engineering)

Imagine you buy a Ferrari. It’s the latest model—W16 engine, carbon fiber chassis, AI-assisted steering. This is your modern AI coding tool. Now, imagine you try to drive it through a dense, overgrown Amazonian jungle (Your Legacy Enterprise).

It doesn’t matter how much horsepower the engine has; you aren't going anywhere. This is the reality of Enterprise AI. The Ferrari is the AI. The Jungle is your Legacy Distributed System.

AI engines thrive on the open highway. They love Monoliths. In a monolith, the entire context of the application is visible. The definition of the database schema, the API endpoint, and the frontend React component are all in one file tree. The AI can "see" the cause and effect.

But in the "Corporate Jungle"—a distributed mesh of 500 microservices, Kafka topics, and undocumented S3 buckets—the AI is blind.

The Fix? We need to stop trying to force the Ferrari through the trees and start paving the road.

  1. Embrace Monorepos (With Discipline): Bring the context together so the AI can see it. But be warned: A monorepo without strict tooling and clear ownership boundaries is just a majestic monolith that burns down faster. You need the visibility of a monorepo with the integrity of modular governance.
  2. Explicit Contracts: If you must be distributed, you cannot rely on implicit behavior. Every API, every event, every data shape must have a machine-readable schema (OpenAPI, AsyncAPI, Protobuf).

🔗5. From TDD to EDD (Eval-Driven Development)

In the software craftsmanship of 2015, TDD (Test-Driven Development) was the gold standard. You wrote a test, saw it fail, wrote the code, saw it pass. The assertion was binary: assert result == 5.

But AI doesn't just output integers. It outputs reasoning, text, and complex decisions. A unit test cannot capture "Is this customer support tone empathetic?" or "Is this SQL query efficient?"

Enter EDD: Eval-Driven Development. In the Agentic Era, your CI pipeline doesn't just run pytest. It runs LLM-as-a-Judge.

The EDD Workflow:

  1. Define the Eval: "The generated summary must mention the user's flight number and be under 50 words."
  2. The Agent Runs: The agent generates the summary.
  3. The Judge Checks: A stronger model (e.g., GPT-4o) evaluates the output against the criteria and assigns a score (Pass/Fail or 1-5).

We are moving from "Deterministic Correctness" to "Probabilistic Alignment." The Architect's job is to define the Evals. If you don't have Evals, you don't have specific requirements—you just have vibes.

🔗6. Spec-Driven Development (SDD): The New Governance Layer

So how do we govern the creation of code? The answer is Spec-Driven Development (SDD). SDD flips the workflow. Instead of asking the AI to "write the code," you ask the AI to "write the spec."

The SDD Workflow:

  1. Natural Language Intent: You tell the agent, "I need a rate-limiting service."
  2. The Spec Generation: The agent generates a Markdown Design Doc or OpenAPI Spec.
  3. Human Review: You review the Spec. "Wait, use a sliding window instead of token bucket."
  4. Code Generation: Once the Spec is frozen, the Agent generates the implementation.

Why this changes everything: By forcing a Spec step, you compress infinite complexity into a finite contract. You debug the Design, not the Implementation. This is High-Frequency Governance.

🔗7. The New Code Review: Intent vs. Diff (Reference: Entire.io & Ashtom)

We are approaching a breaking point in Code Review. When a human writes 50 lines of code, a reviewer reads 50 lines. When an AI generates 500 lines of boilerplate, the reviewer... glazes over.

We scroll. We say "Looks Good To Me" (LGTM). We trust the machine. This is the Glaze-Over Effect, and it is the primary vector for security vulnerabilities in 2026.

As Thomas Dohmke (@ashtom) and platforms like Entire.io have pointed out:

The future of code review is not reviewing the Diff (the text changes), but reviewing the Intent (the topology of the change).

We need tools that visualize:

The "Map View" of Code: We need to stop reading code line-by-line and start reading systems. The Architect must audit the System Map, not just the syntax. If the map looks wrong (e.g., "Why is the Frontend talking directly to the Database?"), reject the PR without even reading the code.

🔗8. The Economics of Durability (Volatility as Downtime)

Finally, how do we sell this to the business? Why should a CTO care about "Craftsmanship" when "Vibe Coding" is so fast?

The argument is Volatility. AI-generated code that is not shepherded by craftsmanship is highly volatile. It works today, but breaks tomorrow when the context changes. It is brittle.

In finance, Volatility is Risk. In software, Volatility is Downtime. The "Speed" you gain from Vibe Coding is a loan. The interest rate is the Mean Time To Recovery (MTTR) when it breaks.

For a startup finding Product-Market Fit, Vibe Coding might be acceptable. For an Enterprise managing millions of dollars, Volatility is unacceptable. Craftsmanship is the Hedging Strategy against the chaos of infinite code.

🔗The Architect's New Mandate

For the experienced engineers, architects, and managers reading this: your value proposition has shifted. You are no longer paid for your ability to remember standard library syntax. You are paid for your Taste and your Stewardship.

1. From Author to Editor Your primary physical act is no longer typing; it is reviewing. You are the Editor-in-Chief.

2. From Implementation to Constraint Don't tell the AI how to write the loop. Tell it the invariant that must hold true. Use SDD and Evals to create the "Pit of Success."

3. From Speed to Durability The code is cheap. The design is expensive. Your job is to ensure that the cheap code respects the expensive design.

We are not entering an era where software builds itself. We are entering an era where the cost of building drops to near zero, but the cost of misunderstanding skyrockets. Software Craftsmanship is the discipline of understanding.

Be the Architect, not the Typist.

Tags: #engineering #software-craftsmanship #ai