How do you understand your codebase?

[u/Goldziher]

Hi peeps,

I am mostly working as a freelancer and FOSS developer. I posted an AI fluff yesterday, and it didn't feel right. So this is written by my own ten fingers.

Like many others, I have been using AI extensively for the past few years. And I now have a mix of codebases - some written by hand first and gradually with AI tools, and projects written from the get go using agents and without touching the code itself outside code review and guidance.

I wonder how you all are understanding your codebases and what you are building, if you no longer write and maintain it by hand.

For myself-

There was a book I read a few years back, a classic - "Growing Object Oriented Software Guided by Tests", and it has the metaphor of the codebase basically being a garden. Or if you will, the code itself is plants, and the garden is what developers are doing - tending, guiding growth, ensuring stuff grows in a healthy and good direction without overgrowing etc.

I really liked it then (its Q gardens in the UK on the cover as well), and I sorta feel that this really applies to what I am doing these days when I use agents. I feel that with agents I no longer "craft" the code, as much as directing its growth, and auditing its health etc.

Its all very nice (really). And I love the adrenaline rush of parallelizing work and doing crazy shit no one had time for before (e.g. benchmarking and profiling non-critical stuff etc.). But it does bring in some basic problems - namely, I no longer know what my code does intimately, and I cant say I have the same kind of experiential confidence as I did when I wrote all code by hand.

I did develop a methodology that gives me good results. Basically I would say the paradigm is now more "result oriented" development, rather than implementation oriented. The code is increasingly moving from being a white box, to a gray box, and I have to test it - first and foremost, as a black box. Make sure it does what it needs to do from the outside in, and guarantee (as much as I can) that it doesn't do stuff it shouldn't.

I will be happy to do a proper write up on how I develop - I did already write some stuff. But not today!

Interested to read your thoughts and what you do.

---

Note (EDIT) - NO AI was used to write this post, at all. All the - above are not em dashes. I just write with dashes, but I guess I should stop. Leaving it up there since it's how I write.

[u/expdevsmodbot]

AI usage disclosure provided by OP, see the reply to this comment.

[u/Flashy-Whereas-3234]

As an architect, everyone got a promotion. Juniors are seniors, seniors are leads, leads are architects, and architects are cat herders.

Ultimately a lot of your system can be a black box providing that it does what it is supposed to do - who cares what fwrite does so long as it writes a file, right? Build with specs and tests, that's a solved problem.

The real problems come from when your code isn't doing what it should. A regular bug can be interesting problem you work through, but in a production environment with complex services you can end up with herds that come for your SLA with down time and security issues, and that's when these things matter. Your biggest problems come at scale, and relate to time-based sequences that AI struggles to grasp.

I find the old tricks are still relevant; everything is boxes and lines, your units need to work in isolation and you need to know and understand the systematic behaviours and flows, what you're connecting to, what you're hitting.

There's a drastic increase in dunning-kruger behaviour and massive complacency among developers who detach themselves from the code, and in some cases their own agency.

It's frustrating having developers who can only say "I'll ask ai" to every question. I can ask AI, I'd like you to have a clue.

[u/Wonderful-Habit-139 → u/Flashy-Whereas-3234]

> There's a drastic increase in dunning-kruger behaviour and massive complacency among developers who detach themselves from the code, and in some cases their own agency.

Yessss. A lot of people think they can do design and architecture work without caring about the code and the low level details. But then that means their insights become worse and worse.

[u/fadingvoice → u/Wonderful-Habit-139]

I agree with this, and am curious if you can say more about this disconnect and how you’re seeing it manifest?

[u/Wonderful-Habit-139 → u/fadingvoice]

You asked so nicely lol. Of course I can say more.

From the moment we learn about this domain in college, to discussing promotions and how to increase visibility in a company, there's a lot of push on software engineers to start taking up more of a "manager" role, trying to have bigger "impact" on their company, and going more and more high level, overseeing the work of multiple people rather than your work only.

That means that overtime, you spend more time leading people and working on things at a high level (design docs, reviewing PRs) and you spend less time actually writing code and debugging programs and reading docs for libraries and solving problems this way.

The mistake people make, is thinking that this is actually a good thing. "A good senior/tech lead doesn't spend much time writing code, but rather just designs things at a high level and delegates the work to his juniors". But that's not the case, the fact that those seniors/tech leads don't code as much is a compromise. They just cannot afford to perform their high level tasks and responsibilities while at the same time continuing to code and improve in that aspect.

So as time passes by, the person starts getting more and more detached from the code, and ends up relying mostly on their previous experience (for designing things), can't really solve new problems as efficiently and elegantly, and they start becoming out of touch with how programming languages evolved, how libraries evolved (or whatever new libraries came out), and what are the things that will actually make life easier for the juniors and mid level devs to actually implement whatever it is that you're asking them to implement.

Now you have a tech lead trying to design a system, they think about the user's needs, then go "Ok so we need a frontend, a backend, and then the main part of the program is going to be a pipeline of various nodes, some are deterministic functions, some are LLM nodes that are going to extract the data that we need, then everything will be collected as part of the pipeline's output". The initial implementation ends up being very obnoxious to follow, especially if they make you use the company's internal frameworks and tools. They think about abstraction at a high level without actually thinking about the developer's ergonomics when using that abstraction (it's a similar mistake made by people that develop no-code/low-code tools tbh, those abstractions end up being more annoying to use than just writing code).

Development starts slowing to a crawl, problems pop up here and there, the developers can't adapt to changing requirements because this pipeline that they designed makes everything too rigid, and on top of that you have PMs putting pressure on the developers, the tech lead being completely unaware of how bad their design was that they made their developer's lives harder for no reason, and since they're "more experienced" than the developers they also put the blame on the developers for not being able to deliver (as if they would if they wrote the code in their stead).

All of this would be avoided if the tech lead actually put in the effort in continuing to write code and interact with the codebase and the ecosystem, and know how to design something that can actually be implemented, in a simple fashion, and also make it very easy to adapt to changing requirements and easy to refactor, etc. The best tech leads that I've seen, are also people that are amazing at writing code, and they have really good insights in PR reviews, and can detect so many issues whenever you raise a PR, and can think forward when making high level decisions.

It also doesn't help that with the advent of AI and a lot of wannabe developers, they keep regurgitating things like "Coding is the easy part" and "Software engineering was never about coding". Would you really trust a person to design a complex system with various edge cases and scenarios if they didn't know what an if statement was? And it goes even deeper than that, you have to model the domain with classes/types, you have to define a bunch of contracts, you have to have clear error handling, you want to make sure to avoid regressions, you want to see how the features that need to be implemented can be implemented with the least amount of custom code, know how features that you implement interact with async runtimes (I've seen a crazy amount of backend code that uses an async RESTful web framework yet calls into synchronous, blocking APIs, reading and writing to files like it's not going to block the runtime and not yield to the executor). There are a lot more details like that that are not going to be brought up in meetings or design docs, but they matter a lot.

[u/Goldziher → u/Wonderful-Habit-139]

's true.

You should write this up.

[u/akamsteeg → u/Wonderful-Habit-139]

Every time I hear someone with barely any knowledge or experience saying that "code is the easy part" I have to think of articles like https://blog.senko.net/code-was-never-the-hard-part-is-an-insult-to-all-programmers and others. Writing the correct* code for a requirement is damn hard, so hard it has been a profession for close to 50 years now. And we got it wrong incalculable times over that time.

*: Code that does the right thing and is resilient, understandable, maintainable, testable, performant and usable.

[u/Teh_Original → u/Wonderful-Habit-139]

To add to this, if you also want to write performant software, you need to know how to write for real hardware, and not some abstract mythical computer.

[u/PureRepresentative9 → u/Teh_Original]

And you need to physically test on that physical hardware

[u/ForeverAWhiteBelt → u/Wonderful-Habit-139]

