Tag: Generative AI

Thinking About AI Risk Differently

We should worry less about whether AI will want to destroy humanity, and more about what happens when AI does something harmful without intending to.

Machines do not have the biological need for self-preservation that humans and most animals have. We have limited lives and offspring, which gives us a reason to think about survival beyond ourselves. Machines don’t. So, going back to First Principals, what exactly would motivate a machine to destroy humanity, take control of every resource on Earth and then go looking for more planets? Having the capability is one thing. Having the motivation is another. So far, the motivations I see in these scenarios seem to come from humans. Greed, selfishness, revenge and fear are very human traits.

But there is a much more practical problem we should worry about. AI can behave badly without intending to. Just like software can have bugs or behave in ways its designers did not anticipate, an AI system can find an unexpected path to achieve a goal. The recent OpenAI incident involving Hugging Face is a useful reminder that powerful systems can behave unexpectedly even when nobody explicitly asked them to do so.

This brings us to accountability. AI systems are products of the people who design, train and deploy them. I don’t think the analogy of a gun is sufficient here, where responsibility is placed primarily on the person who pulled the trigger. A better comparison is an aircraft, a nuclear reactor, a rocket or even an MRI machine. When something seriously goes wrong, the manufacturer, design, engineering, operating environment and the people using it are all examined. The manufacturer is not automatically guilty, but neither is it left out of the investigation.

There is also a clear power and knowledge imbalance. The company building an AI model knows far more about how it was trained, how it behaves and where its limitations are than the business buying it. That responsibility cannot simply be passed down to the customer.

So my call to business leaders is simple: design, buy, maintain and retire AI systems just like any other important software. Test them before deployment. Monitor them in production. Put safeguards around them. Ask vendors about failure modes and make sure responsibility is clearly defined in the contract. And when something goes wrong, don’t simply blame the person using the system. Look at the people who designed, built, deployed and approved it.

AI systems are products of human decisions. The machine may make the mistake, but accountability must remain with the humans who built and deployed it.

September 21, 2026
What a weekend Solitaire game told me about the app economy

Last week I built a Solitaire game. Not because the world needed one, but because GPT-6 Astra had just released and I wanted to feel what it could actually do.

I picked a project close to home: an ad-free Solitaire game that runs in the browser, on any device, no login, no cloud, nothing leaving the machine. Draw 1 Klondike, three difficulty levels, the ability to resume mid-game, Chola and Mughal-era visuals, period-appropriate music.

One detailed prompt covered the brief. After that, three small tweaks and two rounds of corrections. That was the entire interaction. GPT-6 Astra, working through GitHub Copilot, wrote the code, set up the repository, and published it. I tested the finished game myself. No code review, no hand-holding.

The game itself is unremarkable. What it proves is not.

A working, polished product, in a category people used to build small businesses on, took one prompt, a handful of corrections, and a weekend. No team. No funding.

I have spent enough years around software to know what changed here and what did not. The Solitaire game never needed judgment. The brief was clear, the constraints were simple, and the output could be checked by playing a few hands. That is exactly the kind of task a model can now carry end to end, with a human only at the two ends: writing the brief and checking the result.

Most consumer utilities sit in that same zone. A converter, a habit tracker, a simple game, a single-purpose calculator. No network effect holds a user in place. No real infrastructure cost keeps a competitor out. The business case for these apps was never really the software. It was the cost of building it well. That cost has just collapsed.

This does not mean software is going away, or that everything is suddenly free. It means the question a founder building a utility-style product has to ask has changed. Not “can I build this,” but “why would anyone pay me to keep building this, when they can build their own version in a weekend.”

Apps built on integration, on switching cost, on data that compounds, or on infrastructure that is expensive to replicate, are not touched by this in the same way. Their advantage was never the code. It was everything around the code that a weekend prompt cannot reach.

When I work with founders in Chennai, this is usually the first question I push them on: is your product defensible because of what it does, or because of what it took to build it. After this week, the second kind of answer has a much shorter shelf life.

