Kevin Meyvaert - Articles

From manual emails to a fully automated photo pass system

2026-01-24T00:00:00+01:00

I have been part of the photography collective Wannabes for about seven years now, already before covid. Over time I gradually took on the responsibility of handling most of the photo pass requests for the photographers in the collective. At first this felt manageable. It slowly turned into a surprisingly heavy operational task.

Requesting photo passes sounds simple, but it rarely is. For every concert, you need to figure out who the promoter is, find the right press contact, send out emails and then follow everything up. Applications need to be sent well in advance, while replies often arrive only a day or two before the show. In the meantime you are tracking approvals, rejections and confirmations, and making sure every photographer knows where they stand.

Doing this for a handful of shows is fine. Doing it for dozens every month is not. A lot of time went into searching press websites and copying information around. Because the process was so tedious, I sometimes postponed applications. That meant we were late and missed photo passes. It also meant I was not very motivated to let more photographers join the collective, simply because that would create even more manual work.

At some point it became clear that this could not stay this way. The process needed to be automated. Not only to save time, but also to make it consistent and scalable.

The first attempt at automation

I had already seen n8n pass by on social media a couple of times as a workflow automation tool. I never really took the time to try it properly. In October of last year I decided to spend a full day turning my entire manual workflow into an automated one. I started with n8n Cloud because I wanted to move fast and avoid spending time on infrastructure before knowing whether the idea would even work.

The n8n workflow that automated photo pass requests. It handled everything from scraping shows to generating emails.

The first version was surprisingly extensive. I scraped the Live Nation press website to keep a list of upcoming shows in a Google Sheet, since most of our concerts come from there. I created a form using Tally where photographers could submit their requests. Every submission triggered a workflow that matched the request to the correct show and enriched it with promoter contact details. On the first day of each month, another workflow generated draft emails using ChatGPT, ready to be sent to promoters.

Using it for real

We decided to actually use this setup for the last couple of months of the year. It worked well enough to already save a lot of time. At the same time, n8n Cloud turned out to be quite expensive, so I moved everything to my own NAS. I cleaned up the workflows and added Discord notifications for every important step. That way I only had to intervene when something was missing or when a show was not coming from Live Nation.

Incoming replies were still handled manually. I received a notification in Discord and then checked my mailbox to see whether a request was approved, rejected or simply acknowledged. It was not perfect, but it was a big improvement. That is how we closed the year.

A new job and a new idea

In December 2025 I switched jobs. I had mostly worked as a front end engineer before, but my new role is much more full stack. I was looking for a real project to get more comfortable with the technologies we use at work. The timing felt right to turn the automated workflows into a proper application.

Over the course of a weekend I built the bare bones of what is now our photo pass request system. Photographers can log in and see a dashboard with their requests and their current status. They can browse and search through upcoming concerts that are automatically fetched from multiple sources.

One central place for all concert data

The concert dashboard where photographers can browse and search upcoming shows. All press contacts and venue information are automatically fetched.

The system now scrapes not only Live Nation, but also venues like AB and De Roma, as well as other places our photographers frequently cover. Because all shows already exist in the system, photographers can simply type an artist name and select the correct show. All relevant press and promoter information is already attached. Almost no manual searching is needed anymore.

Automating the follow up

On the admin side, all incoming requests are visible in one place. At first this was mostly an interface layer on top of the existing automation. Soon after, I decided to automate the follow up process as well.

I built a service that monitors my mailbox and automatically classifies incoming emails. It extracts which show and which request the email refers to, updates the status in the system and sends a notification to the photographer when a decision is made.

The email logs interface showing automated classification of incoming emails. The system extracts show details, matches requests, and updates statuses automatically.

If a promoter replies that a photographer is approved under certain conditions, those conditions are included automatically. The photographer receives an email with all the details without me having to touch anything. I still receive Discord notifications so I can keep an eye on things and step in when needed.

Discord notifications keep me informed of new concerts, photo requests, and any issues that need manual intervention.

Handling fairness inside the collective

One tricky edge case was handling multiple photographers requesting the same show. I built a simple assignment system that keeps track of how many opportunities each photographer has had. That makes it easier to distribute assignments more fairly across the collective.

Where the system stands today

The application now runs on Google Cloud and is actively used by Wannabes. It saves time, reduces mistakes and removes a lot of mental overhead. Most importantly, it made the whole process enjoyable again. Building it genuinely made me happy.

The admin dashboard showing pending requests, recent updates, and new submissions. Everything I need to manage the collective in one place.

What this project confirmed for me is how much I enjoy solving real world problems through automation. If you have a workflow in your business, hobby or organization that feels clunky or overly manual, I am always happy to think along. Sometimes a bit of advice is enough. Sometimes it makes sense to build something. Either way, feel free to reach out.

A junior software engineer’s AI usage guide

2025-11-20T00:00:00+01:00

Lately, in conversations with other engineers, I’ve noticed a growing concern: AI is widening the gap between junior and senior developers. Seniors know how to structure problems and recognize good solutions, so AI feels like a boost. Juniors, still learning those fundamentals, often feel unsure about how to get the same value from these tools.

