Any feedbacks are welcome

So I created a CLI tool that lets you overlay/remove local-only dev files on top of a repo, without modifying the repo itself.

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

Points: 2

# Comments: 0

I built Local Agent over the weekend to explore a few specific problems in agent runtimes: tool safety and emergent identity.

Most agent frameworks give the LLM broad access. I wanted to experiment with a tiered risk model: Tier 0 (read-only), Tier 1 (unified diff patches with backups), and Tier 2 (side-effects like deletion requiring explicit approval via a YAML policy engine).

The most experimental part is an identity I call 'Nova'. It starts with a minimal system prompt and manages its own long-term memory in a local text file. The goal was to see if an agent could evolve its own 'personality' and continuity through interaction rather than having it hard-coded in a prompt.

Looking forward to hear what you guys think.

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

Points: 1

# Comments: 1

Personally, one of the most dreadful aspects of working on HDFS + Hive + Spark data pipelines has been the “wait” game while spinning up a cluster on cloud. So one day I said I am going to run things locally; and after a week of trial and error, I got the pipelines running all in my laptop. This was honestly a game-changer, increasing velocity and enabling full agentic workflow.

I built local-data-platform because it took me a week to setup HDFS + Hive + Spark all working together on my local machine and how messy it was to switch between different settings (with or without HDFS).

I am sharing the repo in case anyone is stuck in the same predicament.

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

Points: 2

# Comments: 0

Every "agentic" IDE or CLI tool has its own proprietary way of being "instructed": Cursor has .cursorrules, Claude Code has custom hooks, Copilot has instruction files. As developers, we are now forced to re-implement our repository's "rules of engagement" for every new tool we adopt; or even worse, our codebase becomes cluttered with all these tool-specific "instructions".

The real problem isn't that agents are "bad" at following instructions; it's that we lack a standard interface to communicate what a repository is and how it can be safely operated.

I built devBox to move the source of truth out of tool-specific config files and into a single deterministic execution contract that lives in the ".box/" directory in each repo.

The Concept: One contract, any agent.

Why this matters: This approach allows for a "Write Once, Run Anywhere" workflow for AI agents. Whether you are using Cursor, Windsurf, or a custom LLM script, they should be able to interact with your repo through the same deterministic interface and under the same security guardrails.

I'm curious to hear from others: Are you also feeling the "instruction bloat" of maintaining 5 different .rules files for 5 different tools? How are you centralizing your repo's operational logic?

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

Points: 3

# Comments: 1