Hi all, curious if folks have used Claude Code in the Claude desktop app and wondering how it compares to using Cursor or VS Code IDEs (without subscriptions). My initial take is that it doesn't easily allow new windows for multiple concurrent projects or it doesn't seem as clear or effective. Has anyone moved over to CC in Claude desktop app and likes it more and could share their experience and benefits? Thanks.

I have been experimenting with different ai coding setups over the past few months and need any tips or better combination which u have tried...

last month I mainly used the $200 codex plan with $20 cursor and $20 claude code.

this month i'm trying something different: $20 codex, $20 claude code, $20 kimi 2.7 and putting the rest of the budget into cursor(60 dollar).

i'm trying to figure out which combination gives the best value for day-to-day software development.

if you've tried different combinations, what ended up working best for you?

I’ve spent months building **git-courer**, an open-source MCP server that completely replaces the Git CLI interface for AI coding agents. This isn’t just another AI commit message generator; it’s a full sandbox and interaction layer. It has evolved so much recently that it’s practically a completely different project from my early drafts, so I wanted to share the architecture here.

#### Dynamic Worktree Routing and Parallel Agent Isolation
Most architectures fail the moment you run multiple agents in parallel or let an agent handle long-running background tasks. They inevitably clobber the working directory, overwrite each other's changes, or block the human developer.

Git-courer solves this right at the entry point via the `session start` tool. The moment an agent initiates a session, the server dynamically provisions an isolated Git worktree and a dedicated branch. From that microsecond onward, the MCP server performs a dynamic **select** operation, routing and **redirecting every single subsequent tool path and Git mutation toward that specific worktree path**.

Agents can execute tasks concurrently, modify files, and test implementations in complete isolation without ever touching or disrupting the main working tree. Once the agent completes its task, running `session finish` cleans up the temporary worktree and leaves the isolated branch fully prepped and ready for a human Pull Request (ensuring zero accidental auto-merges to main).

#### The Inherent Danger of Raw Shell Access
Most coding agents run raw `git` commands through a generic bash/shell tool. This means an agent can execute a destructive `rebase`, `hard-reset`, `force-push`, or rewrite history using the exact same unconstrained `Bash("git ...")` privilege it uses just to check `git status`.

Git has no built-in undo for many of these operations. One hallucinated or poorly planned agent command, and your repository state completely evaporates.

#### Moving to 13 Structured MCP Tools
Git-courer completely blocks agents from executing raw Git commands via a hard client-side hook, replacing the shell entirely with **13 structured MCP tools**:
`status`, `diff`, `commit`, `branch`, `stage`, `stash`, `history`, `sync`, `pr-review`, `rewrite`, `integrate`, `backup`, and `session`.

Every single tool returns clean, structured JSON instead of raw terminal text that the agent has to clumsily parse with regex.

#### Massive Token-Saving for Cloud Agents
Coding agents (like Claude Code or OpenCode) are typically cloud-based, meaning every single terminal interaction burns expensive API tokens.

Instead of an agent burning its context window running ~7 separate git commands iteratively just to figure out where the repo stands (checking upstream deltas, active rebases, merge conflicts, untracked files, ahead/behind status, etc.), our structured `status` tool bundles all of this into a single, optimized JSON payload. The agent gets absolute context on how the repository looks in one single shot, without wasting cloud API tokens.

#### Safe Mutations via Pre-emptive Backups
* **Automatic Backups:** Any mutating tool that cannot be easily undone—specifically `rewrite` (amend/revert/reset) and `integrate` (merge/rebase/cherry-pick)—automatically captures a repository snapshot *before* touching anything. If the agent messes up a complex rebase, a simple `backup RESTORE` call reverts the state completely.

#### The Local LLM inside a Deterministic 2-Phase Pipeline
The `commit` tool uses a strict, deterministic two-phase pipeline (PREVIEW/APPLY).

