The age of the builder: why AI makes building the skill that matters

Sixteen years, five shifts

I started my career in 2010 writing PL/SQL and Unix shell scripts at Atos in Pune. Since then I've worked on ad exchanges, led solution engineering for AdTech clients, built measurement models on clean rooms at Amazon Ads — and this year I joined Amperity as a Senior Solutions Architect, helping brands bring their customer data together.

Looking back, the titles matter less than the shifts I got to live through:

• On-premise to cloud. Servers in a rack became an API call.
• Ad servers to programmatic. Media buying became real-time auctions measured in milliseconds.
• Cookies to privacy-first. Data sharing moved into clean rooms and consent-aware architectures.
• Siloed data to the customer 360. Brands realised every channel depends on knowing who their customer actually is.
• And now, AI.

Each shift had the same pattern. The people who did well weren't necessarily the ones who understood it first in theory. They were the ones who got their hands dirty early — who stood up the first cloud workload, wrote the first bidder integration, ran the first clean room query. Hands-on experience compounded into judgement, and judgement is what people trust.

AI follows the same pattern, but faster and wider than anything before it.

What AI is actually changing

The cost of building has collapsed. An idea that once needed a team and a quarter can now become a working prototype in an evening. Boilerplate, scaffolding, integration glue — the slow, expensive parts of turning an idea into software — are increasingly handled by AI, with a human reviewing and steering.

Roles are converging. Product managers are shipping working prototypes instead of slide decks. Designers are pushing code. Analysts are building their own pipelines. Solutions architects are building demos on a customer's actual data before the second meeting. Teams are getting smaller, and each person is expected to cover more ground. Wearing multiple hats used to be a startup trait; it's becoming the default.

Adoption is near-universal, but trust isn't. In Stack Overflow's 2025 Developer Survey, 84% of developers said they use or plan to use AI tools, and over half of professional developers use them daily. Yet only about a third trust the accuracy of the output, and the most common frustration — cited by 66% — is "AI solutions that are almost right, but not quite."

That last point is the important one. The gap between almost right and right is where all the value now lives. And you only learn to close it by building.

Thinkers, designers, builders — the line is disappearing

For most of the history of software there's been a natural division of labour. Some people think — strategists, architects, consultants. Some people design — product designers, solution designers. And some people build — engineers. Ideas moved down that chain as documents: strategy decks, specs, wireframes, architecture diagrams.

That handoff existed for a good reason: building was expensive, so you planned carefully before spending engineering time.

AI changes the economics. When building is cheap, the handoff becomes the bottleneck. A spec describes what you think will work; a prototype shows what actually works. The person who can take an idea from whiteboard to working software — even a rough version — moves faster, learns faster, and makes better decisions than a team passing documents back and forth.

This doesn't make thinking or design less important. It makes them more powerful when they're attached to the ability to build. A strategist who can prototype tests ideas against reality before the meeting. A designer who can ship sees their design meet real data. An architect who builds knows which parts of the diagram will break.

The most valuable people in the next decade won't be pure thinkers or pure builders. They'll be thinkers who build.

What building teaches you that reading can't

Over the past year I've built a handful of things with AI as a co-pilot: this website and the AI agent on its home page, a private app that reads scanned documents and turns them into structured records for human review, and Agent X — a side project that puts a conversational layer over advertising clean rooms.

Each one taught me something I couldn't have learned from an article:

• AI is a first draft, not a final answer. Reading messy, handwritten documents, the extraction gets most items right — but not all, and occasionally reads the wrong page entirely. The right design wasn't a cleverer prompt. It was AI drafts, human reviews and approves, with tools that make the review fast.
• Models fabricate with confidence. Asked to cite the records behind its suggestions, a model produced precise-looking IDs that didn't exist. Citations became plain-language descriptions instead of links.
• Validation isn't optional. A date parser cheerfully read a measurement like "90/60" and a pattern like "1-0-1" as calendar dates. When model output drives real actions, every value gets checked.
• The demo is not the product. An agent that writes SQL from plain English is magic in a demo and a knife fight in production. I wrote a whole post on that one.
• The ground moves under you. This morning the AI agent on this site was failing on every message. Nothing in my code had changed — the model it used had been retired by the provider. The fix took ten minutes: find a model my account could actually call, switch to it, and adjust the prompt because the new model formatted its answers differently. You don't find that in a keynote.

None of these lessons are dramatic. That's the point. They're the practical, unglamorous details that separate something that demos well from something people can rely on — and they only show up when you build.

Why this matters in customer-facing roles

In my new role at Amperity, almost every customer data conversation now includes AI. How does AI fit with our data? Can we trust what it produces? What should we be doing in the next six months?

Those questions deserve answers grounded in experience. And the answers usually lead back to the foundations: AI is only as good as the data underneath it — clean, connected, with identities resolved and trust built in. That's not a slogan. It's what you see every time you watch a model reason confidently over messy inputs.

Building with AI makes you better at advising on AI. It's that simple.

How to become a builder

You don't need to become a software engineer. You need to start building:

1. Pick a real problem. Not a tutorial — something you or people around you actually need. Real stakes keep you honest about quality.
2. Use real data. Toy data hides every interesting problem. The messy formats, the duplicates, the edge cases — that's the curriculum.
3. Let someone else use it. Real users find failure modes you'd never think to test.
4. Keep it running. The first month teaches you how to build. The next six teach you how to own it.
5. Build with AI, not just about AI. A coding agent is the fastest way to learn what these tools are good at, and it makes the project fit into evenings rather than quarters.
6. Write down what you learn. A short note on what broke and why is worth more than another bookmark.

The takeaway

Every shift in my career rewarded the people who got hands-on early. AI is the biggest of them, because it changes not just what we build but who gets to build.

The barrier between having an idea and making it real has never been lower. The people who thrive will be the ones who step over it — thinkers, designers, architects and consultants who also build.

So build something small this month. Put real data in it. Let someone use it. Keep it alive long enough to learn from it.

That's how you stay relevant now.