That feeling when Google I/O catches up to you....

I wrote the post below in order to shut up a late night brain worm, with the thought that it might be interesting enough to share. Then today it's almost as if I hear my words coming out of the mouths of the presenters of this Google I/O workshop:

Build core skills to thrive as an AI-era developer

[2026-04-29 Wed 00:26] At one point the ideal engineer was described as t-shaped. They would have broad knowledge of the field, but also tremendous depth in one particular area. The theory was that this engineer had proven that they had the ability to absorb, understand, and exploit every nuance of one specialty, and much like getting a PhD licenses you to study anything you want, demonstrating that ability was proof that you could, with time, achieve it in any area that was needed.

(This always made me imagine a bunch of tacks with the engineer's name on them on the CTOs org chart, ready to be rearranged for the next re-org)

But what is the ideal shape for an engineer in an LLM Coding agent world? Much less a full AGI world. I've watched how quickly these stochastic parrots have climbed the capability ladder. They quickly replaced help documentation and destroyed Stack Overflow's business model. So "knowing stuff" wasn't really part of the engineer's job description any more. When they became agentic, they started encroaching on the "knowing how to do stuff" part of the job.

The last surviving rung is "knowing what to do". I'm hoping that engineers have a bit more of a moat there. But only if they are adding inherently human context to the decision of what to do. I think of the T shape as the combination of being "knowing" about of a lot of things, and being "knowledgable" about a few particular things. But what is the name for being a vessel that understands subjective, emotional, and aesthetic connections to the physical world and its inhabitants?

My hypothesis is that the software development organizations that are able to optimize the workflow used to create software artifacts in alignment with the business goals with respect to that contextual richness is the one that is going to have the competitive advantage.

And I don't believe that this requires different people than there are in their organizations already. Being context full is inherently a human trait. Just like we shaped ourselves into T's or thumbtacks because that is what was needed to create the best software teams, we can shape ourselves into what is needed next