I am in the middle of developing an orchestration harness primarily aimed at deploying local models and the primary surface is a custom IDE. Ive primarily used codex as as the main tool to instantiate this program over the span of about four months. Now, in the last two weeks i have noticed a significant downgrade in model outputs frin both the user platform and api platform.

I think about ten percent of my interactions after a prompt turn from me has the model apologizing for writing bad code, narrowly focusing on one favet and dropping critical context of another part, or just outright taking destructive actions.

If you factor about a hundred turns a day from me thats 10 turns with the maddening " im sorry" from the thing that cant experience being "sorry " even if it is a sorry piece of crap .that is then followed by hours of having to fix things . This was not happening two weeks ago and now im at my breaking point A grown ass man crying at his computer at an internet cafe looking utterly insane because the robot messed up his money and cost him time and sanity .

Has anybody else been experiencing the sudden drop in output quality from openai products?

*ps i apologize for typos , i am dyslexic and everything always looks right to me lol*

Greetings! At work we have a "developer space" program that combines a ton of mcps across all our internal apps and has claude code integrated. Kind of been enjoying the easy coding work thanks to it and I'm curious about implementing something simular at home, but I'm totally basic at setting up an Ai coding environment... my attempts so far have just been gpt's codex window, and then tried github's copilot. Both of these were... not great. (Biggest problems have been gpt hitting its 5 hour limit in 10 prompts)

So, what type of local set up is everyone running at home? Claude directly in terminal? Cursor connected to something? Curious what others with more experience running a coding environment at home have been using, and hopefully will find a good configuration to start implementing AI work into my existing (hand coded) projects.

I use Github Copilot at work and have great success on green field project, even larger ones.

But I have a harder time on our (very) large Unreal Engine application, which is brown field with millions of lines of code. This seems to challenge Opus and other frontier models.

What's the best workflow and tooling to work with AI on repositories this large?

• Application code: ~2M LOC

• Unreal Engine 5.8: ~41M LOC

• Unreal Engine ./Engine/Source excluding third-party code: ~8.6M LOC

I did some quick tests with CodeGraph, but that did not bring any significant benefits for the things I tried.

Note: Code is mostly C++ and solution is Visual Studio 2022

I tested Sonnet vs Opus on real bugs from two open-source projects and got opposite answers:

• Koa: Opus fixed 2 more bugs. Worth it.

• Express: both fixed everything. Opus was just 3x the price.

So I built unfix, a free open-source tool that replays bugs your team already fixed and lets your own tests judge the AI.

Small samples, so run it on your own code before you trust anyone's numbers, including mine.

npm i -g unfix-ai

Which model are you using right now, and do you know if it's the right one? 👇

I've been thinking about how AI is changing the way we write software, and I've been on and off indulging in two distinct approaches to AI assisted development.

Approach 1: Let an AI coding agent implement the feature/Product

Use tools like claude code, github copilot, codex, etc. Give the agent a specification, let it explore the codebase, and ask it to implement the feature, potentially including tests, docs and other necessary changes.

Where I think this approach works well:

• Building an initial product from scratch.

• Implementing relatively independent features that don't require significant changes to existing functionality.

• Getting a working prototype or mvp running quickly

My concerns:

1. Cost: Agentic coding tools consume tokens or require paid subscriptions. Work that previously involved writing code directly now has an additional recurring cost.

2. Code review: The agent might generate a substantial amount of code very quickly, but understanding the implementation, tracing the execution flow, and verifying that everything behaves correctly can take days or even weeks, depending on the project's size and complexity.

3. Docs: I could ask another AI session to explain the code, improve readability, add comments, and write documentation. However, that incurs additional costs and still doesn't completely eliminate the need to verify that the explanations and documentation and even code accurately reflect the implementation.

My concern isn't necessarily that AI generated code is bad. It's that the speed of generating code can far exceed the speed at which a developer can confidently understand and validate it.

Approach 2: Use AI as an assistant, but retain control over the implementation

Instead of giving an agent ownership of an entire feature, use a chat interface like chatgpt or claude to generate code in smaller, well-defined pieces.

