A 13-Year-Old Can Now Build What Your IT Department Quotes 6 Months For

A 13-year-old with no prior coding experience built an AI-powered sports coach in two days. His 18-year-old sister built an astronomy application in the same timeframe. Neither wrote traditional code.

Now think about the last time you requested a "simple tool" from your IT department. How long was the estimate? Three months? Six? "We'll add it to the backlog"?

Something fundamental has changed, and most enterprise technology organisations haven't grasped the implications yet.

The Backlog Problem

Every large organisation I've worked with has a shadow list. Not the official project portfolio, the other list. The one with hundreds of "small requests" that would make people's jobs easier but never rise to the priority threshold.

A tool to automate that weekly report. A simple app to track that manual process. A calculator for that decision people make repeatedly. A form to collect that information that currently lives in scattered emails.

Each item is too small to justify a formal project but too big for a spreadsheet. They sit in the backlog for years, occasionally bubbling up when someone complains loudly enough, then sinking back down when bigger priorities emerge.

Meanwhile, people continue doing things manually. They build baroque Excel workbooks. They develop workarounds that become institutional knowledge. They quietly resent a technology function that seems incapable of helping with anything that doesn't require a steering committee.

That backlog is now buildable by those same frustrated people, over a weekend, without involving IT at all.

What Actually Takes Six Months

Let's be honest about what enterprise software timelines actually contain. Requirements gathering (which mostly means having the same conversation repeatedly with different stakeholders). Security review (which mostly means filling out forms and waiting). Architecture review (which mostly means justifying why you're not using the standard platform that doesn't fit your use case). Resource allocation (which mostly means waiting for someone to become available). Development (the actual building). Testing (finding that the requirements were wrong). UAT (finding that the requirements were also incomplete). Deployment (navigating change management). Documentation (so the next person knows what you did).

The actual building part, the thing a 13-year-old did in two days, might be two weeks of that six-month timeline. The rest is overhead.

Some of that overhead is legitimate. Security matters. Architecture matters. But much of it is process accumulation, the sedimentary layers of every past failure, each adding a new approval gate or documentation requirement.

The question organisations need to ask: how much of our delivery timeline is actual complexity versus accumulated friction?

The Shadow IT Reckoning

For years, IT departments have fought shadow IT, technology purchased or built outside official channels. The usual arguments: security risks, integration problems, data silos, support burden.

These arguments are about to become both more important and more futile.

More important because AI-built applications can create all the same risks as any other ungoverned technology, potentially faster and at greater scale.

More futile because the friction gap between "official channels" and "I'll just build it myself" is about to become a chasm. When official channels take six months and DIY takes a weekend, policy enforcement becomes nearly impossible.

You can't stop people from building what they need when building is this easy. You can only choose whether it happens visibly, with support and governance, or invisibly, as an ungoverned proliferation.

What Development Teams Should Actually Be Doing

If a motivated non-technical person can build a working application in a weekend, what is the professional development team for?

Not the commodity work. Not the simple tools. Not the "small requests" that sit in backlogs for years.

The hard problems. The ones that actually require expertise. Integration with complex legacy systems. Security architecture. Performance at scale. The work that fails dangerously and expensively when done poorly.

Most organisations have these two categories completely tangled together. Senior engineers spend time on work that teenagers could now do, while genuinely difficult problems wait because everyone's capacity is consumed by the ordinary.

The opportunity isn't to replace development teams. It's to finally separate the genuinely difficult from the merely tedious, and ensure that scarce expertise goes where it's actually needed.

The New Role for IT

If IT's value proposition isn't "we're the only ones who can build things," what is it?

Enablement over gatekeeping. Instead of being the bottleneck through which all requests must pass, become the function that makes everyone else more capable. Provide the tools. Create the guardrails. Establish the patterns. Then get out of the way.

Quality assurance over production. Instead of building everything yourself, become the function that ensures everything built meets standards. Security review. Integration verification. Production readiness assessment. The work that requires expertise regardless of who did the initial building.

Platform over project. Instead of delivering discrete pieces of functionality, provide the infrastructure that makes functionality easy to build. APIs. Authentication. Data access. Deployment pipelines. The foundation that others build on.

This is a fundamental shift from monopoly provider to capability multiplier. It requires different skills, different structures, and different measures of success.

The Timeline for Disruption

How long before this is mainstream? The question assumes it isn't already.

A Google executive's kids learned to build apps in a weekend, at the same class that draws tech professionals from Oracle and Amazon. This isn't early-adopter territory, it's already crossing into the mainstream.

The family then entered a public hackathon with hundreds of participants, most of them adults, all of them building with these same tools. This isn't a controlled experiment, it's a movement.

If you're planning your organisation's technology strategy on the assumption that software development will remain a scarce, specialised capability, you're planning for a world that's already ending.

The Real Competitive Question

The organisations that thrive won't be those that prevent this shift. They'll be those that harness it.

Imagine a company where every frustrated employee knows they could build the tool they need, and has the support to do it safely. Where backlogs don't exist because small needs are addressed immediately by the people who have them. Where the development team focuses exclusively on problems that actually require their expertise.

Now imagine competing against that company while you're still running every small request through a six-month process.

A 13-year-old built an AI sports coach in a weekend. The question isn't whether that's impressive. The question is what your organisation will do now that it's possible.