March 17, 2026

Why Everything I Learned as an Engineer Is Depreciating — And What Comes Next

By Christian Fischer

The Software Factory — on how the role of software engineers, CTOs, and computer scientists is fundamentally changing, and what skills will define the next era.

I want to start with personal experience, because the abstract version of what I’m about to argue is less convincing than what it feels like to live through it.

My entire identity, for most of my professional life, has been built on engineering craft. Not management. Not strategy. Craft. I’ve been writing code for over fifteen years. I could hold complex distributed systems in my head, solve algorithm problems, refactor legacy systems, design systems that scale while managing complexity. Along the way, I was given the opportunity to lead engineering teams as CTO — twice now — but I never stopped thinking of myself as an engineer first. The title was a consequence of the craft, not the other way around.

That craft is now depreciating at a rate I never anticipated. And not just the parts I expected to lose — the trendy frameworks, the language-of-the-year churn. That kind of depreciation I’d made peace with long ago. What I wasn’t prepared for is that even the knowledge I considered foundational, the things I would have bet would remain valuable for another decade — parts of algorithms and data structures, systems design patterns I’d spent years mastering — are losing their direct value faster than anything I’ve experienced in my career. The core skill of translating business requirements into code is being hollowed out. We always knew that having good requirements was the hard part and coding was the easy part. Now the easy part is being done for us, and suddenly the hard part is all that’s left.

Here is what that looks like in practice. Last week, I used Claude Code to redesign our existing real estate market observer — a system with yield-based scaling, deduplication across unstructured and potentially fake data, multi-configuration scheduling, observability, and cost constraints. A system with five to six man-years of engineering effort baked into it. Over two to three evenings, walking through requirements, architecture, and implementation details with different agent roles, I had a handoff-ready plan. My estimate is we can build it in three to six months.

That ratio is not a marginal improvement. It is a change in kind. And it forced me to ask a question I’d been avoiding: if a substantial amount of the craft that defined my career can be replicated in minutes, what exactly is my role now — and what skills will still be relevant in ten years?

This series is my attempt to work through that question. Not from the position of a CTO handing down strategy, but from the position of an engineer watching the ground shift under skills he spent years building — and trying to figure out what comes next.

In Part I: The Shift, I’ll look at what’s actually happening — how cognitive labor is being displaced, how fast the timeline is moving, and what it means that software development is becoming a factory you design rather than a craft you perform.

In Part II: What To Build Next, I’ll explore where this is heading — the agentic operating system emerging inside companies, why traditional engineering specializations are dissolving — and what engineers and CTOs can concretely do today to prepare.

Part 1

The displacement of cognitive labor

The question of whether AI will exceed human capability across most cognitive domains is settled. It already has. What remains is how fast the full implications arrive — and for software engineering specifically, the answer is: faster than almost anyone expected.

Sahaj Garg, CTO of Wispr, describes the shift from personal experience. Intelligence, he says, has become “a commodity on tap.” The skills that remain are taste, direction, synthesis. Not raw cognitive horsepower.

I recognize myself in that description. The tasks that defined my early career — debugging complex systems, writing performant code, translating specs into implementations — are increasingly handled by AI with minimal human guidance. Not poorly. Competently. And improving month over month at a pace that makes it hard to plan around.

Sequoia’s Julien Bek offers a useful framework for understanding what’s happening. He distinguishes between intelligence work and judgement work. Intelligence work is translating a spec into code, testing, debugging — complex but ultimately rule-based. Judgement work is deciding what to build, when to ship, whether to take on tech debt, how to dissect a problem into the right components, where to draw the boundaries, and how to handle ambiguity. AI has (or will soon have) crossed the threshold where it can handle most intelligence work autonomously. Software engineering got there first — not just because it is primarily intelligence work, but because engineers are the ones who can actually set up the scaffolding: configuring MCP servers, writing precise prompts, managing context, being exact with language. It is coming to every single profession, but right now it takes technical fluency to make the tools work.

That last point matters for the timeline question. The remaining bottleneck is not whether AI will get smart enough. It already is. The bottleneck is organizational scaffolding — how to harness, structure, and deploy that intelligence effectively. And as Garg points out, that’s an engineering problem, not a research problem. The timeline is a matter of execution speed, not scientific discovery.

Also, the scaffolding is arriving faster than most people expect. Agents coordinating sub-agents, computer-use agents operating software the way humans do, background agents running autonomously in the cloud. Each of these existed as a demo twelve months ago. Today they’re in production at companies like Stripe, Ramp, and Spotify. The gap between “impressive demo” and “how we actually work” is narrowing quickly.

So how much time do we have to adapt? There is still time to reskill, but not as much as it might feel. Given where we were just a year ago, it’s genuinely hard to estimate where we’ll be a year from now. The pace might slow down somewhat. But we’re not talking about many years. The engineers and CTOs who start adapting now will have a meaningful head start. The ones waiting for the picture to fully clarify may find they waited too long.

