We have Ferraris now
We've put extraordinarily powerful tools in the hands of people and organisations who haven't yet developed the judgment to use them well. That's not a criticism. It's just where we are.
"We have Ferraris now"
What Web Summit Vancouver 2026 actually taught me about where AI is taking us.
I wasn't sure what to expect from Web Summit Vancouver. These things can be a lot of vendors telling you their product is the future, or lots of people looking to invest in or build the next unicorn. But I walked out genuinely informed with lots to mull over. Not because anything I heard was wildly new, but because of how clearly I could see the gap between where we think we are with AI and where we actually are.
One throwaway line from a panel summed it up perfectly:
"We all have Ferraris now and no driving licence."
Headlines chatter over token costs, with some teams burning $100K a month with no governance, no model strategy, just vibes. But what are the broader implications of the trend? How do we apply common sense to it, should we? We've put extraordinarily powerful tools in the hands of people and organisations who haven't yet developed the judgment to use them well. That's not a criticism. It's just where we are, we are going 100mph here. The question is: what do you do about it?
Nobody talks about where the time actually goes.
Creator of Claude Code, Boris Cherny says coding is ... "largely solved". And, in a way, it's true. The gap between an idea and working code has collapsed. Developers are shipping syntax faster than ever.
But was coding actually the bottleneck?
If you map where time really goes in a software team, not where you think it goes, where it actually goes, most of it isn't coding. It's waiting. Engineers waiting for design sign-off. Designers waiting for feedback. PRs sitting in queues for days. Requirements that seemed clear turning out not to be. Context lost in handoffs between people.
In the AWS sponsored session "Re-imagining software dev in the age of AI coding agents - AI-DLC", 1Password figured out agentic development doesn't solve this. It exposes it. Move fast enough and the human bottlenecks become impossible to miss. So they didn't try to make coding faster. They went after the waits. AI-first PR review, prototyping in code instead of Figma, always-on AI incident analysis. Closing the gaps, not just the throughput.
But, why change ? after all we have the gains, we are 10x developers now, aren't we? Maybe. But if we haven't fixed where the time actually goes, we might just be 10x faster at hitting brick walls.
1Password engineers use 2–3 AI coding tools daily, and they're allowed to choose which ones: Codex, Claude, whatever. No mandated tool. They've got a dedicated team (they called it "continuous AI") whose entire job is building the agentic SDLC pipeline. Not using AI to ship features but building the infrastructure that makes AI work well for everyone else.
AI does the first pass on every PR. Not to replace code review, but to free the humans for the review that actually matters. Designers can focus on design. Senior engineers can focus on architecture. The grunt work of "did you forget a semicolon" gets handled.
And then there's the always-on incident response agent. Not an alert that fires when something breaks. A system that's watching all the time, flagging the signal before the noise gets loud enough for a human to catch it.
This is what AI-native actually looks like. Not AI as a feature. AI as the connective tissue of the whole process.
Most of what I see in practice isn't this. It's "we gave everyone Copilot" and called it a transformation. Bolting AI on to existing process, that's AI-assisted not native. Faster fingers on the same broken processes.
But, of course, all of this comes with challenges...
Credentials will leak. Not "might." Will. The question is how fast you detect it and how contained the damage is. Shadow AI is already everywhere, if you haven't asked your team what tools they're using outside your approved stack, you probably won't like the answer. Every new tool your engineers try is a new surface. Every model that gets your codebase as context is a potential exposure point.
This wasn’t hypothetical — 1Password shared real customer feedback that said:
"Engineers are spinning up MCP servers on their laptops and connecting them to production APIs. We had no idea until last week."
"Our intern used Claude to build a prototype and hardcoded the production database password right into the script."
"The code looks right, but we've caught AI-generated functions with subtle security flaws three times this quarter."
"We're spending $400 a month on AI coding tools and we can't tell you who's using what."
"Our AI approval process takes four months. By then, developers have already been using the tool for three."
They called the combined problem the "lethal trisector": credential sprawl, new attack surfaces from AI tooling, and the governance friction that means controls are always lagging adoption. It's not one problem or two, but if you have all three you are in deep trouble.
You can't lock this down, not immediately. The pace of adoption is too fast. The better question is: can you build something that detects fast and assumes breach? That's a different posture. Harder culturally. But more honest.
"Trust the tools, verify the output"
The talk that was actually about people.
Benevity's session was different. Less about tools, more about what happens to the humans when the tools change.
They've been restructuring their teams, moving away from dedicated deep domain specialists and toward what they called "fungible" engineers. People who can rotate across the codebase, work in different domains, spin up on new problems quickly. Smaller teams overall. Fewer passengers. More drivers.
The friction this creates is real and they didn't hide it. "This is my domain, my service, my code" is a deeply human instinct. Breaking it requires trust, and trust requires intentional work: listening, coaching, genuine engagement. You can't mandate fungibility. You build it.
But the point underneath all of this is important: domain ownership doesn't scale the way it used to. When agents can handle orchestration and context across a codebase, the value of "only I understand this service" drops. What becomes valuable instead is judgment. Taste. Knowing what good looks like, not just how to build a thing.
Their measure of success was interesting too, not velocity, not story points. It was their focus on Flow. yes, the ever elusive flow that so readily get crushed by bureaucracy. Does value actually move through the organisation, from idea to customer, without unnecessary stops? That's a harder thing to measure, its a case of identifying what works.
Their take:
The Agile Manifesto was about uncovering better ways of building software by doing it. AI-DLC feels like the next evolution of that idea.
SDLC gave us the structure, AI-DLC can give us the automation.
There is no standard playbook for scale:
- Fail forwards, fast.
- Many elements of the AI-DLC will need revisiting and revising as both we and AI-driven development evolves.
The cost problem finance doesn't know about yet.
Here's something I suspect a lot of engineering leaders are quietly sitting on: AI spend is the new shadow IT budget.
Teams are running agents, parallel workstreams, experimental pipelines and the costs are going on personal cards, team budgets, anywhere they can be hidden from proper scrutiny. Some teams are genuinely spending $100K a week. Most finance leaders have no visibility into this. And when it comes to light, the conversation is going to be uncomfortable.
The model selection problem makes this worse. Most teams are reaching for the most powerful model available by default, Opus, Opus, Opus, Ouch. But you don't need a frontier model to parse a log file or generate a first-draft unit test. Using the right model for the task is a discipline that almost no one has developed yet. It's the difference between using a Ferrari for the weekly shop and actually knowing how to drive.
Mike Conover's talk on open source LLMs yielded some interesting stats:
- Deepseek v4 Pro is 35x cheaper than Opus 4.7 ($0.0145 vs. $0.5/M tokens)
- Qwen3.6-27B vs. Opus 4.7
- Qwen @ S0.40-$2.00/Mtok
- Opus @ $7-$25/Mtok
- ~10-30× cost
Open source models are closing the gap faster than people realise, they are roughly six months behind frontier models now. For organisations with real data privacy concerns or geopolitical reasons to avoid US cloud providers, the on-premise case is getting very strong.
The thing everyone's dancing around: roles are changing.
The panels were careful about this, but I'll just say it directly. When PMs and designers can prototype in code, and BAs can build functional tools, and non-engineers can spin up working software, the definition of what an engineer is for has to evolve.
The things that remain stubbornly human: taste, judgment, creativity. LLMs don't have these. They have pattern-matching at an extraordinary scale, but they don't have the thing that lets you know when something is right versus just plausible. One panelist compared it to "A junior developer with lots of knowledge", perhaps i think its more than that but there is no way it can do a thing without the senior "human-in-the-loop". Systems thinking, true domain ownership, knowing when not to build something, those are still deeply human, keep it there.
And agency. Someone in one of the sessions put it well: "Agency will always belong to a human." Even in a world of autonomous agents, the question of what should this agent be doing remains ours. The agent is a remarkable instrument. But the musician is still the human, despite what Lyria 3 tells you!
SaaS is going headless and most people haven't noticed.
This one pricked my ears up. Several sessions touched on it from different angles, but the clearest framing was this: the new users of software are agents. Not people. Agents.
When your primary user doesn't need a UI, doesn't need a dashboard, doesn't need a workflow designed for human cognition, then what does the software look like? It looks like an API. It looks like capabilities that other systems can call. It goes headless.
Salesforce announced headless. Why? It's a strong direction. And the build-vs-buy calculation is shifting alongside it. When you could build exactly what you need for the cost of tokens, software that fits your process perfectly rather than one that's 80% right and requires workarounds, the case for off-the-shelf weakens. The gap between "build it" and "buy it" has closed more than most people are ready for. SaaS-apocalypse? may-just-be.
So what do you actually do?
You get your driving licence. That's the only honest answer.
Know what models you're running and why. Define what your AI agents are and aren't authorised to do. Build context intentionally, an agent with no context about your organisation is like dragging the smartest person you know into the lobby, handing them a coffee, and expecting them to be useful. They might be brilliant. They don't know anything. You have to do the work of making them know.
Have a goal. A real, specific, measurable goal. "Use more AI" is not a goal. "Reduce the time from PR raised to PR reviewed by 40% in Q3" is a goal. "Eliminate credential sprawl from our CI pipeline by end of quarter" is a goal. Pick problems that matter and work backwards to whether AI is actually the right tool for them > sometimes it is, sometimes it isn't.
Keep humans accountable. Not as a feel-good hedge. Because it's true. The things that go wrong go wrong because someone made a choice, or didn't make a choice they should have. Ownership, in the end, isn't optional.
The Ferraris aren't going back to the showroom. But we can learn to drive.
Questions or thoughts? Get in touch.