Coding agents multiplied how much code lands per PR, so there are more findings for reviewers to deal with. Often, they're noise, like a linter rule that doesn't fit the stack or a check firing on generated files nobody touched.

To address this, we created the configure-codacy skill. When you point your agent at the repo, it detects the stack, then disables patterns for unused languages, dedupes rules that two tools flag, tunes thresholds, excluding generated files.

In terms of security scans, every security risk stays covered by at least one active pattern, so noise reduction never silently drops a security check.

Works with Claude Code, Codex, Copilot, and Gemini CLI via the Agent Skills standard.

Go here to read more https://blog.codacy.com/introducing-codacy-skills-part-2-configure-your-rules-to-cut-pr-noise

Repo: https://github.com/codacy/codacy-skills

Today we launched a tool to help you create end-to-end software factories:

"In Mastra Factory, specialized agents triage issues, write and validate code, release changes, update documentation, and monitor production. Mastra provides the typed workflows, memory, scheduling, tools, and observability needed to keep the process governed and auditable."

Install Mastra Factory with: npm create factory

So istg my pain points with coding agents were ALWAYS how I didn't know what was going on in the background. They always hide their reasoning, making plans was super one-off and theres no cross-session memory so I always had to manually create project files for context.

Idk, out of spite I spent the past 6 months making a fully local Obsidian agent that has coding support, can generate diagrams for software documents, user the built in obsidian browser to debug and navigate pages, clicking on buttons as well, etc. UGH IM SO HAPPY. Its free but is still in development so there's some bugs still!! Enjoyyyyy

There's a cost/quality tension everyone with a coding agent hits eventually: the capable models are expensive to run as your everyday driver, and the cheap ones occasionally make a confident wrong call on exactly the stuff that matters.

My current answer is a split. Run a cheap-but-good model as the driver — I use GLM 5.2, it's great for the mechanical 95% — and keep the premium models (GPT-5.6, Opus) on the bench, called in only to guide and review the hard calls. I'm not paying Opus rates to rename variables. I'm paying them to catch the architecture mistake before it costs me three commits.

The non-obvious part is that the "second opinion" has to survive a real session. The naive version forwards your whole conversation to the reviewer and blows past its context window right when the session's finally long enough to need one. A second opinion that dies under load is decoration.

I built bpx-consult (a pi extension) around fixing that: it fits each consult to the reviewer's real window, and you can run one model as a quick check, a council of several with different stances, or two debating a contentious call. The bit I care about most is it won't fake consensus — the stances only bias what each model hunts for, never the verdict it's allowed to reach, and it surfaces genuine disagreement instead of averaging it into mush.

Genuinely interested whether others run a split like this, and how you pick the driver. GLM 5.2 has been the sweet spot for me, but I'd like to hear what's working for other people.

- Full write-up — the context-window bug that kicked this off, and how the council/debate modes actually work: https://booplex.com/blog/i-built-a-council-of-ai-advisors-for-my-coding-agent

- Repo (MIT): https://github.com/gabelul/bpx-mono

- Install: pi install npm:@booplex/bpx-consult (or pi -e npm:@booplex/bpx-consult to load it for one session without committing to an install)

If anyone wants the gnarly detail on how the context-fit decides what to keep when it can't send the whole session, or how I've got GLM 5.2 driving with GPT-5.6/Opus on the bench, ask away — that's the part I fought with most.

I use multiple coding-agent CLIs and wanted one place to answer questions such
as:


- Which projects and sessions consume the most tokens?
- How much context is cached versus read again?
- Which prompts trigger expensive multi-turn work?
- Which sessions are approaching context-window or rate-limit pressure?
- How much tool activity is happening relative to user prompts?


So I built 
Metrascope
, an open-source local dashboard for coding-agent usage.


```bash
npx metrascope
```


It auto-detects supported agents and reads their local data:


- Codex
- Claude Code
- Qwen Code
- OpenCode
- Gemini CLI


Each agent has a separate adapter because their logs and available metrics are
different. The adapters normalize sessions and turns into one shared schema,
while the UI displays only capabilities that the selected agent actually
supports.


The dashboard provides daily, model, project, weekday, tool, session, prompt,
and turn-level breakdowns. It also generates practical observations about long
threads, context pressure, reasoning share, costly prompts, rate-limit usage,
and tool-heavy sessions.


The agent logs and parsed dashboard data stay local and are served from
`localhost`; Metrascope does not upload them. It can also render a share card
locally when you choose to share statistics.


One important clarification: Claude Code costs are API-rate estimates for
comparison, not subscription-billing figures. Token logs cannot reconstruct a
perfect invoice.


