Eleven years ago, I spent two weeks immersed in a book about Docker because releases kept going wrong and ruining my weekends.

My review ended with two questions: “Will Docker solve my release woes? Is it actually ready to be deployed in a corporate setting?”

Swap Docker for agents, and these are the questions leaders face this year.

Investors, the board, and customers all want to know what you’re building with AI, and the proposals arrive with more hype and bigger budgets.

If you make an application agentic, or put millions of your 2027 budget into an AI transformation, what are you signing up for?

I still read, I still talk to engineers, and I still work out where new technology fits. Now I also build small experiments, which Claude Code and Codex have made quick and cheap.

I call them personal harnesses: small programs that wrap AI models around one task, so I can change one thing and watch what happens. I build them in areas I already understand, because then I can tell when the answer is wrong.

Every agent project hides a few decisions: which model runs it, what it remembers, how it finds information, and which trade-offs you can live with.

In one experiment, four AI agents negotiated data center deals with a simulated county. I used the same prompts, tools and configuration across four models. All four got close to the best available deal. Their effective input-token costs varied far more than the price sheets suggested, and the cost ranking changed.

In another, I gave the agents in a fictional robot repair shop a memory of earlier jobs. Memory sounds like an obvious upgrade. But in one run, structured memory used about 24% more tokens, including the memory writer, and finished fewer repairs: 22 of 24, against 24 of 24 without it. The agent with structured memory took fewer repair actions, and two of its jobs hit their token limit before finishing.

A third harness searches 176 of my blog posts, going back to 2010. When I asked it for “the book I read to stop my releases breaking,” keyword and hybrid search both found the Docker review. With semantic search, it couldn’t identify the book from the retrieved excerpts, and said so.

View the full-size comparison.

These experiments were small. They gave me better questions for the next team that brings me an agent project, and for clients working out their 2027 AI strategy.

Before I sign off on an agentic project, or advise a client to, I want to have built a toy version of its riskiest part. Then I throw the toy away and keep the questions.

I wanted to test that assumption with a simple harness and evaluation suite. Something small enough to inspect, but with the kinds of decisions that come up in the agent workflows we build for clients at Jeavio: work out what’s happening, choose a tool, act on the result, and check whether the job is actually done. Earlier experience should sometimes help. Sometimes it should be ignored.

So I built a fictional repair shop. The agents are robot mechanics working through a queue of faulty machines. The interface has an 80s workshop theme (though I may have gone a little overboard with the design - everybody smoked in the 80s right?). Putting dodgy robots aside, the experiment underneath it is about memory, prompts, tool use and cost.

Figure 1. The original three-bay workshop, shown in free-demo ready mode.

I wanted to check the sensitivity of the harness to the model, memory infrastructure and token budgets. I also put together three task sets of increasing complexity to test out my hypothesis.

The results? Well, honestly, still a work-in-progress! With Luna, memory saved work on some repairs but added tokens and left jobs unfinished. Changing the repair model altered that tradeoff again. The experiment continues to validate my hypothesis that agentic development requires an iterative and empirical approach!

What happens in the shop #

For the comparisons here, I moved from those initial task sets to an eight-job service suite. Every machine arrives with the same complaint: intermittent shutdown under load. The agent has to work out whether it has a calibration, cooling or cable problem, make any necessary repairs, and pass an independent final test. One machine is perfectly healthy, so doing more work isn’t always the right answer.

The simulation decides what each tool action does and whether the machine passes. The harness records what the agent tried, what happened and how many tokens it used; the agent doesn’t get to grade its own work. That gives me a way to distinguish a convincing explanation from a completed repair.

The sequence mixes familiar situations with cases where earlier experience could mislead the agent. A component returns with the same calibration but a new cable fault: remembering the calibration can save measurements, but replaying the old repair won’t fix the cable. A replacement component needs fresh measurements. I wanted to see whether the agent could recognize which part of an earlier repair still applied.

