Orthogonal Thinking

Tag: Claude Code

  • The Plan Is the Product: Why AI Is Making Architecture the Only Skill That Matters

    The Plan Is the Product: Why AI Is Making Architecture the Only Skill That Matters

    Last month, I built a complete microservice in a single afternoon. Not a prototype. Not a proof-of-concept. A production-grade service with authentication, rate limiting, PostgreSQL integration, full test coverage, OpenAPI docs, and a CI/CD pipeline. Containerized, deployed, monitoring configured. The kind of thing that would have taken my team two to three sprints eighteen months ago.

    I didn’t write most of the code. I wrote the plan.

    And I think that moment—sitting there watching Claude Code churn through my architecture doc, implementing exactly what I’d specified while I reviewed each module—was the exact moment I realized the industry has already changed. We just haven’t processed it yet.

    The Numbers Don’t Lie (But They Do Confuse)

    Let me lay out the landscape, because it’s genuinely contradictory right now:

    Anthropic—the company behind Claude, valued at $380 billion as of this week—published a study showing that AI-assisted coding “doesn’t show significant efficiency gains” and may impair developers’ understanding of their own codebases. Meanwhile, Y Combinator reported that 25% of startups in its Winter 2025 batch had codebases that were 95% AI-generated. Indian IT stocks lost $50 billion in market cap in February 2026 alone on fears that AI is replacing outsourced development. GPT-5.3 Codex just launched. Gemini 3 Deep Think can reason through multi-file architectural changes.

    How do you reconcile “no efficiency gains” with “$50 billion in market value evaporating because AI is too efficient”?

    The answer is embarrassingly simple: the tool isn’t the bottleneck. The plan is.

    Key insight: AI doesn’t make bad plans faster. It makes good plans executable at near-zero marginal cost. The developers who aren’t seeing gains are the ones prompting without planning. The ones seeing 10x gains are the ones who spend 80% of their time on architecture, specs, and constraints—and 20% on execution.

    The Death of Implementation Cost

    I want to be precise about what’s happening, because the hype cycle makes everyone either a zealot or a denier. Here’s what I’m actually observing in my consulting work:

    The cost of translating a clear specification into working code is approaching zero.

    Not the cost of software. Not the cost of good software. The cost of the implementation step—the part where you take a well-defined plan and turn it into lines of code that compile and pass tests.

    This is a critical distinction. Building software involves roughly five layers:

    1. Understanding the problem — What are we actually solving? For whom? What are the constraints?
    2. Designing the solution — Architecture, data models, API contracts, security boundaries, failure modes
    3. Implementing the code — Translating the design into working software
    4. Validating correctness — Testing, security review, performance profiling
    5. Operating in production — Deployment, monitoring, incident response, iteration

    AI has made layer 3 nearly free. It has made modest improvements to layers 4 and 5. It has done almost nothing for layers 1 and 2.

    And that’s the punchline: layers 1 and 2 are where the actual value lives. They always were. We just used to pretend that “senior engineer” meant “person who writes code faster.” It never did. It meant “person who knows what to build and how to structure it.”

    Welcome to the Plan-Driven World

    Here’s what my workflow looks like now, and I’m seeing similar patterns emerge across every competent team I work with:

    Phase 1: The Specification (60-70% of total time)

    Before I write a single prompt, I write a plan. Not a Jira ticket with three bullet points. A real specification:

    ## Service: Rate Limiter
### Purpose
Protect downstream APIs from abuse while allowing legitimate burst traffic.

### Architecture Decisions
- Token bucket algorithm (not sliding window — we need burst tolerance)
- Redis-backed (shared state across pods)
- Per-user AND per-endpoint limits
- Graceful degradation: if Redis is down, allow traffic (fail-open)
  with local in-memory fallback

### Security Requirements
- No rate limit info in error responses (prevents enumeration)
- Admin override via signed JWT (not API key)
- Audit log for all limit changes

### API Contract
POST /api/v1/check-limit
  Request: { "user_id": string, "endpoint": string, "weight": int }
  Response: { "allowed": bool, "remaining": int, "reset_at": ISO8601 }
  