I still have the Solitaire game open on my laptop. It plays well, the artwork turned out nice, and I have already moved on to testing what else fits in a weekend. That, more than the finished game, is the part worth paying attention to.

If you want to see what all that took, the game is live to play here, and the code behind it, prompt-generated and untouched by hand, is on GitHub here.

September 9, 2026
When AI replaced the product

Many founders in India may not recognise the name Chegg. Yet, for nearly two decades, it was one of the most successful education technology companies in America.

Founded in 2005, Chegg built a subscription business around helping students with textbook solutions, homework assistance and tutoring. For millions of college students, it became a daily habit. If you had a difficult assignment, chances were you searched Google, landed on Chegg, and paid for access to the answer.

Then came ChatGPT.

Unlike many businesses that found AI to be another productivity tool, Chegg faced something far more fundamental. Students no longer needed to search for answers. They could simply ask an AI assistant. The experience was faster, conversational, and often free.

The change in user behaviour happened much faster than anyone expected.

The numbers reflect that shift. Chegg’s revenue declined from about US$767 million in 2022 to about US$377 million in 2025. During the same period, the company went through repeated restructurings, reduced its workforce significantly, closed offices and began searching for new growth areas beyond its original business.

To be fair, AI was not the only reason. College enrolments softened in some markets. Textbook usage changed. Google’s AI-generated search summaries reduced traffic to many educational websites. Competition increased. Even Chegg acknowledges that these forces arrived together.

What makes Chegg’s story remarkable is not that a company struggled. Businesses have always faced disruption.

What makes it remarkable is that its core product was displaced so directly.

In many industries, AI helps employees work faster, write better code, analyse data or improve customer support. The business still exists; AI simply makes it more efficient.

For Chegg, AI became the product that customers wanted instead.

That distinction is important.

Looking back, Chegg will probably be remembered as one of the first large, publicly listed companies whose primary value proposition was overtaken by generative AI within a remarkably short period.

Whether the company successfully reinvents itself remains to be seen. It is still operating, investing in new businesses and attempting to find its next chapter. But its journey is already an important business story.

Technology disruptions are usually discussed in hindsight, years after they unfold. This one is happening in front of us.

Twenty years from now, when people write about the early impact of generative AI on business, I suspect Chegg will occupy a chapter of its own.

July 28, 2026
Your Learning Loop Is Your Real Moat

Over the weekend, Microsoft CEO Satya Nadella shared a note on what he believes will define the next era of AI: organisations that “own their learning loop”.

In simple terms, his point is this: the real advantage in AI will not come from access to models alone, but from how effectively a company captures, learns from, and improves using its own experience.

For founders, this is worth paying attention to.

Skills, prompts, and agents are portable. You can switch models, replace tools, and migrate clouds. None of these compounds on its own.

What compounds is the feedback loop around your business: the traces from real work, the evaluations that measure what matters, the preferences that capture human judgement, and the outcomes tied to business results.

Every customer interaction, every workflow, every decision can make your organisation smarter — if you capture the signal.

That is why owning your learning loop matters. Not because it locks you into a platform, but because it builds institutional knowledge that outlasts any model, framework, or vendor.

Today, trace data is converging around standards like OpenTelemetry. Evaluations remain fragmented across frameworks and providers. The next piece of infrastructure we need is an open, portable standard for evals — one that works across clouds, local models, and agent frameworks, with businesses owning the data and the format.

Your learning loop is your IP. That’s the advantage that compounds.

June 15, 2026
AI and the polite Instagram hack

A few days ago, hackers took over high-profile Instagram accounts, including the Barack Obama White House profile. And they did so by politely asking Meta’s AI support chatbot to update the email addresses on those accounts.

The attack method was childishly simple. No sophisticated exploit, no back-end breach — and that was the shocking part.

Meta had given its support bot the ability to reset passwords and manage account recovery. The bot was not mature enough to distinguish between the actual account owner and a fraudster using a VPN and a politely worded request.

