Systems thinking to 'translation' and back to systems thinking. How AI is shaping the software development profession.
SubscribeSign in
Systems thinking to 'translation' and back to systems thinking. How AI is shaping the software development profession.<br>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.
Anand Krishnan<br>May 28, 2026
Share
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.<br>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.<br>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.<br>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.<br>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.<br>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’.<br>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.<br>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.<br>Brooks’s Law, which observes that adding people to a late project makes it later, is really a statement about...