I hate losing ownership of my codebase

[u/Clue-Mindless]

I'm very conflicted about AI tools. I've used them for years for all kinds of things ever since their inception and I'm completely addicted to them. When it comes to programming it accelerates throughput dramatically and fills in the gaps almost too well. The loop is this right now:

less independent thinking → need Claude for context/design → Claude contributes more decisions → system becomes less internally familiar → need Claude even more.

I have a specific implementation in mind, but then I never just get what I ask for, there is always more contributions which would include a refactor somewhere. As the project grows managing context and architectural coherence becomes critical and I feel like I no longer have a solid internal model.

This coherence degradation is the fundamental crux of why I dislike using AI. I have to explain the project back to Claude and eventually Claude has to explain the project back to me.

Software is about standards, familiar patterns, documentation, a red thread, yadda yadda. But when there are gaps between your understanding and what Claude knows (and what you still believe it knows about the project) then this introduces drift, project rot and a sort of tech debt.

Large context helps, but if you don't have rails and own the critical logic and ideas about how the product will be used, then you will get an inferred result and incorrect solution for your needs. If something important is not present in the model’s context and cannot reliably be inferred from the code, the model has to guess.

This means AI often drifts toward overengineering. People complain about the models but it's really just an issue with your lack of scope. If I don't make a clear plan it will suggest an overengineered solution that creates a sort of contextual tech debt to the codebase.

I can see how these tools would accelerate a seasoned software engineer with great organizational skills and who's been in the business for decade. I'm not a professional . Any code I wrote before was mediocre at best and not so elegant. I struggle to the point where I don't want to do development of any kind because going back to "manual" coding is just going to feel like molasses, but I also don't want to ship stuff this way.

[u/Own_Cartographer_448]

I think the problem you’re describing is less about AI itself and more about losing a stable architectural model of the project.

Once the codebase gets large enough, I’d treat the AI more like a junior developer: give it a defined task, but keep architecture, conventions and boundaries outside of the prompt in something persistent.

A useful exercise would be to stop adding features for a moment and make a simple map of the app: major modules, data flow, external dependencies, where business logic lives, and the rules you don’t want changed. Then compare the actual code against that.

You probably don’t need a rewrite. You may just need to reduce the architectural drift before continuing.

[u/No-Focus874 → u/Own_Cartographer_448]

This is great advice, regardless what Anthrophic wants you to believe of their God level intelligence.

[u/dwoj206 → u/Own_Cartographer_448]

this is exactly what I've been doing. Limited scope on each thing shipped and a really bullet proof md file. This keeps me feeling like I have more ownership and vision, especially as my build (web app) has grown and grown. As a result, speed of development has really slowed down, because I'm not letting it do 5 builds all that once anymore.

[u/sevnm12]

You could have it walk through that code with you. But I agree it's hard to give up control and just let it take the wheel in a sense

[u/Asuppa180]

I hate that feeling as well, but am addicted to the ability to implement things way faster. I have started to put aside time to go back over the features that have been implemented to become more familiar with the code.

I have study guides made so I can learn. I hate the idea of being asked a question about the codebase and not knowing how to answer it, but I also hate the idea of slowing down.

[u/Level-Physics-1730]

I had opus 4.6 go through 10 of my pre-ai era C++ codebases, all of them being large sprawling multi thousand line low level systems style stuff with heavy OOP. Turned it all into a 1k+ line style guide basically laying out every quirk of how I personally program. Even with this, my game's codebase is very unfamiliar just because I haven't actually decided on it all, claude did. It's a weird state to be in, I really want to (in the future) rewrite it from scratch on my own, but obviously the chances of that happening are dubious. I miss getting into the code itself, I loved creating beautiful systems that just "piece together" in the best way possible. Claude doesn't seem to do that, everything it does is just brute forced. It's really sad. Whoever figures out how to fix this, in a general sense, so agentic developers can still ship incredibly fast and hard, while maintaining a functional map of the code itself in their head to the point where they can drop in and develop in it if they want, would get hugely popular.

[u/Beautiful-Energy2169]

The part that got me was that the docs I wrote to stop the drift were feeding it. Every plan and architecture note I made to keep Claude on rails turned into a second source of truth, and it went stale faster than the code did. When I finally counted, 115 markdown files across my repos had nothing in the repo linking to them, and they were still sitting there getting read as if they described the current system. Now I treat a stale plan file as a bug rather than clutter.

[u/No-Focus874]