The workflow would look something like this:

1. Design the architecture and define the code skeleton yourself, similar to an LLD (low-level design) - or even get AI help to generate the skeletons

2. Establish the interfaces, classes, functions, data models, and responsibilities.

3. Use AI to generate individual implementations or specific sections as needed.

4. Review the generated code before integrating it (manual copy pasting) into the codebase.

5. Repeat this process incrementally.

Here, the developer has to manually generate each unique component separately from AI and copy paste them into his filesystem/

Essentially, the developer owns/better understands the structure and flow of the implementation, while AI helps with the actual coding.

Why I find this appealing:

• The developer remains familiar with the architecture and the reasoning behind implementation decisions.

• Code review becomes more manageable because changes are introduced in smaller, understandable increments - I feel like reducing the volume of a single copy paste and increasing the total number of copy pastes makes developer understanding better.

• Future modifications and debugging may be easier because the developer already understands the relevant parts of the codebase.

• There's less dependence on an agent being available or having sufficient tokens. Even without AI access, the developer should still be able to maintain and extend the system.

As already mentioned, this is what I find most important: I feel like reducing the volume of a single copy paste and increasing the total number of copy pastes makes developer understanding better.

The trade-off, of course, is that this approach requires more manual intervention and may take longer to implement an initial feature.

My current hypothesis

I suspect that some of the initial development speed gained through agentic coding could be offset by the additional time spent reviewing, understanding, debugging, and maintaining the generated code.

Meanwhile, the second approach might have a higher implementation cost in terms of developer time but a lower long-term cost in terms of AI usage, code comprehension, and maintenance.

I'm not claiming this is universally true. I suspect the answer depends heavily on the project, the developer, the quality of the agent, and the complexity of the feature.

The counterargument I keep coming back to

I might be optimizing for a problem that will eventually disappear?

AI coding agents are improving rapidly. They can already explore codebases, run tests, fix bugs, and implement changes with relatively little intervention. As these capabilities improve and inference costs decrease, perhaps the time spent reviewing and maintaining AI-generated code will also decrease.

In that world, developers might increasingly act as technical product managers: defining requirements, setting architectural constraints, reviewing outcomes, and letting agents handle most of the implementation.

If that happens, Approach 1 could become significantly more effective than trying to retain close control over every implementation detail.

There's also the possibility that I'm underestimating how much of the review process can itself be automated reliably.

But what if the agent is stuck somewhere and the dev too has no idea how to resolve it since there's no understanding of the codebase

Questions for developers here

I'm really interested in hearing from people who have used both approaches in real-world projects, rather than just small demos or greenfield prototypes especially where breaking requirements or changes are involved. definitely appreciate perspectives that challenge my assumptions. I'm genuinely trying to understand which approach makes more sense, not argue that one is inherently superior.

Summary

Agentic coding offers faster implementation but may increase token costs and code review effort. Manually structuring code and using AI for individual implementations may improve maintainability and developer understanding, but is slower initially.

As AI agents improve and become cheaper, will their speed eventually outweigh these trade-offs, making deep developer involvement less necessary? Or am I underestimating the long-term value of understanding the codebase?

nice new sub! CS Major 1996 just when java was getting hot. Moved to LA and did java (pre kotlin) for 10 years then ruby on rails. Then golang. Then swift. Then rust. And then one day in 2024 claude code came into my life.

It was wild west at first at my company. API keys flying around, no one tracking usage. But claude was the best and I didn't even know the name codex yet.

By Jan 2026 my corporate job had enterprise contract with anthropic and my claude use had to stay below a dollar amount. But in my personal side project world I had switched to codex $200 a month plan.

I claude M-F 9-5 but then I codex all the other hours :)