### Failure Modes
1. Redis connection lost → fall back to local cache, alert ops
2. Clock skew between pods → use Redis TIME, not local clock
3. Memory pressure → evict oldest buckets first (LRU)

### Non-Requirements
- We do NOT need distributed rate limiting across regions (yet)
- We do NOT need real-time dashboard (batch analytics is fine)
- We do NOT need webhook notifications on limit breach

    That spec took me 45 minutes. Notice what it includes: architecture decisions with reasoning, security requirements, failure modes, and explicitly stated non-requirements. The non-requirements are just as important—they prevent the AI from over-engineering things you don’t need.

    Phase 2: AI Implementation (10-15% of total time)

    I feed the spec to Claude Code. Within minutes, I have a working implementation. Not perfect—but structurally correct. The architecture matches. The API contract matches. The failure modes are handled.

    Phase 3: Review, Harden, Ship (20-25% of total time)

    This is where my 12 years of experience actually matter. I review every security boundary. I stress-test the failure modes. I look for the things AI consistently gets wrong—auth edge cases, CORS configurations, input validation. I add the monitoring that the AI forgot about because monitoring isn’t in most training data.

    Security note: The review phase is non-negotiable. I wrote extensively about why vibe coding is a security nightmare. The plan-driven approach works precisely because the plan includes security requirements that the AI must follow. Without the plan, AI defaults to insecure patterns. With the plan, you can verify compliance.

    What This Means for Companies

    The implications are enormous, and most organizations are still thinking about this wrong.

    Internal Development Cost Is Collapsing

    Consider the economics. A mid-level engineer costs a company $150-250K/year fully loaded. A team of five ships maybe 4-6 features per quarter. That’s roughly $40-60K per feature, if you’re generous with the accounting.

    Now consider: a senior architect with AI tools can ship the same feature set in a fraction of the time. Not because the AI is magic—but because the implementation step, which used to consume 60-70% of engineering time, is now nearly instant. The architect’s time goes into planning, reviewing, and operating.

    I’m watching this play out in real time. Companies that used to need 15-person engineering teams are running the same workload with 5. Not because 10 people got fired (though some did), but because a smaller team of more senior people can now execute faster with AI augmentation.

    The Reddit post from an EM with 10+ years of experience captures this perfectly: his team adopted Claude Code, built shared context and skills repositories, and now generates PRs “at the level of an upper mid-level engineer in one shot.” They built a new set of services “in half the time they normally experience.”

    The Outsourcing Apocalypse Is Real

    Indian IT stocks losing $50 billion in a single month isn’t irrational fear—it’s rational repricing. If a US-based architect with Claude Code can produce the same output as a 10-person offshore team, the math simply doesn’t work for body shops anymore.

    This isn’t hypothetical. I’ve seen three clients in the last six months cancel offshore development contracts. Not reduce—cancel. The internal team, augmented with AI, was delivering faster with higher quality. The coordination overhead of managing remote teams now exceeds the cost savings.

    The uncomfortable truth: The “10x engineer” used to be a myth that Silicon Valley told itself. With AI, it’s becoming real—but not in the way anyone expected. The 10x engineer isn’t someone who types faster. They’re someone who writes better plans, understands systems more deeply, and reviews more carefully. The AI handles the typing.

    The Skills That Matter Have Shifted

    Here’s what I’m telling every junior developer who asks me for career advice in 2026:

    Stop optimizing for code output. Start optimizing for architectural thinking.

    The skills that are now 10x more valuable:

    • System design — How do components interact? What are the boundaries? Where are the failure modes?
    • Threat modeling — Security isn’t optional. AI won’t do it for you.
    • Requirements engineering — The ability to turn a vague business need into a precise specification is now the most leveraged skill in engineering
    • Code review at depth — Not “looks good to me.” Deep review that catches semantic bugs, security flaws, and architectural drift
    • Operational awareness — Understanding how software behaves in production, not just in a test suite

    The skills that are rapidly commoditizing:

    • Syntax fluency in any single language
    • Memorizing API surfaces
    • Writing boilerplate (CRUD, forms, API handlers)
    • Basic debugging (AI is actually good at this now)
    • Writing unit tests for existing code

    The Paradox: Why Anthropic’s Study Is Both Right and Wrong

    Anthropic’s study found no significant speedup from AI-assisted coding. The experienced developers on Reddit were furious—it seemed to contradict their lived experience. But here’s the thing: both sides are right.

    The study measured what happens when you give developers AI tools and tell them to work normally. Of course there’s no speedup—you’re still doing the old workflow, just with a fancier autocomplete. It’s like giving someone a Formula 1 car and measuring their commute time. They’ll still hit the same traffic lights.

    The teams seeing massive gains? They changed the workflow. They didn’t add AI to the existing process. They rebuilt the process around AI. Plans first. Specs first. Context engineering. Shared skills repositories. Narrowly-focused tickets that AI can execute cleanly.

    That EM on Reddit nailed it: “We’ve set about building a shared repo of standalone skills, as well as committing skills and always-on context for our production repositories.” That’s not vibe coding. That’s infrastructure for plan-driven development.

    What the Next 18 Months Look Like

    Here’s my prediction, and I’ll put a date on it so you can come back and laugh at me if I’m wrong:

    By late 2027, the majority of production code at companies with fewer than 500 employees will be AI-generated from human-written specifications.

    Not because AI will get dramatically better (though it will). But because the organizational practices will mature. Companies will develop internal specification standards, review processes, and tooling that makes plan-driven development the default workflow.

    The winners won’t be the companies with the most engineers. They’ll be the companies with the best architects—people who can translate business problems into precise technical specifications that AI can execute flawlessly.

    And ironically, this makes deep technical expertise more valuable, not less. You can’t write a good spec for a distributed system if you don’t understand consensus protocols. You can’t specify a secure auth flow if you don’t understand OAuth and PKCE. You can’t design a resilient architecture if you haven’t been paged at 3 AM when one went down.

    The bottom line: The cost of building software is crashing toward zero. The cost of knowing what to build is going to infinity. We’re not in a “coding is dead” moment. We’re in a “planning is king” moment. The engineers who thrive will be the ones who learn to think at the spec level, not the syntax level.

    Gear for the Plan-Driven Engineer

    If you’re making the shift from implementation-focused to architecture-focused work, here’s what I actually use daily:

    • 📘 Designing Data-Intensive Applications — Kleppmann’s masterpiece. If you can only read one book on distributed systems architecture, make it this one. Essential for writing specs that actually cover failure modes. ($35-45)
    • 📘 The Pragmatic Programmer — Timeless wisdom on thinking at the system level, not the code level. More relevant now than ever. ($35-50)
    • 📘 Threat Modeling: Designing for Security — Every spec you write should include security requirements. This book teaches you how to think about threats systematically. ($35-45)
    • ⌨️ Keychron Q1 Max Mechanical Keyboard — You’ll be writing a lot more prose (specs, docs, architecture decisions). Might as well enjoy the typing. ($199-220)

    Key Takeaways

    • Implementation cost is approaching zero — the cost of converting a clear spec into working code is collapsing, but the cost of knowing what to build isn’t
    • Planning is the new coding — teams seeing 10x gains spend 60-70% of time on specs and architecture, not prompting
    • The outsourcing model is breaking — one senior architect + AI can outproduce a 10-person offshore team
    • Deep expertise is MORE valuable — you can’t write a good spec if you don’t understand the domain deeply
    • The workflow must change — adding AI to your existing process gets you nothing; rebuilding the process around AI gets you everything

    The engineers who survive this transition won’t be the ones who learn to prompt better. They’ll be the ones who learn to think better. To plan better. To specify what they want with the precision of someone who’s been burned by production failures enough times to know what “done” actually means.

    The vibes are over. The plans are all that’s left.

    Are you seeing the same shift in your organization? I’m curious how different companies are adapting—or failing to adapt. Drop a comment or reach out.

    Some links in this article are affiliate links. If you buy something through these links, I may earn a small commission at no extra cost to you. I only recommend products I actually use or have thoroughly researched.

  • Claude Code Changed How I Ship Code — Here’s My Honest Take After 3 Months

    Claude Code Changed How I Ship Code — Here’s My Honest Take After 3 Months

    Three months ago, I was skeptical. Another AI coding tool? I’d already tried GitHub Copilot, Cursor, and a handful of VS Code extensions that promised to “10x my productivity.” Most of them were glorified autocomplete — helpful for boilerplate, useless for anything that required actual understanding of a codebase. Then I installed Claude Code, and within the first hour, it did something none of the others had done: it read my entire project, understood the architecture, and fixed a bug I’d been ignoring for two weeks.

    This isn’t a puff piece. I’ve been using Claude Code daily on production projects — Kubernetes deployments, FastAPI services, React dashboards — and I have strong opinions about where it shines and where it still falls short. Let me walk you through what I’ve learned.

    What Makes Claude Code Different

    Most AI coding assistants work at the file level. You highlight some code, ask a question, get an answer. Claude Code operates at the project level. It’s an agentic coding tool that reads your codebase, edits files, runs commands, and integrates with your development tools. It works in your terminal, IDE (VS Code and JetBrains), browser, and even as a desktop app.

    The key word here is agentic. Unlike a chatbot that answers questions and waits, Claude Code can autonomously explore your codebase, plan changes across multiple files, run tests to verify its work, and iterate until things actually pass. You describe what you want; Claude figures out how to build it.

    Here’s how I typically start a session:

    # Navigate to your project