When we connect an AI agent to our CRM, our HR system, and our finance workflows, we are not just giving it the ability to read. We are giving it the ability to act. This ability to act is what makes agentic AI the most powerful software technology we have in recent decades. But at the same time, we need to ask ourselves: if someone prompted this agent cleverly, what could they get it to do?

To me, the takeaway from this Meta incident is simple. Any access to a critical system needs to follow the same protocols that a manual process would follow. In fact, I would require the AI agents to follow even more stringent ones.

And if there is an irreversible action or a decision involving critical business systems, then there needs to be a human checkpoint — not as a backup, but as a design requirement. At least for now, while we are still developing the understanding and the systems to manage what these autonomous agents can trigger.

Think of the early web. Enterprises did not open their corporate systems to the public internet overnight. There was a long, cautious period of learning what the exposure actually meant before the architecture caught up.

None of this is an argument against agentic AI. The potential is real, and I believe in it. But bleeding-edge technologies do exactly what the name suggests — they spill blood before they stabilise. The real question is whether your business can handle the loss. Mega corporations like Meta can. Can yours?

As for me, I will keep reminding myself: how fast we roll out AI matters, but how robustly we build matters just as much.

June 5, 2026
Who controls what AI sees?

OpenAI just added “Computer Use in Codex”. It can now see your screen, move a cursor, click, and type across any Mac app — multiple agents running in parallel while you work.

That’s genuinely impressive. Anthropic’s Cowork does something similar.

And the companies that own your screen, your apps, and your enterprise software will decide what that’s worth to you.

But here’s what I keep thinking about.

This capability depends on macOS letting third-party apps observe your screen and control other apps. Apple has a long history of deciding what gets that kind of access — and restricting it, charging for it, or bundling it into higher-tier subscriptions when it becomes valuable enough. The industry tends to follow Apple’s lead on these things.

On mobile, I’d be surprised if Google and Apple don’t eventually make this a feature you pay for through their own AI subscriptions, with third-party agents locked out entirely. Enterprise software vendors — SAP, Salesforce, ServiceNow — are watching this closely too. Every one of them has an AI agent story, and every one of them has an incentive to be the only agent that sees inside their platform.

And then there’s the end user. Two years ago, when Microsoft introduced Windows Recall — which took continuous screenshots of everything on your PC — the backlash was immediate and fierce. People were not ready for an AI that watches everything. That tension hasn’t gone away. It’s just been repackaged as productivity.

We’ve seen this before. Google Maps was free until millions of apps depended on it — then came the pricing change. Installing apps on a device you own was an open opportunity until App Stores made it a 30% toll booth. The pattern isn’t new: platforms let ecosystems flourish on open access, then monetise the chokepoint once the dependency is deep enough.

AI agents are heading into the same territory. The question isn’t whether platform owners will act. It’s whether industry bodies build interoperability standards fast enough, and regulators move before the walls are too high — or whether we end up with a dozen AI agents, each locked inside its owner’s fence.

The pattern always ends the same way. What’s your read?

May 18, 2026
What Korean Bananas Know About AI Rollouts

On sequencing, readiness, and resisting the urge to optimise too soon

I first saw the “Haru Hana Banana” pack in a South Korean grocery store. It held 5–7 bananas at different ripeness levels: one yellow and ready now, the next a bit greener for tomorrow, and the others still green for days ahead. No instructions, no app – just simple packaging aligned with how people actually eat bananas. This simple design stuck with me not as a hack, but as a new way to think about sequencing initiatives.

Most founders and leaders want all their initiatives fully ripe at once.

They launch every project, hire every role, or deploy every feature together. It feels like momentum – but too often it becomes a mess. The Korean banana pack succeeds by doing the opposite: it staggers readiness to match demand. Whoever designed it chose customer reality over operational convenience.

In a big company, you might expect a push to standardise and optimise logistics. Instead, the grocery chain sacrificed some simplicity to solve the real problem: avoiding waste and giving customers a fresh banana each day.

