Games routinely download a large update the moment they are installed, and this is read as a sign of rushed work. The real cause is a calendar gap built into how games are manufactured and approved.
The build is frozen long before the release date
A disc has to be pressed, packed and shipped to warehouses and shops around the world. That physical chain takes weeks and cannot begin until the code is final.
Console platforms also certify a build, checking it against technical requirements before it is allowed to be sold. Certification is a queue, and a failed submission means going round again.
The result is a lock date well ahead of the day players get the game. Everything the team learns after that date has to reach players some other way.
Development does not stop at lock
The team is still employed and the bug list is still open. Fixes found in the final weeks are real improvements that nobody wants to withhold.
Those fixes cannot go on the disc, so they accumulate into a patch that is ready before the game is even in shops. The patch is not a rescue; it is the difference between two dates.
Scale only becomes visible at launch
Some faults appear only when a large population plays simultaneously. Server behaviour under load, rare hardware combinations and unusual player routes through content are hard to reproduce internally.
Testing can simulate a fraction of that and never all of it. The first hours of public play are, in practice, the largest test the game will ever receive.
Studios plan for this by staffing a live response team for the launch window, which is an admission that the first week is part of development.
Patching changed what shipping means
Before broadband was standard, the shipped version was permanent, so the lock date carried enormous weight and schedules were built around it. That constraint disciplined scope.
Once updates became routine, the lock date turned into a milestone rather than a wall. Planning adjusted accordingly, and a certain amount of post-release work became expected rather than exceptional.
The cost lands on the launch experience
Players on release day face long downloads before anything is playable, and reviewers often work from a build that differs from the shipping one. Both weaken the first impression.
There is also a slow erosion of trust, because a large launch patch looks identical whether it contains polish or repairs. The player cannot tell the two apart from the download size.
That ambiguity is why the practice draws criticism even when the underlying reason is a manufacturing calendar rather than indifference.