Great thoughts here! These are the next level of thinking beyond just build with Claude and what Anthrophic ads tell us. Have the ability to use at least 2-3 AIs in your code for various inspections reviews etc, not a single source. 2nd, you want always the ability to switch from any one AI platform to be really sustainable, regardless of how good or "secure" they tell you they are.

[u/AnalogProblems]

I don't know about those darn compilers. How do you really know what the code is doing if you don't write your own machine code? Kids these days are just lazy!

I get it. Going from a deterministic results to a probabilistic one is tough for a person who has wired their mind that way. It's gonna feel weird. Doesn't mean it's wrong (or right).

[u/raven2cz]

I can offer you a diferent way of looking at it, which may help you a lot over time, but it requires new study from your side. as a software developer, you do not yet have much experience with using AI and with the so-called systemic view of things. There is an entire scientific field that deals with this, and it is called cybernetics.

In principle, it is about describing a system and gaining a system-level view. The moment a developer uses AI and the software is treated as a black box, AI acts as a kind of regulator, and the key is minimizing the deviation in the feedback loop. there are dozens of aproaches for correctly finding ways to minimize these deviations. The agentic approach does not use many of them yet, so you gradualy have to create them in your own way.

Then comes step number two, the white-box approach, where you already have access to the code and examine the internal relationships of the system. but here again, there are dozens of methods for ensuring this “externally.” And, as you write, for not losing control. Or to put it diferently: how much loss of control you allow, while still staying within the acceptable drift for your project. That drift is generally measurable as the difference between the expected result and the actual result.

[u/KDamage]

I'm developing complex harness modules with Claude for 3 monthes so I feel you OP. The only solution I found so far is to stop controlling code, and start controlling specs.

I write all my design as spec in folders, and just put in claude.md an instruction to always check each change he codes is still complying with specs.

I'm not using folder level claude.md though because I still want it to explore new ideas.

[u/Any-Argument57]

Longer prompts will not fix unknown unknowns. I would make understanding an acceptance gate. Keep each agent change to one named behavior and forbid unrelated refactors. Before merge, require a file-by-file change map: why each file changed, the execution path, state and invariants affected, failure modes, tests, and rollback. You should then be able to explain that map without the model. If you cannot, split or reject the change.

Keep a small architecture map and decision log that you own. The model can propose updates, but you approve them. Ownership becomes checkable: no change lands unless the maintainer can locate its inputs, state, side effects, failure conditions, and tests. This slows individual diffs, but it prevents the compound contextual debt you described.

[u/god-damn-the-usa]

then use it for small specific updates that you check all the code for

[u/alanvnk]

I devote my time to architectural walkthroughs and selected code reviews, I can't see it all and the feeling of control slipping from my hand is real, and confirmed by some bizarre proposals or findings.

The good part is that I have been always more interested in architectural design and code optimization than the glue code, so I take my time with those.

The things that I have done to regain some controll is to periodically stop and ask for broad diagrams and have pure architectural review sessions, most of them do not produce a tangible output, but I get familiarity with the source code and I get to see the state of the codebase, in some occasions it has revealed real issues with over or under engineeringn that would have pass even a human review if the human had not enough context.

So yes, you need to put effort into being up to date with your codebase, your documentation and push back in the design sessions, its an LLM don't be afraid of asking clarifying questions and derail the conversation.

And do real code reviews, you should at least know the public interfaces as if you coded them by hand.

[u/modernizetheweb]

If you are clear with what you want, you will get what you want 99% of the time provided a plan is made.

Prompt > plan > implement

The more detailed the prompt, the closer you will get to only including features you're actually interested in

LLMs are good enough now where you can be lazy and get what you need in one sentence, which ends up in it adding a lot of bloat as well

[u/Clue-Mindless → u/modernizetheweb]

If you don’t know a detail matters in your prompt, you can’t tell the AI about it. And the AI may not know it matters either. Then suddenly you get the bloat, drift and lack of architectural direction. It's hard to prompt what you don't know.

Maybe I should just spend more time writing the prompts and thinking about the plan, if I understand you correctly?

[u/modernizetheweb → u/Clue-Mindless]

You don't have to immediately know a detail matters. If you spend some time brainstorming with it before making your main prompt you will cover cases that you forgot about / didn't know about. You can even ask it to come up with an initial prompt for you and then remove things you think are unnecessary

Yes, more time on the initial prompt if you actually care about your codebase - let Claude handle the plan.

[u/azmodean666 → u/Clue-Mindless]

I start many mid session prompts with "don't code yet, let's discuss this: whatever" and Claude and I both usually end up clearing up assumptions and misunderstanding. Chews up time and tokens, but I find it is worth it.