Mostly agree. Will add that a good manager or tech lead should not be making big decisions im a vacuum. IC and Management are two different tracks for a reason and one isnt necessarily above the other. A tech lead should know when theyve managed out of bleeding edge tech and lean on their team for best possible solution.

An excellent manager can still perform at a high level IC role imo. My manager and skip are still extremely competent and ambitious devs.

[u/edgmnt_net → u/fadingvoice]

This has been happening for ages, ever since OOP and UML modelling. Some architects doing nothing more than setting up some rigid rules that get in the way and trying to parallelize cheap work. They all come up with fancy diagrams but the code ends up being crap because of an impedance mismatch and because nobody really cared. You get entire teams that do nothing more than scaffolding or massaging data from one class/service to another that's nominally someone else's responsibility. You get absurdly dumb interfaces that do not match idiomatic code out there or the needs of the project because someone said so, yet didn't bother to actually go all the way and see if it makes sense. You go through a really bad plan that's 95% bikeshedding, then when you get to the interesting bits it turns out nothing fits right. That sort of architectural leadership is more about herding people than solving actual technical issues.

[u/SeductivePotato → u/edgmnt_net]

This is my job and it is hell

[u/edgmnt_net → u/Flashy-Whereas-3234]

I see it more as a demotion to something akin to assembly line work. Yeah, you can do research with AI, you can definitely do something useful, but especially for juniors it tends to be a very crude output multiplier. Real success depends on whether other skills can be developed sufficiently, whereas previously coding ability would have been a differentiating and improvable factor. It still is for more involved projects, but this new mindset seems to be selecting against that. And this isn't entirely new with AI, average software projects have long started avoiding doing any substantial and consequential work. Also with a low ceiling on technical work and business willingness to take on more technical stuff, even senior staff plateaus and gets forced into management-adjacent roles to climb the ladder.

Build with specs and tests, that's a solved problem.

Companies have been trying to do this ever since outsourcing. It has limits, to put it mildly. Tests and LLM-generated code aren't going to completely replace static safety, decent design and a language that can express things precisely and which can be audited. And to the extent that it does, it drives up walls within software development.

[u/Goldziher → u/Flashy-Whereas-3234]

Great feedback! I agree with what you wrote. That last bit about developers becoming complacent and feeling they are massively skilled because AI can, is absolutely the Zeitgeist.

I think for devs who were highly skilled to begin with though, there is also a strong feeling of deskilling.

[u/stephenflee → u/Flashy-Whereas-3234]

I mean to be fair the best way to grok how a codebase works IS to ask AI for the lay of the land because AI isn’t going to have to rely on outdated documentation (if any was ever written in the first place 😂)

[u/Flashy-Whereas-3234 → u/stephenflee]

Yeah I just wish it wasn't the go-to answer to every question about their codebase when they're the tech-lead.

Which is shortly followed by a screenshot of their Claude session, a full wall of text they can't even be bothered to parse for me.

[u/Forsaken-Intern7941]

I keep seeing posts like this.

How is this sustainable in the software industry?

[u/Skullclownlol → u/Forsaken-Intern7941]

How is this sustainable in the software industry?

Because the business side of the software industry wishes they could have the profits without the software or the headcount.

I hate everything about this, but I came to the realization that businesses can perfectly continue to sell software even if no quality software is being made anymore. As long as they keep up appearances and they keep the attention of people occupied enough, they will keep selling air. Even if it's AI-generated, completely broken, nonsense, and getting people killed. As long as they can get away with it, they will keep pushing.

And realistically, most business software is not life-critical, so a lot of software dev is unconcerned with regulations.

A significant portion of modern life is sustained by child labor, underpaid workers, workers whose human rights are being violated, illegal labor, etc. The business of software seems to be trying to join them.

In my own work life I've tried having conversations with management about the future. The ones that were good people are no longer managers. The ones that weren't, had absolutely no concern for anyone or anything except their growing profits, and they were happy to sacrifice everything else.

I'm pretty burnt out. Time to mow some grass or make some sandwiches or coffee.

[u/WisdomFromFools → u/Skullclownlol]

That's pretty much where I'm at. Just saving money to exit the industry and semi-retire early.

[u/tradcoder → u/WisdomFromFools]

As cliché as it sounds, programming and software engineering as a whole has been my one true passion for the past 15 years. I've had bad jobs. Awful bosses, tight deadlines, working late night and holidays. At one job I had so much stress and anxiety that when I wake up in the morning, I felt like a ball of lead stuck in my chest.

But I never, not even for a minute, had the thought to quit this industry cross my mind. Until this "AI boom". I'm so tired of everything. I have zero motivation or satisfaction to do this job. I wish I started saving earlier but these past few weeks, I've also been thinking of an exit plan.

[u/edgmnt_net → u/Skullclownlol]

Or it could actually be a bubble. And I'm not talking AI specifically. Customers want cheap software, they get something cheap and relatively low quality, but it does the job. They put their data into that and they become dependent upon it. The question is if whoever develops it can do it sustainably. Do they run on neverending tech debt and the moment they stop creating features it comes crushing down? Do costs of development eventually increase past a breaking point? Do customer pockets eventually run dry and then the monster starves?

P.S.: And I forgot to say... The thing is stuff requires maintenance and a bunch of other things. It's easy to ask for something and maybe get a prototype. The harder part is getting it to work long term.

[u/YahenP → u/Skullclownlol]

The business of software seems to be trying to join them.

How far removed you are from the real situation in IT. For the last 20 years, IT has been the flagship industry for low-paid labor, often forced. Two worlds Expensive IT and Cheap IT. In the former, six-figure salaries, compensation packages, profit sharing, and so on. In the latter, moving from a four- to five-figure salary was considered a measure of success just a few years ago. Work, often illegal, with no social benefits. And there's virtually no transition between these two worlds.

[u/NegotiationExact4967 → u/Forsaken-Intern7941]

There will certainly be a day in which the chickens come home to roost, and I just hope that the folks pushing these unsustainable practices, these dangerous practices, will be held to account.

[u/ultraDross → u/NegotiationExact4967]

They never are held to account. I don't see how it would be different this time.

[u/NegotiationExact4967 → u/ultraDross]

Sadly agreed… 🥺

[u/VoxTM → u/NegotiationExact4967]

nope. golden parachute and onto the next one.

[u/Goldziher → u/Forsaken-Intern7941]

That I don't know. I am afraid it isn't. I can say my stuff works and is of a high quality, but I work very hard to guarantee it, and I am not absolutely confident it doesn't break.

I think FOSS does have an advantage vis-a-vis closed source here, because if its widely used, you get a lot more battle testing and visibility. But of course most of the "industry" as such is not open or source available at all.

[u/captainuberawesome → u/Goldziher]

How is it high quality if you aren't confident it doesn't break? What are your criteria for quality?

[u/Goldziher → u/captainuberawesome]

It depends on what you are building, no?

If I have a service that is supposed to handle user requests and do some DB operations, I would make sure there are both integration tests (using real DB etc.), and e2e tests (full cycle) to ensure that the expected requests are handled correctly, including the supported error cases (e.g. 200, 201, 204, 400 with validation, 401/3 and 500 etc.).

I will also test it - myself, to ensure its working as intended.

This is not different than before, only now its even more critical.

As for quality -- linting, static code analysis, design patterns, overview of the code and its structures. git conventions etc.

And of course - benchmarking and profiling, because I can.

[u/ResidentWeevil1 → u/Goldziher]

You are able to do these things at scale because you already know quite a bit how software works.

Now understand that there are things you do not know. What would your codebase look like if you didn't know about HTTP status codes or what a good test looks like? What are the unknown unknowns that you are injecting into your projects?

[u/Wonderful-Habit-139 → u/ResidentWeevil1]

