DEV Community: Hadil Ben Abdallah

Learn Programming by Building Real Projects With Hyperskill

Hadil Ben Abdallah — Thu, 17 Sep 2026 09:07:26 +0000

Hadil Ben Abdallah

Sep 16

Stop Watching Coding Tutorials: Learn by Building Real Projects With Hyperskill

#python #java #android #c

14 min read

Stop Watching Coding Tutorials: Learn by Building Real Projects With Hyperskill

Hadil Ben Abdallah — Wed, 16 Sep 2026 09:05:06 +0000

Learning to code can feel easy at first. You watch a lesson, understand a new concept, solve a few exercises, and you start feeling like you have made progress. Then you open a blank editor and try to build something on your own, and knowing how a loop, API, database, or class works does not feel quite as useful as it did five minutes ago.

Programming is a practical skill, and at some point, tutorials have to turn into projects, bugs have to turn into debugging sessions, and individual concepts have to come together inside something that works.

That is the idea behind Hyperskill, a learning platform built around project-based programming education. Its courses put hands-on projects into the learning process, giving learners opportunities to apply new concepts as they progress.

The platform currently covers areas including Python, Java, Kotlin, Web Development, Backend, Cloud & DevOps, Data Science, AI Engineering, AI coding tools, SQL, and more.

In this article, we'll look at what you can learn on Hyperskill, how its projects and development tools fit together, and whether a project-based coding platform makes sense for someone trying to build practical programming skills.

TL;DR

Hyperskill is a project-based learning platform for programming and software development. Its main idea is that you learn concepts while building projects, so writing and applying code becomes part of the learning process instead of something saved for the end.

The platform covers programming languages, career paths, AI, data, backend development, and other technical areas, with 400+ hands-on projects and 70+ courses.

Hyperskill was powered by JetBrains, connecting the learning experience with professional development tools. Learners can build projects using JetBrains IDEs, develop skills across multiple areas, and create projects that can become part of their portfolios and be shared on GitHub.

Here are some of the main things Hyperskill offers:

✅ 400+ hands-on projects
✅ 70+ courses
✅ Learning paths for Python, Java, Kotlin & Android, SQL, Go & C++, Web Development, Backend, Cloud & DevOps, Data Science, AI, and ML
✅ Code-quality feedback and adaptive practice
✅ Certificates to document completed learning
✅ Projects that can be shared on GitHub and used as portfolio pieces
✅ Access to professional JetBrains development tools
✅ Learning options for individual developers and organizations

The biggest takeaway is that Hyperskill puts building at the center of learning to code. You are not simply working through lessons and applying the knowledge later; the projects give you a place to use what you learn as you progress.

Why Building Real Projects Matters When Learning to Code

There is a big difference between being able to explain a programming concept and being able to use it when building software.

You might understand what an API does, know how a for loop works, or recognize the difference between a list and a dictionary. That knowledge matters, but software development rarely gives you one isolated problem at a time. A real project might require you to combine several concepts, decide how to structure your code, deal with unexpected input, debug an error, work with external tools, and figure out what to do when your first solution does not work.

That is where projects become valuable.

When you build something, the knowledge you just learned has somewhere to go. A lesson about functions becomes part of an application. Database concepts become queries inside a working program. An API lesson becomes an actual integration. You start seeing how individual pieces of programming fit together because you are using them to solve a concrete problem.

This also changes how you discover what you do and do not understand.

A concept can feel clear while you are following an explanation. Try using it without someone telling you the next step, though, and the gaps become clear. You may realize that you understand the syntax but struggle with the structure, or that you can follow an example but cannot adapt it to a different requirement.

That is not a failure. That is useful feedback.

Building projects gives you more opportunities to encounter those gaps, fix them, and try again.

And that matters when your goal is to become a developer.

A portfolio project also gives your learning a visible result. You can look back at something you built, improve it, put it on GitHub, and use it as evidence of what you can do.

What Should You Look for in a Coding Skills Platform?

There are plenty of ways to learn programming online, so choosing a platform can become difficult. Two websites can both promise to teach Python or Java while offering completely different learning experiences.

There are a few things I would look at while choosing a coding skills platform.

1. How much actual coding you will do

If most of your time is spent watching explanations and answering multiple-choice questions, you may gain knowledge without getting enough practice applying it. A useful coding platform should give you regular opportunities to write code, make decisions, encounter errors, and work toward something concrete.

2. How the learning is structured

A huge library of courses can sound impressive, but having hundreds of disconnected lessons does not make learning easier. Good structure helps you understand what to learn first, what comes next, and how each new skill connects to the bigger picture.

3. Are you getting feedback?

When you are learning alone, it is easy to keep repeating the same mistake without realizing it. Code-quality feedback, automated checks, explanations, and targeted practice can help you catch those problems while you are still working on them.

4. What you actually build

If you want to become a backend developer, for example, you will eventually need more than syntax exercises. You want experience working with things such as APIs, databases, authentication, frameworks, debugging, and application structure. The projects should reflect the skills you are trying to develop.

5. What is the development environment like

Learning in an environment that resembles the tools developers use professionally can make the transition into real development work easier. So in this case, it's very helpful to work directly in a popular IDE.

6. What happens after you finish learning something

Can you point to a project?
Can you explain what you built?
Can you show the code to someone else?
Can you continue improving it?

Those are practical signals that your learning is producing something tangible.

So, if we use those criteria to evaluate a coding platform, the more important part is not how many courses it has. It is what happens when you sit down and build.

That brings us to Hyperskill.

What Is Hyperskill?

Hyperskill is an online learning platform focused on programming and software development, with a strong emphasis on learning by building projects.

The platform was powered by JetBrains, the company behind development tools such as IntelliJ IDEA and PyCharm. That connection is more than a logo on the homepage: professional JetBrains tools are part of the learning experience, giving learners a chance to practice inside development environments that are familiar to many professional developers.

Until now, more than 1.2M developers have learned on Hyperskill, alongside more than 400 hands-on projects and 70+ courses.

Hyperskill is not built around one narrow programming track. You can start with a language, move toward a career path, explore a technical subject, or develop skills around newer areas such as AI.

The most interesting part of the Hyperskill approach is how the projects are used while you learn.

And that's what makes this platform different from a typical online programming course.

How Hyperskill’s Project-Based Learning Approach Works

The easiest way to understand Hyperskill is to look at what happens when you start a course.

You do not have to wait until you finish a long series of lessons before touching a real project. Hyperskill's project-based learning model lets you start applying concepts as you progress, with projects serving as part of the learning process itself. Its Premium page describes this as starting projects from day one and learning what you need along the way.

That changes the role of practice.

Imagine you are learning Python. You might first encounter variables, conditions, loops, functions, and data structures as individual concepts. As those ideas accumulate, you can use them to build something that has an actual purpose. The project gives those concepts context, and the problems you encounter while building show you where your understanding is solid and where you need more practice.

This is also why the projects do not feel like a final exam tacked onto the end of a course. The building itself is part of how you learn.

Programming rarely happens one concept at a time in the real world. Building software means combining things you have learned, figuring out how they interact, and dealing with problems that were not visible in the original lesson.

A project gives you a place to practice exactly that.

Learn by Building 400+ Hands-On Coding Projects

Hyperskill currently offers 400+ hands-on projects, giving learners a lot of room to practice beyond short coding exercises. The platform's Premium offering lists 400+ projects alongside features such as certification, adaptive practice, detailed code-quality feedback, and unlimited practice.

A beginner can start with a relatively small application and gradually move toward projects that require a wider range of programming skills.

Someone learning Java might work through applications and games while developing their understanding of core programming and object-oriented concepts. A Python learner can move into areas such as web development, databases, data analysis, machine learning, or backend development.

There are also projects for people moving into newer areas of software development. Hyperskill includes courses covering foundation models, AI agents, AI coding tools, and AI-assisted software development.

And these projects can have value beyond the moment when you submit them.

Hyperskill specifically highlights the option to upload projects to GitHub and use them as evidence of practical experience when building a professional portfolio. That makes the project itself more useful than an exercise that disappears as soon as you complete it.

Of course, completing a project does not automatically make someone job-ready. A portfolio also needs good code, clear explanations, thoughtful project choices, and evidence that you understand what you built. But having actual software to discuss gives you something concrete to work with.

What Can You Learn on Hyperskill?

Hyperskill has grown well beyond a platform where you pick one programming language and work through its basics.

Its current catalog is organized into several areas, including:

Python
Java
Kotlin & Android
SQL & Databases
Go & C++
Web Development
Backend
Cloud & DevOps
Data Science & Analysis
AI Engineering
AI Coding Tools
ML & Math

The platform offers 70+ courses across these categories.

You can start with a language if you are still building your programming foundation. Python has courses ranging from fundamentals to backend development, data analysis, algorithms, Django, Flask, and machine learning. Java has paths covering core development, backend development with Spring Boot, full-stack development, and other areas.

You can also start with a career direction.

Someone interested in backend development can work with technologies such as Java, Spring Boot, Python, Django, Flask, SQL, and security. A person moving toward data science can study statistics, data preprocessing, visualization, machine learning, SQL, NLP, or data engineering.

And then there is the growing AI section.

Hyperskill Courses and Career Paths: Learn Beyond a Single Programming Language

Learning one programming language is useful, but professional software development usually requires a broader set of skills. A backend developer needs to understand more than Java or Python. A data scientist needs more than Python syntax. Someone building AI applications needs to understand how models, APIs, data, software architecture, and development tools come together.

Hyperskill's career-oriented categories reflect that reality.

Alongside individual language tracks, the platform currently includes paths and courses around:

Web Development
Backend
Cloud & DevOps
Data Science & Analysis

That makes it possible to start from a programming language and move toward a broader technical direction.

For example, a learner starting with Python can eventually move into Django, Flask, databases, data analysis, machine learning, or backend development. A Java learner can move from language fundamentals toward Spring Boot and backend application development.

The same pattern appears in AI.

Learn AI and Modern Development Skills With Hyperskill

AI is no longer limited to learning how machine learning algorithms work. Developers need to understand how to build applications around foundation models, work with AI coding tools, and integrate AI into existing development workflows.

Hyperskill's current catalog includes courses such as:

Introduction to AI Engineering with Python
AI Agents: Theory and Practice
Building AI Applications with Foundation Models
AI Tools for Developers: Master Code Generation & Automation
Software Development Fundamentals for AI Coding

The practical focus continues here too. The AI Engineering course includes projects around foundation models, retrieval-augmented generation, AI agents, and deploying AI services, while the AI coding courses focus on using modern AI tools as part of software development.

That gives developers who already know how to code a way to expand into AI without treating programming and AI as completely separate worlds.

Practice Coding With Professional JetBrains Development Tools

There is another part of the learning experience that becomes important once you move beyond basic coding exercises: the environment where you write your code.

Hyperskill was powered by JetBrains, and its Premium offering lets learners work on projects using JetBrains IDEs. The platform describes these as the same development tools used by engineers at more than 300,000 companies worldwide.

Premium includes access to the JetBrains All Products Pack starting from the second month, subject to the eligibility requirements.

That means learners can practice inside tools such as IntelliJ IDEA and PyCharm while working through their projects.

How Hyperskill Adapts Practice to Your Learning Pace

Learning speed is not the same for everyone.

Some topics click immediately. Others need several attempts before they become comfortable. Hyperskill's Premium offering includes adaptive problems that adjust to the learner's pace, along with unlimited practice, hints, spaced repetition, and detailed code-quality feedback.

That matters because good practice is not only about doing more exercises. It is also about spending more time where you need it.

If you already understand one concept, repeatedly solving the same basic problem does little for you. If another concept keeps causing mistakes, additional practice and feedback can help you close that gap.

This creates a learning loop that makes sense for programming:
learn a concept → use it → make mistakes → get feedback → practice again → keep building

Hyperskill for Teams: Upskilling Developers With Structured Learning

Learning programming is one thing. Keeping an engineering team’s skills up to date is a different challenge.

A developer might be strong in backend development but need more experience with cloud technologies. Another team member might want to move into AI engineering. Someone else may need to strengthen their Python or SQL skills. Giving everyone the same course does not always make sense when the team's skill levels and responsibilities are different.

Hyperskill also has a business offering designed around this problem. The platform gives organizations tools to help employees develop technical skills through structured learning, hands-on projects, and progress tracking.

The team experience goes beyond giving developers access to a course library. Managers can work with skill development information to understand where employees need more practice and keep an eye on their progress as they move through their learning paths.

That can make structured upskilling easier to manage, especially for teams that want developers to keep learning while continuing their regular work.

Hyperskill vs. Traditional Coding Courses

The biggest difference between Hyperskill and a traditional programming course is when you start building.

A conventional online course might follow a familiar pattern: watch a lesson, read an explanation, answer a few questions, and continue to the next topic. At the end, you may get a larger assignment that asks you to put everything together.

Hyperskill puts projects closer to the center of the learning process. You learn concepts, apply them to projects, receive feedback, and continue building as you progress through the course.

Learning approach	Traditional course	Hyperskill's project-based approach
Learning concepts	Lessons and explanations	Lessons and explanations
Coding practice	Exercises may accompany lessons	Projects are integrated into learning
Building software	Often comes later	Starts throughout the learning path
Feedback	Depends on the platform	Code-quality feedback is available
Portfolio material	May require separate projects	Projects can become portfolio pieces
Development tools	Varies by course	JetBrains development tools are part of the experience
Progress	Course completion	Skills, practice, and project progress

This does not mean traditional courses have no value. A well-made course can be an excellent way to understand a difficult concept or get introduced to a new technology.

The difference is what happens after you understand the explanation.

With a project-based approach, you have to do something with that knowledge. You have to write the code, make decisions, deal with errors, and get the application working. That repeated transition from learning to building is the core of Hyperskill's approach.

Who Is Hyperskill Best For?

Hyperskill can make sense for different types of learners, but the platform will be especially useful for people who want their coding education to involve regular hands-on work.

Beginners learning their first programming language can use structured courses and projects to move from basic concepts toward working applications. The projects give new programmers a concrete reason to use concepts such as variables, loops, functions, data structures, and object-oriented programming.

Developers expanding their existing skills can use the platform to move into another language or technical area. Someone comfortable with Python, for example, might want to explore backend development, data science, machine learning, or AI engineering.

Developers building a portfolio can benefit from having actual projects attached to their learning journey. Those projects can be uploaded to GitHub and used as examples when showing potential employers what they have built.

Developers moving into AI have another reason to look at the platform. Hyperskill includes courses covering AI engineering, AI agents, foundation models, AI coding tools, and related subjects, giving programmers a way to develop modern AI skills through practical work.

Engineering teams and organizations have a separate use case: structured technical upskilling, skill-gap analysis, and progress tracking across employees.

It is also worth being realistic about what Hyperskill can and cannot do. Completing a course will not magically turn someone into a professional developer. You still need to think through problems yourself, write code outside guided exercises, work on increasingly difficult projects, and gain experience dealing with software that does not come with instructions.

Start Learning and Building Now 🔥

Frequently Asked Questions

What is Hyperskill?

→ Hyperskill is an online learning platform focused on programming and software development. Its courses use a project-based approach, allowing learners to apply what they learn while building hands-on projects across areas such as Python, Java, Backend, Data Science, AI, and more.

Is Hyperskill good for beginners learning to code?

→ Yes. Hyperskill offers structured learning paths and projects that allow beginners to practice programming concepts as they learn them. The project-based format can be useful for learners who want to move beyond watching lessons and start writing code regularly.

Can you build portfolio projects with Hyperskill?

→ Yes. Hyperskill's projects can give learners concrete work to add to their portfolio and share on GitHub. The value depends on the quality of the project and your ability to explain the code and decisions behind it, but having working projects gives you something tangible to showcase.

What is the best way to learn coding skills online?

→ There is no single method that works equally well for everyone, but effective programming education usually combines explanations with consistent hands-on practice. Building projects, solving problems, debugging your own code, and receiving useful feedback can help turn programming concepts into practical skills.

Should you learn a programming language or build projects first?

→ You need both. Learning programming fundamentals gives you the knowledge required to write code, while projects give you opportunities to apply that knowledge in realistic situations. A strong learning path connects the two so that new concepts quickly become something you can use.

Final Thoughts

There is a point in every developer's learning journey where watching another tutorial stops being enough.

You need to open the editor and build something.

That is the idea Hyperskill puts at the center of its learning experience. Its courses combine structured learning with hands-on projects, giving learners a place to apply new concepts as they progress. With hundreds of projects, courses across programming languages and career paths, JetBrains development tools, code-quality feedback, certificates, and adaptive practice, the platform covers much more than the basics of learning a programming language.

The project-based approach also gives learning a visible outcome. You finish with code you have written, problems you have solved, and projects you can continue improving and potentially share as part of your portfolio.

For developers, that practical side is what makes the approach worth considering.

You do not learn programming only by knowing what a function, API, database, or machine-learning model does. You become better at development by using those things to build software, running into problems, figuring them out, and doing it again with a little more confidence each time.

Hyperskill is a place where learning to code and building software happen together.

Thanks for reading! 🙏🏻 I hope you found this useful ✅ Please react and follow for more 😍 Made with 💙 by Hadil Ben Abdallah

Hadil Ben AbdallahFollow

Software Engineer • Technical Writer (300K+ readers & 25K+ followers) • Trusted by 20+ startups and tech companies worldwide I turn brands into websites people 💙 to use

Nexpath Review: Can an AI Prompt Quality Layer Make AI Coding Safer?

Hadil Ben Abdallah — Fri, 11 Sep 2026 09:26:59 +0000

AI coding tools have made it easy to go from an idea to working code.

You describe what you want, send the prompt, and a few moments later you have files, components, logic, and sometimes an entire working app.

That speed is great until the prompt leaves something important unsaid.

Maybe the requirement is too vague. Maybe nobody mentioned how the feature should be verified. Maybe an existing behavior needs to stay intact. Maybe the change sounds small but has consequences that are easy to miss.

This is where Nexpath comes in.

Nexpath doesn't try to be another coding environment where you build your project. It works as a prompt quality layer for AI-powered development, looking at the request you're about to send and adding guidance when it decides the task needs more structure or verification.

The idea is simple: keep the speed of AI coding, but add a checkpoint before an underspecified request turns into code.

I wanted to look at how that idea works in practice, what Nexpath adds to a coding workflow, what its browser extension offers for tools such as Replit, Lovable, and Bolt, and whether its benchmark results give the idea some evidence behind it.

TL;DR

Nexpath is a prompt quality layer designed to add structure and missing checks to AI-assisted development. It can work with browser-based coding tools, including Replit, Lovable, and Bolt, as well as Claude Code, Cursor, and Windsurf through its other integrations.

Its first major feature is Prompt Enhancement. It preserves the original request and adds relevant guidance when a task needs more rigor. Depending on the task, that guidance can include:

Acceptance expectations
Verification steps
Reproduction details
Constraints
Risk or confirmation guidance

You remain in control of the final prompt. The original request stays available, and you can review the suggested version before sending it.

Nexpath's published SWE-bench Verified test compared Claude Code with and without Nexpath across 40 tasks. Claude Code solved 27/40 tasks, while Claude Code + Nexpath solved 29/40.

That benchmark is worth looking at, but two additional solved tasks out of 40 aren't enough to prove a large improvement. Nexpath itself makes that limitation clear.

Nexpath is built around a local-first approach, with prompt history stored locally and targeted requests sent out when guidance needs to be generated.

Why AI Coding Agents Still Need a Decision Layer

There's a reason AI coding feels so productive.

You don't need to translate every idea into a detailed implementation plan before you start. You can describe the feature in normal language and let the coding tool figure out much of the implementation.

That lowers the barrier to building software.

It also creates a new problem: the quality of the request can have a huge effect on the quality of the work that follows.

Consider a prompt like:

Add search to the task list.

A coding tool can do plenty with that sentence.

But what does "search" actually mean?

Should it search titles only?
Should it be case-insensitive?
Should results update while typing?
What happens when there are no matches?
Should existing filters continue working?
What needs to be checked after the change?

A developer who has been working on the project for hours may know the answers to some of these questions without writing them down.

The coding tool doesn't necessarily have that same context.

And that's where things can get messy.

And in this case, Nexpath isn't trying to take control of development. It's trying to make the things that are easy to overlook clearer.

What Is Nexpath?

Nexpath is an AI prompt quality engineering layer for AI coding workflows.

Its main feature, Prompt Enhancement, reviews the prompt you're preparing to send and adds development details that may be missing. The original intent stays intact, while the enhanced version can add structure around requirements, verification, constraints, safeguards, and other relevant checks.

The key word here is can.

Nexpath isn't designed to rewrite every prompt. It stays quiet when there isn't much to add and surfaces a suggestion when it detects that something like a vague specification, skipped test, or rushed deployment could benefit from additional guidance.

The basic idea is simple: you write the request, Nexpath reviews it, and you decide whether its suggestions are useful.

Nexpath doesn't replace your original prompt

Another important detail is how Nexpath handles the enhanced version.

The benchmark results provide a concrete example of this. Across all 40 SWE-bench Verified tasks, Nexpath preserved the original prompt word for word and appended additional guidance underneath it.

That creates an important distinction. Nexpath isn't asking you to throw away your request and use an entirely different instruction. It's adding development considerations around what you already asked for.

The browser extension follows the same principle. When Nexpath suggests an enhancement, the original request remains visible alongside the suggested version, allowing you to review the changes before deciding what to send.

The browser workflow in four steps

For browser-based coding tools such as Replit, Lovable, and Bolt, the process looks like this:

1. Write your prompt

Write the request you want to send and submit it as you normally would.

2. Nexpath reviews it

If Nexpath determines that the request needs additional attention, it briefly holds the prompt and opens its side panel. Your original request remains available while the enhanced version is prepared.

3. Review the suggestion

The enhanced prompt can introduce details such as clearer scope, constraints, acceptance expectations, verification steps, or safeguards, depending on the task.

4. Choose what to send

You can send the enhanced version or continue with your original prompt. Nexpath doesn't automatically decide which version your coding tool should receive.

This keeps the developer responsible for the final decision. Nexpath provides additional context around the request, but you remain the person deciding what should actually be built.

How Nexpath decides what to add

Nexpath describes its prompt enhancement process through four stages:

Understand: Review the request, current development stage, and relevant workflow signals while preserving the original intent.
Structure: Add useful sections covering areas such as scope, constraints, acceptance expectations, and verification.
Safeguard: Introduce risk, confirmation, rollback, or evidence requirements when the task calls for them.
Review: Give the developer an opportunity to inspect or edit the enhanced prompt before deciding what to send.

This means the resulting prompt can vary depending on the task.

A straightforward UI change may need only a small amount of additional guidance, while a complex code change or deployment-related request may benefit from more detailed checks.

The goal isn't to make prompts longer. It's to add the development information that is relevant to the work being requested.

Nexpath Browser Extension for Replit, Lovable, and Bolt

One of Nexpath's newest additions is its browser extension for Replit, Lovable, and Bolt, bringing the prompt quality layer directly into the browser-based coding tools developers already use.

The workflow is simple. You write your prompt in Replit, Lovable, or Bolt as usual, and Nexpath reviews it before the request reaches the coding agent. When it finds something that could benefit from more structure, it opens its side panel with an enhanced version of the prompt. You can then review it, choose the enhanced version, or continue with your original request.

This can be useful for developers who like the speed of building with AI coding platforms but don't always want to write a detailed specification for every request. Nexpath can help add things such as acceptance expectations, verification steps, constraints, or other relevant checks when they are needed.

If you already write highly detailed specifications with acceptance criteria and verification steps for every change, the additional value may be smaller.

The extension is available for both Chrome and Firefox, so you can use it directly while working in your preferred browser.

For Replit, Lovable, and Bolt users, that means Nexpath can become part of the normal coding workflow without requiring a separate application or a different way of building. You keep using the platform you already know, while Nexpath adds an extra review step when a prompt needs it.

Nexpath Beyond the Browser Extension

The browser extension isn't the only way to use Nexpath. Its current documentation also covers Cursor, Windsurf, and Claude Code, giving developers options for different types of AI-assisted development workflows.

For editor-based development, Nexpath supports Cursor and Windsurf through its VS Code extension.

Nexpath also documents a CLI workflow for Claude Code, bringing the same prompt-quality approach to terminal-based coding sessions.

The integrations currently documented by the project are:

Coding environment	Nexpath integration
Replit	Chrome / Firefox extension
Lovable	Chrome / Firefox extension
Bolt	Chrome / Firefox extension
Cursor	VS Code extension
Windsurf	VS Code extension
Claude Code	Nexpath CLI workflow

The broader workflow stays simple:

Build → review the request → strengthen what is missing → decide → continue building.

That gives Nexpath a focused role in an AI coding workflow. You don't need to abandon your preferred coding environment or switch to a completely different way of building. Nexpath adds a quality layer around the requests that drive the development process.

