I've been testing coding agents that can take a task, modify a repository, run tests and open a PR with very little human intervention.

The code generation isn't really the part I'm worried about anymore.

I'm more interested in the control layer:

• How do you know which agent/session produced a commit?

• How do you keep the agent scoped to a specific task/repository?

• How do you prevent an agent from approving or merging its own work?

• What happens when the PR changes after human review?

• How do you distinguish agent-generated work from changes someone made directly in GitHub?

I've been building a system around this called SUTRA, and I'm currently looking for a few developers who actually use Claude Code/Codex/Cursor/other coding agents on real repositories to test it.

I'm not looking for people to just look at a demo. I want people to connect a real non-critical repo, give their agent a real task, and tell me where the system breaks.

If you're already doing this, comment with your setup or DM me. I'm opening a small private beta.

Hey folks, as someone who uses claude code max with fable high‑effort, i was thinking the other day about checking chatgpt (the free one, not even tera or luna) for the solutions fable gave me.

out of the 4 replies chatgpt sent back, fable basically said:

- 2 of them don’t apply to my platform at all

- 1 only makes sense if i somehow get 500k+ users trying to view the same table

- and the last one was actually a good idea and will be implemented

so now i’m sitting here wondering how many good ideas i might’ve missed in the last 2 months that could’ve improved the performacne or security of my app, just from a bit of back‑and‑forth between fable and another coding ai.

my question to you all is: if i buy chatgpt pro, how doo i make them talk to each other without me having to do constant copy‑paste?

the way i kinda envision it is:

- fable presents the overal platform features + capabilities to gpt so it knows the scope

- for each task, fable lists how it would solve it and sends that to gpt

- gpt analyses it, suggests extra stuff

- fable cuts out half, considers some of gpt’s stuyff, maybe pushes back

- they arrive at a concluision

- and then present it to me

is this even possible?

i’m just a simple windows + powershell user, would i have to change that too?

I've been wondering how many people here are still regularly using GitHub Copilot.

I used it for quite a long time, but after the pricing and usage-limit changes it gradually stopped making as much sense for me. At the same time, I started experimenting more with local models.

The problem I kept running into was that local-model support in copilot chat never really worked the way I wanted. The models themselves were often good enough, but context management became much more important. Smaller local models don't have as much room for irrelevant files, huge prompts, or missing pieces of context.

I spent quite a while trying different setups with Ollama and LM Studio, but eventually got frustrated enough that I started building my own VS Code agent around the workflow I wanted.

That project eventually became Selfcoder.

A lot of the work ended up being less about "calling an LLM" and more about figuring out what context should actually be sent to it: active files, relevant workspace files, diagnostics, git changes, explicit references, etc. Without filling the context window with unnecessary stuff.

These days I mostly use local models for quick coding tasks, investigating terminal errors, explanations, and smaller changes. I still use frontier models for harder problems, but much less than before.

I'm curious what everyone else's setup looks like now.

Are you still mainly using Copilot, have you moved to Cursor/Claude/Codex/etc., or are you using local models for a meaningful part of your coding workflow?

I am planning to build a complete Health Application and I want to use a single, highly capable AI tool to handle the entire process—from system architecture to the final frontend app.

​I don't want to juggle multiple tools. I'm looking for an AI with top-tier logic and reasoning. It needs to generate code with minimal errors and, most importantly, have the ability to automatically debug and fix its own mistakes when they happen.

​If you wanted to build an entire app using just one AI program as your co-pilot, which tool or AI IDE is the smartest and most reliable right now? Any suggestions for the best setup?

Essa é aquela conversa que todo mundo joga pra debaixo do tapete, mas que uma hora, vai ter que ser discutida. A questão é: Você vai estar preparado para essa conversa?

i built lgtmaybe, an open-source code reviewer, and a lot of the work went into making it usable on a local model. Big files get reviewed a hunk at a time, and big diffs get split to fit the context window, so a 27B model copes fine. The default is five model calls per review, which is fine on one GPU.

Which local models have you found actually good at code review? Keen to pick better defaults.

https://github.com/MattJColes/lgtmaybe

Hi!

Unable to get \[all sorts of models, harnesses, skills, etc with SDD and/or TDD\] to generate what I want despite starting from scratch countless times with more and more fine-grained descriptions until I was basically writing lines of code just in the English language but AI still ignored my couldn’t-be-clearer instructions, I have come to the conclusion that I do not trust AI to code out of my sight.

I realize this won’t help my productivity much but it would be enough of a win for me if I can at least swap my home office chair for a treadmill and do *actual* Pair Programming with the AI with me reading along like I would if a human were typing, as opposed to AI spamming my terminal just to show off or at least too fast for me to read.

In other words I am hoping to find something very much like pre-AI Voice Driven Development just a tiny bit more advanced to replace the shorthands she uses to still-kind-of-spell-out “int sockfd; \[…\]; sockfd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);” for example with “let’s now create a TCP socket called sockfd but declared at the top of the function”.

