> There is so much fun, beauty and pleasure in writing code by hand. You can still handcraft code. Just don’t expect this to be your job. This is your passion.

Can people keep a good mental model of the repo without writing code? I always feel like I lose my thoughts if I let an LLM do it for me. I totally get that LLMs can do stuff faster and (Given the right context) sometimes keep better track of this than humans can.

Even musicians had to go digital, but that doesn't mean people stopped playing raw instruments. Will company culture shift towards one senior that has the context + 7 LLMs that work for him? is that where we're heading towards?

Based on my own experience as someone taking the journey from junior developer to CTO of a mid sized company: No, you can't keep that mental model for long.

At first I would write code, which involves a ton of reading and _truly_ understanding code written by others.

Then I would increasingly spend my (technical) time on code reviews. At some point I lost a lot of my intuition about the system, and proper reviews took a long time, I ended up delegating all of that.

Finally, I would mainly talk to middle managers and join high level conversations. I'd still have a high level idea about how everything worked, but kinda lost my ability to challenge what our technical people told me. I made sure to carve out some time to try and stay on top, but I got really rusty.

This was over a time frame of perhaps two or three years. Since then, I've made changes, working at lower levels. I think I got my mojo back, but it took another one or two years of spending ~50% of my day programming.

Other people will be different, but that's how it was for me. To truly understand and memorise something, I need to struggle with it personally. And truly understanding things helps with a lot of higher level work.

But as with anything that takes a few years to materialise, you usually notice it quite a while after the damage is done. Long feedback cycles (like for business decisions, investments into code quality etc) are the root of all evil, IMHO.

I've found that the best aid to keeping a mental model of the structure of a project is to document it well using Literate Programming:

http://literateprogramming.com/

which then affords a PDF w/ a ToC, indices, and sidebars and other navigational aids all hyperlinked so as to make moving through the code and its documentation quick and fluid.

Then, when I arrive at the section of code which needs to be updated, the documentation and reasoning about its current state is right there.

Not sure if this scales up to multiple developers though....

They're currently still at the "create a million branches until the tests pass" phase. Once they are more capable of genuine design, refactoring, and maintenance, their code will arguably be more readable than code written by humans, as they'll be more able and more inclined to refactor on the fly, rather than letting things bitrot the way we do. They'll be better able to refactor without regressions, refactor across services, all without disrupting feature development and parallel work (because they're fast enough that work will become more serialized), and remembering to update documentation accordingly.

Unless there's a wall getting AI to plan, design, and refactor better than it does now.

> Can people keep a good mental model of the repo without writing code?

Probably not.

In my experience working on large SW, you can't do interesting stuff without talking to the people who wrote the code that your interesting stuff will touch. And the reason you talk to those people is to get their visceral feel for how their code will be affected.

> Can people keep a good mental model of the repo without writing code?

This is the age-old problem of legacy codebases. The intentions and understanding of the original authors (the "theory of the program"[0]) are incredibly valuable, and codebases have always started to decline and gain unnecessary complexity when those intentions are lost.

Now every codebase is a legacy codebase. It remains to be seen if AI will be better at understanding the intentions behind another AI's creation than humans are at understanding the work of other humans.

Anyway, reading and correcting AI code is a huge part of my job now. I hate it, but I accept it. I have to read every line of code to catch crazy things like a function replicated from a library that the project already uses, randomly added to the end of a code file. Errors that get swallowed. Tautological tests. "You're right!" says the AI, over and over again. And in the end I'm responsible as the author, the person who supposedly understands it, even though I don't have the advantage of having written it.

[0] Programming as Theory Building, Peter Naur. https://pages.cs.wisc.edu/~remzi/Naur.pdf

Eventually AI will get so good that why do we even need context? That’s the direction we are heading towards.

Digitization of music has a wall. There was an aspect of intelligence that simply digitizing things can’t replace. AI is rapidly climbing over that wall.

You're still in charge, don't let LLMs do whatever they want.

Software engineering concerns itself with the industrial production of software, at scale. Much like chemical engineering for chemicals. Artisanal handcrafted software is kind of outside the scope of the discipline of software engineering.

AI generation and assistance is such an accelerant to industrial software production that it is now a must for serious software engineering. If you need to evolve your mental model of the code base, ask your LLM. It's at least as good an accelerant of understanding existing code as it is of writing new code—maybe better.