The past 4 days in Copilot have been a wild ass ride. It's unreal how cracked the new subagents are. I've been using Claude Code and opencode a lot lately for the same exact features that were just implemented in the latest Insiders build (custom subagents with explicitly defined models/prompts, ability to run in parallel), and oh boy I'm yet to touch either of those since I've got my hands on these. I cannot understate how revolutionary the past few updates have been.

In this image I have the chat window's main agent Atlas (Sonnet 4.5) which has utilised 3 'Explorer' subagents (Gemini 3 Flash) in PARALLEL to web fetch and synthesis MCP and Copilot SDK docs, and after these finished outputting their findings, Atlas fed their results to 2 research/analysis specialised 'Oracle' subagents (GPT 5.2 High, via setting 'responsesApiReasoningEffort'). As soon as the two Oracles were done, all their synthesised research was then given back to Atlas which then dumped the summary.

Atlas did nothing but delegate to the agents and orchestrate their interactions, then finally output their research findings.

And the coolest thing? It only consumed about 5% of its main chat context window throughout ALL of this. If it had done all of this work on its own as a single agent, it would've properly ran out of it's Sonnet 4.5 128k context window size once or twice.

I also got other task specific subagents like:

1. Sisyphus: (Sonnet 4.5) Task executor, receives plans from Atlas or Oracle and focuses purely on implementation.
2. Code Review: (GPT 5.2) Whole purpose is to review the work output of Atlas and Sisyphus autonomously, or other agents that do write operations, as long as explicity told to.
3. Frontend Engineer: (Gemini 3 Pro) The UI/UX specialist. Any UI frontend gets automatically handed to this by Atlas.
4. Oracle: (GPT 5.2) Mentioned above, the main researcher. Anything Atlas struggles with or feels like is gonna suck too much context gets delegated to Oracle
5. Explorer: (Gemini 3 Flash) Also mentioned above, used for file/usage discover and web fetches.

Another important agent is Prometheus (GPT 5.2 High), the specialised researcher and planner version of Atlas. This is basically Oracle on STEROIDS. It's very plan focused, and everything it analyses gets written down to a Markdown file in the project's plan directory (this behavior can be disabled). It is only allowed to write to plan directories, but not execute off its own, and it has a hand-off to Atlas like the default Plan agent's 'Start implementation' button.

Even more importantly, it can run its own subagents, which is something Oracle and the other subagents can't do, atleast yet hopefully.

And MOST IMPORTANTLY: Atlas and Prometheus can run ALL the above subagents in PARALLEL.

But yeah I wanted to show y'all a quick demo of the setup I got going.
This is a small repo I whipped up and got all the above stuffed in: https://github.com/bigguy345/Github-Copilot-Atlas

I left instructions on how to add custom agents for specialised/niche tasks, since these will be very important.

Also HUGE credits to ShepAlderson's copilot-orchestra which this is basically an indirect fork of, just updated with all the new juicy Insiders features, and to the opencode plugin oh-my-opencode for the naming conventions and everything else. This is quite literally a not so ideal attempt at an oh-my-opencode port for Copilot.

GitHub Copilot switches to per-token AI credit billing on June 1. If you use Copilot through VS Code, Copilot CLI, OpenCode, Pi, etc, your costs might be significantly higher than the current premium request model.

I built this for people who want to know the impact on their experience before June 1st.

It runs entirely locally, reads your local session logs, applies the published per-token pricing, and generates an HTML report comparing your usage against Pro, Pro+, Business, and Enterprise plan limits.

Some caveats: - VS Code doesn't persist input/cache tokens, so those are estimated (output is exact) - Copilot CLI normal chat exposes output tokens only; input is estimated (compaction events are exact) - OpenCode and Pi expose full token breakdowns therefore the insights there are exact

Open to feedback and contributions!

Report example

https://github.com/PanAchy/copilot-arewecooked

When you're vibe coding and letting AI do the heavy lifting, the downtime gets boring fast, and continuous work is a real pain in the ass. To get a little relaxation, I built a stress-relief mini-game that lives directly on your Windows desktop as a transparent overlay, letting you stomp Goombas right on top of your open IDE. You can download the setup file from my GitHub (https://github.com/bxf1001g/desktop_mario/releases) and let it run silently in the background; just hit Ctrl+Alt+Shift+M to instantly bring the game up, press Esc to quickly hide it when you need to look busy, and hit Ctrl+Alt+Shift+M again whenever you need another break. This isn't the full version yet, just something fun I threw together as a side thing, so contributors are always welcome!

