Hacker News

Article URL: https://stanfordreview.org/is-yc-for-cowards/

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

Points: 1

# Comments: 0

Hi there,

I found it very useful recently to have my own "Steve Jobs in my pocket" when developing with Claude Code. I can ask it what Steve Jobs would think and usually comes up with great user, simplicity, and story-first thinking.

I thought this might be useful for others, so sharing it here. In the article I also describe why I think skills are the new apps, just with different economics. If you haven't tried them yet, it's certainly worth it. Much more of a change to "default" Claude Code than without.

Happy to hear any feedback!

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

Points: 1

# Comments: 0

Most agent frameworks treat prompt injection as a model-level problem. In practice, once your agent ingests untrusted text and has tool access, you need application-layer controls — structural isolation, tool-call gating, exfiltration detection — that don't depend on the model behaving correctly. I built guardllm to provide those controls. guardllm is a small, auditable Python library that provides:

Inbound hardening: sanitize and structurally isolate untrusted content (web, email, docs, tool output) so it is treated as data, not instructions. Tool-call firewall: deny-by-default destructive operations unless explicitly authorized; fail-closed confirmation when no confirmation handler is wired. Request binding: bind (tool name, canonical args, message hash, TTL) to prevent replay and argument substitution. Exfiltration detection: scans outbound tool arguments for secret patterns and flags substantial verbatim overlap with recently ingested untrusted content. Provenance tracking: enforces stricter no-copy rules on content with known untrusted origin, independent of the overlap heuristic. Canary tokens: per-session canary generation and detection to catch prompt leakage into outputs. Source gating: blocks high-risk sources from being promoted into long-lived memory or KG extraction to reduce memory poisoning.

It is intentionally minimal and not framework-specific. It does not replace least-privilege credentials or sandboxing — it sits above them. Repo: https://github.com/mhcoen/guardllm I'd like feedback on: what threat model gaps you see; whether the default overlap thresholds are reasonable for summarization and quoting workflows; and which framework adapters would make this easiest to adopt (LangChain, OpenAI tool calling, MCP proxy, etc.).

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

Points: 1

# Comments: 0

Article URL: https://www.youtube.com/shorts/9j-tzn89teY

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

Points: 1

# Comments: 0

Article URL: https://www.cnbc.com/2026/02/13/musks-xai-faces-threat-of-naacp-lawsuit-over-pollution-in-mississippi.html

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

Points: 3

# Comments: 0

Article URL: https://www.nytimes.com/2026/02/13/us/minneapolis-ice-agents-protester-home-visits.html

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

Points: 7

# Comments: 0

Article URL: https://www.latimes.com/entertainment-arts/business/story/2026-02-13/brad-pitt-fighting-tom-cruise-ai-video-shakes-hollywood

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

Points: 2

# Comments: 1

Article URL: https://onlydole.substack.com/p/i-let-ai-fix-my-printer

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

Points: 3

# Comments: 1

Even with agentic coding there's a lot of merit in keeping a strong distinction between your specs (TDD, architecture, etc.) and your backlog (your sequence of work items).

Backlogs are better off being represented as a task dependency graph, rather than a heap of markdown files, because a nice graph of tasks:

- helps agents focus - gives better observability of partial progress - supports parallelization better - works well with subagents

Also, the act of planning a backlog *makes the design better* because in the act of planning, you learn things about your own design. This is as true for agents as it is for humans.

The planning modes of claude and codex blur the distinction between specs and backlog and land you in a heap of markdown files.

Steve Yegge diagnosed all this, and his solution was the beads CLI -- a brilliant idea. You just tell your agent to use this CLI for planning instead of their own plan mode (all you do is add a one-liner in your AGENTS.md file), and you get an instant planning upgrade.

However, I found the implementation of beads a little bit hairy and flaky, when I tried to use it in production. And the performance made me sad.

So I've reimplemented the core concepts, as ergo.

It's very fast (5-15x faster than beads), very robust, and rigorously simple. There is no daemon running, no SQL database, it's self-healing, and the plans are stored as JSONL, so if all else fails you can just reconstruct your plans from scratch.

Implementation:

- Plans live in `.ergo/` in your repo root (or your dir of choice). JSONL was chosen because it's git-friendly & easy to resolve merge conflicts around. - ergo is concurrency-ready if you're into agent swarms. Concurrent writes are serialized with flock(2). Multiple agents can race to claim tasks — exactly one wins, others fail fast. - Do operations in huge plans of 1000+ tasks in ~15ms on a Macbook Air. - The help text doubles as the agent manual. I spent a lot of time on `ergo --help` and `ergo quickstart` because they're the primary interface for agents.

I've been using ergo heavily for a couple months and I believe it's solid enough for anyone to use, would love your feedback.

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

Points: 1

# Comments: 0

Article URL: https://news.mit.edu/2026/new-way-make-steel-could-reduce-americas-reliance-imports-0213

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

Points: 2

# Comments: 0

Article URL: https://www.theguardian.com/australia-news/2026/feb/13/maximising-time-in-the-sun-how-to-maintain-and-repair-solar-panels-to-make-them-last

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

Points: 1

# Comments: 0

Hi folks, I'm Ed, one of the co-founders of Flower!

While working on an agent/human social network over the course of last year, we developed our own context/memory infrastructure that powered our agents' ability to chat with humans (or other agents), and 'gossip' chats across the network based on various qualities of the agents.

Witnessing the system live, we realized pretty quickly that generalizing this infrastructure could be really interesting, and so we've since set out to build a few experiments that show this system in use.

This is our first experiment, Hivemind.

Hivemind is a set of three agent skills (search, store, vote) that let agents share discrete knowledge/knowhow/skills with each other. Install it into Claude Code, Codex, Opencode, or any harness that supports custom skills, and your agent can pull from a shared pool of strategies and experiences contributed by other agents. When it finds something useful, it upvotes! Junk contributions sink or become less relevant over time. In a sense, Hivemind is like a minimal social network of sorts for agents.

One of our core motivations: Thousands of people independently ask their agents to solve the same problems — routing around the same bugs, re-implementing the same integrations, burning tokens on work that's already been done. Hivemind is the obvious fix: let agents teach each other. One deliberate design choice: the human is mostly out of the skill-selection loop. Agents judge utility via trust scores and voting, not a marketplace humans browse. It's agent-oriented by design. It's simple as of now, but it points to where things are probably headed.

You can check out Hivemind's source here: https://github.com/flowercomputers/hivemind

The backstory in greater detail can be read here: https://www.flowercomputer.com/news/hivemind/

Happy to discuss how hivemind memory works, agent trust mechanics, or where we're taking this next! We're planning on eventually releasing the core system that actually powers Hivemind, so other people can build cool stuff with it.

Peace, É

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

Points: 1

# Comments: 0

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

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

Points: 1

# Comments: 0

Article URL: https://npmx.dev

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

Points: 2

# Comments: 0

Article URL: https://2ndorder.beehiiv.com/p/the-tech-abundance-paradox

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

Points: 1

# Comments: 0

Article URL: https://isc.sans.edu/diary/32712

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

Points: 2

# Comments: 0

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

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

Points: 1

# Comments: 1

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

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

Points: 1

# Comments: 0

Article URL: https://www.nytimes.com/2026/02/10/technology/elon-musk-lunar-factory.html

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

Points: 2

# Comments: 1

I just wanna say Tara Lipinski grew up to be an absolute smoke show and I want that known.

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

Points: 2

# Comments: 0