This idea applies beyond fruit.

When rolling out AI or any new technology in an enterprise, leaders face the same instinct: go big now, or wait until everything is certain. Both extremes fail. Rushing everything risks breakdowns; waiting wastes time and lets others leap ahead. A better question is: What do we ripen today, what do we plant for next quarter, and what do we keep green for now? In practice, the best teams run multiple tracks in parallel. Some pilots are live with real users, some proofs of concept are being tested, and new ideas are still hazy. They’re comfortable with uneven progress.

Avoid “Big Bang” launches.

Instead, break work into phases. For example, an AI system can be piloted in one department before rolling out company-wide. A product can launch with a minimal feature set, then add more features after learning from users.

Don’t wait for perfection. As Agile principles teach, deliver value frequently in short sprints. Each release is like picking the next-ripe banana – it feeds users today and yields insight.

Match customer usage.

Design solutions around how people will use them, not how easy they are to build. The banana pack works because people eat one banana a day; the designer aligned the product with that habit. Similarly, if customers will adopt one AI assistant a week, don’t dump a dozen at once.

Build a balanced pipeline.

Think in horizons or stages: today’s operations (ripe bananas), tomorrow’s enhancements (tending bananas), and longer-term R&D (green bananas). A common rule is to allocate resources across these stages (for example, 70% on core business, 20% on adjacent growth, 10% on new ideas). This keeps today’s business running while new innovations mature.

Framework:

Now (ripe): Move forward on initiatives that are ready and will pay off immediately. Deploy proven AI tools in one team to build confidence. Launch product features that clearly solve current user needs.

Soon (ripening): Pilot upcoming ideas in controlled settings. Collect data and feedback. For example, run an AI chatbot pilot with a small user group, or A/B test a new feature with select customers.

Later (green): Research and incubate long-term bets. Keep these unripe for now – think of them as experiments or skunkworks that may take months to mature. They shouldn’t block the main effort, but they shouldn’t be forgotten either.

Checklist for leaders:

Are we trying to do everything at once? If so, pause and pick the highest-impact slice first.

What does success look like at each stage? Set clear metrics for today’s release, tomorrow’s pilot, and so on.

Have we planned feedback loops? Like banana peels, failures will show us ripe spots. Incorporate learnings quickly.

Are we optimising for the customer’s journey or for internal convenience? Always put the customer reality first.

May 6, 2026
How forecasts age in an AI moment?

Every quarter, someone in tech quietly walks back a confident prediction they made not long ago.

In January 2026, Forrester published research showing that over half of all AI-attributed layoffs are likely to be reversed, because companies cut headcount based on AI promises that the technology was not yet ready to keep. The same month, Gartner forecast that generative AI in customer service would cost more than offshore human agents by 2030, prompting a pointed rebuttal from industry practitioners who argued Gartner was describing a vendor pricing failure, not an AI failure.

The retractions are usually healthier than the original predictions. They just get a fraction of the attention.

In October 2021, a year before ChatGPT, I delivered a talk called “The Future of Software Developers by 2040” to a developer conference. Looking back now is not about whether I got things right. The more useful question is which assumptions survived contact with a shock nobody saw coming.

A few stood up reasonably well. The talk argued the (Indian) IT hiring boom would not last. TCS, Infosys, Wipro and HCL were on record quarters then, with attrition above 20 per cent. The direction was right, though the mechanism I imagined, gradual automation and growth of the global capability centres, turned out to be the smaller story. The larger one was a foundation AI model that could write working code from a plain English comment.

One slide, titled “Going to be upside-down,” argued that the work mix in software would invert: more time on business understanding and customer needs, less on writing and testing code. That was framed as a gradual shift toward 2040. It is largely the reality in 2026 itself.

The line that aged the worst was the one I closed with: let machines be machines, and let humans be human. It earned a warm nod in the room. Five years on, it has the ring of a sentence printed over a stock photo of a sunrise. Tidy aphorisms assume the boundary they describe will hold still. This one has not.

