My bet is working through an abstraction layer (LLMs) will make crafting a fun game more difficult. The art of designing a (great) game is in the details. English is not sufficient to communicate the individual strokes of a brush on canvas.
Also, thank you for sharing your experience. I recently joined that subreddit just to see what people are creating and I too have been unimpressed.
For months, I've been thinking of how to express or name this idea that people misname the way other people use coding agents and make bad assumptions about what sorts of tasks they could be used for, seemingly all in the service of demonstrating how derivative the end results must be. So thank you for whatever you've done to help dislodge the blocker for me.
I think there is a model in a lot of people's minds that AI coding is exclusively handing off the thought processes and ideation processes to the agent, which seems to foreclose on the possibility that it offers the least friction of any other available method to translate the users thoughts into useful artifacts, some of which are the working software that is the primary goal of development. The model says something like "I don't know what it needs to consist of, but make me this thing I'll know when I see.". But there are also plenty of people who have spent the time learning these skills before AI came along, and remain capable of performing those feats without the ai, but realize they are even more capable to do those same things with AI, in volumes that would have been previously prohibitively tedious. And now that they have the tedium wrangled, they are freed from all of these arguments that start: we can't do that because it would take forever.
> And now that they have the tedium wrangled, they are freed from all of these arguments that start: we can't do that because it would take forever.
I'm strongly skeptical of this argument, as there's only a few things you can not build a rough version and get something to ideate upon. Even with 3d games you can do design with blocks and buy models to have something to pinpoint the design.
This is still an incomplete model, in my opinion. You're still holding up what is possible as a non ai assisted developer as equal to the assisted one in the abstract, before adding in real world things like tedium, boredom, distraction, the ephemeral nature of novelty, frustration, and everything else that has derailed human software development, but inference engines are perfectly impervious to.
I can give you a concrete example: this week at work, it occurred to me that the 16 channels of expected and measured binary on or off test data I need to collect could benefit from a visualization because matching expectations will have visual properties that failures will not. So I had my AI agent create a script that encodes 16 channels of expected and measured binary wave forms over time, as a 32 channel 1Hz sampling frequency wav file, which I can view with audacity, which also has the necessary controls to measure time between transitions in the waveformms.
From hindsight, one could argue that since all of that solution consisted of rudiments of perfectly normal software that didnt need AI to be written or integrated, it was equally possible to create without AI. But knowing that could do it with the greatest of ease, for the total price of naming it, converted this from a project that required the motivation to figure out all of the necessary steps to one that just needed a good description.
I do get your point about speeds and ease of producing working code. This kind of quick win can be a good example of AI assisted tooling. But I don't generate scripts that way as I prefer to have composable blocks that I can reuse later. AI is not great at reusable code.
Another things I noticed with AI assisted programming is the one track thinking. Someone has an idea, generate a working sample and then it becomes like a sunk-cost fallacy where they don't envision any other implementation choice or design. It's about adding more feature without taking a step back and assessing the overall goal of the project and if that feature is really needed.
Antoine de Saint-Exupéry has said it best:
This kind of cohesiveness is often missed in projects that are AI assisted because there's no refinement step. The product and the efforts are not tempered by real world usage.But what about compositions of your reusable blocks an order of magnitude larger than you were ordinarily willing to manually compose? A lot of this misnaming Im circling around comes down to demanding that the ai user must be giving up their agency. Whatever you can name as a good practice you don't think an AI agent is a capable of employing on its own, I can retort that a human can demand the agent employ it, along with all of its other capabilities that outstrip the human typist.
You have to have the models the create tools for you to paint.
I have a side project which is an experiment to build an interesting quick UI for local AI. As part of it I want a very very specific, interesting look involving shaders, animations, and so on.
I was trying to just get a prototype in place by prompting and it was going nowhere, just constant yo-yo'ing and never really getting what I wanted. This also was quite de-motivating and I found myself "yelling" at the model.
So I told Codex:
- Make this API first-class in our framework, with easy parameters (it had been sort of a hacked low-level thing)
- Add hot reloading to our system so I can edit it without any state loss or refresh
- Give me more knobs (X, Y, Z) so I can tune everything here as I need
- Add a HUD that lets me also drag sliders to tweak the same things
And I got my desired look within a few seconds.
The principles of good design and products have always been this btw, you need your feedback loop to be as tight as possible. Good design has always come from the ability to iterate incredibly fast, your brush needs to move precisely with your hands, and can't have delay from the time you put it down to the time the stroke shows up.