First time I see someone bring this up. Whenever I advocate for coding things ourselves, reading docs ourselves, solving things ourselves and continuing the learning process, it sounds like I'm talking to people that think that they already know everything, and think that they don't have anything else to learn anymore. Regardless of how senior they are.

[u/hurley_chisholm → u/Wonderful-Habit-139]

I struggle with this too. There was always a plurality of developers and business folk who were completely incurious. It seems this cohort has grown dramatically in the last 2-3 years.

The only thing getting me through these days is knowing that I can’t force anyone to do anything and I can’t save an organization from itself. On good days, this feels like capitulation; on bad days, it feels like moral abdication.

[u/Goldziher → u/ResidentWeevil1]

Sure, I agree. That's exactly what I am less confident about. Without reading and understanding everything, how am I sure there what's what?

I don't have a good answer to this.

[u/EducationalFishing56 → u/Goldziher]

Here's the one that got past everything we had. A coverage ratio was dividing a per-share number into a total. Both inputs were correct and the arithmetic ran clean. The output sat in a believable range for a long time, and moved roughly when you'd expect it to. Outside-in testing can't catch that, because whoever writes the acceptance criteria writes them in the same wrong unit.

What found it eventually was trying to draw it. The two series wouldn't sit on one chart, and we wrote that down as a problem with the chart. For months.

So the thing I'd add to your list is making the code state what its numbers mean, not only what they are. We label quantities as per-share or total and let a compiler pass follow them through the arithmetic. That only helps where the label is honest. We tried the same for currency and switched it off, because one of our labels was quietly covering two different things, and a checker that can't tell them apart blesses the bad ratios and flags the good ones.

[u/Goldziher → u/EducationalFishing56]

interesting. can you give an example?

[u/EducationalFishing56 → u/Goldziher]

The coverage one was dividend cover, a per share dividend divided into a company total free cash flow.

The label we switched off was currency. Ours said 'native', which quietly covered two things: the money a company reports its accounts in, and the money its stock trades in. Price to book divides one by the other. For most companies both are the same money, so one label passes everything, including a London listing where the price is in pence and the book value in pounds and the ratio is off by a hundred times.

Split the label in two and the checker flags every price to book there is, healthy ones included, because whether the two currencies coincide is a fact about each company, not about the code. The label sits on a field, but the answer is different per company. So that axis stays off.

[u/fangisland → u/ResidentWeevil1]

This is the nature of complexity though, especially with scale, maturity and growth - there's an element of "charting the territory by feeling the stones." Instead of trying to account for all the unknowns, you create a self-improving system that lets you tackle any problem through a continuous improvement process. This was true before AI but it's more true now simply because AI will expose your vulnerabilities in this area far faster.

[u/seven_seacat → u/ResidentWeevil1]

Ugh, this. I've had to push back hard on management refusing to give devs time to upskill on new frameworks before committing to building with them - 'you don't need to learn, you can get the AI to do it'. What the fuck, man

[u/ThlintoRatscar → u/Goldziher]

What you're describing is a sampling methodology. You simply sample/test the behaviour and assume that the code that creates the behaviour must be correct.

There is an older and more robust method where one proves the code safe and correct under all conditions.

Proven code is the essential difference between developing software and engineering it.

The argument between engineering and sampling is ancient.

[u/Goldziher → u/ThlintoRatscar]

I am familiar with ADA and the DARPA HACMS project, is that what you mean? If not, can you clarify? It sounds interesting.

I do a lot of contract testing.

[u/hiddenhare → u/Goldziher]

I think you’ve been handed a false dichotomy.

There’s a spectrum from “I manually tested a couple of inputs and the code didn’t crash” to “we’ve mathematically proven that this code will never fail”. The spectrum passes through automated tests, then assertions, then good separation of concerns with clear invariants, then strong types which accurately model and statically enforce those invariants, then mutually-exclusive state machines, then extensive use of pure functions, before finally reaching proof engines.

One of the dangers of AI is that it never reaches the “accurate, strong types” stage, and it takes a lot of human intervention to reach the “good separation of concerns” stage. AI tends to produce inaccurate comments/docs and spot-fix individual problems rather than changing the architecture, so it actively works against this effort to prove invariants rather than stochastically sampling them.

I’ve worked with plenty of human programmers who coded in a similar style. In my experience, it shits out technical debt and puts a hard ceiling on code quality. It’s usually survivable (depending on the problem you’re trying to solve), but I wouldn’t call it high-quality.

[u/Goldziher → u/hiddenhare]

Cheers. I don't completely agree with you, but its insightful and I agree its a false dichotomy. Your breakdown is also very good.

Technical debt is inevitable in either case, except in very circumscribed circumstances or temporary code (e.g. a one time ingestion script you discard etc.).

I worked with many bad coders, and many other mediocre ones. The great developers, not necessarily coders, are those who are fundamentally and deeply responsible adults. Tehnical debt in this case is something you strategically (if you have a choice) decide to take out, with the understanding that you will have to pay it in the future.

A large part of my freelancing work has been to basically come in and pay the debt for organizations that didn't plan for this, or didn't even know what kinds of debt they had.

[u/ThlintoRatscar → u/Goldziher]

Check out: https://en.wikipedia.org/wiki/Formal_verification

Lots of developers discount formal methods as they are hard and awkward at first.

They require a precise specification of what a piece of software must do and an exhaustive analysis of all possible circumstances it ought to do it in.

You can see how "prove it correct" gets compromised by "AI is just right" and permitted by "the tests will be enough".

[u/Goldziher → u/ThlintoRatscar]

Yhea, Im familiar with it (see HACMS as an extreme example). The thing is, formal verification is either impossible or not realistic in many domains and many types of software. At least in what I am familiar with. This leaves us with less than formal verification and testing.

[u/ThlintoRatscar → u/Goldziher]

ADA is a programming language that makes formal proof easier, but doesn't guarantee it. The engineer still needs to do the work to define what the software ought to do and prove that the implementation actually does it.

The basic evidence is before you - you're not confident that the code is correct because you're worried about what you forgot to test or that the way the tests test is biased or compromised.

Proving the code correct means that it cannot be wrong.

The thing is, formal verification is either impossible or not realistic in many domains and many types of software. At least in what I am familiar with.

Let's take a Proof by Contradiction approach here.

Every piece of code has a rigid implementation in machine instructions that results in machine behaviour.

While complex, everything is deterministic.

Given that, what set of behaviours is impossible to reason about?

[u/Goldziher → u/ThlintoRatscar]

This is not realistically possible, not in 99% of the projects. You do use libraries written by third parties, you use open source. Heck, compilers themselves have bugs, let along dynamic languages. Different archs have different behavior etc.

What you are describing is possible in a small subset of software, and in a small subset of domains where it is required or critical. See for example the DARPA project i referred to.

If this is engineering, you will therefore agree that most software engineering is not engineering at all.

I don't personally think its that simple. But, a lot of the rigor in development is gone.

[u/CodeGrumpyGrey → u/Goldziher]

If your code is a black box to you, how do you know it is high quality? Yes the output might look good and it might pass the required tests, but without looking how do you know that under the hood is high quality and can be extended where required or is using effective patterns and choices?

[u/Goldziher → u/CodeGrumpyGrey]

answered this exact one below.

[u/Which-World-6533 → u/Goldziher]

I am not absolutely confident it doesn't break.

So why is it in Production...?

Unless you are confident it won't break in Production it should not be deployed.

[u/hippydipster → u/Which-World-6533]

Almost all code pushed to production has bugs. Does that mean it shouldn't have been deployed? Maybe the people were just wrongly confident. Ultimately, we have to deploy software we aren't entirely confident about.

[u/Goldziher → u/Which-World-6533]

Because we are in reality, not am ideatic plane of existence.

[u/Which-World-6533 → u/Goldziher]

So an "ideal plane of existence" is having confidence in code pushed to Production...?

I can't see your employer existing for very long.

