I've spent entire nights building something with AI, gotten a bunch of features working, and then realized I couldn't really explain half of what I...
For further actions, you may consider blocking this person and/or reporting abuse
Your Slate example sent me to the repo, and the revision counter is right there in
document.rs, pinned down by a test callededits_during_a_save_keep_the_document_dirty. A test is a nice way to remember the problem even after you've forgotten the code.In the spirit of "the problem you didn't know existed", that same save path has one more: what's on disk if the app dies halfway through the write?
write_textcallsstd::fs::write, which empties the file before writing, so a crash or power cut at the wrong moment leaves half a file. The funny part is that the fix is already in your repo:storage.rshaswrite_atomic(temp file, then rename) for the settings JSON. So right now your settings are better protected than your documents.It's not a free swap for user files, though. Renaming over the original replaces it, so permissions, symlinks and hard links need care, and surviving a power cut also needs an fsync before the rename. That trade-off is why Vim has a whole option for it (
backupcopy).To answer your question: mine is a cousin of your save race. I once watched an API confirm a delete, then return the deleted item on the very next read. "The write succeeded" and "everyone can see it" turned out to be two different moments, and I've looked for that gap ever since.
Thank you so much for taking the time to actually dig through my repo. I genuinely appreciate comments like this. It’s one thing to have someone read a post, but when someone actually goes looking through the code and points out something I hadn’t considered, that’s incredibly valuable to me.
And you’re absolutely right, that’s another interesting edge case I hadn’t really thought about. Especially since I already have an atomic write implementation for the settings. Now you’ve given me something else to investigate.
I think that’s one of my favorite things about sharing projects publicly. I’m still learning, and getting feedback from people who take the time to actually understand what I’ve built is such a great part of that.
Also, your API delete example is a perfect example of what I was trying to get at in the post. It’s those little situations you run into that end up teaching you something you remember long after you’ve forgotten the actual code.
Glad it was useful! Honestly, it works both ways. I'm always curious to see how other people tackle the problems I'm facing myself. It's enriching, and sometimes reassuring too, when someone else lands on the same idea I had.
The save example is a great one, because the lesson isn't the code, it's the shape: something can change between when an operation starts and when it finishes. Once you've seen it once you spot it everywhere, like a fetch that resolves after the user already navigated away, or a retry that lands after the first attempt succeeded.
What helps me with the "three days later I'm staring at it like I've never seen it" part: when I finally understand why a line is the way it is, I write that why down as a short note on that line, in my own words. Not the explanation the AI gave me, but the problem it solves. Next time I open the file the note is there. And if I can't write it, that's usually the sign I understood the explanation, not the code.
(Disclosure: I build Reado, an IDE where notes like that live on the lines, so I'm biased toward this habit.)
I really like that. Especially the part about writing down the problem the code solves rather than just explaining what the code does. I think that's such an important distinction, and honestly, something I should probably make more of a habit of doing myself.
And you're absolutely right about recognizing the same problems in completely different situations. That's exactly the kind of learning I was trying to get at with this post. Once you understand why something matters, you start noticing it in places you wouldn't have thought to look before.
Also, Reado sounds interesting. I love seeing the different approaches to problems like this, especially when they end up building their own tools to solve them. I can definitely relate to that part.
Thanks, Jessica. The "why" note pays off most months later, when whoever reads the code (often me) has forgotten the conversation that produced it. It's your point again: you remember the problem, so write the problem down right where the code is.
Your point about predicting a change before running it suggests a useful follow-up a few days later: try a small variation without reopening the original explanation. With Slate, that might be asking what the unsaved indicator should show when two saves finish in the opposite order. Explaining the first example can lean on memory; predicting a variation asks whether the underlying model transfers. Would that feel like a useful learning check, or turn a hobby project into homework?
I actually really like that idea. I think being able to apply what you’ve learned to a slightly different situation is probably a much better test of whether you really understand something than just being able to explain the original example.
And I think it could be a useful learning check, as long as I’m not doing it for absolutely everything.
For me, a lot of the fun of building things is getting curious about something and going down those little rabbit holes. Sometimes I’ll spend hours figuring out something that probably could have been done in a few minutes, just because I want to understand it better.
But other times I just want to finish what I’m working on and move on.
I think the trick is knowing when something is worth digging into a little deeper. If it’s a concept I’m likely to run into again, especially something I didn’t understand before, then trying a variation a few days later sounds like a great way to see if anything actually stuck.
Thanks for the suggestion! I might have to give that a try.
The 'not for absolutely everything' limit makes sense; otherwise a learning check becomes another obligation attached to finishing a project. I'd reserve it for a concept that changed a design decision or caused a bug, where forgetting has a real future cost. For a one-off formatting task, getting it done can be the whole goal. Your distinction between following curiosity and choosing to finish seems like a better guide than a fixed quota of exercises.
“The solution is sitting right there in my project, but I might not even recognize the same problem” really captures the gap this post is exploring. The save-tracking example makes it concrete: remembering the implementation isn’t the same as knowing which question to ask when state changes during an operation. I especially appreciate that you don’t turn learning into a requirement to struggle through everything manually. The goal isn’t to earn every line of code—it’s to understand the decisions you’ll eventually have to revisit. Honest, practical, and refreshingly free of the usual “AI is cheating” versus “understanding no longer matters” extremes.
Thank you! I'm really glad that came across, because that's exactly what I was hoping to get at with this post.
I love building with AI, and I certainly don't think we need to struggle through every little thing just to prove we're learning something. But I also don't want to get so comfortable having things done for me that I stop asking questions or understanding the decisions being made.
And I agree, I think the conversation around AI and coding gets pushed into those two extremes way too often. There's a whole lot of middle ground where we can take advantage of these tools while still learning and improving as developers.
The line about remembering the problem rather than the code really lands. Mine came from building a recommendation app with embeddings. Every item has an LLM-written description and a vector, and both carry a version number. That looks like over-engineering until you change the prompt or the embedding model and realise half your data was made one way and half another, with nothing in the rows telling you which. It’s a cousin of your save-revision problem: derived data quietly drifting from what produced it. Now, whenever I store something generated, my first question is “what made this, and how would I know if that changed?”
That's an excellent example. And I can see how versioning everything could be seen as overengineering at first until you change a model or your prompt and you don't have any clue of which data was generated with what.
I really like your point about asking "what made this, and how would I know if that changed?" That is a great way to look at things especially when working with AI-generated data where the underlying models and prompts can change over time.
That's exactly what I was getting at in my post. Once you've run into a problem like that and actually understand why it matters, you start recognizing similar situations in completely different projects.
Thanks for sharing. It's given me something else to keep in mind with my own projects.
THIS! That's why I always build my new projects intentionally slow. Every time I touch a new framework or library or new area in my codebase, I often tend to learn the why's first. What problem it solves and whether I am overengineering it.
AI is helpful in this case since it searches up latest documentations easily and could give me links which I read for verification. If I'm still lost, AI would help me dumb it down so I could keep up.
It's also the same as with school. Sure, most of the students can nod along while the professor explains things but without reflection and practice, the lesson will not stick. Same reason why I try it myself first, explain the concepts with my own words and I would let AI find gaps in my understanding. That way, I am confident that when the same problem comes up, I would be able to step up and solve it on my own.
It doesn't matter if I forgot the exact implementation (that's what the internet is for). What's important is I know what answer I need. That's way different than just searching for the answer.
I love that last point about knowing what answer you need rather than just searching for one. I think that's such an important distinction, and it really sums up a lot of what I was trying to get at with this post.
I also really like your approach of trying to understand something yourself first and then using AI to find the gaps in your understanding. That's something I've been trying to get better at myself.
And I agree about the overengineering part, too. Sometimes when you're learning something new, it's hard to tell whether a particular approach is actually necessary or just adding complexity you don't need. Understanding why something exists in the first place makes those decisions a lot easier.
I don't always have the patience to take things slowly, especially when I'm excited about a new project and just want to build everything at once. But I definitely see the value in it.
Caminante, son tus huellas
el camino y nada más;
Caminante, no hay camino,
se hace camino al andar.
Al andar se hace el camino,
y al volver la vista atrás
se ve la senda que nunca
se ha de volver a pisar.
Caminante no hay camino
sino estelas en la mar.
Todo pasa y todo queda
Pero lo nuestro es pasar
Pasar haciendo caminos
Caminos sobre la mar.
...es un extracto de un muy conocido poema de Antonio Machado.
...nadie conoce cada esquina del mundo ni de la vida, y nadie sabe realmente hacia dónde va. ¡Y yo acabo de llegar! :) ...