Knowing it should exist is the job
Marty Cagan published a piece this week built around an argument from Benedict Evans: most people, and most companies, are not tool builders. AI drops the cost of making a tool close to zero, and still, the number of good tools that get made will barely move. Writing the code was never the hard part. The hard part is knowing that a thing should exist, and knowing how it should exist, and that is usually a different person.
I have spent years being that person, so the argument lands in a specific, unglamorous way. Let me make it concrete.
Three things that are hard, and one AI didn't touch
Evans pulls the product job into three skills. I recognise all three from the inside.
The first is seeing the general problem behind the pain. Everyone on an OSINT team can tell you the tools are painful. Far fewer can say what the pain actually is. When I started rebuilding parts of that stack, the useful move was not "make the dashboard faster." It was noticing that analysts are doing work that looks a lot like what developers already do: navigating huge graphs of named things, searching enormous indexes, reconstructing history, trusting provenance. The pain was a symptom. The real problem was that the tools had been built as 2012 enterprise software with an agent bolted on the side, when they should have been built like developer tooling.
The second is discovering a solution that works. Evans has a line I keep coming back to: being good at using a tool is not the same as being good at building one. You have to know a lot about sales to build good sales software, but being good at sales will not make you good at building it. The same holds here. Knowing OSINT does not make you good at building OSINT tools. The answer for coordination detection was not more content or a bigger model. It was structure: who said what, when. Weight for rarity, cluster, and let the network surface itself. You only find that solution by understanding the domain and the craft of building at the same time, not either one alone.
The third decides whether any of it matters: viability. A solution has to work for the business it lives in, and in my world "the business" means regulators, accreditation, sovereign data boundaries, and an analyst who has to defend a conclusion to someone hostile. This is where most impressive demos quietly die. It is also the part AI does not touch. A model can produce a fluent answer. It cannot decide that the answer needs a chain of custody, that "the model decided" is not evidence, or that the whole thing has to run offline and deterministic so the same input always gives the same output. Those are viability judgments, and they are the difference between a clever prototype and something a government will actually run.
AI changed the threshold, not the job
The anxious version of this moment goes: if anyone can vibe-code a tool, what is left for the people who build them? The honest answer is that the scarce skill was never the typing.
Building Albion did not get hard when I opened the editor. It got hard at the decisions. Read a file's schema from the shape of the data, not the column names, because names change with every vendor and every language. Keep the language model out of the core, because the output might become evidence and a model's guess is not a chain of custody. Version-stamp every stage and lock the hasher with a golden test, so a silent library update fails loudly instead of quietly corrupting a result someone is about to act on. None of that is a typing problem. All of it is a knowing-what-should-exist problem.
That is why software companies and consultants still exist, as Cagan puts it: AI moved the threshold, but left the problem where it was. Someone still has to know the tool should exist, know how it should exist, and build it well enough that it survives contact with the real world.
Where the interesting decisions live
I am not a strategist who hands a deck to engineers, and I am not an engineer waiting to be told what to build. I keep both because the decisions worth having live exactly where they meet. The person who knows the tool should exist and the person who can build it are usually two people, negotiating across a gap. When they are the same person, that gap closes, and what gets built is closer to what should have existed in the first place.
That combination is getting more valuable as building gets cheaper, not less. When the cost of making a tool falls to nothing, the entire premium moves onto knowing which tool is worth making, and whether it will hold up when it matters.
That was always the job. It is just easier to see now.