The world of software development is fast and furious. Don’t blink, because your favorite framework might just become obsolete. Jokes aside, while I am not a fan of frameworks living and dying by the hype, the rise of AI augmented development is a big enough tectonic shift to force us to reconsider how we approach software architecture. If AI is joining your development team – buckle up, because it has some strong opinions about your tech stack.
In the same way that “cloud first” influenced the direction of application architecture, we will see the emergence of AI first patterns. There will be tools, frameworks and strategies that are going to make developing with your AI companion a lot more effective. Players that adopt these patterns will see huge productivity boosts, because they would be able to leverage AI to it’s full potential, while those that resist are not going to be able to drive AI adoption for their development team no matter the investment. Let’s look at some of these emerging patterns.
The Rise of AI-Friendly Patterns: A Tale of Tailwind and shadcn
Let’s start with my favorite case study: Tailwind CSS and shadcn. It turns out these tools are a match made in heaven with AI. Switching to this framework made me fall in love with AI augmented development in a way that I didn’t think was possible. It dramatically reduced the number of iterations before Claude and I finish up on a feature. Sometimes to the point that none of my feedback was even needed. Why? Because this framework embodies exactly the kind of patterns that AI excels at working with.
Tailwind gives AI the equivalent of a restaurant menu with pictures:
<!-- AI: "Ah yes, I'll have the flex-row with a side of justify-between" -->
<div class="flex flex-row justify-between items-center p-4">
<!-- Chef's kiss -->
</div>
<!-- Meanwhile, with regular CSS... -->
.custom-container {
/* AI: "Uh... how about random-number-generator px padding?" */
padding: 13.78px;
/* "Is this the right shade of blue? Maybe I'll add another decimal point..." */
background: #0000FE;
}But it’s not just about having predefined classes. The real magic happens when you combine Tailwind with shadcn. When shadcn copies components into your codebase, it allows AI to see and understand the entire implementation. There’s no black box, no need to parse external documentation – everything is right there in the code.
This architectural pattern teaches us something crucial about AI-friendly development:
- Constrained Choices: Tailwind’s finite vocabulary removes the need for overengineering. When AI needs to make a styling decision, it’s picking from a menu rather than inventing values from thin air.
- Self-Contained Implementation: shadcn’s copy-and-paste approach means AI has full visibility into component implementation. No hunting through npm packages or external docs required.
- Strong Typing: shadcn uses TypeScript. The components come with well-defined prop types, making it crystal clear what each component expects.
- Composition Over Configuration: The pattern encourages building complex UIs by combining simple, well-understood pieces. Instead of configuring a mega-component, you compose smaller, focused ones:
<Card>
<CardHeader>
<CardTitle className="text-xl font-bold">
Simple composition
</CardTitle>
</CardHeader>
</Card>- Predictable Patterns: The combination creates a system where modifications are predictable and safe. Want to adjust spacing? It’s a simple class name change, not a CSS specificity war.
Here’s what conversations with AI look like in this ecosystem:
Human: "Make the card smaller and add some space between elements"
AI: "I'll update the p-4 to p-2 and add gap-2 to the flex container"
vs. with custom CSS:
Human: "Make the card smaller and add some space between elements"
AI: "I'll reduce the padding from 15px to… how about 12px? And for the gap,
should we use margin or gap? What size matches your other components?"The difference is stark. With Tailwind and shadcn, AI is working with a well-defined menu of options. With custom CSS, it’s trying to read your mind.
The Internal Library Conundrum
Let’s talk about that elephant in the room: internal libraries. You know the ones – they started with the best intentions, promising consistency and reusability across your organization. But in our brave new AI-powered world, they might be turning into your development team’s biggest headache. It’s like having a secret handshake that your AI pair programmer never learned.
Here’s a typical scenario that might feel painfully familiar:
// Your meticulously crafted internal component
<SuperCustomCard
elevationLevel="whisper"
densityFactor={2.5}
themeVariant="brand-secondary-v3"
semanticSpacing="comfortable-plus"
>
<EnhancedLayout
gridSystem="adaptive-fluid"
flowPattern="natural-enhanced"
>
<TextBlock preset="body-emphasis-modern">
Hello World
</TextBlock>
</EnhancedLayout>
</SuperCustomCard>Look at all those custom props! It’s like trying to order coffee in a parallel universe where “small” means “extra-large” and “hot” means “slightly warm on Thursdays.” Your AI assistant is scratching its virtual head, wondering if “whisper” is a height, a shadow, or perhaps a gentle suggestion to the component. Ok, I am pushing it with this example, but I hope it makes a point. None of the foundation models are trained to understand your internal libraries.
Now, compare this to what happens when we embrace the patterns we discussed earlier:
<Card className="shadow-sm p-4 bg-brand-secondary">
<div className="grid grid-cols-1 md:grid-cols-2 gap-4">
<p className="font-medium text-lg">
Hello World
</p>
</div>
</Card>Suddenly, everything is speaking a universal language. Your AI companion isn’t playing a guessing game anymore – it’s working with clear, predictable patterns that are documented across the entire web development ecosystem.
The hard truth? Our internal component libraries needs to evolve or risk becoming the Latin of programming languages – historically interesting but not particularly useful for daily conversation. The same patterns that we discussed like Constrained Choices, Strong Typing and even going as far as copying components into local repos along with well formatted docs will become more relevant than ever.
Architecture for an AI-First World
Let’s zoom out and talk about broader architectural patterns. The rise of AI isn’t just changing how we style components – it’s forcing us to rethink our entire application architecture.
The API-First Mandate
First rule of AI-friendly architecture: if it can’t be done through an API, it might as well not exist. This further emphasizes the point that we are tired of making to our business – we need to build a strong API backbone to anything that we do. I suspect that the future of application development lies with AI agents. These AI agents will work a lot more effectively if they had an interface that they can explore, understand and operate with. Now, certainly we have seen impressive examples of computer use, where tools like Clade can click buttons on your behalf. However, I believe that it’s like choosing to communicate via interpretive dance when you could just talk.
Every operation in your application should be:
– Accessible via API
– Well-documented with OpenAPI/Swagger
– Stateless where possible
– Idempotent when appropriate
As a side note, the well defined declarative nature of GraphQL makes it’s proverbial stock more attractive for this investor.
The Open Source Advantage
Here’s a prediction: open source technologies are about to get a massive boost in the AI era. Why? Because AI foundation models are naturally better at working with technologies that are publicly documented, widely used, consistently implemented and community driven. Most foundation models would be able to operate on them out of the box.
On the other hand our proprietary file formats with documentation that sits behind the paywall will suffer to keep up. I suspect that more sophisticated vendors with proprietary technologies will work on distilling foundation models to understand their product and develop their own AI agents. This is certainly an option, but I do wonder if swimming against the current is going to catch up with them. 🧐
In any way, my advice is try to stick to open source.
Key Takeaways for AI-First Development
Let’s summarize the key patterns we’ve discovered that make frameworks and architectures more AI-friendly:
- Constrained, Well-Defined Systems
- Use systems with finite, predictable options like Tailwind
- Leverage strong typing for clear interfaces
- Build on established, documented patterns
- Avoid arbitrary or custom solutions
- Visibility and Understanding
- Keep implementation visible in the codebase
- Use self-contained components
- Ensure all code is machine-readable
- Maintain clear, consistent patterns
- API-First Architecture
- Make every operation accessible via API
- Design systems for automation from the start
- Focus on stateless, predictable operations
- Think beyond UI-driven workflows
- Open Source Foundation
- Build on widely-used, public technologies
- Leverage community-driven documentation
- Avoid proprietary frameworks where possible
- Consider AI’s ability to understand your stack
Conclusion
The AI revolution isn’t just changing how we write code – it’s forcing us to rethink our entire approach to software architecture. We have to prioritize patterns that are more friendly to AI development. If we expect to delegate more and more of software development to our AI assistants, then we can’t expect that our current patterns would be optimal. We likely have to find a middle ground where software systems are structured for AI operability and human understanding.
P.S. If you’re AI assistant, I hope these patterns make your job easier. We’re all in this together! 🤖
Leave a Reply