Vibe coding doesn’t eliminate the physics of software development

So where will the strats come from?

History informs, but it does not instruct. Herbert Butterfield could not have known of modern tech-utopians when he warned of history as a monotonic progression leading to the current day in The Whig Interpretation of History. There are no obvious answers in history, as French planners learned in June of 1940 -- they had studied Verdun and learned its lessons too well.

How much should individual and collective past experience -- about software development practice and about enterprise technology operating models -- teach us about how to thrive in the agentic future? We can’t answer that question prima facie, but we can use experiences to shape the experiments that will help us here?

The main argument: Where will the strats come from?

---

What you need to know: As powerful as agentic development is, it only abstracts away syntax and reduces toil; it doesn’t eliminate the physics of software engineering

What you need to decide: Where your company will find its strats, specifically will you teach operators how to use agentic coding tools or will you teach engineers about business domains? Or both?

What you need to do: Get the strategy and model in place for using rules to shape agentic development activity in place now -- this is an opportunity to enhance your ability to enforce architectural, security and coding standards

---

What does tech is part of the business mean? Historically when business leaders say that they mean “application developers should work for me; I will spend money on new features rather than platforms; and I don’t care about technical debt. I will create as much of it as I want, as I expect I will be on to the next role by the time the bill comes due.”

I become a strat!

I never expected I would become part of the problem. Let me be more precise: I never expected any tool would become so capable that I would decide to pick up writing code in a professional context for the first time since Ross and Rachel were on a break. A few weeks ago I wrote that AI would mean junior knowledge workers would become strats (in that they would blur the line between engineers and domain experts) and senior knowledge workers would become like Winston Churchill (in that they would have access to intellectual leverage only available to giants in the last century).

Maybe I understated the case -- maybe all knowledge workers will become strats. Which would have two implications for CIOs and CTOs, one straightforward and one that will be very challenging.

I have been astounded by what Cursor and Claude Code can do. I started out porting a little spreadsheet model of enterprise technology economics I had built to make it more robust. It has morphed into the economic model that I have wanted to build for two decades -- it can capture a flexible baseline, model an optimal cost structure and build a transformation program out of a library of improvement initiatives. And I am having a blast.

You could argue that my experience demonstrates why blowing up the dividing line between business domains and software engineering is so powerful. At many times in the past week or two I have asked, “hmm...wouldn’t it be cool to do this?” in a way I always used to as a teenager banging away on a C64. And in a way that engineers in enterprise technology functions rarely get to do: “Why are you building something not on the backlog.”

Agentic coding has its own complexities

And yet, there are complexities. After Claude’s inability to fix a glitch in calculating deadweight loss, I threw up my hands and asked it to review the history.md file I had instructed it to create, think about it carefully and suggest ways we could work together more effectively. The response fascinated me:

Claude acknowledged the sources of my frustration

• Suggesting single fixes without considering all potential causes

• Fixing one metric while leaving another broken (build cost)

• Not updating history.md immediately after changes

• Being reactive instead of comprehensive

It promised to change its behavior by updating its configuration file.

• Read all relevant docs (history.md, equations.md) first

• List minimum 3 potential root causes before investigating

• Trace complete data flow (user input → frontend → API → backend → UI)

• Identify all impacted metrics, not just the broken one

• Search for similar patterns in codebase

And also test more thoroughly

• Test every impacted metric (not just the reported bug)

• Verify against source of truth (app.py, equations.md)

• Test both Year 1 and Year 5 (different code paths)

• Check edge cases (0%, 50%, 100%)

• Verify formulas don’t cancel out

Using rules to shape agentic software development

Software development 101, no? Practices I more or less figured out as a thirteen-year-old. I hadn’t instructed Claude Coude to do this, because I assumed it shipped with these instructions. In fairness the agentic coding space is moving at the speed of a hopped up Camaro down the Jersey Turnpike at 3 am. Consolidation and refinement will follow innovation. In the meantime, I started to think more seriously about the Cursor and Claude rules I wanted. I enter most notes into my Obsidian database via the Cursor agent, so I created cursor rules to check different variations of the same name (e.g. Mike versus Michael) and to search for relevant hashtags and links when I entered a note. Realizing that even if I wasn’t writing code, I had been burning a lot of time as a user acceptance tester, I asked to replicate each screen it painted in the browser in an markdown file it could read. I will also provide it with the heuristics I used to validate output — check that, I will ask it (as a first pass) infer those heuristics from the feedback I have provided and it has tracking in history.md.

What CIOs and CTOs need to get right

There are two implications for enterprise technology

1. Agentic configuration will become existential. Yes, the providers will get better at mandating standard good practice, you will need to define the rules for documentation, abstraction, portability, security and readability. And you will need to apply change control of configuration files -- you don’t want some enterprising engineer ripping all the security standards out of your rules file. The good news? You will gain much more control over how code gets written.

