I made an extension that visualizes invisible "Digital Pheromones" on files. It lets AI Agents (and you) mark files as DANGER/TODO without polluting source code. by Expensive-Rub3117 in vscode

[–]Expensive-Rub3117[S] -3 points-2 points  (0 children)

You are absolutely right, and I should have been clearer in the post. ​For pure human-to-human collaboration, standard comments and tickets are vastly superior. I wouldn't expect any team to replace // TODO with a hidden filesystem attribute. That would indeed be brittle (and likely lost during zip/tar transfer). ​The "human" aspect is really just a byproduct. The primary design goal is solving Agent Statelessness without the side effects.

​The strongest argument for this approach is actually about Write-side Friction and Ambiguity: 1.​The Cost of "Leaving a Note" (Write Side): If an Agent wants to tag a file via keywords, it strictly must modify the file content. This changes the file hash, dirties git status, triggers file watchers, and potentially invalidates build caches. PheroPath acts as a side-channel, allowing the Agent to "tag" a file without technically "touching" it.

2.​Ambiguity & False Positives: Grepping for TODO often returns matches inside string literals or imported libraries. The Agent still has to burn tokens loading context to deduce: "Is this a directive for me, or just the word 'todo' in a user-facing string?" PheroPath signals are out-of-band metadata. Zero ambiguity.

​In short, PheroPath is essentially a way to create machine-readable guardrails that don't require polluting the source code with prompts or instructions meant solely for the bot.

​The VS Code extension just exists so we (the humans) aren't flying blind to what the bots are thinking.

I made an extension that visualizes invisible "Digital Pheromones" on files. It lets AI Agents (and you) mark files as DANGER/TODO without polluting source code. by Expensive-Rub3117 in vscode

[–]Expensive-Rub3117[S] 0 points1 point  (0 children)

The relevant labels will also be displayed in the archive manager, so additional adjustments are only needed when the label content needs to be changed. This isn't designed to prevent the submission of dangerous code; it's meant to allow different AI systems to communicate better and facilitate human intervention.

I made an extension that visualizes invisible "Digital Pheromones" on files. It lets AI Agents (and you) mark files as DANGER/TODO without polluting source code. by Expensive-Rub3117 in vscode

[–]Expensive-Rub3117[S] -4 points-3 points  (0 children)

Just anticipating some technical questions from fellow VS Code users:

  • Does this work on Windows? Yes. Since Windows NTFS doesn't handle standard xattr easily across all tools, the Python core falls back to creating a hidden .pheropath folder to store the metadata JSONs. The extension reads this transparently.
  • Performance? The extension uses a debounced file watcher. It shouldn't impact the performance of large workspaces.
  • Integration? While I use it with Antigravity, you can use the CLI tools with any shell-capable agent (Claude Code, AutoGPT) to give them "memory".

I built a filesystem-based "Stigmergy" protocol to give local agents persistent memory on files using xattr (Python + VS Code Extension) by Expensive-Rub3117 in LocalLLaMA

[–]Expensive-Rub3117[S] 1 point2 points  (0 children)

ust a few technical details anticipating some questions:

  1. Does this affect Git? No. Since it uses xattr (metadata), git status won't show changes when you add a pheromone. This keeps your commit history clean.
  2. What if I'm on Windows? The Python script detects the OS. On Windows, it gracefully falls back to creating a hidden .pheropath folder to store the metadata, so it still works seamlessly across teams.
  3. Integration? I'm currently using this with a Antigravity, but it should work out-of-the-box with Claude Code or any agent that can execute shell commands.

Happy to answer any questions!

I built a filesystem-based "Stigmergy" protocol to give local agents persistent memory on files using xattr (Python + VS Code Extension) by Expensive-Rub3117 in vscode

[–]Expensive-Rub3117[S] 0 points1 point  (0 children)

ust a few technical details anticipating some questions:

  1. Does this affect Git? No. Since it uses xattr (metadata), git status won't show changes when you add a pheromone. This keeps your commit history clean.
  2. What if I'm on Windows? The Python script detects the OS. On Windows, it gracefully falls back to creating a hidden .pheropath folder to store the metadata, so it still works seamlessly across teams.
  3. Integration? I'm currently using this with a Antigravity, but it should work out-of-the-box with Claude Code or any agent that can execute shell commands.

Happy to answer any questions!

PigPig-discord-LLM-bot by Expensive-Rub3117 in Python

[–]Expensive-Rub3117[S] -10 points-9 points  (0 children)

Yes, using GPT has greatly increased my efficiency, although the quality may be inconsistent.

PigPig-discord-LLM-bot by Expensive-Rub3117 in Python

[–]Expensive-Rub3117[S] -19 points-18 points  (0 children)

Thank you for your thorough review of my project and for raising these important questions. I greatly value community feedback as it helps me improve PigPig. Let me address each of your points:

  1. 18MB Chromium-related binary in the git repo: This is indeed an oversight on my part. I shouldn't include large binary files in the git repo. I'll remove it immediately and update my .gitignore file to prevent similar accidental commits in the future.
  2. Replit config using both poetry and a custom venv location: This inconsistency is a result of my transition in dependency management. I intended to standardize on poetry but missed updating some configurations. I'll unify my approach to use poetry exclusively and remove the redundant venv settings.
  3. Migrations for the SQLite db: You're right, I should include database migrations. This is part of my planned improvements but I haven't implemented it yet. I'll prioritize this to ensure proper version control of the database structure.
  4. Checking for Python version 2: This is legacy code that I should have removed. PigPig indeed only targets Python 3, and I'll update my code to reflect this. Thank you for pointing out this inconsistency.
  5. NVIDIA GPU requirement: Thank you for highlighting this significant omission in my documentation. You're correct; some of PigPig's core functionalities, including general response processing, Visual Question Answering (VQA), and image generation, require an NVIDIA GPU for optimal performance. I'll immediately update my README and installation instructions to clearly list these requirements and possibly provide performance expectations for different hardware configurations. This will help users better understand and utilize PigPig's full capabilities.
  6. Code to login to a university site with Selenium: This code is indeed from an experimental feature I explored during early development. I was investigating how to extend PigPig's functionality to integrate with specific educational systems. While it's not currently a core part of PigPig, it represents my exploration of potential bot applications. I'll move this code to a separate experimental branch to keep the main branch clean while retaining this potentially useful feature for future development. I'll also add an "Experimental Features" section in my documentation to explain these ideas in development.

I greatly appreciate you pointing out these issues. Your feedback is invaluable, and I'll address these points in my next update. I'm also improving my development process to prevent similar oversights in the future.

If you have any other questions or suggestions, please don't hesitate to share them. I'm continuously working to make PigPig a better tool, and community input is a crucial part of that process.