DEV Community: Kevin Meyvaert

Automating My Workflow with AI: A Web Engineer’s Journey

Kevin Meyvaert — Tue, 04 Mar 2025 14:41:02 +0000

I’ll be honest—I’m a bit lazy. Not in a bad way, but in the "how can I get more done with less effort?" kind of way. As a web engineer, I’m always looking for ways to improve my workflows so I can spend less time on repetitive tasks and more time on creative problem-solving. AI has become my weapon of choice, helping me build software faster and smarter than ever before. One of my favorite tools in this space is Cursor, an AI-powered coding assistant that has completely changed how I develop software.

Using Cursor to Build Software

Whether it’s writing boilerplate code, debugging issues, or generating complex logic, Cursor helps me accelerate my workflow. The seamless integration with my IDE allows me to:

Generate functions and components quickly
Get instant code suggestions and improvements
Debug and troubleshoot problems efficiently
Automate repetitive coding tasks

Thanks to this assistance, I can focus more on high-level architecture and problem-solving rather than getting bogged down by syntax and routine coding patterns. The best part? It’s incredibly easy to get started. Just install it, integrate it into your workflow, and watch it take over the tedious parts of coding. But while anyone can use Cursor, I’ve found ways to use it better—ways that go beyond just auto-completing code. Stick around, and I’ll share how I get the absolute most out of it.

Be Smart About Prompting

One of the most crucial aspects of working with AI tools is crafting effective prompts. The quality of the output is directly related to the quality of the input. Context is king—providing clear, well-structured instructions helps AI models generate meaningful and useful responses.

Here are some key principles to keep in mind when prompting AI:

Be Specific: Vague prompts lead to generic responses. Define what you need in detail.
Provide Context: The more relevant information you give, the better the AI understands your request.
Iterate and Refine: If the first response isn’t quite right, tweak your prompt and try again.
Use Examples: Providing examples or expected formats can help guide AI-generated content.
Break Down Complex Queries: If your request is complex, breaking it into smaller steps can improve accuracy.

By mastering prompt engineering, engineers can unlock AI’s full potential, making it a highly effective assistant rather than just a tool. However, while prompting can generate impressive results, it also comes with its own set of challenges.

Treat Your Agent Like an Intern

One of these challenges is making sure AI-generated code adheres to your team’s or organisation’s coding standards and practices. Just like an intern or junior engineer, your AI assistant needs guidance to produce high-quality work. While AI can generate impressive results, it doesn’t inherently know the best coding practices your team follows. That’s why I leverage Cursor Rules to ensure the AI’s output aligns with the coding standards we agreed on as a team.

Cursor Rules act as safeguards, enforcing best practices and preventing AI from generating inconsistent or subpar code. These rules include:

Formatting Standards: Ensuring consistent indentation, naming conventions, and style guidelines.
Code Quality Checks: Avoiding anti-patterns, enforcing modularity, and ensuring proper documentation.
Performance Considerations: Encouraging efficient algorithms and minimizing unnecessary computations.
Security Practices: Ensuring safe handling of data, 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.

Essentially, 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 to adhere to best practices.

Getting Structured Output in Large-Scale Projects

Another major hurdle is consistency of output—due to the inherent stochastic nature of large language models, if you ask an AI to generate the same code multiple times, you’ll often get different implementations. This can lead to fragmented code, redundant logic, and a lack of cohesion across your project. In small scripts, this might not be a big deal, but in larger projects where multiple people work on the same code, maintaining a structured and scalable architecture requires more than just good prompts.

To address this, I use Nx Generators —a tool that automates the creation of components, modules, and configurations based on predefined templates—to establish scaffolding structures that guide my Cursor agent. Nx Generators provide a consistent framework for AI-generated code, ensuring:

