Working code is not a transformation strategy
Benedict Evans makes a point in his essay on AI, tools and transformation that deserves more attention than it has had. None of this is solved by making it easier to write code, he says, because the hard part is knowing you need a tool in the first place and then knowing what it should do. He is arguing against the idea that AI turns everyone into a builder and software becomes spontaneous and disposable. The same logic applies to any organisation that is treating a code generator for every employee as its transformation strategy.
Giving everyone the ability to produce working code changes who can build, but not how the organisation decides, approves or is held to account. The tools multiply and the approval chain stays where it was. A department can end up with hundreds of staff-built assistants and the same process behind them, which means it has measured activity and changed very little.
A second problem usually arrives later. Code that runs is not code that is maintained. Someone has to support it when the person who built it moves on, debug it when an upstream system changes, and answer for it when it produces a wrong result. Working code is also not necessarily safe or compliant. It can break enterprise architecture standards, mishandle personal information or sit outside the security controls the rest of the estate relies on.
None of that is a criticism of the people building. A finance analyst or a policy officer should not be expected to know those requirements, and it is unfair to leave them carrying the risk of not knowing. The citizen-developer programs of the low-code era ran into exactly this, and a code generator for everyone invites the same outcome.
The more useful measure is how many decisions have been redesigned, each with an owner, a standard and a support path attached. A transformation that cannot point to those has produced output, and output was never the scarce thing.
Source: https://lnkd.in/gQhE65iM
#AusBiz #FutureOfWork #OperatingModel