cd ~/projects/my-api

# Launch Claude Code
claude

# Ask it something real
> explain how authentication works in this codebase

    That first command is where the magic happens. Claude doesn’t just grep for “auth” — it traces the entire flow from middleware to token validation to database queries. It builds a mental model of your code that persists throughout the session.

    The Workflows That Actually Save Me Time

    1. Onboarding to Unfamiliar Code

    I recently inherited a Node.js monorepo with zero documentation. Instead of spending a week reading source files, I ran:

    > give me an overview of this codebase
> how do these services communicate?
> trace a user login from the API gateway to the database

    In 20 minutes, I had a better understanding of the architecture than I would have gotten from a week of code reading. Claude identified the service mesh pattern, pointed out the shared protobuf definitions, and even flagged a deprecated authentication path that was still being hit in production.

    💡 Pro Tip: When onboarding, start broad and narrow down. Ask about architecture first, then drill into specific components. Claude keeps context across the session, so each question builds on the last.

    2. Bug Fixing With Context

    Here’s where Claude Code absolutely destroys traditional AI tools. Instead of pasting error messages and hoping for the best, you can do this:

    > I'm seeing a 500 error when users try to reset their password.
> The error only happens for accounts created before January 2025.
> Find the root cause and fix it.

    Claude will read the relevant files, check the database migration history, identify that older accounts use a different hashing scheme, and propose a fix — complete with a migration script and updated tests. All in one shot.

    3. The Plan-Then-Execute Pattern

    For complex changes, I’ve adopted a two-phase workflow that dramatically reduces wasted effort:

    # Phase 1: Plan Mode (read-only, no changes)
