MurphyA/hacker-news huggingface dataset:
by vineethy | 2026-02-02 19:26:01+00:00
strongly disagree with this article. I think using the tools can actually directly lead to a junior engineer getting closer to a senior engineer. Telling junior engineers that they have to get better at typing out code in order to be better engineers misses what actually makes someone a better engineer.

It's worth actually being specific about what differentiates a junior engineer from a senior engineer. There's two things: communication and architecture. the combination of these two makes you a better problem solver. talking to other people helps you figure out your blindspots and forces you to reduce complex ideas down to their most essential parts. the loop of solving a problem and then seeing how well the solution worked gives you an instinct for what works and what doesn't work for any given problem. So how do agents make you better at these two things?

If you are better at explaining what you want, you can get the agents to do what you want a lot better. So you'd end up being more productive. I've seen junior developers that were pretty good problem solvers improve their ability to communicate technical ideas after using agents.

Senior engineers develop instincts for issues down the road. So when they begin any project, they'll take this into account and work by thinking through this. They can get the agents to build towards a clean architecture from the get go such that issues are easily traceable and debuggable. Junior developers get better at architecture by using agents because they can quickly churn through candidate solutions. this helps them more rapidly learn the strengths and weaknesses of different architectures.
by adam_arthur | 2026-02-02 19:26:31+00:00
Yes!

I've found the same principles that apply to humans apply to LLMs as well.

Just that the agentic loops in these tools aren't (currently) structured and specific enough in their approach to optimally bound abstractions.

At the highest level, most applications can be written in simple, plain english (expressed via function names). Both humans and LLMs will understand programs much better when represented this way
by stego-tech | 2026-02-02 19:26:39+00:00
Bugfixes and security vulnerabilities, mostly. So long as fallible humans make fallible hardware running fallible software that in turn executes and/or compiles fallible code, there will always be a need for continued development of critical tooling and packages.

On a long enough timeline, those fixes become fewer and less frequent as the codebase improves, but there is no "done" in software unfortunately. Hell, entropy itself means nothing is ever done, just in an ever-changing state.
by idle_zealot | 2026-02-02 19:27:09+00:00
There are mixed views here. Some are making the claim relevant to the Silver Bullet observation, than LLMs are cutting down time spent on non-essential work. But the view that's really driving hype is that the machine can do essential work, design the system for you, and implement it, explore the possibility space and make judgments about the tradeoffs, and make decisions.

Now, can it actually do those things? Not in my estimation. But from the perspective of a less experienced developer it can sure look like it does. It is, after all, primarily a plausibility engine.

I'm all for investing in integrating these generative tools into workflows, but as of yet they should not be given agency, or even the aesthetic appearance of agency. It's too tempting to the human brain to shut down when it looks like someone or something else is driving and you're just navigating and correcting.

