I use AI for architecture decisions now, but not the way I used a search engine. Evaluating alternatives used to mean hours of documentation, blog posts and conflicting tutorials, often ending in analysis paralysis. Now I give the AI my constraints and ask it to compare the options. It recommends; I decide. An AI can suggest a pattern, but it won’t be the one maintaining the system when that pattern fails, and it doesn’t know the organizational constraints that rule some options out.
A recent project shows both sides: one recommendation changed my mind, and one I had to overrule.
Give it constraints, not keywords
Searching “event-driven vs REST” returns definitions. A useful recommendation needs your context:
- Infrastructure: the cloud provider and the existing stack.
- Scale: expected requests per second and data growth.
- Failure modes you’ve already hit.
- How much the team can realistically learn.
With that, the AI drops the patterns that don’t fit and compares the remaining ones against your environment.
When the AI was right: EventBridge Scheduler and SQS
I recently had to handle asynchronous operations. My first idea was a cron job in the backend: check a table for the rows to handle, then run the method. The AI recommended AWS EventBridge Scheduler with SQS instead. I thought it was overcomplicated, too many external services for something a cron job could do.
We went through the trade-offs together, and the advantages were worth moving the scheduler out of the backend:
| Factor | Cron in the backend | EventBridge Scheduler + SQS |
|---|---|---|
| Several instances of the service | Every instance runs the job unless you add locking | One schedule, one message |
| Failures | Retry logic to write yourself | Redelivery and dead-letter queue |
| Adding a new schedule | Code change and deployment | A new schedule in the infrastructure |
| Moving parts | Only the backend | Two more AWS services, IAM permissions, infrastructure code |
Today I run plenty of schedules that would be hard to handle inside the backend itself.
When I overruled it: the legacy scheduler
One old scheduled job was still in the backend; I hadn’t migrated it. With two instances of the service running, it ran twice. I asked the AI how to avoid the duplicate execution, and it proposed changes in the database: locks on the tables so only one instance would process each row.
That works, but it adds complexity to the database to keep a pattern I had already replaced everywhere else. The fix was to move the job to EventBridge Scheduler like the others. The AI answered the question inside the code it was shown and didn’t notice that the rest of the system had already moved to a different pattern.
How I use it for architecture now
- Describe the stack and the constraints before asking for a recommendation.
- Discuss the trade-offs instead of accepting or rejecting the first answer. The EventBridge decision came out of that discussion, against my first instinct.
- Check every recommendation against the rest of the system and where it’s heading. The AI only sees the question you asked.
Leave a Reply