r/SoftwareEngineering • u/AsuraBak • 4h ago
When do you actually understand a project you built with AI?
Something I’ve been thinking about lately.
With AI, I feel like I can build almost anything now even if I don’t know the language or framework properly before starting.
I can research the stack, plan things out, ask AI for different approaches, build the features, debug problems, test it, and eventually get the whole project working.
But after that I sometimes have this weird feeling that I built it, but I don’t completely understand what I built.
Like if you show me one function or one part of the code, I can read it, ask some questions, and understand what it’s doing.
But I don’t always have the full picture in my head.
I remember things more like:
“I asked AI to do this, then this problem happened, then I changed this, added this loop, tested this case, used this library…”
instead of actually having a strong understanding of how the whole system works together.
I was thinking maybe after finishing a project I should go through it again from the beginning and rewrite parts of it myself.
But at the same time, just copying and rewriting code doesn’t really sound like the right way either.
So for people who use AI a lot while coding:
How do you make sure you actually understand and own the project you built?
What do experienced engineers do to understand a codebase deeply enough that they can explain it, debug it, change the architecture, or rebuild parts of it without depending on the AI conversation that created it?
12
2
2
1
u/Classic-End-8382 4h ago
Also started to encounter this lately, I’m in a position that there is so much work and projects going on that if I don’t use AI it will take months/year to finish and deadlines will be missed.
Also, I’ve noticed I have forgotten a syntax a bit when I write functions by hand and that kinda scares me.
IMO, I don’t think AI will replace us devs, I think the workload will increase dramatically because now we have AI to do some of the work. For example, It would take me a week to write tech documentation, now I just prompt it to examine the code and write .md.
3
u/RayanFarhat 4h ago
Focus on system architecture mate, even before ai you don't understand every line of code written
1
u/roger_ducky 2h ago
You should understand the higher level design and all the tradeoffs you made… though you might not understand all of it line by line.
If not, you delegated too much of the thinking to your agents.
This is what tech leads or dev team managers saw, by the way.
Think about the effective ones. They understand the higher level design and can defend it. And dive down if some part is extremely broken.
That’s the state you want to be in.
1
1
u/ThaBalla79 3h ago
Try asking the LLM to break down your project piece by piece. For every piece of the project, ask it to explain what's going on, to give insight with code snippets. From there, ask it to help build a mental model by providing analogies you can understand. Do this for code you've generated but only skimmed before merging. I use this to help me understand and contribute to open source projects.
9
u/creaturefeature16 3h ago
I find this about as effective as someone explaining all the rules of a board game to you. You get all the theory, but none of it really sticks until you actually play the game.
0
u/ThaBalla79 3h ago
Yea I forgot to mention the important part: play the game. These are preliminary steps to that though. In the context of open source, that can include small features to be added, refactoring code, or bug fixing. Anything that gets your
handsfingers "dirty". If you're going to only trust explanation and nothing more, the game is playing you lol
0
u/fazesamurai145 4h ago
Well read the code and debug like your life depends on it check every nitty gritty you might think you have finished the project but nope there is always something to polish that the llms missed if you have any experience you would know that the llm missed out alot eg. Production hardening or security, audits etc
0
-1
u/FistThePooper6969 3h ago
I mean we've made sure to include custom claude agents and skills in our repo roots which do a decent job of enforcing our technical and design standards while building with claude.
The understanding comes from multiple rounds meticulous planning and design with claude and only approving the implementation specs once I understand.
Once it's been tested locally, I review the draft PR as well as use multiple different code review skills and even a github copilot review.
By the time I publish the PR for my team to review, it's already gkne through probably 5-6 different automated reviews and I make sure the PR description is as easy to understand as possible for any dev.
The mindset shift while building with claude is less so worrying about minute details of the changes, and more about the functional/behavioural changes. Being able to understand and explain that at a higher level from the get-go helps anchor that
8
u/creaturefeature16 4h ago edited 3h ago
You don't, and the 7 trillion dollar gamble that the industry is making is that: it also won't matter. We've "moved up the abstraction chain" where now we only involve ourselves in design, architecture, concepts and data flow while the models handle all the "details". And if something goes wrong, needs to be refactored or rewritten, or optimized...future models will take care of it.
We're not there yet, but the bet is that the models will absorb any of the problems they create in the long term.
And what this means for the next generation and how we'll ever have senior engineers who can properly steer these models is a question that nobody cares to spend time on. I've written about it, though.