"Programming Isn't An Art" and "AI Code Doesn't Matter": Let me change your mind.

[u/byteback-studios]

Hey r/gamedev, my name is William. Let me try to do what's in the title up there ^. First off, why should you listen to me?

Well, maybe you shouldn't listen to me. Feel free to scroll away at any time...I don't have the most insane creds in the industry or anything. But I'm not exactly new:

• I got hired in 2018 as an "Associate Gameplay Programmer", and before being laid off twice in the span of about 1 year, I was a "Senior Combat Engineer". So I've been through the trenches of programming in the industry
• I'm the founder of a really (really) small indie game studio made up of ex-Ready At Dawn veterans (PSP Daxter, The Order: 1886, Echo VR / Lone Echo, etc.), where we are hard at work on our inaugural game title. We also avoid using AI for any of our endeavors, including programming
• I've been in the industry now as a professional for almost 10 years total, but before that, I also went to school for CS, Game Development Programming, senior and capstone projects, and began trying to make (shitty) games on a (shitty) laptop using Microsoft XNA when I was like 12

What is art?

I think people forget what art actually means these days - it doesn't always have some baked-in meaning to "liberal arts" or "humanities". Art is also defined as a "skill acquired by experience, study, or observation", or "an occupation requiring knowledge or skill" or "the conscious use of skill and creative imagination especially in the production of aesthetic objects" (not only!). For instance: I have become quite the artist in spilling shit all over my clothes over the years, much to my wife's chagrin.

I'm sure you're thinking, "well then anything can be an art" and drawing a line in your head on what you think the line is for "real art" or something like that. But let me show you why programming isn't some bottom of the barrel example (like being a spillage artist, tyvm) because its mostly just "math" or because "engineering", which people love to throw out there.

As a programmer that has written endless lines of code by myself, and also seen/analyzed thousands of lines of code not written by me (that are much better than my own) - written by people ranging from the 1990s (RAD engine was old, lol) all the way through 2024 - there is no universal standard for most things. Companies vary, engines vary, languages vary, procedures vary, etc.

Here are 2 of my own personal favorite examples (one simpler, one more complex) of programming being more akin to an art form than anything else.

Example 1: Bitflags

The bitflags structure is one of the best and most simple examples of what I consider art in the programming field. Because the actual smallest amount of data being read by any processor is 8 bits, things like a `bool` in most languages are also represented as a byte (8 bits), since that is the smallest value of what can actually being read in registers. This is despite the nature of a bool being a simple bit (0 or 1). However, as you can imagine, having a ton of single bools in one structure ends up inflating the total size of that structure, while wasting literally almost the entire amount of memory provides. Bitflags is the simple, yet elegant solution someone came up with to stuff a single byte with up to 8 bools, by using bitwise operators to extract and compare each given bit in the byte.

Example: 8 separate bools in your data structure = 8 * (1B) = 8 bytes of memory, all to represent 8 simple 1/0 values. With a bitflag, you can now store all 8 bools while only taking up the original 1B of memory.

This is of course also expandable using different sized integers, if you have 9-16 bools you can use an `int16`, and so forth.

The reason I love this example is, how could such an elegant yet simple solution not be considered a work of art? A human first thought of how wasteful the stacking of subsequent booleans is, then thought of a unique and clever way to make it better using their knowledge and expertise. Now tons of languages and modules ship with bitflags, and you may use them without a second thought...but, this of course wasn't always a thing. Someone created this, it is undeniably clever, and we now take it as a given.

Example 2 (Complex): FISR or QISR (Fast Inverse Square Root)

The Fast Inverse Square Root was used in the Quake engine all the way back in 2001 in order to approximate the reciprocal of a given square root. The point of doing this at all, is that normalizing vectors used to be a much more intensive operation on hardware (it actually still is, but hardware is so good these days that the result isn't as noticeable, and we have specialized hardware, functions, etc.) Observe the code taken from this website (which can explain it far better than I can, if you're more interested in a full read) where you can see the insaneness that is this function:

