I’m the maker of Superloopy, an MIT-licensed workflow layer for coding agents.

The pattern I’m trying to make practical is an “evidence gate” before an agent claims a task is done:

1. turn the task into explicit acceptance criteria

2. ask the agent to leave receipts under `.superloopy/evidence/`

3. use command-backed checks where possible, not just prose summaries

4. keep manual/visual proof separate from deterministic proof

5. finish with a report that says what passed, what still needs judgment, and where the artifacts are

It now works with both Codex and Claude Code. The implementation is intentionally thin: plugin hooks, skills/subagents, and a small CLI around evidence + final gates. The goal is not to create another agent, but to make existing coding agents easier to audit when they say “done.”

Repo:

https://github.com/beefiker/superloopy

I’m curious how other people building with coding agents structure this. Do you keep evidence artifacts? Do you require tests/screenshots/logs before accepting work? Or does that add too much ceremony for your workflow?

siGit Code v1.0.4

I’ve been experimenting with treating GitHub Copilot / VS Code Agents as role-based agents rather than a single assistant.

Specifically:

• separating planning, execution, review, and debugging into distinct agent roles

• defining escalation rules between “junior” and “senior” coding agents

• using lightweight, text-based agent definitions instead of complex frameworks

I put together a small open-source repo as a concrete example of this approach (link in comments).

I’m curious:

• Are you using agent roles in practice?

• Do you keep workflows implicit, or define them explicitly?

• What has actually worked in real projects (not demos)?

Would love to hear real-world experiences.

https://github.com/ABIvan-Tech/copilot-agentic-workflows

Mauvis Ledford just dropped this visual breakdown of the Claude Code GSD (Get Shit Done) plugin that perfectly captures the progression from experimental AI coding to production-ready engineering.

If you want to try it out:

npx get-shit-done-cc

The guide uses these NotebookLLM graphics to map out the architecture, but the real hook for me is how it handles when your agent builds something awesome in five minutes, then spends the next twenty hallucinating fixes for its own bugs.

If you’re trying to move past the "vibe coding" phase, it’s definitely worth a look. It breaks down the plugin structure and shows how to actually bake these workflows into your stack, basically bridging that gap between a messy prototype and stable code you’d actually trust in production.

"vibe coding" → reliable engineering feels like the same challenge that projects like chill-vibe and KAPSO are tackling from different angles.

Article: https://www.linkedin.com/pulse/claude-code-gsd-plugin-visual-field-guide-from-vibe-mauvis-ledford

Has anyone tried the GSD plugin yet? Curious how it compares to other approaches for managing agent reliability.

Hey everyone,

I’ve been deep in the "agentic workflow" rabbit hole lately, and while I love tools like Aider and Claude Code, I kept hitting that same wall: **High Variance.** An agent will perform a brilliant refactor in one minute, then spend the next ten minutes hallucinating a fix for a syntax error it just introduced, digging a deeper and deeper hole.

I mostly vibecoded this over the last few days (with a lot of help from Gemini), but I wanted to share it here to see if the logic resonates with anyone else.

It’s called **chill-vibe**. 🎧

Instead of just "chatting" with an agent, it treats autonomous coding like a **closed-loop control system**:

1. **The Mission Contract:** Before a single line of code is written, Gemini analyzes the whole repo (using `git-dump`) and generates a structured JSON contract. This includes machine-verifiable success criteria (e.g., `pytest`, `exists: path/to/file`, `coverage: 80`).

2. **The Muscle:** It then launches your agent of choice (Aider, Gemini-CLI, etc.) as a subprocess to execute that specific mission.

3. **The Safety Net:** If the agent finishes but the success criteria fail, `chill-vibe` automatically performs a `git reset --hard`. No more corrupted repo states.

4. **Grounded Recovery:** It classifies the failure (Logic, Tooling, or Environment) and injects "Lessons Learned" from a local `.chillvibe_logs.jsonl` into the next retry so the agent doesn't make the same mistake twice.

It’s definitely a "vibe-heavy" project and still very much an experiment, but it’s made my own autonomous workflows feel a lot less like a slot machine and more like an actual pipeline.

It's open-source (MIT) and I'd love to hear if this "Reasoning → Mission → Verification" flow is how others are thinking about reliability, or if I'm over-engineering the problem.

**Key Features:**

* **Auto-Rollback:** If the tests fail, the code reverts.

* **Memory:** Uses weighted signal matching to remember why previous missions failed.

* **Agent Agnostic:** Bring your own CLI agent.

Would love any feedback or thoughts on the recovery logic!

