

I think this is compatible with TDD. It’s just fancy divide-and-conquer.


I think this is compatible with TDD. It’s just fancy divide-and-conquer.
You need the problem space to be restricted to a manageable bunch of classes. If that’s not the case, split the problem until you get there.
Make sure you have 100% test coverage on this piece of code and that the tests are actually understandable and documenting the functionality well. You might find that there is unreachable code which should be deleted. Mutation testing may also help find code paths which are untested (and so edge cases you might not have considered).
Until that is true, write tests and/or refactor existing ones. At this point you may find a ton of new bugs there. Better find this now than later and then wonder whether your own changes introduced them. Your new failing tests will document the presence of those bugs.
By now you should have full documentation of what the code is supposed to do via tests. This will be tremendously helpful in understanding the code.
Then go public method by public method, line by line, renaming variables, extracting private methods etc. Your basic run-of-the-mill refactoring of classes, until you fully understand what’s going on in the production code.
For every small refactor, run the tests and commit if they pass. If they fail, you only have a small amount of uncommitted code which you know is the culprit.
Finally, fix any bugs you documented in the test writing stage.
At this point you can add any new functionality to the code.


In Big Ball of Mud projects, it’s easy to not notice AI generated code introducing more bugs into the codebase, slowly bringing the project to a halt and its inevitable death due to the rising cost-to-profit ratio of producing new features.
I’m guessing the project doesn’t have the tests, tooling or practices to catch even the more obvious bugs before they go to production. Now consider that LLMs are great at producing code that looks just right, but may behave differently than expected.
Finally, LLMs are said to be a productivity multiplier. Now what happens if you multiply bad practices…?
You seem aware of issues within the company. I assume you either voiced them and were ignored, or felt it was unsafe to do so.
My advice would be to think about what you would want your next project to be like. Something with more of a focus on quality, I imagine. Perhaps using DDD? Maybe remote, with less focus on churning out code and more focus on the actual requirements? Write your wishlist down, then start looking at job postings. Apply when one seems “good enough”. It will take a long time, you’ll get rejected a lot, but I bet you’ll eventually find something better.
This is incredibly disappointing…


Given the original announcement footage, it might be for the best…


I really want them to bring back self-hosting. Multiplayer games don’t need to have a limited lifespan.


If you need comments to explain what is happening (and not why it is happening), then you’ve got some bad code that needs refactoring.


I’m assuming it was hyperbole, not literal.


This seems a bit like missing the forest for the trees. Steam does not really let you know if the game is DRM-free, does not guarantee it will stay that way, and does not provide a reliable way to back these games up in a way where they could be used without the launcher.


Start selling games without DRM that only use the launcher to update and it’s better than steam.
So… GOG?


… Until your doctor starts pushing it because he saw it on Joe Rogan.


Kinda disappointing. I was hoping for a single-player-focused title.
Except “mass” is not useful by itself. It’s not a chair factory where more people equals faster delivery, just like 9 women won’t deliver a baby in a month. I wish companies understood this.


Ok, but the comment thread is about people preferring Bluesky to Mastodon, hence my confusion.


Isn’t the format literally just Twitter?


Over my dead body.
FYI there’s a fully playable unofficial port for Jak 1 and 2, and they’re working on the 3rd one: https://opengoal.dev/
I feel like I’d believe it if the headline was about John McAfee.


Good abstractions are important for the code to be readable. An AbstractEventHandlerManager is probably not a good abstraction.
The original commenter said that their code was “generic with lot of interfaces and polymorphism” - it sounds like they chose abstractions which hindered maintainability and readability.
Unit testing with LLMs is just asking an AI to hallucinate requirements.
Tests are what documents expected behavior and are therefore the worst candidate for code gen.