Silicon Valley trip and the future is here

I am writing this from San Francisco, nearly a week into a trip for OpenAI’s annual developer conference. San Francisco is beautiful, though it remains a very stupid place to put a city, given the terrain and the fault line.

It also feels like someone has turned the AI dial all the way up. Almost every billboard and spare surface carries an advert for an AI company. The coffee shops are full of founders building things between drinks.

I spend most of my time talking and working on AI, and even I found it a lot.

This article is a bit different than normal in that is a state of play with all things AI coming from the centre point of tech globally that is silicon valley around the most AI focused people possibility in the world. Enjoy.

The future still has traffic

We have self-driving cars/taxis in Abu Dhabi, but they still have a safety driver sitting at the front. In San Francisco, I opened the Waymo app, requested a car and climbed into the back.

My first journey took about six minutes along a couple of simple roads. That felt controlled enough. Then I took one for half an hour through San Francisco. It handled traffic, closed lanes, turns and the strange geography of the city. The app experience was smooth. The car arrived, took me where I needed to go and carried on to its next job.

What made it feel different was not the technology itself. I already knew self-driving cars existed. It was how ordinary they had become. On some streets, several cars around me were driving themselves.

The Conference

OpenAI’s developer conference had around two and a half thousand people there to hear about all the latest from OpenAI, with a long list of new products and features announced. My first time witnessing protests outside a tech conference with boards saying “humans not AI”.

One of the larger announcements from the conference was Dots, an accessible way for non-engineers to use agents. The easiest way to think about these agents is as little creatures that go off and do things for you. They can use tools, gather information and complete a task. Over time, they may also learn enough about how you work to become a form of personal assistant that start proactively doing things on your behalf. This is currently targeted towards business and higher subscription users but I am sure we will see it come down towards a more consumer offering soon.

OpenAI also showed security tooling that can analyse software code, identify potential issues and propose code changes for a human to approve.  They described the idea as a defence factory that is continuous running and finding and fixing. The idea of a software factory is something I have been advocating for some time, instead of building a tool you build a process to build as many tools are you desire. This is starting to come true and will trickle down over the coming year in all areas I believe.

One phrase came up repeatedly: high-agency engineers.

The clearest description I heard was this:

Anyone can go to a high-agency engineer, explain a concept, and in 30 minutes they have the solution.

The important word is not engineer. It is agency. A high-agency person takes ownership of the problem rather than ownership of a particular solution. They speak to the customer. They speak to the team. They go outside their usual area if that is what the problem requires. They might build ten prototypes. They might build one. The answer could be a simple prompt. The number does not matter because their identity is not attached to the method.

Their job is to move the problem forward.

I heard versions of this from people working in ecommerce, insurance, property, finance and large technology companies. The details changed, but the pattern did not. Teams using AI deeply were pulling away from teams treating it as an optional assistant.

But this has created a gap between the have and the have nots, I think of this as the AI Enabled Agency Gap. The growing distance between people who use these systems to take greater ownership and people who use them only to complete the same tasks a little faster.

That distinction matters. If I use AI to write code more quickly, I am improving an existing part of my job.

If I use it to understand the customer, test possible answers, build a working version and explain it back to the organisation, the shape of my job changes.

The first helps me do what I was asked. The second helps me solve what actually needs solving.

That second shift, repeated across enough people and teams, is how organisations reinvent what they do, and how economies move forward.

Build the Factory, Not the Engine

Most organisations are still asking how to make the current process more efficient.

• How can I produce this document faster?

• How can I write this ticket faster?

• How can I get through more code?

Those are reasonable questions, and there is useful work available there. But they assume the existing process should remain intact.

The people I met in San Francisco were increasingly asking a different question:

Why does the process look like this at all?

One attendee described teams where the difference in output had become difficult to ignore. One team might complete a large volume of work while another, with a similar structure, completed a fraction of it (100 features vs 5 features over the same time period).

The teams moving fastest had leaders who set the tone. They provided training and support, but they also expected people to change how they worked.

One person overseeing hundreds of engineers told me that, within his strongest team, much of the momentum came from him and a recent graduate who had embraced the tools. Their behaviour pulled the rest of that team forward. The deciding factor was not age, seniority or a formal AI role. It was whether someone was willing to pick up the problem and keep moving.

Another person described engineering teams being given wider responsibility. Engineers joined customer calls and spent more time understanding what needed to be solved.

The acceptance was simple: coding was no longer the job.

That is uncomfortable when someone has spent years building an identity around being the person who writes the code. But the responsibility is moving outwards. The engineer can now spend less time translating a fixed instruction into code and more time deciding whether the instruction makes sense.

This is where things get interesting.

If agents can produce the first version of a tool, the scarce skill becomes knowing which tool should exist. If they can produce ten versions, the scarce skill becomes choosing between them.

The work moves from production towards judgement.

Changing expectations.

One person I spoke with said his organisation required a business case when a team wanted more people or resources.

The question was why the work could not be done with AI first.

I also heard much harsher versions of the story.

Several people expected significant reductions in engineering teams as the gap widened between those embracing AI and those who were not. One attendee told me about an organisation that had already shrunk dramatically (over 90% headcount reduction) while claiming improved accuracy.

The Future Is Waiting at the Lights

I keep coming back to that half-hour journey through San Francisco.

The car did not feel like a prototype. Other drivers did not stop to stare at it. It simply moved through the city as part of the traffic.

That may be what many organisations are missing about AI.

They are waiting for a clean moment when the future arrives and someone announces that the operating model has changed.

I do not think it will happen like that.

The tools will become part of ordinary work. A few people will quietly take on wider problems. One team will begin moving much faster than the team beside it. The empty seats will become visible only after the system has already adjusted around them.

Here is the question worth sitting with:

Are we helping people take ownership of larger problems, or are we only asking them to complete the old tasks faster?

The traffic is already moving.