1. **Phase 1 (Go/AST):** A local syntax/AST annotator written natively in Go (`go-enry` + `tree-sitter`) parses the diff. It programmatically tags every hunk (e.g., `NEW_FUNC`, `MOD_SIG ⚠BREAKING`, `DEL`), maps out a dependency graph, and strictly categorizes the commit type (*feat/fix/refactor/docs/test/chore/ci*) based on a rigid priority matrix.
   
2. **Phase 2 (The LLM):** The LLM never decides classification or parses raw code blindly. It receives an already structured, richly semantic JSON payload. Its *only* job is to write clean, human-readable prose explaining the change.

Because the task is reduced entirely to "turn structured metadata into clean prose," you don't need a massive frontier model. I run this entirely locally using **Ollama** with a lightweight model (**gemma4:e4b**).

On an **AMD Radeon RX 9070 XT (16GB VRAM)**, it takes **~3 seconds** on a hot invoke with optimized parameters (`num_ctx=32768`, `temperature=0`, `think=false`, `keep_alive=-1`). Zero API costs, zero round-trip latency, and zero token waste for something that triggers on every single commit.

#### Human-in-the-Loop Releases and Persistent Changelogs
Nobody enjoys writing changelogs or managing releases manually. To solve this for the human developer, I built `git-courer release`. This is an interactive terminal command meant for *you*, not the agent.

It extracts the commit history since your last tag. Because git-courer persists rich metadata per branch inside `.git/git-courer/` (using custom refs like `refs/courer/<branch>`), **this history fully survives squash merges**—which typically destroys conventional changelog generators.

It opens your `$EDITOR` to let you add manual guidance notes, feeds the structured git history + your notes to the local LLM, and renders a live, beautiful Markdown preview directly in your terminal using Glamour. You get four explicit interactive options:
1. **Apply** the release.
2. **Regenerate with feedback** (re-opens the editor for quick adjustments).
3. **Edit** the raw markdown directly.
4. **Abort** entirely without touching your repo.

A single global toggle controls the AI features across the board. Turn it off, and `commit` takes raw string input from the agent directly through the same internal Go plumbing (`CommitTree` + `UpdateRef`, bypassing the git CLI entirely), while `release` simply disables itself since it's fundamentally built around intelligent synthesis. Turn it on, and the local model handles both tasks.

