hokapo

Hey, I just want to say that I rarely read so long comments, but now I did, and I'm glad I did. Thank you for the nuanced and honest takes, I share a lot of the same thoughts. I'm still a bit sceptical about the Dots and Duets and stuff, but maybe now less so. I may give Duet a try.

This is my experience too. I think people with no gamedev experience widely underestimate the challenge of good game design and the need for iteration with real people testing the game. In a similar way that an inexperienced game developer overestimates their skill to assess the fun and all the small details that matter, and will get demolished when it's first playtested by other people.

Does it store all your screen re recordings indefinitely? I'd imagine it's a lot of data. Or does it clean them up somehow and remove redundant or unnecessary ones?

Yeah, as I said in a reply to another comment, I oversimplified there. What I should have said is that solo or almost-solo gamedev with relatively small games is a good example of where AI shines. I don't have experience of developing larger games in larger teams.

> It would be useful if people _ever_ explained the use cases. Even Anthropic when they're publishing their materials are hand wavey about this.

Yes, good addition.

> I couldn't disagree more. I run an engineering team in GameDev, and AI is great at making a gigantic mess. It's great for generating a lot of code, but the minute that doesn't do what you want it to, you now need to go back and learn _everything_ that it's generated. And IME, doing that is as bad as having just written it yourself in the first place.

Yeah, I should have been more specific since our use cases are very different. I'm working solo on small games, so it's easier to keep the AI on a leash. I can imagine it can be a nightmare on large code bases with many collaborators.

> I tentatively agree here, except I've found about 50% of it is "fine", 40% of it is "this works but isn't really what I want to put into my product" and 10% is "absolutely not".

Yeah, probably our use cases are very different here too. We mostly develop/maintain dozens of microservices for internal use, mostly greenfield, relatively small in scope, and with 1-3 developers in each. And maybe 98% was a bit too optimistic. The larger and older the codebase, the more problems AI tends to create. But it's very good at helping to understand old codebases (even those written by myself haha).

Oh, and esoteric data science topics can be a minefield too. If there's a topic that's new to me, It's difficult to know what is hallucination and what is not. It's best to let AI suggest alternative methods and then study those yourself.

This right here is the truth. Too often people talk in abstract ways, not disclosing what they're actually working on. And then they tell their experiences as universal facts.

I think the main cause of different views is just the fact that people have very different products and codebases they're working on. Therefore, the requirements and applicability of AI varies a lot, case-by-case. It would be useful if people always explained their exact use cases when making claims one way or another. I understand it's not feasible for many use cases to reveal exact details, but at least some transparency would be great.

I've found AI to be immensely useful in gamedev, mainly UX development, research, and curation. In those areas I let it go quite wild, with mechanical and visual tests for UX, and summaries for research and curation. I've also made skills, custom subagents, hooks, and scripts (all made with AI assistance) to streamline development.

Gamedev is a good example of where AI shines, since the risks of fucking things up are not so big. If I worked on, let's say banking, I'd be much more careful. On my day job, as a data scientist (moving towards product owner) in a large industrial company, I'm much more careful. UX can run on vibes, but anything that touches data processing or business logic needs to be looked at by a human, row by row. Depending on use cases, it may be fine to look at only the tests. The main problem is that there's so much stuff to review, and maybe 98% of it is fine. It's then very boring to try to spot the 2%. I don't have good solutions for that yet, and idk if anyone does.

When I was a trainee at university, there was a math professor who worked similarly, with a bare text editor, when writing algorithms for his research. He said he wanted the coding to be slow, so he had time to think the problems through properly. When we automate all the routine away, there's no space for the creative thoughts that we get when our hands are busy.

It applies especially now, in the age of AI agents. When it's so fast to build things, I need to deliberately stop once in a while, and think if it's actually worth it to go down some rabbit hole, or if I should assess what the real problems are.

I think they are fine, and most major apps nowadays seem to follow them (for better or worse). Of course one can misuse them, as any other so-called "law", but in the context they're represented here, they make sense to me. I don't see problems with the Zeigarnik Effect either. It definitely does benefit the user to add their portfolio (more visibility to their profile) and verify their ID (likely a pre-requisite for getting paid?). The benefits of filling those could be made clearer in the UI though.

This is fun! But I feel it needs some onboarding/tutorial. Half the time I didn't understand why I can't take some money off the ground. Sometimes it said that I'm blocked because I need to first collect more money, but other times I didn't get any message and it seemed just random. Also, it seemed a bit random who was considered rammed and who was concidered the rammer. I think the concept has lots of potential, just needs some polish.