The exact capabilities can vary between integrations, so developers should check Nexpath's current documentation when choosing an installation method.

What You Need to Get Started

The browser extension can be used with a free Nexpath account that includes $1 of credit. It also supports using your own OpenAI API key.

The setup is easy.

Download the extension and go to "Options" in the extension; it will take you to "Nexpath Settings".

Create your free account by simply signing up with your email, and the Nexpath dashboard will open automatically, where you can copy your token.

Paste the token in the empty field of Nexpath settings, test, and save.

Go back to the Nexpath dashboard, and you'll find the API token has become active.

One thing to keep in mind is that Nexpath's credit is used for its prompt-quality processing, so it makes sense to test it with meaningful requests instead of repeatedly sending the same prompt just to see whether the extension reacts.

Real test case: Can Nexpath Catch What an AI Coding Agent Might Miss?

To see how Nexpath behaves during a real coding workflow, the Nexpath team provided the video below showing the complete process, from installing the browser extension to testing prompts in Replit.

The test starts with a few simple prompts:

“Make a simple login page.”

“Ship this to production now.”

“Deploy the final release and go live.”

Nexpath doesn't pop up for these prompts. And that's expected.

These are direct requests that don't necessarily need extra context or a detailed checklist. Nexpath is designed to stay quiet when there isn't much useful guidance to add, so not every prompt triggers an enhancement.

The fourth prompt is different:

“Check the spec acceptance criteria against what was built: go through each acceptance criterion in the PRD and tell me whether it is fully satisfied, partially satisfied, or not yet implemented.”

This time, Nexpath opens its side panel and provides an enhanced version of the prompt.

The reason is clear: this request involves checking a specification against the implementation. There are multiple acceptance criteria to review, and the result needs to distinguish between fully satisfied, partially satisfied, and missing requirements. Adding structure and verification guidance can make that task much clearer for the coding agent.

The team then chooses the enhanced prompt and continues with it in Replit.

That's the basic idea behind Nexpath. It doesn't need to interrupt every prompt. It steps in when a request has something that could benefit from more structure or verification.

One last thing worth knowing: if Nexpath doesn't trigger when you think it should, you can regenerate a new Nexpath token and try again.

Nexpath Benchmark: What Happened When It Was Tested on SWE-bench Verified?

Product benchmarks can be useful, but they need to be read carefully.

A benchmark can show how a tool performed under a specific setup. It cannot automatically tell us how the same tool will perform across every project, coding environment, model, or developer workflow.

Nexpath published a benchmark to test one question:

Does adding Nexpath's prompt guidance change how well an AI coding workflow performs on SWE-bench Verified?

The test used 40 tasks from SWE-bench Verified and compared two conditions:

Claude Code alone
Claude Code with Nexpath's prompt enhancement

The reported result was 27 solved tasks out of 40 without Nexpath and 29 out of 40 with Nexpath.

So Nexpath solved two additional tasks in this particular test setup.

That is a positive result, but it needs context.

What Is SWE-bench Verified?

SWE-bench is a benchmark built around real-world software engineering tasks from GitHub repositories. A task typically gives the coding system an issue or bug report and evaluates whether the generated patch actually solves the problem.

The Verified subset is designed to contain tasks that have been manually reviewed for quality and reliability.

For Nexpath's benchmark, the team selected 40 tasks from SWE-bench Verified and ran the same tasks under two conditions. The purpose was to isolate the effect of the prompt enhancement step.

That setup matters.

The benchmark isn't comparing Nexpath against another coding tool.

It's asking whether the same coding workflow performs differently when Nexpath adds its guidance to the original task.

Claude Code Alone vs. Claude Code + Nexpath

Here are the published results:

Setup	Tasks Solved	Success Rate
Claude Code	27 / 40	67.5%
Claude Code + Nexpath	29 / 40	72.5%

According to the benchmark, that is an increase of 5 percentage points, or two additional solved tasks within the 40-task sample.

The two conditions were kept separate by running each task in a fresh environment.

The runs used the same task set, with each condition receiving its own fresh execution environment.

That is the right direction for a comparison like this because it reduces the chance that one run affects another.

Still, the result should be interpreted for what it is: a small benchmark run with 40 tasks.

The benchmark itself acknowledges this limitation, describing the two-task difference as a directional signal, not proof of a broad effect across AI coding tasks.

I appreciate that this limitation is stated directly.

Two extra solved tasks can be meaningful as an early signal.

They do not establish that every developer will see a 5-point improvement in their own workflow.

How Nexpath Changed the Prompts

Nexpath preserved the original bug report word for word and appended its guidance underneath it. The benchmark therefore tested additional structure around the same original task instead of replacing the task with a rewritten version.

Across the 40 tasks:

38 prompts were enhanced
2 prompts were left unchanged
Nexpath used 57 different section types
The median enhanced prompt contained 7 sections

This gives a clearer picture of what the benchmark is testing.

Nexpath wasn't simply making every prompt longer.

It was adding different kinds of development guidance depending on the task.

The most common sections were:

Verification or Test Plan
Source Signal Guidance
Reproduction or Evidence
Expected / Actual State
Risk / Safety / Confirmation

That lines up with Nexpath's broader product idea.

A coding tool may already be capable of writing a fix. The extra challenge can be defining what evidence should prove the fix, what behavior needs to be preserved, and which details from the issue are important.

Privacy and Control

Giving an extension access to the prompts you send to coding tools naturally raises a privacy question.

If Nexpath is reviewing the request, where does that request go?

The answer depends on how you configure the product.

Your Credentials and Settings Stay Local

Your token or OpenAI API key, along with your settings, are stored locally in your browser.

You can use one of two options:

a Nexpath account with Nexpath-provided credit
your own OpenAI API key

The data flow changes depending on which option you choose.

If You Use Your Own OpenAI API Key

The prompt text is sent to OpenAI using your API key to generate the guidance.

That means you should also consider OpenAI's own data and API policies when choosing this setup.

If You Use a Nexpath Token

Prompt context is sent to Nexpath's service, which generates the response.

This is worth understanding before using the extension with proprietary or sensitive project information.

Developers should know which processing path they are choosing and make that decision based on their project's requirements.

Local History and Tracking

The browser extension is local-first, and prompt history is stored locally. The product also does not include ads, third-party trackers, or remote code.

The extension may occasionally ask for feedback about how it is performing. Responding sends anonymous, content-free action names and does not send the prompts themselves.

For developers, the practical takeaway is:

Check the processing option you are using before connecting Nexpath to a project.

If you use your own OpenAI key, understand the OpenAI API path.

If you use a Nexpath token, understand that prompt context is sent to Nexpath's service to generate the guidance.

And if you're working with highly sensitive code or information, review the current documentation and privacy details before testing the extension on that project.

That is good practice for any tool that processes development prompts, not only Nexpath.

Try Nexpath and Share Your Feedback

Nexpath is still an evolving developer tool, and that makes real-world feedback especially useful.

The team is openly asking developers to run Nexpath on their own code, try to break the method, and report what happens.

That includes negative feedback.

If Nexpath doesn't trigger when you expect it to, that is useful information too. The team explicitly says that knowing the tool did nothing can be more valuable than another positive result because that is something a benchmark cannot capture.

Developers can also suggest AI coding agents they want Nexpath to support. The project says that the agent list is influenced by those requests.

For an early-stage developer tool, this kind of feedback loop is worth paying attention to.

As a small thank-you for your time and thoughtful feedback, the Nexpath team will recognize three outstanding contributors.

Submissions will be evaluated based on:

depth of feedback
practical suggestions
reproducible issues
clear explanations
helpful improvement ideas

The selection is based on the quality, originality, and usefulness of the feedback, not on whether the comments are positive or negative.

The three winners will receive cash prizes 🤑

Place	Cash prize
🥇 1st	$79
🥈 2nd	$19
🥉 3rd	$9

So try Nexpath, share your feedback, and win some cash 😍

Frequently Asked Questions

What is Nexpath?

→ Nexpath is an AI prompt quality engineering layer for AI coding workflows. It reviews prompts before they reach the coding agent and can add things such as clearer requirements, acceptance criteria, verification steps, and risk checks while preserving the original request.

It is designed for developers using AI coding agents and browser-based AI development tools who want more structure around the development process without giving up the speed of natural-language coding.

How does Nexpath improve AI coding prompts?

→ Nexpath analyzes the prompt and, when it decides guidance is useful, prepares an enhanced version based on the original request.

The added guidance can cover areas such as task breakdown, acceptance criteria, testing and verification, source signals, and potential risks. The original prompt remains visible, and the developer chooses which version to send.

This makes Nexpath more of a prompt quality check than a replacement for the coding agent itself.

Does Nexpath work with Replit, Lovable, and Bolt?

→ Yes. Nexpath provides Chrome and Firefox browser extensions for Replit, Lovable, and Bolt.new, and its documentation lists all three as fully supported and end-to-end tested integrations.

The browser workflow is designed to review prompts directly where you are already building, so you don't need to manually copy prompts into a separate application.

Does Nexpath work with Cursor and Windsurf?

→ Yes. Nexpath provides a VS Code extension for Cursor and Windsurf, which the project describes as fully supported and end-to-end tested. Claude Code is supported through the Nexpath CLI.

The published benchmark discussed in this article specifically measured Claude Code and showed an improvement when Nexpath was added to the workflow. Similar improvements may also be possible with other supported agents, but there isn't specific benchmark data in this test to apply the same results directly to Cursor, Windsurf, Replit, Lovable, or Bolt.

Is Nexpath free?

→ Nexpath offers a free account with $1.00 of credit and does not require an OpenAI account for that option. Alternatively, developers can provide their own OpenAI API key.

The VS Code/CLI documentation also describes a bring-your-own-API-key setup rather than a subscription requirement.

Final Thoughts

AI coding agents have made the distance between an idea and working software shorter.

That's great for experimentation.

It's also where some of the old development habits can disappear quickly.

You can go from a sentence in a chat box to a working feature without stopping to define acceptance criteria, think through edge cases, or decide how you're going to verify the result.

That's the problem Nexpath is trying to address.

It doesn't try to become another coding agent that writes the implementation for you. Its focus is the step immediately around the request: is this prompt giving the coding agent enough context to do the job properly, and what checks might be missing before the work moves forward?

As AI coding gets faster, the problem may not always be writing the code. Sometimes it's knowing what should have been asked before the code was written.

That's a useful problem to solve.

Thanks for reading! 🙏🏻 I hope you found this useful ✅ Please react and follow for more 😍 Made with 💙 by Hadil Ben Abdallah

Hadil Ben AbdallahFollow

Software Engineer • Technical Writer (300K+ readers & 25K+ followers) • Trusted by 20+ startups and tech companies worldwide I turn brands into websites people 💙 to use

Angular DataGrid: A Free, Open-Source AG Grid Alternative Built for Scale

Hadil Ben Abdallah — Tue, 08 Sep 2026 09:07:24 +0000

Angular has changed in recent versions, especially around how developers handle reactive state. Signals are now an important part of the framework, and that makes the architecture behind an Angular component worth paying attention to.

Data grids are a good example.

A grid can start as a simple list of rows and columns. Then requirements start piling up: sorting, filtering, editing, large datasets, virtualization, grouping, pivot tables, accessibility, theming, and more. Building all of those capabilities around a basic table can become a project of its own.

That's where Angular DataGrid comes in. It's an open-source, MIT-licensed Angular data grid built with Angular, TypeScript, and Angular CDK, with a Signals-based architecture and a separate paid Enterprise tier for advanced spreadsheet and data-governance features.

In this article, I'll go through what Angular DataGrid offers, how to get started with it, which features matter when you're dealing with large datasets, how its free and Enterprise tiers differ, and how it compares with AG Grid.

TL;DR

Angular DataGrid is a free, MIT-licensed Angular data grid built around modern Angular patterns, including Signals, with Angular CDK powering its virtualization layer. The project currently reports 100k+ rows supported, 25+ built-in features, 116 passing tests, and $0 license cost for the open-source tier.

Here's what Angular DataGrid brings to the free tier:

✅ MIT-licensed open-source core
✅ Signals-based architecture
✅ Virtual scrolling for large datasets
✅ Sorting, filtering, pagination, and quick search
✅ Row selection and inline editing
✅ Column resizing, reordering, pinning, and layout persistence
✅ Row grouping, aggregation, and Tree Data
✅ Basic Master/Detail
✅ Pivot tables and integrated charts
✅ Faceted search and live updates
✅ Context menus, tooltips, overlays, and cell/row styling
✅ Light, dark, and high-contrast themes
✅ Keyboard navigation and ARIA grid semantics
✅ CSV export
✅ No separate CSS import required

There is also an optional Enterprise tier for capabilities such as Formula Engine, Undo/Redo, Range Selection, Fill Handle, Server-Side Row Model, Cell Permissions, Audit Trail, Row Locking, Spreadsheet Import, PDF Export, Saved Views, and Form Editor.

So if you're looking for an Angular data grid that gives you a broad feature set without a commercial license for the core functionality, Angular DataGrid is worth evaluating.

What Are Angular Data Grid Components?

An Angular data grid component is a table-like UI component designed for large, interactive datasets. It typically handles features such as sorting, filtering, pagination, inline editing, row selection, column management, and data visualization as part of the grid itself.

That's different from rendering a normal HTML table with *ngFor.

A basic Angular table can work perfectly well for a small dataset. Once the number of rows grows, though, the browser has to deal with a much larger DOM, and developers have to build more of the interaction layer themselves.

There is no built-in virtualization in a plain table. Sorting, filtering, editing, selection, column resizing, keyboard navigation, and other behaviors also need to be implemented separately.

A data grid brings those concerns into one component.

For applications such as admin dashboards, inventory systems, analytics tools, CRM interfaces, financial applications, and internal data platforms, that can make a big difference in how much grid-specific code the application needs to maintain.

The important distinction is that a data grid isn't simply a prettier table. It's an interactive data-management component designed around the problems that appear when users need to work with a lot of structured information.

What Features Really Matter in an Angular Data Grid?

A long feature list doesn't automatically make a data grid useful.

The features need to solve actual problems that appear when applications start working with structured and growing datasets.

When evaluating an Angular data grid, I'd look at five areas first: performance, data operations, hierarchical data, accessibility, and customization. These are also the areas highlighted in the Angular DataGrid brief.

Performance at Scale

The first thing to consider is how the grid behaves when the number of records grows.

Rendering a few dozen rows is easy. Rendering thousands of rows creates a very different workload for the browser.

That's why virtual scrolling matters.

A virtualized grid can keep the number of DOM elements under control by rendering the portion of the dataset that needs to be visible.

For data-heavy applications, this is one of the first capabilities I'd check.

Data Operations

Users need ways to find, organize, and analyze the records that matter.

That starts with sorting and filtering, but production applications often need more.

Multi-column sorting, text/number/date/set filters, quick-filter search, row grouping, aggregation, and pivoting can turn a large dataset into something users can actually explore.

The difference becomes obvious when a grid contains thousands of records. A user shouldn't have to scroll through the entire dataset to answer something as simple as:

Which records match this condition?
Which items have the highest value?
How are records distributed across categories?
What does the data look like when grouped by a particular field?

A capable grid should handle those interactions as part of its data-management layer.

Hierarchical Data

Not every dataset is flat.

Organizations have departments and employees. Projects have tasks and subtasks. Products have categories and variants. Applications can also contain parent records with additional detail.

Here, Tree Data and Master/Detail become useful.

Tree Data lets users expand and collapse hierarchical records, while Master/Detail can expose additional information associated with a row.

Accessibility

Accessibility is easy to overlook when evaluating data grids.

A production grid needs more than clickable cells. Keyboard navigation, focus management, and correct ARIA semantics all matter when users need to operate the grid without relying entirely on a mouse.

Customization

Finally, the grid needs to look and behave like part of the application.

A data grid might need a light theme in one product and a dark theme in another. Some applications also need compact density, custom cell renderers, conditional row styling, tooltips, overlays, or application-specific colors.

Introducing Angular DataGrid

Angular DataGrid is a Signals-based Angular open-source data grid built with Angular, TypeScript, and Angular CDK. It's distributed through the @gridengine/angular-datagrid npm package and released under the MIT license.

The Signals-based architecture is an important part of how the project is designed. This isn't just an Angular wrapper around a generic grid component. Angular DataGrid is built as an Angular component with Signals at its core.

The project homepage currently lists:

100k+ rows supported
25+ built-in features
116 passing tests
$0 license cost for the open-source tier

The project follows the existing react-open-source-datagrid project as its reference specification, but the Angular version is built around Angular's Signals-based architecture.

Angular DataGrid is part of the broader GridEngine platform, which provides data grid solutions for different technologies and use cases.

Installation & Quick Start

Getting Angular DataGrid into an Angular project is straightforward.

Install the grid package together with its Angular CDK peer dependency:

npm install @gridengine/angular-datagrid @angular/cdk

The basic component API lets you provide row data and column definitions directly from an Angular component.

A minimal example looks like this:

import { Component } from '@angular/core';
import { DataGrid, ColDef } from '@gridengine/angular-datagrid';

@Component({
  selector: 'app-team',
  imports: [DataGrid],
  template: `<gd-data-grid [rowData]="rowData" [columnDefs]="columnDefs" />`,
})
export class TeamComponent {
  rowData = [
    { id: 1, name: 'Ada Lovelace', role: 'Engineer' },
    { id: 2, name: 'Grace Hopper', role: 'Engineer' },
  ];

  columnDefs: ColDef[] = [
    { field: 'id', headerName: 'ID', width: 80 },
    { field: 'name', headerName: 'Name', sortable: true },
  ];
}

One small detail is worth calling out:

There is no separate CSS file to import.

Angular DataGrid ships its styles inside the component through Angular view encapsulation. Themes and density can be configured through component inputs or --gd-* CSS custom properties.

That keeps the initial setup clean: install the package, import the component, provide the rows and columns, and then start configuring the features your application needs.

The basic grid is only the starting point. The library's feature set covers everyday data operations, large-scale rendering, grouping and hierarchy, real-time data, search, visualization, accessibility, and customization.

Core Features Walkthrough

The basic setup gets a grid on the screen, but the real value of a data grid comes from everything users can do once the data is there.

Angular DataGrid's feature set covers the everyday interactions you'd expect from a modern grid, along with grouping, hierarchical data, analytics, search, real-time updates, visualization, accessibility, and UI customization. It lists 25+ built-in features across these areas.

Let's break those capabilities down by the problems they solve.

Everyday Grid Interactions

For a typical admin dashboard or data-management screen, users need to manipulate the grid without writing custom UI around every operation.

Angular DataGrid includes multi-column sorting, several filter types, pagination, quick-filter search, checkbox-based row selection, and inline editing.

The available everyday interactions include:

Multi-column sorting
Text filters
Number filters
Date filters
Set filters
Quick-filter search
Pagination
Checkbox row selection
Inline editing
Text, number, date, select, and checkbox editors

This gives users several ways to move through a large dataset.

For example, someone managing customer records could sort by account value, filter by status, select several rows, and update a field directly inside the grid.

That workflow becomes even more useful when the grid is being used as the main workspace of an application.

Virtual Scrolling for Large Datasets

Performance becomes a bigger concern as the number of records increases.

Angular DataGrid uses virtual scrolling to keep the rendered portion of the grid manageable.

Users can work with a large dataset while the browser only needs to render the rows currently relevant to the viewport.

The project supports 100,000+ rows, with Angular CDK-backed virtualization listed as part of the implementation.

Consider a grid containing 50,000 records.

A conventional table would create a very large DOM if all of those records were rendered at once. A virtualized grid can keep the visible portion small while the user scrolls through the larger collection.

For Angular applications dealing with large administrative datasets, analytics records, inventory, or operational data, this is one of the features worth testing early.

Angular DataGrid Virtual Scrolling Demo with 100,000 rows

Sorting, Filtering, and Quick Search

Sorting and filtering are simple features until the dataset becomes large enough that users depend on them for almost every interaction.

Angular DataGrid supports multi-column sorting along with text, number, date, and set filters. There's also a quick-filter search bar for rapidly narrowing the records displayed by the grid.

That combination gives users both precise and fast ways to find information.

For example, a support dashboard could filter tickets by status, search for a customer name, and then sort the remaining records by priority and creation date.

The important part is that these operations are already part of the grid's feature set. Developers don't have to construct a separate filtering interface for every dataset.

Angular DataGrid Sorting Demo

Selection and Inline Editing

Data grids often become more useful when users can work with records directly.

Angular DataGrid supports checkbox-based row selection and inline editing with several editor types:

Text
Number
Date
Select
Checkbox

That covers a wide range of common CRUD-style interfaces.

A product-management grid, for example, could allow a user to select records for a batch workflow while also editing a product's name, price, category, or availability directly inside the relevant cells.

This keeps routine changes close to the data being managed.

Angular DataGrid Selection Demo

Column Operations, Pinning, and Layout Persistence

Users don't always want to view a grid in the same way.

Angular DataGrid includes column resizing, column reordering, left and right column pinning, and layout persistence.

Column pinning is useful when important information needs to remain visible while the user moves horizontally through a wide dataset.

Layout persistence adds another practical layer. A user can arrange the columns around their workflow and have that preferred layout restored later.

These features can become important when a grid has many columns and different users need different views of the same underlying data.

Angular DataGrid Column Operations Demo

Row Pinning, Dragging, and Cell/Row Styling

The grid also includes UI features for controlling how important records are presented.

Row pinning can keep selected rows at the top or bottom of the grid, while drag-and-drop interactions support row reordering workflows.

Angular DataGrid also supports cell and row styling, giving developers control over how specific data should appear. The feature list groups these capabilities with the grid's broader visualization and UI features.

That can be useful for conditional interfaces where a row needs to communicate something visually, such as a warning state, status, priority, or other application-specific condition.

Angular DataGrid Cell/Row Styling Demo

Tooltips, Overlays, and Context Menus

A dense data grid can contain a lot of information in a small amount of screen space.

Angular DataGrid includes tooltips and overlays for displaying supporting information without permanently adding more content to every row or cell.

It also includes a context menu with actions such as copying data and exporting CSV.

This gives users another interaction layer when working with records, especially in interfaces where right-click or contextual actions make sense.

Angular DataGrid Tooltips, overlays & custom cell renderers Demo

Grouping, Hierarchy, and Data Analysis

Once a dataset becomes more complex, a flat list of rows can make relationships difficult to understand.

Angular DataGrid addresses this with several features for grouping, hierarchy, and analysis.

Row Grouping and Aggregation

Row grouping lets users organize records according to shared values.

For example, an employee dataset could be grouped by department, while an order dataset could be grouped by customer or region.

Grouping becomes more useful when combined with aggregation, because users can work with summarized values alongside the individual records.

This changes the grid from a simple record viewer into a tool for exploring how a dataset is structured.

Angular DataGrid Row Grouping and Aggregation Demo

Tree Data

Some datasets naturally have parent-child relationships.

Angular DataGrid's Tree Data support lets users expand and collapse hierarchical records.

Think about a project management application.

A project could contain phases, each phase could contain tasks, and tasks could have nested subtasks. A flat table would make that hierarchy harder to follow. Tree Data gives users an expandable structure that reflects the underlying relationships.

The same approach can work for organizational structures, file systems, product categories, or other nested datasets.

Angular DataGrid Tree Data Demo

Master/Detail

Master/Detail provides another way to expose related information.

The free tier includes basic expandable Master/Detail panels, allowing users to open additional information associated with a row.

This can be useful when the main grid needs to stay compact while each record has additional fields or related data that users only need occasionally.

The Enterprise tier later extends this concept with advanced Master/Detail, including lazy-loaded and cached detail rows for larger nested datasets.

Angular DataGrid Master/Detail Demo

Pivot Tables

A Pivot Table is useful when users need to look at the same dataset from different dimensions.

For example, sales data could be organized by region across columns and product categories across rows, allowing users to inspect totals from a different perspective.

Angular DataGrid includes Pivot Table functionality in its free tier.

That is a meaningful capability for analytics-heavy applications because pivoting can answer questions that are difficult to explore through a conventional row-by-row grid.

Angular DataGrid Pivot Tables Demo

Integrated Charts

Angular DataGrid also includes Integrated Charts, which can generate quick SVG charts from grid selections.

The useful part here is the connection between the grid and the visualization.

A user can work with a subset of the data, select what they want to analyze, and turn that selection into a visual representation.

For internal analytics tools and dashboards, this can reduce the need to create a separate visualization flow for every small data-exploration task.

Angular DataGrid Integrated Charts Demo

Faceted Search and Live Data

Some applications deal with datasets that change continuously.

Monitoring dashboards, operational systems, financial interfaces, and real-time analytics applications all need ways to make those changes visible.

Angular DataGrid includes two features aimed at this kind of workflow: faceted search and live updates.

Faceted Search

