AI-enabled software engineering is declarative -- and requires insights from Lean IT

What an old submariner taught over breakfast in Prague

Sounds like there was a lot of discourse about AI at Davos this year. I was there in 2014. In the space of a week I managed to

• Physically run into a tech billionaire and knock him on his backside. (He was very nice about it.)

• Stand in the sight line for a US governor’s protection detail, causing one of his bodyguards to pick me up and move me out of the way

• Set off a very awkward discussion between a Knight of the Realm and the Prime Minister of a US ally

• Lose my raincoat in the Zurich airport

No, I have not been invited back. Some would say for obvious reasons. Forget about Davos, I’m not even writing from the coffee shop this morning -- it’s too cold and snowy to venture across First Avenue.

Thank you for reading -- and, for those of you in North America: stay warm! Some key points from this issue:

• AI-enabled software engineering is declarative. CIOs and CTOs have to establish the semantics that allow engineers to interact with agents via longer cycles

• This mirrors years-old lessons from Lean IT. Productivity breakthroughs come from designing around human judgment, not eliminating it.

• Let’s worry about the right risks. Worry more about how AI will change the people who use it than whether it will destroy us all.

Also: I have fun writing the footnotes. Let me know if you enjoy them!

The Main Argument: Semantics for AI-Enabled Software Engineering

---

• What you need to know: AI-enabled software engineering productivity requires engineers to engage coding tools in longer cycles

• What you need to do: Create the semantic standards (for functional and non-functional requirements) that reduce the risk of disconnect between declarative intention and procedural code

• What you need to decide: Where you can use industry standards and where you must create your own; which standards you should create at the enterprise versus the business unit level [1]

---

Anyone can be stupid, and I can be stupider than most people. The first time someone described using LLMs to write code I responded “So people will have to use very precise language to describe what they want the software to do. We have that. It’s called Python.”

I failed to understand the power in AI-enabled coding. It’s not replacing formal language (like Python) with English syntax. It’s moving from procedural to declarative statements. Saying “These 12 error conditions should result in asking the user to check the data entered” takes much less time than writing the procedural logic to check each of the 12 error conditions.

Developing my little enterprise tech economic model drove this home for me. I wrote out about 60 equations relating different entities — story points, OS images, GB egress, DBMS instances — and Cursor developed the procedural code to realize the equations with very little error.

It did highlight another challenge though: the relationship between precision and the ability for engineers to interact with coding agents via longer running cycles. I knew that productivity lift required pushing software engineers to engage agents in longer-running tasks with fewer cycles. [2] I suspected semantic precision was important here. Building my little model pounded it into my head.

Cursor did a beautiful job of translating my declarative equations into procedural code. I was bloody specific. The only problems? When I had been imprecise in describing a metric, for example whether the cost per story point was gross of or net of deadweight loss.

But not everything we need to do will be as clear as my tech economic equations. I burned a ton of cycles cleaning up the UI because I hadn’t thought through what I wanted. For the moment, scalability, security and maintainability aren’t especially important. Yes, I am embarrassed by the dog’s breakfast I made in naming variables. [3]

I would want not only standards (”i must do x”), but also semantics my agent would understand that would allow me to tune UI, security, resiliency for the use case in question. Tools like cursor, can enable this, but only enterprises can decide on and implement the semantics and the standards that will mandate precision and enable longer engineering cycles.

This may be as important for functional requirements as for non-functional ones. Imagine how much easier “Spec-driven” development will be for a bank that has common semantics for each of the milestones in opening a new account or each of the touch-points in a customer relationship.

Maybe another reason that semantic layers and ontologies will be strategically critical in extracting value from AI?

Enterprise technology as history: What we can learn from Lean IT as we adopt AI-centric software engineering

---

• What you need to know: Lean IT succeeded because it saw operators contributing talent and imagination to production

• What you need to do: Identify and eliminate muda (or waste) as you build AI-centric software engineering capabilities

• What you need to decide: What techniques and methods you will use to apply the learnings from Lean IT to AI-centric software engineering

---

Some of us are congenital skeptics. Not only did I have questions about AI-enabled development at first, I also expressed doubts about Lean IT. This caused a little bit of tension between me and an older colleague who first figured out Lean IT for McKinsey.

Breakfast in Prague

I was trying to think about how to resolve when I arrived at our 2009 leadership meeting (in Prague!) for the global technology practice. When I walked into the restaurant for breakfast, this colleague who championed Lean IT said, “Hey, Kaplan, come sit with me.”

