desktop-vibe-fly Sniffs Out Vibe Code

desktop-vibe-fly is kulikov0’s open-source macOS desktop toy: a 3D fruit fly that wanders your screen using a live FlyWire-connectome simulation, then sniffs out AI-coding projects. It deals with a real little mess in agentic coding: every repo now has marker files, rules, memories, and steering docs, but they are easy to forget once the editor is open. The takeaway is simple: the joke works because agent workflows are becoming visible infrastructure, and Cursor users can treat those marker files as a reviewable interface instead of hidden prompt sludge. For the cursor ide agent plugin cline deepseek 2026 crowd, the practical answer is not to compare vibes first; it is to inspect the project markers that tell each agent what “good work” means.

Watch what the fly treats as scent

desktop-vibe-fly is a fork of DenisSergeevitch’s desktop-fly, with one strange new instinct: it scans for AI-coding marker files and turns nearby screen objects into odour sources.

The upstream project gives the fly its brain, body, and desktop senses. This fork leaves those parts alone. The new layer looks for files such as AGENTS.md, CLAUDE.md, .cursor/rules, .kiro/steering, and dozens of similar markers.

Then it maps those markers back to things you can see. An editor or terminal window with the project open smells strong. A Finder row smells weaker. A folder icon on the desktop smells weakest. A hub of several marked repos reaches farther across the screen than a single quiet folder.

That is the whole gag, and it is a good one. The fly does not “understand” your startup. It follows the desktop traces of agent configuration, which is exactly where modern AI-coding work has started to live.

As of August 21, 2026, the GitHub repo was small: 6 stars, mainly Swift, no asserted license, and a fresh push that day. Hacker News noticed anyway because the title was funny, the demo was visual, and the project made an invisible workflow smellable.

The trap is treating it like a productivity benchmark. It is closer to a tiny kinetic essay. The useful part is not the insect; it is the list of files the insect considers meaningful.

Notice the agent-marker joke

An agent marker is a repository file or directory that tells an AI coding agent how to behave in that codebase. It can carry architecture rules, local commands, review habits, tool permissions, or project-specific memory.

Cursor, Anysphere’s AI code editor, has its own surfaces for this shape of work: Cursor rules, Cursor skills, custom agents, subagents, hooks, MCP, and Agent Mode. A .cursor/rules folder is not decorative. It is a place where the repo explains itself to the cursor agent before work begins.

That is why desktop-vibe-fly lands with developers using Cursor agents. The fly treats AGENTS.md and .cursor/rules as scent because they are the closest thing a repo has to an agent-facing doorway.

Here is a tiny Cursor rule stub that would make sense in a real service repo:

---
description: Keep API changes inside the route boundary
globs: apps/api/**/*
alwaysApply: false
---
When editing API routes:
- Read apps/api/README.md before changing handlers.
- Do not change database migrations unless the task asks for it.
- Keep generated clients out of handwritten route files.
- Before final review, run pnpm test:api and paste the failing test if it fails.

That file is useful even if no fly ever finds it. It gives the agent a local boundary, a command, and a review habit. It also gives a human reviewer something concrete to inspect when the cursor agent mode output feels “off.”

The trap is letting marker files become stale folklore. A repo with six marker files and three outdated rules does not smell “more agentic.” It smells confusing.

Try the idea on a real Cursor repo

You do not need a desktop insect to learn from desktop-vibe-fly. Pick one repo and ask: what would the fly smell, and would that scent help a Cursor agent do better work?

Start with the repo root. If there is an AGENTS.md, make it short and durable: repo shape, test commands, dangerous paths, and review expectations. Then use scoped .cursor/rules files for local constraints. Put frontend rules near frontend code, backend rules near backend code, and generated-code rules near generated output.

This is the practical section for the cursor ide agent plugin cline deepseek 2026 search path: before wiring more agent plugins together, make the repo’s instruction surface boring and visible. Cursor skills can package repeatable workflows. Cursor subagents can split specialized work. Cursor MCP can connect external systems. But the first smell test is still: can the repo tell an agent where not to step?

A good small experiment is a bugfix in a repo with one clear boundary. Ask the Cursor agent to change one route, then review whether it followed the .mdc rule without being reminded in chat. If it ignored the rule, fix the rule before blaming the model.