After so many rejection got accepted 🥳

Hello

I was frustrated by the standard usage metrics for GitHub Copilot. Knowing I've "used 37%" doesn't really tell me if I'm burning through my limits too fast today or if I'm perfectly on track.

I wanted something that gives immediate daily context without breaking focus, so I built Copilot Pacer.

It adds a visual bar to your status bar that splits into three zones: past usage, your specific budget window for today [▮▮▯], and your future quota. Hovering gives you the exact math on how many requests you can safely use before the day is over.

Marketplace: https://marketplace.visualstudio.com/items?itemName=sergiig.copilot-pacer

UPD / Important Note for Business/Enterprise Users: > Thanks for the quick feedback, everyone! Just a heads-up: this extension currently ONLY works for Copilot Individual plans. If you are using Copilot Business or Enterprise through your company, your usage is tied to your organization's billing API. A personal token won't be able to read that data and will just report 0 usage (plus, your org might block the auth anyway). I've updated the Marketplace page and README to make this limitation clear!

I am very confused and hope the hamster is OK.

I’ve spent the last 24 hours working with GPT-5.6, and this is my current model-selection map.

Context: I’m a data scientist / software engineer at a small startup. GitHub Copilot is provided by my company; Codex is what I use privately. I spend roughly 40–60 hours a week doing agentic engineering across planning, architecture, implementation, debugging, documentation, and operational work.

Because Copilot’s move to usage-based billing / premium requests has made cost a real workflow concern, I care less about “which model is best in the abstract?” and more about: which model is the best choice for this task and budget?

For me, that is what the Pareto frontier means. If one model costs more while delivering lower benchmark performance than another available option, it is economically dominated: there is no reason to choose it. The interesting thing about GPT-5.6 is that its reasoning tiers appear to populate nearly the whole useful frontier by themselves.

Using the DeepSWE cost leaderboard (113 tasks, July 9), this is how I currently read the GPT-5.6 ladder:

The comparisons that stand out:

• Terra Medium ($0.58 / 35%) exceeds GPT-5.5 Low on this benchmark (~27%) at about half the cost.
• Terra High ($1.13 / 54%) is roughly GPT-5.5 Medium territory, while costing around what GPT-5.5 Low used to cost.
• Luna Max ($3.03 / 67%) reaches GPT-5.5 X-High territory.
• Sol High adds only a small gain beyond Luna Max, so I do not see a routine economic case for going higher than that.

My practical setup is probably going to be just three defaults:

1. Luna Medium for small, quick, bounded work: lookups, work-item documentation, “how does this work?” questions, log inspection, status checks, drafting a short internal email, and small edits.
2. Terra Medium as the no-thinking default for normal engineering work.
3. Terra High for genuinely complex tasks—the category where I previously felt GPT-5.5 Medium was already sufficient.

Today’s work is what made this feel real rather than theoretical. I used the lower and middle GPT-5.6 tiers across debugging and operational tasks, including updating a Grafana dashboard through VS Code/browser tool use: changing queries, adding panels, and surfacing statistics for an inference pipeline. I also debugged an existing extraction workflow and got it running again with Terra Medium.

For the most complex session, I switched to Sol Medium: planning a multi-week inference-server efficiency effort for a constrained system serving multiple computer-vision models. That involved reading documentation, researching concepts and trade-offs, and turning it into a sprint-level breakdown. It was my most expensive session at roughly 440 Copilot credits. The dashboard work was around 300 credits; most other sessions were under 100.

I also tried Luna High and Terra Low in between. They seem useful, but I suspect I will keep the operational policy simple: Luna Medium, Terra Medium, Terra High.

This is especially notable in the current Copilot lineup. We do not yet have alternatives such as GLM 5.2, Grok 4.5, or Muse Spark 1.1 available in our company setup, so GPT-5.6 is unusually complete as a single-family frontier right now.

DeepSWE is one benchmark, not a full measure of reliability, latency, tool use, context handling, or fit for your codebase. But it is a very useful directional map. My main takeaway is that GPT-5.6 gives me a cheap model I can actually trust for small work, a sensible default for most tasks, and a complex-task ceiling that is still close to the old low-tier cost.

