> Project Hail Mary was predominantly practical effects

Don't drink the Kool Aid. The studios love to make this sort of claim — recent examples include F1: The Movie, Top Gun: Maverick, and Mission: Impossible – The Final Reckoning, and you'll see interviews where the main actors say it was all real — but it's just marketing.

Project Hail Mary leans heavily on CG. For example, while they did hire a puppeteer (he ended up voicing the alien!) to control a neat physical puppet on set, almost all of it was replaced with CG in post production, and only used for reference. Corridor Crew has a great breakdown [1]. They frequently provide a good counterpoint against fraudulent "no CG" claims.

[1] https://youtu.be/l9zqIo8KtjI?is=e7-3Wz_mnMdl2Yp8

You can have the most everyday-setting movie or TV show imaginable and still have it VFX'd to hell and back compared to something shot on film 30 years ago. Not even just like Ted Lasso faking the stadiums/fields they were on, but just retouching every single little thing.

While many of the things tou say are true, movies like PHM and other "predominantly practical" movies have so many effects that they put Marvel to shame.

I highly recommend the 4-part essay series "'No CGI' is just invisible CGI" https://youtube.com/playlist?list=PLgdTaHO8FLEve_XFiRBEcOSkR...

Just about every professional coding job I've ever had has had programmers eager to code more, complaining about how much rigmarole there is around making changes, complaining about constant meetings and endless bureaucracy around change management and requirements. Meanwhile business mostly saw programmer velocity and output as a problem and a business risk, as they struggled to keep up with the rate of change and kept stepping on the brakes.

Like realistically even without LLMs I output probably around 10x as much code working alone, self-employed with zero meetings or bureaucracy, than I've ever done as a professional programmer. My output sometimes rivals that of entire teams' I've been part of, mostly because I get to just code to my heart's content.

> Fall behind what? Able to produce "as much" what?

Customer meaningful features that move the needle on the business.

I think this is strictly true. And not because LLMs can write code faster. I think it's true even if you're still writing most of your code by hand and using the LLM as an assistant.

My anecdotal but decades-long observation is that most of the time=cost of a project comes not from writing code, but from dealing with "issues". Weird bugs, surprising behaviors, spec ambiguities, library defects, mysterious test failures, etc. Stuff that requires intense debugging and building out a mental map of code that might not even be yours. LLMs excel at this kind of thing, freeing you up to spend most of your time working on business logic.

This has certainly been my experience.

Yes, I dislike this kind of take so much. It keeps being repeated as a truthism and a way of putting down people that don't do what the speaker wants. It's fine to disagree, but there's no need to get such a threatening tone.

A lot of tech jobs seem to be only about sheer output volume, with quality (maintenability, availability, security, generally understanding what the thing is doing) not mattering much. In that case sure, LLM all the way and whatever happens happens. But not all jobs are like that.

This is very much an N=1 anecdote from a friend, but his manager has basically doubled velocity expectations for the team at his company over the last year. Everyone has to use Claude code because that's the only model they're allowed to use, and not using it means not hitting the arbitrary expectations.

Conversely, the company I am at has no such expectations, and we've got a legacy code base that LLMs aren't very handy in anyway.

It reminds me of people that get upset when other people aren't drinking as much as them at a party. It's like they need other people to consume the thing because they suspect that maybe their consumption will look a little problematic if other people aren't doing it to the same degree.

Those who do not transform themselves into paperclip maximizers will become paperclips.

I worked for a company that measures developer's output in number of commits, PRs created and approved, and Jira tickets per sprint. Management doesn't even insist on that the tickets have any kind of an effort estimate.

It can be pretty depressing, until you learn how to game the system - create tickets for yourself that are tiny amounts of work. I hear that it's getting harder to do that, because management is looking more carefully at tickets generated and it looks like they'll start having developers assign points to their tickets before the tickets are added to the sprint

* Those who refuse to use a calculator over a slide-rule will fall behind because they won't be able to produce as much

* Those who refuse to use a spreadsheet over calculator and paper will fall behind because they won't be able to produce as much

* Those who refuse to use a truck over horse drawn wagon will fall behind because they won't be able to carry as much

Seems pretty common sense to me, rathern than aggressive.

