Is AI Turning Science into Art?

During my accounting days, I encountered a familiar question: Is accounting an art or a science? The argument often turned on structure. Methods, standards, and frameworks seemed to place accounting closer to science. Judgment and intuition seemed to belong to art.

AI has brought that question back to me. A developer can describe an application to Claude or ChatGPT, wait for the code, and request changes. Much of the work can happen through conversation. The developer describes what they want and decides whether the result feels right.

That sounds a lot like creative direction. It made me wonder: Is AI turning what used to be science into art?

The Rick Rubin version of software engineering

Rick Rubin’s interview with Anderson Cooper captures the feeling:

Anderson Cooper: Do you play instruments?

Rick Rubin: Barely.

Anderson Cooper: Do you know how to work a soundboard?

Rick Rubin: No. I have no technical ability. And I know nothing about music.

Anderson Cooper: You must know something.

Rick Rubin: Well, I know what I like and what I don’t like. And I’m decisive about what I like and what I don’t like.

Anderson Cooper: So what are you being paid for?

Rick Rubin: The confidence that I have in my taste and my ability to express what I feel has proven helpful for artists.

— Rick Rubin, 60 Minutes, CBS transcript.

Exchange reproduced as supplied; the linked CBS transcript includes minor differences in transcription.

The joke almost writes itself: we have moved from a skill issue to a taste issue. When AI handles implementation, recognizing a good result and communicating what needs to change can become a larger part of the human contribution.

But Rubin works with musicians and technical staff. Someone still plays the instruments and handles the recording. His judgment contributes to that work; it does not make the technical work disappear. The same question follows a generated application: who establishes whether it actually works?

A process does not make something science

My accounting example rests on an assumption: formal procedures make a practice scientific. Procedures can make work consistent, transparent, and easier to audit. They do not automatically establish knowledge about the world.

A depreciation calculation can correctly apply an accounting convention. Whether it usefully represents an asset’s economic life is a separate question. Likewise, a team can follow a development framework and still build software that fails its requirements.

Henri Poincaré described the relationship between facts and science in Science and Hypothesis:

Science is built up with facts, as a house is with stones. But a collection of facts is no more a science than a heap of stones is a house.

— Henri Poincaré, The Foundations of Science.

A pile of facts needs an account of how those facts relate. A set of procedures needs reasons for why following them supports a claim.

Epistemology asks what we know and what justifies our beliefs. For this discussion, the central question is straightforward: Why should we believe a claim, and how could we find out that it is wrong?

I understand science as an effort to develop explanations that answer to evidence and criticism. Philosophers disagree about whether one method characterizes every science. A checklist alone cannot settle the question.

Intuition, evidence, and purpose

Intuition and process do not divide science from art. A scientist can imagine a hypothesis before knowing how to test it. An artist can work through disciplined practice, comparison, and revision. How an idea occurs to someone differs from what gives others grounds to accept it.

Richard Feynman put the experimental emphasis of physics plainly:

The test of all knowledge is experiment.

— Richard Feynman, The Feynman Lectures on Physics, Volume I, Chapter 1.

His statement places physical claims before observation. It does not describe every kind of knowledge. An intuitive guess can suggest a hypothesis; evidence must support accepting it.

Art can also help us understand the world. A painting, however, does not need to establish an empirical explanation to succeed. Engineering has another purpose: building something that meets requirements within practical constraints.

These purposes can overlap. Software involves design choices, formal reasoning, and empirical tests. Calling all of it science hides some of the work we are trying to understand.

From writing code to directing work

AI can change where a person spends their attention. The diagram shows two simplified workflows; both involve design, testing, and revision.

Figure 1. AI can handle code generation. Findings from evaluation should feed back into requirements and implementation.

When a person delegates implementation, intermediate decisions can become less visible. They see a request and a result, with much of the work happening between them. Directing that work can feel artistic: describe an intention, examine a candidate, ask for a variation.

The change concerns how we produce the artifact. Its requirements still determine what we need to check.

What does taste allow us to judge?

Consider three responses to an application:

An attractive interface can conceal broken permissions. A successful demonstration can leave important failure conditions unexplored. Calling every judgment taste blurs these differences.

Taste can still involve expertise. In Of the Standard of Taste, David Hume emphasizes practice and comparison in developing judgment. An experienced developer might sense that a design is fragile before explaining why. Inspection might then reveal hidden dependencies or unnecessary state.

That feeling gives the developer somewhere to look. The investigation gives others reasons to take the concern seriously.

Creative director or meat proxy?

The term meat proxy describes a thinner human contribution. In one account of this AI-era slang, a person forwards requests to AI and passes its answers onward without meaningful review.

Imagine a request to restrict a document to its owner. The model writes a permission check and reports success. Someone exercising engineering judgment asks whether another account can fetch the document directly. They inspect the behavior and test it. A meat proxy forwards the assurance.

When a defect arrives, that person may send it back to the model and relay the next attempt. They remain in the conversation, but the claim gains no independent support as it passes through them. Asking AI to review itself does not resolve this by itself; someone still needs grounds to accept the review.

This is where the Rubin analogy becomes useful. His stated contribution is judgment. Sitting between a request and an output does not establish that contribution. We need to ask what the person adds:

• Do they clarify requirements the original request left ambiguous?
• Can they recognize failures and investigate their causes?
• What evidence do they require before accepting the result?

Prompting and waiting can describe both informed direction and simple transmission. The visible workflow tells us little about the understanding behind it.

The model and its output are different black boxes

The model’s internal operation may be difficult to explain. Its output can still be code a developer understands. Conversely, someone can misunderstand code they wrote themselves. We should distinguish an opaque generator from an artifact nobody has meaningfully inspected.

A demonstration also supports a narrower claim than we sometimes assume. It shows that something worked under the demonstrated conditions. It does not establish every condition under which the system works, or explain why it behaves that way.

We rarely understand every component completely. We can still ask whether our confidence matches the evidence we have.

Where will judgment come from?

There is a difficulty with treating production and evaluation as separate stages: making something can teach us how to judge it. Writing code exposes ambiguous requirements. Debugging reveals assumptions. Maintaining a system teaches us what an earlier shortcut costs.

Delegating those activities may remove some opportunities to learn. That raises the question I find most interesting: How will people develop the expertise to evaluate work they no longer need to perform?

Manual implementation is one route. AI could support others. A learner could compare implementations, ask for explanations, predict behavior, and test those predictions. The important step is engaging with the result closely enough to discover where their understanding fails.

A polished demonstration does not tell us whether that learning happened.

Is science becoming art?

My original question describes a change in the experience of technical work. AI can make production resemble creative direction. People can contribute ideas and domain knowledge without executing every technical step themselves.

But the value of that direction depends on the judgment behind it. The meat proxy shows how easily the same position can become a place for passing answers along.

In my earlier reflection on information systems research, I asked whether research products represent the practices that establish knowledge. AI brings that concern into everyday work. We can produce a convincing artifact before establishing the claims we make about it.

We may write less code and spend more time deciding what to accept. If we delegate the work through which judgment once developed, what will we put in its place?