Systems thinking to 'translation' and back to systems thinking. How AI is shaping the software development profession.

Software engineering became translation job for fifty years. That job is over. What replaces it is harder, rarer, and more valuable and most of the industry is going after the wrong thing.

I started writing software when floppy disks were a thing. I run a technology consulting firm that builds software for mid-market companies, the kind with $20M to $500M in revenue, real operational complexity, and no patience for frameworks that do not ship. I have delivered production systems for over three decades. This article is about what I observe in real engagements, with real money attached and happening right now.

The occupation of software development is undergoing a structural transformation so fundamental that most people inside it have misidentified what is changing. They think the change is about speed. It is about the elimination of an entire category of human labor, and the radical elevation of a different category that most developers have spent their careers avoiding.

The Translation Layer

Somewhere in the late 90s, the core act of professional software development transitioned from ‘systems development’ to ‘software development’ and that nuanced changed transitioned the profession into a translator i.e., develop instructions for machines that understand 0’s and 1’s to do what we want it to do. A business person describes a need in commercial language. An analyst restates it as requirements. A developer converts it, line by line, into machine-readable instructions. The entire occupation, its university curricula, its interview rituals, its compensation bands, its org charts, was built on the premise that this translation is difficult, slow, and requires years of accumulated fluency. That premise started collapsing about eighteen months ago.

Large language models produce syntactically correct, functionally adequate code faster than any human. They do it across every mainstream language, every major framework, every cloud provider’s SDK. The mechanical act of converting a specification into working code, the thing that four-year computer science degrees were designed to teach, is now performed by a machine at commodity cost. In production, at companies of every size, shipping to real users. We have several instances of this at our own firm.

Let me be precise about what “commodity cost” means, because the tendency in this industry is to either catastrophize or dismiss. AI does not write perfect code. It does not understand your business domain, your performance constraints, or the political dynamics that determine whether your system gets adopted. What it does is make the mechanical act of producing a function, a module, a service, a test suite, a Terraform configuration, a CI/CD pipeline essentially free. The typing part. The syntax part. The part that required you to remember whether it is Array.prototype.map or _.map or list(map(...)). I am certain this will also evolve soon from what I seeing.

The ‘Coordination’ Overhead

A conventional software development team of twenty-five people exists not because the software requires twenty-five brains, but because the process does. This became more prevalent as each step in the software lifecycle became more specialized. UX Researchers, UX Designers, Product managers, product owners, ‘Scrum’ masters, team leads, project managers, front end developers, back end developers, devops engineers, support engineers, SDETs, Data engineers, AI engineers, ML engineers, Site reliability engineers etc. etc. and every other flavor of fancy sounding roles that made the “Resume” command more $. I call it “Resume driven development’.

Consider the anatomy of a typical product engineering organization. Frontend engineers, backend engineers, DevOps engineers, QA engineers, a scrum master, a project manager, a product owner, a tech lead, an architect, and several people whose primary function is ensuring the others are talking to one another. The daily standup exists because handoffs create information loss. The sprint retrospective exists because the process generates friction that must be periodically acknowledged. The design review exists because no single person holds the full system in their head.

Stack these roles up and what you find is an organization where the majority of effort goes not into building software but into coordinating the building of software. On a twenty-five-person team, in my experience, fewer than ten produce artifacts that directly become the product. The rest manage the information loss created by having ten people produce artifacts in parallel.

Brooks’s Law, which observes that adding people to a late project makes it later, is really a statement about coordination costs. The mythical man-month is not about the work. It is about the overhead of dividing the work among minds that do not share context.

AI-assisted development collapses this coordination graph. A single engineer with AI tooling can hold the full system context (frontend, backend, infrastructure, test suite, deployment pipeline) because the machine handles the mechanical translation at every layer. There is no handoff from the API team, because there is no API team. There is no standup, because there is no one to synchronize with. There is no sprint planning ceremony, because the backlog is a list and one person works through it at the speed of thought.

Most commentary about AI and software development frames the question as “will AI replace developers?” That question is simultaneously too dramatic and too narrow. The better question: will AI eliminate the need for teams? For a growing class of applications, the answer is yes. Not by replacing individuals one by one, but by eliminating the division of labor that made teams necessary.

A solo engineer with Claude Code or Cursor does not work twenty-five times faster than a single traditional developer. A solo engineer with AI tooling can deliver what a twenty-five-person team delivers because that team was spending 60 to 70 percent of its capacity on coordination, communication, waiting, context-switching, and rework caused by information loss across handoffs. Remove the handoffs and you remove the need for most of the people.

Systems Thinking Moves Back to the Center

Once the translation layer is gone and the coordination overhead evaporates, what remains is the part of software engineering that was always hardest and least teachable: systems ‘thinking’.

