Deep dives on test automation, AI-assisted development, and engineering philosophy.
14 posts
Someone asked me today why I bother learning code when AI can just do it for me. I gave a short answer. Then I came here to give the real one.
I used Figma Make across two completely different projects at the same time. The contrast between those experiences taught me more about the tool than any single deep-dive would have.
The goal was simple: write three records to AppSync when a new user signs up. What followed was four issues, six permission errors, one circular dependency, and a hard lesson about how many layers AWS auth actually has.
My UPS blew up this weekend. Arc, flash, pop, burning smell — the works. What followed was two days of waiting and one very satisfying teardown of something I had no hope of repairing.
120 developer test plans. 800 manual test cases. Tens of thousands of lines of tightly coupled code written over 60 years. Here's what it actually looks like to introduce automation when there's no foundation to build on.
Most companies treat documentation as optional. It isn't. Without it, training takes years instead of months, bugs go unresolved, and decisions become mysteries — even to the people who made them.
They say millennials are the last generation that truly remembers life before technology consumed it. Here's what that perspective means for how I think about AI in software development.
We have AI systems capable of interpreting language and adapting to users over time. So why do most fitness apps still require constant manual interaction during the worst possible moment to use a phone?
Most companies push for the quickest solution. But 9 times out of 10, those aren't the best solutions. The question we should be asking isn't 'what's fastest?' — it's 'what's smartest?'
The highest-impact work often comes from improving systems, not just executing within them. None of my most meaningful improvements started as assigned work.
Adding automation to a legacy codebase isn't about tools. It's about understanding the structure well enough to introduce change responsibly.
I stopped thinking about the immediate fix and started thinking about durability. The billiards table taught me that small inputs shape the entire run.
A passing test doesn't prove system resilience. A clean dashboard doesn't guarantee clean inputs. Working in QA taught me to question the structure behind the output.
What I learned from intentionally building alongside AI instead of just using it for quick answers — and why the biggest shift wasn't speed, it was clarity.