MurphyA/hacker-news huggingface dataset:
by r3trohack3r | 2025-06-02 22:15:49+00:00
I don’t know about you, but I use LLMs as gateways to knowledge. I can set a deep research agent free on the internet with context about my current experience level, preferred learning format (books), what I’m trying to ramp up on, etc. A little while later, I have a collection of the definitive books for ramping up in a space. I then sit down and work through the book doing active recall and practice as I go. And I have the LLM there for Q&A while I work through concepts and “test the boundaries” of my mental models.

I’ve become faster at the novice -> experienced arc with LLMs, even in domains that I have absolutely no prior experience with.

But yeah, the people who just use LLMs for “magic oracle please tell me what do” are absolutely cooked. You can lead a horse to water, but you can’t make it drink.
by cfallin | 2025-06-02 22:16:13+00:00
They're hitting another design point on the compile time vs. code-quality tradeoff curve, which is interesting. They compile 4.27x faster than Cranelift with default (higher quality) regalloc, but Cranelift produces code that runs 1.64x faster (section 6.2.2).

This isn't too surprising to me, as the person who wrote Cranelift's current regalloc (hi!) -- regalloc is super important to run-time perf, so for Wasmtime's use-case at least, we've judged that it's worth the compile time.

TPDE is pretty cool and it's great to see more exploration in compiler architectures!
by mjburgess | 2025-06-02 22:16:31+00:00
I use LLMs frequently also. But my point is, with respect to the scepticism from some engineers -- that we need to know what people are working on.

You list what look like quite greenfield projects, very self-contained, and very data science oriented. These are quite significantly uncharacteristic of software engineering in the large. They have nothing to do with interacting systems each with 100,000s lines of code.

Software engineers working on large systems (eg., many micro-services, data integration layers, etc.) are working on very different problems. Debugging a microservice system isn't something an LLM can do -- it has no ability, e.g., to trace a request through various apis from, eg., a front-end into a backend layer, into some db, to be transfered to some other db etc.

This was all common enough stuff for software engineers 20 years ago, and was part of some of my first jobs.

A very large amount of this pollyanna-LLM view, which isnt by jnr software engineers, is by data scientists who are extremely unfamiliar with software engineering.
by dsr_ | 2025-06-02 22:17:32+00:00
Think DNS vs IP.

"Hey, Kentrak! I'm concerned about 2600:1401:d000:38a::1aca."

versus

"Hey, Kentrak! I'm concerned about the Akamai node that's answering for www.apple.com!"

If you are staring at the same one for hours upon hours, you might remember the number. I'm saying that any time someone is referencing a CVE in any other context, they should use a memorable, informative, searchable, non-clickbaity name.

Previously I have expressed negative feelings about people claiming Heartbleed, Shellshock, and so forth -- they are unnecessarily dramatic. Now I feel that we need a middle course.
by jacobgkau | 2025-06-02 22:17:49+00:00
> We should embrace technological changes that render expertise economically irrelevant with open arms.

To use your example, is using AI to file your taxes actually "rendering [tax] expertise economically irrelevant?" Or is it just papering over the over-complicated tax system?

From the perspective of someone with access to the AI tool, you've somewhat eased the burden. But you haven't actually solved the underlying problem (with the actual solution obviously being a simpler tax code). You have, on the other hand, added an extra dependency on top of an already over-complicated system.
by TheRoque | 2025-06-02 22:17:50+00:00
One of the biggest anti LLM arguments for me at the moments is about security. In case you don't know, if you open a file with copilot active or cursor, containing secrets, it might be sent to a server a thus get leaked. The companies say that if that file is in a cursorignore file, it won't be indexed, but it's still a critical security issue IMO. We all know what happened with the "smart home assistants" like Alexa.

Sure, there might be a way to change your workflow and never ever open a secret file with those editors, but my point is that a software that sends your data without your consent, and without giving you the tools to audit it, is a no go for many companies, including mine.
by consumer451 | 2025-06-02 22:18:01+00:00
I am just some shmoe, but I believe that devs fall into to major categories when it comes to LLMs: those with their own product ideas, and those without their own product ideas.