I want to be specific about the term, because it gets used loosely. I do not mean “thinking about the big picture” in some vague managerial sense. I mean the concrete, technical, constantly exercised ability to hold a multi-component architecture in your head. Not just the code, but the failure modes, the data flows, the operational characteristics under load, the security boundaries, the cost profile at scale, the upgrade path eighteen months out, and the regulatory constraints that will change next year.

Systems thinking is the difference between someone who can write a correct function and someone who knows where that function should live, what it should assume about its callers, what happens when the database it depends on goes away for ninety seconds, and whether the interface it exposes will still make sense after the product pivots.

In the old model, this kind of thinking was distributed across roles. The architect handled structure. The tech lead handled trade-offs. The senior developer handled edge cases. The DevOps engineer handled operational behavior. Each person held a partial model of the system. The full picture existed only in aggregate, reconciled imperfectly in meetings, documented incompletely in wikis nobody read.

In an AI-assisted model, the engineer who directs the AI must hold the full model, because the AI has no persistent judgment. It has no memory of why you chose PostgreSQL over DynamoDB. It has no opinion about whether your event-driven architecture is overkill at your current scale. It generates exactly what you ask for, with no view on whether what you asked for is wise.

Ask it to build a service with no circuit breaker and it will. Ask it to store API keys in a configuration file committed to the repository and it will do so cheerfully. Ask it to create a tightly coupled architecture with twelve services sharing a single database and it will produce it with clean variable names, helpful comments, and comprehensive documentation explaining how the twelve services share a single database.

The AI is an extraordinarily competent translator with zero architectural taste. The human supplies all the taste. And taste in software architecture is not an aesthetic preference. It is accumulated judgment that distinguishes systems that survive production from systems that pass their test suites.

For decades, the scarce resource was people who could write correct code under time pressure. The interview process reflected this: whiteboard algorithms, timed coding challenges, syntax quizzes. Going forward, the scarce resource is people who can think in systems, specify the right thing to build, validate that generated output actually implements it, and anticipate second-order consequences that the model will never flag.

The irony is that most senior engineers have been doing this all along but never received credit for it, because organizations measured output in lines of code and features shipped rather than in disasters averted and architectures that scaled gracefully. The AI era does not create the need for systems thinking. It reveals that systems thinking was always the valuable part, obscured by the translation work that surrounded it.

What Happens to Every Role

Let me walk through the traditional software org chart and describe what happens to each role. Some of this will be uncomfortable. Pretending otherwise is worse.

The Junior Developer

The traditional junior developer role (take a well-defined ticket, implement it in a known framework, submit for review, incorporate feedback, repeat) was a training pipeline. You entered knowing syntax and left knowing systems. The intermediate steps were the education.

AI disrupts this. If a senior engineer can direct AI to produce the output that juniors were producing, faster and with fewer defects, the economic rationale for hiring juniors weakens considerably. The apprenticeship model depended on mechanical work that was simple enough for beginners but real enough to teach them something. That mechanical work is precisely what AI handles best.

I do not have a clean answer for this. The entry path into software engineering is narrowing. People who enter the field will need to bring more than the ability to write code from a specification. They will need to demonstrate systems-level reasoning, the ability to evaluate generated output critically, and enough breadth across the stack to operate as generalists. That is a higher bar than the industry has historically set for entry-level roles. Whether it is permanently higher or transitional, nobody knows.

The QA Engineer

The dedicated QA role (writing test cases from requirements documents, executing manual test plans, filing bugs, arguing about severity levels) is being absorbed. Not eliminated in function, but eliminated in headcount.

In an AI-assisted workflow, the engineer generates test suites alongside production code, in the same session, against the same specification. Unit, integration, end-to-end. The AI writes them. The engineer reviews for coverage gaps, boundary conditions, and the adversarial scenarios that the model lacks the imagination to conceive. The function of quality assurance survives. A dedicated human doing it full-time does not.

What persists, and is actually elevated, is the adversarial mindset. The person who asks “what happens when this assumption is wrong?” and “what does the system do when the third-party API returns garbage?” That person is now the same person who wrote the code.

The DevOps / Platform Engineer

AI tooling generates Terraform modules, Kubernetes manifests, CI/CD pipelines, Dockerfiles, monitoring configurations, and alerting rules with the same fluency it generates application code. I have watched it produce production-grade infrastructure-as-code that would have taken a dedicated DevOps engineer two weeks, and it finished in an afternoon.

The function of infrastructure management persists. Systems still need to be deployed, observed, scaled, secured, and kept alive at three in the morning. The specialized role, where someone’s entire professional identity is writing YAML and debugging Helm charts, is folding back into the application engineer. Infrastructure is becoming a specification that AI implements, not a discipline requiring dedicated practitioners.