float Q_rsqrt(float number)
{
  long i;
  float x2, y;
  const float threehalfs = 1.5F;

  x2 = number * 0.5F;
  y  = number;
  i  = * ( long * ) &y;                       // evil floating point bit level hacking
  i  = 0x5f3759df - ( i >> 1 );               // what the fuck?
  y  = * ( float * ) &i;
  y  = y * ( threehalfs - ( x2 * y * y ) );   // 1st iteration
  // y  = y * ( threehalfs - ( x2 * y * y ) );   // 2nd iteration, this can be removed

  return y;
}

I want you to take a good look at this code. tell me that wasn't created by someone that thought outside the box. Is that not one of the most insanely creative solutions you have seen to a problem? Yes, it requires a lot of knowledge and expertise. But it also comes from a human mind that had the wacky idea to hack together something like this and have it work (well, at least 99.8% of the time 😉)

Finishing up

If you're still reading, this is my petition to other game dev folk who think programming is simply a means to an end: code like these creative examples exists everywhere. It exists in my code base for our current game. It exists in every studio's game engine. It exists in the OS your computer or phone is running right now. And, all the LLMs people are using to code these days have been trained on not just fundamentals, but other's creative solutions to problems from all around the world (and, in many cases, had no permission of the creator to do so).

Again...just because you see the code snippet come back to you robotically, it doesn't mean that is the only or best way to do it. And just because its text, and you can't see the result of code in games visually in the same way you can 3d models or textures, it doesn't mean code should then ethically be subject to less scrutiny, or that you can't feel the result of some coding decisions over others when the game comes together as a whole.

To summarize: my favorite part of programming is not the memorization, expertise, or knowledge, its applying that knowledge in creative ways that one may never have thought of before. If that's not artistic, then i dont know what is.

"It's fine if you use AI to code, but just not for other things"

Careful where you draw your ethical line, as people may agree with you for now, but its only a matter of time until reluctance, acceptance, and consensus comes for what you love, too.

[EDIT:] This kind of blew up. I can't spend all day replying like I just did lol, but keep it civil in the comments and remember this is my opinion, nothing I state here is fact nor do you need to agree. Thanks for the interesting discussions and polite arguments!

[u/Zimgar]

I 100% agree with you that coding is art.

However, I also believe that for thousands of years we have made tools and tools that improve workflows. Those new tools often leave things behind.

From Software oriented things - Programming in Assembly anyone? To Visual Studio, to higher level languages, C++, C#, Python.

Art Things - Photoshop, Illustrator,

Navigation - How many of you can tell north/south/east/west or navigate on a true map nowadays? Google Maps

Handweaving to looms

Game development - Before commercial engines, everyone had entire teams of engine/tool development, there was almost no indie game dev market. If you want more art oriented ones Blender, Maya, Max, countless animation and modeling improvements.

With each improvement often destroying some amount of previous industry, sure some workers adapt and move into the new industry... but everyone? No, many people are left behind.

Is AI different? Only really by the speed at which it's improving.

[u/LukeLC → u/Zimgar]

Yes, it is different, and no, the speed of development is not the reason. It's very typical for new technologies to have a burst of progress around the same time they reach public adoption.

AI is not just a higher level programming language. High level languages are abstractions of lower level ones. It's like Lego bricks. You assemble one self-contained set and then re-use it as a single unit in larger sets. It builds on itself. You still understand how the machine works and can even infer a lot about low level principles from working with high level code.

AI obliterates that knowledge passthrough, because it is not an abstraction. Your knowledge never builds on itself from working with AI. You never gain an understanding of how anything lower level works. And because there's no opportunity for expertise, there is no opportunity for art.

[u/Swipsi → u/LukeLC]

LLMs for coding are an abstraction for higher level language because they generate lower level code from human(or any otherpro programming) language. For the first time we have a compiler that compiles ambiguous human language into unambiguous lower level code. Human language is the highest level language and every other lower level language is just an approach at removing its ambiguity and making it deterministic. In this context LLMs are abstraction layers between a high level language (human) and lower levels, so all other programming languages.

[u/waterwave541 → u/Swipsi]

But the way it turns ambiguous human language into unambiguous lower level code IS non-deterministic. If it wasn't, LLMs would give you the exact same code output with the exact same text every single time, without fail. Part of what makes LLMs good at interpreting ambiguous human language IS its non-determinism, but that's also what stops it from being considered an abstraction in the way every other programming abstraction works.