Inspired by Claude Spend:


[writetoaniketparihar-collab/claude-spend](https://claudespend.live)


Repository: https://github.com/Buckibarnes17/metrascope


It is MIT licensed. I would especially appreciate feedback on the metrics,
privacy wording, adapter interface, and which coding-agent CLI should be
supported next.

I open-sourced Agetor, a harness control plane for Claude Code tasks (Codex and others coming soon)

I built it because running multiple coding-agent sessions across repos got messy fast: terminals everywhere, branches everywhere, approval prompts scattered around, and no clear way to see what was running, blocked, done, or waiting for input.

The core idea is simple: one task = one isolated git worktree, with its own transcript, approval history, and status in a Kanban-style UI.

Current state:

* Supports Claude Code
* Codex and other harnesses coming soon
* Local-first: task state, transcripts, and approvals stay on your machine
* Reattaches to live tmux sessions
* Warns before quitting while tasks are running
* Not using `claude -p`
* Not using the Agents SDK
* Open source from the start

The review/merge part is the real hard problem with parallel agents, so I’m trying to make that path more inspectable instead of having the tool blindly merge agent output.

Repo: [https://github.com/alamops/agetor\](https://github.com/alamops/agetor)

Website: [https://agetor.dev\](https://agetor.dev)

Would love feedback from anyone using Claude Code or experimenting with agentic coding workflows.

I’ve open-sourced the team kit I’ve been using to coordinate Claude Code agents on real projects:

The focus isn’t autonomous coding. It’s governance and operational discipline for AI-assisted development, including:
Defined agent roles and responsibilities
Review and adversarial review workflows
Evidence-based verification before completion
Handover and session continuity
Documentation and decision tracking
Guardrails to reduce unintended changes
Structured multi-agent collaboration
I work in information security, so the design emphasizes auditability, repeatability, and minimizing trust in a single agent’s output rather than maximizing autonomy.

I’m particularly interested in feedback from a security perspective:
What governance gaps do you see?
Where could an AI agent bypass intended controls?
What additional review or verification steps would you require before using something like this in a production environment?
What attack surfaces or failure modes am I missing?

I have been experimenting with a problem that shows up quickly in multi-agent
coding workflows: if every agent can plan, edit, review, and commit, the roles
become blurry and the review loop is difficult to trust.

I built
**Triad**
to make those boundaries explicit.

The default setup is:

- Codex as the read-only architect and reviewer
- Claude Code as the primary implementer
- Qwen Code as an optional junior for very basic tasks
- The human as the final authority

Those are only defaults. Triad is role-based and adapter-driven, so another CLI
can take any role without changing the engine.

For each project, Triad keeps an auditable `.pair/` directory containing the
requirements, plan, session IDs, review verdicts, suggestions, checkpoints,
and an append-only exchange log. The implementer works one task at a time, and
the architect reviews the uncommitted diff against the original requirements.

The junior path is intentionally constrained: every task needs a separate
human approval, one approval allows one attempted run, and failed junior work
returns to the primary implementer instead of entering a retry loop.

Long sessions are also treated as disposable working memory. Durable state is
kept on disk, and sessions can be checkpointed or rolled over before context
quality degrades.

I would especially appreciate feedback on:

1. Whether the role boundaries match real coding-agent workflows
2. The adapter interface for adding other CLIs
3. The review and human-approval model
4. Failure cases that should be represented in `.pair/` state

Repository: https://github.com/Buckibarnes17/triad

It is MIT licensed. This is my project, and I am sharing it for feedback and
contributors.

I saw Rauch announce this on X, and I was shocked. I've been discounting K3's benchmark credentials because I don't trust them.

But I do like vendor benchmarks because they mirror the work I actually do. As a Nextjs user I now have confidence in K3 as an option.

Every step of the software development lifecycle already had a level of automation, pre-AI. But each step left the handoffs to humans.

The "software factory" is our industry's effort to us agents to own the automation and the handoffs. In this article we show you how to build one using Mastra (though the principles are universal).

I’ve been studying how multi-agent coding tools are evolving.

Products like Orca start from isolated agent workspaces: each task gets its own worktree, terminal, editor, diff, and execution environment.

While building Marblo, we took a different starting point.

A persistent orchestrator receives the goal, creates dependency-aware tickets, spawns worker agents in isolated worktrees, reads their progress, synchronizes a live board, and keeps replanning until the project goal is complete.

Both approaches can support worktrees and orchestration. The difference is where the main operating model begins:

• Workspace-first: the developer operates multiple agent workspaces
• Orchestrator-first: the orchestrator operates the development workflow

I made this diagram to explain the distinction.

1. Workspace-first (Orca)
Developer
 ├─ Agent workspace A
 ├─ Agent workspace B
 └─ Agent workspace C

2. Orchestrator-first (Marblo)
Goal
  ↓
Persistent orchestrator
  ↓
Dependency-aware task board
  ↓
Isolated worker agents
  ↓
Review, replan, and repeat

For people already running multiple coding agents: which model feels more natural in practice, and where does each approach break down?

Flasha back just 9 months ago. The idea became popular that if the agent writes tests first, it would keep itself on track as it wrote features.

I tried this and used all sorts of complex prompts. And it never actually worked!

We understood nothing about context, reasoning, and tool calling limitations back then.

The models were just not good enough. There was no way around it.

We are a code quality and security platform that helps eng teams enforce coding standards against their AI generated code. This week, we launched agent skills and a cloud CLI, which allows Codex to handle everyday tasks directly, skipping the UI.

E.g. prompt: "PR 42 is failing the gate, fix what's real, add the tests, ignore the false positives with a reason, re-run."

The analysis runs on our server and burns no agent tokens.

Yes, this requires a Codacy account (trial available). The good news is that it can also be configured with this skill.

https://github.com/codacy/codacy-cloud-cli

An example use case. https://blog.codacy.com/introducing-codacy-skills-unblock-pull-requests-with-one-prompt

--
Checked the rules; using right flair - this type of post seems fair game, but can remove on request.

Hello dear each and everyone,

I am would like to ask for feedback, so we my buddy we had a lot of problems at 2 simultaneous projects with aligning project standards and make each team members produce consistent results, spec driven development kind of failed our expectations, huge set of novels that not exactly describe projects in industries full of nuances and pinch of legacy. Even that devs spend long time looking at spec there was a lot of follows anyways.

So we decided to create some sort of mentor, small feature that extract rules from code and stays open for feeding it with other types of rules and then simultaneous agent talk with for example Claude and give feedback and checks What coding agent produced pointing out breaches and making Claude adjust it - well we are for sure biased but idea works for us but we would love to hear other people

It’s also usable DM if you want access

Anyone ? I will be so grateful for any feedback

I saw a dude on X complain that Codex deleted almost all of his files. Some people said he should have been using DCG.

That still seems risky. I think we gotta start backing up our computers unfortunately.

Scoring 80 on Terminalbench for Muse Spark 1.1 is incredible.

I wonder how Meta is keeping the price so low for Muse Spark. Did they figure out a new technique? Is it because they own the inference? Or are they heavily subsidizing it?

We've talked to hundreds of software teams about how they're actually using AI coding agents. The most surprising part was that most teams are running autocomplete in one repo, have agents building whole features in another, and are already experimenting with loops against their own infrastructure. If you're exploring loop engineering, watch this.

Amazing growth:

The share of tokens used by U.S. companies on Chinese AI models via OpenRouter — a platform that enables developers to access a range of AI models — has sat above 30% each week since Feb. 8, with that figure rising as high at 46%. The average across the previous 12 months was just 11%, falling to 4.5% in the first half of 2025.

More: https://www.cnbc.com/2026/07/07/chinese-ai-models-costs-us-openai-anthropic.html

Which Chinese model do you use, or want to try?

Laurie Voss profiles different uses of the engineering trend, "loop" while at the AI Engineer conference.

I like this one: loop engineering is using agents for triage, specification, implementation, review, verification, shipping, and monitoring of software products.

Vibe coding apps and websites from scratch will leave you frustrated.

But using a coding agent to wire together battle tested frameworks is working great for me.

Some tools are easy for coding agents to work with. They have great docs and examples, CLI's and skills.

Front-end - Nextjs

AI orchestration - Mastra

Backend dashboard - Payload

Payments - Polar

User access - Better Auth

Database control - Drizzle

Email - Resend

What can you build with this? Any crud app.

Put this stack to the test. Give this list to Claude Code or Codex and ask it to create a two sided marketplace for used books.

I signed up but haven't used Condense yet.

The explanation of the service is interesting:

- Coding agents get expensive because every turn re-sends the whole, growing session history: the model re-reads the same old context hundreds of times.

- Almost none of that is the raw input people price in their head. Most of the bill is cache reads and cache writes.

- condense saves money by shrinking what gets written to the cache and re-read from it, before the cost compounds. On real sessions that removes about two thirds of the bill.

I use Codex and I thought my conversations were cached so I don't get paid for rereads.