Is AI Development OK?

There is a reasonable argument that AI has not killed art. It has just separated the vision from the execution, and that separation is not new. Directors do not operate cameras. Architects do not lay bricks. Composers have written for instruments they cannot play since instruments existed. The creative act, the decision about what something should be and why, has never required the maker to hold the brush. If a person with genuine aesthetic sensibility, a real point of view, a specific thing they are trying to say, uses AI to realise an image they could not otherwise produce, it is not obvious that the result is less theirs than a film is less the director's for having a cinematographer.

And yet something resists. The brush is not just a delivery mechanism. The resistance of the medium, the accident, the discovery that happens when the hand moves and produces something the mind did not anticipate, that is not incidental to the work. It is generative. Artists do not just execute visions. They find them, through the process of making, through failure and revision and the unexpected thing that arrives sideways. A model does not find anything in the way a painter does. But the prompt engineer who runs the same generation forty times, adjusts the seed, refines the instruction, and recognises the one that works, is doing something that resembles editing more than it resembles printing. The surprise is real. Whether the discovery is theirs is the harder question.

This is genuinely unresolved. Both arguments hold. The vision matters. The struggle also matters. Most people's instinct is to call AI output not-art, but the reasoning required to close that argument cleanly is harder than the instinct suggests, and anyone who has used these tools with serious intent knows that the prompt is not a passive instruction. It is a craft in itself, iterative, sensitive, requiring taste to direct and judgment to recognise when something is working. That is not nothing.

A product manager who understands a problem deeply, who has lived inside a business process for years and knows precisely what a solution needs to do, can now use AI to build something that works. Not a prototype, not a mockup, a functioning tool. A working Salesforce integration. A data transformation that runs on a schedule. A reporting layer that the technology team has been deprioritising for eighteen months. The vision was always there. The execution was the barrier. AI removed the barrier.

On the surface this is straightforwardly good. The person closest to the problem is now empowered to solve it. The procurement cycle, the scoping engagement, the requirements document that never quite captures how the business actually works, all of it bypassed. Something real exists where nothing existed before.

The ambiguity from the art discussion arrives here with consequences attached.

A painting that is fragile does not matter. A painting that cannot be maintained, that falls apart when the light changes or someone asks it to do something slightly different, is still a painting. It exists. It does what paintings do. Software is not like that. A business system built without the underlying comprehension to diagnose it, extend it, or reason about what it is connected to, is not just a painting that cannot be maintained. It is a liability dressed as a solution. It works until it does not, and when it stops working the person who built it often cannot explain why, because they never understood it well enough to have built a mental model of how it could fail.

This is not an argument against the citizen developer. The productivity gain is real, the democratisation is real, and the person with five years of domain knowledge and no computer science degree is solving problems that would otherwise not get solved. That matters. But the gap between what AI enables someone to build and what they can reason about is invisible until pressure is applied, and in a business context pressure is always eventually applied.

The good developer using AI is a different case entirely. She is removing friction from work she already understands. The model handles the mechanical, the boilerplate, the patterns she has written a thousand times, so she can spend her attention on the parts that require judgment. She is faster. She covers more ground. The AI does not replace her comprehension. It clears the path in front of it.

A director who has never held a camera can still make a great film. But they need to understand enough about what the camera does to know when it is lying to them.

The weak developer using AI is the art question in its most dangerous form. He can now produce outputs that exceed his understanding. The outputs look like the work of someone who knows what they are doing. They pass tests. They deploy. They run. And then something breaks in a way that requires a mental model he never built, and the gap between what he generated and what he understands becomes the problem everyone else has to solve.

The organisations navigating this well are not the ones who have decided whether AI-assisted development is legitimate. They are the ones who have worked out where genuine comprehension lives and who is directing the tool versus who is being carried by it.

The vision matters. It has always mattered. A product manager with a clear mental model of a problem is a genuine asset, and AI has made that asset more powerful than it has ever been. But the struggle also matters, for the same reason it matters in art. The resistance of the medium, the debugging, the failure, the reasoning through a system that is not behaving as expected, that is not incidental to the craft of building software. It is where the comprehension is formed.

A director who has never held a camera can still make a great film. But they need to understand enough about what the camera does to know when it is lying to them.

The vision without that understanding produces something that looks finished. Whether it is, depends entirely on what happens next.