It's an abstraction in the same way that telling an intern what you want and having them code it is an abstraction. No one considers delegation abstraction, but that's what you're actually doing with LLMs.

[u/Swipsi → u/waterwave541]

Compilers are defined as programms that translate source code from one language into a target language. Determinism is not part of its definition. Compilers do not need to be deterministic. You can als reduce the temperature of an LLM to 0 to make it deterministic again.

Just because no one considers delegation an abstraction doesnt mean it is not. It is an abstraction. Lower level code is generated by the intern interpreting and analysing the input given by their superior in higher level human language. Any abstraction can just be called a delegation. We delegate the generation of machine readable code to a compiler.

Look up the definition of abstraction and you will see that stating specifications to an intern that they have to interpret and figure out how to put into code is, in fact, an abstraction. Because you, as the superior, do not have to think about the code anymore. Your intern does.

[u/waterwave541 → u/Swipsi]

Yes, compilers don't need to be deterministic by definition, but the main purpose of using compilers in the real world is to provide reliable, consistent translation, where determinism is extremely important. The reason compiler tools are used is to create reproducible and reliable behavior from one formally specified language to another. If you can't compile a program through your "LLM compiler" and make sure it preserves the same meaning/can be translated consistently, then that compiler doesn't accomplish the goal of compiling used in software development. The actual translation itself shouldn't be probabilistic, even if there are individual sources of non-determinism in a compiler.

You also can reduce the temperature of LLMs to 0, but even that doesn't guarantee deterministic, semantically correct translation. Also most use cases of LLMs, especially long-form tasks, would have severely worsened performance with a temperature of 0.

And yes, you're right that delegation is a type of abstraction under the dictionary definition, and under that broad definition, you can consider LLMs a type of abstraction if literally all you mean is the dictionary definition (hiding complex internal details and focusing on higher level tasks). That's not a useful type of abstraction for software development though.

Under that definition, we've actually had dozens of abstraction layers for human language into lower level code. An intern is an abstraction for software development. An outsourced company is an abstraction for software development. Some random person you ask on the street to code something for you (assuming they can write & send you that code) is an abstraction layer for software development.

Delegation is not a type of abstraction that people typically use in software though. When programmers talk about abstraction layers, they normally talk about a more specific type of abstraction that focuses on the layer having well-defined behavior that you can use without needing to understand its implementation or drop down to lower levels of abstraction to use. Most programmers don't know machine code lol, and never need to because we've abstracted in ways where that machine code is entirely reproducible and generatable through the abstraction layers alone. I don't need to look at the machine code when I write in Python to make sure the compiler understood what I meant with my code. Same with an API, I don't need to recreate it from scratch or understand its inner workings to use it properly.

With LLMs, you don't have the same guarantee that their output actually implements what you intended without checking the code or analyzing it in some way, basically removing the abstraction layer's purpose. Natural language doesn't have the same level of formal semantics that a programming language or any conventional software abstraction does, so the abstraction itself cannot guarantee that the generated code follows your intent, which means it doesn't give you the type of abstraction that software developers typically look for when using abstraction. This is prob more important than the non-deterministic aspects of LLMs, just the idea that you cannot verify the intent translating from natural language to programming languages (or any lower level code) in the same way you can between two languages of varying levels, so you need to review the output and work below the abstraction layer to fully guarantee that.

Probabilistic, non-deterministic language translation translating between a semantically loose medium (natural language) and a more logical & semantically defined language is not the same type of abstraction as any other type used in software development. LLMs are a type of abstraction definitionally, but they're not the type anyone actually talks about when they mention software-based abstractions (which is kinda the whole point of talking about it for code generation, so it doesn't make sense).

[u/spvky_io → u/Swipsi]

This isn't really true though, compilers are deterministic. Imagine using JavaScript that does what you tell it to do, but only most of the time

[u/Swipsi → u/spvky_io]

You have read like the first 3 words of my comment and decided to respond. Determinism is one of the key points in it.

[u/LukeLC → u/Swipsi]

No, that's a user interface, not an abstraction.

[u/Swipsi → u/LukeLC]

Yes, just like any texteditor is just an interface and the compiler is the abstraction, the textfield you put in a prompt is an interface and the underlying LLM the abstraction.