There’s a concept gaining traction called the “dark factory” — borrowed from manufacturing, where a lights-out factory runs with no workers on the floor. In software, it means: a specification goes in, working tested software comes out.

Saumya Tyagi, writing about his own platform team’s journey, puts it honestly: most organizations hit a ceiling at “AI writes code, a person reviews it.” His team had adopted every tool — Cursor, Copilot, agents fixing Dependabot alerts automatically. It looked great in a slide deck. Then he tracked where everyone’s time actually went. The bottleneck hadn’t disappeared. It had moved down the hall. Developers were still waiting hours for code reviews that amounted to rubber stamps, still testing by hand on localhost, still going back and forth about variable names. They’d automated the typing. Just the typing.

The breakthrough came when he realized the next step isn’t making the human faster — it’s removing the human from the loop entirely for the parts that don’t require judgement. Specs go in. Holdout scenarios — acceptance tests the coding agent never sees — validate the output. A separate model judges whether the result satisfies them. No human writes the code. No human reviews the code. The human writes the specification and evaluates the outcome.

This isn’t theoretical anymore. In early 2026, StrongDM demonstrated that three engineers can ship production software — thousands of lines of Rust and Go — without anyone writing or reviewing a single line. Both coding and review are handled by agents, with quality enforced through holdout validation rather than human oversight.

The dark factory

What’s emerging alongside this is a pattern of role separation. Garry Tan, Y Combinator’s president, open-sourced gstack, a set of agent roles that map to how real engineering organizations work. The insight is simple but important: when you ask the same model to plan, implement, review, and ship in one conversation, you get mediocre results. Different phases of software development require fundamentally different cognitive modes. A CEO-level review challenges whether you’re building the right thing. An architecture role locks data flow and boundaries. A reviewer looks for ways the code will break in production. A QA role checks whether it actually works. Each agent is scoped to a lane and cannot drift. This is what I used for the crawl engine redesign I mentioned earlier — walking through requirements, architecture, and details with different agent roles. It works because it mirrors the organizational structure that makes human teams effective.

The pattern goes further. Tyagi describes AGENTS.md files — structured documentation that tells agents how to navigate your codebase, what conventions to follow, where the boundaries are — as “the single best thing you can do for agent quality today.” Two hours of writing. Permanent payoff. The best developers and CTOs are already mandating these from their teams. It’s the new definition of engineering hygiene.

This is the shift that matters most. The job is no longer operating the machines on the factory floor. It’s designing the factory itself — the specifications, the agent roles, the quality gates, the documentation that makes agents effective. You’re not writing code. You’re building the system that writes code. And the quality of your factory determines the quality of what comes out.

The dark factory as a new form of company

The software factory doesn’t exist in isolation. It sits inside something bigger: an agentic AI-enabled operating system for the company. This is where agents and humans collaborate across the entire software delivery lifecycle — planning, coding, reviewing, testing, deploying.

The background agents landscape is emerging rapidly. These are agents that run in the cloud, triggered by events (a PR opened, a Slack message, a schedule), completely decoupled from a developer’s machine. You don’t steer them. You delegate, walk away, and review the output later. The shift is from being in the loop to being on the loop.

Workflow orchestration platforms are emerging that make this tangible — tools where humans and agents work together, with humans handling reviews, approvals, and judgment calls while agents handle the execution. The core workflow becomes: define intent → agents execute → humans review and approve → agents continue.

This changes the organizational model. Engineers become orchestrators of agent fleets. They define what needs to happen, set quality gates, review critical decisions, and handle the edge cases that require genuine judgment. The factory runs. Engineers ensure it runs well and in the right direction.

In this world, the traditional specializations dissolve. Frontend engineer, backend engineer, DevOps engineer, mobile engineer — these distinctions made sense when the bottleneck was human expertise with specific technologies. When agents can write React, configure Kubernetes, build APIs, and set up CI/CD pipelines, the value isn’t in knowing any one of those domains deeply. It’s in understanding the whole system and making sound decisions about it.

Skills losing value rapidly:

  • Framework-specific expertise: Knowing React vs. Vue vs. Angular deeply matters less when agents can write any of them. The shelf life of framework knowledge, already short, is approaching zero as a differentiator.
  • Language fluency: Being an “expert Java developer” or “senior Python engineer” loses meaning when agents write idiomatic code in any language.
  • Routine architectural patterns: Standard CRUD applications, REST API design, basic database modeling — these are now commodity work that agents handle well.
  • Parts of algorithms and data structures: I never thought I’d write this. But the ability to implement a red-black tree or optimize a dynamic programming solution from scratch is becoming a party trick, not a career skill. Understanding when these tools matter still counts. Implementing them yourself, less so.
  • Manual code review for correctness: Agents are increasingly better at finding bugs than humans in review.