The prior look upon Claude Code/Cursor/Windsurf much more favorably, as they are able to ship their ideas much faster.

This is a bit of a hot take, so I would love any replies to bring me back down to earth.
by abdullin | 2025-06-02 22:18:45+00:00
My current workflow with Codex is (coding environment from OpenAI):

(1) Ask to write an implementation plan for a specific change or a feature. It will go through the source code, look up references, make notes and produce a plan

(2) Review the plan. Point out missing things, or stuff that needs improvement.

(3) Once I'm satisfied with the plan - ask to draft PR. Launch a few attempts in parallel and pick the one that I like the most.

(4) While drafting PR, Codex will run unit tests (even can run E2E tests in its container), linting and type checkers at every single step. This helps a lot with the stability.

(5) I review the code and merge the PR if I like it. Ask to cleanup - if not.

This feels like working with a remote team - very patient and diligent at that.

Ultimately, I get to get more features done per day. But I also feel more tired by the end of the day due to a higher level of cognitive load. There are more decisions to make and less idle time (e.g. no more hours spent tidying up the code or doing relaxing and pretty refactoring).

TLDR; this AI thing works really well at least for me. But it comes with trade-offs that might slow down its adoption by companies en masse.
by hbroadbent | 2025-06-02 22:18:48+00:00
Honestly, if you've found something that works for you, I'd stick with it.

Once (if) you start scaling one of your apps, that's when I'd loop back to thinking about infra: either yeah considering something semi-managed like Hatchbox, or even fully managed like DO.

(Hatchbox does actually integrate with managed database instances like those from DigitalOcean which is pretty cool imo)
by sshine | 2025-06-02 22:19:29+00:00
> This isn’t my bragging about money.

I get it. Simple living. Don’t own things you can borrow for free or rent cheap. I really see how that makes for quality of life. My brother lives simply but more luxuriously. He owns less and spends more on experiences. I see that saving things you can use in 5 years isn’t really maximising total wealth or convenience, so it’s just a deep affection for a ton of crab.
by bigyabai | 2025-06-02 22:19:49+00:00
NixOS "solves" this, albeit with a pretty archaic configuration language and deep buy-in. The end result is that I now keep a Git repo with 95% of my Linux config represented as modules. Then I install each module as-needed (eg. terminal.nix for terminal config, desktop.nix for desktop config) for the devices I use and rebuild it with that set of modules.

Works great, even with my laptop, desktop and server sharing the same config. Versioned rollback + nixpkgs has kept me happy for about 4 years with this setup.
by synack | 2025-06-02 22:19:59+00:00
There are 15 competing standards: https://xkcd.com/927

Augeas [1] does a decent job of translating various formats into a common AST which you can edit and write back out, but setting this up is often more trouble than just editing/templating whatever config and moving on with your life.

Many new projects go straight for YAML/TOML/JSON/INI as they're widely understood and relatively easy to parse. I think this is as close to standardization as you'll get.

OpenBSD's developers have gone in the other direction, defining domain specific configuration languages for each of their daemons. They're all different, but they look similar enough that it feels like a cohesive system. You can look at the yacc grammar and see how httpd's config [2] got started as a fork of relayd [3].

[1] http://augeas.net/

[2] https://github.com/openbsd/src/blob/master/usr.sbin/httpd/pa...

[3] https://github.com/openbsd/src/blob/master/usr.sbin/relayd/p...
by timr | 2025-06-02 22:20:10+00:00
Yeah...I've toyed with that, but there's still a productivity maximum where throwing it all away and starting from scratch is a worse idea, probabilistically, than just fixing whatever thing is clearly wrong.

Just to make it concrete, today I spent a few hours going through a bunch of HTML + embedded styles and removing gobs and gobs of random styles the LLMs glommed on that "worked", but was brittle and failed completely as soon as I wanted to do something slightly different than the original spec. The cycle I described above led to a lot of completely unnecessary markup, paired with unnecessary styles to compensate for the crappiness of the original DOM. I was able to refactor to a much saner overall structure, but it took some time and thinking. Was I net ahead? I don't really know.