My goal in writing this article is to share what I’ve learned and help make that gap feel smaller. With the right approach, AI can accelerate your growth instead of overwhelming it, supporting you as you build your engineering foundation.

As you transition to professional engineering, you’ll find that artificial intelligence coding assistants are powerful tools. Think of AI not as a replacement for your growing skills, but as an advanced co-pilot that helps you work faster while you still learn to navigate.

Your primary goal right now is to build deep foundational knowledge. This guide outlines how to use AI tools (like Cursor, GitHub Copilot, or Tabnine) to support your learning, not short-circuit it.

LLM 101: models vs tools (the engine vs the car)

The distinction between a model and a tool is fundamental to understanding AI-assisted coding. The interchangeable use of these terms in common conversation can be confusing, but knowing the difference is key to maximizing AI utility.

The model: the core intelligence

The Large Language Model (LLM) is the engine that generates code and answers. Its performance is defined by its inherent characteristics:

Context window: This is the limit of how much code and conversation history the model can “see” at any one time. A larger context window allows the model to understand more complex, multi-file problems.
Reasoning capability: Models differ in their ability to plan and execute tasks. Better models exhibit superior chain-of-thought reasoning, meaning they can break down a complex problem into logical steps before writing the code.
Examples of models: GPT-5.1, Claude Sonnet 4.5, Gemini 3.

The tool: the workflow integration

The tool is the product or interface that integrates the model into your workflow (e.g., your IDE or CLI). The tool can significantly influence the model’s effective performance:

Tool calling: The tool enables the model to interact with external systems. For example, a tool might allow the model to read and edit multiple files in your codebase, giving it a much broader effective context than the model alone could handle.
Optimization: tools are often specifically optimized for certain models. For example, the product Claude Code is designed and optimized to work seamlessly with Anthropic models like Claude Sonnet 4.5.
Examples of tools: ChatGPT, GitHub Copilot, Cursor, Claude Code.

Deep dive on context: model context protocol (MCP)

The model context protocol (MCP) is an open standard that allows AI assistants (the tool/client) to dynamically fetch real-time, version-specific information from external services (MCP servers) and inject it into the model’s context window. This is how the AI can access up-to-date documentation or interact with your file system. While this capability is incredibly powerful, it introduces a major pitfall: context bloat.

The danger of context bloat

Context bloat occurs when the model’s limited context window is overloaded with excessive or irrelevant information. When this happens, the model’s performance degrades rapidly. It struggles to find the “signal” in the “noise,” leading to:

Lost focus: the model pays attention to irrelevant details instead of the task at hand.
Increased latency & cost: every message sent to the model requires re-sending the entire bloated context.
Accuracy decay: the model’s ability to reason and recall correct information drops (the “lost in the middle” problem).

Starting smart: context7 MCP

Context7 MCP is a prime example of an MCP server that exclusively focuses on providing clean, up-to-date, version-specific documentation for popular libraries and frameworks. It is designed to minimize bloat and combat hallucinations by only giving the model what it needs. No unnecessary logs, files, or chat history. This is the safest way to leverage tool-augmented context while you develop an understanding of context management.

Tip!

Although MCP is all the hype. Use it wisely. Personally, I only use Context7 and Playwright. I don't use Figma MCP as it translates the design to a json representation, bloating the context of your session. Screenshots work as good or even better!

Crucial ground rules

Before you begin, these rules are non-negotiable. They protect your learning curve and your code quality.

No blind copy-paste: Never accept and commit a large block of AI-generated code that you do not fully understand. If you can’t explain it to another engineer, you shouldn’t check it in.
No entire features: Avoid prompts like “Write a function that handles user login and authentication”. Break down the task into small, manageable components and write them yourself, assisted by the AI.
Always verify: AI can sometimes hallucinate (make up facts or code). Always verify the AI’s suggestions against security policies, coding standards, and project-specific constraints. You are the final authority.
Document: When you use a complex piece of AI-generated code, make a note of it (e.g., in a code comment or a pull request description) to maintain clarity and accountability.

Tip!

I know it's very tempting to go with the flow when using AI. Pumping out features fast feels good. But know that building an understanding of how good software works takes time, effort and critical thinking. Knowing and understanding code will make you a better engineer in the long run! So don't cut corners.

The 5-phase learning roadmap

This guide is about using AI to accelerate your learning curve, not to skip it. By focusing on comprehension and using the AI as an interactive tutor and assistant, you will quickly develop the instincts of a great engineer.

The following phases are designed to systematically build your skills:

Phase 1: AI as a smart autocomplete (code and learn)
Phase 2: AI as a knowledge agent (ask and understand)
Phase 3: AI as a peer reviewer (ideate and refine)
Phase 4: The Socratic prompt (learning by asking)
Phase 5: Never stop experimenting (the evolving landscape)

Phase 1: AI as a smart autocomplete (code and learn)

The most effective way for you to start is by treating the AI as an extremely smart autocomplete function. This keeps you in the driver’s seat, ensuring you reason through the problem and write the code yourself.