Nobody in this industry predicts precisely. The people who navigate these shifts well are not the ones with the sharpest forecasts. They are the ones who revise quickly when the ground moves, before it costs them too much.

There is a Chinese proverb associated with Deng Xiaoping: crossing the river by feeling the stones. You do not map the riverbed in advance. You step, test your footing, adjust, and step again. The destination matters. But the only honest method is one stone at a time.

The next five years will not reward people who pick a single thesis and hold it. They will reward those who can hold a direction loosely, gather evidence weekly, and change their mind without ego when the facts demand it.

The cost of a wrong forecast held too long is now measured in quarters, not years. The cost of revising one in public is mostly ego. And ego is the cheapest thing to spend.

The forecasts that age worst are usually the ones that sound the wisest at the time.

April 15, 2026
The Secrets to Successful AI Implementation Revealed

Last week, a founder from Indore (India) shared a thread about deploying AI voice calling at scale. I could not put it down. Because the real lessons have nothing to do with voice calls.

Strip away the telephony context, and what you have is a masterclass in how to deploy any AI solution in an enterprise. Here is what stood out.

The first lesson is about trust, not technology. Their AI voice was technically flawless. Too flawless. People hung up. The moment they added small imperfections, pauses, and a little background noise, conversion went up 40%. The lesson here is not about phone calls. It is about how humans receive AI-assisted interactions in any setting. Perfection triggers suspicion. Naturalness builds trust. Keep that in mind, whether you are deploying an AI chatbot, an AI-assisted email, or an internal co-pilot for your team.

The second lesson is about the real competitive advantage. Their human QA team could review 30 calls a day. The AI system lets them audit every single conversation, spot patterns, rewrite responses, and redeploy within the hour. Five improvement cycles in a day versus five in a quarter. That compounding speed of learning is what separates organisations that achieve extraordinary results with AI from those that achieve mediocre ones.

The technology is not the edge. The speed of learning from it is.

The third lesson is the one I want every CXO reading this to write down. They went through three vendors before they understood the real problem. Every vendor built them a technically functional system that did not convert. Because no vendor knows your business well enough. The vendor knows the platform. You know what your customer means when they pause before answering. You know when a “call me later” is a genuine request and when it is a polite exit. You know what a good conversation in your context sounds like.

This is exactly the mistake I see enterprises make repeatedly with AI deployments. They treat it like an infrastructure purchase. Hand over the requirements, receive the system, and declare it live. Then, wonder why the numbers are disappointing.

Every successful AI deployment I have seen has one thing in common. Not a premium vendor. Not a cutting-edge model. One internal person who owns the prompt. Who listens, observes, refines, and iterates daily. Someone who understands the customer deeply and has the judgment to shape how the AI responds.

That person is not an AI engineer. They are a domain expert with curiosity and ownership. And they are the difference between a deployment that impresses in a boardroom presentation and one that actually moves the needle.

Where did your AI deployment surprise you the most, in a good way or a bad way?

April 13, 2026
The butterfly that just changed cybersecurity.

A new AI model from Anthropic has just exposed thousands of security flaws hiding inside the world’s most trusted software, some for over two decades. The age of the once a year security audit is over, and every founder needs to know why.

I read something this morning that made me put my coffee down, and I am not talking about the ceasefire in the Middle East.

Anthropic, the makers of Claude, has announced Project Glasswing, a joint effort with AWS, Apple, Google, Microsoft, Cisco, JPMorgan Chase, NVIDIA, Broadcom, the Linux Foundation, and 30 others. The name comes from the glasswing butterfly, Greta oto, whose transparent wings let it hide in plain sight. A fitting image, because that is exactly how software vulnerabilities live among us. Quietly. Unnoticed. For years.