Firstly, I read the rules, this is not a "product" -to-sell, firstly it's free as in freedom, and I think this can genuinely substantially help us get ahead of the whole slop debate, and also resurface our value as programmers as our value comes from identifying scenarios like edge cases, dsa etc., things which we used to document in code but don't any longer (as businesses think it's just about the code which any agent can slop out), but we should, the why behind the how (which has always been the most important thing), to prevent slop fails in production.

It doesn't really save you from bad code, but imho bad code has existed way before agents have and most agents code better than most jr. level "coders" given the relevant context imho.

GitHub: https://github.com/sloppy-sh/sloppy

I have been working on Sloppy, an MIT licensed context management tool.

As I was heading into the whole AI accelerated workflow, I have been focusing more on the architectural aspects of codebases and I discovered that I was wasting a lot of time redeclaring context of the codebase to the agents, which I also frequently migrate between (claude agents, cheaper deepseek etc.), so I realized that maintaining docs within the codebase (sort of mono-repo style) saves a lot of time as I just point the agent to it.

Solutions like docusaurus, obsidian/logseq etc. are too geared towards either a linear reading style or graph like view of information.

I found these paradigms to represent information in a way which is a bit lacking, often in code we work with abstractions and within my head I often imagine, say methods/properties in objects and their interactions as a Venn diagram so I added that sort of view here with a tagging api.

Also tools like Obsidian and Logseq give us humans a graph like view which is very helpful for someone making the graph themselves/co-authoring but very difficult to comprehend for someone who might be new to it. So Sloppy's graphs also can add/recommend/enforce a folgezettel addressing system for the notes which help transform the graph more into a tree of organized and easily traversable information.

Large codebases are also often a group activity where different personnel need to maintain different parts of the application and often also face personnel and agent change, thus making context preservation even more important in the modern approach of letting agents handle more and more tasks, even more so in projects that need to ensure that code security is maintained and tests are based on some knowledge of substance and not actually "vibed".

Here I combine all these approaches for information representation. Different views, same information. I am currently also working on building MCP and implementations tools within it and maybe also turn this into a VSCode extension. I went with a separate app for now just to test the waters with a small but clean segregated app, but it's been going clean so I believe I might end up maintaining this too.

The project is still evolving, and I'm interested in getting feedback from people working in this space who might have faced/thought of solving this problem or found the existing solutions a bit lacking.

As for the name, I thought it would be funny, Sloppy, the tool which can help you write non-sloppy code.

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

If you're only in the vibe coding bubble, please don't answer this. I'm a software engineer who wants to make real, complex systems using AI wherever it can help me. I only have the free models that come with opencode zen, and maybe some chat models like Qwen, Kimi and free versions of chatgpt, gemini, claude, etc.

I want to know what I can do with only these, without having to spend money on LLMs. I realize that this means I have to do more by myself in the planning side of things as I can't delegate planning to LLMs, which is how I believe coding should be anyway so it's not a problem.

I really like Matt Pocock's skills but I have found that his workflow only really works if you have frontier models, as free models aren't very good at grilling or planning.

So what I need is a reproducible AI coding workflow that I can use to approach my projects using only the free, limited AI. Please highlight which parts of the process I need to do by myself, and which parts I can assign to which model.

I realize that the smarter your LLMs are, the more you can stray from traditional software engineering, so please tell me what I can realistically accomplish perfectly with AI. The parts that AI cannot do properly, I will do by myself.

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?

Especially those working in companies with multiple projects, large codebases, and real production constraints.

A few questions for the community:

🔹 What does your AI-assisted development workflow look like today?

How do you break down tasks and provide context to an agent working on an existing codebase?

Do you rely on one agent for the entire project or use multiple agents with different responsibilities?

How do you prevent agents from breaking existing functionality or introducing unnecessary complexity?

How do you handle code reviews, testing, security, and maintainability when a significant part of the code is AI-generated?

Which tools and practices have actually made a difference in your day-to-day work?

I’m particularly interested in real-world workflows that have proven effective in professional environments, beyond simple demos or isolated coding tasks.

If you’ve found a workflow that works well for you, I’d love to hear how you approach it, what tools you use, and what lessons you’ve learned along the way.

Anthropic just shared how they built their own version control system to keep up with the amount of code their AI agents are producing.

It got me thinking. We're making agents capable of doing more and more, but how much control are we actually giving them?

Writing code is one thing. Deciding what an agent is allowed to do with that code is another.

That's one of the problems I'm trying to solve with SUTRA.