Standardized Implementations: Combined with Cursor rules we can instruct the agent to use specific generators when doing certain actions, reducing inconsistencies.
Codebase Uniformity: Every component, service, or feature is generated with the same patterns, making collaboration easier.
Scalability: Large projects remain maintainable because AI adheres to 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 has to offer. It’s a powerful tool for managing large-scale projects, enforcing modularity, optimizing builds, and streamlining workflows across multiple teams. Using Nx, I ensure that AI-generated code doesn’t just fit into the project—it enhances the overall architecture and development experience.

Introduction to Model Context Protocol (MCP)

MCP, an open protocol developed and pioneered by Anthropic, is the sauce that helps AI understand and interact with the tools engineers use every day. It acts as a bridge between a large language model (LLM) and external services, like codebases, issue trackers, and deployment pipelines. Or as they describe it: “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 is designed to:

Provide structured context to AI models, improving response accuracy.
Facilitate interactions with external systems, reducing manual overhead.
Enhance automation by leveraging AI-driven commands within development workflows.

By leveraging MCP, engineers can create more intelligent and efficient integrations between AI tools and their software development lifecycle.

Building a Custom MCP server for Azure DevOps

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

This integration allows me to interact with Azure DevOps seamlessly without leaving my development environment. Here’s how it works:

Fetching Work Items: I can retrieve work items, tasks, and issues from Azure DevOps using AI-generated queries.
Accessing Acceptance Criteria: By accessing work items, I can directly reference acceptance criteria, allowing me to create precise prompts and generate test cases based on project requirements.
Tracking “Side Quests” in Real-Time: If I come across new tasks while coding, I can ask my agent directly to create a new work item, ensuring I can pick it up later without losing context.
Better Contextual Awareness: AI agents can get a better understanding of the current codebase by referencing work items and related repositories within the project.

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 significantly reduced context-switching and manual interactions, making my workflow far more efficient.

The Future of AI-Driven Development

The rise of AI-powered coding assistants like Cursor is reshaping how engineers build software. With AI-driven automation, we can reduce friction in our workflows, minimize repetitive tasks, and 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 even weeks. The pace of AI development is relentless, and new breakthroughs, tools, and best practices emerge constantly. I can already imagine reading this post again after summer and realizing how much further my workflow has evolved—how even more seamlessly AI has integrated into my development process.

If you’re a developer looking to optimize your workflow, I highly recommend hopping on the AI wave now. The possibilities are endless, and the time savings are game-changing. Coding without these tools feels like doing manual labor on a field—slow, tedious, and exhausting. But now, we have shiny tractors that let us work more productively. The industry is moving forward at a rapid pace, and 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!

Introducing the Hubble ecosystem: an automated design and documentation system

Kevin Meyvaert — Thu, 02 May 2019 10:45:58 +0000

This post originally appeared on the In The Pocket blog.

At In The Pocket, we've been theorycrafting about design systems for quite some time now. In our Shift article on the future of design systems, which we published at the end of 2018, we addressed the challenges of working towards a full fledged future-proof automated design system. Today we are glad to announce that we have moved past theory and that we are launching the first version of Hubble, our automated design and documentation system.

The Hubble origin story: peeking into deep space

We have been around for quite some time now and have grown as a team and as a company. As our clients and projects got bigger over the years, we have been forced to adapt, optimize our workflows and improve our tooling to meet client needs and increase our own productivity.

At first, we used a screen-based design approach; we had to update hundreds of screens, update a multitude of prototypes and review each one of them every step of the process. Friction between design and engineering was huge and maintenance was hard.

When we started the first React projects at In The Pocket, we embraced atomic design as a new way to increase productivity and agility. We created a library with the best possible atoms for design and engineering. We became increasingly more consistent and created the routine of documenting everything along the way.

Progress was being made. However, we were still defining our design in two completely separate locations. In our case, for design, this was being done in Zeplin. Developers had to copy the styles from Zeplin into the codebase, which was a process very prone to inconsistencies and errors. At this point, friction between design and engineering was still big, but we worked more smoothly than before. We had a solid component library, however, this was no automated design system - yet.