The trap is turning every preference into a rule. Rules should remove ambiguity that repeatedly hurts work. They should not encode one person’s ideal prompt style.

For a deeper Cursor background-agent angle, compare this with how cloud work needs explicit build and review boundaries in Cursor Cloud Agents Get Longer Leashes. The same pattern shows up: more autonomy makes local instructions more important, not less.

Know when the fly is overkill

desktop-vibe-fly is worth trying if you like small macOS experiments, AI-coding culture, or tangible ways to explain invisible repo conventions. It is also useful as a reminder that agent metadata is now part of the codebase.

It is probably overkill if you want a dependable Cursor training artifact, a security scanner, or a cross-platform workflow. The repo is a playful Swift project, not an enterprise control plane. It also scans for markers across your disk, so you should understand what it sees before running it near sensitive work.

A better production habit is much plainer: keep one obvious root instruction file, keep scoped Cursor rules close to the code they govern, and review agent output against those files. If you use custom subagents or Cursor background agents, give them the same small, inspectable boundaries.

For more on this cluster of work, see the related training topic. The useful connection is not “make a fly.” It is “make agent instructions findable.”

Try it safely checklist

Use this as a small local experiment, not a trust fall.

• Confirm you are on macOS, or watch the repo’s demo video instead of running the app.
• Read the repository first, especially the Swift code that scans for marker files and desktop objects.
• Start with a harmless test folder, not a customer repo or a directory full of secrets.
• Add one marker at a time: first AGENTS.md, then .cursor/rules/example.mdc.
• Open the folder in an editor or terminal and see whether the visible window becomes the strongest scent.
• Move the folder to Finder or the desktop and compare how weak the scent becomes.
• Remove the marker and confirm the project stops smelling.
• In your actual Cursor repo, keep any lesson boring: one root instruction file, one scoped rule, one review command.

The best result is not a dramatic demo. It is noticing that your repo either has a clear agent interface or a pile of half-remembered instructions.

Common questions

• Is desktop-vibe-fly a real coding tool or just a joke?

  It is a real macOS project with a playful purpose. The repo says it forks the FlyWire-connectome desktop fly and adds scanning for AI-coding markers such as AGENTS.md, CLAUDE.md, and .cursor/rules; as of August 21, 2026, the public repo was small and mainly Swift.

• What should I take from cursor ide agent plugin cline deepseek 2026 here?

  The useful lesson is to inspect the repo’s agent markers before comparing agent stacks. For Cursor users, that means checking AGENTS.md, .cursor/rules, skills, subagents, and MCP boundaries so each cursor agent has durable context instead of relying on one long chat prompt.

• Does this replace Cursor rules or cursor agent mode setup?

  No, it does not replace Cursor rules or cursor agent mode. desktop-vibe-fly only notices marker files and turns them into a desktop scent source; the real work still happens in Cursor through Agent Mode, rules, skills, review, and the code changes you accept.

• Should every repo have AGENTS.md and .cursor/rules?

  No, every repo does not need both on day one. A small library may only need one short root instruction file, while a larger app benefits from scoped .cursor/rules near risky areas such as migrations, generated code, payments, or API boundaries.

• What is the main limitation of desktop-vibe-fly?

  The main limitation is that it is a macOS desktop experiment, not a cross-platform agent-management system. It can make marker files visible in a delightful way, but it cannot tell whether those files are accurate, safe, or actually followed by your coding agent.

Best ways to use this research

• Best for: Cursor users who want a memorable way to explain why repo-local agent instructions matter.
• Best first artifact: A short AGENTS.md plus one scoped .cursor/rules/*.mdc file covering a risky directory.
• Best comparison angle: Compare agent tools by how clearly they read, scope, and review repository instructions, not by how many buttons they expose.
• Best sanity check: Ask whether a new cursor subagent, skill, or MCP server has a visible boundary a reviewer can inspect.

Further reading

• Cursor — Agent
• Cursor — Rules
• desktop-vibe-fly — source

Next step

Open one active Cursor repo and list the files an agent would treat as instructions. Delete or fix the stale ones before you add another agent surface.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.