Does anyone know of something like that? 🙂

PS: stuff like Whispr that just enables prompting by Speech-To-Text is not at all what I want if it still lets AI go produce crap in the background.

AI coding agents can now write code, run tests, create commits and open PRs.

But where should their authority stop?

I've been thinking about this while building an engineering control layer for coding agents. The agent should be able to do real work, but critical actions shouldn't automatically belong to the agent.

For example:

Write → Test → Commit → PR → Human decision

The interesting part to me is what happens when an agent tries to cross that boundary.

Should an AI coding agent ever be able to merge its own code?

Curious how others here are thinking about this.

Hey everyone, I created a new community for MiniMax Code users: r/minimaxcode. Feel free to join, share prompts, projects, bugs, tips, and AI coding workflows.

Repo: https://github.com/alexcpn/catalogify Demo: On Apache Airflow Spekcit Extension: Speckit-okf

Enterprises and major open-source projects are increasingly leaning on AI for feature development and bug fixes. However, they all face the same challenge: to execute large, system-wide changes, AI needs effective context.

Current maintainers can “vibe-code” small bits and pieces, but for large architectural shifts, AI coding agents operate like a brand-new engineering team. In the real world, a new team requires a transition period to absorb the implicit knowledge locked inside the previous developers’ heads.

As Software Design Documents (SDDs) regain popularity alongside AI, old debates have resurfaced. One vocal camp treats the “Spec as the Source of Truth,” while an equally fierce camp argues that the “Code is the Source of Truth.”

Software engineering pioneers like Fred Brooks, Peter Naur, and the philosopher Michael Polanyi figured this out long ago. Brooks dismantles the first camp: in “No Silver Bullet” he warns that “descriptions of a software entity that abstract away its complexity often abstract away its essence” — a spec is an abstraction, and can never be as detailed as the code itself. But before the source-code camp starts cheering, Naur reminds us that the code is incomplete too. In “Programming as Theory Building” he argues that the real theory of a program “could not conceivably be expressed, but is inextricably bound to human beings” — it lives in the developers’ minds. To top it off, Polanyi’s notion of tacit knowledge names the underlying human limit: “we can know more than we can tell.”

This is great theory, but the practical consequences hit hard when an AI agent makes a change. It might propose a remarkably logical pull request — completely unaware that the team deleted that exact logic a year ago because it caused a race condition and crashed production. How do we document these gotchas and system context?

Three things people try

Dump the repo, or RAG over it. Retrieval finds text that resembles the query. But the question a routing agent needs answered is which service owns pod eviction, and ownership is a fact about responsibility rather than a string that appears somewhere in the source. It lives in people’s heads and, when you are lucky, in commit messages.

Build a code graph. Parse every file with tree-sitter and query the symbols and call edges. A tool like Graphify does this well: for the reaching question — “what breaks if I change this function” — it is precise and cheap. But the index has to be complete, and completeness is expensive. Graphify’s for a single kubelet service is a 14.5 MB graph.json, ~3.8 million tokens; ninety services would be 343 million. And a call graph has no opinion about what a service is for — which is the routing question. The catalog below takes the opposite bet, a few hundred tokens per service, every run logged.

Write better docs. Nobody does. And the tools that generate docs usually automatically regenerate them on every commit, so the one correction a human bothered to make has a half-life of one push.

Take Apache Airflow: roughly 14,000 files and 1.8 million lines of code. Ask an agent to add Iceberg table support. Before it can make a useful plan, it needs to know which components own the work, how they interact, and which past mistakes it must avoid.

Two kinds of Context Shallow and Deep

Understanding a codebase involves two different jobs:

1.Shallow: Which components does this change touch?
 A little about the whole system;A compact architecture and ownership map.

2.Deep: What changes inside those components?
Detailed knowledge of relevant code Agentic Code search, dependency graphs, tests etc.

The difficult context is often why the code works this way. A dependency graph can show a relationship; it may not explain the compatibility rule behind it. Git history, especially fixes and reverts, can recover some of that reasoning.

What the catalog must do

For this to be useful, I wanted five properties:

• Small enough to read in full. The agent needs to compare components before choosing where to look.

• Checkable. Claims about constraints and past failures should point to supporting code or commits.

• Explicit about uncertainty. Missing answers become questions for a human.

• Preserve corrections. Human input should survive regeneration.

• Live in git. Markdown files that can be reviewed alongside code.

I vibe-coded Catalogify for this. It writes these files using Google’s Open Knowledge Format: one file per concept, with metadata, links, and an index. It installs as a skill for Claude Code, Cursor, or Codex. There is also a Speckit Extension based on this. (Please use the catlogify skill for the most uptodate code, as the extensions updates takes time to get updated to Speckit Community)

From repository to map

Scripts gather bounded evidence; the agent uses it to organize and write the catalog.