Those times are passing and you'll sooner or later meet with new reality.

It's marketing. The big AI companies know what they're doing and are trying to drive adoption with FOMO. Some people bought into the idea early on and feel self-important. Meanwhile, using AI is so easy that it's tantamount to pushing a button, because that's the whole point of it: to make things easy to do. You can pick it up in half an hour, so it's impossible to "fall behind," unless you're holding stock when the bubble inevitably crashes.

We have general expectations on the velocity an engineer should be able to work at. If it took someone 5 weeks to deliver the exact same feature another engineer could deliver in 1 week, that would be considered "falling behind" at most places. Would you disagree?

The notion of falling behind because you refuse to adopt an advance in the field seems both uncontroversial and not aggressive at all to me.

No, he is correct. LLMs have much larger working memories for the kind of details you work with in programming tasks. You are at an objective cognitive deficit by not taking advantage of this. Everybody knows what he means by left behind. When you program, you do so with a goal in mind, and you will not be able to reach that goal as quickly without LLMs. You will be outcompeted by those who use them, and this means that opportunities to contribute professionally, in open source, etc. will be closed to you.

This is the future. Adapt or die.

  127. A technological advance that appears not to threaten freedom often turns out to threaten it very seriously later on. For example, consider motorized transport. A walking man formerly could go where he pleased, go at his own pace without observing any traffic regulations, and was independent of technological support-systems. When motor vehicles were introduced they appeared to increase man’s freedom. They took no freedom away from the walking man, no one had to have an automobile if he didn’t want one, and anyone who did choose to buy an automobile could travel much faster and farther than a walking man. But the introduction of motorized transport soon changed society in such a way as to restrict greatly man’s freedom of locomotion. When automobiles became numerous, it became necessary to regulate their use extensively. In a car, especially in densely populated areas, one cannot just go where one likes at one’s own pace one’s movement is governed by the flow of traffic and by various traffic laws. One is tied down by various obligations: license requirements, driver test, renewing registration, insurance, maintenance required for safety, monthly payments on purchase price. Moreover, the use of motorized transport is no longer optional. Since the introduction of motorized transport the arrangement of our cities has changed in such a way that the majority of people no longer live within walking distance of their place of employment, shopping areas and recreational opportunities, so that they HAVE TO depend on the automobile for transportation. Or else they must use public transportation, in which case they have even less control over their own movement than when driving a car. Even the walker’s freedom is now greatly restricted. In the city he continually has to stop to wait for traffic lights that are designed mainly to serve auto traffic. In the country, motor traffic makes it dangerous and unpleasant to walk along the highway. (Note this important point that we have just illustrated with the case of motorized transport: When a new item of technology is introduced as an option that an individual can accept or not as he chooses, it does not necessarily REMAIN optional. In many cases the new technology changes society in such a way that people eventually find themselves FORCED to use it.)

It's extra weird because the Carmack quote immediately following seems to invalidate this very point!

Or at the very least: "It was never about the actual coding" and "coding more separates you from those who will fall behind" is classic kettel logic.

Designing good tests requires the most intelligence. Sometimes even more than writing the code itself. You have to fully understand the code, its uses, and its various edge cases.

Automating this away feels like massive folly.

Nothing about AI will stop people doing the work that brings them joy, be it stop motion, or hand knitting a jumper from yarn you made yourself from shearing your own sheep.

You just won't be able to get a job doing it. It will be a hobby, not a way to make a living.

Some of my colleagues say they don't want to be "AI proofreaders", that they'd prefer to do something else. I can't really argue, they are entitled to their own desires of course. But I do enjoy the chat sessions with agents. It's like pair programming with superman.

This is the path I'm on. I want to know enough about them to actually demonstrate their weaknesses when I choose to not use them for a given task. Upper management doesn't want to hear "because they suck" when they ask why. My company (and many others) just added a new "AI proficiency" metric to their hiring process, and I can take a hint.

How many dependencies do you review the source code of?

Or put the dependency in the unit tests so it's not part of the code base but able to be compared to the canonical implementation.

On the negative side, the code may not work.

But on the positive side, no dependencies.

My biggest gripe with AI is that I struggle to come up with even one real problem that it has solved in my daily life, and that of my family and friends.