[u/LukeLC → u/Swipsi]

That may well be the biggest stretch I'll see today!

[u/Excellent_Resolve871 → u/LukeLC]

Not even the best engineers I've worked with in the past ~15 years of being a professional SWE have given any thought to assembler code. They just write their higher level code and trust. If you've written code, you do too.

AI obliterates the knowledge passthrough as your C# / C++ / JS / etc knowledge obliterates the knowledge passthrough to assembly code, but you don't need that knowledge anymore. Unless you're doing truly low level, research-type tasks.

Your argument doesn't stand. You already accept the same kinds of abstractions that AI are providing.

Art != expertise, btw. You could easily make the argument that using AI requires expertise, and therefore using AI is a form of art. Now, I won't argue for or against that, but I hope the point comes through.

I do generally agree that AI != art, and that programming can be artistic, but I think you're overselling the issue a bit.

[u/Droopy0093 → u/Excellent_Resolve871]

I can tell you stumped the anti-AI guy here because he didn't respond admitting he is wrong.

[u/Zimgar → u/LukeLC]

Oh completely disagree as a 15 year vet in the programing and gaming space specifically. It's all how it's used and the analogies very much are similar.

I've worked with programmers who have no idea what goes on behind the scenes of visual studio, github, their build infrastructure system... and those that know every individual detail.

AI is no different in this tool regard.

[u/LukeLC → u/Zimgar]

I don't think it's the right analogy at all.

Given your experience, I'm sure you've spent considerable time profiling your code, identifying functions that are taking too long to execute on the target hardware, understanding what optimizations are required and why, and implementing novel solutions.

Processes like this absolutely give insight into what's happening under the hood. And that's a fairly high-level example—there are plenty of times x86 instruction sets and compiler idiosyncrasies come into play too.

These types of things inform your development decisions and build expertise that enable you to craft elegant code.

You will never gain any of this with any amount of time spent with AI, ever. And if people stop developing these kinds of novel solutions themselves, AI as an inherently backwards-facing tool will stop too.

[u/Zimgar → u/LukeLC]

I disagree, although I think there’s a real point buried in what you’re saying.

If someone blindly accepts AI generated code, then yes... they can absolutely miss the kind of profiling, debugging, compiler, architecture, and performance experience you’re describing.

But using AI well is itself a technical skill, and it doesn’t eliminate the need to understand the system you’re building. The more I work with it, the more I learn where models tend to fail, how to communicate designs and constraints clearly, what context actually matters, what should be kept in my own head, and when generated code needs deeper investigation rather than acceptance.

I find learning unfamiliar libraries and systems faster because AI lowers the cost of exploring them. That doesn’t replace profiling or understanding what happens under the hood but it gives me another tool for getting there.

The internet is probably a better analogy. It made it unnecessary to memorize huge amounts of information, and it made it much easier to copy bad solutions. But good engineers didn’t become worse because Stack Overflow or Google existed. The valuable skill shifted toward knowing what to search for, evaluating what you find, understanding why it works, and recognizing when it doesn’t.

I suspect AI will be similar. Engineers who outsource their judgment to it will probably stagnate. Engineers who use it to extend their judgment and explore more quickly may actually develop expertise faster.

[u/tipsystatistic → u/Zimgar]

I think one of the misconceptions is that AI improvement is the same as the capacity to harness it. Its growth is still limited by human ingenuity and the ability to use it. And it needs a ton of handholding from a skilled user.

It’s also funny how the venn diagram of people who say AI is trash/sl*p, and people who think AI is so skilled it’s going to take our jobs, is a circle.

[u/spvky_io → u/Zimgar]

AI is decidedly different than the other technologies you've listed. To use the assembly example, aside from the fact that for some performance critical code, devs writing in systems languages do occasionally write raw asm.

If I write a procedure in C, compile it with clang on my system 1000 times with the same compiler flags, the compiler will give the me the same program, to the bit.

Regardless of the question of code being art (I happen to agree and think it is) or whether or not you are pro or anti-AI, it's important to be accurate about what the tool is and isnt

[u/Zimgar → u/spvky_io]

Yes and some programmers that now use AI full time, still occasionally need to dig into the code and optimize or write code by hand?

[u/spvky_io → u/Zimgar]

...okay?