AI + Architecture
Quick context if you're new here: I'm Sandeep, a Technical Lead and AI engineer with 13+ years in the industry. This newsletter is where I document a pattern I keep running into: AI is exceptionally good at writing code, and largely indifferent to whether that code should exist where you put it.
Two pieces went up on the blog this month:
→ AI Ships Your Code in Minutes. Your Team Pays for It for Months.
→ Stop Building Microservices on Day One
→ What I'm building next
WHAT AI GETS WRONG
AI Ships Your Code in Minutes. Your Team Pays for It for Months.
Ask an AI assistant for an order-creation endpoint and you'll get something that works HTTP handling, raw SQL, business rules, all tangled into one file. It'll pass a demo. It'll also become the file nobody wants to touch six months from now. I walk through the fix using three plain layers (controller → service → repository), and how to prompt around AI's default toward the tangled version.
Takeaway: Bad code is easy to fix. Missing boundaries aren't — they don't show up as bugs, they show up as fear.
THINK IN SYSTEMS
Stop Building Microservices on Day One
The fix for both too-early microservices and unstructured monoliths is a modular monolith — real bounded contexts enforced inside one codebase. The test: stop looking at your folder structure and look at your foreign keys.
Takeaway: Inside a bounded context, AI is a fantastic resident. Across bounded contexts, it'll take the shortest path to a green test every time — usually the shortcut that deletes your boundary.
A clean box diagram means nothing if your Orders module is quietly joining straight into inventory_items.
What's next:
I build something in the open every month — real open source projects, real architecture edge cases, documented as I hit them. Every build turns into a couple of posts here and a video recap.
If any of this is useful, forward it to a teammate who's shipping AI-generated code without thinking hard about what's underneath it.
Until next time,
Sandeep