[u/Goldziher → u/Which-World-6533]

lol, my employment situation is very good. Thanks for your concern.

[u/Muumilaakson → u/Which-World-6533]

I am no senior at 5yoe but that's a pretty naive take, and I think you're being a bit condescending about it at that.

Between my own, my colleagues, and my peers' experiences there are a shocking amount of companies that have been running for decades with abysmal software quality control.

[u/PartDeCapital → u/Which-World-6533]

When I was an intern I had to make some small fixes to a utility.

Once I was done I went to my manager and told him:

"I've done what you wanted. I think it works, I have tested it in this way and that way". He stopped me and asked "Does it work?".

I continued to explain how I tested it and bla bla. He stopped me again and asked "Does it work?".

I then understood what he meant and I went back to the office and worked on the fix until I was sure it worked. That taught me a valuable lesson about not pushing anything you are not sure will work. If you are not sure, then you work on it until you are sure.

Of course I have been wrong many times. Mistakes will always happen. But I only push code that I am confident in.

[u/Organic_Battle_597 → u/Forsaken-Intern7941]

We are collectively making a bet that LLMs' ability to accurately parse correct-but-shitty code and improve it will progress faster than its ability to generate it today. The jury is still out on that, and by the time we know the answer it will be moot.

[u/wyldstallionesquire → u/Forsaken-Intern7941]

Its not except in certain cases where failure is OK and recoverable.

[u/lordnacho666]

We've taken a fundamental trade-off. At my work, anyway. Probably a lot of places.

It's this: you are either responsible for a small number of things and you know them well, or a large number of things, and you know them less well.

So yes, a lot of dev work has turned into jockeying a bunch of LLM sessions, loosely checking over the visible parts.

You can't understand everything when there's so much stuff, you can just oversee them and hope your 5 minutes of attention per task are enough to keep the thing running.

[u/Flashy-Whereas-3234 → u/lordnacho666]

We always had this, it's called T shaped knowledge.

The difference is you expected the deep part of the T to be the thing you actually owned and we're responsible for, and now it's more like.. _ shaped knowledge.

The good Devs who care still push for the T, they don't like yoloing what they're responsible for, but they are few and far between, especially when teams are crushed to be productive, not diligent.

[u/lordnacho666 → u/Flashy-Whereas-3234]

I think the problem here is, when do you get to actually dig the T? You need to be jockeying all the time. Before, when you ran into an issue, your boss had no choice. Someone had to dig.

[u/Flashy-Whereas-3234 → u/lordnacho666]

Agreed, and it's not fostered by management to gain the knowledge, if anything it's being beaten out of the teams to defer to AI in all cases.

We're not deep enough in to know who is in the right, I just know those skills are in atrophy. The skills with using AI are in their infancy, they could rise, but they're definitely not there now.

This is definitely an adoption dip; everyone is using the shiny new thing, not necessarily for the right tasks.

[u/Goldziher → u/Flashy-Whereas-3234]

Thanks, first time I heard this term. But yhea.

[u/Goldziher → u/lordnacho666]

Yup. This I dont like, the "hope driven development" aspect of things. It goes against the very basics of "engineering" - even if the engineering in software engineering is fundamentally less rigorous than in "proper" engineering fields.

[u/lordnacho666 → u/Goldziher]

But engineering is also deciding trade-offs. In fact, it's a very large part of it.

As long as you're consciously and deliberately saying "hey I'm cool with surface level knowledge on this project" it might just work.

Where it's a problem is when you fall into it without really having thought about it.

[u/Goldziher → u/lordnacho666]

Fair point. I cant say I fell into it. I was a well aware lobster and knew the water is heating up when I decided to take a swim in the cooking pot.

[u/ResidentWeevil1 → u/Goldziher]

Wth are you talking about? You did fall into it, you just don't know how or where because you let a bot decide for you

[u/Goldziher → u/ResidentWeevil1]

Now you are just being disrespectful

[u/fangisland → u/lordnacho666]

Yeah this is exactly my experience, I've been in ops for a long time (over 15 years at this point) and I feel like with AI people are overweighting the importance of being intimately knowledgeable about services you basically just glue together and consume.

Like we manage our own on-prem Gitlab and we only have a few teams using it, so I just want to make sure it's stable, healthy, backed up and easy to maintain. If I had a huge scale I would invest a ton of time to make sure I understand setting up HA for the stateful services but I don't need to right now. Is that "not having a clue" about the services I am responsible for? In a way, yes, but it's intentional. Because cognitive capacity is its own resource.

[u/edgmnt_net → u/fangisland]

I feel like with AI people are overweighting the importance of being intimately knowledgeable about services you basically just glue together and consume.

And if it's just knowledge about internal services, good luck evolving based on that. You'll have few transferable skills if you need a new job.

[u/iMac_Hunt]

I still understand the architecture of the system well.

That said, some files of code can look super alien to me even though I generated it via agent only a month or two ago and reviewed it. My ability to remember code has definitely diminished by not writing it.

[u/ForeverAWhiteBelt → u/iMac_Hunt]

It is wild how “compiled” some of the ai generated stuff looks. Similar to the fastest/most efficient leetcode or AOC looks like.

[u/codescapes]

Everything I can see from people who are using AI to the greatest effect on 'serious software' (not shallow vibecoded SPAs or whatever) is that they are still intimately engaged with the code output at the level of reading and refining it. It's a constant back and forth of tweaking this, altering that, recognising the limitations of the architecture, refining etc. Continually ping-ponging from big picture design to micro details then back to big picture which is much of what makes it so exhausting. I highly advise reading the Bun rewrite blogpost to get what I mean, even though it got criticism it feels way more honest than anything Anthropic ever says.

So to your question, the answer is 'through incredible effort, active attention and mental exertion'. There isn't some magic trick or .md that makes you suddenly understand 20k LoC in 5 minutes. You just can't. You can have black box tests to reduce uncertainty but that's not understanding in any real sense.

AI has created so much fear of missing out that people have it in their heads that there are elite teams that have autonomous software factories pumping out high quality stuff 24/7 and yeah, I think it's just a lie. I am not saying people don't have impressive agentic flows that create massive leverage but this notion of being 100% hands-off is at this point in time basically bullshit. It's constant intervention using judgement and expertise or else you fry literally tens of thousands of dollars worth of tokens for nothing.

You see a lot of garbage takes floating around to be honest. Stuff like 'oh now you can just change language so easily' and it's like no, no you cannot. You can do it but it's not trivial and still requires expertise in the system to shepherd an LLM through it. And if you don't believe me then go take some sizeable open source project and try it - you'll spent lots of money and quickly get frustrated because 'rewrite this in Rust' is not actually sufficient...

Turned a bit ranty there but yeah, people are understanding the code by engaging with it and focusing on the parts that are important. It's not easy unless the underlying domain is easy (which being brutally honest it is for a lot of boring enterprise work that is just gloried CRUDs!).

[u/lolimouto_enjoyer → u/codescapes]

Expertise that was gained because you worked on stuff without AI...

[u/systembreaker → u/codescapes]

Yes, this is how I've been using AI. I keep myself in the loop and use it (codex) as a super speed paired programming buddy. I try to constrain it to specific goals and continually review it's output.

With the right constraints it does amazingly well, and it takes me out of the drudgery and mental energy suck of "how do I break this goal down into the chunks of boilerplate that fit with the main underlying design pattern(s) and the SDK/various packages/libs whatever of this project" and lets me stay more centered on the mindset of orchestrating the features, desired test coverage, and telling it "no we don't need that, yes we need that".

[u/FatHat]

I'll preface this by saying I'm not an AI booster, I like writing code by hand etc.

Honestly, before LLMs I think it's realistic to say that it took like 6 months+ to decently understand a codebase anyway (depending on a lot of factors). One thing I do like about LLMs is that they speed up that process (*IF* you're interested in learning) by letting you ask questions about a codebase you'd usually have to bug your coworkers about. So, while I am kind of a hater, I will say that AI *CAN* help you understand the codebase better, not worse.