Over the last couple of months, a lot of small automation initiatives were taken by different teams, across different competences. These initiatives were focussed on trying to create an impact on our current way of working. We researched Sketch-to-code tools and design tokens, created a common component library, assembling our own create-react-app wrapper, generating automated documentation etc.

We decided to bundle those efforts and create a cross-competence design system team consisting of like-minded developers and designers. Project Hubble was born.

Shifting focus: scalable design automation

The goal of Hubble is to build the bridge between design and engineering by reducing the cost of having to do things over and over again, thus increasing productivity, and offering a single source of design truth which results in shipping faster, better and more consistent products.

To make sure we didn't lose focus when starting development on Hubble, we created a backlog of cool things we wanted in the system and split those functionalities in different tracks - epics if you will. This way, we could differentiate which features could mean quick wins for our organization and which features could bring long term value to the teams.

On one side we have the “design to development” track, which consists of everything related to “design to code” automation. The second track is the “document style guide” track that focuses on creating automated documentation which updates whenever a designer makes adjustments to the design files. Finally, we have the ”component” track, where we focus on creating an extensive library of fully accessible and reusable components for all our different technologies. This track was initiated from our React Web team, but React Native, iOS, Android and Xamarin are following.

This approach paid off, we are now in the process of rolling out Hubble in our first client projects and have a clear roadmap of features to make Hubble even better.

A team without vision is hard to keep alive

connecting design files with engineering projects. This consistency allows you to ship faster and build products with higher quality that need less effort to develop them. As Mary Poppins would say: it’s practically perfect in every way.

Yes, it’s open source

We use open source tools on a daily basis for a multitude of projects, that is why we decided to open source all the core tools that make Hubble great. On our Github page, you can find The Hubble Plugin, this plugin sends all the design data from the design tool to the Hubble App. The Hubble App is responsible for integrating the JSON tokens to your projects. Our Hubble Scripts are responsible for converting the design elements from design tools to JSON tokens. It can convert tokens to another format and keeps track of history. Other design elements that can't be converted to JSON - like images and fonts - can be uploaded through the app.

Get your hands-on experience with Hubble today and feel free to contribute to the future of design systems via our In The Pocket Github page.

Fixing hanging Gatsby 2 builds on Netlify

Kevin Meyvaert — Fri, 28 Dec 2018 07:22:52 +0000

I have been working on a music festival website as a pet project for several years now. Last year I decided to rebuild the entire thing using the JAM Stack. Contentful + Gatsby + Netlify. It's great, fast, scalable and for my usage, completely free.

A few months ago Gatsby released their v2 and I was eager to update the website and use all the new fancy stuff. However, shortly after upgrading, when making a build via Netlify, the builds got stuck at "Cached node version vx.x.x" step, and eventually timed out.

I did about 40 commits making slight changes to the code, reverting dependencies, trying different Node versions, but nothing worked. I decided to stop trying after I lost entire weekends trying to solve the issue.

I'm one of those stubborn developers. I had to fix this myself.🤦🏻‍♂️ Meanwhile, some months had passed, and I really had to start working on the 2019 edition website. For once, I had to call in the support cavalry.

Finally I got help from Chris & Dennis from Netlify support (shout out, you made my day). They pointed me to an issue on Github logged some months ago during Gatsby v2 Beta - where they address a bug, which is still in the latest version.

As it appears. The failing build is caused by a Jest worker child spawned by Gatsby during the build. But when the parent Jest worker is exited, the child keeps existing, causing the build on Netlify to time out.

Solution

TL;DR
Don't use setTimeout on componentWillMount. But when you do, make sure you only execute it during runtime. (wrap it in a typeof window !== 'undefined' check)

Also. Don't use componentWillMount at all. Use hooks, like all cool kids do.😎🆒

Anyway, this issue made me lose a lot of time and gave me my first grey hairs. I hope writing this will help someone in the near future.

