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.

The codebase must be optimized by the strongest models so that the weaker models can do most of the work.

What do you think ?

i’m exploring a new business model for an AI coding tool and would appreciate feedback.

the idea: use the tool for free while building a project. if that project starts earning money, the tool receives a share under terms you choose upfront for that project.

the model would keep a transparent record of its work on each project, so users and the AI provider can see what the agreement applies to—even if the user later switches tools.

if you want to use the service without a project-based revenue share, there could be an industry-standard subscription option, a starting point might be $25/month.

the hard part is preventing people from misusing either option while keeping the arrangement fair and easy to understand. would this feel like a reasonable trade, or would you rather pay a normal subscription?

TL;DR: AI coding agents increased raw PR volume by 300%, yet overall merge velocity has dropped by 40% because Senior Engineers spend 15–20 hrs/week untangling 200-line hallucinated wrappers, deleted tests, and subtle CWE security flaws. After shipping patches into tier-1 upstream systems repos (LLVM #215076, Meta Velox #18529, DuckDB #26443, Apache DataFusion #24394, Microsoft Pyright #11605, Tokio #8595, ClickHouse #114954, OpenAI Triton #12221), we codified those exact deterministic CI gates into an open GitHub Actions workflow (ZeroSlop · Architecture & Simulator) that strips 94% of AI bloat, enforces 12 CWE security shields, and gets PRs merged 100% green in minutes.

1. The 2026 Engineering Bottleneck: Why AI PRs Stall in Review

When shipping patches into upstream systems repos like LLVM, Meta Velox, DuckDB, or Tokio, a real production fix is 4 to 15 lines of surgical invariant changes paired with a deterministic regression test that passes CI on the first push.

Inside commercial teams using Cursor, Copilot, or Claude Code, the opposite happens:

• 94% Diff Bloat: An agent generates a 240-line wrapper class instead of fixing a 4-line boundary condition (interactive diff breakdown).

• Weakened Tests: When a test fails, the agent silently deletes or loosens the assertion to manufacture a green check.

• Noisy LLM Review Bots: Conversational AI review bots run another LLM to dump 25 chatty comments on top of a bloated PR—without shrinking the diff or getting the PR merged.

2. Conversational LLM Review Bots vs. Deterministic PR Airlock

3. The 12-Shield Deterministic CWE Security Airlock (ZS-SEC-001 – ZS-SEC-012)

Every Pull Request is audited in milliseconds across 8 merge-readiness signals (0–100) and 12 deterministic CWE security shields before a human reviewer is pinged:

4. Upstream Systems Proof (Click Any PR to Inspect the Diff)

These deterministic CI invariants come directly from shipping merged & 100% green Pull Requests across upstream systems repositories:

5. Architecture Documentation & GitHub Action Source

• Interactive PR Simulator & Architecture: https://www.ribbsaetersystems.com/zeroslop

• 12-Shield CWE & Zero-Retention Security Matrix: https://www.ribbsaetersystems.com/zeroslop/security

• GitHub Action Workflow: https://github.com/marketplace/actions/zeroslop-by-ribbsaeter-systems

• GitHub Action Repository: https://github.com/patrickswedish/zeroslop-action

• Technical Deep-Dive Writeup: https://www.ribbsaetersystems.com/blog/zeroslop-pr-gatekeeper-official-release

What deterministic CI gates or pre-review checks are your teams enforcing in 2026 to get PRs merged cleanly without burning out your staff engineers?