A practical playbook for working with AI code assistants
Over the past 10 months, I’ve used AI assistants to speed up how I prototype, design, and reason about frontend systems. They’ve drastically improved how quickly I can build proofs of concept — what used to take hours now takes minutes. But they don’t magically understand context, intent, or architecture. I use to define them with the knowledge of wikipedia but the skills of a junior/mid developer.
I treat the assistant’s output as a starting point, something I’ll review, adjust, and refine just like I would if another engineer had written it. That means I’m constantly checking for things the model misses: subtle architectural rules, shared contracts, naming conventions, or performance trade-offs that it simply doesn’t grasp. Sometimes is my prompt’s fault, sometimes is not.
The result? I move faster, but I have to stay in control. AI becomes a force multiplier because I invest in reviewing and iterating on its output. It’s not magic. It’s a collaboration. And like any collaboration, the quality depends on how clearly you communicate and how seriously you take the review process.
Based on what I’ve learned over the past eight months, I’ve developed a practical playbook I now apply every time, a set of principles and patterns that help me use AI assistants as reliable collaborators across every stage of architectural design and frontend development.
1. Start with intent, not just code
Too many developers treat AI like an oracle: “Generate a login page” or “Build me X.” The result? Generic code, bloated logic, and brittle coupling. In distributed frontend systems, you’re juggling boundaries, contracts, and team ownership. If your intent isn’t clear, the AI will fill in the blanks — often incorrectly.
Define your goal in terms of:
- What the code should do
- The context it lives in
- The boundaries it must respect
Write this down in a Markdown file. Point your assistant to it when needed. This helped me saving time and get the result I wanted.
2. Give AI the context it needs
AI doesn’t “remember” like humans. Without proper context, it will guess based on common patterns and not your architecture or design decisions.
Context is your responsibility. Especially in a micro-frontend setup where small mistakes break boundaries.
Remember to:
- Describe your stack, folder structure, and conventions.
- Reference markdown files with shared decisions.
- Reuse context blocks across prompts.
3. Decide for the right plan
When I’m about to implement a feature or refactor part of the system, I don’t jump straight into prompting AI for code. Instead, I use it as a thinking partner from the beginning. I start by describing what I’m trying to achieve and ask the assistant to prepare a plan. This gives me something to react to and I got in exchange a concrete proposal I can refine.
From there, I iterate on the plan with the assistant. I ask it to consider design principles, architectural boundaries, performance trade-offs, and any constraints that apply to the system. We go back and forth until the plan aligns with how I would approach the problem myself. Only after we’ve reached that point do I ask it to act on the plan and start generating code.
This approach not only leads to better technical outcomes, it also helps me stay in control of the direction. AI becomes part of the design process, not a shortcut around it. And in complex systems like micro-frontends, that clarity upfront makes a huge difference later on.
4. Think like a Developer
After we have a solid plan, I never let AI try to solve the whole problem in one go. Instead, I treat it like a teammate helping me build incrementally. I break the work down into small, focused tasks and ask the assistant to handle them one at a time.
This approach mirrors how any careful developer works — tackling manageable chunks, validating each part before moving on. I start with the simplest building block, review the output, then move to the next. If something isn’t quite right, I feed that back and refine before proceeding. This back-and-forth keeps the code clean, maintainable, and aligned with the architecture.
5. Automate the boring stuff
AI isn’t just for writing code. It’s powerful for automating governance and developer workflows across micro-frontends. You know all those tasks that are often overlooked because “I don’t have time”?
A few ideas I applied with micro-frontends:
- Dependency management: “Create a Dependabot config to check all package.json files weekly…”
- Architecture rules: “Write a ts-arch test preventing /apps/public-site from importing /shared/auth…”
- Bundle size checks: “Fail the push if /apps/profile’s bundle exceeds 200kb…”
- CI workflows: “Create a GitHub Actions pipeline that lints, tests, and runs bundle size checks for all MFEs in parallel…”
In all of these, AI acts as your DevOps co-pilot. It saves you hours — and enforces architecture at scale.
Final Thoughts
AI can significantly speed up how we build and prototype, but it requires a disciplined approach to be truly effective. The key is to treat AI as a collaborator that helps you think through problems, draft plans, and write code incrementally — not as a tool to deliver finished solutions out of the box. By investing time in guiding AI with clear context, iterating on plans, and reviewing every output carefully, you maintain control over quality and architectural integrity.
This playbook reflects my experience with AI so far, I have even more steps I’m testing out in the past weeks, but I want to continue testing them before sharing them publicly.
With the right process, AI can help you deliver faster without sacrificing maintainability or design standards. It’s about working smarter, not just faster.
If you’re experimenting with AI in your development workflow, I’d love to hear your experiences and lessons learned. Share tips so we can all improve how we collaborate with AI and build better software together 😁