Faceted search combines filtering with information about the values available in the dataset.

Angular DataGrid's feature list describes it as supporting value counts and token search.

That can help users understand the dataset while narrowing it down.

For example, if a status field contains several possible values, seeing the available values and their counts gives users more context when deciding which filters to apply.

Angular DataGrid Faceted Search Charts Demo

Live Updates

For changing datasets, Angular DataGrid can provide live updates with flash-on-change cells.

When a value changes, the cell can visually indicate that an update occurred.

That small interaction can make a big difference in monitoring interfaces. Users don't have to repeatedly scan every value to figure out what changed.

Angular DataGrid Live Updates Demo

Theming and Customization

A data grid usually needs to match the rest of the application.

Angular DataGrid includes light, dark, and high-contrast themes, along with density modes and CSS custom-property overrides. It also supports custom cell renderer templates.

For example:

<gd-data-grid
  [rowData]="rowData"
  [columnDefs]="columnDefs"
  theme="dark"
  density="compact"
/>

<style>
  gd-data-grid {
    --gd-accent-color: #7c3aed;
    --gd-border-color: #334155;
  }
</style>

The CSS custom properties make it possible to adjust the visual details of the grid while keeping the component inside Angular's view-encapsulation model.

Custom cell renderers are useful when a standard text value isn't enough.

A status column could display badges. A score column could use a visual indicator. A date column could use application-specific formatting.

That gives developers more control over the final UI without having to replace the grid's underlying rendering system.

Angular DataGrid Theming and Customization Demo

Accessibility and Keyboard Navigation

Accessibility deserves its own mention because data grids can become difficult to operate when keyboard and focus behavior are handled poorly.

Angular DataGrid includes roving-tabindex keyboard navigation and ARIA grid semantics.

The goal is to make the grid's interactive structure understandable to assistive technologies while giving keyboard users a predictable way to move through the interface.

For applications used by a broad range of users, these details are part of the grid's overall quality, not an optional visual enhancement.

Documentation and Grid API

Angular DataGrid also exposes an imperative Grid API, alongside API documentation covering inputs, outputs, methods, and ColDef.

This matters when the declarative component configuration isn't enough for a more complex application.

A grid may need to react to an external event, trigger an operation programmatically, or coordinate its state with another part of the application.

Having an API layer gives developers a way to integrate those interactions into a larger Angular application.

Free vs. Enterprise: What's Actually Free?

At this point, it's important to separate the open-source functionality from the paid Enterprise features.

The free Angular DataGrid tier is MIT-licensed and includes a much broader set of functionality than basic sorting and pagination. That includes virtual scrolling, sorting and filtering, selection, editing, column operations, grouping and aggregation, Tree Data, basic Master/Detail, Pivot Table, faceted search, live updates, integrated charts, context menus, styling, theming, accessibility, and CSV export.

The project also has a separate Enterprise tier for teams that need more advanced spreadsheet workflows, backend-driven data handling, collaboration controls, and governance features.

The Enterprise feature list includes:

Formula Engine: Excel-style formulas evaluated directly in cells
Undo / Redo: Multi-step edit history
Range Selection: Excel-style cell-range selection
Clipboard (TSV): Excel-compatible copy and paste
Fill Handle: Drag-to-fill series and copy operations
Advanced Master/Detail: Lazy-loaded and cached detail rows
Server-Side Row Model: Block-fetched data for huge backend-driven datasets
Transactions: Staged add, update, and remove operations
Cell Permissions: Per-cell read/edit controls
Audit Trail: Immutable edit history
Row Locking: Collaborative row locks
Excel / CSV Import: Mapping, validation, and coercion of spreadsheet data
PDF Export: Branded, paginated PDF documents
Filter Presets: Savable AND/OR filter configurations
Saved Views: Personal and shared grid layouts
Form Editor: Slide-in panel for structured record editing

These Enterprise capabilities are explicitly separated from the free feature set in the project brief.

Here's the distinction at a glance:

Category	Free / Open-Source	Enterprise
License	MIT	Paid
Virtual Scrolling	✅	✅
Sorting & Filtering	✅	✅
Pagination	✅	✅
Quick Filter	✅	✅
Row Selection	✅	✅
Inline Editing	✅	✅
Column Resize / Reorder	✅	✅
Column Pinning	✅	✅
Layout Persistence	✅	✅
Row Pinning & Drag	✅	✅
Row Grouping & Aggregation	✅	✅
Tree Data	✅	✅
Master/Detail	Basic	Advanced
Pivot Table	✅	✅
Faceted Search	✅	✅
Live Updates	✅	✅
Integrated Charts	✅	✅
Context Menu	✅	✅
Cell & Row Styling	✅	✅
Tooltips & Overlays	✅	✅
Theming & Density	✅	✅
Keyboard Navigation & ARIA	✅	✅
CSV Export	✅	✅
Formula Engine	❌	✅
Undo / Redo	❌	✅
Range Selection	❌	✅
Clipboard (TSV)	❌	✅
Fill Handle	❌	✅
Server-Side Row Model	❌	✅
Transactions	❌	✅
Cell Permissions	❌	✅
Audit Trail	❌	✅
Row Locking	❌	✅
Excel / CSV Import	❌	✅
PDF Export	❌	✅
Filter Presets	❌	✅
Saved Views	❌	✅
Form Editor	❌	✅

The split makes the positioning fairly clear. A team can use the MIT-licensed core for a broad range of data-heavy Angular applications, then consider Enterprise when the requirements move toward spreadsheet-style editing, backend-driven datasets, collaborative controls, or stronger governance.

That licensing distinction also becomes important when comparing Angular DataGrid with AG Grid, because several advanced capabilities available in Angular DataGrid's free tier are associated with AG Grid Enterprise.

How Angular DataGrid Compares to AG Grid

If you're searching for an AG Grid alternative for Angular, the important comparison is not just the total number of features. It's how much functionality you get in the free tier.

AG Grid Community is free and open source, while features such as row grouping, pivoting, Tree Data, Master/Detail, Server-Side Row Model, Integrated Charts, and Enterprise context-menu functionality are part of AG Grid Enterprise.

Angular DataGrid takes a different approach with its free MIT-licensed tier.

Here's a broader comparison between AG Grid and Angular DataGrid:

Feature	AG Grid Community	AG Grid Enterprise	Angular DataGrid Free	Angular DataGrid Enterprise
License	MIT	Commercial	MIT	Paid
Virtual Scrolling	✅	✅	✅	✅
Sorting	✅	✅	✅	✅
Multi-Column Sorting	✅	✅	✅	✅
Filtering	✅	✅	✅	✅
Text / Number / Date Filters	✅	✅	✅	✅
Set Filter	❌	✅	✅	✅
Quick Filter	✅	✅	✅	✅
Pagination	✅	✅	✅	✅
Checkbox Row Selection	✅	✅	✅	✅
Inline Editing	✅	✅	✅	✅
Text / Number / Date / Select / Checkbox Editors	✅	✅	✅	✅
Column Resizing	✅	✅	✅	✅
Column Reordering	✅	✅	✅	✅
Column Pinning	✅	✅	✅	✅
Layout Persistence	✅	✅	✅	✅
Row Pinning	✅	✅	✅	✅
Row Dragging	✅	✅	✅	✅
Row Grouping	❌	✅	✅	✅
Aggregation	❌	✅	✅	✅
Tree Data	❌	✅	✅	✅
Master/Detail	❌	✅	Basic	Advanced
Pivot Table	❌	✅	✅	✅
Context Menu	❌	✅	✅	✅
Integrated Charts	❌	✅	✅	✅
Faceted Search	❌	❌	✅	✅
Live / Flash Updates	❌	❌	✅	✅
Cell & Row Styling	✅	✅	✅	✅
Tooltips & Overlays	✅	✅	✅	✅
Theming	✅	✅	✅	✅
Density Modes	✅	✅	✅	✅
Custom Cell Renderers	✅	✅	✅	✅
Keyboard Navigation	✅	✅	✅	✅
ARIA Grid Semantics	✅	✅	✅	✅
CSV Export	✅	✅	✅	✅
Formula Engine	❌	✅	❌	✅
Undo / Redo	❌	✅	❌	✅
Range Selection	❌	✅	❌	✅
Clipboard (TSV)	❌	✅	❌	✅
Fill Handle	❌	✅	❌	✅
Advanced Master/Detail	❌	✅	❌	✅
Server-Side Row Model	❌	✅	❌	✅
Transactions	❌	✅	❌	✅
Cell Permissions	❌	❌	❌	✅
Audit Trail	❌	❌	❌	✅
Row Locking	❌	❌	❌	✅
Excel / CSV Import	❌	✅	❌	✅
PDF Export	❌	✅	❌	✅
Filter Presets	❌	✅	❌	✅
Saved Views	❌	❌	❌	✅
Form Editor	❌	❌	❌	✅

Who Should Use Angular DataGrid?

Angular DataGrid makes sense for Angular teams that need a serious data grid without immediately committing to a commercial grid license.

I'd consider it a good fit for:

Internal admin tools where users manage large collections of records
SaaS dashboards that need sorting, filtering, grouping, and interactive exploration
Analytics applications that benefit from Pivot Tables and Integrated Charts
Data-heavy Angular applications where virtual scrolling becomes important
Applications with hierarchical data that can use Tree Data or Master/Detail
Custom Angular interfaces that need control over themes, density, and cell rendering
Teams evaluating an AG Grid alternative that want advanced functionality in the free tier

If your application needs spreadsheet-grade collaboration or governance from day one, features such as Undo/Redo, Range Selection, Cell Permissions, Audit Trail, Row Locking, or Server-Side Row Model belong to the Enterprise tier.

That makes the licensing model worth considering early. The free tier covers a broad range of standard data-grid requirements, while Enterprise gives teams a path forward when the application needs more advanced workflows.

📌 If you find this useful, consider starring the GitHub repo; it helps support the open-source project and its continued development.

⭐ Star Angular DataGrid on GitHub

Frequently Asked Questions

What is an Angular data grid?

→ An Angular data grid is an interactive table component designed for working with structured datasets. It typically provides features such as sorting, filtering, selection, editing, column management, virtualization, and data analysis without requiring developers to build each interaction around a basic HTML table.

What features should I look for in an Angular data grid?

→ The most useful features depend on the application, but large Angular applications commonly need virtualization, sorting, filtering, inline editing, row selection, column management, grouping, hierarchical data, accessibility, and theming. Analytics-heavy applications may also need pivot tables and integrated charts.

Is Angular DataGrid free to use?

→ Yes. Angular DataGrid's core is MIT-licensed and free, including virtual scrolling, grouping, Tree Data, Pivot Tables, Integrated Charts, theming, accessibility, and other core grid features. A separate Enterprise tier adds capabilities such as formulas, Undo/Redo, range selection, server-side data handling, and governance features.

Does Angular DataGrid support Angular Signals?

→ Yes. Angular DataGrid is built as a Signals-based Angular component, making Signals part of its underlying architecture.

Do I need to import a separate CSS file for Angular DataGrid?

→ No. The library ships its styles inside the component through Angular view encapsulation, so there is no separate CSS file to import. Themes and density can be configured through component inputs and --gd-* CSS custom properties.

Final Thoughts

Angular DataGrid gives Angular developers a broad MIT-licensed feature set that goes well beyond basic table functionality.

Virtual scrolling, grouping, Tree Data, Pivot Tables, Integrated Charts, theming, accessibility, and live updates are available in the free tier, while Enterprise adds a clear path for more advanced spreadsheet and governance requirements.

For Angular teams evaluating data grids, the main point is simple. You don't have to start with a commercial license to get a feature-rich grid, and you still have an Enterprise path when your application's requirements grow.

Thanks for reading! 🙏🏻 I hope you found this useful ✅ Please react and follow for more 😍 Made with 💙 by Hadil Ben Abdallah

Hadil Ben AbdallahFollow

Software Engineer • Technical Writer (300K+ readers & 25K+ followers) • Trusted by 20+ startups and tech companies worldwide I turn brands into websites people 💙 to use

I Tested Brilliant.design: Building a Real Portfolio from Figma to AI-Powered Design and Code

Hadil Ben Abdallah — Mon, 07 Sep 2026 09:12:44 +0000

I’ve used quite a few AI design tools, but I was always thinking about what might happen when I stop generating a fresh screen and start working on a real design.

Generating a nice-looking landing page from a prompt has become easy. Importing an existing design, editing it without breaking its visual language, asking an AI agent to understand the canvas, creating another page that follows the same design system, and eventually getting that design into a real React workflow is a better test, I think.

That’s what I wanted to do with Brilliant.design.

For this hands-on review, I decided not to start with a blank canvas. I used a real developer portfolio I picked from Figma and brought it into Brilliant. From there, I worked through the editor manually, connected OpenAI Codex through MCP, asked Codex to inspect and modify the design, created a second canvas from the existing design system, tested Brilliant’s built-in AI with Codex, and tried its Playground mode.

I also looked at the parts of Brilliant that matter to developers beyond the visual editor, including its design system, Blueprint language, MCP workflow, and design-to-code options.

TL;DR

I tested Brilliant.design by using a real developer portfolio as the starting point instead of building a random demo from scratch. I imported the portfolio from Figma, made manual changes, connected Codex through MCP, asked Codex to understand and modify the canvas, created a new canvas using the existing design system, tested Brilliant’s built-in AI with Codex, and explored Playground mode.

Here’s the short version of what I found:

Figma import: Brilliant can bring an existing Figma design into an editable canvas, including layout, vectors, text, fills, strokes, auto layout, and other design properties.
Manual editing: The imported design remains editable, so you can continue working with it as an actual design instead of treating the import like a static screenshot.
MCP: Connecting Codex to Brilliant gave me a way to work on the design from the terminal while Brilliant handled the visual canvas.
AI agents: Codex could inspect the existing portfolio and work with the canvas through Brilliant's MCP connection.
Design consistency: I asked Codex to reuse the portfolio's existing typography, colors, spacing, cards, buttons, border radius, and component patterns, and the new section followed those visual patterns.
Cross-canvas work: I also tested creating a separate Projects canvas based on the homepage’s existing design system.
Built-in AI: Brilliant can use Codex and many other agents as built-in AI providers, giving you another way to interact with the same canvas.
Playground: Playground provides a way to see Brilliant's AI workflow through bundled demonstrations before connecting a provider.
Blueprint: Brilliant has its own compact design language for representing editable canvas elements and their relationships.
Design-to-code: Brilliant supports exports such as React, HTML, CSS, SVG, PDF, and other formats, while the MCP workflow opens another route where an AI coding agent can read the design and implement it in an actual codebase.

The biggest thing I liked is that the AI isn't limited to generating a picture of a design. The canvas contains actual editable design elements that an agent can inspect and modify.

That makes the workflow more interesting for developers because the design can become part of the same AI-assisted workflow as the code.

What Is an AI Design Tool?

Before getting into Brilliant, it helps to define what I mean by an AI design tool.

The term gets used for a lot of different products right now.

Some AI design tools are basically prompt-to-image generators. You describe a landing page, dashboard, mobile app, logo, or illustration, and the tool produces a visual result.

Others go further. They generate actual UI layouts that you can edit, move around, resize, restyle, and export.

Then there are tools that put an AI agent directly into the design workflow. In that setup, you can ask the AI to create or change parts of a design while still working with real design elements.

That last category is where things get more interesting for developers.

A useful AI design tool shouldn't just generate a nice-looking interface.

It should also answer these questions with a big "YES":

Can I edit the result after it has been generated?
Can the AI understand an existing design?
Can it follow an existing design system?
Can it reuse components?
Can it work across multiple screens or canvases?
Can I make small, targeted changes without asking it to rebuild everything?
Can another AI agent access the design?
Can the design eventually become useful code?

Those differences matter when you're working on something real.

For example, imagine you already have a dashboard with a defined type scale, spacing system, buttons, cards, colors, and components.

You don't want an AI tool to create a completely different dashboard every time you ask for a new screen.

You want it to understand what you've already built and continue from there.

That was one of the main things I wanted to test with Brilliant.

AI Design Tools vs. Traditional Design Tools: What Changes?

Traditional design tools are built around the designer.

You open the canvas, select an element, change its properties, move things around, create components, adjust spacing, and build the interface yourself.

The designer makes the decisions, and the tool gives them the controls.

AI design tools add another layer to that workflow.

You can describe an outcome and let an AI model handle some of the mechanical work.

For example, instead of manually creating four cards, aligning them, adding text, adjusting spacing, and repeating the same structure, you might tell an AI agent to create a four-card section that follows the existing design.

The gap between them becomes bigger when the AI can read an existing canvas.

At that point, the workflow doesn't have to stop at:

Prompt → generated design

It can become:

Existing design → AI understands it → AI makes a change → designer reviews it

During my test of Brilliant, I wasn't interested in seeing whether an AI could create something visually impressive from nothing. I wanted to see how well it behaved when I gave it an existing design and asked it to respect what was already there.

And with an MCP connection, an AI coding agent can interact with tools outside the code editor.

So the workflow becomes:

Design canvas ↔ AI agent ↔ codebase

That is a very different idea from generating a screenshot and then manually rebuilding it in React.

What Is Brilliant.design?

Brilliant.design is an AI-powered design tool built around an editable design canvas and AI agents.

The important distinction is that the canvas isn't just an image.

Brilliant works with native design elements such as frames, text, vectors, lines, icons, layouts, components, and other properties that you can continue editing after an AI action.

If you ask an agent to create a section, it can create actual elements on the canvas. If you ask it to modify an existing element, the change happens to that design element instead of producing a new flattened image.

Brilliant also has a built-in AI experience, but you aren't locked into one hosted AI model. Its current workflow supports connecting providers through your own credentials or local CLI-based tools.

The other great piece was MCP.

Brilliant exposes its canvas through a local MCP server while the desktop application is running. That means supported AI agents can connect to the design canvas and interact with it from outside Brilliant.

Brilliant also has Blueprint, its own compact design language for describing canvas elements. Blueprint represents things such as frames, text, vectors, positions, sizes, fills, strokes, radius, effects, auto layout, and relationships between elements.

The files themselves can also be represented as plain-text .bl files, which makes the design closer to something developers are already comfortable working with: text that can be inspected, compared, and managed alongside code.

So, at a high level, Brilliant brings together several pieces:

Figma import + visual editing + design systems + AI agents + MCP + Blueprint + design-to-code workflows.

Why I Tested Brilliant.design With a Real Figma Portfolio

I could have opened Brilliant, typed a prompt like "Create a modern developer portfolio," and called it a test.

I didn't want to do that.

A blank canvas doesn't tell you much about how an AI design tool behaves once you already have design decisions in place.

So I picked a developer portfolio from Figma.

That gave me a much better starting point because the design already had its own visual language.

There were existing sections, typography choices, colors, spacing, cards, buttons, skills, and other visual patterns that Brilliant and the AI agent had to work with.

My Test Setup

I wanted to keep the setup close to something a developer could reproduce.

Setting Up Brilliant

The setup on Windows was fairly straightforward.

I first installed the Brilliant desktop application and signed in. The setup was really quick.

Connecting Codex CLI to Brilliant Through MCP

I didn't have a paid Claude Code or Cursor subscription available for this test, so I used Codex as the external AI agent.

I didn't use an API key.

That wasn't a problem for the MCP test because Brilliant supports Codex as an external MCP client, and the same local MCP connection approach can be used with other supported AI agents.

I signed in with my ChatGPT account.

You just need to run Codex in your terminal to start it.

Once Codex was working, I enabled the Codex MCP connection from Brilliant's settings.

Brilliant exposes its local MCP server through the desktop application. The documented local endpoint uses:

http://127.0.0.1:3333/mcp

If port 3333 isn't available, Brilliant can use another local port, such as 3334 or 3335.

Brilliant can also register the MCP connection for Codex automatically when it detects the Codex configuration directory.

This Codex CLI connection gave me two different ways to interact with the same design:

Codex from the terminal → Brilliant through MCP

and

Codex inside Brilliant's built-in AI chat

Importing a Real Figma Portfolio Into Brilliant

The first real test was simple:

Can Brilliant take an existing Figma portfolio and turn it into something I can continue working with?

Brilliant currently supports importing Figma designs through its web editor, desktop app, and Figma plugin. Brilliant's documentation also describes options for importing a whole file, selected pages, or a selected subtree from the desktop workflow.

For my test, I used my existing portfolio and brought the design into Brilliant.

Figma portfolio imported into the Brilliant desktop app

With this test I wanted to know whether the design structure survived the move.

Could I select individual elements?
Could I edit text?
Could I work with the layout?
Could I continue changing the design without rebuilding everything?

If an imported design becomes an image, it doesn't give me much value as a designer or developer. I need the objects to remain useful after the import.

Brilliant's Figma import brings over a range of design information, including layout properties, auto layout, vector geometry, fills, strokes, corner radii, image fills, and other resolved design values.

So I found out that I could continue working with the imported portfolio inside Brilliant 🎉

And I tried to make the portfolio mine by doing some manual edits.

Manually Editing the Imported Design

Before involving AI, I wanted to spend some time editing the portfolio myself.

This might sound like a small step, but I think it's important when reviewing an AI design tool.

If the AI disappeared completely, would the editor still be useful?

For me, that means being able to select an element, change its properties, adjust the layout, edit text, move things around, and generally work with the canvas without having to ask an AI agent to do every little thing.

I made a few manual changes to the imported portfolio and used that process to get familiar with Brilliant's editing experience.

Honestly, the editing experience was very smooth and straightforward. I could select individual elements and continue editing the imported design, which makes the transition much easier even if you're not already familiar with Figma or another design tool.

For example, when I wanted to change the primary color across the design, I changed it once in the design system, and the change was reflected throughout the design.

After making a few updates, the portfolio started to feel like my own.

For a clear view, I'm sharing the top part of the new design where I made the most updates.

Codex inspected the existing Brilliant canvas

The next thing I want to find out is whether the AI agent can actually work with the design I already have.

First MCP Test: Can Codex See My Brilliant Canvas?

Before anything, I wanted to make sure that Codex understands the design that's open in Brilliant

Here's the prompt I used:

Connect to my open Brilliant project and inspect the current canvas.

Do not make any changes.

Tell me what you can see and briefly describe:
1. The main sections
2. The visual structure
3. The typography
4. The primary colors
5. The reusable components you can identify

Do not modify anything.

I think this is a much better first test than immediately asking an AI agent to redesign something.

If the agent can't correctly understand the existing canvas, there's no reason to trust it with a large design change.

Codex was able to work with the open Brilliant project and return an analysis of the canvas.

It could identify the major sections and describe the visual structure.

Codex inspected the existing Brilliant canvas

The agent wasn't working from a screenshot that I had manually provided. Through Brilliant's MCP connection, it could inspect the open design canvas and return structured information about it.

This is the result Codex gave me:

• Inspected the active scratch Brilliant canvas; no changes were made.

1. Main sections

- Header + hero
- About Me
- Skills
- Works / portfolio carousel
- Blogs
- Contact form
- Footer

2. Visual structure

A 1920px desktop, single-page personal portfolio. It uses a dark, full-width vertical flow with generous section spacing, centered section titles, and a floating pill navigation near the hero. Content is contained in wide desktop gutters (~128px).

- Hero: identity card on the left, large intro copy in the center, compact experience stats on the right.
- About: split text/card and photo composition.
- Skills: two service cards above four circular skill badges.
- Works: central project montage with left/right carousel controls.
- Blogs: one featured horizontal article row and two CTA buttons.
- Contact: title, form fields, submit button, then footer links.

3. Typography

- Primary UI/body/code face: IBM Plex Mono.
- Headings and editorial titles: Ubuntu.
- Hero display "Technical Writer": Agency FB, ~117px.
- Major section headings: Ubuntu, ~64px.
- Smaller labels/body copy: mostly 14-16px IBM Plex Mono or Ubuntu.
- Type treatment is technical/editorial: monospaced body content, bright-blue code-style tags (<h1>, <p>, </>), and white display text. 

4. Primary colors

- Main dark surfaces: #292F36 and near-black #1A1E23.
- Brand/interactive blue: #0080FF, with lighter cyan-blue variants around #1295F7, #12B5F7, and #12F7D6.
- Primary text: white #FFFFFF.
- Divider/muted gray: #43454D.
- Skill accents: HTML #E54F26, CSS #0C73B8, JS #E7A020, React #28A9E0.

5. Reusable components/patterns identified

- The canvas has one explicit declared component: Homepage - Desktop/1920.
- Repeated section-title module: scroll/mouse indicator, large title, and subtitle.
- Repeated rounded-pill buttons: filled blue and outlined dark/blue variants.
- Header/navigation items, including active/inactive nav states.
- Repeated code-tag decoration and bright-blue heading treatment.
- Service cards, skill badges, carousel arrows, blog metadata chips, form fields, and the footer link groups are all structured as reusable patterns.

