Hacker News

Hello, World!

Need your help, urgently! :)

Long-time lurker, newly and hopefully valuable HN poster soon.

My X account is currently classified as "Probable Spam" after I made 1,078 posts over the last 7 days (lol).

Any chance ya'll can explore the above, then if you are delighted to please interact with my account to counter the "Probable Spam" classification?

Thank you!

P.S. "Show HN is for something you've made that other people can play with. HN users can try it out, give you feedback, and ask questions in the thread." <-- I hope this qualifies when related to Combinatorial Memetics!

Comments URL: https://news.ycombinator.com/item?id=46928274

Points: 1

# Comments: 1

Article URL: https://steamdaily.xyz

Comments URL: https://news.ycombinator.com/item?id=46928255

Points: 1

# Comments: 0

Article URL: https://steve-yegge.medium.com/the-anthropic-hive-mind-d01f768f3d7b

Comments URL: https://news.ycombinator.com/item?id=46928251

Points: 1

# Comments: 0

Article URL: https://intelligenttools.co/blog/ampcode-multi-agent-production

Comments URL: https://news.ycombinator.com/item?id=46928239

Points: 1

# Comments: 0

Every day I'm seeing blogs on here about the impact of AI on software engineering. Sentiment seems split between AI eventually automating the software engineer role away, vs AI produces too many bugs to displace senior engineers.

I feel like many of the AI insights featured on hackernews are from the software engineers Point of View?

There's also the perspective of vibe-coded-to-prod disaster scenarios.

For me, as a software engineer with nearly 20 years experience, AI is already more trustworthy than many contractors I've worked with over the years.

As a founder/product manager, a lot of trust is put into the engineers building the platforms. The Founder <-> Implementer interaction already involves huge amounts of trust. Things happen all the times, and C-suite executives don't have the ability to fix themselves.

My interpretation is that a lot of engineers are just encountering this trust relationship for the first time with AI. We're trusting AI (a ~contractor) to do something to spec. Advanced engineers are able to audit the AI output at a very deep level.

For founders / product managers / executives, this relationship is nothing new, and we already trust other parties to implement our code.

What does everyone think?

Going from contractor to LLM is actually a huge benefit to me, LLM has a much faster feedback loop than human contractors, costs a fraction and has a lower base rate of error (in my experience). Nothing new with the trust model.

Comments URL: https://news.ycombinator.com/item?id=46928231

Points: 1

# Comments: 0

Article URL: https://phys.org/news/2026-01-crosstalk-cells-pathogens-evade-drugs.html

Comments URL: https://news.ycombinator.com/item?id=46928220

Points: 2

# Comments: 0

Article URL: https://huesly.app

Comments URL: https://news.ycombinator.com/item?id=46928219

Points: 1

# Comments: 1

I’ve been home alone today, so made myself a challenge to write 5 songs from scratch and then showcase them with a simple website and player. The music is all me, the website is Claude with me guiding design decisions. Hope you like it.

Comments URL: https://news.ycombinator.com/item?id=46928205

Points: 1

# Comments: 0

Article URL: https://github.com/Paraxiom/topological-coherence

Comments URL: https://news.ycombinator.com/item?id=46928176

Points: 1

# Comments: 1

Article URL: https://www.zdnet.com/article/ai-failed-test-on-remote-freelance-jobs/

Comments URL: https://news.ycombinator.com/item?id=46928172

Points: 5

# Comments: 2

Article URL: https://harpers.org/archive/2023/04/the-science-of-the-perfect-second/

Comments URL: https://news.ycombinator.com/item?id=46928157

Points: 1

# Comments: 0

Article URL: https://marc.info/?l=openbsd-misc&m=115820462402673&w=2

Comments URL: https://news.ycombinator.com/item?id=46928122

Points: 2

# Comments: 0

Hi HN, I’m the creator of glimpsh.

glimpsh is an experimental project exploring gaze input inside the terminal. The idea is to treat eye tracking as a secondary input signal alongside keyboard and mouse.

One motivating use case is multi-agent management. Using gaze to quickly switch focus between running agents or processes, inspect state, or trigger context-sensitive actions without constant keybindings.

I’m also interested in pushing on the quality of commodity eye-tracking software as an HCI tool. Webcam-based eye tracking is widely available but often inaccurate and underexplored in real interfaces. This project is a way to stress-test those tools in a demanding UI environment.

I’m curious about combining gaze with other high-bandwidth input, especially voice. Systems like Wispr suggest that voice plus gaze could work well together, for example in terminal multiplexors where gaze establishes focus and short commands trigger actions.

This is not meant to replace efficient keyboard-driven workflows. Many users are already extremely fast with keybindings. The goal is to explore whether gaze and voice can act as complementary tools when managing many concurrent agents or streams of information.

This is very early and experimental. I’d especially love feedback on:

whether gaze as a secondary input makes sense in terminal workflows

multi-agent or TUI use cases that might benefit

accessibility implications

thoughts on combining gaze and voice in developer tools

Happy to answer questions or dig into implementation details.