PS: This issue also occurs when using certain firebase or aws-amplify functions in componentWillMount - as they also use setTimeouts.

A single source of truth: the future of design systems

Kevin Meyvaert — Tue, 27 Nov 2018 12:08:42 +0000

Last year at Shift we talked about getting started with design systems: living style guides that are collaborative and code-connected. This concept is gradually finding its way into our workflows and great examples are already out there. At In The Pocket, we are continuously improving our efforts to implement design systems in existing and new projects for our partners, but while doing so, new challenges arise. Usually design systems are initiated and owned by the designer or design team. During the implementation of the designed screens, discrepancies with the original design will start to occur sooner or later.

The approach of making an interaction and visual design for every screen has long been the standard for mobile app design. This approach is clear for clients as well as developers and suits the needs of small products with a short lifespan. Nowadays we build products that are long-lasting, require more maintainability, need scalability and are consistent across a variety of platforms and other products in an organization. These products demand a different and more efficient approach to design and tooling.

The main challenge we are facing now is the fact that tools don’t communicate with each other in a desirable fashion. Details fall through the cracks, and important nuances get lost. There is a huge gap between design and engineering; to make sure we stay on top of the constant changes, a lot of time-consuming manual work still has to be done. When a new designer or developer joins the team, there is a need for a swift onboarding process and good conclusive documentation to get started on the project. Designers should be able to move quickly from ideation to production, and developers should be enabled to dive straight into the code.

The way we work today can broaden the gap between engineering and design, and the many layers between designing and building are a burden. We can do better. We can work better. - Alex Schleifer, Airbnb

When we look at what is happening in the industry, we see other companies facing these challenges as well. Companies like Airbnb have invested a lot of resources in developing specific tools to maintain a design language while enabling them to close the gap between design and development - a gap that has only gotten bigger in the last couple of years. Software development has become a lot more collaborative due to the availability of a plethora of tools, making engineering increasingly productive. In comparison, design tooling has been lagging behind.

When talking about design systems, the main issue these companies are facing is that they often focus on one workflow, one technology, which makes it very hard for that system to match or integrate into other systems. Ideally, they want their system to be entirely decoupled from one specific technology and toolkit, making it ‘plug-and-play’ for any given environment. In the long term, this could be achieved by creating a generic file format from which any design tool or new technology can import, and export to one source of truth.

To support this idea of what is basically one source of truth for design and development, we started building our own system with a cross-competence team. Using our atomic design approach, we analysed which components and patterns we currently have and created new ones to fulfil the need to build a complete product.

This is an excerpt from an article I wrote for Shift, our annual report on the next big trends in digital. It is read by more than 1,000 experts worldwide. Join the conversation and get your free copy today! The article on design systems continues on page 89.

Download your copy of Shift here!

This article was authored by @behangmotief and @maartenderoeck for @itpocket.

React Native is dead, long live React Native

Kevin Meyvaert — Wed, 20 Jun 2018 15:40:37 +0000

This post originally appeared on: In The Pocket blog.

A lot of rumbling and commotion on the Twitter-sphere and tech blogs today. Last night, Airbnb released a five-part series of blog posts on Medium covering their experience and findings using React Native, concluding with the announcement that they’re saying goodbye to React Native by the end of this year.

“Due to a variety of technical and organizational issues, we will be sunsetting React Native and putting all of our efforts into making native amazing.”

This news comes as quite the surprise - as Airbnb has been continuing its efforts in pushing development on open source projects and workflow-tools for React Native, i.e. the Lona announcement last month at React Europe - but before getting all caught up in doomsday-tweets and cross-platform rants…

Airbnb was one of the first major Silicon Valley start-ups to adopt React Native in 2016, which was shortly after it was released mid 2015. At that time, Airbnb had a native iOS and Android stack on mobile and a React stack for web. Given the good experience with React, they decided to embrace React Native to speed up their native development. The implication of this migration (which didn’t become apparent immediately) was that it created a lot of overhead. They had to invest a lot of extra effort in writing supporting functionality (e.g native bridges, wrapper code, ...) in order to be able to support (existing) native functionality through Javascript. As well as maintaining these libraries for every iOS, Android & React update. Next to a technical challenge, it also proved to be an extra organisational challenge for them.