And eventually, with a few more breakthroughs in architecture maybe this tech actually will make digital people who can do all the programming work, and we can all retire (if we're still alive). Until then, we need to defend against sleepwalking into a future run by dumb plausibility-generators being used as accountability sinks.
by nozzlegear | 2026-02-02 19:27:10+00:00
IMO the problem with Discord is it encourages forming cliques and community fragmentation. I think anyone who's used Discord for long enough has seen their favorite server inevitably add so many channels that the discussion gets spread out and diluted to the point that the server feels dead, even though it might have hundreds of members. At the same time, your most active users eventually form their own group DMs with other active users that they get along with, while posting less and less in the main server.

Discord actively encourages this by making it so easy to form group DMs and splinter servers (a good thing from a user's perspective, but a community-killer from the server's perspective). And financially, it's probably more profitable for Discord to do it that way too.
by simonleeb | 2026-02-02 19:27:14+00:00
I think the balancing act of code size (how fat your WASM binary will be) and DX/comfort in Swift is tricky.

Just as an example:
JSON data - Including a Swift serializer adds code size, but bridging to JS is a bit less comfortable. And for each similar feature we will need to find a good compromise. We need to be careful not to create a "parallel universe" of Swift, where everything works completely differently from "normal Swift" - but at the same time things like 'import Foundation' won't fly on the web.

And, of course, things like HMR or "module splitting" and other more dynamic features are much, much tougher to do with a compiled language and Wasm. So, trying to reach "DX-parity" with JS frameworks can be a very pricy endeavor.

I think Swift adoption in general is also a ... factor. I personally think it is way more ergonomic to write than most languages, especially for UI and app-level stuff, while bringing a lot to the table. But as - we all know - it is still hasn't grown to its potential outside of Apple-land.

Embedded Swift is a moving target, but I am confident it delivers (it's evolving rapidly). Also, Wasm is a moving target to a degree.

And then there is just a ton to do, none of which a "great challenge", but just the grind of moving towards a "fully-featured UI framework"...
by phicoh | 2026-02-02 19:27:24+00:00
There have always been young people who can quickly hack something together with whatever new tools are available. That way of working never lasts, but the tools do last.

When tools prove their worth, they get taken into to normal way software is produced. Older people start using them, because they see the benefit.

The key thing about software production is that it is a discussion among humans. The computer is there to help. During a review, nobody is going to look at what assembly a compiler produces (with some exceptions of course).

When new tools arrive, we have to be able to blindly trust them to be correct. They have to produce reproducible output. And when they do, the input to those tools can become part of the conversation among humans.

(I'm ignoring editors and IDEs here for the moment, because they don't have much effect on design, they just make coding a bit easier).

In the past, some tools have been introduced, got hyped, and faded into obscurity again. Not all tools are successful, time will tell.
by throw0101a | 2026-02-02 19:27:35+00:00
> Why should something like sudo not be "done" after 30 years?

Because new needs arise over time. For example, when I started in IT the "sudoedit" functionality was not present and so allowing someone to do "sudo vi …" would allow them breakout of the editor when it was running as root.

With sudoedit you can give people permissions to edit particular files with elevated permissions.

> Even OpenBSD gave up and implmented their own simplified replacement (doas).

They did not "give up": they found they needed only much simpler functionality shipped in the base OS. For example, sudo has functionality to talk to LDAP (which I've used at multiple jobs over the years), but is not needed for a local-only box. Once you need centralized account and privilege management, doas becomes much less useful.
by constantcrying | 2026-02-02 19:27:40+00:00
The hardware itself is utilized by many pieces of software on any Apple device. Face ID uses it, Siri uses it, the camera uses it, there are also other Apple on device LLM features, where you could easily test whether the basic capabilities are there.

I highly doubt that you could have a usable iPhone with a broken neural engine, at the very least it would be obvious to the user that there is something very wrong going on.
by rpastuszak | 2026-02-02 19:27:51+00:00
Oh boy, I have I've been working with offline-first web apps since the late 2000s... then the particular app I have in mind has been used as a PWA for the past 6-7 years.

I really, really, love building stuff for/on the web. When working with founders/clients we'd often start with building the MVP as a PWA, because of how easy it is to iterate and test. (https://untested.sonnet.io/notes/web-and-feedback-loops/)

That said, some reasons off the top of my head in random order:

- seemingly small but UX critical features breaking or not working at all (wake, audio, notifications, scroll breaking).

- most of the users don't know/haven't been taught they can install a site or assume that PWAs are inherently worse

- PWAs are harder to monetise (no super easy way to let the user pay a lifetime licence for the app, customers want super easy, and that's not for me to judge)

- critical, but non-obvious to a non-technical person (and thus difficult to explain) features are unstable or janky on iOS when running standalone/via home screen (example: wiping offline storage every few days).

In some ways things work better than, say 10 years ago, but at the same time there's the *unpredictability*. I really don't want to worry about my app breaking in some impossible to fix way next year. Not, when the app is meant to pay my rent.

Performance was rarely an issue, discounting experiments like running image recognition inside a "service worker" in JS, on iPhone 7 for an AR game I was messing with. That was in 2016 (before Pokemon Go came out and kind... of dumbed down the idea or AR).
by Esophagus4 | 2026-02-02 19:27:59+00:00
Yeah, exactly.

While I’ve been watching it, it seems like the narrative of value has rotated between:

- BTC will be a global currency (this has only proven true for illicit activity)

- BTC will be a hedge against inflation like gold (this has also not been correct recently)

- BTC is a store of value??? Which is just circular reasoning… you should buy it because other people are buying it

Idk man, what do I know
by samoube | 2026-02-02 19:28:14+00:00
thelab | New York, NY (Hybrid) | Senior Backend Developer | https://thelab.co | Full-Time | $160-165K + benefits

We're a digital agency focused on e-commerce, marketing, creative production and increasingly, AI-powered workflows to make our own teams more productive. We're hiring a senior backend developer to lead a greenfield ML/NLP project building workflow automations across image production, design, analytics/performance reporting and more.

You'll work on a growing team on the technical side with—with access to talent in every department as we build tools to support our internal processes.

Stack: Typescript, Python, Django, Node, Docker, Kubernetes, AWS, Terraform

Apply: https://thelabnyc.bamboohr.com/careers/189?source=aWQ9Mjk%3D
by seanhunter | 2026-02-02 19:28:21+00:00
The oxford english dictionary disagrees with you.

https://www.oed.com/search/dictionary/?scope=Entries&q=ooh

"Ooh" is most certainly a word. As is both "Ah" and "Aah"
https://www.oed.com/dictionary/ah_int?tab=factsheet#8068455

https://www.oed.com/search/dictionary/?scope=Entries&q=aah
by IL_Foundation | 2026-02-02 19:28:35+00:00
Support Engineer | Remote | FinTech | Open Source | Startup

Hi there. We are Interledger Foundation and are looking for an experienced Support Engineer (5+ years) who can build the entire support function for our Wallet from the ground up. This is a contractor position, initially. USD 6700/month. Please send your resume and brief motivation to hr@interledger.org

Basic requirements:
Understanding of web and mobile applications
Comfortable troubleshooting using logs, metrics, and system behavior
Ability to operate autonomously and make pragmatic operational decisions

Nice to Haves:
Experience supporting financial infrastructure or cross-border payment systems
Prior experience in open-source or nonprofit environments
Knowledge of APIs (REST, GraphQL, gRPC)
Experience defining on-call rotations and incident response frameworks
Familiarity with CI/CD, monitoring, and observability tools
Experience with distributed scaling or remote support teams
by O1111OOO | 2026-02-02 19:28:38+00:00
I had to followup on this because I still can't believe a thing like this existed.

https://en.wikipedia.org/wiki/Non-fungible_token

"In 2022, the NFT market collapsed..". "A September 2023 report from cryptocurrency gambling website dappGambl claimed 95% of NFTs had fallen to zero monetary value..."

Knowing this makes me feel a little better.
by kevinmgrant | 2026-02-02 19:29:24+00:00
Location: Scottsdale, AZ (Phoenix)
Remote: Yes
Willing to relocate: No but can travel any time
Technologies: Swift, Objective-C, C++, Python, shells, Perl, HTML, CSS, JavaScript and several others
Résumé/CV: kevingrant.name/resume
Email: kmg at mac dot com

I am a computer engineer with two degrees and extensive experience both as a manager of a team of 10, and as a software developer for over 30 years.

I am most interested in a director or project manager position, or as a software architect. I also prefer Apple tech but am open to other opportunities.
by tzs | 2026-02-02 19:30:14+00:00
Some have been built where there wasn't enough power currently available from the grid but would later be available, and were allowed to operate using temporary power sources until then which can cause serious pollution issues for nearby communities.

A notorious example was/is xAI's Memphis data center. They started out using a loophole that let them power it with dozens of gas turbines without permits that didn't have to meet air pollution standards. (I don't remember for sure, but I think they were using them under a rule that is meant for emergencies like natural disasters).

The surrounding communities, mostly poor and minority with not much political clout, already had air that was significantly worse than wealthier and whiter parts of the area, and the data center pushed that to levels health officials considered to be alarming, like a 79% rise in peak NO2 nearby.

This was actually bad enough that even the Trump administration had to act and the EPA now had a rule making it harder for data centers to exploit that loophole.

But they are still using gas turbines, 15 instead of dozens, and they now are permitted and have more pollution controls, but independent data suggests it remains a major source of the smog in the surrounding neighborhoods. They are expected to be fully on the grid later this year.
by ultrafox42 | 2026-02-02 19:30:27+00:00
I built this because AI coding assistants waste enormous amounts of context on code navigation. Every grep returns hundreds of
text matches that the AI reads through — consuming 2000+ tokens for a simple "Where is function X?" question.

AiDex pre-indexes your codebase with Tree-sitter and serves results via MCP (Model Context Protocol). A search returns ~50
tokens instead of 2000+. It knows the difference between identifiers and text — searching for log won't match catalog.

Technical stack: Tree-sitter for parsing, SQLite (WAL mode) for storage, MCP stdio transport. Supports 11 languages. Index time
is ~1s per 1000 files, queries take 1-5ms.

It's not a vector DB or embedding-based search — it's a plain identifier index with exact matches, prefix/substring search, and
method signature extraction. Simple, fast, deterministic.

Also includes a built-in task backlog (persisted in SQLite) and an interactive browser-based viewer for exploring the index.

Works with Claude Code, Cursor, Windsurf, Gemini CLI, VS Code Copilot, and anything else that speaks MCP.
by etamponi | 2026-02-02 19:30:43+00:00
It that's the essence, then of course 9/10 is accident. I think that's not software engineering though.

The essence: I need to make this software meet all the current requirements while making it easy to modify in the future.

The accident: ?

Said another way: everyone agrees that LLMs make it very easy to build throw away code and prototypes. I could build these kind of things when I was 15, when I still was on a 56k internet connection and I only knew a bit of C and html. But that's not what software engineers (even junior software engineers) need to do.
by its_ubuntu2 | 2026-02-02 19:30:43+00:00
Links? To what? "First contribution"? I'm not new around here.

(If anyone is wondering what he's referring to--I said that I was mystified why my post would be immediately downvoted.)

Let's try again, much shorter this time:

I am releasing a distro soon that is right up your alley. SEE MY PROFILE for info.
by nh2 | 2026-02-02 19:30:48+00:00
> has a hardcoded maximum receive buffer of 2MiB

For completeness, I want to add:

The 2MiB are per SSH "channel" -- the SSH protocol multiplexes multiple independent transmission channels over TCP [1], and each one has its own window size.

rsync and `cat | ssh | cat` only use a single channel, so if their counterparty is an OpenSSH sshd server, their throughput is limited by the 2MiB window limit.

rclone seems to be able to use multiple ssh channels over a single connection; I believe this is what the `--sftp-concurrency` setting controls.

Some more discussion about the 2MiB limit and links to work for upstreaming a removal of these limits can be found in my post [3].

Looking into it just now, I found that the SSH protocol itself already supports dynamically growing per-channel window sizes with `CHANNEL_WINDOW_ADJUST`, and OpenSSH seems to generally implement that. I don't fully grasp why it doesn't just use that to extend as needed.

I also found that there's an official `no-flow-control` extension with the description

> channel behaves as if all window sizes are infinite.
>
> This extension is intended for, but not limited to, use by file transfer applications that are only going to use one channel and for which the flow control provided by SSH is an impediment, rather than a feature.

So this looks exactly as designed for rsync. But no software implements this extension!

I wrote those things down in [4].

It is frustrating to me that we're only a ~200 line patch away from "unlimited" instead of shitty SSH transfer speeds -- for >20 years!

[1]: https://datatracker.ietf.org/doc/html/rfc4254#section-5

[2]: https://rclone.org/sftp/#sftp-concurrency

[3]: https://news.ycombinator.com/item?id=40856136

[4]: https://github.com/djmdjm/openssh-portable-wip/pull/4#issuec...
Interest in a "Who's looking for funding?" post
by gushogg-blake | 2026-02-02 19:30:54+00:00
I may be blinded by the subjective importance of my own mission but I'm wondering if there would be any interest in a "Who's looking for funding" post in the same vein as looking for work/wants to collaborate.

Would it be tenable to moderate such a post to filter out not-significant-enough projects and scammers?

My thinking is to give wealthy benefactors a way to see what interesting projects are looking for funding. It would be mostly projects that don't fit, or aren't getting enough donations, from traditional funding sources such as being a charity or getting government grants.

Here's my project: jawhealth.org

It's a campaign to raise awareness of the so-called jaw epidemic, which is a global health issue that's been highlighted and thoroughly described by researchers at Stanford (among many others) but is currently being ignored by the mainstream for various reasons, and people are suffering as a result.
by ErroneousBosh | 2026-02-02 19:31:05+00:00
Yes, because a demolished house is a brownfield site which automatically has outline planning consent and you can build just about anything you like on it. It's worth a fortune.

A farmer's field without planning consent is bought from the farmer priced as a worthless patch of mud, but taxed as though it already had a couple of dozen £500k rabbit hutch houses built on it.
by adam_arthur | 2026-02-02 19:31:27+00:00
People can take on debt for all sorts of things. To go on vacation, to gamble.

Debt doesn't imply it's productively borrowed or intelligently used. Or even knowingly accrued.

So given that the term technical debt has historically been used, it seems the most appropriate descriptor.

If you write a large amount of terrible code and end up with a money producing product, you owe that debt back. It will hinder your business or even lead to its collapse. If it were quantified in accounting terms, it would be a liability (though the sum of the parts could still be net positive)

Most "technical debt" is not buying the code author anything and is materialized through negligence rather than intelligently accepting a tradeoff
by hlfshell | 2026-02-02 19:31:31+00:00
Location: San Diego, CA, USA or Remote
Remote: Preferred but not required
Willing to relocate: Yes
Technologies: Python, golang, AI, robotics, ROS, GCP, AWS, Terraform, Pulumi, React, Vue, Typescript, Computer Vision, Reinforcement Learning, tensorflow, pytorch
Resume: https://github.com/hlfshell/resume
Portfolio: https://hlfshell.ai/projects
Current startup: https://hiredcoach.ai
Email: keith@hlfshell.ai

I am an experienced systems-focused software engineer who builds and integrates cloud solutions, AI tooling, composable agent frameworks, and robotics-oriented software, capable of building either the low level pieces or of full on orchestration for AI workflows. I have a strong background in cloud SaaS products, robotics, reinforcement learning, AI, and more.
by backes | 2026-02-02 19:31:43+00:00
Loki Robotics | https://lokirobotics.co/ | Zurich, Switzerland (Europe) | Full Time | Onsite

We build robots that do facility management. We are an early-stage startup developing teleoperated and autonomous robots for contact-based indoor cleaning. We already have deployed robots and are planning to pivot from prototype to product.

We are looking for experienced SWEs that can work across the stack:

- Create pipelines for building, testing and deployment. This includes HIL testing, kernel compilation, multi-arch compilation, cloud and robot provisioning,...

- Design autonomous systems by building 3D occupancy maps, LiDAR odometry, or behaviour planning

- Work on a low-latency teleoperation pipeline that enables remote operation across the globe

- Integrate sensors and hardware and develop reliable drivers

Check out these SWE roles:

- https://loki-robotics.notion.site/Senior-SWE-Robot-Platform-...

- https://loki-robotics.notion.site/Senior-SWE-Robotics-Z-rich...

Mention that you're from HN. Or write me directly: thierry@lokirobotics.co
Only on-site. Happy to support with relocation.
by remolacha | 2026-02-02 19:31:44+00:00
Mesa | San Francisco - On-site | Software Engineers (Senior+) | https://mesa.dev/

Mesa is building GitHub for AI Agents. We create new kinds of infrastructure and human interfaces for AI-driven software development. We are currently a team of 7 (all engineers), looking to add a few more highly autonomous SWEs.

Comp: $180k - $275k, 0.2% - 2% equity

Sound like a good fit? Email founders@mesa.dev
by michal-stlv | 2026-02-02 19:31:48+00:00
Yeah, SST seems to be closest thing to Stelvio I guess.

I don't really think we're competitors, their focus is on JS/TS eco system. As you suggested Stelvio focuses on Python and aims to really nail down experience for deploying Python to AWS (and later potentially elsewhere). e.g. we resolve python dependencies for lambda functions and layers and package them for you etc.

In the long run we want Stelvio to be a go to tool for deploying Python (with some nice TUI and web console to make it all really smooth).