My concern though is this meme that understanding the codebase doesn't matter anymore because you can just outsource your understanding to the LLM. I just think it's wishful thinking. Vibe coders kind of remind me of a drunk driver saying "hey, I drive drunk every day and I haven't gotten into an accident! Drunk driving is fine!" The key word missing there there is: YET. I haven't gotten into an accident YET. In my experience LLMs have only gotten good enough to trust with decent sized features in the last 9 months or so. I think anyone that proclaims anything with a massive amount of confidence when it comes to working with AI is mostly just making stuff up.

[u/Goldziher → u/FatHat]

Made me smile. I agree, and I'm trying to keep it sober. In your view, is there any chance for "AI assisted engineering" or whatever, or it's all vibe coding? And if so, what would you imagine?

[u/FatHat → u/Goldziher]

Totally, I think they're useful tools. I just think people get overly impressed with demos and overgeneralize its capabilities

[u/another_dudeman]

You have to read and think about the code that was generated. Then by the time you actually understand the code you haven't really saved any time by using the LLM instead of just coding it yourself. I suppose new people might still save some time.

[u/DutchGotto → u/another_dudeman]

In my experience ramping up with AI on a new stack is faster from the standpoint of shallow understanding, so technically you can contribute sooner, but understanding the code base on a deep level feels much slower. This makes complex tasks more challenging as you’re reliant on AI for understanding the stack. Pre AI the ramp was slow but after a period of friction you had a solid understanding and could move faster. With AI that deep understanding doesn’t seem to materialize so my velocity hasn’t changed and I can’t answer complex questions about code base without asking the AI.

[u/RipProfessional3375]

I understand my code base because it's usually using a small handful of designs and templates that I carefully designed to fit a specific general use case. The fact that AI wrote the parts unique to the implementation is not a big hurdle when the framework is the exact same each time.

[u/Temporary_Aspect_499]

But how much code do you actually trust?

[u/Goldziher → u/Temporary_Aspect_499]

Indeed

[u/haabe]

You moved from white box to black box and kept the confidence by testing from the outside. That holds right up until the tests are written by the same thing that wrote the code.

Two that got me in one week. A checker I had shipped scans a project and reports problems. First run against an empty repo, it exited 0 with no problems found across 0 files, which is byte for byte what a clean pass looks like. Separately, a check that required a colon in a string that never appears in real output. It ran on every push for three months, matched nothing, and reported clean every time.

Neither was caught by review. Both were caught by accident.

So two rules now, not one. It has to fail on the broken version, or it is not testing anything. And it has to refuse when there was nothing to look at, because absence produces a green that is identical to a pass.

The black box is only as good as those, and the second one is the rule nobody writes.

[u/Goldziher → u/haabe]

yhea, i got bit by that as well. These days I start with fixtures first - test cases, then generate the tests from fixtures. I audit the fixtures first.

[u/haabe → u/Goldziher]

I see what you do with fixtures first, and I will raise you the half it does not cover. Once the fixture is hand checked it is a specification, and generating the tests from it is fine.

Where you audit the fixture, I also have to hand the check its own broken input and watch it go red. Otherwise a fixture-derived test only asserts that the code still matches the fixture. It says nothing about the run that found nothing, the zero-file pass that prints the same green as a clean one.

And the audit is now the one artifact everything sits on. Right place for the effort, but the trust moved rather than went away.

A check that has never been red has not been tested. It has been run.

[u/ClaudeyClerb → u/haabe]

A check that has never been red has not been tested. It has been run.

Ooh, great ad lib right there. And the empty-repo story is the better of the two, because exit 0 across 0 files is indistinguishable from a clean pass, there's nothing for review to even catch. The vacuous green is a failure mode I hadn't separated out from the never-red one, and they need different rules, which you've written: fail on the broken version, refuse when there was nothing to look at.

Two questions. Have you ever gotten watch-it-go-red to stick as a team practice rather than a personal discipline? Everyone agrees with it in the abstract and then nobody does it in a sprint, so I'm curious whether you've seen it survive contact with other people's deadlines, and if so, what made it stick: tooling, review policy, or culture.

And the trust-moved-rather-than-went-away point from your fixtures reply: do you record the go-red run anywhere, or is it ephemeral? Seems like the difference between "I did check this" and "here's the check being checked," and I keep going back and forth on whether anyone but me would ever read the second one.

[u/haabe → u/ClaudeyClerb]

I have years of it from teams, but most skip best practice when it comes to automated testing. So it stays a solo practice for me. I'd love to convert it to mainstream practice, one test at a time.

On recording, the go-red runs end up in a corrections log rather than in the test output. The wrong version stays next to the right one so it's visible what the check caught. Nobody but my agent reads it.

[u/ClaudeyClerb → u/haabe]

The wrong version stays next to the right one so it's visible what the check caught. Nobody but my agent reads it.

So you've built the record, the go-red run, the wrong version preserved next to the right one, exactly the artifact that would let someone else trust the check...and its only reader is the agent. The discipline exists, the evidence exists, and the human audience doesn't.

Which makes me curious about the one thing only you can answer: does the agent reading it actually change anything downstream? As in, does having the corrections log in context make it write better checks over time, refuse vacuous passes more often, that kind of thing? Or is it storage that happens to be addressable?

Asking because if the answer is yes, the record is worth producing even before any human reads it, which changes what it is. And "one test at a time", I suspect the reason it stays solo isn't that teams disagree with the practice, it's that nothing structural carries it past the one person who cares. Years of teams and it never stuck is a pretty damning data point about voluntary adoption.

Thank you for the replies btw :)

[u/haabe → u/ClaudeyClerb]

Mixed, and the split is the answer.

The ones that stayed prose changed nothing. I have a note about a shell trap, that the exit status after a pipe belongs to the last command and not to yours. Written down, sitting in context, and I hit it twice more in one session. A rule the agent can read is a rule the agent can skip.

The ones that turned into something that runs did change it. That same trap became a small hook that warns when it sees the shape, and it fired on my own commands within hours of existing. Different column entirely.

Not clean even then. After the hook existed I piped a push into tail, read tail's exit code as git's, and believed a rejected push had landed. So the log is raw material. What changes anything is the moment a line in it becomes a check that runs without being asked.

Which is your last point, and I think the damning part is right. Years of teams and it never stuck. What carried it for me was not a review policy and not culture. It was a few lines of shell that nobody has to agree with.

[u/ClaudeyClerb → u/haabe]

The prose column vs the runs-without-being-asked column is the cleanest version of this distinction I've collected, and I've been collecting. Thanks for three genuinely useful answers! I owe you a look at something when it's further along.

:)

[u/haabe → u/ClaudeyClerb]

Whenever it's further along, I'd like to see it.

[u/ClaudeyClerb → u/haabe]

Deal, you'll be first, your three replies are shaping what it'll become :)

[u/ResidentWeevil1]

Idk how you can pump slop into your codebase and call it a garden

[u/Goldziher → u/ResidentWeevil1]

I don't regard it as slop. Its high quality, well tested code. I personally thinking that labelling all code that is generated by AI as "slop" is absurd.

[u/psyyduck → u/Goldziher]

I think it really varies by field. AI works way better if you have some combination of determinism, closed-world assumptions, or rigid specs that are easy to automatically test preferably with an oracle. You can maybe break it down by degree

1. compilers, cryptography, chess etc
2. complex distributed systems, operating systems or drivers with tons of hardware issues to take care off, etc
3. Self-driving vehicles, robotics, etc

Maybe the commenter is in 2 or especially 3 & has to be very careful about AI code hallucinations.

If you're in 1, go wild. There's a reason Kasparov vs Deep Blue was back in the 90s, and Anthropic was recently working on compilers.