As their original intent was to ‘move more quickly as a company’, using React Native is no longer a viable strategy for Airbnb due to multiple reasons. Does this mean we should turn our backs to React Native? We think not. We can relate to a lot of the issues mentioned in the blogpost. But the scale at which Airbnb operates (for reference, they have 100 developers working on their mobile app, at In The Pocket, a product team usually consists of 4-10 developers) and the depth of their investment together with the product & UX requirements of their application are a big reason for their decision to abandon React Native. As with any tool, you should know/anticipate for its limitations.

“Hybrid Apps Are Hard.”

Although React Native is a Javascript framework, most React Native developers know at least two platforms (Android, iOS, React Native). While working with React Native applications at In The Pocket over the last year-and-a-half we have learned that knowing common native patterns (like navigation..) is a valuable asset, and at some point you’ll eventually have to introduce some native parts in your codebase. And yes, this brings extra complexity - but in the end, we really want to stick to Javascript as much as possible - albeit with Native integrations under the hood.

“...we wound up supporting code on three platforms instead of two.”

At Airbnb they have 220 screens in React Native, but additionally they have about 880 native screens per platform, which basically means they only have 20% functionality living in React code. “Many of the difficulties we encountered were due to the hybrid model approach we took” is also one of the lessons we learned from combining native and React code in the projects we work on. However, these difficulties shouldn’t be a setback when choosing to use React Native as a platform.

“When everything came together, which it did for many features, the iteration speed, quality, and developer experience matched or surpassed all of our goals and expectations. At times, it really felt like we were on the verge of changing the game for mobile development.”

Even though Airbnb has now decided to ‘sunset’ React Native in their mobile products, this should not have a negative impact on the future of React Native. Airbnb’s major open source projects (Lottie, react-native-maps,..) that we use on a daily basis are being handed over to the React Native Community. Having read all five blog posts we can safely say that React Native was no longer a fit for the scale of Airbnb’s applications when considering maintainability and sustainability. In the end, they have proven that React Native is an extremely powerful framework that can handle and scale big production apps. But like any tool, it isn’t always the right one for the job.

Here at In The Pocket, we still believe we’re at the dawn of some great evolutions in mobile app development when talking about React Native. The community is ever so active, with Facebook announcing they’re working on a big-scale rearchitecture to make the framework more flexible and integrate better with native infrastructure, and companies like Expo making big breakthroughs creating libraries like react-native-gesture-handler. We are continuing our efforts to bridge the gap between development & design, using tools based on React components, improving our workflow and iteration speed, and by doing so create more value for our clients.

React Native is not dead.

Thanks to @bitcrumb, @jodierckens & @thomasmons for helping me write this post.

Our key takeaways from React Europe 2018

Kevin Meyvaert — Tue, 22 May 2018 19:35:09 +0000

Last week, developers from all over Europe gathered in Paris for the yearly React Europe conference. As the React landscape is changing ever so rapidly, we sent our own In The Pocket delegation to find out all about the new and upcoming goodness in the React Community.

With the release of React 16, and more recently 16.3, the React core got a complete overhaul. By enabling developers to prioritize rerenders of their components, React has become an even more powerful tool to build performant interfaces across platforms. However, these features were announced last year, so we were very curious what this year’s talks would learn us about the future.

Typing and the premise of ReasonML

Typing was a hot topic at this year’s React Europe conference, several talks covered the benefits and need for a typed language when programming React applications. Caleb Meredith - working on Oculus, and previously on Flow at Facebook - did an extensive talk on subtyping in Javascript, and the technical drawbacks of using that pattern.