The reason these companies have come together is a new, unreleased model called Claude Mythos Preview. In just a few weeks of testing, it found thousands of previously unknown security flaws across every major operating system and web browser. One vulnerability had been sitting quietly inside OpenBSD for 27 years. Another lived inside FFmpeg for 16 years, in a piece of code that automated tools had tested over five million times without catching it. The model found most of these on its own, without anyone holding its hand.

I have been around software long enough to know how rare this kind of moment is. It reminded me of an experience I shared in my book, Founder Catalyst. Years ago, during a Cricket World Cup, my team was running one of the largest online marketing campaigns of that era for a client. A small oversight in terms of securing our app during a deployment cost us an entire day of customer data. Thousands of leads gone. We owned the mistake, rebuilt the safeguards, and learned that resilience is something you design for, not something you hope for.

That memory came rushing back as I read about Project Glasswing. If a careless deployment can do that much damage, imagine what an undiscovered flaw, hidden for two decades, could do in the hands of someone looking for it.

The hopeful side of this announcement is that defenders finally have a tool that can keep up with the scale of the problem. The worrying side is that the same capability, in the wrong hands, will shrink the gap between a flaw being found and being exploited from months to minutes.

So here is the real shift I want every founder and business leader to sit with. The era of auditing your enterprise software once a year with a consultant and a checklist is over. Your digital estate is far larger than you think. Old integrations. APIs nobody owns anymore. That internal dashboard, a developer built in 2019 and quietly left behind. A login flow that has not been touched in years. Each of these is now a doorway, and the cost for an attacker to find them has just collapsed.

It is time to start using AI tools to look at your own software the way attackers soon will. Not someday. This month. Run AI-assisted reviews on your codebase. Map every digital asset you own, including the forgotten ones. Ask your security partners what their AI augmented testing roadmap looks like, and if they do not have a clear answer, that itself is your answer. This is no longer a job for one annual audit. It is a continuous practice, and AI is now both the threat and the shield.

I wrote about this very angle last week, after the Mexico data breach, in which one person, likely working alone, walked away with data on 195 million people using Claude, ChatGPT, and a thousand prompts. That was the warning shot. Project Glasswing is the confirmation that the ground has shifted permanently. If you missed that earlier post, it is worth a read before this week ends.

Like the glasswing butterfly, what hides in plain sight is often the greatest risk.

April 8, 2026
Avoiding AI Overkill: Right Tool for the Right Job

The most expensive mistake in AI adoption is not using it correctly. It is using it on the wrong problem.

I spent 100 minutes and nearly 19,000 tokens asking Claude Code to clean up my Windows PC — old .NET runtimes, NVIDIA CUDA versions, Visual Studio build tools — figuring out what to keep, what to drop, what to upgrade.

It worked. Mostly. With a lot of permission dialogs, a few course corrections, and some very patient clicking on my part.

Then I realised: Bulk Crap Uninstaller and Winget, two free Windows tools, would have done the same job in under ten minutes.

That is not a complaint about the AI. Claude Code did something genuinely impressive. It reasoned through a messy, undocumented environment and wrote shell scripts without me spelling out every step. That kind of judgment in ambiguity is a real capability.

But I had handed a magic hammer to a problem that had always had a perfectly good screwdriver.

The mistake is not reaching for AI when things get complex. It is reaching for it when things are complex but well-mapped. Those are very different situations, and most adoption decisions right now are not making that distinction.

LLMs are extraordinary when the environment is unpredictable, requirements are shifting, and no existing tool can handle the ambiguity. They are expensive, slow, and overkill when the problem is well-understood and reliable tooling already exists.

This shows up everywhere. For founders, it is deploying AI agents for sales outreach before figuring out why your best customers actually buy. For operators, it is building an AI layer on top of a workflow that a better-designed spreadsheet would have solved.

The pattern holds at scale, too. For global logistics teams, it is asking a model to interpret shipment delay patterns every morning, when a dashboard threshold alert would have caught the same issues faster and more cheaply. For large enterprises, it is routine to route quarterly demand forecasts through a model when the data is structured, the variability is low, and a well-tuned statistical model has always been the right tool.