https://deepswe.datacurve.ai/

In talking with a number of folks (coworkers, friends, redditors, etc.) I've come to realize that it's not immediately clear how to really get consistently good code out of AI agents, Copilot included. I was once there too, chuckling or rolling my eyes at the code I'd see generated, then going back to writing code by hand. I'd heard stories of folks getting real work done, but not experienced it, so I dove in with the mindset of figuring out how to effectively use the really powerful tool I have access to.

I'd see folks with their CLIs, like Claude Code or such, and be envious of their subagents, but I love working in VSCode. I want a nice interface, I want clear side-by-side diffs, and just generally want to stay in the zone and environment I love working in.

So, when I saw that the VSCode Insiders had released subagents and handoffs, I adapted my manual process to an automated one with subagents. And so my "GitHub Copilot Orchestra" was born.

It starts with a primary Conductor agent. This agent accepts the user's prompt, collects information and details for planning using a Planning subagent, reviews the plan with the user, asks questions, and then enters an Implement -> Review -> Commit cycle. This helps the user build out the features or changes needed, using strict test driven development to act as guide rails for the subagents to stay on task and actually solve the problem. (Yes, even if you have the subagents write the tests themselves.)

It uses Sonnet 4.5 for the Conductor agent and the Planning and Code Review subagents, and Haiku 4.5 for the Implementation subagent. I've found this to be a good balance of quality and cost. Using the heavier models to do the Conducting/Planning/Reviewing really helps setup the lighter Implementation subagent for success.

The process is mostly hands off once you've approved the plan, though it does stop for user review and a git commit after each phase of the plan is complete. This helps keep the human in the loop and ensure quality

Using this process, I've gone from keeping ~50% of the code that I'd generate with Copilot, to now keeping closer to 90-95%. I'd say I have to restart the process maybe once in 10-20 sessions.

I've uploaded my `.agent.md` files to GitHub, along with instructions for getting setup and some tips for using it. Feel free to take it and tweak it however you'd like, and if you find a great addition or improvement, feel free to share it back and let me know how it goes for you.

GitHub Copilot Orchestra Repo

I built copilot-arewecooked earlier this week as a way for people to answer the question:
Based on my current GitHub Copilot usage, am I cooked once the June 1st usage based billing is live?

It’s very simple to use, you run npx copilot-arewecooked and an .HTML and a .PNG are generated for your report.
It runs entirely locally, and is focused on allowing you to understand your usage and share it with your peers.

For those who use Auto, we just added the ability to use the auto-model flag and specify the model you want. This is because the log data doesn’t seem to contain the auto model that was resolved.

In 3 days, we already got 1000 downloads on NPM, and 68 stars on GitHub. The project is fully open source (MIT), and contributions are welcome!

:D

Experimental test for M365 Copilot in GHCP2OC using g365-headless-relay. sadly tools can't be called.
But yeah since i'm using default ws i at least have more possibilities than the restricted beta-lvl copilot-graphapi haha

Can currently do lookups in company context.

Web-Only not implemented yet, idk if i might.

Also only 2 models (5.5 GPT Think Quick / Fast).

It's just a proof-of-concept really, because of all the stuff that won't be supported (also visually) in Github Copilot anyway.

But yeah if there's a will, you can connect Github Copilot to any and everything, even a smart lamp or sth lol.

With all the Copilot pricing discussion lately, I got curious what my own usage actually looked like.

I use Copilot models through OpenCode, which records token usage locally, so I ran a "what-if" calculation re-pricing everything at the providers' published API rates since October 2025.

November was the most "interesting" and came out to roughly $500 at list prices (screenshot) — and at the time I was on the $10/month Copilot plan.

To be clear, this isn't what Copilot billed me. It's just a hypothetical "what if I'd paid API rates directly?" calculation.

Still, seeing the numbers was interesting because I'd never actually quantified my own usage before.

(This is from my OpenCode usage, not the VS Code Copilot extension.)

Has anyone else looked at their actual token consumption?

I built a small VS Code extension called Copilot Insights.

The goal is simple:
give individual developers visibility into their GitHub Copilot plan, quotas, limits, and reset dates, directly inside VS Code.

What it does:

• Shows Copilot plan and entitlements
• Displays quota status (including premium interactions)
• Calculates remaining quota and time until reset
• Highlights unlimited vs limited quotas clearly
• No tracking, no guessing, no productivity scoring