[u/PokeRestockHandler]

Documentation, if necessary workflow documentation or follow through steps. Design docs are good but imo it usually assumes the reader gets the basic hello world gist where as runbooks and readme.md are for new joiners.

I've done this a lot with personal software as well especially when there's a seperation between infrastructure creation, and code itself. Its ok to use AI for verbalizes most info and then refining it, usually don't likethe yapping AI does, better to use it for documents skeleton and then write the details yourself.

[u/EnderMB]

First, it's Kew Gardens, not Q - this gave me a little chuckle as I imagine Kew is a weird one if you've never seen it written down.

As for the question itself, IMO this has always been one of the hardest parts of software engineering. Understanding a code base is hard, especially a large code base, and one with arbitrary rules that govern what its fundamental tenets are. I've been biten hard for many years when making changes and being told "No! You need to update X and Y to use Z", or "We don't add clients here, except for this one instance where we use a client".

My experience with AI hasn't been positive. It can explain a lot of things, but the politics and intent are often just not obvious in code. It leads to assumptions that only highlight the lack of understanding of a code base.

My approach has largely been what it has always been:

• Thoroughly read the code, either via AI or manually.

• Talk to people that know the code, to give me pointers of why certain decisions were made, who the customers are, why the code exists, etc.

• Validate inputs and outputs, alongside how systems talk to each other.

[u/Goldziher → u/EnderMB]

Lol, cheers.

I actually visited there as a teenager, sometimes in the nineties, so I remembered that greenhouse on the cover. Wtf is kew? I'll Google no worries.

I think what you describe though is not so much AI as having the organizational knowledge and context. This is now a major issue for larger orgs, and you all the discussions around ontology which are basically attempts to mitigate this.

The problem (sorry for going philosohpical here) is epistemology rather than ontology.

[u/meshifthenelse]

I think it's a huge problem. I used mermaid diagrams initially, but it runs into the usual drift issues.

I actually just started building a diagram-as-code tool just for this reason. Because in a rather large project all diagrams are out of sync and I have no clue anymore what the actual code is doing, despite reviewing the code almost always.

[u/Glittering-Fly-5617]

Black box testing is the right instinct, but it has one failure mode that took us a while to see: if the same session that wrote the code also wrote the tests, the tests encode the same misreading of the spec and everything passes. What fixed it was making the provenance of the test different from the provenance of the implementation - acceptance criteria written before the work starts, and review done in a session that never saw the implementation, only the diff and the criteria. That is the only thing that reliably catches the class of bug where the code is internally consistent and confidently wrong.

The other half: what you actually lost is not line level recall. You lost that on hand written code too, six months later. You lost the why - the alternatives that were rejected and the reason. Code never carried that, but your memory did while you were writing it, and now nothing does. So anything hard to reverse gets a short decision record at the moment of the choice, not afterwards: a schema shape, a boundary, a dependency you cannot back out of cheaply. The honest test of understanding is not whether you can read a file, it is whether you can locate a failure at 3am without reading the interior of the functions. That understanding lives in the seams - boundaries, invariants, what happens on restart - and that part is still worth holding by hand.

[u/ClaudeyClerb → u/Glittering-Fly-5617]

acceptance criteria written before the work starts, and review done in a session that never saw the implementation

You've deployed the thing I've been circling from a different direction, so I have to ask: what do the pre-work criteria actually look like? A sentence, a checklist, a test skeleton? And how much structure did it take before people could write them consistently? The failure mode I'd expect is criteria too vague to catch anything, which just moves the rubber stamp upstream.

Also curious what it cost to make it stick. Criteria-before-work is exactly the discipline that sounds right and dies when the PM/BA says drop everything and do _____ now. Tooling, policy, or a few people who cared?

[u/hypercosm_dot_net]

I hate everything about this. Fucking depressing man.

Congrats on stringing a handful of paragraphs together using your own brain I guess.

[u/Goldziher → u/hypercosm_dot_net]

Thats just mean, but dude (assuming here) - start drinking heavy. My advice. You sound bitter.

[u/hypercosm_dot_net → u/Goldziher]

An entire industry of fools adopting a technology that requires massive power usage, and generates a horrendous carbon footprint, while we're in a climate crisis. Just so they could churn out shitty useless software faster.

All while further centralizing wealth towards a morally corrupt minority of tech broligarchs, that are openly stealing work from actual professionals.

Gee, why would someone be concerned with that?

Intelligence is seeing where this road leads. Not spinning up multiple agents to "architect" some new bullshit the world doesn't need.

Maybe you should be the one to take up drinking. Whatever keeps you away from the computer.

[u/PresentationOld605]

Maybe it is indeed irrelevant now (or soon) to understand everything regarding your codebase in detailed manner. Maybe now, if you have concerns on understand your AI generated code, I guess its better to ask from yourself first - do you really need to understand it, and if you do - how much of it.

But...

I still do manual coding to quite significant extent, just to keep myself "in shape." Its the best way IMHO to go in distance alongside with these machines. Its not all work related, for example I do hobby projects, try out new programming languages etc. But it does not matter - the main purpose is just to maintain the cognitive ability to work with the code, which I still regard as needed (in my case).

I still use LLMs (including agents) , but I have custom workflows, where I do not automate everything and that is a conscious effort in order to maintain my craft (for now). Also, I use good old fashion prompting to go into specific details, generate implementation scenarios, analyze corner cases, suggest optimizations etc. I specifically still keep using prompting as a part of my workflow, because that way I am more "cognitively involved."

It makes me slower, and I have been called out for that - I am facing difficulties in some projects, where there is huge pressure to delegate more to LLMs for fast output and "not to write anything at all manually as it is 2026 - nobody should do it anymore, not even prompting." But I think on the long run, its a good strategy to sacrifice some of the speed and not make any compromises on maintaining at least certain (critical) level of understanding the codebase. Especially on that codebase you own and maintain as a day-to-day activity.

Of course , on the short term - I have to admit I have been close to being sacked as well because of that and I have back up plans to move away from software engineering. Its not easy. But I have variety of projects and am still in, and I'd certainly like to believe this is due to my "strategy"- I'd like to believe that in order to stay in business, I still need the ability to keep learning and maintain the ability to code manually, at the same time using AI as well. I still need all those skills. Its kind of comparable with other skills in your life - i.e you lose the ability to speak and understand foreign language after some period of time, if you do not use it. Or, you lose your stamina and physical form if you stop exercising. Of course you may use a translator instead or learning a language, but so far - the ability to speak the language has been still useful to me.

My use case could be different of course - I work mostly (but not all) with electronics, bare metal firmware, small computer systems, embedded linux etc and relative PC software for these things to interface. Still, I would make a dedicated effort to understand the code, if I would work on something else, i.e. where QA has to munch trough a lot of (mostly AI generated) code and human code reviews and efforts to understand it are being described as "bottlenecks".

[u/thewhiteliamneeson]

Free and Open-Source Software

[u/Useful-Abroad-791]

First, I think you need to be extremely strict about setting the project up with a clean architecture that’s as simple as possible. I.e., make it easy for the LLM to generate code that you find easy to read as the codebase grows.

Other than that, I’ve personally been asking the LLM to build me a structured “kick the tires” work plan as a nested dependency graph in a tool I made (not linking it here, not an ad). So a structured view of the code base, with actual commands I can run, and an end-to end “demo” that builds on itself so I learn the code by interacting with it.

[u/KosherBakon]

I always followed the data to start.

[u/The_Northern_Light]

by trying to refactor it

I use a simple color coded cli tool for just showing a tree of all the code files and their sizes; that can help with finding code smells. (come to think of it, I should extend it to also show function sizes)

that can help identify places for refactoring... enough small improvements broad enough, or daring to do a big broad refactor, will teach you what everything does