Given that LLMs almost always write this kind of "assembled from StackOverflow" code, I have precisely 0% confidence that I'd end up in a better place if I just reset the working branch and started from scratch.

It kind of reminds me of human biology -- given billions of years of random evolution you can end up with incredible sophistication, but the end result will be incomprehensible and nearly impossible to alter.
by duskwuff | 2025-06-02 22:20:23+00:00
> - this only applies to task-focused jobs; e.g. the service industry still needs people to work all the time customers might turn up

This is a problem which service industry jobs have already solved by scheduling employees in shifts. A typical fast food restaurant may be open 18+ hours a day, 7 days a week, but they certainly aren't requiring each of their employees to work those hours.
by jongjong | 2025-06-02 22:20:38+00:00
I believe that AI is very useful in software development but I don't buy the narrative that AI is responsible for layoffs over the past few years (at least not most of them). I think that narrative is a convenient cover for systemic misallocation which created a need to contain inflation. I think big tech execs understood that, beyond increasing their company stock prices, they also need to work together to keep the monetary system itself under control. This is why they've been firing people whilst having record profits. They've reached such scale and the system has reached such fragility that they have to think and act like economists to keep the thing going. The economy itself has become the responsibility of big tech.

But who knows, maybe AI will accelerate so rapidly that it will fix the economy. Maybe we'll have robots everywhere doing all the work. But I worry about the lack of market incentives for people to adapt AI to real world use cases.

For example, I'm an open source developer who likes to tinker but I've been booted out of the opportunity economy. I can't afford to program robots. People like me are too busy using AI to parse spreadsheets and send targeted ads to even think about automating stuff. We work for companies and have no autonomy in the markets.

If things had worked out differently for me, I'd probably own a farm now and I'd be programming robots to do my harvest and selling the robots or licensing the schematics (or maybe I'd have made them open source, if open source had worked out so well for me). I don't have access to such opportunity unfortunately. The developers who worked for big tech are good at politics but often disconnected from value-creation. Few of them have the skills or interest to do the work that needs to be done now... They will just continue leveraging system flaws to make money, so long as those flaws exist.
by dimal | 2025-06-02 22:20:40+00:00
> a novice who outsources their thinking to an LLM or an agent (or both) will never develop those skills on their own. So where will the experts come from?

Well, if you’re a novice, don’t do that. I learn things from LLMs all the time. I get them to solve a problem that I’m pretty sure can be solved using some API that I’m only vaguely aware of, and when they solve it, I read the code so I can understand it. Then, almost always, I pick it apart and refactor it.

Hell, just yesterday I was curious about how signals work under the hood, so I had an LLM give me a simple example, then we picked it apart. These things can be amazing tutors if you’re curious. I’m insatiably curious, so I’m learning a lot.

Junior engineers should not vibe code. They should use LLMs as pair programmers to learn. If they don’t, that’s on them. Is it a dicey situation? Yeah. But there’s no turning back the clock. This is the world we have. They still have a path if they want it and have curiosity.
by observationist | 2025-06-02 22:20:46+00:00
It's being looked at as an AI signal, which is causing labs to artificially suppress it, so it may end up being a "human-authored" signal in the end. Give it a year or two, though, and we're looking at AI with superhuman word choice. There will be dozens of layers of introspection underlying the selection of each word, in a broad context, articulating exactly whatever the user wants. The philosophical and psychological implications of superhuman text generation, beyond the p(doom) discussions, gets crazy. Superhuman persuasion is one facet, but unintended manipulation through reinforcement of secondary and peripheral notions in the context create all sorts of weirdness.

Language communicates ideas, and we've made machines that produce intricate, sophisticated ideas that land in our brains. The consequences are going to be fascinating.
by geraltofrivia | 2025-06-02 22:20:47+00:00
Location: France Remote: yes Willing to relocate: no Technology: pytorch; numpy; pandas; transformers; LLM inference; sparql; RAG; OpenAI, anthropic APIs etc; static analysis.

About me: Doing NLP (research, then industry, then failed PhD attempt ~3yr, then industry) since 2015. Worked extensively with transformers (and RNNs, pre-transformers) including BERT* models, and thereafter with LLMs. Worked extensively on query generation from free text. Currently happily employed in Switzerland, but want to move to France to be with my SO.

LinkedIN -- https://www.linkedin.com/in/priyansh-trivedi-3578442a2/

Email: mail [at] priyansh [dot] page
by camhayes | 2025-06-02 22:20:49+00:00
Location: Jacksonville, Florida, USA

Remote: Impartial

Willing to relocate: Yes (preferred)

Languages: TypeScript, Python, C#, Java, PHP, SQL

Technologies: .NET, Angular, React, Node.js, SQL Server, Hugging Face

Résumé/CV: https://bit.ly/3FD1iPh

LinkedIn: https://www.linkedin.com/in/cammatthewhayes

Email:cam@camhayes.dev

I am a full-stack developer with 10+ years of experience building user-centric applications and APIs. I have a passion for building scalable and reliable software, machine learning, and data governance tools. My background is primarily in full-stack development, and I am excited to explore opportunities across different engineering domains with an emphasis on machine learning engineering. I am currently looking for remote and/or hybrid careers, particularly with relocation in Europe.
by citizenpaul | 2025-06-02 22:21:00+00:00
Yeah exactly.

Whats nuts is watching all these people shill for something that we all have used to mediocre results. Obviously Fly.io benefits if people start hosting tons of slopped together AI projects on their platform.

Its kinda sad to watch what I thought was a good company shill for AI. Even if they are not directly getting money from some PR contract.

We must not be prompting hard enough....
by jsnell | 2025-06-02 22:21:03+00:00
Thanks,

I believe the API prices are not subsidized, and there's an entire section devoted to that. To recap:

1) pure compute providers (rather than companies providing both the model and the compute) can't really gain anything from subsidizing. That market is already commoditized and supply-limited.