The DevOps engineers who thrive will be the ones already operating at the systems level: designing platform architectures, defining deployment strategies, thinking about cost optimization at scale. Those who were primarily writing configuration files are in the same position as developers who were primarily writing boilerplate.

The Scrum Master and Project Manager

These roles exist to manage the complexity of coordinating many humans. When one human does the work, the coordination function evaporates. There is no sprint to plan. There is no velocity to track. There is no burndown chart to present. There is no retrospective to facilitate, because the feedback loop between one person and their AI tooling runs continuously, not in two-week intervals.

What survives is prioritization. Someone still needs to decide what to build next, in what order, against what trade-offs. That function migrates to the product owner, the business stakeholder, or the engineer. It does not require a dedicated role with a certification.

Some scrum masters provide value beyond ceremony facilitation: coaching, removing impediments, protecting teams from organizational dysfunction. When “the team” is one or two people, the impediments are different and the coaching looks different. The function may persist in some form. The named position on the org chart, with a salary and a Jira dashboard, does not.

The Business Analyst and Product Owner

The traditional business analyst wrote specifications that developers would implement. The product owner maintained a backlog of stories with acceptance criteria. Both were translation layers, converting business intent into structured artifacts that engineering could consume.

In an AI-assisted model, the specification is the prompt, authored by someone who understands both the business need and the technical system well enough to validate output immediately. The requirements intermediary, who interviews stakeholders, writes user stories, and hands them to developers, loses their function to the engineer who can sit with the stakeholder, understand the need, and build a working prototype in the same meeting.

The feedback loop shrinks from weeks to minutes. The business analyst’s value proposition was bridging a communication gap between business and engineering. AI does not close that gap. It makes the gap irrelevant, because the person writing the software can produce a working version fast enough that the stakeholder reacts to the product rather than to a document.

Product owners who survive will be strategists rather than administrators: people who understand market positioning, competitive dynamics, unit economics, and customer psychology. Those whose primary contribution was writing tickets will find that contribution automated.

The Software Architect

Architecture was always the highest-value, lowest-headcount function on a software team. Most organizations had one architect for every fifteen or twenty developers. The architect made decisions that constrained everything else: technology selection, service boundaries, data models, API contracts, deployment topology, security posture. These decisions were made infrequently but had enormous downstream consequences.

In the old model, the architect designed and the team implemented. There was a time gap between design and implementation, during which requirements changed, assumptions proved wrong, and the implementation drifted.

In an AI-assisted model, the architect directs an AI that implements in real-time, validating output against a mental model of the system and correcting course before defective structures compound. The time gap between design and implementation collapses. An architect who previously spent 20 percent of their time designing and 80 percent explaining, reviewing, and correcting now spends 80 percent designing, evaluating, and iterating. The output is not incrementally better. It is categorically different in quality and volume.

This is the one role that gains leverage.

The Senior / Staff Engineer

The senior engineer who once spent 60 percent of their time in code review, mentoring juniors, resolving merge conflicts, and attending status meetings now spends that time on work that actually requires accumulated judgment: system design, failure-mode analysis, performance modeling, security review, API contract design, data model evolution.

Mentoring changes rather than disappears. It shifts from “how to write a for loop” and “here is how our ORM handles lazy loading” to “how to evaluate whether generated code is safe to ship” and “when to override the AI because it optimized for the wrong variable.” The apprenticeship becomes one of judgment rather than syntax.

The Prompt Engineering Trap

A narrative gaining traction holds that “prompt engineering” is the new core skill for software developers. That the future belongs to people who write better prompts. That the translation job has merely shifted from translating requirements into code to translating requirements into prompts.

This is a comforting story because it preserves the familiar shape of the job. It suggests the existing workforce just needs to learn a new syntax and everything continues.

It is wrong. Prompt engineering, in the narrow sense of phrasing instructions to extract better output from a language model, is a transitional skill. Models improve rapidly at interpreting intent from imprecise instructions. The gap between a well-crafted prompt and a mediocre one shrinks with every model generation. The skill ceiling is low. It takes weeks to become adequate, not years. It is not a career moat.

What matters is not how you instruct the AI but what you instruct it to build. Knowing which architecture will scale, which data model will flex, which service boundary will hold, which abstraction will help rather than hinder: that is systems thinking. It is not a prompting technique. It is a mode of cognition that takes years to develop and cannot be shortcut.

