Deep dives on test automation, AI-assisted development, and engineering philosophy.
10 posts
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.