Own the code: Write the first few characters or a comment describing what you need. Let the AI suggest the rest. Do not prompt the entire feature. You should be able to write the code yourself if the AI suggestion disappears.
Reason first, accept second: Before accepting an AI-generated snippet, pause and ask yourself:
- Why did the AI suggest this method or syntax?
- How does this code work, line by line?
- Is this the most efficient or cleanest way to solve the problem?
- Is this simple, readable code?
Small, repetitive tasks only: Use autocomplete for:
- Boilerplate (e.g., setting up a basic class structure, function signature).
- Simple, repetitive patterns (e.g., initializing a list, basic error handling).
- Syntax lookup in a new or unfamiliar library.

Tip!

It's always useful to go read up on some framework/library documentation. Deep understanding of core principals and patterns will make you understand new things faster as you encounter them.

Phase 2: AI as a knowledge agent (ask and understand)

Your AI tool often has a chat or agent mode. Use this for contextual questions that would typically require digging through documentation or interrupting a senior teammate.

Goal	Your Prompt Strategy	Why this helps you learn
Understanding code	“Explain this block of code” or “What does this library function do and why is it used here?”	It forces you to analyze existing code, and the AI provides an instant, relevant explanation.
Design choices	“Why is this API endpoint implemented with a POST request instead of a GET?” or “Why was this specific database pattern chosen?”	It gives you historical and architectural context, building your understanding of system design.
Refactoring	“I’m thinking of renaming this variable to `currentUserProfile`. Review the pros and cons of this change.”	It teaches you the value of code clarity and maintainability.

Tip!

Use your AI coding assistant as a first line of information when you have questions or if you want to bounce ideas. Verify assumptions. Explore options. But don't also forget you can reach out to other engineers you're working with! They'll gladly point you in the right direction.

Phase 3: AI as a peer reviewer (ideate and refine)

Once you have a functional idea or have started an implementation, use the AI to bounce off ideas and challenge your own assumptions.

Ask for alternatives: “I’ve implemented this logic using a dictionary/map. Can you suggest 2-3 alternative ways to implement this, and what are the upsides and downsides of each (e.g., performance, readability, memory use)?”
Review your logic: Write out a piece of pseudocode or a comment explaining your planned implementation, and ask the AI to critique it. “I plan to do X, then Y, then Z. Is there a case I’m missing? Is there a more standard pattern for this?”
Critical evaluation is key: Your human mind is better at critical thinking, nuanced requirements, and considering the overall system context. Always verify the AI’s suggestions against security policies, coding standards, and project-specific constraints. Remember, AI can sometimes hallucinate (make up facts or code). You are the final authority.

Tip!

Try moving out of your code editor. Explain the problem you want to solve to a model that doesn't have access to the codebase. That way it won't be confined to the limitations of the current implementation of your project. I call this prompting outside of the box.

Phase 4: the Socratic prompt (learning by asking)

To maximize your learning, train your AI to act like a Socratic tutor. It should ask questions and guide you, not simply hand over the solution. This is essential for developing your debugging and problem-solving muscle.

Problem Area	Instead of this prompt…	Use this guided prompt…
Component Logic	“Write a component that fetches data and displays a loading state.”	“I’ve started building a data-fetching component. Before you write the implementation, explain the best place to handle asynchronous logic in a functional React component, and why that hook is the preferred method.”
Debugging State	“Fix this bug where my component updates twice when I click a button.”	“I have a double-render issue when state changes. List the top 3 common causes of this in a React component and suggest a debugging step I can take to isolate the cause in my specific code.”
Performance/Best Practices	“Rewrite this function to be faster.” (Referring to a complex render function)	“Review my component’s rendering function. Do you see any opportunities to use React’s built-in memoization hooks (like `useMemo` or `useCallback`)? If so, explain the performance trade-off of applying the hook here.”
New Hook/Library	“Write code to manage global state with Redux.”	“I need to manage state across multiple components. Compare Context API vs. Zustand for a small-to-medium-sized React application. Don’t provide code, but list the pros and cons of each in terms of boilerplate and learning curve.”
Refactoring	“Refactor this component.” (Large file with mixed logic)	“This component has too many responsibilities. Suggest a plan for breaking it down into 2-3 smaller, single-purpose components. Outline what the new components should be named and what props they will accept.”

Tip!

You'll get more value from your coding agent if you ask it to ask you questions (or if you're using Claude, try setting its output style to "learning"). When responding try to avoid adding your own bias, because LLMs are pleasers. i.e. don't say "Isn't it better that we do it this way?" as it will probably agree with you. Try asking "What are the benefits or possible pitfalls when we do it this way?".

Phase 5: never stop experimenting (the evolving landscape)

The moment you become comfortable with an AI tool is the moment you must start looking for its successor. The AI engineering landscape is evolving at a breakneck pace. New models, agents, and IDE integrations are released weekly, constantly raising the bar for what’s possible. Your ability to adapt and experiment is the final, and perhaps most critical, skill to cultivate.

The 30-day testing cycle

Your biggest competitive advantage in this field will be your willingness to test new technologies. You only truly learn about new technology when you use it.