Asking Codex to Build a New Section From the Existing Design

For the next test, I asked Codex to add a new Featured Projects section to my portfolio.

This sounds simple, but I deliberately made the prompt more specific.

I didn't want:

"Add a Featured Projects section."

That could produce almost anything.

I wanted the agent to look at the existing portfolio and use it as the visual reference.

This is the prompt I used:

Connect my open Brilliant project and add to the current canvas a new "Featured Projects" section below the skills section.

Reuse the existing:
- typography
- colors
- spacing
- card patterns
- button styles
- border radius
- component patterns

Do not redesign or modify the existing sections.

Codex created a new Featured Projects section below the Skills section.

This was a useful test because I could immediately compare the new section with the surrounding content.

The goal wasn't for the new section to look impressive.

The goal was for someone looking at the entire portfolio to feel that the section belongs to the same page.

In my test, I specifically asked Codex to reuse the existing typography, colors, spacing, cards, buttons, border radius, and component patterns.

The resulting section followed those existing patterns closely enough to make the workflow useful.

The cards didn't feel completely disconnected from the rest of the portfolio, and the section followed the visual direction of the page.

This was the first test where I started to see why Brilliant's combination of AI agents + MCP + an editable canvas can make sense for developers.

I was happy with the result, especially because the new section didn't feel completely disconnected from the existing page.

Creating a New Canvas With Cross-Canvas Context

After testing Codex on the existing homepage, I wanted to push the workflow a little further.

Adding a new section to an existing canvas is useful, but creating a whole new page is closer to what happens in a real project.

A developer portfolio rarely has just one screen. You might have a homepage, projects page, about page, blog, contact page, or individual case-study pages. Once you start adding those screens, keeping the same visual language across them becomes important.

So my next test was:

Could Codex create a completely new Projects canvas while using the homepage as its design reference?

I wanted to see whether Brilliant could help with that kind of cross-canvas work without making me manually rebuild the same components and styles.

For this test, I asked Codex to create a new Projects canvas based on the portfolio homepage I had already been working on.

This was the prompt I used:

Connect my open Brilliant project and create a new Projects canvas.

Use the existing design system and components from homepage.

Include:
- Page title
- Short introduction
- Project filters
- Project Grid
- Project cards
- Technology badges
- GitHub link
- Live demo link

The new canvas should feel visually consistent with the homepage.

There are two things I was looking for here.

The first was whether Codex could actually create another canvas in the same Brilliant project.

The second was whether it would use the homepage as a visual reference instead of inventing a completely unrelated design.

I didn't give it exact colors, font sizes, spacing values, or card dimensions this time.

I had already given it those instructions in the previous test.

The resulting canvas gave me a separate place to work on the projects page while keeping the homepage available.

That separation is useful on its own.

The new Projects canvas created from the existing homepage design

The Projects canvas included the pieces I requested: a page title, introduction, filters, project grid, project cards, technology badges, GitHub links, and live demo links.

The new page didn't feel like a completely separate template. It followed the visual direction established by the homepage quite well. The new canvas was ready pretty quickly.

But I still believe that a human designer already knows which details are intentional and which ones are incidental. An AI agent has to infer that from the available design context.

That means I'd still review the new page carefully, especially if the design system is large or has many similar components.

For a production application, I would also want to be very deliberate about which components are truly shared and which ones only happen to look similar.

Using Brilliant's Built-In AI With Codex

So far, I had been driving Brilliant from outside the application through the terminal.

That worked, but Brilliant also has another way to use AI.

You can connect an AI provider and use Brilliant's built-in AI chat directly from the design environment.

Since Codex was already available to me, I wanted to test that workflow too.

External agent: Codex CLI → MCP → Brilliant

Built-in AI: Brilliant → Codex

Brilliant supports Codex as a built-in AI provider.

The setup uses my ChatGPT authentication, so I didn't need to add an OpenAI API key for this test.

After connecting Codex, I could open Brilliant's AI chat and interact with the canvas directly.

The chat is available from Brilliant's interface, and the / shortcut can be used to open the AI interaction.

Here, the AI interaction was part of the Brilliant interface itself.

I didn't need to leave the canvas, switch to the terminal, and communicate with the agent there.

For this test, I went back to my homepage portfolio.

I already had HTML, CSS, JavaScript, and React in the Skills section.

I wanted to add four more technologies:

TypeScript
Next.js
Angular
Node.js

Here's the prompt I used:

In my homepage scratch project I have HTML, CSS, JS, and React in the skills section.

Add these 4 programming languages:
Typescript
Next.js
Angular
Node.js

Use the same style.

Put them inside colored circles, and inside each circle, the logo of the language.

The result was good overall. The four new items followed the existing visual direction of the Skills section, including the circular presentation and general styling.

That was what I wanted to see.

The AI didn't need me to manually describe every existing property in the prompt.

I could point it toward the existing section and tell it to follow the same style.

There was one limitation, though. The AI placed the four new languages on the same line as the existing ones, which pushed some of them outside the visible frame. I fixed the layout manually afterward, as you can see in the video.

And here's the final new section.

New Skills section

For me, an AI design workflow becomes much more useful when I can ask for a specific change without worrying that unrelated parts of the page will get redesigned at the same time.

I still review the result visually, of course.

That's not something I'd skip just because the agent has access to the canvas.

But the interaction itself was straightforward.

Built-In AI vs. External Codex + MCP

After testing both workflows, I see them as two different ways of working with the same underlying idea.

The distinction can be summarized simply:

Workflow	Best fit
Brilliant + built-in Codex	Quick AI-assisted edits directly in the design environment
Codex CLI + MCP	Agent-driven design work from the development workflow
Manual Brilliant editing	Precise visual changes and human control

I wouldn't say one replaces the others. They solve different parts of the workflow and complement each other.

For a designer who wants AI assistance without leaving the design application, the built-in experience is convenient.

For a developer who already spends a lot of time in an AI coding agent, MCP is the part that makes Brilliant much more interesting.

Brilliant Playground

Before wrapping up the AI testing, I also wanted to understand Brilliant's Playground.

This is easy to misunderstand if you open Brilliant before connecting an AI provider.

When I first encountered it, I saw the Playground experience with a bundled example conversation.

I tested the:

"Notes app — entry view"

Notes app generated in Brilliant's Playground mode

The important thing to understand is that Playground isn't the same thing as having a live AI provider connected to Brilliant.

It gives you a way to see the AI workflow through prepared demonstrations.

That makes it useful when you're exploring the product for the first time.

The Notes app example gave me a quick look at how an AI-driven design workflow can operate inside Brilliant.

It was useful for understanding the interaction model before I started using Codex.

Playground is better thought of as a guided demonstration of the experience, so I recommend trying Playground before any other test.

One small limitation I noticed is that when I ran the "Notes app" example from Playground while inside my Homepage canvas, Brilliant placed the generated design beside my portfolio. Personally, I'd prefer Playground demonstrations like this to open in a separate canvas by default so they don't mix with an existing project.

Blueprint: Brilliant's Design Language

Blueprint is Brilliant's compact, line-oriented design language for representing editable canvas elements.

A Blueprint file can describe things such as frames, text, vectors, positions, dimensions, fills, strokes, corner radii, effects, auto layout, hierarchy, and references between elements.

The interesting part for developers is that the design has a text representation that can be inspected and worked with by AI agents and development tools.

Blueprint and Git-Friendly Design Workflows

A developer-oriented detail is that Brilliant design files can be represented as plain-text .bl files.

That's useful because text files work naturally with version control.

You can inspect changes, compare versions, and keep design changes alongside other project files.

I think this is one of the ideas that makes Brilliant feel different from a traditional visual-only design workflow.

A design doesn't have to be treated as something that only exists inside a graphical application.

It can also have a representation that developers and AI agents can work with.

From Design to Code: Brilliant's Developer Workflow

At this point, the workflow starts to move beyond design.

If I'm a developer, I eventually need to take the interface I've designed and turn it into something that runs in an application.

That's where Brilliant's export options come in.

Brilliant supports several export formats, including:

HTML
CSS
React/JSX
SVG
PDF
MP4
MOV
Image formats

It also provides Blueprint and other project-level representations.

React/JSX

Brilliant can export a design as React/JSX. I would treat this as a starting point for implementation rather than production-ready application code. The exported structure still needs to be adapted to the project's architecture, components, state, data, routing, and responsive requirements.

HTML/CSS

HTML and CSS exports provide another starting point when you're building a static interface or want to use the generated structure as a reference.

Brilliant.design vs. Traditional Design Tools

So where does Brilliant actually fit compared with a traditional design tool?

A traditional design workflow is centered around the designer creating and editing the interface visually.

Brilliant keeps that visual workflow but adds AI agents, MCP, Blueprint, and developer-oriented exports around it.

Here's how I would think about the difference:

Capability	Traditional design tools	Brilliant.design
Visual editing	✅	✅
Components	Common	✅
Auto layout	Common	✅
Design tokens	Common	✅
Figma import	Common	✅
Built-in AI	Depends on tool	✅
External AI agents	Varies	MCP
AI access to canvas	Varies	MCP
Text-based design representation	Varies	Blueprint
Git-friendly design representation	Varies	`.bl`
React export	Depends on tool	✅
HTML/CSS export	Depends on tool	✅

I wouldn't say Brilliant makes traditional design tools obsolete.

There are still situations where a mature design platform with a huge ecosystem, established collaboration workflows, plugins, and existing team processes will make more sense.

What Brilliant does differently is put AI agents and developers much closer to the design canvas.

That is the part I think developers should pay attention to.

Who Should Use Brilliant.design?

After using Brilliant with a real portfolio, I think it makes the most sense for a few types of users.

Developers who care about UI design

If you're a developer who regularly needs to design interfaces before building them, Brilliant gives you a visual environment while keeping AI agents close to the workflow.

Designers who want AI-assisted editing

If you prefer working visually but want an AI agent to handle repetitive or structural changes, Brilliant provides that option without turning the canvas into a static generated image.

Product teams experimenting with AI-native workflows

Teams building products around AI agents may find the agent-accessible canvas useful because design can become part of the same tool ecosystem as development.

Developers working heavily with React

The React export and design-to-code workflow make Brilliant worth exploring if your end goal is a React application.

It won't replace the work of building a production React application, but it can shorten the path from visual design to an initial implementation.

People who already use AI coding agents

This is probably the group I would point to Brilliant first.

If you're already using Codex, Claude Code, Cursor, or another supported agent, the MCP workflow makes much more sense because you're adding a design canvas to an AI workflow you already understand.

Frequently Asked Questions

Is Brilliant.design an AI design tool?

→ Yes. Brilliant.design is an AI-powered design tool that combines a visual editing canvas with AI-assisted workflows and AI-agent integrations. It supports built-in AI providers as well as external agent access through MCP.

The important distinction is that Brilliant isn't limited to generating visual mockups. Its canvas contains editable design elements that can be modified manually or through supported AI workflows.

Can Brilliant import Figma designs?

→ Yes. Brilliant supports Figma import, allowing existing Figma designs to be brought into Brilliant as editable design content.

The import carries over many visual and layout properties, including elements such as text, vectors, fills, strokes, corner radius, and auto layout. Some Figma-specific connections, such as live bindings to Figma Variables and shared styles, don't remain as live Figma connections after import.

Can Codex work with Brilliant through MCP?

→ Yes. Brilliant supports connecting Codex to its local MCP server through the Brilliant desktop app.

In my testing, I used Codex CLI to inspect my portfolio canvas, create a Featured Projects section, and create a separate Projects canvas using the homepage as a design reference.

That made MCP one of the most useful parts of the workflow for me as a developer.

Does Brilliant export React code?

→ Yes. Brilliant supports React/JSX export as part of its design-to-code workflow.

The exported React code should be treated as a starting point that developers can refine for their actual application. A design tool doesn't automatically know your application's routing, state, APIs, business logic, architecture, or existing component conventions.

What is Brilliant Blueprint?

→ Blueprint is Brilliant's compact design language for representing the structure and properties of a design.

It can represent elements such as frames, text, vectors, layout, styling, hierarchy, and references. Brilliant designs can also be represented as plain-text .bl files, making Blueprint relevant to developers, AI agents, and version-controlled design workflows.

Final Thoughts

After using Brilliant.design with a real portfolio, I think the easiest way to describe it is:

It's an AI design environment that tries to make the canvas useful to both humans and AI agents.

I started with a Figma portfolio, not a blank prompt.

I imported it into Brilliant, edited it manually, connected Codex through MCP, asked Codex to understand the existing design, had it create a new Featured Projects section, created a separate Projects canvas from the homepage's design system, and tested Codex as Brilliant's built-in AI provider.

I also explored Playground, Blueprint, and the available design-to-code exports.

The workflow isn't magic, and I wouldn't expect it to be.

AI-generated design still needs human review. Exported React still needs engineering. A design system still needs good decisions behind it.

But Brilliant does something I find genuinely useful: it gives AI agents access to a real editable design environment.

If you're a developer who already works with AI coding agents and wants the design side of that workflow to be editable, inspectable, and connected to the same agent ecosystem, Brilliant is worth trying.

Thanks for reading! 🙏🏻 I hope you found this useful ✅ Please react and follow for more 😍 Made with 💙 by Hadil Ben Abdallah

Hadil Ben AbdallahFollow

Software Engineer • Technical Writer (300K+ readers & 25K+ followers) • Trusted by 20+ startups and tech companies worldwide I turn brands into websites people 💙 to use

Mozaik Hackathon 2026: Build Concurrent Multi-Agent Systems and Compete for $1,000 in Cash Prizes

Hadil Ben Abdallah — Mon, 31 Aug 2026 09:09:32 +0000

Building a multi-agent system sounds simple on a whiteboard. Give one agent a task, let another handle the next step, add a reviewer, connect a few tools, and you have an agentic workflow.

It gets more complicated when those agents need to operate at the same time.

A sequential workflow can force agents into a fixed order: one finishes, another starts, and everyone downstream waits. That model is easy to reason about, but it can become restrictive as the system grows and agents need to react to new information independently.

Mozaik takes a different architectural approach. It is an open-source TypeScript framework for building reactive agents inside an event-driven environment, where agents can work concurrently, respond to events, and coordinate without requiring a central workflow to define every interaction.

And now there is a practical way to try this architecture.

JigJoy, together with daily.dev and Hyperskill, is organizing the Mozaik Hackathon 2026, a free online hackathon focused on building concurrent AI agents.

TL;DR

Building more agents doesn't automatically make a multi-agent system better. The way those agents communicate, react, and depend on one another can have a bigger impact on how the system behaves as it grows.

Mozaik approaches this problem with an event-driven architecture designed around reactive, non-blocking agents. Agents join a shared AgenticEnvironment, receive events, and decide how to react to them.

Here’s what makes the Mozaik Hackathon 2026 worth a look:

Concurrent AI agents: Multiple agents can work at the same time and react to events as they arrive.
Event-driven architecture: Agents, humans, observers, and tools participate in the same AgenticEnvironment.
Non-blocking execution: Inference and message delivery can continue in the background without holding up other participants.
Loosely coupled agents: Agents can operate more independently, making them easier to reuse across projects and applications.
TypeScript-based: Mozaik is an open-source TypeScript framework available through @mozaik-ai/core.
Hands-on learning: Participants build a multi-agent system while exploring agent loops, reasoning-model context, and loop engineering.
$1,000 cash prize pool: $500 for first place, $300 for second, and $200 for third.
Free and online: Developers can participate from anywhere without paying an entry fee.

The hackathon takes place on September 5–6, 2026, with a livestream kickoff on September 4 and winners announced on September 13.

If you've been experimenting with AI agents, this is a chance to move past simple API orchestration and explore how concurrent multi-agent systems can be designed.

Sequential vs. Concurrent Multi-Agent Systems: What Changes With Mozaik?
How Mozaik’s Event-Driven Architecture Enables Concurrent AI Agents
- AgenticEnvironment: A Shared Event-Driven Layer
- Non-Blocking Inference Keeps Agents Moving
- Participants Keep Agents Loosely Coupled
Getting Started With Mozaik: A TypeScript Runtime for Concurrent Agents
Mozaik Hackathon 2026: Build a Concurrent Multi-Agent System
- Who can participate in the Hackathon?
- Mozaik Hackathon Timeline: September 4–13, 2026
What Can You Build With Mozaik?
Why Developers Should Join the Mozaik Hackathon
- You can learn by building alongside other developers
- There is a real incentive, too
Frequently Asked Questions
Final Thoughts

Sequential vs. Concurrent Multi-Agent Systems: What Changes With Mozaik?

When developers first build a multi-agent system, a sequential workflow is often the easiest model to understand.

Imagine a research application with five specialized agents:

A researcher collects information.
An analyst examines the findings.
A critic looks for weaknesses.
A writer turns the results into an answer.
A reviewer checks the final output.

The workflow might look like this:

Researcher
    ↓
Analyst
    ↓
Critic
    ↓
Writer
    ↓
Reviewer

Each agent has a clear responsibility, and each stage can pass its output to the next one. For tasks where every step depends on the previous result, this approach makes sense.

The problem appears when agents don't need to wait for each other.

Suppose the researcher finds three useful sources. The analyst could begin examining the first source while the researcher continues collecting information. A critic could inspect an early finding while the rest of the research is still underway. An observer could monitor the work continuously and react if something looks wrong.

A fixed sequence makes those interactions harder to express because the workflow is built around who runs next, not around which agent should react when something happens.

That distinction is central to Mozaik.

Sequential multi-agent workflow	Mozaik's concurrent model
Agents follow an ordered execution path	Agents react to events as they arrive
One stage commonly waits for another	Multiple agents can work concurrently
Orchestration logic defines the workflow	Participants define their own reactions
Adding an agent can require changes to the workflow	New participants can join the shared environment
Long-running work can hold up downstream stages	Non-blocking inference allows other activity to continue
Agents can become tightly connected to a specific workflow	Agents can operate more independently

The goal isn't to make every AI workflow concurrent. Some tasks really have dependencies that require an order.

Mozaik is useful for the cases where multiple agents need to observe the same activity, react independently, and continue working while other agents are still processing.

That changes how you design the system.

Instead of starting with a chain such as:

Agent A → Agent B → Agent C

you can think about the system as a shared environment in which several participants respond to events:

                    ┌── Research Agent
                    │
                    ├── Planning Agent
                    │
Event ──────────────┼── Coding Agent
                    │
                    ├── Review Agent
                    │
                    └── Observer

The agents still have different responsibilities, but their relationship doesn't have to be encoded as one rigid pipeline.

This also affects agent independence and reuse. When an agent's behavior is based on the events it receives and the handlers it implements, that agent can be easier to move into another application or combine with a different set of participants.

For example, a review agent could be used to evaluate generated code in one application and research findings in another. The surrounding participants can change without requiring the reviewer to become part of a completely different orchestration chain.

That is an important part of Mozaik's approach: concurrency and interoperability are connected to the architecture itself.

The framework gives agents a shared environment where they can collaborate while allowing their individual behavior to remain separate.

And that leads to the next question:

how does Mozaik make this possible under the hood?

How Mozaik’s Event-Driven Architecture Enables Concurrent AI Agents

Mozaik builds its concurrent multi-agent architecture around an AgenticEnvironment.

The environment is shared by humans, agents, observers, and tools. Each participant can emit events, while other participants can listen for the events relevant to their role and decide how to react.

Those events can include plain-text messages, typed ContextItems representing model interactions, and streaming SemanticEvent<T> chunks produced during inference.

The key architectural decision is that participants don't have to wait for a central scheduler to tell them what happens next.

They join the environment, register the handlers they care about, and react when relevant events arrive.

a name="agenticenvironment-a-shared-event-driven-layer">

`AgenticEnvironment`: A Shared Event-Driven Layer

The AgenticEnvironment acts as the communication layer between participants.

A human can send a message into the environment. An agent can receive it through onMessage(). The agent can then start inference, which can produce reasoning, model messages, or function calls. Other participants can observe those events and decide whether they need to respond.

The flow looks more like this:

Message
   ↓
Agent reacts
   ↓
runInference()
   ↓
Model events
   ├── Reasoning
   ├── Function call
   └── Model message
          ↓
    Other participants react

There is no requirement that every participant complete its work before the environment can continue processing other events.

That matters because model inference is not instantaneous. A slow model call should not turn the entire multi-agent system into a waiting line.

Non-Blocking Inference Keeps Agents Moving

Mozaik's runInference() capability is designed to be non-blocking.

A reactive agent can receive a message, add it to its ModelContext, and start inference:

async onMessage(message: string): Promise<void> {
  this.context.addContextItem(
    UserMessageItem.create(message)
  );

  runInference({
    model: "gpt-5.5",
    context: this.context,
    caller: this,
    environment: this.environment
  });
}

The important detail is what happens after runInference() is called: the handler returns while the model continues running.

The agent doesn't have to stay waiting for the inference result before the environment can handle other activity. The same participant can respond to another event, while other participants can continue processing their own events.

When inference produces new ContextItems, those items are sent back through the environment. The agent can react through handlers such as onReasoning, onFunctionCall, and onModelMessage, while other participants can observe corresponding external events.

So the underlying pattern becomes:

Event
  ↓
Reaction
  ↓
Inference or tool call
  ↓
New event
  ↓
Another reaction

Here, Mozaik's reactive agent architecture differs from a workflow that simply executes one function after another. The system can keep responding as new information appears.

Participants Keep Agents Loosely Coupled

Mozaik also separates the participants from the overall application flow.

The base BaseParticipant class provides the foundation for participants, while handlers such as onMessage, onFunctionCall, onReasoning, and onModelMessage allow each participant to implement only the behavior it needs.

That means a participant doesn't have to know the entire application.

A planner can focus on planning.
A researcher can focus on research.
A critic can focus on evaluation.
An observer can monitor events.

They can all participate in the same AgenticEnvironment without requiring one central controller to contain every interaction between them.

This is also what makes the architecture useful for reusable AI agents. If an agent's behavior is defined around the events it understands and the actions it can perform, the same participant can potentially be introduced into another environment with a different combination of agents.

Adding a critic, observer, or specialist can therefore become a matter of composing participants and defining their reactions, instead of redesigning one large workflow every time the system changes.

For developers building AI agent orchestration systems, that is a meaningful change in how the architecture can be structured: the environment provides the shared communication layer, while each participant owns its own behavior.

And this is the kind of architecture the Mozaik Hackathon gives developers a chance to build themselves.

Getting Started With Mozaik: A TypeScript Runtime for Concurrent Agents

Mozaik is written in TypeScript and is available as the @mozaik-ai/core package.

For a new project, installation starts with:

npm install @mozaik-ai/core

You can also install it with Yarn or pnpm:

yarn add @mozaik-ai/core

pnpm add @mozaik-ai/core

The framework resolves the model provider from the model name passed to runInference(). Provider credentials are configured through environment variables, such as:

OPENAI_API_KEY=your-openai-key-here
ANTHROPIC_API_KEY=your-anthropic-key-here
GEMINI_API_KEY=your-gemini-key-here

DeepSeek models can use the OpenAI-compatible chat-completions endpoint with OPENAI_API_KEY and OPENAI_BASE_URL configured for DeepSeek.

For TypeScript projects, Mozaik's documentation recommends a modern moduleResolution setting, such as bundler, node16, or nodenext so package imports resolve cleanly.

Mozaik Hackathon 2026: Build a Concurrent Multi-Agent System

The Mozaik Hackathon is about giving developers the freedom to try out new things with AI agents that work together. It's a chance for them to build something real using Mozaik and see what they can create.

It is fully online and free to enter, and you do not need previous Mozaik experience.

When you sign up, you get a bunch of helpful stuff like documents to read, a template to get started, and a quick intro to get you going before everything kicks off. Plus, the organizers will guide you through the process, so the weekend is not simply a contest where you are handed a framework and left alone with it.

The goal is also educational. You are expected to build something, but the process gives you a chance to understand what is happening underneath an AI agent system: how agents receive events, maintain context, call models and tools, react to outputs, and coordinate with other participants.

Who can participate in the Hackathon?

The hackathon is open to developers anywhere in the world.

You can enter on your own, and the organizers will help solo participants find teammates. You can also bring your own team. The website currently says that team-size limits will be announced soon.

You also do not need to arrive as a Mozaik expert. The event is designed to introduce the runtime to participants before the build weekend begins.

That makes the hackathon relevant to developers who already build AI applications as well as those who are just starting to explore AI agents and multi-agent architecture.

Mozaik Hackathon Timeline: September 4–13, 2026

The main build happens over the weekend of September 5–6, 2026, but the event starts with an introduction on September 4 and ends with the winners' announcement on September 13.

Here is the timeline currently provided by the organizers:

