Agilish

I’ve had some time recently to re-tool and refocus, which led me down an AI journey that ultimately resulted in building a showcase web application called Tee It Up Chicago . Tee It Up Chicago is a golf course catalog and utility platform for golfers in the Chicago area, featuring course information, scorecards, handicap tracking, and other tools designed for local players. I am working on adding round and match scoring and other features to make outings and tournaments easier to score and track. The best way I can describe the experience working with agentic AI agents is this: it feels like having the smartest kid from my computer science class sitting next to me, helping me build software. This “AI teammate” never gets tired, never complains when I ask a basic question, and can jump in and write code when I need it to. The more I’ve worked with these AI coding tools, the more I’ve learned how to collaborate with them effectively — and the faster I’ve been able to build web appl...

Some organizations decide to maintain only two environments: Development and UAT. The reasoning usually sounds practical. One fewer environment to maintain. One fewer pipeline to manage. One less budget line to defend. In practice, it eliminates the one thing that makes a pre-production release testable. When QA and UAT are the same environment, in-progress work and release candidates sit side by side. Business stakeholders doing acceptance testing are looking at code that may not even be part of the upcoming release. External partners are testing against something that does not represent what production will look like. Most critically, there is no stable, controlled place to validate the actual release before it ships. The result is that the final validation happens in production. Nobody sets out to test in production — but many organizations end up there because they removed the environment that would have prevented it. UAT as Your Most Valuable Diagnostic Tool Con...

Given that UAT is reserved for external-facing testing against market infrastructure and external partners, your internal teams need somewhere else to test. That environment is QA — and the name is where things start to break down. UAT is a term almost everyone understands. Say it in a room full of developers, business analysts, project managers, or regulators, and they all broadly know what you mean: the environment where acceptance testing happens before a release goes live. QA does not carry the same shared understanding. Ask teams across different systems or business lines what they call their pre-UAT environment, and you will get a different answer from each one: SIT (System Integration Testing), INT (Integration), TEST, UAT2, STAGE, or simply "the lower environment." These are all names for the same concept, but the lack of consistent terminology creates real operational friction. When teams across multiple systems are trying to coordinate an end-to-end test,...

AI writes the code, so we need fewer developers. And if we need fewer developers, the thinking goes, we probably need fewer testers too. The software just…works. That story is wrong . Not slightly wrong. Fundamentally and dangerously wrong. AI is changing how software gets built. It is not changing the fact that software is used by humans, that humans make mistakes, that systems fail under pressure, and that every new line of code — whether written by a person or generated by a model — introduces new ways for things to go wrong. If anything, the rise of AI-generated software makes rigorous, human-led testing more important, not less. AI Makes Testing Better — It Does Not Make It Optional None of this is an argument against using AI in testing. AI is already making testing faster and more thorough. It can generate test data at scale, suggest regression suites, identify patterns in defect history, and reduce the mechanical burde...

I value trust and honesty as core beliefs. I have always been transparent in work and in my personal life because I have nothing to hide. I do not lie, cheat, or steal — so why wouldn't I be? With that context, this post is not an April Fool. But I do want to share the best April Fool that ever got me. It got thousands — if not millions — of us. Every year I think about it, remember my friend Erik and his dad, and I smile. 1985 The year was 1985. Erik and I were baseball-crazy teenagers getting ready for our first freshman high school baseball season. I was finishing dinner with my parents when the white rotary phone in my mom's kitchen rang. "It's over! It's over! Baseball as we know it is over." Erik was on the other end, more excited than I had ever heard him. He went on and on about a new pitcher the Mets had found who threw 168 miles per hour with pinpoint accuracy. The Mets would win the World Series — nobody could beat a team with pitching li...

I love fables. Like a picture is worth a thousand words, a simple story with a moral lesson is a good way to share experience — translating something complex into something smaller and more digestible. Looking back across my career, I have led teams of every sort, shape, and size across a lot of different industries. The people were different. The platforms were different. The tools were constantly changing, sometimes mid-project. But when I think across every engagement, one thing runs through all of them: incremental delivery of software. That is the only constant. Not the language, not the methodology, not the org chart or the budget. Just the steady act of shipping working software piece by piece and learning from what it tells you. I have done a lot of it. I have lived through the wins, the near-disasters, and the moments where the wheels came completely off. Every one of those experiences taught me something. Fables strip it down to what matters. A tortoise and a hare do n...

There is a particular kind of manager who is deeply involved in everything and yet somehow never actually close to the work. They attend every meeting. They ask for constant status updates. They want to be copied on every email. They weigh in on decisions that are nowhere near their level. And yet, despite all of that involvement, they do not actually know what is going on. They are micro-managing from 50,000 feet — controlling everything in theory while understanding very little in practice. I have seen this pattern more times than I can count. And I have seen the damage it does. What It Actually Looks Like Micro-managing from altitude is harder to spot than the classic version, where a manager is looking over someone's shoulder telling them how to type. The high-altitude version feels more sophisticated. The manager is "engaged." They are "across" the project. They are "asking the right questions." But what they are really doing is creating...