Consume reviews: Dedicate a small amount of time each week to consuming content about new models (like GPT-5.1, Gemini 3, or Claude Sonnet 4.5) and new tools (like Antigravity, Aider, or new Cursor features). Watch videos, listen to podcasts, and read newsletters to hear about other developers’ real-world experiences and benchmarks.
Install and test: When a new tool or model update seems promising, install it.
- Run the tests: Use it to write or refactor a component with existing unit tests. Does the generated code pass the tests on the first try?
- Check the flow: Use it for a day or two on a small feature. Does it genuinely enhance your workflow? Is it faster, less distracting, and more context-aware than your current setup?
Switch or stay:
- If it enhances your workflow: Switch immediately. The cost of switching is minimal compared to the long-term gains in efficiency and learning.
- If it doesn’t: Revert to your current tool. You haven’t lost anything, but you’ve gained invaluable context about the technology’s current limitations and strengths.

Tip!

Find information sources that work for you. (Twitter, Reddit, newsletters,..) But remember many tech influencers are very opinionated. That's why it is so important to get hands-on, read the docs, and form your own opinion.

The ultimate learning metric: agentic reflexes

Pay close attention to tools that emphasize agentic behavior. These are tools designed to handle multi-step tasks, like creating a full feature or fixing a complex bug across multiple files, by planning and executing code changes while keeping you in the loop for verification.

The transition from simple autocomplete to a collaborative, multi-step agent is the future of AI-assisted coding. The true measure of your professional growth will be your ability to:

Critique the plan: Can you immediately identify a flaw in the agent’s multi-step plan before it writes any code (a reflex honed in Phase 3)?
Verify the code: Can you quickly explain why the agent’s complex, multi-file solution works (a reflex honed in Phase 1)?

By actively testing new tools, you are not just chasing productivity; you are testing and refining the core engineering instincts you built throughout this guide. The goal isn’t to be a subscriber to every tool, but to be an informed evaluator. By actively testing and comparing, you ensure your personal AI co-pilot remains the most powerful and effective assistant available, keeping your skills relevant and your productivity high.

I built an IKEA price checker for a friend’s renovation

2025-11-12T00:00:00+01:00

A friend was redoing his kitchen. He told me IKEA prices aren’t the same everywhere. Same product, different country, different price. He checked them one by one across Belgium, the Netherlands, and France.

His kitchen plan had ninety-eight products from the IKEA kitchen configurator. That sounded painful to track by hand.

He said, “It’s strange. The exact same cabinet is cheaper across the border.” That line stuck with me. He didn’t need another spreadsheet. He needed a small tool that did the checking for him.

So I started building one that same afternoon.

From idea to first version

I didn’t start by writing code. I asked GPT-5 what would make a good IKEA price comparison tool. It suggested simple features: search by product code, compare countries, highlight the lowest price, show stock, and maybe handle full shopping lists later.

Then I opened Claude Code to build it. Within minutes, we had a working prototype. Type an IKEA article number and it fetched prices from Belgium, the Netherlands, and France. It took less time to make than opening three IKEA sites by hand.

The first working version of the IKEA price checker. “ship it?” I send to my friend via text.

Building beyond the basics

Once the basics worked, I asked GPT-5 what else people might want. It suggested checking stock by store, uploading shopping lists, exporting results, and adding a browser plugin. That became my plan.

I added live store availability first. IKEA has no public product API, so I scraped pages and checked the numbers against the site until they matched.

Then came shopping list mode. You can upload an IKEA shopping list PDF. The app reads the product codes, checks prices across countries, and shows which stores give the lowest total. It can export that plan as a clear PDF.

I just prompted the shopping list (pdf) feature. “will it work first try”

The next step was the Chrome plugin. It adds a section that appears automatically on IKEA product pages. The section shows the price comparison for that product right inside the page. It feels native, as if IKEA quietly added it themselves.

Those ideas came from GPT-5 brainstorms. Claude Code helped turn them into working parts.

Two AIs, different jobs

Claude Code handled development. It wrote functions, API routes, and scrapers fast. When something failed, I gave it the error and product ID. It helped narrow the fix.

GPT-5 handled the product side. It asked why a feature mattered and how people would use it. That mix kept the code moving and the scope tight.

I wasn’t feeling creative naming this project, but GPT-5 helped. He also helped out making the logo, who needs desigers anyway 🤷‍♂️

Managing the project

I gave Claude Code my article Architecting for AI as context. That shaped the structure. All generated code lived in one Nx monorepo. The scraping, authentication and analytics logic were shared by the web app and the Chrome plugin. It kept the setup clean instead of a collection of one-off scripts.

I like clean project trees and efficient code reuse 🤝🏻

Clauding on the go

While building this project, I tried a new feature from Claude. They have a mobile app where you can link your repository and send prompts from your phone. The next day after finishing the app, I was at work when my girlfriend texted me. She couldn’t import shopping lists from the IKEA mobile app because those links used a different format. At the coffee machine, I opened Claude on my iPhone, pasted her link, and typed:

It’s the productmanagerification of software development

What the app does now

You can type any IKEA product code. It shows prices for Belgium, the Netherlands, France, and Germany. It marks the lowest price. It checks stock for specific stores. You can upload a shopping list and get a per-store breakdown with totals. And on IKEA’s own pages, the Chrome plugin shows the same comparison right below the product details.

