AI & Data Science Specialist | Building ML models, NLP systems & real-world AI apps 🚀
Freelance data analysis & AI/ML projects, technical writing, open to collaboration on data visualization & forecasting work
Yes, actually , on my current project I'm analyzing a synthetic travel dataset (10K rows, 33 features) and one of my encoded columns had inconsistent category labels like same value, different capitalizations. Model didn't throw an error. Output looked fine. But the groupings were completely off. Caught it during EDA, not during modeling. Which is exactly the problem bad data doesn't always break things loudly. Sometimes it just quietly gives you wrong answers.
Mine was simple but painful: don't skip EDA thinking you'll "fix it later." I'm currently mid-project on a 33-feature dataset and the one time I rushed past a preprocessing decision, I caught the mistake three steps later and had to redo everything from scratch. Now I treat EDA as the actual work, not the warm-up
Exactlyy this...The "nobody shows that part" is so real and every clean notebook you see online skipped 3 days of messy column names and nulls 😅 And the downstream poisoning thing is what actually scares me. A bad assumption at cleaning doesn't fail loudly, it just quietly breaks things way later.
The AEO point stands out ,.. as someone building in public and writing about my projects, I hadn't thought much about how AI assistants might reference (or not reference) that content versus traditional search. Makes me want to go back and check if my own posts are structured clearly enough to be "answer-worthy" rather than just readable. Good reminder that clarity matters beyond just SEO.
Strict typing definitely solves the "lying documentation" problem but code can't drift from itself. But I think it's less either/or and more what each is good for: types tell you what the data/interface looks like, but not why a particular approach was chosen over alternatives, or what tradeoffs were considered. For AI agents specifically, maybe the real shift is documentation moving from "describe the system" to "describe the decisions".... the parts types genuinely can't capture.
The "vibe-testing is dangerous" point really resonates I've seen prompt changes that looked better in a quick test but quietly broke edge cases. The tool-calling check (right tool, right params, error handling) is something I hadn't separated out explicitly before, but it makes total sense as its own evaluation layer. Going to try structuring my next agent project around this baseline + regression approach.
Great breakdown, the SSM path mismatch and JSON-stringified secrets issues alone could eat a full day of debugging for anyone migrating without this context. Bookmarking this for reference. Curious if you considered SST/OpenNext as a middle ground before going full Amplify, or was the new Adapter API specifically the deciding factor?
"Ship when one clear workflow works end-to-end without breaking" ,...this is going on my wall honestly. The part about users teaching you what to polish first really hit different. I launched anyway and you're right, already getting a clearer picture of what actually matters. Really appreciate this perspective! 🙏