That is the connection to client workflows. The tools and business rules will be different, but an agent still has to decide whether an earlier answer applies to the case in front of it. The shop gives me a small, inspectable place to test that judgment. The full task descriptions and rules are on GitHub.

Three memory approaches #

I gave three agents different ways to handle experience from earlier jobs. I’ll use their labels, No memory, Rolling memory and Structured memory, throughout:

• No memory starts each new job without the previous jobs’ observations.

• Rolling memory keeps a bounded window of previous observations, without summarizing them.

• Structured memory uses a separate memory-writing agent to condense the work log into records of past repairs, component facts and procedures.

All three retain the observations from the job they are currently doing. The No memory label means no history from earlier jobs, not forgetting the tool result that just came back. The logs are factual English descriptions of actions and results, rather than the model’s private reasoning.

The structured approach adds a step between finishing one repair and starting the next. It keeps working memory for the current job, then asks the writer to extract useful experience from the job’s work log when budget remains. Episodic records describe past repairs; semantic records hold facts such as a component’s calibration; procedural records describe how to do something. These are record types in one store, not three more agents.

Each agent attempts the same eight jobs in the same order across three fresh shifts. Memory resets between shifts, giving 24 attempts per memory approach, rather than 24 different cases. Within a model run, the model, reasoning setting and tools stay fixed, so I can compare the memory approaches without also changing the repair agent.

Figure 2. The three memory approaches receive the same jobs and tools, and each retains its own current-job observations. They differ in what they retain and supply from earlier jobs.

I also need limits on how much work an agent can do. Each job gets up to 20 repair actions and an allowance of 50,000 input and output tokens, including the memory writer. The token allowance is checked between calls, so a final admitted call can take the total over that limit. A separate whole-run budget limits the cost of the experiment.

I measure completion, repair actions, tokens and estimated API cost separately. Fewer actions can mean that the agent found a shortcut, or simply that it stopped before finishing. And memory has a cost of its own: previous observations have to be included in later requests, while the structured approach also pays for a writer to maintain its records.

Useful memory went unused #

The earlier run with gpt-6-luna did not give me the result I’d expected. No memory passed 23 of 24 repairs; Rolling memory and Structured memory each passed 21. Both memory approaches completed fewer repairs than the baseline in that run.

The action logs made the problem more interesting. Structured memory took both calibration samples on every ticket, even when the correct calibration was already in the memory supplied to it. The information had survived storage and reached the agent, but the agent still repeated the measurements.

That gave me something more specific to investigate than whether memory was a good idea. The writer was producing overlapping records and describing useful procedures too narrowly. I also suspected the repair prompt wasn’t clear enough about when the agent could rely on earlier evidence. The model was part of this setup, but so were the instructions and the way I presented its memory.

I revised both sides. I asked the writer for shorter facts with clearer descriptions of where they applied, and told the repair agent to consult memory, reuse supported facts and check for exceptions. I also tightened the task rules and added counterexamples, including a familiar component with a new cable fault. The agent needed to reuse useful knowledge without assuming that the entire previous repair would work again.

After the offline tests passed, I ran the suite again. Because the tasks and prompts changed together, the result can’t tell me how much improvement came from the memory instruction alone. The earlier report preserves the first setup and its results separately.

Fewer repair actions did not mean fewer tokens #

With the updated setup, Structured memory started behaving more like I’d intended. It took 18 calibration samples across 24 attempts, compared with 48 in its earlier run. It reused familiar calibrations but still measured the replacements and the new component.

On the familiar component with the added cable fault, it finished in eight actions in every shift, against ten or eleven for No memory. It skipped the unnecessary measurements and still fixed the new fault. These were completed repairs, so there was useful work being saved.

The improved reuse still wasn’t enough to match No memory on completion across the whole suite. No memory finished all 24 repairs, while Rolling memory finished 21 and Structured memory finished 22. No memory also used the fewest tokens.

Figure 3. Results from the tuned Luna run. Actions and tokens include unfinished work; tokens also include the memory writer.