You can find the code on GitHub and visit the live app at komprare.vercel.app. The Chrome plugin is in review and should be publicly available soon.

Migrating my photography blog with AI: Lessons in iterative development

2025-11-02T00:00:00+01:00

I recently migrated my photography blog from Tumblr to Jekyll with help from Claude Code. The project took a few hours and involved migrating 85 posts, optimizing 839 MB of images, and building a custom blog section. But more interesting than the technical outcome was learning how to effectively work with an AI coding assistant.

This is a screenshot from my Tumblr. Looks familiar?

This isn’t a tutorial. It’s a reflection on what works (and what doesn’t) when building something real with AI.

Starting with context

My first prompt was straightforward:

“I created this fresh Jekyll project. I have a Tumblr blog at the moment, but I want to migrate it to a Jekyll setup so I can host it on my GitHub. First of all, I want you to analyze my current setup on Tumblr and recreate the layout as it is today. The url of the blog is kevinmeyvaert.be”

What worked here: I provided the actual URL instead of describing the design. I stated the end goal (GitHub Pages hosting). I asked for analysis first, implementation second.

The AI analyzed my Tumblr theme and started building. But immediately, we hit the first lesson.

Visual feedback beats everything

The initial build looked clean but wrong. Instead of my sidebar navigation, it created a horizontal header. I could have written a paragraph explaining the difference, but instead:

“The first image is my tumbler, which you can see has a sidebar. And the second image is what you created, which has a header and no sidebar. Please make the desktop version look like the tumbler one.”

Two screenshots. One sentence. Problem solved.

Lesson: When something doesn’t match your vision, show it. Screenshots, mockups, or rough sketches communicate infinitely faster than descriptions.

The masonry grid saga

This is where things got interesting. My Tumblr blog used a masonry layout. Images of different aspect ratios flowed naturally into two columns. Simple to see, harder to build.

The AI initially used Masonry.js, a popular JavaScript library. It worked, but loaded all 85 images at once. The page took forever to load.

Next attempt: CSS Grid with calculated row spans based on image aspect ratios. This should have worked. But instead, I got massive gaps between images. Huge, unusable vertical spaces.

I tried giving feedback:

“The gaps are huge now (they got bigger since last change)”

Still broken. Time for directness:

“maybe reevaluate your approach ultrathink”

This moment taught me the most important lesson: When you’re stuck in local optimization (tweaking values, trying variations), sometimes you need to step back entirely. Don’t be polite. Be direct. “This approach isn’t working” is valuable feedback.

After my prompt, the AI switched approaches entirely to CSS multi-column layout:

.photo-grid {
  column-count: 2;
  column-gap: 30px;
}

.photo-item {
  break-inside: avoid;
  margin-bottom: 30px;
}

Perfect. Zero JavaScript. True masonry effect. The right solution was simpler all along.

Lesson: Don’t get attached to the first approach. If something fundamental isn’t working, say so and explore alternatives.

Asking for best practices

I had 839 MB of images sitting in the project. I didn’t know if Jekyll had built-in optimization, so I asked:

“The images that we’re showing now on the website are pretty big. Does Jekyll offer some kind of image optimization plugin or resizer so we can ship more reasonably sized images?”

The AI recommended jekyll_picture_tag, configured it for AVIF/WebP/JPEG with multiple responsive sizes, and ran the optimization.

Result: 839 MB to 21 MB (97.5% reduction)

Lesson: You don’t need to know every solution. Ask about best practices for the problem you’re trying to solve. “Does X have a way to handle Y?” is a powerful prompt pattern.

When constraints change plans

Later in the project, I wanted better URL structure. The blog listing was at /blog but individual articles used /articles/article-title. Confusing.

My request:

“It’s kind of confusing that the overview of the blog is slash blog, but that the detailed pages are slash articles. Can you align those?”

The AI suggested renaming _posts to _photos for consistency. We did it. Then discovered: the standard jekyll-paginate plugin only works with _posts directory, and GitHub Pages doesn’t support the v2 plugin that handles custom collections.

We had two options. Use GitHub Actions for custom builds (complex). Keep _posts as the directory name (simple).

I chose option 1: keep it simple. The URLs are clear even if the directory name isn’t perfect.

Lesson: Real projects have constraints (hosting limitations, plugin compatibility, deadlines). Perfect architecture sometimes loses to practical shipping.

Prompting patterns that worked

Looking back at the conversation, the most effective prompts were:

Incremental and specific. Not “Make my site better” but “Can you make the pagination navigation more subtle?”

Visual when possible. Not “The layout should have a sidebar on the left” but [Screenshot] + “Please make it look like this”

Direct about problems. Not “The spacing seems a bit off” but “The gaps are huge now, maybe reevaluate your approach”

Context-rich for complex requests. Not “Add a blog” but “I want a separate page on my blog where I can post technical blog posts. These articles shouldn’t appear in the feed of photos on the homepage.”

Questions over commands. Not “Implement image compression” but “Does Jekyll offer some kind of image optimization plugin?”

What we built

In a few hours:

