🗓️ This Week
While reviewing the code for the minimum-feature iOS app that Codex implemented for ToneDrill, I started coming up with ma...
For further actions, you may consider blocking this person and/or reporting abuse
Hey Umitomo! Great work so far and glad you are keeping it consistent.
I would love to see more posts about what you did in detail. For example, a whole post about cybersecurity that you learned recently in detail and your thoughts about it. It would be nice to see diversity! I notice you also mention that in your weekly logs, but it would be nice to see in a formal article if that make sense.
Again, nice work so far :D
Thanks for your thoughtful comment, Francis😁!
I’m really glad you noticed that I’ve been keeping this up consistently. Your reactions, like hearts and unicorns, also really motivate me to keep posting, so I truly appreciate them✨
You’re right — in my weekly logs, I usually only touch on what I learned briefly. I’d like to try writing a more detailed article focused on one specific topic, especially as a way to organize my understanding and share my own thoughts more clearly.
Thanks again for the great suggestion!
Really enjoyed this ❤️ great work Umitomo!!!
Thank you so much, 𝕋𝕙𝕖 𝕃𝕒𝕫𝕪 𝔾𝕚𝕣𝕝😁!
I’m really happy to hear that, and thank you for the ❤️ reaction too 😊
If my honest learning journey can have a positive impact on someone in some small way, that would make me really happy ✨
The pattern you're describing — Codex delivers a working skeleton, you review it, and suddenly there are ten things you'd do differently — comes up repeatedly on teams using AI generation for the first time. The review step tends to surface assumptions that were invisible while the code was still running: hardcoded layout constants, orientation logic that doesn't generalize, structure that reflects what the model inferred rather than what you actually intended. Breaking tasks into short-term and long-term before diving back in sounds like the right call — the AI can own the first draft, but the architecture needs a human deciding how the pieces should fit together.
Thank you so much for such a thoughtful comment!
I hadn’t thought about it that deeply, but your point about AI being great for creating the first draft while humans still need to decide how everything should fit together really gave me something to think about.
Since this is my first time building an iOS app, I’m still learning a lot through reviewing what Codex creates and figuring out what I actually want to change or improve.
I really appreciate you taking the time to share such a detailed perspective!
Makes sense — reviewing before you fully understand the domain is actually a decent way to learn iOS, as long as you're asking "why did it do it this way" and not just "does it compile." One failure mode I've hit with AI-generated Swift specifically: it will confidently produce code that compiles and runs but violates platform conventions Apple enforces informally — retain cycles in closures, delegate patterns done as strong refs instead of weak, main-thread violations that only surface under load. Xcode's static analyzer catches some, but not all, so treat "it built and ran once" as the start of verification, not the end.
Thank you so much for sharing such a detailed comment based on your own experience.
I’m really glad you pointed these things out, because they were not areas I had paid much attention to before. Your examples helped me realize that even if AI-generated Swift code compiles and runs, there can still be important issues to review beyond that.
I’d like to keep these points in mind and use them as part of my review process when checking code generated by AI.
I really appreciate you taking the time to share such practical advice🙏!
The compile-and-run bar is especially deceptive with Swift because Apple maintains backward compatibility on deprecated APIs for years — AI models train on older code, produce it, and it ships. The case that stuck with me was keychain access:
kSecAttrAccessibleAlwayscompiles cleanly, stores the credential, passes every test, and silently exposes it on an iCloud-backed device. You're right that the checklist approach is the sustainable path; the key is making it specific enough to catch parameter-level decisions, not just structural ones, because that's exactly where AI code looks confident and lands wrong.Thank you so much for sharing such practical advice based on your real-world experience.
I don’t think I’m at the point yet where I can review every piece of AI-generated code at that level of detail, but simply learning that I need to look at things from that perspective has already been very valuable to me.
Right now, I’m mainly working on a simple local app, something closer to a calculator, but in the future I’d like to build apps that involve data storage and authentication as well. So I want to start keeping these kinds of concerns in mind from now on.
I really appreciate you taking the time to explain all of this so carefully!
Interesting mix of iOS and web dev this week! I'm curious how you're handling secure data flows on mobile — have you considered using WebAssembly modules for sensitive logic, maybe with some SGX-like isolation? On the GPU side, I've seen similar patterns where VoltageGPU helps keep ML inference private, but that's a different stack.