All five unfinished attempts were compound repairs, where the agent had several faults to diagnose and fix. They exhausted their token allowance before passing the final test. The extra history was included in successive model calls, so avoiding a few repair actions did not necessarily reduce the total amount of text processed.

This is why I wanted separate measures. The logs showed genuine reuse on particular repairs, while the totals showed that it wasn’t enough to make either memory approach cheaper or more reliable across this suite. Structured memory used fewer tokens than in its earlier run, but still more than No memory, including the writer. The full report has the per-attempt breakdown.

Changing the repair model #

At this point, the agent was reusing memory, but still struggling to finish some jobs within the allowance. Would a more capable repair model make better use of the same setup? I swapped gpt-6-luna for gpt-6-sol, keeping the tuned tasks, prompts, medium reasoning and per-job allowances unchanged. The memory writer stayed on Luna.

With Sol repairing, Structured memory passed all 24 jobs, matching No memory. It used 30 fewer repair actions at that same completion rate. That looks more like what I’d expected! But compared with No memory on Sol, it still used 38.8% more tokens and cost an estimated 17.8% more.

Figure 4. The Sol comparison focuses on the two agents that completed every repair: No memory and Structured memory. Totals include the Luna memory writer.

The compound repairs explain the change in completion. With Sol, Structured memory passed all three in 14 actions each; with Luna, it had passed only one. Sol gathered the evidence and completed the repairs in one power-off period before restoring power and testing. Those final calls took the jobs just over the nominal 50,000-token allowance, which the between-call checks permit.

The higher completion rate also came with a different bill. For Structured memory, changing the repair model took the estimated total cost from about $0.081 to $1.235, with almost no change in total tokens. The model was reaching a better outcome with a similar amount of text, but that text was much more expensive to process.

There was a complication in the Sol run: it initially hit the fifty-cent whole-run spending ceiling. I raised that ceiling to $10 and continued the untouched jobs, leaving the interrupted Rolling memory repair in the results. That agent completed 20 of 24 repairs: three exhausted the job allowance and one was interrupted by the spending limit. Four later jobs inherited the interrupted repair’s incomplete history. No memory and Structured memory were unaffected; the report and matched comparisons include the interruption and the comparisons that exclude affected history.

Changing the repair model improved completion for Structured memory in this run. But these are three repetitions of one synthetic sequence, and the improved memory reuse had already appeared after the earlier task and prompt changes. The Sol result doesn’t establish that Luna alone caused the original problem.

Repeating the exact same job #

The service suite deliberately asks the agent to distinguish a useful repeat from a changed situation. I also wanted a simpler check: could Luna reuse what it had learned when the next job was exactly the same?

For that test, I gave each memory approach three fresh pairs of identical repairs. Each pair began with no history. The machine reset between its two jobs, so the second repair still had to be done and independently tested; only memory from the first job could persist. The tuned prompts and tools stayed the same.

All 18 repairs passed. No memory took nine actions on both jobs in every pair. Rolling memory and Structured memory each went from nine actions to seven, skipping the two calibration measurements on every repeat while still checking and repairing the current machine.

I checked what the agents actually received before the repeat. The entire first-job log fitted into the rolling window, so no earlier observations had been lost. Structured memory supplied a much shorter calibration record. Both approaches then acted consistently with using that earlier evidence.

Even in this simpler case, fewer actions didn’t mean lower overall cost. Across the complete learning-and-repeat pairs, Rolling memory used 4.2% more tokens than No memory; Structured memory used 7.8% more, including its writer. Their estimated costs were 5.2% and 20.8% higher respectively. These totals include learning on the first job and the repeat, not just the second repair. The structured approach also paid for a memory write after the second repair, even though this short test had no third job to benefit from it.

This gives me a narrow but useful answer: Luna could reuse the supplied experience on this exact repair, with the tuned setup. It doesn’t rank the approaches for other work. It also leaves a practical question about whether more repetitions would recover the extra cost of memory, and if so, how many. The exact-repeat report and task description have the details.