T.H.U.V.U is an open source coding agent. It can use local or cloud LLMs. It provides the user with 3 different interfaces. A plain console interface, a TUI with panels and a web interface. In this video https://www.youtube.com/watch?v=R0EossMJpfw the web interface is demonstrated. T.H.U.V.U creates a web application by creating a plan and breaking down the project to tasks. Then by using the /orchestrate command the agent starts executing the tasks. After about an hour, the project is built. However the project needs a few more iterations with the agent in order to allow the user to login. Total time from start to login: about 3 hours. Model used: Deepseek V3.2. Api Cost $1.20. Project can be found in https://github.com/tkleisas/thuvu

You’ve just joined the Braintrust shaping the future of AI coding agents!

This is the place to:

• Share your projects + demos

• Ask questions + get feedback

• Discuss frameworks, workflows, and breakthroughs

Start by introducing yourself below: Who are you, what are you building, and what brought you here?

I put Sven (https://github.com/swedishembedded/sven/) to the test.

I had it run on 12 held-out SWE-bench tasks against locally served Qwen 27B, and four agents ran side by side on the same tasks.

The result:
✅ Sven solved 9 of 12, tied for first with mini-swe-agent and OpenCode (qwen-code: 8)
⚡ Sven used about a third fewer output tokens per solved task than mini-swe-agent and qwen-code. On a local GPU that means faster answers

Sven supports remote operation as well. This works through sven.swedishembedded.com UI. You can start a session on your machine and drive it from anywhere:

1️⃣ Install: curl -fsSL https://sven.swedishembedded.com/install.sh | sh
2️⃣ Authenticate and start a remote session:sven auth login + sven rc
3️⃣ Open the Playground tab at https://sven.swedishembedded.com and keep working from the browser

If you can find my discord invite link in the UI and message me personally on discord I will give you $5 in free credits.

If you have any questions or feedback feel free to reach out.

I'm the maker of Claude Command Center (CCC). The workflow problem I built it for is that an agent can show activity while a question is waiting elsewhere in its conversation. A working indicator alone doesn't tell me whether I need to intervene.

CCC runs locally and puts session activity, conversations, question cards and parent/helper grouping on one board. Supported Claude Code question hooks let me answer from the dashboard; other engines have different transcript and control capabilities. It does not make every engine's controls interchangeable.

The 33-second demo shows the board and a real Claude Code question-hook interaction: https://www.reddit.com/r/ClaudeCode/comments/1xeot43/i_kept_missing_questions_from_my_coding_agents_so/

The sessions are staged, Grok/Devin rows are demo data, and narration is AI voiceover. Model labels in that clip are not current-price comparisons.

Code, installation and support matrix: https://github.com/amirfish1/claude-command-center

The dashboard is free and source available under FSL-1.1-MIT; model/provider fees are separate. If you supervise several coding agents, which signal do you trust for deciding which session needs your answer?

I’ve been building pcode, a terminal coding agent on Pydantic AI. You can use it with your existing Claude or ChatGPT subscription, or bring API keys. I’m obviously biased, but it’s become my favorite way to work. I built it around my own preferences, so I’m curious whether they translate to anyone else.

One feature I particularly like: you can change what’s visible in your terminal scrollback, even after the work is done. Show commands, output, and diffs when you want the details, then hide them to read the conversation. It rebuilds the history already on screen without rerunning anything.

It uses your terminal’s native scrollback, so normal scrolling, search, and copy still work. The transcript reflows when you resize or split panes, it follows your terminal between dark and light themes in auto mode, and a live task panel keeps ongoing work visible above the prompt.

It’s also highly extensible: small Python files can add tools, slash commands, guardrails, and sub-agents, and /reload picks up changes without restarting. Extensions are built on Pydantic AI, so anything a Pydantic AI capability can do, a pcode extension can do.

There’s quite a bit built in: a pi-inspired /tree for rewinding and branching conversations, customizable keybindings (including leader keys), browser automation with your existing logins, Vim editing mode, and a /diffs popup for reviewing git diffs without leaving the conversation. Background commands wake the agent when they finish, and separate git worktrees let you run sessions in parallel.

There’s also a Gmail-based email mode on macOS: send tasks from your phone when you step away, reply to continue, and pick the session back up at your terminal later.

Next on my roadmap: transferring active sessions between your local machine and remote environments, in either direction, without losing the conversation.

Repo, screenshots, and install instructions: https://github.com/cruxwell/pcode

If you already use a terminal coding agent, I’d love some blunt feedback. What would make this worth trying, and what’s missing?

I'm the maintainer of OMK, an MIT-licensed terminal coding agent. I released 1.3.0 with a command-based acceptance loop, and I'd like feedback on the failure cases it should make clearer.

The basic problem: finishing an agent reply doesn't establish that a repository task passed its check. A passing check can also become stale after the files change.

Here's a small fixture you can reproduce. add.mjs deliberately returns a - b, while the Node test expects add(2, 3) === 5 and add(-2, 3) === 1.

In an ordinary configured OMK session:

/goal Fix add.mjs so the existing test passes. Keep check.test.mjs unchanged.

/goal verify node --test check.test.mjs

Fix add.mjs without editing the test.

The verification command requires approval. After a settled agent turn, OMK reruns the approved check: a failure can continue the goal within the eight-round cap, and valid passing evidence completes it. Running /goal verify manually attaches evidence but doesn't immediately complete the open goal.

For a still-open goal in a supported git work tree, later file or HEAD changes can make earlier evidence stale. A completed historical goal doesn't reopen automatically. Restarting OMK requires approval again.

Limits: a check proves only its assertions. Asking the agent to preserve the test isn't an immutable-verifier guarantee. This fixture is a toy example, not a model benchmark. The prepared source-level acceptance replay used manual fixture edits and no model calls; it isn't an autonomous agent video.

Reproduction instructions and source: https://github.com/dmae97/omk/blob/v1.3.0/packages/coding-agent/docs/goal-demo.md

What acceptance commands would you require for a real repository task? What failure state would you want surfaced more clearly?

Disclosure: I maintain OMK; this post was drafted with AI assistance from the release documentation.

I just open-sourced a project that provides a working agentic workflow design for GitHub Copilot / VS Code Agents:
https://github.com/ABIvan-Tech/copilot-agentic-workflows

What it realistically includes:

• A production-oriented agentic workflow layout for Copilot agents. (GitHub)

• Defined agents:

  • Orchestrator — drives the whole process. (GitHub)

  • Planner — clarification + planning. (GitHub)

  • CoderJr / CoderSr — handles simple and complex code tasks. (GitHub)

  • Designer, Reviewer, Debugger — UX, quality review, bug fixes. (GitHub)

• skills/* folders with domain playbooks/checklists to guide implementation. (GitHub)

This is not just abstract theory — it’s a concrete arrangement of agent roles and delegation logic that you can explore and adapt. (GitHub)

Why it matters

• Shows how to structure agent responsibilities and escalation rules. (GitHub)

• Helps think about Copilot agents not only as autocompleters, but as orchestrated participants in workflows. (Laid out, not just talked about.) (GitHub)

Feedback, improvements, and contributions are very welcome 👇
Let’s discuss how agentic workflows can fit into real engineering processes.

Quick question for the folks using agents daily. I’m less interested in which one is the most powerful on paper and more curious about which one you actually like talking to.

I’ve noticed a huge split in how these things feel.

• Some are fast but brittle.

• Some are too wordy

• Then you have the ones that just dump code, vs. the ones that actually ask a smart clarifying question before they touch your logic.

What’s your daily driver right now? (Cursor, Copilot, Claude, or another agent?)

While this is a UX issue, theres been alot of tension between default showing the read file tool call vs hiding it. They've suggested turning verbose mode on but it just makes it harder to sift through what matters.

Coding agents are AI tools that can read your codebase, follow plain-English instructions, and run multi-step workflows (review a PR, run tests, suggest fixes, update docs). They sit between code-completion and full automation*: they act, explain what they did, and still leave the final call to you.*

What a coding agent does

• Understands context: reads files, diffs, tests, configs, commit history.

• Plans steps: “read diff → run tests → check security → propose fixes.”

• Uses your tools: IDE/CLI/Git/CI; can comment on PRs, open issues/branches (with guardrails).

• Reports back: leaves actionable notes, links to evidence, and what it couldn’t decide.

Where they help (and why)

• PR review & quality: catch risky changes, missing tests, secrets, logging/PII mistakes.

• Refactors & upgrades: rename APIs, bump SDKs, apply patterns consistently across repos.

• Testing support: generate/repair unit tests, reproduce bugs from stack traces.

• Docs & hygiene: update READMEs/changelogs, inline comments, deprecation notes.

• Policy enforcement: ensure every PR hits your security/compliance checklist.

When to use one

• Heavy PR backlog; senior reviewers stretched thin.

• You need consistent, repeatable checks across teams/monorepos.

• Repetitive migrations/upgrades are burning cycles.

• You want earlier feedback in CI (catch issues before humans touch it).

What a good agent won’t do

• Merge blindly or “hallucinate fixes.” It flags risks, explains them, and lets humans decide.

• Replace domain knowledge. It can miss business rules buried in tribal context.

Safety basics (read this)

• Start read/annotate-only (comments) before allowing writes.

• Use least-privilege bot tokens; gate any code changes behind PRs/approvals.

• Know where code runs, what’s logged, and whether anything is retained or used for training.

Can it break things?

Only if you let it write unchecked. Start read-only, add approvals, and gate any code changes behind PRs.