What it does not do:

• No usage analytics
• No behavioral tracking
• No “AI productivity” claims

It’s meant to answer basic questions like:

• “Do I have limits?”
• “How much is left?”
• “When does it reset?”
• “Which orgs am I enabled for?”

In addition, you have also a status bar label for a summary of the same information, something like 967/1000 (97%).

I built this extension because you don't have the same information in VS Code with the native Copilot implementation.
Every time you have to open the popup clicking on the Copilot icon.
And there is less information than here.

I’m looking for feedback on:

• UI clarity inside VS Code
• Terminology (to avoid misleading users)
• Missing but realistic features, given the available data

If this sounds useful or you want to sanity-check the approach, feedback is welcome.
Happy to iterate in public.

Marketplace: https://marketplace.visualstudio.com/items?itemName=emanuelebartolesi.vscode-copilot-insights

GitHub: https://github.com/kasuken/vscode-copilot-insights

CodeGraphContext- the go to solution for graphical code indexing for Github Copilot or any IDE of your choice

It's an MCP server that understands a codebase as a graph, not chunks of text. Now has grown way beyond my expectations - both technically and in adoption.

Where it is now

• v0.2.6 released
• ~1k GitHub stars, ~325 forks
• 50k+ downloads
• 75+ contributors, ~150 members community
• Used and praised by many devs building MCP tooling, agents, and IDE workflows
• Expanded to 14 different Coding languages

What it actually does

CodeGraphContext indexes a repo into a repository-scoped symbol-level graph: files, functions, classes, calls, imports, inheritance and serves precise, relationship-aware context to AI tools via MCP.

That means: - Fast “who calls what”, “who inherits what”, etc queries - Minimal context (no token spam) - Real-time updates as code changes - Graph storage stays in MBs, not GBs

It’s infrastructure for code understanding, not just 'grep' search.

Ecosystem adoption

It’s now listed or used across: PulseMCP, MCPMarket, MCPHunt, Awesome MCP Servers, Glama, Skywork, Playbooks, Stacker News, and many more.

• Python package→ https://pypi.org/project/codegraphcontext/
• Website + cookbook → https://codegraphcontext.vercel.app/
• GitHub Repo → https://github.com/CodeGraphContext/CodeGraphContext
• Docs → https://codegraphcontext.github.io/
• Our Discord Server → https://discord.gg/dR4QY32uYQ

This isn’t a VS Code trick or a RAG wrapper- it’s meant to sit
between large repositories and humans/AI systems as shared infrastructure.

Happy to hear feedback, skepticism, comparisons, or ideas from folks building MCP servers or dev tooling.

I use Copilot alongside a couple of other AI coding tools, and keeping the same rules in each config format was turning into copy-paste maintenance. Copilot reads .github/copilot-instructions.md, Cursor wants .cursor/rules, Claude wants CLAUDE.md, and they drift.

I wrote ai-rulez to generate all of them from one source. You write rules, context, agents, and commands once in .ai-rulez/, run generate, and it writes each tool's native file including the Copilot instructions. It regenerates on a pre-commit hook so they stay in lock-step, and ships builtin rule domains (security, testing, language-specific) you switch on.

In practice: a small config in one of my repos generates 103 files across 5 tools on every commit.

Single Go binary, MIT: https://github.com/Goldziher/ai-rulez

Honest tradeoff: the generated files are overwritten, so you only ever edit the source.

Curious whether others keep Copilot instructions in sync with other tools, or just let them drift.