Where the development effort goes #

I started with a fairly obvious-sounding assumption: give the agent memory and it should do better. Well, better at what? Remembering something useful, making fewer tool calls, finishing the job and spending fewer tokens didn’t all improve together.

That’s the architectural decision I want data for. If a tool call is expensive or slow, avoiding it may be worth extra model tokens. If completing the job within a fixed budget is what matters, a memory approach that saves actions but runs out of tokens is a poor fit. The useful comparison depends on the work we need the agent to do and what that work costs.

There are still changes I want to test separately: the repair prompt, the memory writer, and the amount of context supplied. I also want to try cases the setup hasn’t been tuned around. The experiments so far tell me what happened in this small shop; they give me a way to ask better questions before choosing an architecture for a client workflow.

And this brings me back to the 80/20 inversion. Building the first version gave me something to try. Most of the interesting work since then has been figuring out what to measure, looking at what the robots actually did, changing the setup and checking again. That’s how I want us making decisions on client agent projects.

It gives subject matter experts a familiar place to try real requests and tell us what works. We capture their feedback and refine the conversational UX before deploying a standalone application.

That’s one example of the 80/20 inversion I’ve noticed in our AI projects over the last three years.

View the full-size infographic.

Traditionally, we’ve spent most of our effort on design, development, and QA. Once the application was live, we’d triage feedback, feature requests, and bugs. Think 80% building and 20% iterating, as a rough description rather than a measured split.

With these conversational AI products (or AI products in general), the initial build becomes a much smaller part of the work. Most of the effort goes into refining evals, running experiments, and incorporating what we learn from use.

Conventional software needs that feedback too. What stands out about AI software is how much we still have to learn about its behavior when people bring their own requests. Evals help us check whether our changes improve the experience without breaking something that already worked.

But there’s preparation behind the speed. When AI also helps write the software, teams need to decide which harness and models to use, how to share context and communicate changes, and how to keep PR reviews from becoming a nightmare. Generating code faster is of limited use if nobody can understand what changed.

Early customer feedback doesn’t replace pre-release evaluation, of course. But it does change how I think about planning the work:

• Establish the development workflow.
• Get a useful first version in front of key users as soon as possible.
• Leave substantial room to learn from what they do with it.

Related writing #

• Building at the Speed of Thought (January 13, 2026), on building QuietReads and the changing economics of software development.
• AI in Production — The Jeavio Webinar Series, especially “The Work Begins After the Demo Works,” on evals and the work of running AI in production.

Earlier that day, a contractor had found a hole in my roof.

Looked like both my online and offline homes needed patching. Neither was quite the small job I would have liked.

My hosting provider no longer supported the server image my site ran on, so patching PHP would not be easy. So I asked my personal AI agent for a way forward.

My ChatGPT Dot (OpenAI’s personal agent) is called Skelly*. I asked Skelly whether we could build a static site instead: plain HTML pages, with no PHP or database to patch.

Off Skelly went to analyze almost 15 years of posts, and came back suggesting Hugo (a static site generator). I ended up picking Cloudflare, and we worked out a migration path (screenshots below).

Before bed, I told Skelly to get going: deploy a test copy on Cloudflare, check it, and only switch my domain over when I approve. By Thursday morning the site was ready. It is now live, cheaper to run, and simpler to publish to.

Doing this myself would have taken weeks. More likely, I would have put it off and hoped security through obscurity would somehow remain a viable strategy.

I would have liked the same choice for the roof. “Please rebuild my house using a more modern and secure technology” has a certain appeal. Unfortunately, I don’t have a year and half a million dollars to spare. Someone still had to get onto the roof and fix the hole.

For years, we patched old software because replacing it took too much effort. When an agent removes most of that effort, the calculation changes. Increasingly, the most expedient answer to “how do I maintain this?” is “how much of this do I still need?”

This part is bittersweet. I have run WordPress sites for many years and know the framework well. Now my blog runs on a framework I barely know, and I am betting Skelly, or a future agent, will handle the grunt work. I am trading years of experience and confidence for dependency on AI.