We migrated 85 photo posts from Tumblr HTML. We optimized and served responsive images (AVIF/WebP/JPEG). We built masonry grid with pagination (10 photos per page). We added separate blog section for technical writing. We made it all GitHub Pages compatible.

The conversation had ~50 exchanges. Most were quick iterations and refinements.

Takeaways for AI-assisted development

Start with context. Give the AI your actual URL, existing code, or screenshots. Context beats lengthy descriptions.

Iterate quickly. Don’t try to specify everything upfront. Build, review, adjust. The feedback loop is your friend.

Use visual feedback. Screenshots communicate design intent faster than any written description.

Be direct when stuck. If an approach isn’t working, say “this isn’t working, try something else.” Don’t optimize a bad solution.

Ask questions. You don’t need to know every tool or library. Ask “what’s the best practice for X?” and learn from the answer.

Embrace constraints. Perfect architecture isn’t always practical. Ship the thing that works with your constraints.

Review, don’t just accept. The first solution often works, but not always optimally. The masonry grid needed three attempts to get right.

Want predictable results from AI coding agents? The iterative approach described here works great for smaller projects. For larger codebases and enterprise applications, I’ve developed a more structured approach using NX, module boundaries, and code generators that makes AI-generated code consistently production-ready. Learn more in Architecting for AI: How NX, module boundaries, and code generators transformed my development workflow.

The real value

The final blog works great. But the real value wasn’t the code. It was learning how to collaborate effectively with AI tooling. These patterns apply whether you’re building a blog, refactoring an app, or debugging production issues.

The best collaboration happens when you provide clear context, give direct feedback, iterate quickly, know when to push back, and stay focused on shipping.

Now I have a blog I control, hosted on GitHub, with optimized images and clean URLs. And I learned a better way to work with AI in the process.

You can view the final result at kevinmeyvaert.be and the source code on GitHub.

Architecting for AI: How NX, module boundaries, and code generators transformed my development workflow

2025-08-25T00:00:00+02:00

When ChatGPT appeared, every dev team rushed to integrate it into their workflows. I did too. But I quickly discovered a problem. AI assistants generate code that violates architectural rules. They introduce coupling. They break dependency boundaries. They don’t understand your architecture unless you teach them.

This is the story of how I prepared my enterprise Angular app for the AI age. I didn’t write better prompts. I enforced better architecture.

The problem: AI assistants don’t know your architecture

Here’s a scenario you’ve probably lived through. You ask your AI assistant to “add a new feature to the stories module.” It generates code enthusiastically. But the code imports from unrelated modules. It creates files in the wrong directories. It uses outdated Angular patterns from its training data. It violates your team’s linting rules and breaks your dependency graph.

That was my daily reality until I realized something. AI assistants need guardrails, not guidelines.

NX: The monorepo that thinks like an architect

NX is more than a monorepo tool. It’s a framework for architectural discipline. When I migrated my social-style application to NX, I wasn’t just cleaning up the repo. I was creating a structure both humans and AIs could navigate without ambiguity.

My app had features for posts, stories, notifications, and more. Think of it like an internal Instagram engineering system. Every domain needed a clear home. Every dependency needed to be intentional.

NX gave me three things I couldn’t get anywhere else. First, explicit project boundaries. When I ask the AI to “add a feature to the stories domain,” it knows exactly where the files belong. Second, a dependency graph that works like an executable contract. My AI and my fellow developers can query this graph to understand what depends on what. Third, a predictable project structure. Every feature library follows the same layout.

Here’s what that looks like:

libs/posts/feat-scheduler/
├── src/
│   ├── lib/
│   │   ├── components/
│   │   ├── services/
│   │   └── guards/
│   └── index.ts
├── jest.config.ts
└── project.json

This predictability eliminates guesswork for humans and machines.

Module boundaries: Your architectural immune system

The key to AI-safe architecture isn’t documentation. It’s enforcement. I use ESLint’s @nx/enforce-module-boundaries rule. This rule relies on a two-dimensional tagging system that defines both the domain and type of each library.

Each library belongs to a domain that represents a business area. In a large social app, you might have domain:users for authentication, profiles, and relationships. You’d have domain:posts for content creation and feed features. You’d have domain:stories for ephemeral stories and highlights, domain:notifications for alerts and engagement, domain:ads for monetization, and domain:shared for utilities that cross domain boundaries.

Domains depend on each other intentionally, not by accident. Posts can depend on users and notifications for author and engagement data. But posts cannot depend on ads or stories. Here’s how I configure that:

{
  "sourceTag": "domain:posts",
  "onlyDependOnLibsWithTags": [
    "domain:posts",
    "domain:shared",
    "domain:users",
    "domain:notifications"
  ]
}

Each library also declares its architectural role through type tags. A type:feature library contains smart, routed components. A type:ui library contains dumb, reusable components. A type:data-access library handles state management and data orchestration. A type:api-service library wraps API clients and adapters. A type:model library holds TypeScript types and interfaces. A type:util library contains framework-agnostic utilities.

Here’s an example rule for UI components:

{
  "sourceTag": "type:ui",
  "onlyDependOnLibsWithTags": [
    "type:ui",
    "type:model",
    "type:util",
    "type:data-access"
  ]
}