Skills gaining value:

  • Communication and natural language precision: When prompts and specifications are your primary tools, the ability to articulate what you want — clearly, precisely, with the right level of detail — becomes the core engineering skill. This is a profound shift from code being the primary medium of expression.
  • Business understanding and domain expertise: Engineers who understand the why behind what they’re building can direct agents far more effectively than those who only understand the how. Owning a piece of the business outcome, not just a piece of the technology, becomes the expectation.
  • Divide and conquer / systems thinking: Breaking complex problems into well-scoped sub-problems is exactly what agent orchestration requires. This fundamental CS skill actually gains value — but the application shifts from code decomposition to work decomposition.
  • Architecture for security, scalability, and cost: While agents can implement architectures, understanding the trade-offs between security postures, scaling strategies, and cost implications still requires experienced human judgment. This is where deep technical knowledge retains its value — not in implementation, but in decision-making.
  • Factory design and optimization: Writing great agent descriptions, crafting reusable prompt libraries, designing review workflows, setting up quality gates, choosing the right level of autonomy for different tasks. This is the new “engineering.”
  • Edge case and hard problem solving: When agents hit their limits — novel problems, ambiguous requirements, system-level failures — humans with strong technical foundations step in. The skill is knowing when to step in and having the depth to solve what agents can’t.

There’s a consequence to all of this that’s worth calling out explicitly: engineers need to deliver impact more directly. When a team of three can ship what used to require thirty, the question becomes what to build, not how to build it. Companies will expect engineers to own outcomes, not outputs.

This means understanding customers, revenue models, market dynamics, competitive landscapes. The CTO of the future isn’t the best coder — they’re the person who best understands how technology creates business value and can orchestrate the factory to deliver it.

For individual engineers, this means the career path shifts. The 10x engineer of the future isn’t someone who writes 10x more code. They’re someone who directs agents to deliver 10x more business impact — because they understand what matters, can communicate it precisely, and can judge whether the output is right.

If you’re a software engineer reading this and feeling the ground shifting, here’s what I’d recommend — not as abstract advice, but as concrete steps I’m taking myself.

Mindset shifts:

  • Accept that developing software is fundamentally different now. Not incrementally different. Fundamentally. The sooner you internalize this, the sooner you can adapt.
  • Stop optimizing for coding speed. Start optimizing for specification clarity and agent orchestration effectiveness.
  • Think of yourself as building the factory, not the product. Your output is workflows, prompts, quality gates, and agent configurations — not code.

Concrete skill-building:

  • Get fluent with agent-based development. Use Claude Code, Cursor, or similar tools daily. Not as autocomplete — as autonomous agents. Give them complex, multi-file tasks. Learn what makes a good specification vs. a bad one.
  • Build a personal prompt library. Treat prompts like you treat code: version them, iterate on them, share them. The best developers already have reusable prompt patterns for architecture reviews, code generation, testing strategies, and more.
  • Invest in communication skills. Writing clearly is now an engineering skill. Practice articulating technical requirements in natural language. The gap between “what you meant” and “what the agent understood” is the new debugging.
  • Go deep on your business domain. If you work in fintech, become an expert in financial products. If you’re in healthtech, understand clinical workflows. Domain knowledge is the moat that AI can’t easily replicate because it requires context that lives in relationships, institutions, and lived experience.
  • Learn systems architecture at the decision level. Not how to configure Nginx — why you’d choose one architecture over another given security, cost, and scale constraints. The judgment layer.
  • Experiment with agent orchestration. Try tools like gstack. Set up background agent workflows. Build small “factories” for your own projects. This is the new craft.

For engineering managers and CTOs:

  • Rethink how you hire. Evaluate communication quality, prompt engineering ability, and AI proficiency alongside traditional skills. Ask candidates to solve a problem using an AI agent, then evaluate how they directed it and judged the output.
  • Evaluate prompts and specifications, not just code. In code reviews, start reviewing the prompts and agent configurations that generated the code. This is where the craft lives now.
  • Restructure teams around outcomes, not technology layers. Kill the frontend/backend/DevOps silos. Build teams around business capabilities with engineers who can direct agents across the full stack.
  • Invest in your agent infrastructure. Build the factory floor: standardized development environments, governance frameworks, trigger systems, quality gates. This is your competitive advantage.

I’ll end where I started — with honesty. I feel the loss of skills I spent years building. There’s a grief to it that I think many engineers share but few talk about publicly. The patterns I memorized, the frameworks I mastered, the clever optimizations I was proud of — their half-life has collapsed.

But here’s what I also feel: excitement. Because what’s emerging is a role that’s more creative, more strategic, and more directly connected to impact than writing code ever was. The engineers who thrive won’t be the ones who cling to the old model. They’ll be the ones who embrace being architects of the factory — who see natural language as their new programming language, business outcomes as their new test suite, and agent orchestration as their new craft.

The factory is being built. The question is whether you’ll design it or be replaced by it.

What’s your experience with this shift? I’d love to hear from other CTOs and engineers navigating this transition. Drop a comment or reach out.

References & Further Reading