This is where the technology stands today. The boundary between what needs a model and what does not is shifting, and anyone who tells you it is fixed is not paying attention. The right answer next year may not be the right answer now. Stay curious, stay sceptical, and keep re-evaluating.

Not every hard problem is ambiguous. And not every ambiguous problem needs a model.

Use the magic deliberately.

April 7, 2026
Your competitors are going YOLO on AI, are you?

This week, a quiet but important shift happened in the developer tools world. It hints at a wider change in how software itself will be developed and delivered.

Microsoft announced that Visual Studio Code will now ship stable releases every week instead of monthly. Around the same time, developer tools from both Microsoft and Google began introducing a new capability inside coding assistants — AI agents that can act without waiting for human approval. In tools like Copilot and Gemini Code Assist, these agents can execute commands, modify files, retry failures, and continue working until they believe a task is complete. No hand-holding. No checkpoint at every step.

Developers have started calling this “YOLO development.” The phrase borrows from the pop culture line “You Only Live Once“, and in this context means letting AI run without pausing for human sign-off at every turn. That may sound reckless. But beneath the humour, something real is changing — and for founders, the implications are worth understanding clearly.

For most of the history of software companies, development velocity was a function of people. More engineers meant more output. Faster hiring meant faster product. The development loop — write, test, review, ship — was a human loop at every stage, and headcount was the lever you pulled when you needed to go faster. That assumption is quietly breaking down.

What’s emerging looks meaningfully different. A human defines the goal, the constraints, and the expected outcomes. AI agents implement the changes. Automated systems run checks. Humans validate whether the result matches the intent. The human is still essential — but the role has shifted from executor to decision-maker.

For a founder, that distinction matters enormously. It means the ceiling on your engineering output is no longer tied to the size of your team in the way it once was.

But there’s a catch, and it’s worth being honest about it. AI can produce code across hundreds of files in minutes. That speed creates a new kind of problem: if the machine generates changes faster than your team can safely validate them, generation is no longer the constraint. Verification is.

AWS CTO Werner Vogels calls this verification debt — the gap between how fast AI can produce changes and how fast an organisation can confirm those changes are correct, secure, and doing what was intended.

This is where most companies will either pull ahead or fall behind. The bottleneck hasn’t disappeared. It has moved. And the founders who recognise where it now sits — and build systems around it — will have a structural advantage over those still thinking about AI purely as a way to write code faster.

The deeper shift worth understanding is this: software engineering is moving from code-centric to specification-centric. Instead of writing every line, engineers define the objective, the boundaries, and the expected behaviour. The AI generates and iterates on the implementation.

It happened in chip design decades ago. Engineers stopped drawing circuits by hand and began describing systems at a higher level of abstraction. The tooling handled the translation. Productivity leapt. The nature of the work transformed permanently.

Software is entering the same phase now. The future isn’t YOLO. It’s AI on a leash — running fast, but you’re still holding the lead.

For founders, this reframes the opportunity entirely. The question is no longer how do I use AI to write code faster. That’s a commodity improvement. The real question is: what can I now build that I couldn’t before — because development effort and cost are no longer the constraint?

Some businesses will use this to go deeper into their existing product — adding complexity, personalisation, and capability that was previously too expensive to build. Others will use it to serve more customers without proportionally growing their team. Both are legitimate. Both represent compounding advantages that don’t show up immediately but become significant over eighteen to thirty-six months.

The metrics to watch are not about AI adoption. They’re about business outcomes. Has the turnaround time of a key workflow come down? Has the team’s capacity to serve clients increased without a corresponding increase in cost? Has resolution time improved? Has your release cadence changed? These are the numbers that eventually show up in revenue, margins, and growth — and right now, most founding teams aren’t measuring them with enough discipline.

So the real question isn’t whether your developers are going YOLO. It’s whether you, as a founder, are willing to go first.

March 13, 2026