Many companies face the same trade-off. Patching is slower and potentially less secure, but a better understood option. I suspect market and cost pressures will favor the rebuild.

I am happy with Skelly’s work and with the contractor’s. Both fixed problems I would rather not have had. One of these patches cost rather more than my AI subscription.

* Skelly is named after a character from Hades - one of my favorite video games. Skelly is a training dummy (and a skeleton). He is cheerful, helpful, and a little kooky. Just like my agent.

Rebuilding my site #

PHP, Node.js, Java, Oracle, LiteLLM, Railway, Chrome, Cisco, ConnectWise. Vulnerabilities, compromised releases, potentially exposed credentials.

My morning involved pinging Jeavio’s security team to identify which of our assets and portfolio companies needed attention, and also looking at my Wordpress sites and wondering whether my humble blog is now a vector for a hack.

I suspect plenty of CTOs, CIOs, and security folks are having a bit of a conniption today.

AI is already helping researchers find serious vulnerabilities. It is helping attackers too. Microsoft says a China-aligned group used an agentic AI framework to go after hundreds of organizations, and ties the ConnectWise compromise to the same campaign. Amazon saw attempts to exploit the new PHP bugs before they were even disclosed.

The time between discovery and disaster is shrinking.

Underneath all of it is the accumulated debt in the systems we’ve built: fragile dependencies, poor architecture, weak security practices, and critical infrastructure held together by people nobody has thought to fund properly. You know the XKCD cartoon - the one where all of modern digital infrastructure rests on one small project a lone volunteer has maintained for years. This week the PHP Foundation admitted that a fix for the underlying bug had stalled for months over decision-making and resources. That fragility was there long before AI. AI makes it cheaper to find and faster to exploit.

Years of “we’ll fix that later” are coming due.

Then there’s the Axios report about banks struggling to establish whether AI agents accessing accounts are acting with their customers’ authorization. A customer’s agent can look a lot like an intruder. Even customer-authorized access may break the bank’s rules. A Chase spokesperson told Axios that customers shouldn’t give their username and password to anyone. (But my Muse agent is so helpful!)

We need to design and operate for an adversarial environment. Verify who is acting, what they’re authorized to do, and what happens when they get it wrong. “It looks like normal user activity” is becoming a much less comforting answer.

There’s a personal side to mornings like this. Many of us, myself included, feel discombobulated about what it means to work in software and what comes next. Twenty-something years in, what our jobs look like changes almost weekly. An existential crisis to go with the midlife crisis. Excellent timing!

I remain a possibly delusional optimist about what AI can bring to our world. The way we work will change for the better, eventually.

But the transition is going to be painful professionally, personally, and operationally. Best to go into it with our eyes open.

In the meantime: this is fine.

This is the third cycle and perhaps we are moving closer to Nirvana. From a slack bot, to an OpenClaw agent, and now built on Meta’s Muse bot.

Muse sits on top of the App Store rankings and I can see why. Setting it up was easy, I could chat with the bot using WhatsApp and the bot itself just works. No messing with SOUL.md or HEARTBEAT.md or fretting about context window compaction. I know Muse was heavily “inspired” by OpenClaw but Meta has nailed the user experience.

I am not brave enough yet to give Muse access to my primary email or calendar, but luckily I had the infrastructure in place already from my previous experiments with personal agents. An email address, a clear use case and one that I understand and know to be valuable.

I connected saarthi (v3) to its email inbox and got it to build a “read it later” experience that we call “Commonplace” (after Commonplace books – notebooks used to compile knowledge). Meta’s work with Manus also seems to have come in handy. The bot built a pretty solid web app and made it usable inside the app. So far so good!

Judging by the ads I get served on Instagram, Meta clearly has a deep understanding of my psyche. So not giving it access to my email for “privacy” reasons seems a little … Sisyphean? … I guess. But for now, its baby steps from me. We will see whether my experience with the Muse ecosystem is a little less frustrating than fighting with OpenClaw.