2) there is no value to gaining paid API market share -- the market share isn't sticky, and there's no benefit to just getting more usage since the terms of service for all the serious providers promise that the data won't be used for training.

3) we have data from a frontier lab on what the economics of their paid API inference are (but not the economics of other types of usage)

So the API prices set a ceiling on what the actual cost of inference can be. And that ceiling is very low relative to the prices of a comparable (but not identical) non-AI product category.

That's a very distinct case from free APIs and consumer products. The former is being given out for no cost in exchange for data, the latter for data and sticky market share. So unlike paid APIs, the incentives are there.

But given the cost structure of paid APIs, we can tell that it would be trivial for the consumer products to be profitably monetized with ads. They've got a ton of users, and the way users interact with their main product would be almost perfect for advertising.

The reason OpenAI is not making a profit isn't that inference is expensive. It's that they're choosing not to monetize like 95% of their users, despite the unit economics being very lucrative in principle. They're making a loss because for now they can, and for now the only goal of their consumer business is to maximize their growth and consumer mindshare.

If OpenAI needed to make a profit, they would not raise their prices on things being paid for. They'd just need to extract a very modest revenue from their unpaid users. (It's 500M unpaid users. To make $5B/year in revenue from them, you'd need just a $1 ARPU. That's an order of magnitude below what's realistic. Hell, that's lower than the famously hard to monetize Reddit's global ARPU.)
by aucisson_masque | 2025-06-02 22:21:38+00:00
> Professional software developers are in the business of solving practical problems for people with code. We are not, in our day jobs, artisans. Steve Jobs was wrong: we do not need to carve the unseen feet in the sculpture. Nobody cares if the logic board traces are pleasingly routed. If anything we build endures, it won’t be because the codebase was beautiful.

I think it comes all down to that, do you have pride in what you do or you don’t ?

I make a wall with bricks, even if it will be covered with coating i will do my best to have regular joints and pacing.

Could make it faster, no one would notice the difference but me… i hate that feeling when you done something and you know it’s barely enough, just barely, it’s kind of shit and you really don’t want others to see it.

On the opposite side, some people will take pride in building wall twice as fast as me and won’t care it’s horrendous.