I must have listened to him talk for two hours, and it was glorious. He talked about Annapolis, and how decided he wants to be a submariner. About his interview with Admiral Rickover. How he must have risked court martial to help get a friend into the submarines. (Loyalty was an important thing with him.) About playing hide and seek with the Soviet fleet in the Arctic. [4] How he navigated a submarine with a busted navigation system back to port with a sextant. He also told a story about watching Walter Munk emerge from a Harrier jump jet that landed on a bloody pier to deliver classified intelligence to a waiting submarine that I would not have believed had it appeared in a movie script. [5]

About his early career with oil company and how his grizzled old mentor there explained to him that if you wanted to get anything done you needed a team that combined “born-intas” (second- or third-generation oilmen with Ivy League degrees) with hungry people from humble backgrounds who would roll up their sleeves and work.

And how he developed his views on enterprise technology organizations could make use of lean operations.

Lean operations reshaped the auto industry

In The Machine That Changed the World James P. Womack, Daniel T. Jones and Daniel Roos described how Japanese companies had developed an alternative to American-style mass production – a world of large batches, big inventories, dedicated machinery, fragmented tasks, humans as just another element of the production line and quality “inspected in” at the end. Lean manufacturing, they said, was very different:

• Value Defined by the Customer: Production is driven by customer demand, not by pushing products into inventory.

• Just-in-Time Flow: Parts and materials arrive exactly when needed; Inventory is minimized, which exposes problems and forces continuous improvement.

• Continuous Improvement (kaizen): Workers at every level are empowered to identify waste and improve processes; improvement is incremental and ongoing, not periodic or top-down only.

• Respect for People: Teams rather than individuals are the core unit; workers stop the line (e.g., andon) to fix quality problems immediately.

• Right-Sized Equipment & Flexible Production: Smaller, more versatile machines located near each other, enabling flow for varied models (not giant, specialized mass-production plants); production can shift quickly between different products.

• Pull System (Kanban): Production is “pulled” by downstream demand, not “pushed” by upstream schedules; visual signals (kanban cards) regulate work-in-progress.

• Quality Built In: Errors are prevented or fixed at source (jidoka), avoiding rework and scrap.

Toyota pioneered the principles of lean operations in the “Toyota Production System,” started in the 1950s – scarcity of capital and materials meant it couldn’t replicate the way Ford, GM or Chrysler built cars. Taiichi Ohno argued that Toyota couldn’t afford any form of waste, so he sought to expunge “muda” from all the company’s manufacturing processes:

• Overproduction: Making more than is needed or before it is needed.

• Waiting: Idle time when people, machines, or materials are waiting for the next step (e.g., bottlenecks, unbalanced work).

• Transport (or Conveyance): Unnecessary movement of products or materials (e.g., shuttling parts long distances between processes).

• Overprocessing (or Inappropriate Processing): Doing more work or using more complex processes than necessary (e.g., tighter tolerances than required, redundant approvals).

• Inventory: Excess raw materials, work-in-progress (WIP), or finished goods beyond what is immediately needed; Hides underlying problems and ties up capital.

• Motion: Unnecessary movement of people (e.g., searching, reaching, walking) that does not add value.

• Defects: Effort involved in inspecting, fixing, or scrapping errors—essentially rework.

The results shook the automotive industry. In 1955, Toyota produced about 23,000 vehicles – compared to 4.5MM for GM and 2.5MM for Ford. Toyota has been the world’s largest vehicle manufacturer for years, producing four times the volume of General Motors. For many years Toyota was the world’s most valuable auto manufacturer, until Tesla overtook it in 2020.

In contrast, David Halberstam pointed out how the “Whiz Kids” misused systems thinking and quantitative analysis in a way that degraded productivity and quality at Ford in The Reckoning.

And it had a lot of impact in IT

My colleague taught us to create value stream maps for core IT processes like server provisioning or incident management. This turned up a seemingly endless amount of waste, e.g.

• Requests sitting in queues for weeks at a time, with nobody working on them

• Sys admins searching for the information required to provision a system

• Requests redone multiple times because there was no incentive to do them correctly the first time

• Complex tickets sent to junior technicians and simple tickets fulfilled by senior engineers

They came up with creative solutions.

• Routing tickets through a point guard (or center-mid for soccer fans) who could distribute the right ticket to the right admin at the right time.

• Tracking rework and insisted that requestors include the information required to fulfill a request correctly the first time.

