Might be a weird suggestion but here we go: - use whatever diff tool you used before LLMs came around and actually review the code? Just a suggestion. If people claim they always examine the full output at the end before they commit it, then why not fully review it using the tools used before the dawn of LLMs?

Cool cool cool. So if you use LLMs as junior devs, let me ask you how future awesome senior devs like you will come around? From WHAT job experience? From what coding struggle?

What would you like individual contributors to do about it, exactly? Refuse to use it, even though this person said they're happier and more fulfilled at work?

I'm asking because I legitimately have not figured out an answer to this problem.

Why is that a developer's problem? If anything, they are incentivized to avoid creating future competition in the job market.

It's not a problem for the senior dev directly, but maybe down the road. And it definitely is a problem for the company once said senior dev leaves or retires.

Seriously, long term thinking went out the window long time ago, didn't it?

No, long term thinking didn't go out the window.

It is definitely a problem for the company. How is it a problem for the senior dev at any point?

What incentive do they have to aid the company at the expense of their own *long term* career prospects?

My last job there was effectively a gun held to the back of my head, ordering me to use this stuff. And this started about a year ago, when the tooling for agentic dev was absolutely atrocious, because we had a CTO who had the biggest most raging boner for anything that offered even a whiff of "AI".

Unfortunately the bar is being raised on us. If you can't hang with the new order you are out of a job. I promise I was one of the holdouts who resisted this the most. It's probably why I got laid off last spring.

Thankfully, as of this last summer, agentic dev started to really get good, and my opinion made a complete 180. I used the off time to knock out a personal project in a month or two's worth of time, that would have taken me a year+ the old way. I leveraged that experience to get me where I am now.

Ok, now assume you start relying on it and let's assume cloud flare has another outage. You just go and clock out for the day saying "can't work, agent is down"?

I don't think we'll be out of jobs. Maybe temporarily. But those jobs come back. The energy and money drain that LLMs are, are just not sustainable.

I mean, it's cool that you got the project knocked out in a month or two, but if you'd sit down now without an LLM and try to measure the quality of that codebase, would you be 100% content? Speed is not always a good metric. Sure, 1 -2 months for a project is nice, but isn't especially a personal project more about the fun of doing the project and learning something from it and sharpening your skills?

When the POS system goes down at a restaurant they'll revert to pen and paper. Can't imagine its much different in that case.

How do you get junior devs if your concept of the LLM is that it's "a principal engineer" that "do[es] not ask [you] any questions"?

Also, I'm pretty sure junior devs can use directing a LLM to learn from mistakes faster. Let them play. Soon enough they're going to be better than all of us anyway. The same way widespread access to strong chess computers raised the bar at chess clubs.

I don't think the chess analogy grabs here. In chess, you play _against_ the chess computer. Take the same approach and let the chess computer play FOR the player and see how far he gets.

Maybe. I don't think adversarial vs not is as important as gaining experience. Ultimately both are problem solving tasks and learning instincts about which approaches work best in certain situations.

I'm probably a pretty shitty developer by HN standards but I generally have to build a prototype to fully understand and explore problem and iterate designs and LLMs have been pretty good for me as trainers for learning things I'm not familiar with. I do have a certain skill set, but the non-domain stuff can be really slow and tedious work. I can recognize "good enough" and "clean" and I think the next generation can use that model very well to be become native with how to succeed with these tools.

Let me put it this way: people don't have to be hired by the best companies to gain experience using best practices anymore.

There's that long term thinking that the tech industry, and really every other publicly traded company is known for.

Maybe unpopular, but papers should be in n markdown flavor to be determined. Just to have them more machine readable.

Compared to HTML, Markdown is very bad at being mahcine-readable.

Not unpopular, but a lot of the publishing companies would have to agree to that and make their own formatting/structure rules.

I also haven’t had good luck with images/graphs/custom tables in anything but typist/latex.

It's my goto for new languages, but Gameboy instead of Chip8. It covers good parts of new languages when learning them.

Do you happen to have any resources on hand or advice for building a Gameboy emulator? It seems like a very interesting way to learn a new programming language.

Yes. The AI companies for the token usage.

My first manager at Amazon was like that. Loved him to pieces. He didn't micro-manage, he didn't even fully care about the scrum. Just said "I can see the ticket status myself. If you are blocked by something, need any info or resource, I'll hunt it down for you, otherwise you keep cooking".

Famous last words of empires. I doubt that if current situations continue that the US will in any sense be still thought of as the reserve currency.

Still daily driving an old x220 and a T480. Last time they were actually decent. You can pry them out of my cold dead hands.

I wish they'd make something like the x220 again.

Here's an idea for LLM makers: allow for a very rigid and structured Claude.md file. One that gives detailed instructions, as void of ambiguity as possible. Then go and refine said language, allow maybe for more than one file to give it some file structure. Iterate on that for a few years and if you ever need a name for it, you might wanna give it a name describing something that describes a program, or maybe if you are inclined enough....a programming language.

Have we really reached the low point that we need tutorials on how to coerce a LLM into doing what we want instead of just....writing the god damn code?

The just released FreeBSD 15 for example as a major release is supported until end of 2029, how much more LTS support do you want?

The minor point releases are close to a year in support. And that is only talking base system. Packages and ports you can also easily support yourself with poudriere and others.

As for backwards compatibility: FreeBSD has a stable backwards compatible ABI. That is why you can run a 11.0 jail on a 15.0 host. With zero problems.

Other way around is what doesn't work. You can't run a 15.0 jail on a 11.0 host for example. But backwards compatibility is definitely given.

[1]: https://www.freebsd.org/releases/15.0R/schedule/