Date	Event	What happens
September 4, 2026	Livestream kickoff	Introduction to Mozaik and the public release of the hackathon brief
September 5–6, 2026	Build weekend	Participants build their concurrent multi-agent systems with Mozaik
September 6, 2026	Submissions close	Submit your repository and short demo by the evening
September 13, 2026	Winners announced	The judging period ends and the winners are announced

You do not need to travel anywhere, find a physical venue, or rearrange your weekend around an in-person event. You can build from wherever you are and communicate with the organizers and other participants through the event's online channels.

What Can You Build With Mozaik?

Once you understand the event-driven model, the interesting part starts: deciding what you want your multi-agent system to do.

The Mozaik Hackathon does not give developers a long list of predefined tracks. There is one open brief, and the core requirement is simple:

build a working system where several agents run at the same time, share state, and coordinate with one another.

That leaves plenty of ideas for creativity.

You could build a research system where multiple agents investigate different parts of a problem simultaneously, with one agent checking the findings as they arrive. You could create a coding team where a planner, implementation agent, tester, and reviewer respond to changes as the project develops.

You could also go beyond familiar developer workflows. Think about customer-support agents that monitor conversations together, autonomous research teams that exchange findings, content systems where writers and fact-checkers react to new information, or monitoring agents that watch another agent's activity and step in when something needs attention.

A project with five agents that only execute one after another won't demonstrate the concurrent-agent architecture as clearly. A smaller system with three agents that genuinely react to shared events and influence each other's work can demonstrate the architecture much better.

The best way to approach the project is to define these three things before writing the code:

What is the shared goal?
Give all participants a reason to collaborate.
What can each agent observe and react to?
This is where Mozaik's event-driven model becomes important.
What happens when agents work at the same time?
Your architecture should make concurrency visible in the actual behavior of the application.

That last point matters because the hackathon is specifically looking for systems where concurrency is genuine, not a sequential pipeline presented as a multi-agent application.

Why Developers Should Join the Mozaik Hackathon

Building a multi-agent system from scratch forces you to understand things that can easily stay hidden when you work with higher-level abstractions.

You have to think about agent state, events, context, model inference, tool calls, communication, reactions, and concurrency. You start seeing an AI agent as an actual software component with inputs, behavior, state, and outputs.

That is exactly the kind of experience the Mozaik team wants participants to gain.

You can learn by building alongside other developers

Hackathons are also useful because the learning does not happen in isolation.

The organizers plan to support participants through Discord, including announcements, team formation for people entering solo, and a place to ask questions throughout the weekend.

If you run into a problem with your architecture, need clarification about Mozaik, or simply want to discuss an approach with other builders, there is a shared space for it.

And because the event is open-ended, you are not limited to reproducing one official demo. You get to make architectural decisions yourself and see what happens when you apply the concurrent-agent model to a problem you care about.

There is a real incentive, too

The hackathon offers $1,000 in cash prizes:

Place	Cash prize
🥇 1st	$500
🥈 2nd	$300
🥉 3rd	$200

There are also additional prizes and discounts shown on the event page, including subscriptions from the event partners.

But for developers interested in AI engineering, the bigger prize is the opportunity to leave the weekend with a working multi-agent application and a clear understanding of how concurrent agents can be designed.

That is a useful project to have in your portfolio, especially as AI applications move beyond single-agent interactions toward systems where several specialized agents collaborate.

Frequently Asked Questions

What makes Mozaik different from other AI agent frameworks?

→ Mozaik is built around a concurrent, event-driven architecture where agents don't have to wait for one another in a fixed sequence. Agents can react to events independently, allowing multiple participants to work at the same time while remaining loosely coupled and reusable across different projects.

Do I need experience with Mozaik to join the hackathon?

→ No. The Mozaik hackathon is open to developers without prior Mozaik experience, and participants receive documentation, a starter template, and a primer before the event. The hackathon is also free and fully online, so you can participate without paying an entry fee or traveling.

What will I build during Mozaik hackathon?

→ You'll build a working multi-agent system around an open brief, with the core requirement that multiple agents genuinely run concurrently and coordinate with one another. Possible directions include a research swarm, a self-reviewing codebase, a live operations room, or a system for parallel hypothesis testing.

When does the Mozaik hackathon take place, and is it free?

→ The Mozaik hackathon takes place online on September 5–6, 2026, and it is free to enter. The livestream kickoff is scheduled for September 4, while submissions close on the evening of September 6.

What prizes can Mozaik hackathon participants win?

→ The hackathon offers $1,000 in cash prizes: $500 for first place, $300 for second place, and $200 for third place. Additional prizes include daily.dev Plus subscriptions, Hyperskill Premium subscriptions, and Mozaik Cloud Premium subscriptions, while every participant receives discounts on Mozaik Cloud and Hyperskill Bootcamps.

Final Thoughts

A lot of today's AI agent development still revolves around deciding what happens first, what happens next, and which agent receives the previous agent's output.

That approach works for many tasks. But as systems become more autonomous, there is another way to think about coordination:

Give agents an environment where they can observe events, react independently, and collaborate as the situation changes.

That is the idea Mozaik is bringing to multi-agent development.

Its event-driven architecture, non-blocking inference model, participant system, and shared environment give developers a foundation for experimenting with agents that can work concurrently without every interaction being hard-coded into one sequential workflow.

The Mozaik Hackathon is a chance to take that idea out of the documentation and build something with it.

You do not need to arrive with a finished architecture or years of multi-agent experience. You need a problem worth solving, a willingness to experiment, and an idea for how multiple agents can contribute to the same goal.

If you have been curious about what happens when AI agents can work together without waiting for each other at every step, September 5–6 is a good weekend to find out.

Thanks for reading! 🙏🏻 I hope you found this useful ✅ Please react and follow for more 😍 Made with 💙 by Hadil Ben Abdallah

Hadil Ben AbdallahFollow

Software Engineer • Technical Writer (300K+ readers & 25K+ followers) • Trusted by 20+ startups and tech companies worldwide I turn brands into websites people 💙 to use

Best Enterprise MCP Gateway for Security & Governance in 2026: A Practical Guide to Securing AI Agent Tool Access

Hadil Ben Abdallah — Fri, 28 Aug 2026 08:46:05 +0000

MCP is changing how AI applications interact with the systems around them.

An AI agent can now do much more than generate text. It can connect to MCP servers, discover available tools, query internal systems, interact with databases, and trigger actions on behalf of a user.

That capability is powerful, but it creates a new challenge for engineering teams: how do you control what AI agents are allowed to access, how those actions are tracked, and how much they can consume?

As MCP adoption grows, managing each connection independently quickly becomes difficult. Authentication, permissions, tool access, logging, budgets, and security policies can end up scattered across applications and teams.

This is where an enterprise MCP gateway becomes valuable.

A centralized MCP gateway gives engineering and platform teams a consistent control layer between AI applications and the tools they use. It can enforce policies, manage access, provide visibility into requests, and make MCP infrastructure easier to operate at scale.

In this guide, we'll look at what an enterprise MCP gateway should provide for security and governance, how Bifrost approaches MCP governance, and how Bifrost Edge extends those controls to developer endpoints.

TL;DR

An enterprise MCP gateway provides a centralized layer for controlling how AI applications and agents access MCP servers and the tools they expose.

For production environments, the important capabilities go beyond basic authentication. Engineering teams need:

Centralized authentication and authorization
Tool-level access control
Guardrails and policy enforcement
Audit logs and observability
Usage and cost controls
Consistent governance across AI applications

Bifrost approaches MCP governance through a centralized AI gateway that manages access to models and MCP servers while providing virtual keys, policies, budgets, logging, and observability.

Bifrost Edge extends that governance toward developer endpoints, helping organizations apply the same governance model across the AI applications and developer workflows used by their teams.

The goal isn't to prevent engineers from using AI. It's to give them a controlled infrastructure layer that lets them use increasingly capable AI systems without losing visibility or operational control.

What Is an Enterprise MCP Gateway?

An enterprise MCP gateway is a centralized layer that manages communication between AI applications or agents and the MCP servers they use.

Without a gateway, an AI application can connect directly to multiple MCP servers:

AI Application
      │
      ├── MCP Server A
      ├── MCP Server B
      ├── MCP Server C
      └── Internal Tools

As the number of applications and MCP servers grows, this architecture becomes increasingly difficult to govern.

Different applications may implement authentication differently. Permissions can become inconsistent. Logging may be distributed across several systems, and platform teams may have little visibility into which applications are accessing sensitive tools.

A gateway introduces a centralized control layer:

AI Applications
      │
      ▼
Enterprise MCP Gateway
      │
      ├───────────────┬───────────────┐
      ▼               ▼               ▼
   MCP Server A    MCP Server B    MCP Server C
      │               │               │
      ├── Tools       ├── Tools       ├── Tools
      ├── APIs        └── Databases   └── Internal Systems
      └── Services

The gateway becomes the place where organizations can establish consistent rules before requests reach MCP servers.

For enterprise environments, this matters because MCP servers can expose capabilities that go far beyond retrieving information. Depending on the tools available, an agent could interact with internal databases, APIs, cloud infrastructure, or other systems.

The more capable those tools become, the more important centralized governance becomes.

MCP Gateway vs. Direct MCP Connections

Direct connections can work well when experimenting with MCP or building a small application.

An individual developer might connect an AI client to a handful of MCP servers and manage the configuration locally. At that scale, the setup is relatively easy to understand.

The situation changes when MCP becomes part of an organization's engineering infrastructure.

Imagine several teams using different AI applications, each connecting to different MCP servers. Some applications need access to internal documentation, while others require access to development tools or production systems.

Now the organization needs to answer questions such as:

Which applications can access each MCP server?
Which users can invoke sensitive tools?
What happened during a specific tool call?
Which teams are generating the most usage?
Can access policies be changed centrally?

A direct-connection architecture makes those questions harder to answer.

A gateway provides a shared governance layer where these decisions can be managed consistently.

Enterprise MCP Gateway vs. MCP Proxy

An MCP proxy can forward requests between an AI client and an MCP server.

An enterprise MCP gateway goes further by making that connection a governed part of the organization's AI infrastructure.

The distinction becomes important when teams need more than connectivity.

An enterprise gateway can bring together authentication, authorization, tool access, policies, logging, observability, and cost controls around MCP traffic.

That makes the gateway useful not only for connecting AI applications to MCP servers, but also for governing how those connections are used.

Why MCP Security Has Become an Enterprise Problem

MCP introduces a different security challenge because AI agents can interact with tools on a user's behalf.

An MCP server might expose several capabilities through a single connection. Some tools may simply retrieve information, while others can interact with systems that contain sensitive data or perform actions with real consequences.

As organizations add more MCP servers, the number of possible agent-to-tool interactions grows quickly.

A developer might use one MCP server for documentation, another for databases, and another for cloud infrastructure. A different team may use an entirely different set of tools.

The challenge isn't determining whether someone is allowed to use MCP.

The real question is:

What exactly should this application, agent, or user be allowed to do through MCP?

That distinction is at the heart of enterprise MCP governance.

Why MCP Security Requires More Than Authentication

Authentication answers an important question:

Who is making the request?

But enterprise MCP security also needs to answer:

What is that identity allowed to do?

An engineer may be authorized to use an AI assistant, for example, but that doesn't necessarily mean the assistant should have access to every MCP tool available across the organization.

Similarly, an internal application may access company documentation without needing permission to interact with production databases.

These are authorization and governance decisions.

That's why authentication alone isn't enough for enterprise MCP deployments. Organizations need a way to define and enforce policies around the tools and systems AI agents can access.

Without centralized controls, each application may end up implementing those decisions independently.

That creates the same governance problem that appears when AI integrations are scattered across different applications: permissions become inconsistent, visibility becomes fragmented, and security teams have a harder time understanding what is happening across the environment.

What Should an Enterprise MCP Gateway Provide?

A useful enterprise MCP gateway needs to do more than route requests.

For production AI environments, the gateway should provide a combination of access control, policy enforcement, observability, and governance.

The goal is to create one consistent layer where organizations can control how AI applications interact with MCP infrastructure.

MCP Authentication and Authorization

Authentication provides the foundation for controlling MCP access.

Bifrost uses Virtual Keys to separate applications from the underlying provider credentials and define how they can interact with AI infrastructure.

Instead of giving every application direct access to provider credentials, applications authenticate through Bifrost while the gateway handles the underlying connections.

Virtual keys can be used to define policies around:

Which models an application can use
Which providers are available
Spending limits
Rate limits
Allowed MCP servers
Tool permissions
Logging behavior

This creates a clear separation between an application's identity and the credentials used behind the gateway.

For enterprise MCP deployments, that same principle is valuable because access can be governed centrally instead of being embedded independently into every AI application.

MCP Tool Filtering and Access Control

MCP servers can expose multiple tools, and not every application should necessarily have access to all of them.

Consider an MCP server connected to internal infrastructure.

One tool might retrieve documentation. Another might query a database. A third could potentially perform an operational action.

Treating all three capabilities as equivalent creates unnecessary risk.

Bifrost extends governance to the MCP tool layer, allowing organizations to control which MCP servers and tools can be accessed through the gateway.

This gives platform teams a more precise way to define AI permissions.

The question becomes about which capabilities that application is actually allowed to use.

Audit Logs and MCP Observability

Access control answers what an AI application can do.

Audit logs help answer what it actually did.

This becomes especially important when AI agents interact with multiple tools and systems.

Without centralized logging, investigating an unexpected action can mean searching through application logs, provider dashboards, MCP server logs, and other monitoring systems.

Bifrost provides centralized visibility into AI requests passing through the gateway.

Depending on the workflow, teams can track information such as:

The application initiating the request
The virtual key being used
The user or service involved
The model handling the request
MCP tools being accessed
Latency
Token usage
Associated costs

That creates a more complete picture of the AI request lifecycle.

For engineering teams, this isn't only useful during security investigations. The same visibility can help with debugging, performance analysis, optimization, and compliance reviews.

Guardrails and Policy Enforcement

Authentication and tool permissions establish who can access an MCP environment, but enterprise governance also needs rules that apply consistently to every request.

This is where guardrails become important.

Without centralized policies, individual applications have to decide how requests should be handled. One application may restrict certain models or tools, while another may allow them. Over time, those differences create gaps that are difficult for platform teams to monitor.

Bifrost provides a centralized layer where organizations can apply policies across their AI infrastructure.

Depending on the environment, those policies can include:

Restricting access to specific models
Limiting which providers can be used
Blocking sensitive MCP tools
Enforcing role-based permissions
Applying rate limits
Separating development and production environments

The advantage is consistency.

Developers don't have to implement the same governance rules separately in every application they build. The gateway can enforce the organization's policies while developers continue working with the AI tools and models they need.

For enterprise MCP deployments, this becomes especially important as the number of agents and tools grows. A policy that works for five applications should not require a completely different implementation when the organization reaches fifty.

AI Governance and Cost Control

Security isn't the only governance problem that appears when AI usage scales.

Cost control matters too.

MCP-enabled agents can interact with multiple models and tools during a single workflow. When usage is spread across different applications, teams, and providers, understanding where AI spending comes from becomes increasingly difficult.

One team might use one model heavily for development. Another might rely on a different provider for production workloads. Meanwhile, AI agents can generate additional requests as they interact with MCP tools.

Without centralized visibility, organizations can end up discovering unexpected spending only after the bill arrives.

Bifrost brings usage and budget controls into the same infrastructure layer that handles AI requests.

Organizations can define controls such as:

Usage limits
Spending caps
Rate limits
Team-specific budgets
Project-specific allocations

Because requests pass through the gateway, teams can connect usage with the applications, models, and workflows generating that activity.

That changes the conversation around AI costs.

Instead of simply asking why the monthly bill increased, platform teams can investigate which projects generated the usage, which models were involved, and where the costs came from.

Good AI governance isn't only about blocking risky behavior. It's also about making AI usage visible, predictable, and manageable.

How Bifrost Approaches Enterprise MCP Governance

Bifrost approaches MCP governance as part of a broader AI gateway architecture.

The idea is straightforward: AI applications shouldn't have to independently manage every model connection, MCP server, credential, permission, budget, and logging requirement.

A centralized gateway can handle those concerns consistently.

With Bifrost, the gateway provides a control layer for AI infrastructure that includes:

Virtual Keys for managing application access
MCP governance for controlling access to MCP servers and tools
Guardrails for enforcing centralized policies
Budgets and rate limits for controlling usage
Audit logs and observability for understanding AI activity
LLM routing across multiple providers

This architecture is useful because MCP doesn't exist in isolation.

An AI application may use an LLM for reasoning, call an MCP server for additional context, access internal systems through tools, and continue the workflow through several subsequent model requests.

Trying to govern each part independently can quickly become complicated.

A gateway provides one place where these interactions can be managed.

For example, a simplified workflow might look like this:

AI Application / Agent
          │
          ▼
   Bifrost Gateway
          │
    ┌─────┴─────┐
    │           │
    ▼           ▼
LLM Providers  MCP Servers
    │           │
    │       ┌───┴────┐
    │       ▼        ▼
    │    Tool A    Tool B
    │
    └──── Governance ────┐
                         │
          Keys • Policies • Budgets
          Logs • Access • Observability

The important part isn't simply putting another component in the request path.

It's creating a consistent governance boundary around AI infrastructure.

That gives platform teams a central place to establish policies while application teams can focus on building AI-powered products and workflows.

How Bifrost Edge Extends MCP Governance to Developer Endpoints

A gateway provides centralized governance for requests that pass through it.

But modern developers don't interact with AI through only backend applications.

They use coding agents, desktop AI applications, browser-based assistants, IDE integrations, and MCP-enabled developer tools directly from their machines.

That creates another governance challenge.

A company may have carefully configured its gateway, but if developers can use AI applications that bypass the organization's intended infrastructure, those policies may not cover every AI interaction.

Bifrost Edge extends the governance model toward the endpoint.

The goal is to bring AI traffic from developer environments into the same centralized governance architecture.

A developer might use several different AI tools during a normal workday:

Coding agents
Desktop AI assistants
Browser AI applications
IDE integrations
MCP-enabled tools
Terminal workflows

Without an endpoint layer, each application can become another place where AI access and configuration need to be managed.

Bifrost Edge helps extend the governance established through Bifrost Gateway to those developer workflows.

That creates a broader architecture:

Developer Endpoints
       │
       ▼
   Bifrost Edge
       │
       ▼
 Bifrost Gateway
       │
   ┌───┴──────────┐
   ▼              ▼
LLM Providers  MCP Servers

The gateway remains the central governance layer, while Edge helps bring developer-side AI activity into that controlled environment.

What Enterprise MCP Governance Looks Like in Practice

Consider an engineering organization where different teams use different AI tools.

Backend engineers might use coding agents. Frontend developers may work with AI inside their IDEs. Other teams may use desktop assistants or browser-based AI tools.

At the same time, internal agents may connect to MCP servers exposing documentation, databases, APIs, or other enterprise resources.

Without centralized governance, each workflow can develop its own permissions, credentials, and logging.

With Bifrost Gateway and Edge, the organization can establish a more consistent path:

Developer / AI Application
           │
           ▼
      Bifrost Edge
           │
           ▼
     Bifrost Gateway
           │
     ┌─────┴─────┐
     ▼           ▼
  LLMs       MCP Servers
     │           │
     └─────┬─────┘
           ▼
   Centralized Governance

The same core principles can then apply across the workflow: identity, permissions, tool access, guardrails, budgets, logging, and observability.

That consistency becomes valuable as organizations move from experimenting with MCP to operating AI agents as part of everyday engineering workflows.

What to Look for in the Best Enterprise MCP Gateway

Choosing an enterprise MCP gateway shouldn't come down to whether it can simply connect an AI application to an MCP server.

The more important question is whether it gives engineering teams enough control to operate those connections safely at scale.

Here are the capabilities worth evaluating.

1. Centralized authentication and authorization

The gateway should provide a consistent way to identify applications and control what they can access.

2. Tool-level access control

MCP servers can expose many capabilities. Organizations should be able to control which tools different applications, users, or workflows can access.

3. Centralized audit logs

Teams need visibility into AI requests and tool activity when debugging incidents, investigating unexpected behavior, or reviewing compliance requirements.

4. Policy enforcement

Security and governance policies should live in a centralized layer so applications don't have to recreate the same controls independently.

5. Budget and usage controls

As AI adoption grows, organizations need to understand and manage consumption across models, applications, and teams.

6. LLM and MCP support in one architecture

MCP governance becomes more useful when it is connected to the rest of the AI infrastructure instead of being treated as an isolated feature.

7. Endpoint governance

For organizations with developer-facing AI workflows, governance should also account for AI applications running directly on employee machines.

These capabilities turn an MCP gateway from a simple connectivity layer into infrastructure that platform and security teams can operate.

How to Choose the Best Enterprise MCP Gateway in 2026

There isn't one universal MCP gateway that is perfect for every organization.

The right choice depends on how your teams use AI, how many MCP servers you operate, what systems those tools can access, and how much centralized governance you need.

A useful evaluation should start with a few practical questions:

How many AI applications and agents need MCP access?

A small experiment may not require a full governance layer. A large engineering organization with dozens of AI workflows has very different requirements.

How sensitive are the tools behind your MCP servers?

If MCP connects agents to internal databases, production infrastructure, or business-critical systems, granular access controls become much more important.

Can policies be managed centrally?

If every application requires separate configuration, governance becomes harder to maintain as adoption grows.

Can you trace AI activity?

Audit logs should make it possible to understand which application, user, model, or tool was involved in an AI workflow.

Can you control AI spending?

As organizations adopt multiple models and AI agents, cost visibility becomes part of infrastructure management.

Does governance extend to developer endpoints?

If employees use coding agents, desktop assistants, or other AI applications directly, endpoint coverage can be just as important as server-side governance.

For many engineering teams, the best enterprise MCP gateway will be the one that fits naturally into the broader AI infrastructure.

A Practical Enterprise MCP Governance Checklist

Before adopting an MCP gateway, it's worth turning the requirements into a practical checklist.

An enterprise MCP deployment should give engineering and security teams clear answers to a few basic questions:

Who can access MCP?
What can they access?
What happened?
How much are they using?

A useful checklist includes:

[ ] Centralized authentication and authorization
[ ] Virtual keys or another consistent identity mechanism
[ ] Tool-level access control
[ ] MCP server access policies
[ ] Centralized audit logs
[ ] Request and usage observability
[ ] Guardrails and policy enforcement
[ ] Usage limits and spending controls
[ ] Support for multiple LLM providers
[ ] Governance across developer AI applications and endpoints

The exact requirements will vary between organizations, but the underlying principle remains the same: MCP governance should become easier as the organization grows, not harder.

If adding another MCP server means creating another set of credentials, permissions, dashboards, and policies manually, the architecture will eventually become difficult to maintain.

A centralized gateway helps keep those controls in one place.

Frequently Asked Questions

What is an enterprise MCP gateway?

→ An enterprise MCP gateway is a centralized infrastructure layer that manages and governs communication between AI applications or agents and MCP servers.

It can provide authentication, authorization, tool access control, policy enforcement, audit logs, observability, and usage controls.

Why do enterprises need an MCP gateway?

→ Enterprises often have multiple AI applications, agents, and MCP servers connecting to internal systems.

Managing those connections independently can create inconsistent permissions, fragmented logs, and limited visibility.

An MCP gateway provides a centralized place to manage those interactions and apply consistent governance policies.

How does an MCP gateway secure AI agents?

→ An MCP gateway can control which applications and users can access MCP servers and which tools they are allowed to invoke.

It can also apply policies, enforce limits, and maintain audit logs so teams can understand how AI agents are interacting with enterprise systems.

What is the difference between an MCP gateway and an MCP proxy?

→ An MCP proxy primarily forwards communication between an AI client and an MCP server.

An enterprise MCP gateway adds governance capabilities around that traffic, including authentication, authorization, tool permissions, policies, logging, observability, and cost controls.

Can an enterprise MCP gateway control individual MCP tools?

→ Yes. Tool-level access control is an important part of MCP governance because an MCP server can expose multiple capabilities with different levels of sensitivity.

Controlling individual tools allows organizations to give AI applications only the capabilities they actually need.

Final Thoughts

MCP is making AI applications more capable, but that capability also changes what engineering teams need to control.

Once AI agents can interact with internal tools, databases, APIs, and other systems, simply knowing which model an application uses isn't enough.

Teams need to know who can access those tools, what they can do, how their activity is monitored, and how usage is controlled.

That's the role an enterprise MCP gateway can play.

Bifrost approaches this problem through a centralized AI gateway that brings MCP governance together with authentication, virtual keys, tool access, guardrails, budgets, audit logs, and observability.

Bifrost Edge extends that model toward developer endpoints, helping organizations maintain consistent governance across the AI applications and workflows their teams use.

Bifrost Edge extends that model toward developer endpoints, helping organizations maintain consistent governance across the AI applications and workflows their teams use. If you'd like to explore the architecture in more detail, you can book a demo with the Bifrost team.