They did this in a way that increased front-line employees’ sense of ownership of and investment in their work. The results were transformational – server provisioning times reduced from months to a week or two; twenty percent productivity improvements in year, with little investment.

At first, I stood aside. Part of it was my natural contrarianism – if everybody around me believes in something it must be wrong. [6] Some of it may have been an overly mechanistic, rather than humanistic, mindset – I wanted to turn every infrastructure function into a machine.

After that breakfast in Prague, I began to see the relevance of Lean IT and the wisdom of designing around people, rather than seeing them as a necessary but unfortunate adjunct to the technology environment. And because I allowed my colleague to influence me, he came to see that some of the questions I asked were legitimate

• Lean operations derived from the Toyota Production System, not Toyota’s entire business system, which included, for example, decisions about what type of cars to make – enterprise technology organizations needed not just to improve their delivery processes, but also make good decisions about the architectures and technologies they supported

• Pushed a bit further, the Toyota Production System rested on an assumption that Toyota sold models of cars. In contrast, in that era, most IT organizations build infrastructure to order, just like coach-builders did fulfilling wealthy customers’ orders for cars in the late 19th century.

Eventually, we started to make Reese’s peanut butter cups – bringing together Lean IT, with the thinking about productized infrastructure [7]

The technology changes; the insights from lean remain

So what does this mean as CIOs and CTOs seeking to build an AI-centric enterprise technology function?

Much has changed. Lean IT sometimes veered into a skepticism of automation that we need to discard. Some of the operational techniques will change as well. Lean IT strove for smaller batches and shorter cycle times. As noted above, AI-enabled engineering productivity often requires larger «batches» specifications that allow coding tools to run for longer cycles between human interventions.

The humanism remains. Lean IT inverted the core assumption of mass production. It perceived human operators as contributing talent and imagination to production, rather than executing as task per instructions, as Frederick Taylor would have demanded.

Yes, productivity in AI-enabled software engineering will require standards, like the semantic ones suggested above, but it will also require designing around engineering creativity. It will also require close review of how software engineers do their work. As tech organizations implement AI coding tools, they must use value stream maps no less than they might have two decades ago to determine:

• What drives defects and rework?

• When does transporting information between different tools add complexity and toil?

• How to avoid inefficiency lost to waiting for a prompt to complete?

The game changes, but the imperative to remove muda from the system remains. How can we update the learnings from Lean IT to identify waste, minimize it and maximize the benefit of AI-enabled software engineering?

The Wire Section

Who is using AI to code? Global diffusion and impact of generative AI, Science
Who is adopting AI-enabled development and how much impact is it having? Some researchers decided to check with Github (using a model that identifies markers of AI-enabled code).

• Adoption rates for US-based contributors increased from roughly zero in mid-2021 to almost 30 percent at the end of 2025

• Adoption spikes with introduction of new tooling/capabilities

• US has the highest adoption rate, followed by Germany, France and India. Russia and China are further behind in adoption rates.

• AI adoption in US is associated with a 3.6 percent increase in commit rates, with productivity increases concentrated in more experienced developers

• AI adoption also associated with experimentation with new libraries

The Physics of Learning (And Why Almost No One Uses It), Justin Skycak
College lectures on Youtube. Virtually any book ever published on Kindle. Academic papers on arXiv.org -- we live in a golden age of self-education. Still, nobody has conquered the last mile between eyeball and cerebral cortex. We have access to the world’s intellectual treasures, but shoving them into our brain remains difficult.

On-line learning hasn’t helped. Watching video lectures may create more feeling of learning than learning itself, and the typical drill-and-kill type training works best for the simplest forms of knowledge.

Skycak, who leads analytics for EdTech company MathAcademy. He observes that we have known how people learn (including the underlying neuroscience) for years. We don’t apply those learnings in designing educational and training software because they make demands on the user and increase development costs.

Maybe we can’t do much about user motivation, but AI-enabled engineering should make it a lot easier and cheaper to build training software designed for the way people learn.

Just Six Numbers, Martin Rees
I doubt I’m smart enough to have learned much from this book about the how values of a few ratios imply a stable universe where life can exist. Reading it, though, fosters intellectual humility. We only perceive a 100,000 node environment as vast and complex. For people who think at the scale of galaxies, that’s not even a speck.

The Possessed Machines
How can you not admire the ambition here? The anonymous author, alumnus of a frontier lab, uses a nineteenth century novel (even if a Russian one) to analyze the ethical and social dynamics of the AI alignment community.