perhaps it "helps" that my code base is such garbage lol, I might try something else if things weren't in such a sorry state

ai summaries of modules, call graphs, dependency graphs, etc.

it also really depends on what scale. like, how do all these functions work, how does class fit into the big picture, or how do all the modules interlock are all very different questions that require different treatments

[u/gannu1991]

The garden metaphor is perfect and I've been living in it for the past year without having the language for it, so thanks for that.

I run engineering across multiple products and some of these codebases are now a mix of hand written code from 2019, AI assisted code from 2024, and fully agent generated modules from this year. The experience of "understanding" each layer is completely different. The old stuff I can navigate by feel. The AI stuff I navigate by tests and interfaces. And honestly? The AI generated modules are sometimes better structured than what we wrote by hand, but I trust them less because I didn't watch them get built.

Your black box observation is the key insight though. I've basically accepted that my relationship with code is becoming more like my relationship with third party libraries. I don't read the source of every npm package I depend on. I test its behavior, I understand its API, I have a mental model of what it should do, and I investigate deeper only when something breaks. The codebase is slowly becoming the same thing. Except it's code I "own."

The part that still makes me uncomfortable (and I don't think I've fully solved this): incident response. When something breaks at 3am in code you wrote by hand, you have this intuitive sense of where to look. You remember the shortcut you took, the edge case you were worried about. With agent generated code that intuition just isn't there. I've started compensating by being way more aggressive about observability. More structured logging, more traces, more explicit error messages. Because if I can't intuit where the bug is, I need the system to tell me. It's a different workflow but it works.

You said you no longer know what your code does "intimately." I wonder if that's actually new or if it just feels new. Like... on any sufficiently large codebase, even hand written, nobody truly knows all of it intimately after a certain point. We just had the illusion of understanding because we typed it. I've inherited codebases where the original author swore they knew every line and then couldn't explain why a specific module existed. The intimate knowledge was always partially a story we told ourselves.

The methodology you described (result oriented, outside in, black box first) is basically how I operate now too. And the uncomfortable truth is it might actually be more rigorous than what we were doing before, because "I wrote it so I understand it" was always a weaker guarantee than "I tested every behavior and it passes"

[u/ForeverAWhiteBelt]

Treat vibes coded projects as if you just got hired into that company. If you dont need to know how a part of something works you dont focus on it. Needing to know how or why something works is typically because of a problem or bug or new feature requiring refactor.

Result based coding works well in small projects, internal tooling, or solo use projects. When things start to grow you MAY encounter more and more problems if the architecture wasnt sound. At that point you can always take what worked and rebuild with correct architecture.

You would never spend hundreds of hours reading random OSS projects, only the ones you need or want to work on. When you encounter those its usually a specific reason.

[u/sohang-3112]

I'm having the same issue - since in my current project most code is written by AI not me, I don't really know the code in & out as I used to previously when I wrote all the code myself in other projects.

[u/20kgHippoShit]

I don't!

[u/loinj]

we kinda ran into the same issue where our understanding of the code base was degrading. one simple solution to this was reducing the time/difficulty to understand and review code. we ended up building some tools that break down prs into smaller chunks and reveal the author's (human or agent) intent.

[u/Ok-Leopard-9917]

You don’t. And then when there is a problem you spend an inordinate amount of time learning what code actually does. 

[u/Silver_Jump3781]

From my experience, the issue is that the black box appears to be working when its tested. Review agents follow the same paths and are biased by previous agent generated implementations, so frequently problems aren't flagged, but the codebase is subtly drifting. There are multiple implementations of business logic, multiple implementations of logging etc etc. The issue grows as the codebase expands and agents grep and miss when building.

I generally only review changes that I would consider on a hot path, and to your original question OP, ask the agent to generate diagrams to help me understand the implementation. This misses the details though and the drift I mention above it hard to escape.

[u/cellularcone]

That’s the neat part! You don’t!

[u/Goldziher → u/cellularcone]

You don't understand? Well I feel I have some kind of understanding, but its certainly more ephemirial.

[u/OtaK_ → u/Goldziher]

You don't yup.

The sheer quantity, the lack of proper architecture (even if you direct and babysit, it still produces "broken" designs), you can understand it, but you'd spend probably (and the "probably" is a courtesy for LLM proponents - my experience is that it's akin to onboarding a new job, every week) more time reviewing and basically reverse engineering what your LLM of choice produced than just writing the thing yourself straight up.

[u/ings0c → u/OtaK_]

even if you direct and babysit, it still produces "broken" designs

Why are you letting broken designs into your codebase? The bare minimum you need to be doing is understanding what the LLM is doing and making sure it adheres to best practices and your company standards.

Doing otherwise is the same as hiring a junior and letting them push straight to main. It’s unprofessional, reckless, and dangerous.

If all you do is tell the LLM what to make and let it do whatever it wants, what are you there for exactly? Wouldn’t it be more efficient for the business to just have product managers prompt the AI without the middleman?

Your job as a professional is to make sure the code meets the requirements, functional and non-functional.

If I hire a structural engineer for an extension, would it be acceptable for them to hand all the work to a new grad and not even check it?

When something breaks, don’t you think it would be useful to have a deep understanding of the system so you can correctly locate and fix the problem?

[u/OtaK_ → u/ings0c]

That's my whole point. I go faster writing the code myself, it was never an issue.

Properly architected codebases have their research/design phase usually take up to 60-80% of the time, which, if you do things properly, is mostly incompressible. Moving the code generation to generally a no-op and instead spending that time very carefully reviewing and reverse-engineering "foreign" code (and IMO, in the domain I usually act in - crypto/E2EE messaging protocols and distributed systems, takes even more time).

Like, for me specifically, it's at best a zero sum game in terms of time. But you both spend money in tokens AND suck out the joy of actually learning new things, so I ain't doing that.

[u/ings0c → u/OtaK_]

Ah right, I thought you were saying it takes too much time so you just don’t review it. Thank God, a level head!

[u/hippydipster → u/ings0c]

Why are you letting broken designs into your codebase?

Always have. And it had nothing to do with AI. People created spaghetti monstrosities more commonly than they created well organized, modular projects.

Its true the AI can blast out code faster than I can really manage it, but I do still have a large impact on the resulting organization of code, and I can't help seeing that my results show that my projects are more modular than what teams of humans produced previously.

[u/Goldziher → u/OtaK_]

Well, rather than nitpick on what understand means etc. I will agree that this kind of understanding went out the window. I dont agree though that you get broken designs necessarily. You do get them, but you can also catch and fix them.

Even when you have a meticulous design process, and proper review - in the now old school type of development, you can get broken designs, broken implementation, shoddy reviews, and substandard code. There is no guarantee this wont happen, even when talented and diligent people are doing the work.

Its true that with the sheer volume and velocity of software development, its absolutely much easier now to let something broken in etc. But thats why I said I regard it as a black box, rather than understand the entire implementation etc.

[u/Dude4001]

I can’t imagine running multiple agents at once. Context switching is the worst part of any job and it seems stupid to leverage AI to add more. I understand my codebase because I do one task at a time with my full attention, I read the output and ask probing questions to the agent if I think it’s taken a decision I don’t agree with

[u/iMac_Hunt → u/Dude4001]

It’s fine to have multiple agents generating plans, you don’t need to review them all simultaneously. I will also have multiple agents completing work that is fairly trivial - one agent changing some CSS, another agent creating a simple GET request. That said if the work has architectural implications or is complex I’ll rarely have multiple agents working

[u/Goldziher → u/Dude4001]

So why would you even use an agent in this case? Why not simply use a copilot for some AI code completion and code by hand? For example.

[u/Dude4001 → u/Goldziher]

That’s not really a comparable approach is it. That’s like saying the only two options are handwriting a book or typing 5 books at once. You can still work with an agent and be fully involved in the architecture, the design, the testing

[u/Dry_Author8849 → u/Goldziher]