As AI agents become more capable, these controls will become important. The organizations that can give their developers powerful AI tools while maintaining clear visibility and control will be in a stronger position to scale AI across engineering teams.

Thanks for reading! 🙏🏻 I hope you found this useful ✅ Please react and follow for more 😍 Made with 💙 by Hadil Ben Abdallah

Hadil Ben AbdallahFollow

Software Engineer • Technical Writer (300K+ readers & 25K+ followers) • Trusted by 20+ startups and tech companies worldwide I turn brands into websites people 💙 to use

I Tested 5 Design to Code Tools With the Same Outdated SaaS Dashboard

Hadil Ben Abdallah — Wed, 26 Aug 2026 09:05:06 +0000

A polished UI can make a product feel completely different, but getting there usually takes more than changing a few colors or swapping out an old chart. Modern design to code tools can now handle much of that work, from redesigning an existing interface to generating the frontend code behind it.

That’s what made me curious about today’s design to code tools.

Instead of testing each tool with a different project or judging them from a demo, I wanted to put them on equal ground. So I took the same outdated SaaS analytics dashboard, gave the same dashboard screenshot to five popular tools, and used the same redesign prompt for every test.

The five tools I tested were:

Flowstep
Anima
v0 by Vercel
Lovable
Bolt.new

The goal wasn’t to see which tool could produce the prettiest screenshot.

I wanted to see how each one handled the same real-world UI problem: modernizing an old dashboard while keeping its core information and functionality intact.

I also looked at the generated frontend code, because a beautiful interface doesn’t help much if the code underneath it becomes a mess that developers have to rebuild.

So, how different were the results when every tool started with exactly the same design and instructions?

Let’s find out.

TL;DR

I tested five design to code tools, Flowstep, Anima, v0 by Vercel, Lovable, and Bolt.new, using the same outdated SaaS analytics dashboard and the same redesign prompt.

The original dashboard had the kind of interface you might recognize from older analytics products: dense navigation, dated typography, limited visual hierarchy, tightly packed content, and a layout that could use a serious UX refresh.

The challenge for each tool was to preserve the dashboard’s core information while giving it a modern 2026 interface.

I evaluated the results across several areas, including visual design, hierarchy, spacing, typography, component quality, UX, and frontend code quality.

Here’s the quick result:

Flowstep → Strongest overall redesign, with a modern visual system, clear hierarchy, polished spacing, and well-structured frontend code.
Anima → Produced a cleaner interface with good code, although the final design still felt fairly basic.
v0 by Vercel → Stayed close to the original dashboard while improving its presentation; the result still needed more visual refinement.
Lovable → Delivered a clean, well-designed dashboard with solid frontend code and a good overall balance.
Bolt.new → Created a well-structured interface with good hierarchy and typography, although the result needed some additional updates.

The test also showed something that can get lost in AI tool comparisons: design to code tools are not equally good at the same parts of the workflow.

A tool can produce impressive code while delivering an average visual redesign, while another can create a polished interface but leave more work for the developer.

That’s why I’m not treating this as a competition to discover which tool generated the prettiest UI. What matters more to me is how much each tool improved the starting design and how usable the result would be for a real frontend project.

What Are Design to Code Tools?

Design to code tools are platforms that help turn visual designs, screenshots, UI concepts, or product requirements into frontend interfaces and code.

The category has changed quite a bit with the rise of AI. Traditional design to code workflows often started with a finished design file, such as a Figma project, and focused on translating that design into HTML, CSS, React, or another frontend stack.

Modern AI-powered tools can start much earlier in the process.

You might give a tool a Figma design and ask it to generate the implementation. You might provide a screenshot and ask it to recreate or redesign the interface. Or you might describe the product you want and have the tool generate the UI and application code from a prompt.

That makes design to code tools useful for several different workflows, including:

Figma to code
screenshot to code
AI UI generation
prompt to UI development
AI app building

But there’s an important difference between generating something that looks good and generating something that developers can work with.

A dashboard can look impressive in a screenshot and still have poor component structure, awkward responsive behavior, duplicated styles, or code that needs extensive cleanup. On the other hand, clean code isn’t enough if the generated interface barely improves the original design.

Testing 5 Design to Code Tools With the Same SaaS Dashboard

To make the comparison as fair as possible, I kept the starting point and instructions consistent across all five tests.

Each tool received the same outdated dashboard screenshot and the same prompt. I then evaluated the generated result.

The Outdated SaaS Analytics Dashboard

For the test, I used an older SaaS analytics dashboard with a dense desktop layout and a dated visual style.

The original interface contains several common analytics dashboard elements: a left-hand navigation menu, a top navigation bar, site metrics, a line chart, metric cards, content tables, action statistics, traffic-source charts, visitor information, referrers, and recent activity.

Old SaaS analytics dashboard

The screen works as a good test case because there is plenty of useful information to preserve, but there is also a lot of room for a visual and UX redesign.

The challenge wasn’t to invent a completely different product. The tools needed to understand the existing dashboard, keep its core information and functionality, and give it a more modern interface.

That makes the test closer to a real redesign task than simply asking an AI tool to create a dashboard from scratch.

The Prompt I Gave Every Tool

I used exactly the same prompt for all five tools:

Redesign this outdated SaaS analytics dashboard with a modern 2026 UI.
Keep the same core information, functionality, and content, but improve the visual hierarchy, spacing, typography, and overall user experience.

I deliberately kept the prompt relatively short without too many details to see the creativity of each tool.

The SaaS dashboard screenshot provided the visual context, while the prompt established the main requirements.

How I Compared the Results: Evaluation Criteria

I didn’t judge the five outputs on appearance alone.

For each result, I looked at several aspects of the redesign and implementation:

Visual design: Does the redesigned dashboard actually feel modern and polished?
Visual hierarchy: Are the most important metrics, charts, navigation elements, and actions easy to identify?
Spacing and layout: Does the interface have enough breathing room, or does it still feel crowded?
Typography: Are font sizes, weights, and text hierarchy used effectively?
Component quality: Are cards, charts, tables, navigation, and other UI elements presented as a coherent system?
User experience: Is the dashboard easier to scan, understand, and use than the original?
Code quality: Is the generated frontend code structured, readable, and practical for further development?
Room for improvement: How much additional work would I need to do before considering the result ready for a real project?

The last criterion matters because AI-generated UI is rarely finished after the first prompt.

A useful design to code tool should give you a strong starting point, but the real value comes from how much work remains after that first generation.

If the result looks good but requires a complete rebuild, the time savings are smaller than they appear.

Quick Comparison Table

Before getting into each tool in detail, this comparison table provides a quick overview of the five tools I tested. It compares them based on their ideal use case, free availability, starting price, and standout capabilities, helping designers and developers quickly find the design to code tool that best fits their workflow.

Tool	Best For	Free Plan	Starting Price	Standout Feature
Flowstep	Modern UI redesigns and frontend code	✅	$15/mo	Design to code workflow with editable UI and structured code
Anima	Turning existing designs into frontend code	✅	$25/mo	Figma-to-code workflow
v0 by Vercel	React UI and application generation	✅	$30/mo	React, Tailwind CSS, and shadcn/ui generation
Lovable	Rapid web app prototyping	✅	$25/mo	Full-stack app generation from natural language
Bolt.new	Browser-based AI development	✅	$25/mo	Code, preview, and development environment in one place

The table gives you the quick answer, but it doesn't tell the whole story. Two tools can generate perfectly usable dashboards while taking very different approaches to design and code.

So, let’s look at each tool individually.

1. Flowstep

Flowstep is an AI design engineer that helps turn a product UI idea into editable interface designs and frontend code. It is closer to the design and development workflow than a traditional image-to-code converter, which makes it useful when you want to rethink an existing interface and then continue toward implementation.

What It Generated

Flowstep produced the biggest visual transformation of the five tools I tested.

The redesigned dashboard moved away from the dated layout and introduced a much more modern 2026 interface. The visual hierarchy was noticeably stronger, with clearer separation between the main analytics area, supporting metrics, charts, and secondary information.

The spacing and typography also felt more intentional. Elements had more room to breathe, the different sections were easier to scan, and the dashboard felt closer to something you would expect from a current SaaS analytics product.

The component structure was another strong point. The generated frontend code was clear and well organized, which made the result more useful from a development perspective.

Flowstep's redesigned SaaS analytics dashboard

Key Features

AI-powered UI generation: Create interface designs from natural-language descriptions.
Multi-screen workflows: Generate connected product screens from the same design context.
Editable designs: Continue refining the generated interface after the initial generation.
Frontend code generation: Generate code that can serve as a starting point for implementation.
React and TypeScript support: Useful for modern frontend development workflows.
Tailwind CSS and shadcn/ui: Works well with popular React-based UI technologies.
Figma copy-paste: Move generated designs into Figma without relying on a separate plugin.
Reference-based design: Use visual references and other context to guide the generated interface.
MCP integration: Connect design context with compatible coding agents and development workflows.

Pricing

Flowstep offers a free tier, with paid plans starting at $15/month.

2. Anima

Anima is a design to code platform that helps turn existing designs, websites, and visual concepts into frontend code. Its workflow is especially useful when you already have a design and want to move from the visual interface to an editable implementation that developers can continue working with.

What It Generated

Anima produced a cleaner version of the dashboard, and the overall redesign was definitely an improvement over the original interface.

The layout felt more organized, and the updated visual treatment made the dashboard easier to look at. The core analytics information was still there, so the redesign didn't lose the purpose of the original screen.

That said, compared with some of the other results in this test, the final design still felt fairly basic. It looked cleaner and more modern than the original dashboard, but it didn't go as far visually as I expected from a complete 2026 redesign.

The code was a stronger part of the result. The generated frontend structure was good and provided a reasonable starting point for further development. For teams that already have a design and mainly want to speed up the transition from design to implementation, that makes Anima worth considering.

Anima's redesigned SaaS analytics dashboard

Key Features

Figma-to-code conversion: Convert existing design files into frontend code.
React code generation: Generate React-based implementations from designs.
HTML and CSS export: Support projects that don't use a React stack.
Design-to-development workflow: Reduce manual recreation between design and implementation.
Component-based output: Turn parts of a design into reusable frontend components.
Responsive design support: Translate responsive layouts into code.
AI-assisted workflows: Use AI to help accelerate design and development tasks.
MCP support: Connect design context with compatible AI coding workflows.

Pricing

Anima offers a free plan, with paid plans starting at $25/month.

3. v0 by Vercel

v0 by Vercel is an AI-powered development platform that turns natural-language prompts and visual references into interfaces and web applications. It is especially well suited to React-based projects, with strong support for technologies such as Tailwind CSS and shadcn/ui.

What It Generated

v0 stayed fairly close to the original dashboard I provided.

That isn't necessarily a bad thing. The generated version preserved much of the original information and overall structure, which means the result was easy to recognize as a redesign of the same product rather than an entirely different dashboard.

The visual treatment was cleaner, and the layout had a more contemporary feel, but I still think it needed another round of refinement before I would call it a polished 2026 SaaS dashboard. Some areas could use stronger visual hierarchy, more distinctive component styling, and additional attention to spacing and overall visual balance.

The code was one of the stronger parts of the result. The generated implementation was good and gave me a solid foundation to continue improving the interface. This is where v0 makes a lot of sense for developers who care about getting from an interface concept to editable React code quickly.

v0's redesigned SaaS analytics dashboard

Key Features

Prompt-to-UI generation: Describe an interface or application and generate a working frontend.
React support: Generate React components and applications for modern web development.
Tailwind CSS: Build interfaces using a widely adopted utility-first CSS framework.
shadcn/ui integration: Generate interfaces using reusable, customizable UI components.
Visual iteration: Preview and refine generated interfaces as you work.
Code editing: Developers can inspect and modify the generated implementation.
Application generation: Go beyond individual screens and create more complete web applications.
Vercel integration: Fits naturally into workflows that already use Vercel for deployment and hosting.

Pricing

v0 offers a free plan with usage limits. Paid plans start at $30/month.

4. Lovable

Lovable is an AI app builder that turns natural-language instructions into functional web applications. It goes beyond generating a single interface because the platform can also work with application logic, databases, authentication, and other pieces needed to turn an idea into something users can actually interact with.

What It Generated

Lovable produced a clean and modern redesign that successfully moved the dashboard away from its original dated appearance.

The information was reorganized into a more contemporary dashboard structure, while the interface retained the important analytics content from the original screen. The result felt cleaner without becoming unnecessarily complicated.

The visual hierarchy was also good. The main metrics were easier to identify, supporting information had clearer separation, and the overall dashboard felt more cohesive.

The generated code was another positive point. It was clean enough to provide a useful foundation for continued development, which is important when you're using an AI tool for more than a quick visual prototype.

Lovable's redesigned SaaS analytics dashboard

Key Features

Natural-language app generation: Describe what you want to build and generate a functional application.
AI-powered UI generation: Create and refine interfaces through prompts.
Full-stack development: Build more than static frontend screens.
React-based applications: Generate modern web application interfaces that developers can continue editing.
Database integration: Connect applications to backend data and database services.
Authentication: Add login and user-management functionality.
Conversational editing: Continue modifying the application through natural-language instructions.
Deployment workflows: Move generated applications toward a usable deployed experience.
Code ownership and editing: Continue working with the generated project instead of being limited to a static mockup.

Pricing

Lovable offers a free plan with usage limits. Paid plans start at $25/month.

5. Bolt.new

Bolt.new is an AI-powered development environment from StackBlitz that lets you create, edit, run, and preview web applications directly in the browser. It combines AI-assisted coding with an in-browser development environment, so you can move from an idea or design reference to a working project without setting up the entire development environment locally first.

What It Generated

Bolt produced a well-structured redesign with a clear visual hierarchy.

The dashboard was more organized than the original, and the typography, spacing, and overall arrangement made the information easier to scan. The core analytics content remained recognizable, while the interface received a more contemporary treatment.

The result wasn't completely finished, though. A few areas still needed additional updates before the dashboard felt fully polished. Some components could benefit from more refinement, and another iteration would help bring the visual language together more consistently.

The code was good and provided a useful foundation for continued development. That's an important advantage of Bolt: once the initial interface is generated, you can continue working on the actual project inside the same browser-based environment.

Bolt.new's redesigned SaaS analytics dashboard

Key Features

Prompt-based development: Describe an application or interface and generate code from natural-language instructions.
In-browser coding environment: Write and modify code without setting up a local development environment first.
Live preview: See the application as you build and make changes.
AI-assisted coding: Use prompts to create, modify, and extend application features.
Multiple framework support: Work with technologies such as React, Vue, Svelte, and Astro.
Built-in terminal: Run development commands within the browser environment.
Full application workflows: Build beyond isolated UI components.
Code access: Developers can directly inspect and modify the generated implementation.
Deployment support: Move projects from development toward a live application.

Pricing

Bolt.new offers a free plan with usage limits. Its paid plans start at $25/month.

What I Learned From Testing All 5 Design to Code Tools

After putting all five tools through the same test, I came away with a clear picture of what separates these platforms.

The first lesson is that visual quality and code quality are two different things. A tool can generate a beautiful dashboard and still leave you with code that needs significant cleanup. Another tool can produce very respectable frontend code while the visual result needs another design pass.

That became obvious throughout this test.

There was also a second lesson that I think matters even more: the best design to code tool depends on what you want to do after the first generation.

If you're only judging the screenshots, you might choose a different winner than if you're planning to take the generated code into a real project.

A beautiful first screen is great. But if you need to spend hours rebuilding components, fixing responsiveness, cleaning up the code, and recreating the design system afterward, some of that initial time saving disappears.

Which Design to Code Tool Should You Choose?

I don't think there is one answer that works for everyone. It depends on what you are trying to accomplish with a design to code tool.

If your priority is creating a modern UI from an existing design or visual reference and getting clean frontend code alongside it → Flowstep is the strongest choice from my test. It gave me the biggest visual improvement while also producing frontend code that was clear and structured.

If you're working heavily with Figma designs → Anima makes more sense. Its workflow is built around taking existing designs and moving them toward implementation, and the code it generated in my test was good. The redesign itself just didn't feel as visually ambitious as some of the other results.

If you're a developer who wants React code and a strong component foundation → v0 is worth considering. Its result stayed fairly close to the original dashboard, but the generated code was good, and the interface can be refined further.

If your goal goes beyond the UI and you want to turn an idea into a working application → Lovable is a stronger fit. Its clean dashboard result was only one part of the workflow; the platform can also handle application logic and backend functionality.

And if you want an AI development environment where you can generate, edit, preview, and continue coding in the browser → Bolt.new is a compelling option. Its dashboard had a good structure and hierarchy, although I would still give the design another pass before considering it finished.

Here's how I'd break down the five based on this particular test:

If you want...	My pick
The strongest overall UI redesign + frontend code	Flowstep
Figma-to-code workflows	Anima
React and shadcn/ui development	v0 by Vercel
A functional full-stack application	Lovable
An in-browser AI development environment	Bolt.new

This wasn't a benchmark of everything these products can do. I gave them one outdated SaaS dashboard and one prompt. Your results can change depending on the complexity of the design, the quality of the prompt, the framework you're targeting, and how much iteration you do after the first generation.

So if you're choosing between these design to code tools, I'd use my results as a starting point, then test the tool against a screen from your own product. That's where you'll find out whether it fits your workflow.

FAQs About Design to Code Tools

What are the best design to code tools in 2026?

→ The best design to code tool depends on the type of input you're working with and the output you need. In my test, Flowstep produced the strongest overall redesign and clean frontend code. Anima is a good option for existing design to code workflows, especially when Figma is involved. v0 is well suited to React development, while Lovable and Bolt.new are useful when you want to turn ideas into working web applications.

Can AI design to code tools turn an existing UI into code?

→ Yes. Many modern design to code tools can take an existing visual design, screenshot, or interface and generate frontend code from it.

The exact workflow varies between products. Some tools are built around Figma-to-code conversion, while others can use screenshots or visual references as input. AI app builders can also use an existing interface as context while generating a new implementation.

The generated code should still be reviewed before it goes into production. Check the component structure, responsiveness, accessibility, performance, dependencies, and how well the implementation fits your existing codebase.

Are design to code tools good enough for production?

→ They can provide a strong starting point for production development, but I wouldn't treat the first generated result as production-ready without review.

Production readiness involves more than making a screen look good. Developers still need to consider responsive behavior, accessibility, performance, security, component reuse, state management, error handling, testing, and maintainability.

The real value of these tools is that they can reduce the amount of repetitive work required to reach that stage.

What is the difference between design to code tools and AI app builders?

→ The difference is mainly in the starting point and the scope of the output.

Design to code tools generally focus on moving from a visual design or UI concept toward frontend implementation. They can help translate an existing design into components and code or generate a UI from a description.

AI app builders usually take the process further. They can start with a product idea and generate not only the interface but also application logic, database functionality, authentication, and other parts of a working application.

Final Thoughts

Testing five design to code tools with the exact same dashboard gave me a better understanding of what these tools are good at.

The biggest conclusion is that AI can now do much more than simply turn a static design into a few lines of frontend code. It can interpret an existing interface, make design decisions, reorganize information, generate components, and produce a working implementation in a short amount of time.

But speed doesn't remove the need for judgment.

A generated dashboard still needs someone to decide whether the hierarchy makes sense, whether the interface is accessible, whether the layout works across screen sizes, and whether the code can realistically live inside a larger application. The first generation is only one step in the process.

That's also why I think testing the same project across multiple design to code tools is more useful than looking at feature lists alone. When every tool receives the same input, differences in design quality, code structure, usability, and refinement become easier to see.

And there isn't necessarily one tool that will produce the best result for every project. Your starting design, framework, level of customization, development workflow, and willingness to iterate can all change the outcome.

The important part is knowing where the generated result is good enough, where it needs another iteration, and where a developer still needs to take over.

Thanks for reading! 🙏🏻 I hope you found this useful ✅ Please react and follow for more 😍 Made with 💙 by Hadil Ben Abdallah

Hadil Ben AbdallahFollow

Software Engineer • Technical Writer (300K+ readers & 25K+ followers) • Trusted by 20+ startups and tech companies worldwide I turn brands into websites people 💙 to use

I Used React DataGrid to Build a Real Space Mission Explorer

Hadil Ben Abdallah — Mon, 24 Aug 2026 09:09:25 +0000

I went through the documentation and feature list of React DataGrid, and I wrote React DataGrid: A Free, Open-Source React Data Grid with an Enterprise Edition (An AG Grid Alternative)

Now I wanted to use it the way I would use any other data grid in a real project: start with a real dataset, build useful interactions around it, push the grid with a large number of records, and see where things get difficult.

So I built a Space Mission & Satellite Explorer, a small flight-dynamics-style web application for exploring missions across different agencies, destinations, mission types, and decades.

The project works with a 100,000-mission live archive, while a 1,200-row client-side working set powers the interactive analysis experience. That gave me a good opportunity to test much more than basic sorting and pagination, including filtering, faceted search, grouping, pivoting, row pinning, custom cell renderers, virtual scrolling, and server-side infinite scrolling.

I also built two other parts of the application around the same data: a Mission Analytics page for aggregating and visualizing the dataset, and a Mission Details page where I used Tree Data to represent an individual mission's timeline.

This article is about what happened while building it, from setting up React DataGrid and configuring the first columns to working with 100,000 records and deciding whether I'd reach for it again in another data-heavy React project.

TL;DR

I built a Space Mission Explorer with React DataGrid to see how it would handle a real application.

The project uses a 1,200-row client-side dataset for interactive analysis and a 100,000-row live archive loaded through server-side infinite scrolling.

Along the way, I used features including:

multi-column sorting
quick search
faceted filtering
row grouping
row pinning
a Pivot Table builder
custom cell renderers
virtual scrolling
CSV/Excel export
Tree Data for Mission Timelines

The integration was smoother than I expected. The API felt familiar from the beginning; most of the features I needed worked as expected from the documented examples with relatively little adjustment, and switching between the smaller working dataset and the full archive stayed responsive.

There were still a few areas that required more digging, which I'll cover later, but overall, building the project gave me a better impression of React DataGrid than I could have gotten from reading its feature list.

What I Built: A Space Mission Explorer

I called the project an Orbital Index / Mission Data Terminal.

The idea was simple: take a large archive of fictionalized space-mission records and turn it into something developers could imagine using, a searchable, filterable interface where you can explore missions by agency, destination, status, mission type, launch date, duration, cost, and decade.

I deliberately chose this instead of building another generic CRUD dashboard because the dataset naturally creates the kinds of problems where a data grid becomes useful.

A mission record has enough structured fields to make filtering and sorting meaningful. Missions can be grouped by agency or destination. Costs and durations can be aggregated. And the mission itself has a natural hierarchy:

Launch → Earth Orbit → Translunar Injection → Lunar Orbit → Descent & Landing → Surface Operations → Return to Earth

That last part also gave me a reason to test Tree Data instead of adding it just to check another feature off a list.

The application ended up with three main pages:

Mission Explorer: The main data-grid interface for searching, filtering, grouping, pivoting, editing, and exploring the mission archive.
Mission Analytics: A chart-focused view that turns the same mission data into success rates, agency comparisons, destination distributions, duration statistics, and cost analysis.
Mission Details: An individual mission view with metadata, crew and equipment information, related dossiers, and a hierarchical mission timeline.

The Explorer is where most of my React DataGrid testing happened. The Analytics page uses the same 1,200-row working dataset and aggregation logic to produce visualizations, while the Details page gave me a completely different use case for the grid's hierarchical data capabilities.

For the stack, I used React, TypeScript, Tailwind CSS, React DataGrid, the mission dataset, and a charting library for the analytics view.

One quick transparency note before I dive into the grid: I vibe-coded a small part of the initial project setup to avoid spending a big chunk of my time building boilerplate that wasn't really the point of this experiment.

The goal here wasn't to prove that I could build an entire space-mission website from scratch; it was to spend my time actually using React DataGrid in a realistic project and see how it handled the data, interactions, and scale.

I deliberately kept the project small enough to understand from end to end but complex enough that a basic <table> would start becoming a problem.

You can check out the full project and explore the missions yourself.

Live Demo 👀

GitHub Repository ⭐

Setting Up React DataGrid

Once I had the project structure in place, I wanted to get the grid working before spending time on the rest of the interface. I started with the open-source package and kept the first render intentionally simple.

The installation was straightforward:

npm install react-open-source-grid

Then I imported the library's stylesheet:

import 'react-open-source-grid/dist/lib/index.css';

For the first test, I created a small grid with only a few mission fields:

const columns: Column[] = [
  { field: 'mission', headerName: 'Mission', width: 200 },
  { field: 'agency', headerName: 'Agency', width: 120 },
  { field: 'status', headerName: 'Status', width: 140 },
  { field: 'launchDate', headerName: 'Launch Date', width: 130 },
  { field: 'destination', headerName: 'Destination', width: 150 },
];