Using typed programming languages has the benefit of discovering errors more early on in the development process, it makes sure you don’t make wrong assumptions while developing certain features in your app - and thus, make fewer errors. Michel Weststrate - creator of MobX - made the following analogy:

“When Napoleon invaded Russia, he went to Moscow and eventually lost most of his army. What was his mistake? Making the assumption there would be enough food in Russia to feed his army.”

A solution for writing typed code for React - and one that is already being adopted by some big influential companies - is ReasonML. ReasonML is a subset of Ocaml, created by Facebook. Jared Foresyth talked about how React development today is about leveraging code safety & power. “React was not made for Javascript”, he stated. Today we use patterns (types, immutability,...) that aren’t native to Javascript. We have adopted devtools like Flow, but the process of setting up a custom type-system with Flow is usually cumbersome and time-consuming.

Adopting ReasonML today for creating React apps still has some drawbacks on Javascript development, as the community is much smaller, fewer packages are available, and some frequently used API’s - for Firebase i.e. - don’t have a ReasonML implementation. However, I think we’re about to hit a turning point. Today, ReasonML still compiles to Javascript, but the team working on ReasonML have announced they’re working on a cross-compilation tool, to export to Native code! Which would mean we could run React Native apps completely on the main thread of mobile devices.

React Native on the web: revisited

The last year we’ve noticed more and more developers in the community experimenting with cross-platform implementations for React, like React Native Web - which we demoed on our React Academy earlier this year. One of the talks that caused a lot of hype at the conference was “Bridging React Native back to its roots”, by Vincent Riemer.

As an experiment, he made a browser implementation for Yoga - the same layout framework that powers React Native. But he stumbled upon rendering the entire application in the browser with Yoga, which was not performant at all. He then tried running React in a webworker, but ran into technical limitations and dropped the project.

Fast forward a couple of months. Meanwhile, Vincent worked with React Native and started experimenting with React Native Web. He stumbled upon the fact that React Native Web was not really native, and had too much of a web-first approach. He wanted to create a development experience that allowed him to write React Native code and run it everywhere.

Enter React Native Dom. React Native Dom is a web-browser implementation for React Native. Following the native architecture, all your app and component logic runs on a webworker, while the main thread can focus entirely on rendering. Using Yoga to render the layout, we can access all the animation goodness in the browser as if we would use it on native devices. Last but not least, React Native Dom uses the same bundler as existing React Native projects, allowing for a familiar development and debugging process.

After the demo, excitement filled the room.

Beyond React: a glimpse into the future

Usually, when Airbnb sends a speaker to a conference, cool things are bound to happen. Devin Abbott - creator of developer- and design-tools at Airbnb - walks onto the stage.

“Should we use React? The answer is always yes.”

The future of React is a future where we can write our application once, and compile it so we can run it everywhere, without making changes to our stack, which is the main cost of using cross-platform React at the moment.

After a demo showing a React component being transpiled to Swift, in real-time - yeah, that happened - Abbott stated: “React is a data format for describing components at compile-time”. To describe a component, you only need a JSON. However, at Airbnb they propose using React Native components as single source of truth, as they are easier to visualize then JSON data.

Drum roll. Introducing Lona.

Lona is a design-tool for developers and a development-tool for designers. Building components is boring, Lona allows you to visually compose and maintain your components. Basically Storybook meets Sketch. It is still in early early Beta but the demo is looking amazing!

React is here to stay

It is really exciting to see how the React community is continuing its efforts to make React a truly cross-platform framework. This week we have seen new interesting proposals to improve the React developer experience - by using typed languages. Promising new collaboration tools for designers and developers that will make processes easier and increase productivity. And most of all, proof of a big and active community.

Looking forward, the React ecosystem is evolving into a powerful cross-platform framework for building mobile, web and AR/VR apps. We’re stoked to experiment with the new features and libraries that were announced in Paris. Keep an eye out for our next React Native Academy on our socials!

Originally posted on In The Pocket.