UI code can’t call APIs directly. It must go through the data-access layer. No documentation needed. No human enforcement required.

Libraries must satisfy both domain and type constraints. A library tagged ["domain:stories", "type:feature"] must respect both sets of boundaries. It can import domain:shared, type:ui. It cannot import domain:ads, type:ui. It cannot import domain:shared, type:api-service from a UI component. The boundaries are enforced automatically. AI has no room to color outside the lines.

What happens when AI hits a boundary

When AI-generated code violates a rule, it doesn’t fail silently. It hits a lint wall:

$ npx nx lint posts-feat-scheduler

ERROR: 15:1  @nx/enforce-module-boundaries
A project tagged with "domain:posts" can only depend on libs tagged with
"domain:posts", "domain:shared", "domain:users"

The feedback is immediate and clear. The AI adapts. Next time, it generates correct imports. Your architecture becomes the AI’s training data.

Custom generators: Teaching AI to fish

Boundaries defend your architecture. Generators let you go on offense. I built custom NX generators that wrap my architectural patterns into reusable commands.

I can create a new feature module with npx nx g @app/generators:library feat-highlights --directory=stories. I can create a shared UI component with npx nx g @app/generators:shared-component carousel. I can create a lazy-loaded module with npx nx g @app/generators:module profile-settings.

Every generator creates files in the right places. It applies architectural tags. It sets up linting, tests, and i18n. It uses modern Angular syntax like signals, standalone components, and the inject() function. The AI doesn’t need to generate boilerplate. It just calls the right generator.

CLAUDE.md: Context for AI, not rules for humans

Many teams maintain massive documentation files describing coding conventions. I deleted mine. I replaced it with a CLAUDE.md file that focuses on context, not rules:

# CLAUDE.md - Project Context

## Overview
- Social platform for sharing content (posts, stories, messages)
- Key domains: users, posts, stories, notifications

## Domain Terms
- "Reel" = short-form video (domain:stories)
- "Boost" = paid post promotion (domain:ads)
- "Insights" = analytics dashboard for creators

## Test Accounts
- qaInfluencerUser: creator account
- qaModeratorUser: admin privileges

Everything that can be enforced through tooling gets enforced. Linting, code structure, import rules, and formatting are not written down. They’re baked into the tools.

Enforcement over documentation

If a rule can be enforced, don’t document it. This creates immediate feedback for AI and humans. Your tooling configuration becomes your single source of truth. When you update ESLint rules, you update AI behavior. There’s zero drift between documentation and implementation.

Real results

Since I adopted this approach, module boundary violations dropped to near zero. AI assistants generate code that passes lint on the first try. New developers onboard in days, not weeks. Code reviews focus on business logic, not structure. My AI assistants now self-lint before suggesting commits.

What I wish I’d known earlier

Start with boundaries, not features. Architectural constraints teach AI faster than documentation. Treat generators as infrastructure. They’re as critical as CI/CD pipelines. Use tags, types, and tooling to make wrong code impossible. Lint early and often. If it doesn’t lint, it doesn’t ship. Treat your architectural context like code and version-control it.

When architecture meets AI

Once your architecture enforces itself, AI becomes a productive collaborator instead of a liability. Onboarding happens in minutes, whether the new team member is human or AI. Every library follows the same structure. Refactors become safe. Consistency scales with your team size.

When AI and architecture align, velocity and stability increase together. That’s rare in software engineering.

The takeaway

The teams that thrive in the AI era won’t be the ones with the best prompts. They’ll be the ones with the best architectures. Make your architecture enforceable. Make your AI architecturally aware. Let your development team and your AI move faster, safely.

Automating my workflow with AI: A web engineer’s journey

2025-03-04T00:00:00+01:00

Update (August 2025): This article is outdated. I no longer use Cursor to build software. My approach has evolved significantly since writing this post. For a more recent and comprehensive look at how I integrate AI into my development workflow, see Architecting for AI: How NX, module boundaries, and code generators transformed my development workflow.

I’m lazy. Not in a bad way, but in the “how can I get more done with less effort?” way. As a web engineer, I look for ways to improve my workflows. I want to spend less time on repetitive tasks and more time on creative problem-solving. AI has become my tool of choice. It helps me build software faster and smarter. Cursor is an AI-powered coding assistant that has changed how I develop software.

Using Cursor to build software

Cursor helps me accelerate my workflow. It writes boilerplate code, debugs issues, and generates complex logic. The integration with my IDE is smooth. I can generate functions and components quickly. I get instant code suggestions and improvements. I debug and troubleshoot problems faster. I automate repetitive coding tasks.

With this help, I focus more on high-level architecture and problem-solving. I don’t get stuck on syntax and routine coding patterns. Getting started is easy. Install it, integrate it into your workflow, and watch it handle the tedious parts. But anyone can use Cursor. I’ve found ways to use it better. I’ll share how I get the most out of it.

Be smart about prompting

Crafting good prompts is critical when working with AI tools. The quality of the output depends on the quality of the input. Context matters. Clear, well-structured instructions help AI models generate meaningful responses.

