Doing things "faster" and "easier" is an interesting way to put it. It places all of the value on one's personal experience of using the AI, and completely ignores the quality of the thing produced. Which explains why most stuff produced by LLMs is throwaway garbage! It only reinforces the parent comment - there is virtually no emphasis on making things "better".
There is a funny, deep observation made by The Good Place character Michael (a non-human) that has stuck with me since. He says that humans took ice cream, which was perfect, and "ruined it a little" to invent frozen yogurt, just so they could have more of it. There's supposedly a 'guilt' angle there somewhere but I never felt guilty for eating "too much" ice cream so can't relate.
Still, this "making something worse so you can have more of it" shows up pretty much everywhere in human experience. Sometimes it's depressing, other times amazing to see what was achieved with that mentality, and it seems AI is just accelerating it.
There won't even be a quality conversation if a thing isn't built in the first place, which is the tendency when the going is slow and hard. AI makes the highly improbable very probable.
I agree. I think this is the LLM superpower: making quick prototypes that allow us to speak concretely about technical tradeoffs.
My comment was pointed at people who use AI specifically with the goal of making anything easier and faster. Doesn't matter what it is. "Faster and easier is better". as though doing more of the same shit are primary goals in themselves.
If you're using AI to explore better technical decisions, you're doing it right! AI can be a catalyst for engineering and science. But not if we treat it like a mere productivity tool. The quality of the thing enabled by the AI very much matters.
Doing things faster/easier means I now do most of these things whereas I didn't before.
Because I have limited time and energy. Take learning as an example:
I couldn't afford to spend a weekend learning the tradeoffs made by the top 5 WebGL JavaScript game engines AND generate the same demos for all of them to compare DX, and performance on my phone. And as I had more questions about their implementation I would have to scavenge their code again, for each question.
A sample of the questions I had (and as I asked it would suggest new question for things I didn't know I should ask):
- Do they perform sorting or are their drawing immediate? sort on z? z and y? z/y and layers? immediate'ish + layers? Frustum culling supported? What's their implementation for it if any?
- What are their GPU atlas strategies? fixed size? multiple with grouping by drawing frequency to reduce atlas switching? 2048? 4096? How many atlases? Does it build the atlas at boot or does it support progressive atlas sprite loading? How does it deal with fragmentation? What does it use for packing algo? Skyline ir something more advanced? How is their batch splitting behaviour and performance characteristics?
- Does it help with ECS? How is their hierarchical entity DX, if any? Does it math with matrices for transformations or simpler math? Shaders support? Do they use an Uber shader for most things? And what about polygons? Also, how do they help with texture bleeding? What's their camera implementation? Do they support spatial audio?
...and so on. Multiply the number of questions by at least 10.
And I asked LLM to show me the code for each answer, on all 5 engines.
This kind of learning just wasn't feasible for me before with my busy life.
So when I say "easier" it often means "made possible".
Finally let's not forget most of us in HN are incredibly privileged and can afford to learn futile things on the weekend. But for a great part of the less privileged population, having access to easier learning is LIFE CHANGING.