claude --permission-mode plan

> I need to add OAuth2 support. What files need to change?
> What about backward compatibility?
> How should we handle the database migration?

# Phase 2: Execute (switch to normal mode)
# Press Shift+Tab to exit Plan Mode

> Implement the OAuth flow from your plan.
> Write tests for the callback handler.
> Run the test suite and fix any failures.

    Plan Mode is like having a senior architect review your approach before you write a single line of code. Claude reads the codebase with read-only access, asks clarifying questions, and produces a detailed implementation plan. Only when you’re satisfied do you let it start coding.

    🔐 Security Note: Plan Mode is especially valuable for security-sensitive changes. I always use it before modifying authentication, authorization, or encryption code. Having Claude analyze the security implications before making changes has caught issues I would have missed.

    CLAUDE.md — Your Project’s Secret Weapon

    This is the feature that separates power users from casual users. CLAUDE.md is a special file that Claude reads at the start of every conversation. Think of it as persistent context that tells Claude how your project works, what conventions to follow, and what to avoid.

    Here’s what mine looks like for a typical project:

    # Code Style
- Use ES modules (import/export), not CommonJS (require)
- Destructure imports when possible
- All API responses must use the ResponseWrapper class

# Testing
- Run tests with: npm run test:unit
- Always run tests after making changes
- Use vitest, not jest

