This week I forked Garry Tan’s gstack and began adapting it to my own workflow.
Nothing polished. I wanted to test what AI means for work I already understand: data engineering, data design, digital services and the layers where people actually interact with systems.
That is where the impact becomes real for me—not in predictions about an entirely different future, but in the ordinary work already in front of us.
The early signal is that these systems can be shaped around the work rather than requiring the work to be reshaped around the tool.
By service as software, I mean software beginning to do more than provide a fixed function. It can interpret an intention, help structure the work, guide the next step and adjust when the situation changes.
That does not remove people or expertise. It changes where some of their effort goes.
One of the ideas I can’t shake is this:
a team of 15 starting to look like a team of 40.
That is not a measured productivity claim. Nor does it mean fifteen people should simply be expected to produce nearly three times as much.
It is an observation about certain kinds of effort becoming much cheaper: setting up the initial structure, navigating unfamiliar tools, producing a credible first version and completing the repetitive work needed before the interesting problem can even be reached.
Even some of the more mundane administration begins to look different. If somebody can describe the board, workflow or structure they need and have the software help create it, work that is often delayed or done inconsistently becomes easier to do properly. Planner or Azure DevOps no longer has to be understood in full before somebody can begin organising the work.
The value is partly speed. More importantly, more of the team’s attention can remain with the problem rather than being consumed by the mechanics surrounding it.
Any gain can still be absorbed. Expectations rise. Processes expand. A faster route to a first version can simply create demand for more versions.
So the useful question is not how much more work a team can produce. It is what becomes possible when less of its capacity is spent getting the machinery to cooperate.
It would be easy to call all of this productivity. That is true, but incomplete.
If the friction involved in making something drops, the ability to make things becomes less distinctive. The harder questions move forward.
Which problems are worth solving?
What should the service actually do?
What evidence should we trust?
Where does automation help, and where would it merely make a poor decision happen faster?
Edward De Bono called it “Serious Creativity”: the deliberate ability to generate and shape alternatives rather than waiting for a good idea to arrive.
That feels increasingly relevant. When producing a plausible answer becomes easier, the quality of the question, the judgement applied to the answer and the ability to imagine a better alternative all matter more.
The constraint is no longer only:
can we build this?
It is also:
can we think of something worth building, and recognise the difference?
Some of what we have treated as expertise is deep judgement. Some is familiarity with difficult machinery. As the machinery becomes easier to operate, the distinction becomes harder to avoid.
Technical friction has also given us a visible explanation for why something could not be done. As that friction falls, the remaining limits become more human: expertise, imagination, judgement and the willingness to make a choice.
Capability alone does not mean a team will realise any of this.
People need room to test incomplete ideas, use tools in ways that do not yet fit established processes and discover where the apparent promise breaks down.
Leadership shows up in what people are allowed to try, what is encouraged and what gets shut down without anyone quite noticing.
A team can have access to capable tools and still be required to work as though nothing has changed. Every experiment can be forced through a production process. Every uncertain idea can be judged against a plan written before the new capability existed. Every efficiency can be filled immediately with another demand.
In that environment, a team of 15 will continue to behave like a team of 15, or less.
This does not require abandoning governance or treating experimentation as an excuse for carelessness. Some work should be controlled. Some systems cannot be treated as a playground.
Good governance should create proportionate places to learn: somewhere unfinished work can remain unfinished long enough to teach us something, and where useful discoveries can influence the way the organisation operates.
The tool still matters. So does the engineering beneath it. But more of the differentiation now sits in how the capability is used, what people are trying to achieve and whether the organisation allows them to work differently.
For now, I am continuing the experiment: applying these tools to work I know, watching which kinds of effort collapse and paying attention to what we actually do with the space that creates.