A developer who writes beautiful prompts but has no mental model of the system being built will produce beautiful code that is architecturally incoherent. I have already watched this happen. The output looks good. It passes tests. It runs in staging. Then it hits production with real traffic patterns, real failure modes, and real operational requirements, and it falls apart. Not because the code is buggy, but because the design was wrong and nobody with the judgment to notice was involved.

The Quality Illusion

AI-generated code has a quality profile that is deeply deceptive.

It is syntactically clean. It follows naming conventions. It includes error handling. It has comments. It often includes test coverage. By every surface-level metric, it looks professional. A code reviewer scanning quickly would approve it.

The defects are not syntactic. They are architectural. The code works, for now, at this scale, with these assumptions. But it encodes assumptions nobody examined, creates coupling nobody intended, introduces performance characteristics nobody modeled, and makes security trade-offs nobody evaluated. It works today and becomes technical debt tomorrow, and the debt accrues silently because the code looks like it was written by someone who understood what they were doing.

The organizations that will suffer most in the near term are those that adopt AI tooling aggressively without retaining people who have the systems-level judgment to audit the output. They will ship faster. They will ship more features. And they will accumulate architectural debt at a rate that will take years to unwind, because the debt was invisible at the point of creation.

The Arithmetic

The net effect of this shift is fewer software engineers employed, doing more valuable work, at higher individual compensation. Demand for software is growing. Demand for software teams is shrinking.

A company that once needed twenty-five engineers, a QA team, a DevOps team, a scrum master, and a project manager to build and maintain a product can now achieve comparable output with three to five engineers who think in systems and use AI as their labor force. I am not projecting. I am describing engagements I have staffed in the past twelve months.

A twenty-five-person team costs, fully loaded, somewhere between $4M and $7M annually depending on geography and seniority mix. A three-person AI-native team delivering equivalent output costs $1M to $1.5M. Every CFO in every software company is looking at those numbers, even if most have not yet acted on them.

The transition will not be instant. Large organizations move slowly. Safety-critical and heavily regulated systems will retain larger teams for legitimate reasons. Organizational inertia is real. Many companies have long-term contracts, institutional knowledge locked in individuals, and cultural resistance that will slow adoption by years.

But the direction is unambiguous.

What This Means for You

If you are a senior engineer or architect, your position strengthens. The judgment you accumulated over years of building and maintaining production systems is exactly what AI cannot provide and what the market is about to value more explicitly. The task now is to become comfortable operating across the full stack. Not by memorizing every framework, but by understanding enough at every layer to evaluate AI output. You need to be the person who looks at a generated Terraform module and knows whether it will cost $200 a month or $20,000. You need to read a generated API design and know whether it will handle the next order of magnitude of traffic.

If you are mid-career, move up the abstraction ladder as fast as you can. Stop investing in mastering the syntax of any single language or framework. Start investing in systems: distributed architectures, failure modes, data modeling, performance characteristics, security patterns, cost optimization, operational behavior. The specific technologies change. The underlying principles do not. Learn to think about systems the way a physician thinks about the body, as interconnected components with feedback loops, failure cascades, and emergent behaviors that are not visible from any single part in isolation.

If you are early in your career, I will not pretend the path is clear. The traditional entry ramp is narrowing. What I would tell someone starting today: do not optimize for learning to code. Optimize for learning to think about software. Read architecture case studies. Understand why decisions were made, not just what was built. Build complete systems, even small ones. Deploy them. Operate them. Break them on purpose and fix them. The muscle you need is not “can I write a function” but “can I hold a system in my head, spot the weak joints, and make decisions that will still look reasonable in a year.”

If you are a QA engineer, DevOps engineer, scrum master, or project manager, the honest assessment is that your role title is at risk but the underlying skills may not be. The adversarial mindset of QA, the operational instinct of DevOps, the prioritization discipline of project management: these remain valuable. They need new containers. They will not exist as standalone roles on many teams. They will exist as facets of the systems-thinking engineer who does everything.

The Craft

There is a grief in this transition worth acknowledging. Many developers fell in love with the act of coding itself, the flow state, the puzzle-solving, the satisfaction of a clean implementation. The identity of being someone who builds things with their hands. Learning that the typing is no longer the valuable part is a genuine loss for people who built careers and self-concepts around it.

But the best developers always knew this, even when they could not articulate it. The best developers were not the fastest typists or the ones with the most API signatures memorized. They were the ones who said “we should not build this” and were right. They were the ones who sketched a design on a whiteboard in twenty minutes that saved the team six months. They were the ones who could look at a working system and see the fracture lines that would open under stress. They understood that the purpose of software is not to exist but to do something useful, reliably, at acceptable cost, for a sustained period of time.

That understanding is systems thinking. It was always the core of the craft, obscured by the translation work piled on top of it. Hence our company’s name thinkbridge.

The market is about to price accordingly.