The essay compares frontier AI researchers to the radicals in The Possessed who let intellectual hubris trump moral sense, unleashing catastrophe on a Russian village. It’s a great read, if a disappointing one. Many AI researchers will be asking themselves “Which character do I resemble?” this week, but the author avoids the core issue by conflating effective accelerationism with tech-pragmatism.

Yes, some researchers put e/acc in their .sig files and believe in the fastest possible technological innovation for its own sake because it accords with the laws of the universe. Many more people are techno-pragmatists, who fear free societies losing the AI race to a totalitarian or authoritarian regime.

The author glosses over rather than engages this argument. He or she never wrestles with the relative risk of AI catastrophe versus losing the AI race.

Let me add one final question. What if the AI risks aren’t us all getting turned into paperclips? Maybe we should worry more about AI changing us than about AI destroying us? Human connection requires negotiation and compromise. Even your closest friend might not want to talk about what you want to talk about at the moment. We’ve all seen how sycophantic chatbots can be. At what point might users avoid the world so they can lock themselves inside and engage with eager-to-please virtual personalities?

Vitus Reflux may be the lowest stakes episode of Star Trek ever. Luckily, it’s also a lot of fun, Space.com
Yes, I tend to overanalyze television shows no less than I overanalyze everything else. I once wrote a Facebook post about why it would be so unrealistic for Frank Underwood to serve as majority whip that caused some amusement within McKinsey.

And yes, my reading queue is endless, but sometimes you have to try to shut your brain off, so I watched Starfleet Academy, Episode 3. [8] But because I can’t shut my brain off, I had a question.

One of the characters said that many of the students grew up hungry because faster-than-light travel became impossible (again!) for some number of years. Does the logic work? Let’s say you have a interstellar civilization with FTL. Would they really ship bulk foodstuffs between planets? That sounds economically impractical, except where you have a tiny number of people doing something economically vital in a remote location. Generally, you don’t ship foodstuff by air today, but it might work to re-supply workers on a oil rig, for example.

Or maybe most people eat food produced in industrial scale replicators, and you have to ship some incredibly dense fuel for the replicators (or some other high-value, low-mass part of the nanotechnology supply chain) between planets. Maybe they should explain their thinking here? Maybe the folks in the writers room need to think more about interstellar logistics? Or maybe I should relax and remember it’s a TV show?

Footnotes

[1] McKinsey taught me clear communications. Back in the summer of 2000, I was on a project to do an OSS strategy for a Competitive Local Exchange Carrier. (For our younger readers, the 1996 Telecom Act...oh never mind.) Shortly before a meeting with the CEO, one of the partners asked me what I was going to say. I started to ramble. He intejected: «Stop. That’s bad. You need to structure what you’re going to say. Here’s a simple framework you might use: what you need to know, what you need to do and what you need to decide.»

Good advice. Yes, corporate culture has evolved a bit in the ensuing two-and-half decades.

[2] Ironic, isn’t it? After decades seeking to shorten engineering cycle times, now we need to lengthen (part of) them.

[3] I’m so out-of-date, I asked myself: “Hmmm. Maybe I should be using Hungarian notation?”

Here is what Gemini said in response to this footnote: “Regarding your second footnote: please, for the love of all things holy, do not go back to Hungarian notation. If the AI is writing the code, let it use modern, expressive naming conventions.

[4] If you’ve ever read the book Blind Man’s Bluff, that’s what my colleague did in the Navy.

[5] Walter Munk was essential to planning for D-Day. He also invented the science of surf forecasting.

[6] If you believe Michael Lewis about making money in debt markets, maybe I should have been a bond trader? Separately, I got to know the person who supported the “The Human Piranha” on technology. Can you imagine what he must have been like as a business partner?

[7] For those not fortunate enough to grow up in the US in the 1970s, Reese’s used to run commercials in which one person eating peanut butter and one person eating chocolate would get mad after they crashed into each other and contaminated each others’ snack. “Your peanut butter is on my chocolate,” one would accuse. “Your chocolate is in my peanut butter,” his antagonist would reply. They soon realized they had discovered “two great tastes that taste great together” – hence the Reece’s peanut butter cup.

[8] The dialogue wasn’t as horrific as it is in, say, Star Trek: Discovery. You recall Harrison Ford’s retort to George Lucas, “George, you can type this @#$%, but you can’t say it?” The Discovery writers’ room made George Lucas sound like David Mamet.