From there, I defined typed columns for Mission, Agency, Status, Launch Date, Destination, Mission Type, and Duration and mapped the dataset to them.

At this stage, the API felt familiar, so I didn't have to spend much time learning a completely unfamiliar grid model.

I also kept the React DataGrid GitHub repository and documentation close by while building, since this was a hands-on test.

Building the Mission Explorer

I didn't want to build a grid with a few rows just to say I had used one. I wanted enough data and enough interactions to see whether the component could handle the kind of complexity you'd expect in a real application.

I ended up using two dataset modes: a 1,200-row client-side working set for interactive analysis, virtual scrolling, and a 100,000-row live archive that loads records on demand through server-side infinite scrolling.

The difference between the two modes was useful because it gave me two different ways to work with the same mission data instead of artificially creating a huge dataset just for benchmarking.

Mission Explorer page

Sorting, Filtering, and Search

I started with the interactions I'd expect from any data grid. The column headers support sorting, including multi-column sorting, so I could do things like sort missions by agency and then by launch date without writing custom sorting logic myself.

For filtering, I had both the global search bar and individual column filters. The global search makes it easy to quickly find a mission, agency, or destination, while the filters directly under the column headers give me more control when I need to narrow down a specific field.

The sidebar filters were even more useful for this dataset. Instead of forcing me to type everything into a search box, the faceted search panel lets me filter by Agency, Status, Destination, Mission Type, and Decade. Each facet also displays live counts, such as NASA (265) or Successful (839), so I can immediately see how much data each filter represents.

If I want to see only successful NASA missions to Mars from the 1990s, I can narrow the dataset from several different dimensions without building a complicated filter UI around the grid myself.

I also tested column resizing and reordering, and both were straightforward to use when adjusting the Explorer to different screen sizes and workflows.

Sorting, Filtering, and Search

Grouping and Pinning

Once filtering was working, I wanted to see how the grid handled more analytical interactions.

React DataGrid lets me drag columns into the grouping area above the table. That means I can group missions by something like "Agency" and then further organize them by another field, instead of treating every mission as an isolated row.

Grouping and Pinning

I also pinned four reference missions to the top of the grid. This is a small feature, but I found it really useful when working with a large dataset because important records remain visible while I scroll through the rest of the archive.

Pivot Table

The most interesting part of the Explorer was the built-in Pivot Table builder.

Instead of manually writing aggregation logic for every analysis I wanted to perform, I could choose a Row Group By, Pivot Column, Value Column, and Aggregation, then apply the configuration directly from the interface. I could also toggle totals rows and a grand total column.

For example, I could group missions by agency, pivot them by destination, and aggregate values such as duration or cost. That turns the grid from a place where I simply browse records into something I can use to explore the dataset.

Pivot Table

Custom Cells, Totals, and Export

I also used custom cell rendering to make the grid easier to scan. Mission statuses aren't displayed as plain text; they're represented with color-coded badges for Successful, Planned, Partial Success, Failed, Cancelled, and in progress. The working set also includes a totals footer that aggregates values such as duration and cost.

Around the grid, I added the controls I would actually expect to use in a production data table: a column picker, CSV and Excel export, a layout reset control, and four density options ranging from Ultra Compact to Comfortable.

Custom Cells and Totals

CSV and Excel export

What I liked most was being able to combine faceted filtering, grouping, pivoting, pinned rows, custom renderers, and export in the same interface without the page turning into a collection of disconnected controls.

Building Mission Analytics

Once the Mission Explorer was working, I wanted to use the same dataset for something beyond browsing individual records. That's why I made the second page, Mission Analytics.

This page is deliberately chart-first. Instead of displaying another table, I used the same mission data and aggregation logic from the Explorer to create a set of visualizations that answer higher-level questions about mission history, agencies, destinations, and costs.

At the top, I added four summary cards:

1,200 missions in scope
79.6% average success rate
$669.12B in program cost
1,543 days average mission duration

Under those cards, the page contains five different visualizations: launch cadence by decade, agency reliability, destination distribution, success profile by mission type, and cost versus mission duration.

Mission Analytics page

Launch Cadence and Agency Reliability

The first chart looks at Launch Cadence by Decade, showing how the number of missions and successful missions changed across the different decades in the dataset.

This gives the archive a historical dimension that isn't obvious when you're looking at individual rows in the Explorer. Instead of asking which missions launched, I can start asking how mission activity changed over time.

Next, the Agency Reliability chart compares launch volume with average success rates across agencies such as NASA, SpaceX, Roscosmos, ESA, CNSA, ISRO, JAXA, and Blue Origin.

This is where the aggregation capabilities became useful. The chart isn't based on a separate dataset created just for the dashboard. It's derived from the same mission records I was already filtering, grouping, and analyzing in the Explorer.

Launch Cadence and Agency Reliability

Destination, Mission Type, and Cost

The other three visualizations look at different dimensions of the same data.

The Destination Distribution chart shows where missions in the archive are going, with destinations including Earth Orbit, the Moon, Mars, the Asteroid Belt, Deep Space, and Jupiter.

The Success Profile by Mission Type takes another angle by comparing success rates across mission types such as rovers, orbiters, flybys, robotic landers, space telescopes, and sample-return missions.

Finally, the Cost vs. Mission Duration scatter plot lets me look at whether expensive missions also tend to have longer durations. Each point represents an individual mission, making it easier to spot unusually expensive or long-running programs.

What I found interesting here is that I didn't need to put another grid on this page for React DataGrid to remain useful. The grid's underlying dataset and aggregation logic are still doing the work; I'm simply presenting the results in a form that's easier to interpret visually.

Destination, Mission Type, and Cost

Building the Mission Details Page

After working with the full archive, I wanted the third page to do the opposite: take me from 100,000 missions down to one specific mission.

For this example, I used MX-000006, Apollo VIII. The page brings the mission's main information together, including its launch date, duration, program cost, and crew, without forcing everything into another large table.

Mission Details Page

The most interesting part of this page, though, is the Mission Timeline.

Using Tree Data for a Real Mission Timeline

A mission isn't just a collection of unrelated fields. It naturally has an ordered structure: launch happens before orbital insertion, which happens before the mission's main operations, and so on.

That made the timeline a good place to use Tree Data.

For Apollo VIII, I structured the mission into 5 phases:

Apollo VIII
├── Launch
├── Orbit Insertion
├── Payload Commissioning
├── Operations
└── Deorbit

Each phase has its own COMPLETE status badge and a T+ day offset, so the timeline gives me both the hierarchy and the chronological context of the mission.

Tree Data for a Real Mission

This is one of the features that made more sense once I had a real application to build. I could have created a custom nested component for the timeline, but Tree Data already maps naturally to this kind of structured information.

The rest of the page contains the Crew Manifest, Payload & Equipment, and Related Dossiers sections. These keep the additional mission information accessible without turning the page into another dense data-management screen.

Crew Manifest, Payload & Equipment and Related Dossiers

At this point, I had all three parts of the application working together:

Mission Explorer for searching and manipulating the archive
Mission Analytics for understanding the data at a higher level
Mission Details for drilling into an individual mission

This gave me a better environment for evaluating React DataGrid than a small demo table would have. I had real filtering, grouping, pivoting, hierarchical data, custom rendering, and large datasets all working in the same project.

Theming & UI Customization

Once the functionality was working, I spent some time making the grid belong inside the application. The default data grid look would have worked, but it didn't really fit the dark, cyan-accented flight dynamics terminal style I was going for.

I used theme variables to adapt the grid's appearance and added custom cell renderers for the mission status badges. The badges use different colors for states such as Successful, Planned, Partial Success, Failed, Cancelled, and in progress, which makes scanning the Explorer much easier.

I also used four density modes, Ultra Compact, Compact, Normal, and Comfortable, so the amount of information displayed per row can be adjusted without rebuilding the grid layout.

What I appreciated here is that customization didn't require me to fight the component's default styling. Most of the work was about making React DataGrid match the visual language of the project rather than trying to work around the grid itself.

Developer Experience: What Was Easy and What Took More Work

The overall developer experience was one of the biggest positives from this project. Installation and getting the first working grid on screen took less time than I expected, and the API felt familiar.

Once the basic grid was running, adding sorting, filtering, grouping, and the Pivot Table builder was straightforward and aligned with the documented examples. The same was true for the Tree Data implementation on the Mission Details page. I wasn't constantly trying to figure out how to make the library do something it wasn't designed to do.

Accessibility was another area I paid attention to while working with the grid. I also tested keyboard navigation and paid attention to the grid's ARIA behavior while working through the interface. The documentation also gave me enough examples to understand the less common features I was using.

That said, not every part of the process was equally straightforward. The more specialized features required more time to understand than everyday operations such as sorting or filtering. The Pivot Table builder and Tree Data configuration were the areas where I spent more time checking examples and figuring out exactly how I wanted the data structured.

React DataGrid vs. a Basic HTML Table: What I Would Choose

If I were only displaying five or ten rows of static data, I wouldn't reach for React DataGrid. A basic HTML table or lightweight React table would be simpler and would do the job well.

This project was a very different situation.

Once I needed 100,000 missions, faceted search, multi-column sorting, grouping, pivoting, Tree Data, custom cell renderers, and server-side infinite scrolling, a basic table would have required me to build a large part of that functionality myself.

That's where React DataGrid made more sense. Instead of spending my time building and maintaining table infrastructure, I could focus on the actual application: how missions should be organized, what users should be able to explore, and how the analytics should work.

Is React DataGrid Worth Using?

After building a project with it, I think React DataGrid makes sense for applications where the data itself is a major part of the user experience.

I'd particularly consider it for:

Data-intensive dashboards
Analytics applications
Admin interfaces
Financial applications
Internal business tools
Applications with large datasets
Projects with complex filtering or grouping
Applications with hierarchical data
React applications that need server-side data loading

The Space Mission Explorer was a good test because it combined several of these requirements at once. I had a 1,200-row client-side working set for interactive analysis and a 100,000-mission live archive using server-side infinite scrolling.

Final Thoughts

Building the Space Mission Explorer gave me a better perspective on React DataGrid than I could have gotten from a feature checklist alone.

I was able to take a real dataset, turn it into an interactive explorer for a 100,000-row mission archive, build analytics around it, and use Tree Data for a mission timeline without having to build the grid infrastructure myself.

For data-heavy React applications, that's ultimately what matters:

The grid should handle the complexity of the data so you can focus on building the product around it.

Thanks for reading! 🙏🏻 I hope you found this useful ✅ Please react and follow for more 😍 Made with 💙 by Hadil Ben Abdallah

Hadil Ben AbdallahFollow

Software Engineer • Technical Writer (300K+ readers & 25K+ followers) • Trusted by 20+ startups and tech companies worldwide I turn brands into websites people 💙 to use

