Retrospective

FlyRank AI Fluency & Backend Engineering track — written for the person I was in Week 1.

In Week 1, the goal was narrow: audit how I actually use AI tools day to day, get sharper at prompting across models, and sketch a portfolio sitemap — Home, Work, About, Contact — so the rest of the track had somewhere to land. At that point "backend AI engineering" mostly meant writing a FastAPI endpoint that returned the right JSON. The plan was to get through the weekly assignments, keep the repos clean, and end up with a portfolio that didn't lie about what I'd built.

What changed is the definition of "done." The first few assignments — first-api, first-api-db — were about correct response shapes and 404 handling: real, but small. By the time I got to tasks-api, "done" meant proving a claim with a number: I seeded 500k rows and ran EXPLAIN ANALYZE before and after adding an index, and only wrote down the ~724x speedup because I'd watched the query plan flip from a parallel sequential scan to an index scan myself. That habit didn't go away after that assignment. It's why SOLACE's README has a "v2 Evaluation" section where I ran the app end-to-end and tested my own claims instead of trusting that code someone — or something — else wrote was correct just because it compiled. It's why the capstone widget platform's geo-enrichment fallback got rebuilt with a mock flag once I realized the "proof" depended on an external API the brief explicitly said not to rely on. Verification stopped being a step at the end and became part of how I build.

The second shift was learning to name what's broken instead of hiding it. "Break Your Own Site" is the assignment that forced this, but the habit shows up everywhere once you look: SOLACE's README has a real Limitations section (the safety filter is keyword matching, not a trained classifier; session memory doesn't persist); this site's own README names an unattributed console 403 that never got traced, instead of pretending the site was flawless. A portfolio that only shows what works reads as marketing. One that names what doesn't yet reads as engineering.

1. Verify, don't assume. A benchmark, an eval, or a screenshot of the thing actually running beats a claim every time — and it's the only way to catch the gap between "the code looks right" and "the code is right."
2. Build for the dependency that breaks, not just the demo. The Groq model I built SOLACE's conversation agent on was deprecated mid-build; the fix was straightforward, but it only became straightforward because I'd kept the integration isolated enough to swap. Same lesson from face-api.js's Node fs polyfill issue on deploy. Things you depend on change under you; the question is how much it costs when they do.
3. A named limitation is worth more than a hidden one. Every real piece of work in this track ships with something unfinished or imperfect. Saying so, specifically, is what makes the rest of the claims believable.

What surprised me most was realizing a feature I'd already marked verified — the capstone platform's geo-fallback chain — was only "working" because a public IP-lookup API happened to be reachable that day, which is exactly what the brief warned against trusting. Finding that gap myself, after I'd already called it done, was a better lesson than if it had failed loudly in a test.

What's next: the widget & lead-capture platform still has two pieces blocked on my own machine — live Supabase verification, and Docker against real Postgres — finishing that is the immediate target. Past that, the direction is the same as the track's: fewer toy endpoints, more systems that hold up under a real load, a real failure, or a real stranger trying to break them.