| ▲ | kombookcha a day ago |
| I'm with you and I think a variety of companies are going to learn this in a highly expensive way over the next few years. Once your shared mental model of how the codebase works is gone it seems practically impossible to get it back. Like what would you even do if you change your mind in 3 years - sit everyone down to meticulously comb through all the AI code until they start to get how it works? Getting back to a similar level of understanding seems like it would take ages and effectively locks you into the new solution in a way that cannot be feasibly reversed. |
|
| ▲ | stackbutterflow a day ago | parent | next [-] |
| How is this different from when you join a company and learn your corner of the codebase? In a sufficiently large enough codebase no one had the whole mental model in their head even before AI. What you did was find and ask that one person who knew enough about some part of the project to answer your questions. Now you can ask a model. |
| |
| ▲ | theLiminator a day ago | parent | next [-] | | I believe institutional knowledge used to work on a ship of Theseus model. It's going to be completely different going forward. | |
| ▲ | robswc 21 hours ago | parent | prev | next [-] | | > How is this different from when you join a company and learn your corner of the codebase? Because most AI generated code is incredibly verbose and noisy. This can be true for any codebase, but it is especially egregious in AI codebases. It is hard to prevent that by just saying "be concise" because knowing exactly where to be concise is the measure of true skill/intelligence. Every time I have success with AI coding, it is because whatever I need done can work as a pure function, where the probability I have to return to it is very very low. Making sense of a codebase is like putting together a puzzle. A purely AI generated codebase is like trying to put it together without a picture on the pieces. | |
| ▲ | port11 13 hours ago | parent | prev [-] | | This is more like ALL the developers have just joined a company where no other devs work and can pass along institutional knowledge. You know, the thing that makes all that complexity wieldy. |
|
|
| ▲ | throwaway_new_1 19 hours ago | parent | prev | next [-] |
| >change your mind in 3 years I think if people change their mind in six months, let alone 3 years, they would just rewrite it again with something different, or just double down on the AI rewrite to rewrite the rewrite to fix the gaps and so on. It's a rabbit hole. What people are completely missing with AI is that when a company/someone makes the decision (which is most these days) to go heavily on the AI route, they are probably going to keep going that way. We don't really know what’s the right balance of AI and People right now. My personal take would be to leverage AI to fix and improve what already exists in a maintainable way and wait for others to experiment with going heavily AI. It's worked great for Apple who is generally years behind in a lot of things because they wait it out for others to experiment with things. |
|
| ▲ | beardbandit 8 hours ago | parent | prev | next [-] |
| I don’t think this changes just because you don’t do a rewrite. This is happening already as engineering leans more on AI tools in our own company. Things ship and change way too fast and the changes are massive. |
|
| ▲ | SoftTalker a day ago | parent | prev | next [-] |
| Also Reflections on Trusting Trust taken to a whole new level. |
|
| ▲ | moralestapia a day ago | parent | prev | next [-] |
| I'd say they're betting on AI getting good and reliable enough to not have to go back to the "old" practice. |
| |
|
| ▲ | CamperBob2 a day ago | parent | prev [-] |
| Once your shared mental model of how the codebase works is gone it seems practically impossible to get it back. You won't want it back. How much time do you spend surfing through your .o or .obj files today? |
| |
| ▲ | fao_ a day ago | parent | next [-] | | Back in the day you'd read reference manuals which would tell you about the library, they might be hand written or a listing of the addresses and names. Today in the modern day, we still use reference manuals for writing C and C++. It's just encoded in websites, e.g. https://pubs.opengroup.org/onlinepubs/9699919799/functions/c... and https://en.cppreference.com/ But there are still libraries where familiarising yourself with the header is important, for example stb's libraries. man(1) and GNU Info were both invented to be computer-stored reference manuals, and indeed to this day you can type `man 3p open` to get the POSIX documentation of the system up in front of you. I am not aware of many codebases that have manuals as complete as this, but back in the day (1970s-era to the 1990s-era) there would be internal documentation written as par of course for the specification created by the waterfall model of development. Post-2010 companies are very lackadaisical about documenting internal interfaces and libraries because they come from startup cultures where "move fast and break things" is the name of the game. | |
| ▲ | dieortin 13 hours ago | parent | prev [-] | | > How much time do you spend surfing through your .o or .obj files today? Those are not the source of truth for the application logic. But the higher level code is. The application code describes the behavior of the program and the compiler translates it into a different representation following a set of known, deterministic rules. This is unlike an LLM producing code from a prompt, which is why the source code is still the source of truth, and not a bunch of prompts. | | |
| ▲ | CamperBob2 6 hours ago | parent [-] | | Determinism is something you'll have to give up if you want to stay employed, I'm afraid. The solution, as usual in engineering, is negative feedback. Unfortunately, many people around here think that means "Shoot the messenger." |
|
|