Comments URL: https://news.ycombinator.com/item?id=46928115

Points: 1

# Comments: 0

Article URL: https://micahblachman.beehiiv.com/p/the-optima-l-situation

Comments URL: https://news.ycombinator.com/item?id=46928112

Points: 2

# Comments: 1

Article URL: https://blog.typeobject.com/posts/2026-barn-owls-know-when-to-wait/

Comments URL: https://news.ycombinator.com/item?id=46928105

Points: 1

# Comments: 0

Article URL: https://www.youtube.com/watch?v=qjOBZ_Xzuio

Comments URL: https://news.ycombinator.com/item?id=46928100

Points: 1

# Comments: 0

My first job in management was not good. I became so stressed I got a mild case of shingles[0], and at that point decided to quit for my own health. I didn’t stay long enough to overcome the difficulties—I had to run away.

I’m wondering if this job was just especially bad, or if I can expect similar troubles in any management job.

It was consulting company work, and I enjoyed it when I was an individual contributor on the team. The company cared about our project in the beginning and things were well planned. If we fell behind, the consulting company would give us extra people to help catch up.

Then they made me team lead and all of that stopped. We were left to flounder. Or maybe I was just bad at planning and asking for help?

The team was filled with good people, but I always felt like I was leading “the B team.” In part because the team was originally assembled to do Python work, but then the client decided to start using TypeScript, but only for some things. None of us knew TypeScript.

Ultimately, I couldn’t trust that the other members of the team would get their work done well. I was expected to spend some of my time programming as the team lead, and so I felt a lot of pressure to personally fix all the code the team produced.

Was this team lead position just an especially bad one? I think I’m about to answer that question with this next observation:

Our client was a company run by Alice, and our technical manager was Bob (names changed). Bob wanted us fired so he could hire another consulting company made up of people he was friends with, but Alice was friends with executives at my consulting company. So my team and I were forced to work with Bob, even though Bob didn’t want to work with us.

It was really screwed up, and management at the consulting company told us at one point to stop talking to Bob—we literally couldn't talk to our client for a time. This seemed like a red line for me. Once everyone stops working toward solving a problem and instead company politics are the #1 consideration, it’s time to go. Or so I thought—once you’re actually in a job, leaving isn’t always as easy as you expect.

I’ve also been frustrated throughout my career because it seems like in most jobs, company politics are actually more important than solving the problem. Is this true?

Anyway, I guess this turned into a bit of a ramble.

I’m looking for new work again, and I’m wondering if I should be open to management roles again. I really didn’t like my first leadership experience. But I have a lot of experience and enjoy being included in the higher-level decisions that come with management. I do hate the politics, though.

Is it unreasonable to hope for a job where everyone works toward solving technical problems without politics?

----

[0]: I also learned that I have celiac disease (which is an autoimmune disease) during the same time I had shingles. It was a rough time. The shingles cleared on their own, but there was one evening where they were hurting worse than anything I've ever experienced. All of this made it feel like the stress was going to kill me.

Comments URL: https://news.ycombinator.com/item?id=46927652

Points: 1

# Comments: 0

I've worked on the design-end of engineering for some time, and have done my share of crimping for prototyping / development, but have never done electrical design for mass production. I'm now working with a small company who is scaling up their early prototypes, and we're going to assemble the early ones in house -- think 10s of units. This is the first time that I'm involved in this scale of manual assembly. I find I'm spending significant time _just making crimps_, and this makes me wonder if I can get better at making crimps, or make a design change to simplify the assembly. I take about 60 sec per crimp, and I don't have the exact tools in this guide, but it is basically what I do: https://www.youtube.com/watch?v=jHfYzrSF4pY

Here's the design constraints that come to mind:

1. We have about 15 connections to make

2. Most of our connections are JST-XH, some are JST-SM. We could maybe simplify to just JST-XH and then buy pre-crimped wires, but we like having the locking connections for wire-to-wire connections

3. Sometimes we need different connectors at opposing ends of wire. If we buy pre-crimped SM and SH, we could just solder the appropriate lines together.

4. we want to keep the 2.54mm pitch, to interface with simple OTS boards

My best ideas:

1. Buy pre-crimped JST-XH wires, and change one end to JST-SM as needed. This should get rid of ~80% the crimping effort.

2. Move entirely to JST-XH, buy pre-crimped wires, and accept slightly worse wire-to-wire connections.

3. Buy better crimp tools, practice like hell, and 'git gud'

Are there other ideas I should consider? Is there a secret or a better guide to crimp faster? I know this is a noob-ish question, any help is appreciated. I have googled, searched youtube, and asked the various LLMs, and the ideas listed above are the result.

Comments URL: https://news.ycombinator.com/item?id=46927634

Points: 1

# Comments: 0

Article URL: https://arxiv.org/abs/2511.01815

Comments URL: https://news.ycombinator.com/item?id=46927580

Points: 1

# Comments: 0

Article URL: https://www.nature.com/articles/s41467-025-67747-9

Comments URL: https://news.ycombinator.com/item?id=46927562

Points: 1

# Comments: 0