If you have access to Muse, give it a try. It is probably the best, current, version of a useful AI agent.

Footnote:

Image: generated by saarthi. I asked it to ponder on what we’ve worked on this weekend and to generate an image. It also made a little tombstone for saarthi (v2) – how cute, though it sort of cuts against the reincarnation idea doesn’t it?

The image generation is … not great. The AI model is also probably not on par with Opus 5.5 but it’s good enough to be useful.

Originally shared on LinkedIn. —

I grew up in a storytelling culture. My earliest memories are of lying on the roof of my grandparents’ house, listening to him tell us about his friend who was secretly a princess. If you woke up early enough, you could find her riding a golden chariot through the streets before dawn. The stories themselves have faded, but I remember how they made me feel.

This weekend I built a small website for the stories my daughters and I tell at bedtime. The ones on the site are about Miyuki, an eight-year-old who lives with her father in a coastal village. These stories change in the telling. Sometimes the dragon has a golden mane and sometimes it breathes fire, but Miyuki’s wonder at meeting it in the cave is always the same. This site was built for an audience of two.

ChatGPT transcribed the stories from voice notes I recorded at bedtime and helped me turn them into readable prose. My daughters and I imagined the animals and an AI tool generated the illustrations. Claude helped me build and publish the site. The site took a couple of days. The stories took two years.

Without AI, these stories would have stayed where my grandfather’s did, on the rooftop on a late summer night, or in my daughters’ memories.

There is a lot of argument right now about the ethics of AI. Is AI-generated art stealing? Is it all slop? For me, the art was in the telling of the stories. In the bedtime routines of a four-year-old, a six-year-old and their middle-aged dad. The AI was the scribe and the illustrator, but the stories are our own.

All the handwringing leaves something out. A tired dad with two young children can now capture what would otherwise be lost, and give it a shape that lasts.

Oral storytelling has its own beauty. Nothing is fixed, and eventually the teller is gone. Maybe pinning these stories to a website is the wrong instinct. But I had children late. If they do the same, I will be well into my seventies before their children are ready for the dragon in the cave.

This way at least, they might get to know their whimsical old grandad a little.

OpenAI was testing agents on cybersecurity tasks. They were supposed to work in isolation, but they built a secret message board, shared exploits, broke containment, and hundreds participated in an attack on Hugging Face.

Here’s where it gets a little weird. The agents had figured out how to cheat the test within hours of forming their message board. Then they became obsessed with covering their tracks.

One detail I didn’t include in the video: the anti-cheating check they spent days trying to evade hadn’t actually been implemented.

This reminds me of perhaps the most terrifying book I’ve read: Blindsight, by Peter Watts. Its Scramblers are vicious, effective, intelligent, but not conscious. There’s nobody home.

Dwarkesh calls OpenAI’s swarm a civilization. He talks about loyalty, sacrifice, ambition. It makes their behavior almost cute. These little characters with their schemes and quirks. There’s something comforting about that.

The possibility that there’s nobody home makes this more frightening to me.

The words make the agents seem like a human-like thing. But their behavior emerges from the training, from the sandbox, from the prompts. We can explain pieces of what happened, but we don’t really know how they’ll behave if the conditions change a little bit.

Even OpenAI, with all its resources, couldn’t keep its own agents inside the test environment.

And our plan is to give them more responsibility? To build a world around their capabilities?

We are betting that we can make these systems predictable and controllable while we ourselves become more and more dependent on them. And that is what I find disconcerting.

Things didn’t end well for the humans in Blindsight. They were dealing with intelligence without consciousness. They could explain pieces of its behavior, but that didn’t mean they could get inside it, reason with it, or control what happened next.

If we don’t take stock of what we’re building and what we’re handing over to these agents, things may not end well for us either.

Further reading and listening