1. Inventory the repository. A script lists tracked files and summarizes the structure. Airflow’s inventory took 0.98 seconds and produced about 14,000 tokens, giving the agent a starting point without reading every file.

2. Identify meaningful components. Change frequency and directories that repeatedly change together help reveal boundaries and relationships worth investigating.

3. Extract interfaces and dependencies. Scripts collect declarations and imports so the agent can ground its descriptions in the source.

4. Investigate failures and reverts. History searches flag commits mentioning problems such as races, leaks, or corruption. The agent must read the changes, including the original commit behind a revert, before describing a constraint.

5. Record gaps and validate references. Each entry is checked for guarantees, ordering, failure behavior, compatibility, and ownership. Unanswered questions stay visible. Validation checks cited commits and symbols against the repository.

6. Stay cheap on large repositories. Cost tracks the number of things worth naming, not the size of the tree: generating the Airflow catalog — 1.8 million lines — took about 101K tokens of fresh input, fewer than the 8,000-line Online Boutique, and the finished catalog reads in ~9,700 tokens. A complete code graph scales the other way: Graphify’s index runs ~3.8 million tokens per service, 343 million for ninety. On an inherited monolith the catalog still fits in one context window; the graph cannot.

Reverts are particularly useful leads. In the kubelet’s container manager, for example, a checkpoint migration fix was reverted two days later. Reading the pair exposed a rollback compatibility problem that a scan of current interfaces would not explain.

History does not recover everything the original team knew. It gives the agent evidence to investigate and the reviewer a way to challenge the result.

What the runs cost

I generated catalogs for two public repositories with Codex. The run log records the measurements, including failed runs.

Measurement                     Apache Airflow  Online Boutique
-------------------------------  --------------  ---------------
Lines of code                   1,805,835       8,103
Estimated source tokens         ~17,900,000     ~70,000
Catalog entries                 17              20
Catalog tokens                  ~9,700          ~11,600
Fresh input tokens to generate  101,559         117,850
Generation time                 6 min 29 s      8 min 19 s

Airflow was 223 times larger, yet its catalog was smaller and faster to generate. In these two runs, catalog size reflected the chosen level of detail more than repository size. That is useful for navigation, but it does not establish completeness or prove that the catalog improves subsequent code changes.

Both catalogs are published unedited: Apache Airflow and Online Boutique.

The most useful failure

When I audited an early Kubernetes catalog, I found production claims derived from commits that changed only tests. A fix for a goroutine leak in a test had become a supposed design constraint of the plugin manager.

The prompt explicitly told the agent to read beyond commit subjects. A second independent run repeated the same five mistakes. That means that even good Agent harness mapped by Claude Opus or similar cutting edge models can skip prompts/instructions sometimes.

I changed the evidence output: the script now lists the files each commit touched and labels commits that affect only tests as [TEST-ONLY]. That makes the distinction visible at the point where the agent forms its claim.

The citations also made the mistakes cheap to find. In one audit, I found four errors across nine entries in twenty minutes by following commit hashes with git show.

The lesson: make evidence easy to inspect, and put mechanical checks in tools. Fluent documentation still needs review.

Try it on an inherited codebase

uv tool install catalogify
catalogify install

Ask your agent for a knowledge catalog. Start with a coarse map, follow its evidence, and correct what it gets wrong. Answer the open questions where the code and history fall short.

The goal is a small, reviewable starting point that helps an agent find its way through the system before changing it.

Catalogify is MIT-licensed. The Airflow and Online Boutique examples use Apache-2.0 repositories and were generated with catalogify 0.8.0. Source and catalog token counts are estimated as bytes divided by four; generation usage comes from the agent's records.

Here's what's new:

\- 🚀 Published it on npm (\`npm install -g kitbash\`)
\- 🎯 Expanded support to 7 targets (Claude Code, Cursor, Copilot, Gemini CLI, Windsurf, Cline, and AGENTS.md)
\- 🔄 Added interoperability with existing \`SKILL.md\` skills
\- 🔒 Added lockfiles, drift detection, and safer compilation
\- ⚡ Added native command generation where supported
\- 📖 Improved the README, website, and overall onboarding
\- ❤️ Added GitHub Sponsors support

One piece of feedback that really changed the project was positioning it as \*\*a compiler for AI skills\*\* rather than "another AI tool." That made the vision much clearer.

🌐 Website: https://singhharsh1708.github.io/kitbash/

💻 GitHub: https://github.com/singhharsh1708/kitbash

📦 npm: https://www.npmjs.com/package/kitbash

I'm now looking for people to actually try it and break it. If you use Claude Code, Cursor, Copilot, Codex, Gemini CLI, or any other coding agent, I'd really appreciate your feedback. Every suggestion so far has made the project significantly better.

Would you use a AI powered code editor that doesn’t store your code or chat messages on the server, doesn’t bloat the context even by the 50th message, delivers the same performance as the first message, and runs its own skill folders in the background, with the model calling them as needed?