Yes it might have made me a bit faster at some things I do for work. But it seems to me that we face so many challenges as a civilization, and AI doesn’t actively help with any of them? Unless you buy into the narrative that it will somehow usher in a golden age of abundance where everyone is taken care of and nobody needs to work anymore (utter BS in my opinion). The amount of capital flowing into it, that is then not available for other causes, is completely mind-boggling to me.

You can accomplish quite a lot with smaller local models on reasonably priced pro tier hardware (not cheap hardware, but very attainable hardware for anyone making average software engineer money). Qwen 3.6 27B and 35BA3, Gemma 28B, and so on are incredibly beneficial even if Anthropic and OpenAI produce better options.

Failing that, GLM 5.2 is open weights, trades blows with current frontier models and widely available on commodity inference providers. And you could run it yourself if you do actually have the resources.

Even with locally runnable small "open" models you are relying on scraps of others. They are much worse at the LLM game and you don't know when they stop releasing the weights.

How can you go the opposite direction? Instead of using LLMs to produce more code, can you produce less, maybe higher abstraction code?

If you're a hacker, which most of you are not (things have changed here over time), you will reject this.

You'll also recognize that the problem is not AI in general or LLMs in particular, but the proprietary entities that control the best models.

That's the part HN'ers seem to have the most trouble with. They protest AI qua AI, as if that's somehow going to help, when they should be fighting for independent development and universal access.

- Always us {} after if, even on single lines.

- Avoid using magic numbers and strings. There should be consts or even better enums.

- When working on a patch, you should other the test first. Watch the test fail. Then include the new code. And watch the test pass.

- Leverage early return and continue as much as possible to reduce code indentation.

- Only delete comments if they are obsolete. If you change code, make sure the comment above is still correct.

- Use enums instead of boolean for function parameters.

- Talk to me like an engineer. Don't be excessively verbose. Be down to the point.

- Don't use superlative. Stop praising me, give me the cold hard truth.

- Let the reader of the code breath. Add empty lines between logic block of code. Add a small to the point comment to explain what the block does.

- When you write unit tests, add a short comment at the beginning of the function and class to explain what they test and how they test it.

- Check commit message, if you proof read or write one, follow these 7 rules:

Rule 1: Separate the subject line from the body with a single blank line.

Rule 2: Limit the subject line to 50 characters (72 is the absolute hard limit).

Rule 3: Capitalize the first letter of the subject line.

Rule 4: Do not end the subject line with a period.

Rule 5: Use the imperative mood in the subject line (e.g., "Fix bug," "Add feature," not "Fixed" or "Adds"). Test formula: It must complete the sentence: "If applied, this commit will [your subject line here]".

Rule 6: Wrap the body text manually at 72 characters to prevent Git formatting issues.

Rule 7: Use the body to explain what and why vs. how. Assume the code explains the how; the message must explain the context and reasoning.

This is exactly right, but a lot of people have motivated reasoning about it. I can’t really blame them, the kind of shifts that AI is looking like it will bring are unprecedented, and usually when people claim big, world changing things will happen, they don’t, so most people are primed not to believe it.

However as you say, we already have the evidence about this one, and it would require some unknown wall to exist where AI could suddenly not improve further, and I’m just not seeing it. Most likely it will get more capable and cheaper as time goes on, and then every industry will be impacted the way software currently is.

I do find it rather curious that on a site where people value discussion, instead of answering my genuine question, people just downvoted the fact that it was asked in the first place.

LLMs are statistical prediction machines, they're always going to produce the most "average" code because they reproduce what they're trained on. Average code is bad, and it's going to get a lot worse as people's skills degrade and the training set degrades.

If the code isn't readable to humans, there's no particular reason to think it's going to be magically readable by LLMs either.

There have been a few movies that each revolutionised CGI in their own way. The Last Starfighter, flight of the navigator, tron, jurassic park, toy story, Terminator 2

Both were pretty influential. Roughly speaking I think a lot of people saw T2 and thought "wow, that looks really cool in a high-tech way" and a lot of people saw Jurassic Park and thought "wow, that looks really realistic". The silvery liquid terminator morphing into stuff was cool, but the natural-looking dinosaurs were cool in a complementary way.