As a software engineer with over 20 years of experience, I’ve spent a good chunk of my career solving complex problems with a blend of intuition, best practices, and brute-force experience. But recently, I found myself in a familiar yet evolving situation: building a flexible, scalable feature into my Symfony 6 + PHP 8 + Doctrine stack — and needing a fresh perspective.

I’ve been diligently developing an AI-driven pipeline that generates reports based on incoming Assessment Responses. But not all assessments are created equal. Some reports rely on custom algorithms, others on pre-configured GPTs, and some follow more deterministic formats like Score Cards or Answer Cards. The challenge: How can I elegantly handle all these different “generation strategies” without hard-wiring logic that will become a nightmare to maintain?

Initially, my instinct was to go with what I knew — perhaps a good old-fashioned Factory Pattern, or just some quick inheritance-based polymorphism to get things moving. But I paused. I knew that flexibility would be crucial here, especially as I foresee more report types and AI integrations on the horizon.

Taking the Problem to ChatGPT

Here’s where the story pivots.

Out of curiosity (and maybe a bit of fatigue), I threw the problem at ChatGPT — not expecting much beyond a boilerplate example. But what I got back wasn’t just code. It was a better way to think about the problem.

ChatGPT recommended the Strategy Pattern, a classic design approach that I hadn’t considered in this specific context. While I’ve known about it for years, I rarely reached for it in PHP-heavy projects. But now, it made perfect sense.

Instead of binding my logic to an inheritance hierarchy or relying solely on a factory to spit out report generators, I now had a cleaner, interface-driven approach:

interface ReportGenerationStrategy {
    public function generate(array $data): Report;
}

Each report type (e.g., CustomAlgorithmReport, GPTDrivenReport, ScoreCardReport) implements this interface. A simple Strategy Resolver or Factory then selects the right strategy based on the assessment type.

It’s elegant, easy to test, and most importantly — open for extension, closed for modification.

If interested, I made a separate post for the geeks here, where I expand on the idea.

AI Is Not Just for Writing Code — It’s a Thinking Partner

What stood out to me most wasn’t the code suggestion itself, but how ChatGPT helped surface a design principle that aligned better with my long-term goals: reducing rigidity, promoting scalability, and embracing composability.

As developers, we often assume that experience alone is enough. But sometimes, experience becomes a filter — and we miss opportunities to adopt patterns that better suit modern challenges.

This small interaction reminded me that AI isn’t just a junior coder or a documentation assistant — it can be a thinking partner, capable of surfacing ideas that cut through the fog of habit.

The Bigger Picture

This experience has changed how I approach my work:

• I’m more open to pausing and questioning my default architectural instincts.
• I’ve embraced AI as an augmentation layer for design decision-making, not just content or code generation.
• I’m building faster, yes — but also building better.

Final Thoughts

If you’re a seasoned developer, I encourage you: don’t just use AI to write boilerplate. Use it to challenge your assumptions, discover fresh approaches, and enhance the quality of your decisions.