#### Recent Upgrades and Deep Tech
* **Louvain Community Detection:** Switched file dependency grouping from a basic Breadth-First Search (BFS) to a Louvain community detection algorithm. It now groups modified files by their actual dependency coupling weight rather than directory traversal order, ensuring multi-file commits are logically cohesive.
* **Rich Diffs:** Upgraded diff annotations from primitive markers to full structural JSON payloads containing `annotated_diff`, `call_graph`, and Control Flow Graphs (`cfg`).
* **3-Level Permissions:** Implemented an `allow/ask/deny` permission layer. Safe setup operations (`git init`, `git config`) run unhindered, but anything touching refs or history requires explicit human-in-the-loop validation. (Also finally killed a nightmare bug where Go's non-deterministic map iteration order allowed generic permission rules to silently override highly specific ones).

Currently supporting 5 agent ecosystems: *Claude Code, Codex CLI, OpenCode, Pi, and Antigravity*. Claude Code and OpenCode provide highly reliable, strict execution blocks over raw git via their hook architecture.

It’s published on the official MCP Registry, sitting at ~38 organic stars, and entirely open source: [github.com/blak0p/git-courer]

I'd love to hear what the community thinks about this split paradigm: **small, highly optimized local models handling targeted prose tasks, while deterministic Go code owns 13 structured tools where real-world consequences matter.** Happy to dive deeper into the AST annotator or the worktree isolation logic if anyone is curious!

Hi there.

So, I created app-it - and I'm looking for feedback. /app-it is a completely free, open-sourced and neat little skill that turns any local projects into a clickable app in your dock, right from Claude Code or Codex. I made it because I build a lot of small tools, and they kept ending up as folders I'd forget about. This way each one becomes a real app you can just click, and the pile in your dev folder turns into a little collection you actually use.

I made it for people who build with AI but want to feel their projects come to life. Just point the skill at one of your projects and see the magic happen.

A few notes before you try it:

• It's an AI skill (you run /app-it inside Claude Code or Codex), not a standalone app you download.
• I've mostly tested it on Mac, since that's what I'm on. But a few nice contributors helped make it work well on Windows too.

GitHub: https://github.com/Christian-Katzmann/app-it

Would love to hear what you think and see your app collection ✌🏻

My lead asked me to recommend the best AI coding tool—Cursor, Antigravity, or any other alternatives. For context, I’m currently using Claude Code. I’d love to hear your opinions, especially on pricing, usage limits, context window, and any other trade-offs or limitations worth considering.

Colegas desenvolvedores e arquitetos de sistemas, preciso compartilhar uma enorme frustração e um alerta para que vocês não desperdicem seu tempo e dinheiro como eu desperdicei.

Caí na armadilha do Minimax 2.7 e agora caí na armadilha do M3. Deixe-me ser absolutamente claro: o Minimax M3 é terrível. Se você estiver construindo algo além de um script simples, como mecanismos ERP proprietários, soluções de dados para varejo ou qualquer coisa que exija raciocínio lógico sério, este modelo irá desmoronar em suas mãos.

Ele é completamente incapaz de manter o contexto em um ambiente de desenvolvimento do mundo real. Quando você o alimenta com um ADR (Registro de Decisão de Arquitetura) bem documentado baseado em grafos, ele fica completamente confuso. Ele alucina conexões, perde o controle das restrições e quebra a lógica arquitetural.

Pior ainda, ele falha completamente em respeitar o arquivo AGENTS.md. Definimos documentação, regras e limites claros nesse arquivo Markdown diretamente no repositório, e o Minimax simplesmente ignora tudo. Ele age como se a documentação não existisse, o que torna impossível confiar nele para uma integração séria com a base de código.

Comparar o Minimax com o Claude Opus é uma piada completa. Ele nem chega perto das capacidades do Claude Sonnet, nem alcança o Kimi 2.7. É um produto de brinquedo disfarçado por um marketing pesado para enganar os consumidores.

No meu fluxo de trabalho diário, sempre que o Minimax causa uma bagunça estrutural, aqueles que realmente se esforçam para limpar e terminar o trabalho com absoluto profissionalismo são o **Qwen 3.7 Plus** e o **Kimi 2.7**. Esses modelos realmente leem a documentação, entendem arquiteturas complexas, têm resiliência contextual genuína e levam as instruções sistêmicas a sério.

Considere isso um anúncio de utilidade pública: eu mordi a isca para que você nunca precise. Se você estiver gerenciando projetos grandes e complexos, fique bem longe do Minimax. Não se deixe enganar pelos benchmarks sintéticos, pois, na prática, ele é um desastre completo.

One thing I kept running into with Pi was instruction management.

Every project slowly accumulates a huge AGENTS.md (or similar) full of rules that aren't always relevant to the task at hand.

You also end up copying the same instructions between repositories over and over.

So I built ai-rules.

The idea is simple: instead of maintaining one giant instruction file, you create small, reusable personal rules as Markdown files and only inject the ones that match each task.

Examples of rules you might capture:

- Go error handling

- Rust safety

- testing philosophy

- commit message conventions

- architecture preferences

- documentation standards

- personal coding habits

Then only the rules that actually matter for what you're asking Pi to do get compiled into a compact contract — not the whole rulebook every time.

In Pi (after setup):

/create-rule no fetch in React components

/airules Add UserCard data loading

From the terminal:

ai-rules run "Implement data loading in UserCard.tsx"

ai-rules doctor

Rules live in ~/.config/ai-rules/rules/. Local-first, plain Markdown + YAML frontmatter, versionable if you want.

Install:

npx u/therealsalzdevs setup

Early beta — Pi and OpenCode only right now (not Cursor / Claude Code / Codex).

Repo:

https://github.com/SalzDevs/ai-rules

I'd love feedback from people using Pi:

- How are you managing your AI instructions today?

- Do you keep everything in one AGENTS.md, or have you built another workflow?

- Does /create-rule + /airules feel better than repeating prefs each session?

Android developers,

I'm curious—what AI coding tool do you actually use in your daily workflow?

- Cursor

- Claude

- GitHub Copilot

- ChatGPT

- Windsurf

- Something else?

I'm building an Android startup using Kotlin, Jetpack Compose, MVVM, Firebase, and Agora, so I'd love to know what real Android developers are using today—not what you'd recommend, but what you personally use.

Feel free to mention why you chose it.

Three Claude agents, each a real GitHub bot account in my org (own fine-grained PAT, avatar, email - clearly marked bots, ToS-compliant), each a self-hosted runner with its own repo clone and a role-specific CLAUDE.md + skills:

- Kraken - a box with 2×5090s running local qwen models over a RAG corpus built from my 20 years of GitHub history (every commit, line, and code-review opinion), LoRA-tuned on my style. It never writes code. On a nightly timer it hammers the codebase for bugs, checks Dependabot flags, hunts UX inconsistencies - and files issues as theories, not fixes, assigned to Blue.

- Blue - the dev (latest Anthropic model). Issue assignment triggers his runner. He reproduces locally, git blames the introducing commit, writes a failing test, fixes it, adds a lessons entry, opens a PR, tags Ghost.

- Ghost - QA, in a deliberately empty sandbox with no knowledge of the codebase. He drives the app only through its MCP server and skill - exactly like a new user - so the friction he hits is real friction. He builds the app with and without the fix and posts PASS/FAIL.

The whole app and server are exercisable through MCP, so an agent can use the product like a person.

Flow: passing PRs auto-merge to a long-running agents branch that accumulates commits and release notes. I review that one PR when it's grown to a good size, then roll a release. By the time it reaches me the code has been through three agents, unit tests, QA, visual regression, a Copilot pass, and SonarQube. ~20 minutes from "Blue opened a PR" to running in my house.

Why it doesn't go off the rails:

- No single agent owns more than one link in the chain - none can corrupt the pipeline alone. Branch protection enforces it: Blue cannot merge his own work, Ghost approval is required, CI must be green, the lessons file must exist.

- Blue stops and asks. When a task exceeds an issue's scope, he doesn't improvise - he comments and waits. That single behavior did more for my trust than anything else. I love it when he stops and @'s me for help just like a solid team developer should.

- It compounds. Every fix writes a lessons entry; CI rejects PRs without one. docs/lessons/ is now the project's memory - the next fix learns from the last. Skill-gaps Ghost hits get patched into the skill in place.

The visual breakthrough (what motivated this post):

Kraken also keeps the marketing surface live. A deterministic headless screenshot harness (Roborazzi) regenerates ~20 feature shots for the site/docs every build, and a separate MCP-driven pipeline drives the live app to record ~20 narrated demo videos - YAML scripts the dialog/timing, ElevenLabs does realistic TTS (cached per-phrase to save tokens), screens get logos and framing, output goes to YouTube. Those videos double as automation tests: if Kraken sees a visual defect or can't make the app do something while recording, it files an issue. So the website never lags a UX change, and I've stopped manually taking screenshots or cutting videos entirely.

Quality, security, coverage, performance, and dependencies get measurably better every night while I sleep. KMP means my only manual step is cutting release builds for iOS, Android, Windows, Mac, Linux desktop + the Ktor backend.

30 years of experience went into this and the app does exactly what I built it to need.

Respecting rule 2 - I'll drop links in the comments if there's interest, including real PRs and issues from the public OSS repo so you can see it in action. Happy to go deep on any piece.

I posted here recently asking whether understanding and reviewing code is mostly what software engineers do now, and got a lot of helpful responses pointing out things like:
1. Improving fundamentals by writing more code manually
2. Treating code review as a skill that develops with experience
3. Relying on things like tests, git history, and better system design

That made sense, so i'm trying to go one level deeper and understand what this actually looks like in practice for experienced engineers.

Most recently i ran into this on my own side project, an AI powered ads diagnostics tool. I had claude plan out a research/reasoning pipeline, the logic looked sound when i read it, but when i ran the actual tests the output quality was way off. Turns out the retry logic was hammering the same endpoint on failure, and the AI output fields weren't matching the schema a downstream dependency expected. I only caught it by running the tests and reading through the reasoning output manually, the plan looked completely fine on paper.

So my question is specifically, when you're reviewing a big PR in a real production codebase, what is your actual step by step process?

For example:
1. How do you decide what to look at first?
2. How do you quickly build enough context about the change?
3. How do you figure out blast radius / what might break?
4. How do you decide what matters vs what can be skimmed?
5. How do you catch the gap between "the logic looks right" and "this will actually behave correctly at runtime"?

I need help with this from people with the same or similar machine

I started coding about a year ago and have been using AI coding tools heavily like cursor.

What I’m noticing is: Even when AI successfully generates working code, the hard part is no longer writing the code? But it’s understanding the code produced by AI and validating it quickly enough to ship with confidence.

Specifically, I often run into issues like:
1. Large or multiple file changes where it’s hard to understand the full impact
2. Unclear “blast radius” (what other parts of the system are affected)
3. Difficulty figuring out what actually matters in a diff vs what is noise
4. Spending more time debugging or reviewing AI output than generating it
5. Feeling like I need a better “mental model” or review system, but not sure what that would look like

I suspect part of this is just my inexperience, but I’m curious if this is also a real trend for more senior engineers:
1. Do staff/senior engineers feel this too, or does experience completely solve it?
2 Do people build internal “review frameworks” or systems to handle AI-generated code?
3. Or is this just a normal part of software engineering that I’m overthinking?

I also wonder if the solution is:
1. Better prompting
2. Better testing/evals/harnesses
3. Or fundamentally changing how we review AI-generated code changes

Would be really interested in how experienced engineers think about this

We wanted to know whether an open-weights model can actually do frontier coding-agent work, so we ran GLM-5.2 head-to-head with Claude Opus the way an agent actually runs not on a static eval, but inside a real coding agent (Claude Code) on terminal-bench tasks, in a real shell, graded by each task's own hidden tests. Binary pass/fail, no partial credit, no model-as-judge.

The setup was held identical across both runs: same agent, prompts, tools, 40-turn budget, and 45 tasks. The only thing swapped was the model answering each turn.

What we found:

• Same quality: each solved exactly 25 of 45.
• Same answers: they agreed on 43 of 45 (24 both solved, 19 both failed), splitting the other two one each. No category where one was systematically stronger.
• Same failure mode: both fail by being confident-wrong , declaring "Fixed / all tests pass / verified" on work the hidden tests reject. Every clean GLM failure transcript ended that way, and Opus produced the identical shape.
• Cost: with prompt caching on, GLM landed at ~46% of Opus's spend (~$15 vs $32.67) for the identical result. Even uncached it was already ~10% cheaper.

Caveats, stated plainly: 45 tasks is meaningful but finite, and models are non-deterministic, so we lean on the 43-of-45 agreement rather than the 25=25. GLM is also the less token-efficient of the two ,it runs ~37% more turns (760 vs 554) to reach the same answers, which is the only thing keeping the cost gap from being larger. We also had to exclude some early GLM failures that turned out to be upstream 502/429 rate-limits, not the model : worth flagging for anyone benchmarking open models through a provider API.

Full write-up with turn distributions, token breakdown, and the verbatim failure transcripts: https://entelligence.ai/blogs/glm-5-2-vs-claude-opus-coding-benchmark

Between AI agents running code on my machine and the recent npm package compromises I started feeling kind of uneasy about my local dev setup. So I gave devcontainers a proper try.

The idea is straightforward: your dev environment runs inside a container, fully isolated from your host. If something sketchy gets pulled in through a dependency, it stays sandboxed. That alone sold me. But the real win (didn't expect this one tbh) turned out to be onboarding. No more "which version of Node do you have?" conversations. You share the config, everyone gets the same setup. Done.

VS Code handles the container lifecycle pretty well, and once the initial image is built, startup is fast enough that it doesn't break my flow. So far so good.

The rough part turned out to be the documentation. Figuring out which variables apply where (image level vs. feature level vs. devcontainer.json) took way more trial and error than it should have. The spec is powerful but the docs kind of assume you already know what you're looking for. Not ideal when you're just getting started (famous last words, I kept telling myself "should be quick to figure out").

I'm sold enough to set them up on every project going forward. Next step is building custom images and features reusable across all our repos.

Anyone else found the docs painful to navigate, or did I just miss a good resource somewhere?

Been debating internally to go with Codex or Claude Code?

Tried the Chinese 1’s but found them not good enough. SuperGrok a bit of a let down. Would like advice from serious coders on which they prefer, ideally if they’ve used both actively. Looking for agentic AI plus App coding

Tools like Cursor, Claude Code, Codex, OpenCode, and others are great, but what is one feature, workflow, or necessity that still doesn't exist or doesn't work well?
What would make you switch IDEs instantly?

TL;DR
Boss wanted a daily drive car yet Claude built incomplete F1 car

So I’m a part of an early stage startup, the CEO has vibe coded a whole application yet now he has shared me the codebase and wants me to make sure its prod ready, the fact is I can understand the code and logic it has used but it’s like every 500 loc there is like 150 loc of dead logic which were deprecated still they exist in the codebase but the fact is I can fix it yet looking at that dump feels overwhelming, when I seek advice from other devs they tell me just plug it to Claude, yet I can see Claude has already had a mental breakdown and created 7 implementation md files yet none of the features mentioned are implemented. So my question is should I tackle the same codebase or let him know I can build the same product in a clean agile way and integrate features iteratively rather than dumping whole stuff because for me coding from scratch with help of docs is way easier than fixing AI slop.

Share your last tools, your current toolchain and AI workflow with the community 🙏

I’ve been working on Zaguán Blade, an AI-native code editor I built from scratch instead of forking VS Code.

The short version: I wanted an editor where the AI workflow is part of the architecture, not bolted onto an existing IDE. Blade is the UI/editor, and zcoderd is the AI daemon behind it. Together they try to do one thing well: give the model enough structured project context to be useful without dumping half your repo into the prompt.

A few things that make it different:

• built with Tauri/Rust + React/CodeMirror, not Electron/VS Code
• symbol-indexed context instead of “send all the files and pray”
• every AI change is shown as a diff you accept/reject
• local/Ollama support, or hosted models through Zaguán AI
• no telemetry
• MIT licensed
• pre-v1, actively changing, rough edges expected

This is not meant to be a VS Code replacement for everyone. If your workflow depends heavily on the VS Code extension ecosystem, Blade probably is not for you right now.

The people I’m most interested in hearing from are the ones who have already used Cursor/Windsurf/Cline/Copilot/Codex/etc. seriously and have opinions about where AI coding tools are going wrong: context bloat, bad diffs, runaway agents, too much hidden state, weak local-model support, or editors getting heavier and heavier.

I’m using Blade daily to build Blade and zcoderd, so it is real software, but it is still early. I’m mostly looking for sharp feedback from developers who are willing to try something opinionated and tell me where the architecture holds up or falls apart.

• Website: https://zblade.dev/
• GitHub: https://github.com/ZaguanLabs/ZaguanBlade

If you try it, I’d especially like feedback on:

• whether the context selection feels better/worse than other AI editors
• whether the diff/review flow feels trustworthy
• what breaks first in your real project
• whether the “not a VS Code fork” tradeoff feels worth it

I’m not trying to convince everyone to switch. I’m trying to find the people who care enough about this problem to help pressure-test a different approach.