# Security
- Never commit .env files
- All API endpoints must validate JWT tokens
- Use parameterized queries — no string interpolation in SQL

# Architecture
- Services communicate via gRPC, not REST
- All database access goes through the repository pattern
- Scheduled jobs use BullMQ, not cron

    The /init command can generate a starter CLAUDE.md by analyzing your project structure. But I’ve found that manually curating it produces much better results. Keep it concise — if it’s too long, Claude starts ignoring rules (just like humans ignore long READMEs).

    ⚠️ Gotcha: Don’t put obvious things in CLAUDE.md like “write clean code” or “use meaningful variable names.” Claude already knows that. Focus on project-specific conventions that Claude can’t infer from the code itself.

    Security Configuration — The Part Most People Skip

    As a security engineer, this is where I get opinionated. Claude Code has a robust permission system, and you should use it. The default “ask for everything” mode is fine for exploration, but for daily use, you want to configure explicit allow/deny rules.

    Here’s my .claude/settings.json for a typical project:

    {
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test *)",
      "Bash(git diff *)",
      "Bash(git log *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Read(./config/credentials.json)",
      "Bash(curl *)",
      "Bash(wget *)",
      "WebFetch"
    ]
  }
}

    The deny rules are critical. By default, Claude can read any file in your project — including your .env files with database passwords, API keys, and secrets. The permission rules above ensure Claude never sees those files, even accidentally.

    🚨 Common Mistake: Running claude --dangerously-skip-permissions in a directory with sensitive files. This flag bypasses ALL permission checks. Only use it inside a sandboxed container with no network access and no sensitive data.

    For even stronger isolation, Claude Code supports OS-level sandboxing that restricts filesystem and network access:

    {
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true,
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"],
      "allowLocalBinding": true
    }
  }
}

    With sandboxing enabled, Claude can work more freely within defined boundaries — no more clicking “approve” for every npm install.

    Subagents and Parallel Execution

    One of Claude Code’s most powerful features is subagents — specialized AI assistants that run in their own context window. This is huge for context management, which is the number one performance bottleneck in long sessions.

    Here’s a custom security reviewer subagent I use on every project:

    # .claude/agents/security-reviewer.md
---
name: security-reviewer
description: Reviews code for security vulnerabilities
tools: Read, Grep, Glob, Bash
model: opus
---
You are a senior security engineer. Review code for:
- Injection vulnerabilities (SQL, XSS, command injection)
- Authentication and authorization flaws
- Secrets or credentials in code
- Insecure data handling

Provide specific line references and suggested fixes.

    Then in my main session:

    > use the security-reviewer subagent to audit the authentication module

    The subagent explores the codebase in its own context, reads all the relevant files, and reports back with findings — without cluttering my main conversation. I’ve caught three real vulnerabilities this way that I would have missed in manual review.

    CI/CD Integration — Claude in Your Pipeline

    Claude Code isn’t just an interactive tool. With claude -p "prompt", you can run it headlessly in CI/CD pipelines, pre-commit hooks, or any automated workflow.

    Here’s how I use it as an automated code reviewer:

    // package.json
{
  "scripts": {
    "lint:claude": "claude -p 'Review the changes vs main. Check for: 1) security issues, 2) missing error handling, 3) hardcoded secrets. Report filename, line number, and issue description. No other text.' --output-format json"
  }
}

    And for batch operations across many files:

    # Migrate 200 React components from class to functional
for file in $(cat files-to-migrate.txt); do
  claude -p "Migrate $file from class component to functional with hooks. Preserve all existing tests." \
    --allowedTools "Edit,Bash(npm run test *)"
