---
Most of this month I’ve been working on a contract AI-engineering project, I implemented sign-in-with-apple, iOS in-App purchase, sign-in-with-wechat (OAuth), account linking, revamped some UI/UX on iOS app; submitted the iOS app to App Store Connect and resolved four review cycles; I also surveyed, selected cloud vendors and migrated existing backend and database servers from HongKong to Beijing.
Throughout the month, I shipped PRs, and Leo reviewed it. Leo is an ex-Amazon engineer, and a friend/mentor of mine. This is the first time I’m collaborating with someone with a lot more engineering expertise than me.
(Note: my responsibility on this project is primarily execution. We align on priorities and checkpoints, and I carry them through to deliver the agreed results.)
As someone junior in Engineering, I received lots of feedback, and here are some of my reflections.
When designing systems, optimize for what we actually care about
It’s all about identifying what we care most about and system engineer towards that. Systems engineering is about asking, at each step, how our decisions are helping us get to what we care about. In our case, we want to ship it quickly and get done with it, but we also want to be able to maintain it easily after our development. So Leo and I had lots of discussions around how to better design the database schema and related system (dev/prod env). Being able to identify tradeoffs for each decisions becomes even more critical.
Read what the LLM wrote
You can’t skip reading what LLM coded, otherwise prepare for spaghetti code. Almost always, claude will over-engineer and make the codebase a lot harder to understand. Always be ready to ask if it over-engineered. There are often moments when I can’t tell if it over-engineered, and that’s when I know I have limited knowledge on the subject. I rely a lot more on seniors and talking to models to learn here.
Doc‑driven coding
Engineering is changing from code driven to doc driven. For each feature you want to add, have LLM do research in the codebase and solution space and ask for a plan, then you have another agent code it out. You still need to understand what’s happening under the hood to make sure it’s not trying to end humanity. A very helpful way to do that is to have LLM create an ascii chart representing how the components work together, or sequence diagrams of how the threads are working at the end of each coding session. If it’s complex also have another vendor’s agent check it. Our current practice is to create a doc that has both ascii charts for human readability and file paths, function names in the descriptive paragraphs for LLM grepability. There is a trend of preparing data for LLM other than for human, not confusing them is one of the hard tasks.
I also imagine there will be tools that help you visualize & plan in the codebase in a more interactive and dynamic way in the near future (for high-level planning, building), more suited for LLM-driven (doc-based, abstracted) engineering.
Biggest blockers aren’t code anymore
In the past month, the biggest blockers in product development usually aren’t technical, but approval bottlenecks. To login with an 2FA-enabled enterprise accounts might take minutes to hours, getting verified on the Weixin Open Platform involved almost a week of back-and-forth, and clearing App Store Connect required four review cycles, adding nearly another week of delay.
Git is still very important.
Know your git commands, esp. when you git pull origin main, otherwise you’ll ended up introducing +10,000 -9,876 lines of code changes to your feature branch haha (when not rebasing well).
Yes, junior software engineer is not a thing anymore.