2. You need to figure out where to get the strats from. Many assume that operators will learn how to code with agentic coding tools. It may be easier to teach software engineers (who tend to be pretty curious people) about the business domain than it will be to teach operators how to use agentic tools, despite what many assume. Agentic development abstracts away syntax and reduces toil; it doesn’t eliminate the physics of software engineering. My ability to leverage Claude Code, though growing daily, is a pale shadow compared to that of someone who has been doing front-line engineering the past decade. Many tough decisions lie ahead in talent management for large enterprises.

Throwback Thursday: no, we didn’t always have agentic development tools -- we didn’t even always have data structures

I like to joke to the Padawans here at **[McKinsey Digital](https://www.linkedin.com/showcase/mckinsey-digital/)** that if DOS 3.3 comes back I can wipe the floor with them. That’s not remotely true — I am sure they would learn everything there is to know about DOS 3.3 and immediately hand me my backside — but I like to say it anyway. Still my one great programming triumph using technology one step from an abacus causes me to reflect a bit on, as **[Zubin Ghafari](https://www.linkedin.com/in/zghafari/)** likes to remind me, how much of the problem solving method in technology stays the same. But also: which problems that bedevil us now (like the one I wrestled with below) will not even be trivialities in thirty years.

The question my experience raised about agentic development

Here’s the question my recent Claude Code experience raises for me: Imagine the patently ahistorical scenario of having access to modern agentic coding tools to develop an application to run in an interpreted language with no native data structures on computers with 16-bit processors. Would the tool have come up with the creative solution I did (or something even better) -- or would it have concluded you could only put a few hot spots on the screen because that’s what everyone else did? Absurd as it is, that’s an important question for us to contemplate over the next few years as we sort out the working model between human and machine.

A quick GUI on a 286 wasn’t easy

After college I worked for a little company that did demos, on-line catalogs and tutorials. In this era on-line catalog meant “arrives on a floppy disk” — not “get on the internet and go to a URL.”

My boss announced a new project to me — we had to create an “on-line” catalog for a business software company. We had to create a GUI that will allow the user to select a software package and display a couple of paragraphs of descriptive text and see maybe 2 screen shots. This was 1993, so there was no click to order or anything like that. We might have included the (landline!) phone number of the sales contact in the descriptive text. It had to run on machine with the following specs: DOS 3.1 or higher, standard VGA -- 640x480x16, a 720Kb floppy and a 286 processor.

What luxury! VGA instead of EGA! Assumption of a 286, rather than an 8086 processor! And 720K rather than 360K of disk space. I felt like I was living in the future already.

Creative abstraction has always solved problems

And we’d write it in [Grasp 3.3](https://www.aftergrasp.com/). I had come to love Grasp 3.3 after initially hating it. What type of language I asked doesn’t even support arrays? Well that explained why my colleagues’ code was so bad. How can you perform any abstraction without any data structures at all?

Then I discovered that Grasp supported infinite levels of indirection. Via text concatenation and indirection I could create n-dimensional arrays, complex data structures and linked lists. Hell, I could create pointers to functions (actually procedures, but still..) I had created a whole library of lower level routines to handle this stuff. My colleagues knew to invoke these routines, but never ever alter them. That would lead to a fight.

But there was one problem: Grasp was interpreted, so mouse operations were slow. The Grasp manual advised against having more than 5 or so clickable spots on one screen. As Compute! Magazine taught us in the early 1980s, if/then operations are slow. Using if/then statements to evaluate whether the pointer was within one of 30 boxes on the screen would grind the user experience to a halt.

Conceptually, I divided the 640x480 screen into a grid of 32 blocks by 24 blocks. So:

• When I created the bitmap of the screen the user would see (this is how we used to roll in 1993), I aligned each clickable hot spot with the edges of cells in my grid. So the first icon to click on was at location (4, 3). Assuming the origin was at the top left of the screen, that would translate to a mouse coordinate of (80, 60). And I made sure each icon was 20 pixels high and wide.

• I created two 32 x 24 arrays, one with the appropriate procedure to call (we set up the screen differently for some of the products) and one with the product code

• I grabbed the x and y coordinates for the mouse click and used a division and an INT operation to translate them from a 640x480 screen to my 32x24 grid. So if the user clicked at spot 83, 65 then INT (83/ 20) produced 4 and INT (65/20) produced 3

• Then I looked at spot 4, 3 in my procedure and product code arrays. That told me to call the procedure “DisplayScreen1” with parameter “1010”

• The “DisplayScreen1” looked at the variable Description1010 to find the relevant text to display

All very prosaic (even for 1993) but it flew. No if/then logic. Just a couple of math operations and then a few array lookups.

The client was happy. The Grasp discussion group on CompuServe was scandalized (“How the hell did they do this?)

A few days later, a very nice woman from the company that published Grasp called me (on a landline!) and said Gary (I think that was his name) who lead the Grasp development team wanted to speak to me to hear how the hell we got Grasp to handle so many clickable spots on one screen with no latency.

I asked my boss about this. He insisted we demur. It was our trade secret.

Fair enough — but in terms of writing code, it was all downhill after that for me. At least until I discovered Claude Code!