Here are some principles to keep in mind. Be specific. Vague prompts lead to generic responses. Define what you need in detail. Provide context. The more information you give, the better the AI understands your request. Iterate and refine. If the first response isn’t right, tweak your prompt and try again. Use examples. They help guide AI-generated content. Break down complex queries. Smaller steps improve accuracy.

Mastering prompt engineering unlocks AI’s full potential. It makes AI a powerful assistant rather than just a tool. But prompting comes with challenges.

Treat your agent like an intern

One challenge is making sure AI-generated code follows your team’s coding standards. Your AI assistant is like an intern or junior engineer. It needs guidance to produce high-quality work. AI can generate impressive results, but it doesn’t know your team’s best practices. I use Cursor Rules to align the AI’s output with our coding standards.

Cursor Rules act as safeguards. They enforce best practices and prevent inconsistent code. The rules cover formatting standards. They check for consistent indentation, naming conventions, and style guidelines. They enforce code quality. They avoid anti-patterns, enforce modularity, and require proper documentation. They address performance. They encourage efficient algorithms and minimize unnecessary computations. They handle security. They require safe data handling, authentication flows, and API interactions.

image: an example of some of the cursor rules I have in place for the project I’m currently working on.

These are the classic boy scout rules. Always leave the code better than you found it. Just like when we mentor interns and junior engineers, we need to train our AI assistant.

Getting structured output in large-scale projects

Another hurdle is consistency of output. Large language models are stochastic. If you ask an AI to generate the same code multiple times, you’ll get different implementations. This leads to fragmented code, redundant logic, and a lack of cohesion. In small scripts, this might not matter. In larger projects with multiple developers, it’s a problem. You need more than good prompts.

I use Nx Generators to address this. Nx Generators automate the creation of components, modules, and configurations from predefined templates. They establish scaffolding structures that guide my Cursor agent. Nx Generators provide a consistent framework for AI-generated code.

Combined with Cursor rules, I can instruct the agent to use specific generators for certain actions. This reduces inconsistencies. Every component, service, or feature is generated with the same patterns. Collaboration becomes easier. Large projects remain maintainable because AI follows an organized framework.

image: here i’m asking to move a component to the “shared components”, which triggers a Cursor rule that defines that the agent has to use our shared-component Nx Generator. Which makes sure it is scaffolded and exported from the correct location.

Generators are just a small part of what Nx offers. Nx is powerful for managing large-scale projects. It enforces modularity, optimizes builds, and streamlines workflows across teams. Using Nx, I make sure AI-generated code fits into the project and improves the architecture.

Introduction to Model Context Protocol (MCP)

MCP is an open protocol developed by Anthropic. It helps AI understand and interact with the tools engineers use every day. It acts as a bridge between a large language model and external services. Think codebases, issue trackers, and deployment pipelines. Anthropic describes it like this: “Think of MCP like a USB-C port for AI applications. Just as USB-C provides a standardized way to connect your devices to various peripherals and accessories, MCP provides a standardized way to connect AI models to different data sources and tools.”

MCP provides structured context to AI models. This improves response accuracy. It allows interactions with external systems. This reduces manual overhead. It enables automation through AI-driven commands in development workflows.

Engineers can create more intelligent integrations between AI tools and their software development lifecycle.

Building a custom MCP server for Azure DevOps

AI-assisted coding had already improved my development speed. Recently I took automation one step further. I built a custom MCP server to interface with Azure DevOps directly from Cursor chat.

This integration lets me interact with Azure DevOps without leaving my development environment. I can retrieve work items, tasks, and issues from Azure DevOps using AI-generated queries. I can access acceptance criteria directly. This allows me to create precise prompts and generate test cases based on project requirements. If I come across new tasks while coding, I can ask my agent to create a new work item. This way I can pick it up later without losing context. AI agents get a better understanding of the current codebase by referencing work items and related repositories.

image: here you see our agent using the Azure Devops MCP to access the context of a work item, which it then analyzes and tells us what the most important test case is for that feature.

By integrating Azure DevOps with Cursor, I’ve reduced context-switching and manual interactions. My workflow is far more efficient.

The future of AI-driven development

AI-powered coding assistants like Cursor are reshaping how engineers build software. With AI-driven automation, we can reduce friction in our workflows. We minimize repetitive tasks. We focus more on creativity and problem-solving. My custom MCP for Azure DevOps is just the beginning. I’m constantly exploring new ways to integrate AI into my development process.

But what’s exciting today might feel outdated in just a few months or weeks. The pace of AI development is relentless. New breakthroughs, tools, and best practices emerge constantly. I can already imagine reading this post again after summer. I’ll realize how much further my workflow has evolved.

If you’re a developer looking to optimize your workflow, I recommend adopting AI tools now. The possibilities are vast, and the time savings are real. Coding without these tools feels like doing manual labor on a field. Slow, tedious, and exhausting. Now, we have tractors that let us work more productively. The industry is moving forward at a rapid pace. Those who don’t adopt AI-powered development will struggle to keep up.

The choice is clear. Adapt and accelerate, or risk being left behind.

Are you using AI in your development workflow? I’d love to hear about your experiences!