done

    The --allowedTools flag is essential here — it restricts what Claude can do when running unattended, which is exactly the kind of guardrail you want in automation.

    MCP Integration — Connecting Claude to Everything

    Model Context Protocol (MCP) servers let you connect Claude Code to external tools — databases, issue trackers, monitoring dashboards, design tools. This is where things get genuinely powerful.

    # Add a GitHub MCP server
claude mcp add github

# Now Claude can directly interact with GitHub
> create a PR for my changes with a detailed description
> look at issue #42 and implement a fix

    I’ve connected Claude to our Prometheus instance, and now I can say things like “check the error rate for the auth service over the last 24 hours” and get actual data, not hallucinated numbers. The MCP ecosystem is still young, but it’s growing fast.

    What I Don’t Like (Honest Criticism)

    No tool is perfect, and Claude Code has real limitations:

    • Context window fills up fast. This is the single biggest constraint. A complex debugging session can burn through your entire context in 15-20 minutes. You need to actively manage it with /clear between tasks and /compact to summarize.
    • Cost adds up. Claude Code uses Claude’s API, and complex sessions with extended thinking can get expensive. I’ve had single sessions cost $5-10 on deep architectural refactors.
    • It can be confidently wrong. Claude sometimes produces plausible-looking code that doesn’t actually work. Always provide tests or verification criteria — don’t trust output you can’t verify.
    • Initial setup friction. Getting permissions, CLAUDE.md, and MCP servers configured takes real effort upfront. The payoff is worth it, but the first day or two can be frustrating.
    💡 Pro Tip: Track your context usage with a custom status line. Run /config and set up a status line that shows context percentage. When you’re above 80%, it’s time to /clear or /compact.

    My Daily Workflow

    After three months of daily use, here’s the pattern I’ve settled on:

    1. Morning: Start Claude Code, resume yesterday’s session with claude --continue. Review what was done, check test results.
    2. Feature work: Use Plan Mode for anything touching more than 3 files. Let Claude propose the approach, then execute.
    3. Code review: Use a security-reviewer subagent on all PRs before merging. Catches things human reviewers miss.
    4. Bug fixes: Paste the error, give Claude the reproduction steps, let it trace the root cause. Fix in one shot 80% of the time.
    5. End of day: /rename the session with a descriptive name so I can find it tomorrow.

    The productivity gain is real, but it’s not the “10x” that marketing departments love to claim. I’d estimate it’s a consistent 2-3x improvement, heavily weighted toward tasks that involve reading existing code, debugging, and refactoring. For greenfield development where I know exactly what I want, the improvement is smaller.

    🛠️ Recommended Resources:

    Tools and books mentioned in (or relevant to) this article:

    Key Takeaways

    • Claude Code is an agentic tool, not autocomplete. It reads, plans, executes, and verifies. Treat it like a capable junior developer, not a fancy text expander.
    • CLAUDE.md is essential. Invest time in curating project-specific instructions. Keep it short, focused on things Claude can’t infer.
    • Configure security permissions from day one. Deny access to .env files, secrets, and credentials. Use sandboxing for automated workflows.
    • Manage context aggressively. Use /clear between tasks, subagents for investigation, and Plan Mode for complex changes.
    • Always provide verification. Tests, linting, screenshots — give Claude a way to check its own work. This is the single highest-leverage thing you can do.

    Have you tried Claude Code? I’d love to hear about your setup — especially if you’ve found clever ways to use CLAUDE.md, subagents, or MCP integrations. Drop a comment or ping me. Next week, I’ll dive into setting up Claude Code with custom MCP servers for homelab monitoring. Stay tuned!

    📋 Disclosure: Some links in this article are affiliate links. If you purchase through these links, I earn a small commission at no extra cost to you. I only recommend products I’ve personally used or thoroughly evaluated. This helps support orthogonal.info and keeps the content free.

    📚 Related Articles

Home · About · Privacy Policy · Terms of Service
© 2026 Orthogonal Info. All rights reserved.