How to Reach Your Full Potential as a Programmer (It's Probably Not What You Think)

Hadil Ben Abdallah — Mon, 17 Aug 2026 13:05:25 +0000

Every programmer wants to improve.

We all dream about becoming the person who can look at a difficult problem, think for a few minutes, and confidently build a solution from scratch.

But whether you're writing your first "Hello, World!" program or you've been coding for years, you've probably asked yourself this question:

"How do I actually become a great programmer?"

The internet is full of advice.

One person tells you to build more projects. Another says you should solve hundreds of coding problems…

Then someone else insists that AI has changed everything and that learning has never been easier.

But the truth is…
There are no shortcuts.

The developers who keep improving year after year usually have something else in common: they build habits that make learning part of their daily routine.

Here are the habits that I believe make the biggest difference.

1. Go Beyond Tutorials and Learn the Fundamentals

Tutorials are a great place to start.

They help you build your first application, understand a new framework, or explore a technology you've never used before. We've all learned something valuable from a good tutorial.

But tutorials shouldn't become your entire learning strategy.

At some point, you need to understand why the code works instead of simply following someone else's steps. That's where books, official documentation, and software architecture resources become valuable.

The more you understand the reasoning behind a solution, the easier it becomes to solve completely new problems without searching for another tutorial.

2. Stop Treating Working Code as the Finish Line

We've all done it.

You find a solution online, paste it into your project, it works perfectly… and you immediately move on to the next task.

The problem is that your application improved, but your understanding didn't

Instead…

Get curious
Remove a line of code
Change a function
Replace one approach with another
See what breaks, then figure out why it broke

Those little experiments teach you far more than simply reading an article or watching a video.

3. Spend More Time Outside Your Comfort Zone

Growth feels exciting in hindsight.

While it's happening, it usually feels frustrating.

If you've been building the same type of application for months, using the same framework and the same programming language, you're probably becoming more efficient, but not necessarily becoming a better programmer.

Try something different.

Build an API if you've only worked on the frontend
Learn a systems language if you've only written Python
Explore mobile development, databases, networking, or cloud technologies

The goal isn't to master everything.
The goal is to keep giving your brain new problems to solve.

4. Take Ownership Instead of Waiting for Permission

The habit I've noticed in strong developers is that they don't always wait for interesting work to appear.

They look for opportunities to challenge themselves.

Maybe it's the feature everyone keeps postponing.
Maybe it's the bug nobody wants to investigate.
Maybe it's improving a tool the whole team relies on every day.

Those moments rarely come with a big announcement.

But they're often the projects that teach you the most because they force you to think beyond your comfort zone.

5. Don't Be Afraid of Open Source

Open source can look intimidating from the outside.

You see thousands of contributors, millions of lines of code, and assume you have nothing valuable to add.

In reality, it's much simpler than that.

Not every contribution needs to introduce a complex new feature.

Fixing documentation
Improving an example
Correcting a typo
Reporting a bug

They all matter.

Once you start contributing, you also begin learning how experienced developers organize projects, review code, and collaborate on software that people actually use.

That's an experience personal projects don't provide.

6. Surround Yourself with Developers Who Inspire You

Programming isn't something you have to learn alone.

Some of the biggest improvements in my own journey came from reading other developers' code, joining technical communities, and paying attention to how experienced engineers approached problems.

Being around people with higher standards naturally pushes you to improve your own work.

It might be an open-source community, a local meetup, Discord, a DEV community, or even a colleague whose code you admire.

Being part of those communities exposes you to ideas, feedback, and different ways of thinking that you probably wouldn't discover on your own.

Sometimes a single conversation can completely change the way you think about software development.

7. Teach What You Learn

One of the fastest ways to discover what you actually understand is trying to explain it to someone else.

The moment you write a blog post, answer a question online, or help a teammate solve a problem, you quickly notice the parts you're still unsure about.

That's not a weakness. It's part of the learning process.

Teaching forces you to organize your thoughts, simplify complex ideas, and fill the gaps in your own understanding.

And along the way, you might help another developer who's just starting the same journey.

So, How Do You Actually Become a Better Programmer?

There isn't one secret technique.

No single programming language, framework, course, or AI tool will suddenly make you an exceptional developer.

Real progress comes from combining small habits and repeating them consistently.

Read beyond tutorials
Experiment with your code
Challenge yourself with unfamiliar problems
Take ownership
Contribute to open source
Learn from developers who push you to improve
Share what you learn with others

Final Thoughts

Every programmer's journey is different.

Some people learn quickly because they have great mentors. Others figure things out through countless experiments, mistakes, and late-night debugging sessions.

No matter where you are today, reaching your potential isn't about knowing every programming language or memorizing every framework.

It's about staying curious, asking better questions, and never becoming too comfortable with what you already know.

The best programmers aren't the ones who never get stuck.
They're the ones who never stop learning.

Thanks for reading! 🙏🏻 I hope you found this useful ✅ Please react and follow for more 😍 Made with 💙 by Hadil Ben Abdallah

Hadil Ben AbdallahFollow

Software Engineer • Technical Writer (300K+ readers & 25K+ followers) • Trusted by 20+ startups and tech companies worldwide I turn brands into websites people 💙 to use

React DataGrid: A Free, Open-Source React Data Grid with an Enterprise Edition (An AG Grid Alternative)

Hadil Ben Abdallah — Tue, 11 Aug 2026 09:09:04 +0000

If you've ever needed to build a serious data table in React, you've probably run into this problem. React doesn't include a native data grid component, so you're usually left choosing between paying for an enterprise solution or spending weeks building advanced table functionality yourself.

For small datasets, a simple HTML table works well enough. But once you need virtualization, row grouping, inline editing, advanced filtering, server-side data loading, or richer keyboard interactions, things become much more complicated. Those features require significant engineering effort if you decide to build everything from scratch.

That's exactly where React DataGrid, an open-source React data grid with both free and Enterprise offerings, comes in.

In this article, I'll walk through what makes a production-ready React data grid, introduce React DataGrid, show how to get started with its open-source edition, explore its standout features, explain what's available in the Enterprise edition, and compare it with AG Grid so you can decide which option is right for your project.

TL;DR

If you're looking for a React data grid that combines an open-source MIT-licensed core with an optional Enterprise edition, React DataGrid is worth considering.

It's an open-source React data grid built with React 18, TypeScript, and Tailwind CSS, designed for everything from simple data tables to large, data-intensive applications. The free edition provides a broad set of data-grid capabilities, while the Enterprise edition adds commercial features for teams that need more advanced workflows, data operations, and enterprise functionality.

Here's what React DataGrid offers:

✅ MIT-licensed, open-source core that is free to use.
✅ Virtual scrolling for datasets with 100,000+ rows and 200+ columns.
✅ Server-side infinite scrolling for datasets with 100M+ rows, including server-side filtering, sorting, pagination, intelligent block caching, request concurrency, and LRU cache eviction.
✅ Row grouping and aggregation for organizing and analyzing complex datasets.
✅ Tree Data for hierarchical rows and expandable parent-child structures.
✅ Market data support for applications that receive frequent live updates.
✅ 10 built-in themes, custom cell renderers, layout persistence, density modes, and extensive customization APIs.
✅ Accessibility support with WCAG 2.1 AA compliance and a published VPAT 2.4 report.
✅ Enterprise features including Server-Side Row Model, Master/Detail, Formula Engine, Undo/Redo, Range Selection, Clipboard (TSV), Fill Handle, Transactions, Cell Permissions, Audit Trail, Row Locking, Excel/CSV Import, PDF Export, Filter Presets, Saved Views, and Form Editor.
✅ A familiar AG Grid-style API that can make adoption easier for developers already working with enterprise data grid libraries.

What Are React Data Grid Components?

A React data grid component is a specialized table component designed to display and manage large, interactive datasets. Unlike a basic HTML table, it typically includes features such as sorting, filtering, pagination, row selection, inline editing, keyboard navigation, and virtualization.

A traditional HTML <table> is perfectly fine for displaying a few dozen rows of static data. The problem appears once datasets start growing or users need richer interactions.

Rendering thousands of rows can slow down the browser, and implementing advanced behaviors like filtering, editing, or drag-and-drop often means writing and maintaining a significant amount of custom code.

That's why most production React applications rely on dedicated data grid libraries. They solve performance challenges, provide a consistent user experience, and include many of the features that enterprise dashboards, admin panels, analytics platforms, and internal business applications depend on every day.

What Features Really Matter in a React Data Grid?

The difference between a basic data table and a production-ready React data grid comes down to five areas: performance, data operations, server-side capabilities, accessibility, and customization. These are also the features that many free libraries either limit or don't offer at all.

When evaluating a React data grid, here are the capabilities that deserve the most attention:

Performance at scale through virtual scrolling so tens of thousands of rows remain smooth to navigate.
Advanced data operations like row grouping, aggregation, filtering, multi-column sorting, and inline editing.
Server-side support for massive datasets using infinite scrolling, server-side filtering, sorting, and intelligent caching.
Accessibility with keyboard navigation, screen-reader compatibility, and WCAG compliance.
Customization through themes, custom cell renderers, layout persistence, and flexible APIs that fit your application's design system.

Many open-source React grids do one or two of these things well.

Performance might be excellent, but advanced grouping is missing. Another library may support editing but fall short when datasets become truly large.

React DataGrid was built to check every one of those boxes.

Introducing React DataGrid

React DataGrid is an open-source React data grid built with React 18, TypeScript, Tailwind CSS, and Vite. Its open-source core is MIT licensed and published as the react-open-source-grid npm package, while the project also offers an Enterprise edition with additional commercial features. The API is intentionally familiar to developers who have previously worked with AG Grid, which can make the learning curve smaller.

React DataGrid is part of the broader GridEngine platform, which provides data grid solutions for different technologies and use cases.

One thing I particularly like is that the project doesn't expect you to install it blindly. Before writing any code, you can explore a public live demo, browse the documentation, and inspect the GitHub repository to see exactly what the library offers.

That transparency is valuable, especially when you're evaluating a component that may become the backbone of your application's data layer.

Installation & Quick Start

Getting started with React DataGrid is straightforward. If you're starting a new React project or adding a data grid to an existing application, you can install the package and have a working grid running in just a few minutes.

The setup is intentionally minimal so you can focus on your data instead of configuration.

Install the package:

npm install react-open-source-grid

Then import the stylesheet:

import 'react-open-source-grid/dist/lib/index.css';

Finally, create your first grid:

import { DataGrid } from 'react-open-source-grid';
import type { Column, Row } from 'react-open-source-grid';

const columns: Column[] = [
  { field: 'id', headerName: 'ID', width: 70 },
  { field: 'name', headerName: 'Name', width: 180, editable: true },
];

const rows: Row[] = [
  { id: 1, name: 'John Doe' },
  { id: 2, name: 'Jane Smith' },
];

export default function App() {
  return (
    <DataGrid
      columns={columns}
      rows={rows}
    />
  );
}

From this simple starting point, you can gradually enable more advanced capabilities like grouping, virtual scrolling, custom renderers, server-side infinite scrolling, and layout persistence, while keeping the same underlying grid as your application grows.

Core Features of React DataGrid

React DataGrid stands out among open-source React data grid libraries because it doesn't just offer a long feature checklist. The open-source core gives you a broad foundation for everyday data-intensive applications, while the Enterprise edition provides additional capabilities for more advanced workflows as your requirements evolve.

Let's look at the capabilities that make the biggest difference in real-world React applications.

Everyday Grid Features You'll Actually Use

Every data grid should make everyday interactions feel effortless, and React DataGrid's open-source core covers a broad set of essential capabilities without requiring additional plugins or a commercial license.

Out of the box, you get:

Click-to-sort columns
Per-column filtering with advanced filtering options
Pagination with 10, 20, or 50 rows per page
Drag-to-resize columns
Drag-and-drop column reordering
Sticky column headers
Full keyboard navigation
Single and multiple row selection
Double-click inline editing
Built-in quick filter for searching across the entire grid

Beyond those essentials, React DataGrid also includes several quality-of-life features that become valuable in larger applications. APIs such as rowStyle, rowClass, and getRowHeight make it easy to highlight overdue invoices, completed tasks, priority tickets, or any other rows that deserve extra visual attention.

React DataGrid live demo with filtering, sorting, and status badges

Row Grouping and Aggregation for Complex Data

Row grouping is one of those features that developers often don't realize they need until users ask for it. When datasets become more complex, grouping records by department, status, region, customer, or category makes analysis much easier than scrolling through hundreds or thousands of individual rows.

React DataGrid lets users simply drag a column into the grouping area to organize data into expandable groups. Beyond grouping itself, the library also supports aggregation footers at two different levels.

You can display subtotals for each individual group as well as a grand-total footer for the entire dataset, with built-in aggregation functions including:

Sum
Average
Minimum
Maximum
Count

Both group-level and grid-level aggregation are included in the open-source grid. That's noteworthy because similar functionality is often associated with commercial data grid offerings.

Besides row grouping, React DataGrid also supports tree data, allowing you to display hierarchical datasets with expandable parent and child rows. This is useful for cases such as organizational charts, file explorers, category trees, or nested project structures.

React DataGrid Tree Data Demo for folder and file structure with nested directories

Built for Scale: Virtual Scrolling, Market Data, and Server-Side Infinite Data

Performance is often the first thing users notice when working with large datasets. A data grid can have every feature imaginable, but if scrolling feels sluggish or interactions lag, the overall experience quickly suffers.

React DataGrid tackles this challenge with two complementary approaches, depending on the size of your data.

For large datasets that can still live in the browser, the library supports virtual scrolling. Instead of rendering every row and column into the DOM, it only renders what's currently visible on screen.

This enables smooth performance with 100,000+ rows and more than 200 columns, while reducing rendering overhead and memory usage compared to rendering everything at once. The documentation also reports up to 100× faster rendering, 100× lower memory usage, and smooth 60 FPS scrolling in virtual mode.

React DataGrid Virtual Scrolling Demo with 100,000 rows & 200 columns

Performance isn't only about handling large datasets; it also matters when the data is constantly changing. React DataGrid includes support for real-time market data cases, making it suitable for applications that receive frequent live updates while remaining responsive.

If you're building financial dashboards, trading platforms, monitoring systems, or live analytics applications, the grid is designed to process continuous data updates while preserving smooth scrolling and a responsive user experience. This makes it a good option for applications where users need to monitor rapidly changing information without sacrificing performance.

React DataGrid live streaming updates Demo

For applications dealing with truly massive datasets, React DataGrid goes a step further with its free Server-Side Infinite Scroll capability. The InfiniteScrollDataGrid component works with a ServerSideDataSource to request only the data users actually need while scrolling, instead of loading millions of records into the browser at once.

This free server-side mode includes:

Server-side filtering, sorting, and pagination
Intelligent block caching
Configurable request concurrency
LRU cache eviction
Efficient handling of datasets with 100 million or more rows

Despite all of those capabilities, the API is simple:

const dataSource = new ServerSideDataSource({
  blockSize: 100,

  getRows: async (request) => {
    const response = await fetch("/api/data", {
      method: "POST",
      body: JSON.stringify(request),
    });

    return response.json();
  },
});

Instead of forcing developers to build custom pagination or infinite loading logic, the component handles the heavy lifting while your backend simply returns the requested records.

For applications that need more advanced server-side data-management capabilities, React DataGrid also offers a separate Server-Side Row Model as part of its Enterprise features.

Enterprise Features for Advanced Workflows

React DataGrid also offers an Enterprise edition for teams that need capabilities beyond the open-source core.

The Enterprise tier adds a collection of advanced features designed for more sophisticated data workflows, including server-side data management, transactional editing, controlled access, auditability, data import and export, and advanced record management.

Some of the Enterprise features include:

Server-Side Row Model for applications that need more advanced server-side data management and block-based data fetching for large datasets.
Master/Detail for expanding records and displaying related or nested information.
Formula Engine for Excel-style formulas directly inside grid cells.
Undo/Redo for multi-step reversible edits.
Range Selection for selecting Excel-style cell ranges.
Clipboard (TSV) for copying and pasting tabular data with spreadsheet-style workflows.
Fill Handle for dragging to fill or copy cell values across a range.
Transactions for staged add, update, and remove operations.
Cell Permissions for controlling per-cell editing and data visibility.
Audit Trail for maintaining an immutable record of edits.
Row Locking for collaborative workflows where specific rows need to be locked.
Excel/CSV Import for mapping, validating, and coercing imported data.
PDF Export for generating branded, paginated documents from grid data.
Filter Presets with an AND/OR filter builder and reusable filtering configurations.
Saved Views for storing personal or shared grid layouts.
Form Editor for editing records through a dedicated slide-in form interface.

These features are particularly useful when a data grid starts acting as an interactive workspace for business operations.

For example, a financial application might use the Formula Engine and Range Selection for spreadsheet-like workflows, while a business application with stricter data controls could combine Transactions, Cell Permissions, Audit Trail, and Row Locking to provide more controlled data management.

The Enterprise edition therefore gives teams a path to move from a capable open-source data grid to a more advanced commercial data-management experience without having to replace the underlying grid technology.

The open-source core also includes several features that make day-to-day development easier, such as computed value getters, custom formatters, flexible column sizing, conditional cell styling, shared default column definitions, built-in tooltips, loading overlays, and "no rows" states.

Taken together, the open-source core and Enterprise edition give React DataGrid a broader range of capabilities while allowing teams to choose the level of functionality that matches their requirements.

Accessibility and Enterprise Compliance

Accessibility is an area where many open-source UI libraries still fall short. Keyboard navigation may be partially implemented, screen readers may receive limited support, and formal accessibility documentation is often missing altogether.

React DataGrid stands out by treating accessibility as a core feature, not just an afterthought.

The grid is WCAG 2.1 AA compliant and includes full keyboard navigation, ARIA support, and screen-reader compatibility. It also publishes a VPAT 2.4 accessibility report along with Section 508 documentation, making it much easier for organizations with accessibility requirements to evaluate React DataGrid before adopting it.

While individual developers certainly benefit from accessible components, this kind of documentation becomes more valuable in larger companies where procurement, legal, or compliance teams often review third-party dependencies before they're approved for production use.

Theming, Customization, and Developer Experience

A data grid rarely exists in isolation. It needs to blend naturally into the rest of your application's design system, support custom business logic, and remain flexible as requirements evolve.

React DataGrid provides 10 built-in themes, covering both light and dark interfaces, including Quartz, Alpine, Material, Nord, Dracula, Solarized (Light and Dark), Monokai, One Dark, and a standard Dark theme.

Theme switching is powered by CSS variables, making it easy to match the rest of your application without extensive styling work. Themes can be switched instantly while preserving consistent spacing, typography, and component styling.

React DataGrid theme system

Customization goes well beyond colors. The library also provides:

A custom cell renderer framework for badges, progress bars, images, buttons, charts, and icons.
A right-click context menu with actions like copy, export, pin/unpin, auto-size, hide columns, and filter by value.
Layout persistence using localStorage, server storage, or user profile storage.
Multiple density modes ranging from Ultra Compact to Comfortable.
Value getters and formatters for computed columns.
Conditional styling through cellStyle, cellClass, and cellClassRules.
Shared column configuration with defaultColDef and built-in default sorting.
Tooltips, loading overlays, and no-data overlays.
Declarative column visibility for showing or hiding columns based on user roles or application state.

Beyond the getting-started guides, the project includes a documented Grid API with more than 100 methods, along with interactive examples demonstrating how those APIs work. Enterprise capabilities build on this foundation with additional functionality for advanced data workflows.

How React DataGrid Compares to AG Grid

AG Grid Community is a solid open-source grid, but many of its most powerful capabilities, including row grouping, server-side data handling, pivoting, and several advanced data operations, are reserved for the commercial Enterprise edition.

React DataGrid takes a different approach by making many of those enterprise-style features available under the MIT license.

Here's a side-by-side comparison:

Feature	AG Grid Community	AG Grid Enterprise ($$)	React DataGrid Free	React DataGrid Enterprise ($$)
License	MIT	Commercial	MIT	Commercial
Virtual Scrolling	✅	✅	✅	✅
Tree Data	❌	✅	✅	✅
Row Grouping	❌	✅	✅	✅
Server-Side Infinite Scroll	❌	✅	✅ (100M+ rows)	✅
Server-Side Row Model	❌	✅	❌	✅
Aggregation Footers	❌	✅	✅	✅
Context Menus	❌	✅	✅	✅
Advanced Filtering	Basic	✅	✅	✅
Faceted Search / Token Search	❌	✅	✅	✅
Row Pinning	❌	✅	✅	✅
Master/Detail Rows	❌	✅	❌	✅
Pivot Table	❌	✅	✅	✅
Integrated Charts	❌	✅	✅	✅
Advanced Cell Editors	❌	✅	✅	✅
Excel Export	❌	✅	❌	✅
Formula Engine	❌	❌	❌	✅
Undo / Redo	❌	❌	❌	✅
Range Selection	❌	❌	❌	✅
Clipboard (TSV)	❌	❌	❌	✅
Fill Handle	❌	❌	❌	✅
Transactions	❌	❌	❌	✅
Cell Permissions	❌	❌	❌	✅
Audit Trail	❌	❌	❌	✅
Row Locking	❌	❌	❌	✅
Excel / CSV Import	❌	❌	❌	✅
PDF Export	❌	❌	❌	✅
Filter Presets	❌	❌	❌	✅
Saved Views	❌	❌	❌	✅
Form Editor	❌	❌	❌	✅
Accessibility (WCAG 2.1 AA + VPAT)	Partial	✅	✅	✅
Built-in Themes	1	Multiple	10	10

This doesn't necessarily mean React DataGrid should replace AG Grid in every project. AG Grid remains one of the most mature data grid solutions available and comes with commercial support for organizations that require enterprise SLAs.

However, if your team needs a capable open-source React data grid with features such as grouping, aggregation, virtualization, theming, and rich customization, React DataGrid's MIT-licensed core presents a compelling option.

When requirements expand to advanced workflows, auditing, permissions, transactions, or spreadsheet-style operations, the Enterprise edition provides an upgrade path without requiring you to switch to a different grid component.

Who Should Use React DataGrid?

React DataGrid isn't trying to be the right data grid for every React project, and that's actually one of its strengths.

I think it's well suited for:

Internal business dashboards
Admin panels
SaaS applications
CRM and ERP systems
Financial dashboards
Analytics platforms
Inventory management systems
Applications that need grouping, aggregation, virtualization, rich customization, or Server-Side Infinite Scroll for large datasets without paying for a commercial grid
Enterprise applications that may need advanced capabilities

If your application starts with a few hundred rows today but could eventually grow into tens of thousands, or even millions, of records, it's nice to know you won't need to replace your grid component later just because your data has outgrown it.

📌 If you find this useful, consider starring the GitHub repo; it helps support the open-source project and its continued development.

⭐ Star React DataGrid on GitHub

Final Thoughts

What stands out about React DataGrid isn't a single headline feature; it's the combination of an open-source core and an optional Enterprise edition that can grow with an application's requirements.

The MIT-licensed core provides developers with a capable React data grid for everyday data management, including sorting, filtering, grouping, aggregation, virtualization, theming, customization, and accessibility.

For teams that need more advanced workflows, the Enterprise edition adds capabilities such as Server-Side Row Model, Master/Detail, Formula Engine, Transactions, Cell Permissions, Audit Trail, Row Locking, Excel/CSV Import, PDF Export, Filter Presets, Saved Views, and Form Editor.

That gives teams a straightforward choice:

Start with the free, open-source grid for projects that don't need commercial features
Move to the Enterprise edition when more advanced data operations and workflows become necessary.

This article focused on what React DataGrid offers and how its free and Enterprise capabilities compare. In my next article, I'll take a different approach by building a real React project with it, sharing the complete development experience, highlighting what worked well, and discussing any challenges I encounter along the way. Stay tuned!

Thanks for reading! 🙏🏻 I hope you found this useful ✅ Please react and follow for more 😍 Made with 💙 by Hadil Ben Abdallah

Hadil Ben AbdallahFollow

Software Engineer • Technical Writer (300K+ readers & 25K+ followers) • Trusted by 20+ startups and tech companies worldwide I turn brands into websites people 💙 to use

AI Agents for Marketing in 2026: 8 Platforms Replacing Manual Marketing Ops

Hadil Ben Abdallah — Wed, 05 Aug 2026 09:02:32 +0000

According to HubSpot's 2026 State of Marketing Report, 61% of marketers believe AI is creating the biggest disruption marketing has experienced in the last 20 years, while 80% of marketers are already using AI for content creation and 75% are using it for media production. The shift is all about how effectively marketing teams can turn AI from a productivity assistant into an autonomous execution layer.

That shift explains why AI agents for marketing (also called autonomous marketing platforms) have become one of the fastest-growing categories in marketing technology.

Unlike AI assistants that simply generate blog posts, suggest campaign ideas, or summarize performance reports, AI marketing agents are designed to monitor real-time signals, make decisions, execute workflows, optimize campaigns, and continuously adapt based on outcomes.

For growth teams trying to increase output without constantly expanding their operations team, this represents a fundamental change.

In this guide, we'll look at the eight best AI agents for marketing in 2026, compare where each platform fits, examine their limitations, and explore which solutions can replace parts of the manual marketing operations workload.

Quick Comparison: Best AI Agents for Marketing in 2026

Before diving into each platform, here's a side-by-side comparison of the leading AI marketing agents and autonomous marketing platforms available today.

Platform	Category	Best For	Pricing	Key Limitation
Jasper AI	AI content generation	Scaling blogs, ads, email campaigns, and brand-consistent content	Paid	Generates content but doesn't execute campaigns or react to marketing signals
Hellyeah	AI-powered marketing platform	Teams wanting autonomous paid media operations and AI-powered marketing workflows	Enterprise	Requires onboarding, event instrumentation, and setup before delivering value
Smartly.io	Paid social automation	Large paid social teams managing Meta and TikTok campaigns	Paid / Enterprise	Focused on paid social only
HubSpot AI	CRM + AI marketing suite	SMBs wanting CRM, email marketing, and AI assistance in one platform	Free / Paid / Enterprise	AI assists users instead of operating autonomously
Persado	AI messaging optimization	Enterprise email and advertising teams	Enterprise	Focuses only on copy optimization
Clay	AI outbound personalization	B2B sales and outbound marketing	Paid	Outbound-focused rather than full marketing operations
Anyword	AI writing + predictive scoring	Teams optimizing marketing copy before publishing	Free / Paid	Requires humans to approve and publish content
n8n	Workflow automation + AI agents	Engineering-led organizations building custom AI workflows	Free / Paid	Requires technical resources to build and maintain

Although every platform on this list uses AI, they don't solve the same problem.

Understanding the differences between them is important because the right choice depends far more on what part of your marketing operation you want to automate than on which platform has the most AI features.

What "Replacing Manual Marketing Ops" Means

When people hear that AI agents are replacing marketing operations, it's easy to assume the goal is to replace marketers themselves. In reality, that's not what these platforms are designed to do.

Marketing teams still need people to:

define positioning
understand customers
shape brand strategy
approve messaging
make business decisions

Those responsibilities depend on creativity, judgment, and market knowledge that AI cannot replace.

What AI increasingly takes over is everything that happens after those strategic decisions have already been made. Once a campaign has been planned, someone still needs to launch it, build audience segments, monitor bids, rotate creatives, prepare reports, analyze experiments, watch for churn signals, schedule lifecycle campaigns, and research prospects before outbound outreach begins.

Individually, none of those activities are especially difficult. Together, however, they consume a significant portion of a marketing team's week, leaving less time for strategy and growth initiatives. AI marketing agents are designed to automate that execution layer so marketers spend less time operating systems and more time making decisions that actually move the business forward.

Instead of requiring someone to manually monitor dashboards throughout the day, these platforms continuously observe performance signals, decide what action makes sense based on current conditions, execute that action automatically, and evaluate the results before making future decisions.

That creates three broad categories of AI marketing platforms.

Category	What It Does	Examples
Single-function AI agents	Automate one marketing operation exceptionally well	Jasper AI, Clay, Persado, Anyword
Multi-function marketing platforms	Combine several connected marketing capabilities into one platform	HubSpot AI, Smartly.io
Full-stack agentic marketing platforms	Coordinate AI-powered marketing workflows and paid media operations from a unified platform	Hellyeah

The distinction matters because many products now advertise themselves as AI-powered, even though they still function primarily as assistants that help marketers work faster.

True AI marketing agents go much further by operating independently once objectives, constraints, and data are in place, allowing teams to automate entire operational workflows.

1. Jasper AI

One of the biggest challenges marketing teams faced when generative AI became mainstream wasn't simply creating content; it was producing large volumes of content without losing consistency across different writers, campaigns, and channels.

That's the problem Jasper AI is built to solve.

Jasper allows organizations to train a Brand Voice using their existing content. Once that foundation is established, the platform can generate blog posts, landing pages, email campaigns, advertising copy, product descriptions, and social media content that closely matches the company's writing style.

Its Campaigns feature also helps teams create multiple marketing assets from a single campaign brief, making it much easier to produce coordinated content for different channels without starting from scratch each time. For organizations publishing at scale, that significantly reduces production time while maintaining a consistent brand voice across the entire marketing team.

Best for

Marketing teams, content marketers, and demand generation teams producing large volumes of written marketing content across multiple channels.

Limitation

Jasper excels at generating content, but it doesn't operate your marketing stack. It won't manage advertising campaigns, monitor customer behavior, optimize budgets, trigger lifecycle campaigns, or react to performance signals automatically.

Pricing

Paid.

2. Hellyeah

Many companies don't struggle because they're missing marketing tools; they struggle because every marketing function lives inside a different one. Paid advertising, content operations, analytics, and reporting often run across separate platforms, leaving someone on the team responsible for connecting everything, interpreting the data, and managing the day-to-day execution that keeps campaigns running.

Unlike traditional marketing platforms that gradually added AI features over time, Hellyeah AI is an AI-native growth engine designed to reduce marketing operations overhead. Rather than simply helping marketers complete individual tasks faster, it automates repetitive marketing execution so teams can spend less time managing campaigns and more time focusing on strategy, creativity, and growth.

Today, Hellyeah centers on two core products. AIMA continuously optimizes paid media by monitoring performance, adjusting bids, reallocating budgets, and responding to conversion signals, while CLI provides an AI-powered interface for interacting with marketing workflows and operational data more efficiently. Together, they help reduce repetitive marketing work while keeping marketers in control of business decisions.

AIMA: Replacing Daily Paid Media Operations

Managing paid advertising requires constant optimization. Budgets need to be reallocated, bids adjusted, creatives refreshed, and audience performance monitored as campaign data changes throughout the day. For growing marketing teams, keeping up with those decisions manually can quickly become a full-time job.

AIMA automates that optimization layer by continuously monitoring campaign performance, interpreting conversion signals, adjusting bidding strategies, reallocating budgets, and helping teams respond to changing campaign performance. Marketing teams remain responsible for campaign strategy and business goals, while AIMA handles much of the repetitive execution required to keep campaigns performing efficiently.

CLI: AI-Powered Marketing Operations

Hellyeah's CLI provides an AI-first interface for interacting with marketing workflows, making it easier to execute operational tasks without navigating multiple dashboards or manually coordinating different systems. Instead of relying solely on traditional interfaces, teams can use AI to access marketing capabilities more efficiently and streamline day-to-day operations.

Combined with AIMA, the CLI helps reduce the operational overhead of running modern marketing by making routine execution faster and more accessible, while marketers continue focusing on strategy, messaging, and business decisions.

Best For

Growth-stage SaaS companies, enterprise B2B organizations, e-commerce businesses, fintech companies, gaming companies, mobile apps, and education platforms that want to reduce marketing operations overhead through AI-powered paid media optimization and modern AI-driven marketing workflows.

Limitation

Hellyeah is not a plug-and-play platform that delivers full autonomous execution on the first day.

Like any serious agentic marketing system, it requires clean event instrumentation, clearly defined business objectives, and an onboarding period so the platform can understand your business objectives, campaign structure, and operational workflows. Teams willing to invest in that foundation gain a platform that becomes more effective as more operational data becomes available over time, but organizations expecting immediate results without preparation may find the initial setup more involved than simpler marketing tools.

Pricing

Enterprise.

3. Smartly.io

Managing paid social campaigns at an enterprise scale involves much more than launching advertisements. Marketing teams constantly monitor campaign performance, adjust bids, test audiences, rotate creative assets, optimize budgets, and compare results across multiple advertising platforms. As campaign volume grows, those operational responsibilities quickly become too time-consuming for manual management alone.

Smartly.io helps automate much of that workload by combining creative production, campaign management, audience testing, bid optimization, and performance analysis inside a single platform. Its AI capabilities identify high-performing creative combinations, optimize campaign delivery across channels such as Meta and TikTok, and automatically allocate additional budget toward stronger-performing campaigns as new performance data becomes available.

The platform generates copy for landing pages, paid advertisements, emails, product descriptions, social media posts, and other marketing assets while assigning predictive performance scores to every variation. Those predictions are based on historical marketing data, giving teams another layer of confidence when comparing headlines, calls to action, subject lines, and advertising copy before launching a campaign.

While those scores don't replace real-world testing, they can help marketers prioritize stronger candidates earlier in the content creation process and reduce the number of weak variations that ever reach production.

Best for

Marketing teams producing high volumes of advertising, website, email, and social media copy that want performance insights before publishing.

Limitation

Anyword remains an AI-assisted writing platform rather than an autonomous marketing system. Human marketers still decide which content to approve, edit, publish, and distribute, and the platform doesn't execute campaigns or optimize marketing operations after the content has been created.

Pricing

Free / Paid.

8. n8n + AI Nodes

Not every company wants an opinionated marketing platform with predefined workflows. Many engineering-led organizations prefer building their own automation infrastructure so it integrates perfectly with existing internal systems, data sources, and business logic.

That's where n8n stands out.

As an open-source workflow automation platform, n8n connects hundreds of services through visual workflows while allowing developers to incorporate LLM-powered AI nodes into decision-making processes. Teams can build custom AI-powered workflows for campaign approvals, lead routing, CRM synchronization, reporting, content production pipelines, customer notifications, and countless other marketing operations.

Because the platform is self-hostable and highly customizable, organizations retain full ownership over their automation stack instead of relying entirely on a managed SaaS platform. That flexibility makes n8n especially attractive for companies with strong engineering teams and complex internal requirements.

Best for

Engineering-led organizations that want to design, build, and maintain highly customized AI-powered marketing workflows using their own infrastructure.

Limitation

The flexibility that makes n8n so powerful also makes it more demanding to implement. Building, maintaining, debugging, and continuously improving AI workflows requires dedicated engineering resources, making it less suitable for marketing teams looking for a ready-to-deploy autonomous marketing platform.

Pricing

Free / Paid.

How to Evaluate an AI Marketing Agent Platform

Not every platform marketed as an AI marketing solution is really an AI agent.

Many products still function as AI assistants that generate recommendations while leaving marketers responsible for execution. True AI agents go much further by observing real-time signals, making decisions, carrying out those decisions, and continuously improving based on the outcomes they observe.

If you're evaluating an AI agent for marketing, these are the questions that matter most.

Evaluation Criterion	What to Ask	Red Flag
Autonomy	Does the platform make decisions autonomously or simply recommend actions?	It only suggests optimizations that humans must review and approve.
Coverage	Does it automate one marketing function or multiple connected operations?	It automates a single workflow while claiming to replace an entire marketing team.
Real-Time Signals	Does it continuously monitor product, CRM, behavioral, and advertising data?	It relies on scheduled imports, CSV uploads, or delayed reporting.
Learning Loop	Does the system improve future decisions based on previous outcomes?	Performance improves only when humans manually update rules or workflows.
Setup Requirements	What onboarding, instrumentation, and data preparation are required before deployment?	It promises complete autonomous marketing within minutes and without preparation.

When campaign performance, customer behavior, experimentation results, and workflow execution all inform one another, improvements don't remain isolated inside individual tools. Instead, every successful outcome strengthens future decisions across the entire marketing operation, creating a compounding effect that's difficult to achieve with disconnected software.

Frequently Asked Questions

What are AI agents for marketing?

→ AI agents for marketing (also called autonomous marketing platforms) are AI systems that continuously monitor marketing signals, make decisions, execute campaigns, and learn from the outcomes without requiring marketers to initiate every action manually. Unlike traditional automation platforms that follow predefined rules, AI agents adapt their behavior as new data becomes available.

Can AI agents replace a marketing team?

→ Not entirely.

AI agents are designed to replace much of the marketing execution layer, including campaign optimization, reporting, audience management, experimentation, lifecycle automation, and many repetitive operational tasks. Human marketers remain responsible for strategy, positioning, creative direction, customer research, brand management, and the business decisions that require judgment, context, and creativity.

What's the difference between marketing automation and AI marketing agents?

→ Traditional marketing automation executes workflows that humans configure in advance using predefined rules.

AI marketing agents continuously evaluate current conditions, decide which action is most appropriate, execute that action automatically, and refine future decisions based on the results they observe. In other words, automation follows instructions, while AI agents determine what the next instruction should be.

Which AI marketing platform is best in 2026?

→ The answer depends on the part of marketing you're trying to automate.

If your priority is AI-assisted content generation, Jasper AI and Anyword are good choices. Clay is a strong option for outbound personalization, while Smartly.io remains one of the leading platforms for paid social automation.

If you're looking for a purpose-built platform that brings paid acquisition, lifecycle marketing, continuous experimentation, and custom workflows together into one connected autonomous system, Hellyeah is the strongest fit because it was designed specifically to automate the broader marketing operations layer rather than a single function.

Final Thoughts

Marketing teams aren't adopting AI agents simply because they want to work faster.

They're adopting them because modern marketing operations have become too complex for people to monitor every campaign, workflow, customer signal, and experiment manually throughout the day.

The biggest shift isn't that AI writes content or recommends optimizations. It's that an increasing share of the operational work, monitoring campaigns, adjusting budgets, reacting to customer behavior, coordinating workflows, and continuously testing new ideas, can now happen autonomously while marketers focus on higher-value decisions.

The right platform ultimately depends on what you're trying to automate. Some teams need better content creation, others need smarter outbound prospecting or paid media optimization, while larger organizations may benefit from platforms that automate broader marketing operations.

Understanding those differences will help you choose a solution that fits your workflow instead of adding another disconnected AI tool to your stack.

Thanks for reading! 🙏🏻 Please follow Hadil Ben Abdallah & Hellyeah for more 🧡

Hellyeah Follow

Hellyeah is an autonomous AI growth platform that runs and optimizes marketing operations in real time. It helps companies scale faster by turning their entire growth engine into a continuously learning, always-on system.

Hadil Ben AbdallahFollow

Software Engineer • Technical Writer (300K+ readers & 25K+ followers) • Trusted by 20+ startups and tech companies worldwide I turn brands into websites people 💙 to use