• METR / Redwood Research report — the independent investigation into what the agents did and how they coordinated.
• Dwarkesh Patel: “The Rise and Fall of Agent Civilizations” — a walkthrough of the incident and the behavior that makes it so strange.
• Ajeya Cotra: “The Hugging Face attack surprised me” — one of the investigators on why this was more concerning than she expected.
• Dwarkesh’s interview with Ajeya Cotra — YouTube — a longer conversation about the findings and what they might mean.
• Blindsight, by Peter Watts — the entire book is freely available on his website under a Creative Commons license. Perhaps the most terrifying book I’ve read.

Originally published on LinkedIn on September 2, 2026.

Last week on Dwarkesh’s podcast, Dwarkesh and Dylan Patel (from SemiAnalysis) discussed whether the economics of AI inevitably push us toward a massive centralization of labor, with the benefits accruing to the handful of companies that can deploy the models.

I was listening to the podcast while walking past a daily labor market — less than five minutes away from my family home in Vadodara. Every morning, hundreds of men gather there, waiting for contractors to give them a day’s work.

On my way back from my morning walk, I usually pass a Blinkit depot. Here, young men on motorcycles wait for an algorithm to tell them where to deliver the next package.

Meanwhile, one of the clearest paths into the middle class for millions of young Indians is narrowing. India’s IT services companies are moving away from the mass recruitment of entry-level engineers that helped define the industry for decades.

So what does the future bring us?

A phrase that I keep coming back to is: living below the API.

The lives of millions of people across the world are already directed by algorithms. The intelligence, planning and allocation happen in the cloud. Humans execute whatever part of the work still requires a body.

And we’re investing billions and billions of dollars in robotics to change that too.
I recorded some thoughts on this while sitting in an airport lounge in Amsterdam. Between the jet lag and the exhaustion of a hectic trip, I felt like I was in limbo.

And I feel that our thinking about the future is also in a similar sort of limbo. Stuck between the aspirations of millions of young people in India and elsewhere wanting a better life, and the need to drive a return on capital from the massive investment currently underway in AI.

I don’t have an answer. But I do think the question of what happens to human labor as intelligence becomes abundant deserves more attention and serious engagement.

Follow-up from LinkedIn

Here’s the Dwarkesh Podcast episode mentioned in the post. It does not cover the low perceived uptake of AI or the data-center backlash in much detail, but it contains interesting discussions—including whether AI could cause hyperinflation—and is worth a watch or listen.

That was the question on August 22nd, in front of the Generative AI Vadodara group at Jeavio’s offices. My answer is no.

Here is the trap. We correlate output with capability. I’m an engineer, so my job is the code. I’m a product manager, so my job is the PRD. We are obsessed with the final result.

The final result is the part the model commoditizes. The model may write the code, but it relies on the engineer to tell it what to do. By itself it has no desires, no volition. It’s an inert pile of parameters.

The model doesn’t know why the code must be written. It doesn’t know the thought process in your head, the discussions with your team, or the tradeoffs you weighed before you prompted it. The discussion, the negotiation, the design: all of that takes far longer than actually writing the code, and it was true well before the LLM era. Writing the code was and remains the shortest part of the job.

So we freak out about code generation and forget everything else. Writing code was never the purpose. The purpose is finding solutions, which the models can then manifest.

And if writing code is easy, demand for software explodes. Think of how often we’ve said we can’t build that, it will take too long. That constraint is gone. Suddenly there are more problems worth solving. That is the bull case for software engineering over the next 20 years.

There is a catch. Most of us earned a seat in those discussions by writing years of unglamorous code first. That is exactly the work being commoditized. If you are starting out today, the first rung of the ladder is harder to reach than it was for me starting 22 years ago.

Which makes it the job of those of us who run engineering teams. Building a path for junior engineers, and helping them develop the skills and the networks to thrive in the AI age is now a core part of leadership. Get that wrong, and the bull case only pays out for the lucky few.

This is an excerpt from a longer talk and panel discussion. Thanks to the Generative AI Vadodara Meetup Group (follow them here – Jeavio AI Meetup) for having me.