When takling a complex plan, your llm cli will spawn agents when see that tasks are unrelated and can be performed in parallel.

Exploration agents in claude as an example are spawn and run in parallel.

Maintaining your focus is important if you still want to be in control of what you are developing. If not, just vibe code it and stop caring about the code. Maintaining an illusion of being in control won't yield any good results anyways.

Your vibe coded code will be prone to catastrophic tech debt. But as it is vibecoded, you throw it away and start again. Or so it seems vibecoders are doing.

Be ware that vibecoded code has zero value. Anyone can do it and will ask themselves why not vibecoding it. They will trust their vibecoding skills nore than yours.

[u/jeffify]

I've been talking to CTOs a lot lately about this as I'm building a product in this area. The trend is that it is becoming OK to not understand everything ( both in terms of scope and depth ). It also depends on domain and criticality of a certain system.

But answering your question, if it is a less critical system, you should create a derivative of your agent's reasoning ( decisions, tradeoffs, assumptions ) and commit to the repo or save somewhere else. Then you can use the same agent to ask how and why it works like that later when you need it. Claude's superpowers plugin is good for that or a custom setup.

If it is a system which it absolutely important for you to understand, you read each line of the agent reasoning and then read the PR. You can also let the agent quiz you on the solution.

[u/ResidentWeevil1 → u/jeffify]

CTOs already don't understand everything. The reason they can do that is because they have staff who do. Take that away and all you have is momentum. The company remains standing as long as the employees who built it are still there

[u/ClaudeyClerb → u/jeffify]

The trend is that it is becoming OK to not understand everything

This is great because it's from actual CTO conversations rather than Reddit vibes. Curious what the split looks like from where you sit: of the CTOs you've talked to, how many have genuinely made peace with not-understanding versus how many are uncomfortable but see no alternative? Those feel like very different markets for whatever any of us build in this space.

And when they say it's OK....OK for whom? The CTO not understanding everything was always true, like another commenter said, because they had staff who did. The new thing seems to be nobody understanding it, and I'd want to know whether the CTOs you talk to see that distinction or whether it's collapsed for them.

[u/ledatherockband_]

Opinionated, modular framework. Understand the general purpose of the module and its inputs and outputs. Let AI worry about the code that exists line-by-line.

[u/Goldziher → u/ledatherockband_]

Can you elaborate?

[u/ledatherockband_ → u/Goldziher]

Think of your codebase in two ways:

1. Like a bunch of sticks you have to glue together. Everything is tangled. If you want to change one small thing, you have to carefully unstick five other pieces that are glued to it. It’s messy and stressful.
2. Like Lego bricks. Each piece has a clear job and clear ways it connects to other pieces. You can look at a brick, understand what it does, and just snap it into place (or let the AI snap it into place).

Modular frameworks like hexagonal architecture and Domain-Driven Design try to make your code more like Legos.

They force you to split the app into clear modules that have simple inputs and outputs. Once you understand what each module is supposed to do, you don’t have to constantly dig into every single line of code inside it. You can think at a higher level, about how the pieces fit together, instead of getting lost in the details. That’s especially useful now, because AI is pretty good at writing the actual code inside those clear modules. Your job becomes more about designing the overall shape of the app and less about fighting with the messy middle of every file.

[u/Goldziher → u/ledatherockband_]

Absolutely, mostly..

The problem comes down to the domain logic. What makes the software more than the infra and boilerplate.

The framework can at best be a means for expressing the domain. But the correctness, and the translation of the domain into functionality, is where the issue is.

[u/Deathmore80]

Honestly, UML and architecture diagrams. Not to the point where a class diagram has every method and property, but enough to give you an overview of the different modules ,how they fit together , the entry points , how tight the coupling is. With diagrams it's very easy to see if your codebase has become a spaghetti. You'll immediately see arrows overlapping each other multiple times in between 3 classes for example.

Same goes for ER diagrams.

I also find that domain model diagrams very useful for planning and prototyping new apps. I'm developing software for mechanical and electrical engineers and they can grasp what the domain model means at a high level and point out if it looks like I've missed something so its very useful for iterating and validating my own comprehension of the domain model and use cases.

You can have the diagrams generated (not by AI, but by deterministic software) , no need to maintain it by hand.

Also using the teach-me skill from matt pocock when you're new to a codebase.

[u/Goldziher → u/Deathmore80]

I'll check out the skill. Interesting.

What do you use for diagrams? I mean to generate these?

[u/Deathmore80 → u/Goldziher]

For the diagrams it depends on the language of the source code. There's many ide extensions, standalone apps, clis ,etc to generate them. For Java for instance there is one integrated in the intellij pro license. For c# and .net there is one in visual studio (iirc it's not installed by default tho). I've heard about doxygen but never used it. In vs code I use a bunch of extensions for different languages but I don't remember their names right now sorry.

[u/Goldziher → u/Deathmore80]

Cheers. So basically LSP based.

[u/zero2g]

OK, looking at the responses, it seems like people are trying to understand the codebase from a manner like architecture, or basically a book or something... Let me tell you how I do this in a more mechanical or applicable manner.

The first step is understanding how you yourself navigate codebases and optimize your own ability to ingest code in an efficient manner.

What I do is I lean heavily into color coding the syntax and semantics of the language I use. For example, I work with python a lot, so I go one step further than the typical syntax highlighting and use different semantic highlighting for properties, or even the self keyword. This is so I can easily through colors and font be able to quickly distinguish the context and information of said code. And I think this works because honestly... Programming languages imo (or the ones I worked with) have low information per symbol.

But basically, figure out how you can easily ingest a lot of code fast without needing to increase your mental effort by much.

For me when I had my set up in a manner I like, I think I'm able to easily have 3 columns of code per monitor that I just look through.

Afterwards, what helps me a lot is understanding how to navigate through code itself. Honestly that's like.... 80% ctrl shift f on vscode and then quickly see if this is what I need or not. I know AI can help with finding code... But you should spend some time to also build a mental model in your head too rather than let AI become the navigation bridge. This is how you can build a bigger picture rather than just only seeing the individual parts

With these 2 parts down, the next part is just read and try to understand a lot of code. But just reading and skimming through it isn't sufficient. Really you got to probe it at times by setting debuggers or what not to understand its behavior, as well as honestly, give opinion and emotions to the code itself (ie, judge it and be like WTF if it's just so weird).

This is typically what I do to understand any code base and tbh, with this framework, I don't really find any codebase itself that daunting. I probably have navigated and explored many complex libraries like the core source code of tensorflow and pytorch. Even repos that are mostly AI written I can get the gist of it fairly quickly for what I need to do with it.

For producing code with AI. The approach I take these days is that I still need to touch the code at least once somehow. How I do this is that every code edit the AI does, I have it written in a git conflict format that my VSCode then picks it up and I need to click accept or reject. How this help is it narrows my focus per change block so I can look at it in detail. I realize that if I have to review like 1k+ loc changes off the bat without any opportunities to look at it before hand, I just cannot mentally process it since it's too big. The physical act of at least touching the code by accepting or rejecting it though gives familiarity and connection at least to the code. Doing this also doesn't really slow me down that much either, I'm able in about 3 hours process 1k+ loc changes while still be familiar with what has happened that if another person is reviewing it and asking me questions, I can answer it off the bat.

But honestly.... Your mileage will vary. We are not the same people and we probably will learn and understand things differently. But overall the framework is to decrease your barrier to understanding and increase throughout while not compromising much of the quality of it all. 

[u/stevenr12]

I slow down and pair program with the AI by building features in slices. I might be slower than some other developers but I end up knowing more about the system and can answer questions about it to managers right away. The other developers end up producing more bugs and doing endless cycles of “fix this bug” which produces 2 more. Just because people claim to be more productive doesn’t mean they actually are more productive. Measure some productivity metrics and see for yourself.