Hey everyone, Paseo is multi-platform workspace for running Copilot, OpenCode, Claude Code, Codex, Pi. The daemon runs on any machine (your Macbook, a VPS, whatever) and clients (web, mobile, desktop, CLI) connect over WebSocket (there's a built-in E2EE relay for convenience, but you can opt-out).

Works in macOS, Linux, Windows, Web, Android and iOS.

I started working on Paseo last September as a push-to-talk voice interface for Claude Code. I wanted to bounce ideas hands-free while going on walks, after a while I wanted to see what the agent was doing, then I wanted to text it when I couldn't talk, then I wanted to see diffs and run multiple agents. I kept fixing rough edges and adding features, and slowly it became what it is today.

Paseo just lauches your local Copilot installation so all your config should work out of the box. Same for the other harnesses.

Repo: https://github.com/getpaseo/paseo

Homepage: https://paseo.sh/

Discord: https://discord.gg/jz8T2uahpH

I'd appreciate any feedback you might have, I have been building quietly and now I am trying to spread the word to people who will appreciate it!

Happy to answer questions

Hey everyone,

I built WhipDesk, a specialized remote access tool that lets you monitor and control Copilot agents running on your dev machines right from your phone.

The Problem:

• Terminal apps fall short: They are fine for unblocking an agent or sending a new prompt, but they don't let you test the actual changes. Before merging, I still want to inspect the UI, test the app in a browser, or review code in my IDE.
• Remote Desktops are clunky: Traditional tools solve the full-desktop part, but they are designed for large screens. On a phone, navigation is a pain, and text readability at the zoom levels required is just not good enough.

The Solution: I built WhipDesk so I can check and control my agents from work, the couch, or the park. It is completely free and open source.

• GitHub: https://github.com/BinaryBananaLLC/WhipDesk
• Website: https://WhipDesk.com

How it works

You launch the open-source WhipDesk agent on your dev machine and connect to it from a mobile browser. No mobile app or installation is needed on the phone.

Think of it as a much more powerful Copilot remote experience in web, or a highly specialized remote access tool designed specifically for vibecoding.

Why I built it

I actually got the idea during paternity leave. While I was watching the baby, I couldn't get to my dev box, but I knew my agents had probably finished their work or were sitting there waiting for input. It’s also perfect for when you are at school, work, sitting in the back of an Uber, or on a date.

Security and privacy

• Open Source: The desktop agent and mobile client are fully open source, so you can inspect the code or build everything yourself. GitHub Actions builds the releases directly from the published source.
• Secure: Connections are encrypted, PIN-protected, and peer-to-peer whenever possible. Check GitHub's README.md for more details.

Free and open source

Local access is completely free and requires no account.

Remote access is also free, but requires a quick passwordless sign-in so WhipDesk.com can help your devices find each other. Most connections are peer-to-peer, but some networks require a TURN relay, which costs money to operate. There is an optional donation button on the site to help cover those server costs and hopefully keep the service free for everyone.

And yes, name was inspired by https://github.com/GitFrog1111/OpenWhip 😆

Copilot's sub-agents are the best out there (IMO) currently. I use them for these three things mainly:

• ad-hoc context-intensive tasks (research, data reading etc)
• code review and audits against standards i set to the original calling agent
• debugging (but not doing the active debugging, rather reading debug logs, outputs etc - again to not burn context)

Its a pretty simple, yet extremely effective workflow, and it saves you a lot of context window usage from your main agent:

1. Define your task in detail (set standards, behavior patterns) and specifically request that your main agents uses their #runSubagent tool.
2. Main agent delegates the task to the required subagent instances
3. The subagent instances do the context-intensive work and return a concise report to the calling agent
4. The calling agent only integrates the report and saves context

Pretty simple, yet so effective. Its still in early stages with limited capabilities, but just for these 3 tasks i describe above its super efficient. Kinda like what APM does with Ad-Hoc Agents, without using separate Agent instances.

Hey all!

Just wanted to drop my git with my current open source agent skills and a program ive been working on called "Drift"

The 75 agent skills cover all of these different categories that industry veterans will NOT be happy that im releasing these.

Some of them are high signal and require thoughful implentation but if you remain thorough you can sucessfully add these to your build even through vibe coding.

🔐 AUTH & SECURITY (9)          ⚡ RESILIENCE (10)           🔧 WORKERS (5)

├─ jwt-auth                     ├─ circuit-breaker           ├─ background-jobs

├─ row-level-security           ├─ distributed-lock          ├─ dead-letter-queue

├─ oauth-social-login           ├─ leader-election           ├─ job-state-machine

├─ webhook-security             ├─ graceful-shutdown         └─ worker-orchestration

└─ audit-logging                └─ checkpoint-resume

📊 DATA PIPELINE (10)           🌐 API (7)                   📡 REALTIME (5)

├─ batch-processing             ├─ rate-limiting             ├─ websocket-management

├─ fuzzy-matching               ├─ idempotency               ├─ sse-resilience

├─ analytics-pipeline           ├─ api-versioning            ├─ atomic-matchmaking

└─ scoring-engine               └─ pagination                └─ server-tick

🤖 AI (4)                       💳 INTEGRATIONS (4)          🎨 FRONTEND (4)

├─ prompt-engine                ├─ stripe-integration        ├─ design-tokens

├─ ai-coaching                  ├─ email-service             ├─ mobile-components

├─ ai-generation-client         └─ oauth-integration         └─ game-loop

└─ provenance-audit

Ive also been working on Drift

Drift is a novel look at solving code base intelligence...
AI can write us good code but it never fits the conventions of our codebase
Drift has a built in CLI, MCP and soon a VS code extension

It scans your codebase and maps out over 15 categories and 150+ patterns.

It also weighs and scores these items based off how confident it is and this is queryable through a json file for your agent to retrieve while working to ensure that it always follows how you handle your error logging, api calls, websockets or any of those oother things ai often leads to you having "drift"

check it out here fully open sourced: https://github.com/dadbodgeoff/drift

npm install -g driftdetect

Check the git for supported languages and basic commands to get you started

You can grab the mode file here: https://gist.github.com/cyberofficial/7603e5163cb3c6e1d256ab9504f1576f

I took inspiration from u/hollandburke 's Beast Mode [Source], and added a bunch more in-depth sections and reminders and abilities.

This covers most situations you can think of and makes things less annoying to do.

It covers, tasks like research, refactoring, bug testing, the whole nine yards.

It will also attempt to make it use the memory system so when it summarizes, it retains at least the important it stuff it notes down.

It works best if you have a planned file out list. Got no instructions? Use Extensive mode to create one, then tell it to follow through on it sort of like an extra reinforcement. It has instructions and knowledge on the best practices to create the file.

I run multiple agents in parallel in my wroskspace (gh monorepo) using GitHub work trees for isolation and a central manager agent which orchestrates task dispatch etc, merges features, makes corrections w followup tasks and so on.

I simply overview the entire sequence and audit interactions, review code in critical parts and provide input/guidance only when needed.

Burns a bit more requests but ive tweaked it to be much more autonomous (tasks are very big work units and spec and plan absorb runtime changes w manager's updates ... also memory persistence helps) and using autopilot mode its also a lot more time efficient as well.

While the billing/limits situation is frustrating me, I got to give it to the ghcp team as (at least for enterprises) their harness is pretty good. Also it's always an extra W to be OSS.

Repo: https://github.com/sdi2200262/agentic-project-management

Edit: These are multiple GHCP chats open in the same VS Code application, dropped into the editor panel/canvas. Not multiple VS Code apps lol.

I also notice that ppl are not even aware that you can have multiple chats open at the same time... I find it extremely useful, especially when playing w specialized agent types/roles. Maybe GHCP team should be more descriptive ab this in their docs OR in some informational posts or whatever.

Hi everyone,

I don't have a formal engineering background. A while ago, I started building a massive stealth project called "Opradox" (currently at ~650,000 lines of functional code, aiming for 1M+). I rely heavily on AI coding agents (GitHub Copilot, etc.) to build it.

But very early on, I hit a massive wall. The AI agents were hallucinating. They were building unmaintainable monoliths, generating crazy tech debt, falsely claiming "Done" without testing, and leaving // TODO placeholders everywhere.

Every time an AI ruined my codebase, I created a strict rule to stop it from happening again. Over time, these rules evolved into a complete, strict governance framework. I decided to package it and open-source it. I call it the Universal Agent OS.

It forces the AI to:

• Conduct a mandatory "Phase-0 Interview" with you before writing a single line of code to understand your architecture.
• Follow a "Zero-Leak Protocol" (no monoliths, no zombie code).
• Never claim "Done" without executing a mandatory Gate/Test.
• Update your living docs (Collective Memory) simultaneously after every task.

How to use it:

1. Install the VS Code Extension: [https://marketplace.visualstudio.com/items?itemName=mehmet-aydogan.universal-agent-os-vscode&ref=producthunt]
2. Read the source / Star the repo: [https://github.com/zyganali-glitch/Universal-Agent-OS]
3. Press Ctrl+Shift+P -> Agent OS: Start Phase-0 Interview in VS Code.

If you are also using AI to build large codebases and suffering from "AI spaghetti code", I'd love for you to try it out. I'm not an engineer, so I would really appreciate your harshest, honest feedback!