Both cases are valid, but me i know i can’t do a work I’m not proud of.
by matt_s | 2025-06-02 22:21:54+00:00
> This was the craftsman’s ‘Golden Age’ and much time and trouble was taken over the design of tools. Craftsmen were being called upon to do more skilful and exacting work and the use of tools and the interest in development had become very widespread.

Above pulled from A Brief History of the Woodworking Plane [0]. A woodworking tool that has evolved over 2,000 years. Now there are electric planers, handheld electric planers and lots of heavy machinery that do the same thing in a very automated way. If a company is mass producing kitchen cabinets, they aren't hand planing edges on boards, a machine is doing all that work.

I feel like with AI we are on the cusp of moving beyond a "Golden age" and into an "industrial age" for coding, where it will become more important to have code that AI understands vs. something that is carefully crafted. Simple business pressure will demand it (whether we like it or not).

^ A comment I made just yesterday on a different thread.

For software developers AI is like the cabinet maker that gets a machine to properly mill and produce cabinet panels, sure you can use a hand plane to do that but you're producing a very different product and likely one that not many people will care about, possibly not even your employer when they see all the other wood shops pumping out cabinetry and taking their market share.

[0] https://www.handplane.com/879/a-brief-history-of-the-woodwor...
by mrguyorama | 2025-06-02 22:22:06+00:00
Understanding code takes more effort than writing it, somehow. That's always been a huge problem in the industry, because code you wrote five years ago was written by someone else, but AI coding takes that from "all code in your org except the code you wrote in the past couple years" to "all code was written by someone else".

How well does your team work when you can't even answer a simple question about your system because nobody wrote, tested, played with the code in question?

How do you answer "Is it possible for our system to support split payments?" when not a single member of your team has even worked on the billing code?

No, code reviews do not familiarize an average dev to the level of understanding the code in question.
by killerstorm | 2025-06-02 22:22:06+00:00
I think a large fraction of my programming skills come from looking through open source code bases. E.g. I'd download some code and spend some time navigating through files looking for something specific, e.g. "how is X implemented?", "what do I need to change to add Y?".

I think it works a bit like pre-training: to find what you want quickly you need to have a model of coding process, i.e. why certain files were put into certain directories, etc.

I don't think this process is incompatible with LLM use...
by btown | 2025-06-02 22:22:08+00:00
This is a bit stronger than my point, I should say. I do think that LLMs would have a net benefit to society, by way of their effects on research and innovation... if we could get our political houses in order such that we weren’t negating those effects, and such that we were empowering small businesses and high-tech startups to build with the results of this innovation sustainably.

And in a world where policy is horrid and the effects are mainly negated, things would be even worse if the remaining researchers lost AI as a tool. For better or for worse, fire has been shared with humanity, and we might as well cook.
by deanCommie | 2025-06-02 22:22:25+00:00
I'm sure salt miners needed to make peace with their toil and also focused on tools and techniques to be more productive; how to remove the salt most elegantly in nice clean blocks, minimize waste, reduce burden on their physical bodies.

But to their bosses their output was salt.

I'm sorry but unless you're working in open source for the pure love of the tech/craft, the output of software engineering is PROBLEM SOLVING.

That's why "build vs. buy" exists - sometimes it's better to buy a solution than buy one. That's why a valid solution to a problem sometimes is to convince a customer that their ask is wrong or unreasonable, and something simpler or easier would get them 99% of what they need with 1% of the effort.

That's our job.
by cinci | 2025-06-02 22:22:35+00:00
Location: Dubai, UAE (EU citizen)

Remote: Yes

Willing to relocate: Yes

Technologies: Penetration testing, Reverse engineering, Python, C, Assembler, Low-level development, Emulation, Embedded, Electronics, Linux/Unix/BSD/Windows

GitHub: https://github.com/chris-pcguy

Email: chris.jobshn2506@broke-the-inter.net

Spare time project(s): co-developing an iPhone emulator

Hi,

Preferred positions: Penetration tester > Reverse engineer > Embedded > Software developer

I would be glad to hear from you.