DEV Community: Hadil Ben Abdallah

I Removed Passwords From My App. Here’s What the Login Flow Looks Like Now

Hadil Ben Abdallah — Wed, 14 Oct 2026 13:13:55 +0000

Most applications eventually face login problems that have little to do with their core purpose.

Users forget passwords, reuse credentials, and struggle with account recovery. Meanwhile, developers must consider credential security, brute-force protection, and session management.

This is the reason why I started looking into passwordless authentication and how passkeys can potentially alter the login experience.

The idea is simple: users should be able to prove their identity without typing a conventional password every time they sign in.

Passkeys use public-key cryptography through standards such as WebAuthn. Users authenticate with a compatible device or security key, while the identity provider verifies the authentication and completes the login flow.

I was curious to find out what implications it has for developers: how the login procedure would change, what configuration the developers have to do, and which responsibilities remain with the app.

To answer these questions, I will explore the technology of passkey authentication and review Skycloak's managed Keycloak solution.

TL;DR

Passwordless authentication enables users to log in to their accounts without typing in a traditional password. With passkeys, the browser and the user's authenticator handle a cryptographic challenge, and the identity provider verifies the result.

Here are the important points for developers:

The traditional password step is replaced with passkeys. When users authenticate using the passkey, they must use a suitable device or security key.
WebAuthn enables public-key authentication. The authenticator uses a private key to respond to a challenge, and the identity provider verifies the response using the registered public key.
Identity providers manage authentication. Keycloak supports passkeys, while Skycloak offers a managed Keycloak solution with a passkey setup provided.
As usual, recovery must be taken care of. One must not forget that the users could end up losing their devices or switching browsers and want to register a passkey.
Passwordless doesn't automatically mean MFA. Whether additional authentication factors are required depends on the configured authentication policy. A passkey can also satisfy multiple authentication-factor requirements in supported flows.

The main benefit is a simpler sign-in experience with strong phishing resistance when passkeys are correctly implemented. The trade-off is that developers still need to manage registration, recovery, device compatibility, and session security carefully.

Passwords Were Only the Beginning of the Problem

A login form looks simple from the outside. A user enters their credentials, the server verifies them, and the application starts a session. The complexity appears when something goes wrong.

Users forget passwords, attackers try leaked credentials, and account recovery can become a security weakness if it's poorly designed.

Developers must also protect stored passwords, limit repeated login attempts, and make sure reset links can't be abused.

For a growing application, these responsibilities add ongoing security work that competes with other product priorities.

This is where passwordless authentication becomes useful. Passkeys remove the need to remember and type a reusable password, reducing exposure to common password-related attacks.

They don't eliminate every authentication risk, though. Account recovery, session security, authorization, and fallback methods still need careful design. The goal is to simplify sign-in without compromising the security of the application.

How Passwordless Authentication Works

Passwordless authentication describes a login experience that doesn't require the user to enter a conventional password. There are several ways to achieve this, but passkeys are a useful starting point because they combine a straightforward user experience with public-key cryptography.

Passkeys: Prove Your Identity Without Typing a Password

When a user registers a passkey, their authenticator creates a public/private key pair. The private key is protected by the authenticator or passkey provider, while the identity provider stores the corresponding public-key credential.

During sign-in, the identity provider sends a challenge. The authenticator responds using the private key, and the identity provider verifies the response. If authentication succeeds, the user can continue into the application.

The browser handles this interaction through WebAuthn, a web standard for public-key authentication.

Depending on the device, users may confirm their identity with Face ID, Touch ID, Windows Hello, a device PIN, or a compatible security key. Their biometric data isn't sent to the application as part of the WebAuthn exchange.

                   ┌──────────────────────────────┐
                   │       Sign in / Register     │
                   │                              │
                   │  Enter username or email     │
                   │  Choose Register             │
                   └──────────────┬───────────────┘
                                  │
                                  ▼
                   ┌──────────────────────────────┐
                   │          Register            │
                   │                              │
                   │  Username: hadil             │
                   │  Email: hadil@example.com    │
                   │                              │
                   │       [ Register ]           │
                   └──────────────┬───────────────┘
                                  │
                                  ▼
                   ┌──────────────────────────────┐
                   │      Choose Setup Method     │
                   │                              │
                   │      [ Setup Password ]      │
                   │             OR               │
                   │      [ Setup Passkey ]       │
                   └──────────────┬───────────────┘
                                  │
                 ┌────────────────┴────────────────┐
                 │                                 │
                 ▼                                 ▼
    ┌────────────────────────┐       ┌────────────────────────┐
    │     Setup Password     │       │      Setup Passkey     │
    └────────────┬───────────┘       └────────────┬───────────┘
                 │                                 │
                 ▼                                 ▼
    ┌────────────────────────┐       ┌────────────────────────┐
    │ Enter a new password   │       │ Register a passkey     │
    │ Confirm the password   │       │ with your device       │
    │                        │       │                        │
    │     [ Register ]       │       │     [ Continue ]       │
    └────────────┬───────────┘       └────────────┬───────────┘
                 │                                 │
                 │                                 ▼
                 │                    ┌────────────────────────┐
                 │                    │  Choose authenticator  │
                 │                    │                        │
                 │                    │  • Windows Hello       │
                 │                    │  • Touch ID / Face ID  │
                 │                    │  • Security key        │
                 │                    └────────────┬───────────┘
                 │                                 │
                 │                                 ▼
                 │                    ┌────────────────────────┐
                 │                    │ Confirm registration   │
                 │                    │ with device PIN,       │
                 │                    │ fingerprint or face    │
                 │                    └────────────┬───────────┘
                 │                                 │
                 └────────────────┬────────────────┘
                                  │
                                  ▼
                   ┌──────────────────────────────┐
                   │    Registration Complete     │
                   │                              │
                   │  User can sign in using the  │
                   │  configured authentication   │
                   │  method.                     │
                   └──────────────────────────────┘

This is a conceptual registration flow. The available authentication methods and registration steps depend on the application's identity provider and configured authentication flow.

For developers, passkeys still require configuration: users need a way to register credentials, the identity provider must accept them, and the application must establish a secure session after authentication.

Magic Links: A Different Way to Skip Passwords

Magic links offer another passwordless approach. The user enters an email address, receives a login link, and follows it to authenticate. The link typically contains a time-limited or one-time token that must be validated securely.

This can make onboarding straightforward because users don't have to create or remember a password. However, the experience depends on email delivery and on the security of the user's email account. Developers must also protect against token reuse, link leakage, and unsafe redirect handling.

Where Does Keycloak Fit Into the Flow?

Keycloak can manage authentication, user credentials, and the login flows that applications use through standard identity protocols. With passwordless authentication configured, it can verify a registered passkey and complete the authentication flow for the application.

              ┌─────────────────────────────┐
              │            User             │
              │                             │
              │      Clicks "Sign in"       │
              └──────────────┬──────────────┘
                             │
                             ▼
              ┌─────────────────────────────┐
              │       Web Application       │
              │                             │
              │  React / Next.js / other    │
              │  application                │
              └──────────────┬──────────────┘
                             │
                             │ Redirects for login
                             ▼
              ┌─────────────────────────────┐
              │          Keycloak           │
              │                             │
              │  Identity and authentication│
              │  Handles the configured     │
              │  login flow                 │
              └──────────────┬──────────────┘
                             │
                 ┌───────────┴───────────┐
                 │                       │
                 ▼                       ▼
       ┌───────────────────┐   ┌───────────────────┐
       │ Password          │   │ Passkey           │
       │ authentication    │   │ authentication    │
       │                   │   │                   │
       │ Enter credentials │   │ Use device        │
       │                   │   │ authenticator     │
       └─────────┬─────────┘   └─────────┬─────────┘
                 │                       │
                 └───────────┬───────────┘
                             │
                             ▼
             ┌───────────────────────────────┐
             │   Keycloak Verifies Login     │
             │                               │
             │ Applies configured policies   │
             │ and completes authentication  │
             └───────────────┬───────────────┘
                             │
                             ▼
              ┌─────────────────────────────┐
              │       OIDC Response         │
              │                             │
              │  Application receives the   │
              │  authorization code and     │
              │  completes the OIDC flow    │
              └──────────────┬──────────────┘
                             │
                             ▼
              ┌─────────────────────────────┐
              │       Web Application       │
              │                             │
              │  Establishes its session    │
              │  and checks authorization   │
              └──────────────┬──────────────┘
                             │
                             ▼
              ┌─────────────────────────────┐
              │     Protected Resource      │
              │                             │
              │       Access granted        │
              └─────────────────────────────┘

Developers can use an identity provider to manage the authentication process without having to build every part of credential registration and verification themselves. The application still needs to integrate correctly with the identity provider and handle its own authenticated sessions and authorization.

Passkeys vs. Passwords vs. MFA: What Changes?

These terms often appear together in authentication discussions, but they describe different things. Understanding the distinction helps you choose the right login flow for your application.

Approach	What the user does	What it provides
Password-based login	Enters a username and password	Authentication using a memorized secret
Passwordless passkey login	Uses a registered passkey, often with a device unlock or security key	Authentication using public-key cryptography without entering a password
Multi-factor authentication (MFA)	Completes multiple authentication factors according to the configured policy	An additional layer of account protection

A passkey can replace a password as the primary authentication method, while MFA requires multiple authentication factors according to the configured policy. The two can also work together: passkeys can support passwordless login or be incorporated into a multi-factor flow.

Passkeys offer strong phishing resistance because WebAuthn credentials are associated with the website's identity. A credential registered for one website can't simply be reused on an unrelated fake domain.

For developers, the right approach depends on the application's security requirements, its users' devices, and the available account recovery options.

Where Skycloak Comes In

Skycloak provides managed Keycloak, allowing developers to use Keycloak's identity and authentication capabilities without managing the underlying identity infrastructure themselves.

It includes a passkey configuration recipe for enabling passwordless registration and creating a dedicated browser-passkey authentication flow. The documented setup also describes a password-based fallback for users who haven't registered a passkey.

This configuration provides a starting point for exploring passkey authentication with Keycloak.

Using Skycloak for Passwordless Authentication With Passkeys

Passkeys change how users authenticate, but an application still needs an identity provider to manage registration, verify authentication, and handle the login flow. Skycloak provides managed Keycloak and a preconfigured Passkeys recipe that helps developers set up this flow without building a custom WebAuthn authenticator.

What the Skycloak Passkeys Recipe Configures

Skycloak's Passkeys recipe applies a passkey configuration to a selected Keycloak realm. It handles three main parts of the setup:

Passkey registration: Enables the webauthn-register-passwordless required action so users can register a passkey.
A dedicated authentication flow: Creates a browser-passkey flow that identifies the user first and then prompts them to authenticate with a passkey.
Fallback authentication: Keeps password authentication and conditional OTP available for users who haven't registered a passkey, according to the configured flow.

The recipe leaves the existing browser flow untouched. It also provides an option to require passkey registration for existing users, so developers can choose when to enforce the change across a realm.

Skycloak's Recipes section includes a Passkeys configuration that can be applied to a selected realm

Prepare Your Development Environment

Start with a dedicated realm for your test application. Keeping the setup separate makes it easier to configure the authentication flow and test registration and sign-in without affecting other applications or users.

I created my first-app realm in the Skycloak dashboard

You'll need the following:

Identity provider: A Skycloak-managed Keycloak environment with a development realm.
Application: A small React or Next.js application with an OpenID Connect (OIDC) integration.
Browser and authenticator: A WebAuthn-compatible browser and a supported authenticator, such as Windows Hello, Touch ID, or a security key.
Test account: A dedicated user account for trying passkey registration and sign-in.

Connect the Application Through OIDC

The application needs an OIDC client in Keycloak so it can redirect users to the identity provider for authentication and receive the appropriate authentication response.

Creating an OpenID Connect client in Keycloak is an early step in connecting the application to its identity provider

Configure the client's redirect URIs and other settings to match your application. Skycloak's first application setup guide provides guidance for creating the client.

Your application will also need the relevant issuer URL and client ID for its OIDC integration. Keep client secrets out of browser-side code, and use HTTPS in production.

Configure and Test Passkey Authentication

With the realm and OIDC client in place, follow Skycloak's Passkey configuration guide to apply the recipe and understand the resulting authentication flow.

Work through these steps:

1. Apply the Passkeys recipe.

Select your development realm and follow the documented instructions to enable passkey registration and create the browser-passkey flow.

2. Connect your application.

Configure the application's OIDC integration with the correct issuer URL, client ID, and redirect URI. The application should use the identity provider's authentication flow and handle the OIDC response according to its integration.

3. Register a passkey.

Sign in with your test account and follow the configured registration flow. The exact screens depend on the realm's configuration and the user's authentication state.

4. Test the sign-in flow.

Try signing in with the registered passkey using a compatible browser and authenticator. Also check the configured fallback for users who haven't registered a passkey.

5. Check recovery and failure scenarios.

Test what happens when a user cancels the browser prompt, has no registered passkey, or loses access to their authenticator. Confirm that the available fallback and recovery options work as intended.

What Developers Still Need to Handle

The recipe configures the identity-provider side of passkey authentication, but it doesn't remove the application's integration responsibilities. Developers still need to handle OIDC correctly, establish and protect application sessions, enforce authorization, and configure redirect URIs securely.

Before using the flow in production, test it across the browsers and devices your users rely on, and decide whether passkey registration should remain optional or become a requirement for the realm.

Edge Cases to Test Before Shipping

A passkey login that works once isn't enough for production. Developers need to consider recovery, device compatibility, and authentication failures before making passwordless authentication the default.

Account recovery is a priority. Users may lose a device or lose access to their authenticator. Provide a secure recovery process that helps legitimate users regain access without creating an easy route for attackers.

Test different browsers, operating systems, and authenticators relevant to your audience. Also check what happens when users cancel the passkey prompt, haven't registered a passkey, or try to access a protected page without an authenticated session.

Finally, remember that passkeys don't replace authorization checks, secure session handling, or session expiration policies. Authentication verifies a user's identity; the application still determines what they can access.

Before shipping, use this checklist:

[ ] New users can register a passkey successfully.
[ ] Returning users can sign in with a registered passkey.
[ ] Users have a documented, secure account recovery process.
[ ] Unsupported or cancelled authentication attempts are handled gracefully.
[ ] Unauthenticated users cannot access protected pages.
[ ] Redirect URLs, sessions, and identity-provider settings are configured securely.
[ ] Relevant browser and device combinations have been tested.

Frequently Asked Questions

What is passwordless authentication?

→ Passwordless authentication allows users to sign in without entering a conventional password. It can use passkeys, security keys, magic links, or other password-free methods. Passkeys use public-key cryptography and can provide phishing-resistant authentication when correctly implemented.

How do passkeys work without a password?

→ A passkey uses a public/private key pair associated with the relying party. During authentication, the authenticator uses the private key to respond to a challenge, and the identity provider verifies the response with the registered public key. The user doesn't need to enter a conventional password.

Are passkeys the same as MFA?

→ No. Passwordless authentication describes how a user signs in without a conventional password. MFA requires multiple authentication factors according to the configured policy. A passkey can be used for passwordless login or incorporated into a multi-factor authentication flow.

What happens if a user loses their passkey?

→ The user needs a supported recovery path, such as another registered passkey or a secure account recovery process. The appropriate approach depends on the application's identity configuration. Developers should plan recovery before making passkeys the only available authentication method.

Is passwordless authentication more secure than passwords?

→ Passkeys can offer important security advantages over passwords, including resistance to common phishing attacks and the absence of a reusable password that can be stolen and replayed. The overall security of the application still depends on account recovery, session management, authorization, and correct implementation.

Final Thoughts

Passwordless authentication can simplify sign-in and reduce reliance on conventional passwords.

Passkeys offer a phishing-resistant approach, but a production-ready implementation still needs secure registration, account recovery, device compatibility, session handling, and authorization.

Managed Keycloak can reduce the burden of operating identity infrastructure.

Skycloak's passkey configuration gives developers a starting point for exploring this approach, while OIDC connects the identity provider to the application.

The goal isn't just to remove a password field. It's to make authentication easier for users without compromising security.

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

Your Marketing Site Has 40 Scripts. Which Ones Are Actually Worth Keeping?

Hadil Ben Abdallah — Tue, 13 Oct 2026 09:09:59 +0000

Third-party scripts are easy to accumulate on a marketing website. A site might start with GA4 for analytics, a cookie banner, and a chat widget.

A year or two later, the list can look very different.

There’s a tag manager, heatmaps, session recordings, A/B testing, ad pixels, a CRM integration, a chatbot, a scheduling tool, a consent platform, embedded videos, social widgets, product analytics, and other tools.

Each one had a reason to exist.

The problem is that the browser doesn't care why you added it.

It has to download, parse, and execute that code on a real visitor's device. Some third-party scripts consume CPU, compete for network resources, delay other work, or add work to the main thread. Chrome's performance guidance specifically calls out third-party code as a significant source of page-load and JavaScript costs.

And that creates a problem that has very little to do with whether your marketing team likes a particular tool.

The question is whether the tool still earns its place on the website.

TL;DR

Keep a third-party script when it has a clear business purpose, an identifiable owner, useful data or functionality, and a cost that makes sense for the pages where it runs.

Remove it when nobody can explain why it exists, nobody uses the data it collects, another tool already does the same job, or its performance and maintenance cost are greater than its value.

A practical way to evaluate every script is to ask:

What does this script do?
Who actually uses what it provides?
Does it affect leads, conversions, analytics, customer experience, or another measurable business outcome?
Does another tool already cover the same job?
Does it need to load on every page?
What does it cost in performance, privacy, maintenance, and reliability?
Who owns it?

If you cannot answer those questions, the script deserves an audit.

Why Too Many Third-Party Scripts Become a Problem

Third-party code is common on modern marketing websites. Analytics platforms, advertising tools, chat systems, consent management, testing platforms, embedded content, and other services often depend on JavaScript loaded from an external domain.

That doesn't automatically make them bad.

A script that sends important conversion data to your analytics platform can be worth its cost. A consent-management platform may be essential for how your site handles tracking. A scheduling widget may directly support your sales process.

The problem starts when the list grows without anyone reviewing it.

A marketer adds a new tool for a campaign. A developer installs its snippet. Another team adds a heatmap tool six months later. A redesign introduces a second analytics implementation. An agency adds its own tracking script. The campaign ends, but the script stays.

Nothing looks broken.

The website still loads. The forms still work. The analytics dashboard still has numbers in it.

Meanwhile, the browser is doing more work every time someone visits the site.

Chrome's Lighthouse documentation notes that third-party scripts can significantly affect page performance, including the amount of work performed on the browser's main thread.

That matters even more on marketing websites because the third-party script list often grows through small, reasonable decisions rather than one obviously bad technical choice.

The result is script bloat.

And script bloat is difficult to spot when you look at each tool separately.

How to Find Every Third-Party Script on Your Website

Before deciding what stays and what goes, you need a complete inventory.

This sounds simple until you actually do it.

A script can be added directly to a page, injected through Google Tag Manager, loaded by a WordPress plugin, included by a Webflow integration, or introduced by another third-party tool. Looking at the page source alone may give you an incomplete picture.

For a proper audit, I would check the website from several angles.

Start with the browser

Open Chrome DevTools and go to Network.

Reload the page with the Network panel open, then filter by:

JS
Fetch/XHR
Img
Doc

The JavaScript filter is the obvious starting point, but don't stop there. A third-party tool may load JavaScript and then make additional requests through XHR or fetch.

Look at the domains making those requests.

You might find something you recognize immediately:

www.googletagmanager.com
www.google-analytics.com
connect.facebook.net
snap.licdn.com
static.hotjar.com

You may also find domains that mean nothing to you.

Those deserve investigation.

The goal at this stage isn't to decide whether a script is good or bad. You're building the inventory first.

Check your tag manager

If the site uses Google Tag Manager, open the container and review every tag.

Pay attention to:

tags that are still active
tags with unclear names
old campaign tags
duplicate analytics tags
tags firing on every page
tags that were created for a temporary campaign
tags owned by former employees or agencies

Check your CMS and plugins

If the website runs on WordPress or another CMS with integrations and plugins, check those too.

A plugin may inject tracking code without anyone adding a script manually.

This is one reason script audits should include the systems responsible for adding code, not just the code itself.

You may discover that the same service is being loaded through two different paths.

For example:

GA4 is configured directly in the CMS
another GA4 implementation exists in GTM
a plugin adds another tracking library
a custom script sends additional events

The result can be duplicate data and unnecessary browser work at the same time.

Measure the Cost of Third-Party Scripts

Once you have the inventory, measure the actual impact.

This is where Chrome DevTools and Lighthouse become useful. Core Web Vitals can also help you understand how performance issues affect the actual experience of visitors.

Lighthouse has a dedicated third-party summary that helps identify third-party resources and the amount of main-thread work associated with them.

You can also use Chrome DevTools to inspect individual requests and understand what happens when the page loads.

Look at:

request count
transferred size
resource size
loading time
JavaScript execution
main-thread activity
additional network requests
when the resource starts loading
whether it blocks or delays important work

Don't obsess over one number.

A 200 KB script isn't automatically worse than a 50 KB script. The smaller script could trigger several additional requests or perform expensive JavaScript work after it loads.

Likewise, a script that takes a little time to load may still provide significant business value.

The broader impact of website speed also matters when evaluating third-party code, especially on marketing sites where performance directly affects the user experience.

You're looking for the cost-to-value ratio.

Look for Duplicate Functionality

One of the easiest wins in a script audit is finding tools that overlap.

A growing marketing stack can accumulate several tools that solve almost the same problem.

For example, you might have:

GA4 for analytics
another product analytics platform
a heatmap tool
a session-recording tool
a CRO platform
a separate event-tracking solution

They aren't identical, but there may be significant overlap.

The same thing can happen with tracking.

You might find multiple systems tracking:

page views
form submissions
CTA clicks
video plays
conversions

That creates two problems.

First, you're paying for tools that may not all be necessary.

Second, your team can end up with several versions of the same event and different numbers in different dashboards.

That kind of inconsistency can make analytics harder to trust, especially when multiple tracking systems are collecting similar data.

The technical cleanup can be easy.

The organizational cleanup is usually harder.

Someone needs to decide which system is the source of truth for each type of data.

Do Third-Party Scripts Need to Load on Every Page?

This is one of the highest-value questions in the entire audit.

A tool can be useful without needing site-wide access.

Consider a scheduling widget.

If its only purpose is to let visitors book a call, loading it on every blog article may not make sense.

The same applies to:

calculators
interactive demos
chat tools
review widgets
embedded videos
campaign-specific tracking
product-specific functionality

A simple rule is useful here:

If a script only supports one type of page, try to load it only where that functionality is needed.

This can reduce unnecessary requests and JavaScript execution on pages that don't benefit from the tool.

It also makes the website easier to reason about.

When someone investigates a slow blog post six months from now, they won't have to wonder why it is loading a collection of sales and product widgets that have nothing to do with the article.

A Script Audit Should End With a Decision

Once you've collected the data, every script should have a clear status.

I like using five:

1. Keep

The script provides meaningful business value, and its cost is justified.

2. Optimize

The tool is valuable, but its loading behavior, implementation, or scope can be improved.

3. Restrict

The tool is useful only on certain pages, for certain users, or after a specific interaction.

4. Replace

The business needs the functionality, but another implementation may provide a better balance of functionality, reliability, and performance.

5. Remove

Nobody needs it, nobody owns it, or its value doesn't justify keeping it.

That final category is often smaller than people expect.

The goal of a good audit isn't to delete half the website.

It's to make sure every piece of third-party code has a reason, an owner, and an appropriate place in the user journey.

Consent Changes the Loading Strategy

Privacy and consent requirements add another layer to script management.

Not every tracking or marketing script should necessarily load in the same way for every visitor.

Depending on the jurisdiction, consent configuration, and purpose of the technology, some third-party scripts may need to wait until the appropriate consent has been given. Google's Consent Mode documentation explains how Google tags can adjust their behavior based on a user's consent choices.

That means your audit should document:

which scripts are strictly necessary
which require consent
what happens when consent is denied
whether the consent platform actually controls the scripts
whether tags can fire before the expected consent state
whether the implementation matches your organization's privacy requirements

This is another reason you shouldn't simply copy a list of scripts from one website to another.

The technical implementation and the privacy requirements need to be considered together.

A consent banner that exists visually while tracking scripts continue firing before the appropriate consent state isn't solving the underlying problem.

The Goal Isn't Fewer Scripts. It's a Website You Can Explain.

A marketing website can have dozens of integrations and still be well managed.

The problem isn't the number sitting in your inventory.

The problem is when nobody can explain what those scripts do, why they load, who owns them, or what would happen if they disappeared.

That's when your marketing stack starts becoming technical debt.

A good WebOps process gives every integration a purpose and a place.

It also gives the team a way to challenge old decisions.

A tool that made perfect sense two years ago may not make sense today. A campaign may have ended. A new platform may have replaced an old one. A feature may have moved into another part of the stack.

The website should evolve with those changes.

And that brings us to the simplest rule I use for third-party scripts:

If you can't explain the value, the owner, the scope, and the cost, it's time to investigate why the script is still there.

Frequently Asked Questions

How many third-party scripts should a marketing website have?

→ There is no universal number that defines a healthy website.

A site with 10 scripts can have serious performance or tracking problems, while another site with 30 or 40 can be well managed.

What matters is whether each script has a clear purpose, an owner, an appropriate loading scope, and a reasonable technical cost.

Focus on understanding and controlling the script stack instead of chasing a specific number.

Do third-party scripts slow down a website?

→ They can. Third-party scripts can add network requests, download JavaScript, consume CPU, execute code on the main thread, and trigger additional resources.

The actual impact depends on the service, how it is implemented, when it loads, and what it does after loading.

Tools such as Chrome DevTools and Lighthouse can help you identify which third-party resources are contributing to the work performed by the browser.

Should I remove Google Tag Manager to improve website performance?

→ Not automatically. Google Tag Manager is a container that can load many different tags, so the performance impact depends heavily on what you put inside it.

Removing GTM while leaving the underlying tracking requirements unresolved may simply move the problem somewhere else.

Audit the tags inside the container first. Remove unused tags, eliminate duplicate tracking, restrict tags to relevant pages, and review how non-critical tags are loaded.

Should every marketing script load on every page?

→ No. A script should generally load wherever its functionality or measurement is actually needed.

A scheduling tool may only be necessary on pages where visitors can book a meeting. A product demo widget may only belong on product pages. A campaign-specific tracking script may only be relevant during a particular campaign.

Reducing unnecessary site-wide loading can improve performance while keeping the functionality your marketing team actually needs.

How often should I audit third-party scripts?

→ For many B2B SaaS websites, a quarterly review is a sensible starting point.

You should also review the script inventory after major website changes, migrations, new marketing tools, tracking architecture changes, or campaigns that introduce temporary integrations.

The exact frequency depends on how quickly the website and marketing stack change.

Final Thoughts

Having less scripts in your marketing site shouldn’t be just a goal in itself. Your site must utilize a technology stack that your marketing team is familiar with and can justify.

Each and every third-party script must justify its right to exist through efficiency of its business function, prevail scope, and the known owner.

Next time you find dozens of third-party requests present in DevTools, don’t ask yourself how to get rid of them. Instead, try to find out which requests actually has the right to exist.

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

You’re a Real Python Developer Only If...

Hadil Ben Abdallah — Mon, 12 Oct 2026 13:15:32 +0000

A few months ago, I published You're a Real JavaScript Developer Only If...

It was supposed to be a little post for fun.

You know, just a few things JavaScript developers could laugh about before going back to fighting their bugs 😅

But the community loved it, and the comments made me realize that developers have an incredible talent for turning their daily struggles into comedy.

Then @sylwia-lask published her own take, You're a Real Software Developer Only If… and surprised me how much fun this kind of post can be.

So I kept the fun going.

I published You're a Real TypeScript Developer Only If..., and now I'm back for another round with Python.

Well, Python developers have a very special relationship with whitespace 😂

They also have virtual environments, mysterious package conflicts, notebooks full of experiments, and that script that was supposed to take five minutes, but it became an entire project.

So, Python developers, this one's for you.

You're a real Python developer only if...

🤏🏻 You forgot one tiny indentation

Your code was almost perfect.

Almost.

Then Python reminded you that indentation is not just a formatting preference.

It's the difference between a working program and a confusing afternoon.

📦 You installed a package and broke everything

Everything was working perfectly.

Then you ran:

pip install some-package

Suddenly, another package needs a different version.

Your project has trust issues.

And you're asking what brought you here.

🧪 You created a virtual environment...

...and forgot to activate it.

You installed all your dependencies.

You ran your script.

And Python told you the module doesn't exist.

You installed it again.

Same problem.

Then you realized you were using the wrong environment.

🐼 You imported pandas just to open a CSV file

At first, it was a simple CSV.

A few rows. A few columns. Nothing complicated.

Then you started cleaning the data, filtering records, grouping results, and creating charts.

Three hours later, you're building an entire data analysis pipeline.

And you're having a great time.

🤔 You wrote a list comprehension and felt unstoppable

You started with a simple loop.

Then you discovered list comprehensions.

Now everything looks like this:

squares = [x**2 for x in range(10) if x % 2 == 0]

You could have written three lines, but this fits on one.

And that makes it better.

🐞 You used `print()` to debug everything

You could have used a debugger.

You could have added proper logging.

You could have investigated the issue systematically.

Instead:

print("HERE")
print(user)
print("WHY IS THIS NONE?")

And somehow, you found the bug.

📓 Your Jupyter notebook became a crime scene

You have cells numbered [1], [7], [14], and [39].

Some cells have been run five times.

Others haven't been touched since the day before.

One variable contains the result of an experiment you no longer remember.

And restarting the kernel feels like playing Russian roulette with your entire afternoon.

🧠 You discovered that `is` and `==` are not the same thing

You thought they did the same job.

Then someone explained object identity versus equality.

You nodded.

You understood the explanation.

You closed the article.

And six months later, you still pause for a few moments whenever you write one of them.

Just to be safe.

🐛 You caught a bug caused by `None`

Everything looked reasonable. The function ran. The variable existed.

But you were trying to perform an operation on None.

And the error message was basically Python saying:

"You gave me nothing. What exactly did you expect?"

Fair enough.

🔄 You turned a simple script into a reusable module

You needed to rename a few files.

So you wrote a quick script.

Then you added arguments.

Then error handling.

Then logging.

Then a configuration file.

Then a README.

At some point, you stopped calling it a script.

It's a tool now.

And you're considering publishing it on GitHub.

📚 You read the documentation and still had questions

Python has excellent documentation.

You know this and you appreciate it.

But sometimes you just want to know why a three-line example works in the tutorial and fails in your project.

So you open another tab. Then another.

And somehow, you're reading a discussion about a completely different problem.

That's programming.

🧹 You ran a formatter and discovered how much you needed it

Your code worked.

Your variable names made sense to you.

Your spacing was... creative.

Then you ran Black.

You didn't change the logic.

But you feel more professional already.

🚀 You wrote a Python script that worked locally...

...then discovered the server had a different Python version.

Or a missing dependency.

Or a different environment variable.

Or permissions you didn't know existed.

Your little script was supposed to automate a boring task.

Now you're learning deployment.

Character development comes in many forms.

🧩 You used `try/except` because you didn't want to see the error

You had an exception.

You didn't understand it.

So you wrote:

try:
    do_the_thing()
except Exception:
    pass

Problem solved!

Well, technically, the error disappeared.

The actual problem is still in the shadows.

And future-you is going to have some questions.

💛 You started learning Python because it looked simple

The syntax was clean.

The examples were easy to follow.

You could write something useful without spending half your day configuring a project.

You thought, "This language is so friendly!"

Then you met asynchronous programming, dependency management, packaging, decorators, and type hints.

Python is still friendly.

It just has a few rooms you haven't explored yet.

☕ You said, "I'll automate this little task"

You were doing something repetitive.

Surely, writing a script would save time.

So you spent two hours automating a task that takes five minutes.

Was it worth it?

Absolutely.

Will you admit how long it took?

Absolutely not.

🐍 The Python Developer Paradox

Here's the funny part.

You can spend an entire afternoon fighting with dependencies, wondering why your notebook has forgotten every variable, or trying to understand an error that looks completely unrelated to your code.

And the next day you open Python again.

Because you know how much you can build with it.

Python always has another interesting project waiting for you.

💬 Your Turn!

Python developers, although this list ended up being longer than I expected, but I know it still is missing some classics.

What's the most "Python developer" thing you've ever done?

Tell me your stories in the comments 😄

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

5 Best AI Gateways

Hadil Ben Abdallah — Mon, 12 Oct 2026 09:05:21 +0000

Choosing between the best AI gateways is not just about getting a way to call an LLM.

In real deployments, teams face more than one model vendor. Models can change over time. Traffic is not steady. Token prices keep going up. Agent style workflows can get hard to manage. A gateway lets engineers manage these moving parts in one spot, instead of writing provider-specific code across the app.

Still, not every gateway is meant for the same job. Some tools focus on a smooth developer setup and quick onboarding. Others aim for wide provider support and more control over choices. A few run close to the edge. Others are built for large scale production use, where throughput and enterprise needs matter.

This write-up compares five AI gateways: Bifrost, Cloudflare AI Gateway, Vercel AI Gateway, LiteLLM, and OpenRouter.

We will cover what counts for live use. That includes speed, provider access, reliability, routing, logs and tracing, cost limits, deployment options, and how simple it is to hook the gateway into your code.

TL;DR

AI gateways are an important part of the modern AI stack, but the best AI gateway for your application depends on where you host it and what you need from the gateway.

Below is a short review of five gateways:

Bifrost: Built for real production use. It is open source. It handles routing and failover. It also brings governance and observability. It includes MCP and agent features too. You can deploy it for teams that want enterprise setups.
Cloudflare AI Gateway: This one runs on Cloudflare’s edge. It supports routing across providers. It adds analytics, caching, and retry logic. It also ties into the rest of Cloudflare’s platform.
Vercel AI Gateway: This is a managed choice. The focus is on easy setup. It targets teams building with modern web tools and AI SDKs. The goal is quick integration.
LiteLLM: It is open source and written in Python. It covers many model providers. It offers an OpenAI-style interface. That helps if you want one client style while you switch between providers.
OpenRouter: This is a hosted API gateway. It routes models for you. It lets developers use a wide set of models and providers. You access them through one API.

In the end, the gap between these tools is control. Some help you reach many models fast. Others give you more control over how requests route, how the system runs, how it stays reliable, and how you can see what is happening in production.

What Is an AI Gateway (And Why Does It Matter in Production)?

An AI gateway is a layer that could be added between your app and the AI models or providers it uses.

Instead of connecting your application separately to OpenAI, Anthropic, Google, AWS, and other providers, an AI gateway can give your application a unified interface for sending requests and managing what happens around those requests.

Depending on the platform, an AI gateway can provide:

Unified APIs that reduce provider-specific integration work
Model routing across different providers and models
Automatic retries and failover when a provider has an issue
Observability for requests, latency, errors, tokens, and usage
Caching to reduce repeated model calls and costs
Rate limits and budgets for controlling AI usage
Access controls for teams, applications, or users
MCP and agent support for more complex AI workflows

This matters more as your AI app gets bigger.

A prototype might call one model directly from a single application. A production system can end up depending on several models, multiple providers, different environments, and thousands of requests per minute.

Without a centralized gateway, provider configuration and reliability logic can spread across the application codebase. Changing models, handling provider failures, tracking costs, or introducing usage policies can then require changes in several places.

A gateway gives your engineering team a clear place to manage these issues. Your app code can stay focused on the product.

How We Evaluated These AI Gateways

This comparison is about where AI gateways land in real work settings. It is not only about the feature list on a sales page.

The main criteria are:

Performance and scalability
Model and provider coverage
Routing and failover
Observability and cost control
Ease of integration
Deployment and infrastructure flexibility
Open-source availability and enterprise capabilities

Quick Comparison: The 5 Best AI Gateways

This comparison of the best AI gateways highlights the differences in deployment, provider access, performance, and pricing. Use it to narrow down the options that best fit your production requirements.

AI Gateway	Runtime / Model	Open Source	Key Strength	Pricing Model	Best For
Bifrost	Go	✓ Apache 2.0 core	Performance, routing, reliability, governance	Free self-hosted; Enterprise custom	High-traffic production AI
Cloudflare AI Gateway	Cloudflare Edge	✗	Edge integration, analytics, caching	Free core; usage-based Cloudflare costs	Cloudflare-based applications
Vercel AI Gateway	Managed	✗	Developer experience, routing, web integration	Free tier; paid plans	Vercel and frontend-heavy teams
LiteLLM	Python	✓	Provider coverage and flexibility	Free self-hosted; managed options	Multi-provider and Python teams
OpenRouter	Managed	✗	Large model catalog and unified API	Usage-based	Developers needing broad model access

It gets easier to tell them apart when you compare real production flow. Look at how each gateway manages live traffic. Also check how it handles provider setup. Finally, review what they do around AI request routing and supporting infrastructure.

1. Bifrost (by Maxim AI)

Bifrost is an open-source AI gateway and control plane built for production AI infrastructure. It gives engineering and platform teams a single interface for routing requests across models and providers while handling reliability, governance, observability, and cost controls from the same layer.

Bifrost is designed for environments where the gateway itself becomes an important part of the production request path. It supports 10,000+ models across 25+ providers, and provides an OpenAI-compatible API, so existing applications can connect by changing the API base URL.

It also goes beyond traditional LLM routing. Bifrost can govern LLM requests, MCP tool calls, and AI agent traffic through the same gateway, with enterprise capabilities for identity, access control, security, and deployment inside the customer's own infrastructure.

Production Performance and Reliability

An AI gateway adds another layer to every request, so its own performance can have a direct effect on the application using it.

Bifrost is built in Go with the request path optimized for low overhead. Its architecture keeps configuration in memory, pools and warms memory at startup, and maintains provider connections so requests do not repeatedly pay connection or database costs.

In a benchmark on AWS EC2 with 500 concurrent users over 60-second runs (benchmark results), Bifrost delivered:

424 requests/second versus 44.84 requests/second for LiteLLM
804 ms P50 latency versus 38.65 seconds
1.68 seconds P99 latency versus 90.72 seconds
120 MB memory usage versus 372 MB
100% success rate versus 88.78%

Actual performance depends on infrastructure, workload, provider latency, and configuration, so it is worth testing with your own traffic.

For larger production deployments, Bifrost Enterprise adds cluster mode, adaptive load balancing, circuit breakers, automatic failover, and zero-downtime deployments.

Routing, Governance, and AI Traffic Control

Bifrost provides a unified gateway for model and provider routing, with support for weighted load balancing, retries, and automatic fallback.

Teams can route requests across different models and providers while keeping application integrations behind a single API. Governance controls can then be applied to that traffic without requiring each application team to implement the same rules independently.

Core capabilities include:

Routing across 10,000+ models and 25+ providers
Weighted load balancing and provider failover
Budgets and rate limits through virtual keys
Semantic caching for repeated requests
Prometheus metrics and OpenTelemetry tracing
Integrations with platforms such as Datadog, Kafka, BigQuery, Pub/Sub, and Splunk

Bifrost also supports MCP Gateway capabilities, allowing models and agents to discover and call tools through the same infrastructure. Tool filtering, authentication, agent mode, and MCP server functionality extend the gateway beyond conventional model routing.

For large tool environments, MCP Code Mode lets the model orchestrate tools through sandboxed code instead of carrying every tool definition inside the prompt. Code Mode cuts input tokens by up to 92.8% across large tool sets.

Deployment and Enterprise Control

Bifrost is designed for organizations that need control over where their AI infrastructure runs and where their data stays.

The gateway can run as a single binary across environments including:

Virtual machines
Kubernetes
Private cloud
VPC infrastructure
On-premises environments
Air-gapped networks

The open-source core is licensed under Apache 2.0, while Bifrost Enterprise adds capabilities such as identity-based governance, fine-grained access control, guardrails, signed audit logs, secret management, and high-availability infrastructure.

Bifrost also includes Bifrost Edge, which extends gateway control to employee devices.

Pricing

Bifrost's open-source version is free forever for self-hosted use under the Apache 2.0 license.

Bifrost Enterprise uses custom pricing and includes a 14-day free trial.

Best for

Bifrost is built for businesses that require high-level performance, scalability, and reliability ability that are crucial to AI deployment. Its primary function is to act as a gateway through which all AI traffic goes through the system in a guided and secure manner. Bifrost combines its LLM, MCP, and Agents gateways into a single platform. It covers industries subject to regulations and strict business needs, including air-gapped deployment, VPC isolation, and on premises infrastructure. It offers complete control over data, access, and execution, as well as huge security capabilities.

Explore Bifrost

2. Cloudflare AI Gateway

Cloudflare AI Gateway provides a centralized layer for managing AI requests across different model providers while keeping those requests within the Cloudflare ecosystem. It is designed for teams that want more control over AI traffic without building a separate gateway layer from scratch.

The gateway works as a proxy between applications and AI providers, giving teams a consistent endpoint for sending requests while adding capabilities such as caching, rate limiting, retries, logging, and analytics. This can make it easier to monitor AI usage and manage production traffic as applications scale.

Pricing

Cloudflare AI Gateway has a free gateway layer, while the underlying AI provider usage and other Cloudflare services can incur their own costs. Pricing therefore depends largely on the Cloudflare products being used and the volume of AI traffic generated.

Best for

Cloudflare AI Gateway is best for teams already using Cloudflare infrastructure that want centralized AI traffic management, observability, caching, and control without introducing a separate AI gateway stack.

Explore Cloudflare AI Gateway

3. Vercel AI Gateway

Vercel AI Gateway is built for teams that are developing AI-powered web applications and want a simple way to connect their applications to multiple model providers.

The gateway provides a unified interface for model access while handling infrastructure concerns such as provider routing, failover, and model selection. This can reduce the amount of provider-specific logic developers need to maintain inside their applications.

Its biggest appeal is the developer experience. Teams already building with Vercel, Next.js, and the AI SDK can adopt an AI gateway without introducing a large amount of additional infrastructure to their stack.

Pricing

Vercel AI Gateway offers a free way to get started, with additional Vercel plans and usage-related costs depending on the deployment and services a team uses. BYOK configurations can also use provider pricing directly without additional token markup from Vercel.

Best for

Vercel AI Gateway is best for frontend and full-stack teams building AI applications with Vercel that prioritize developer experience, fast integration, and straightforward access to multiple AI models.

Explore Vercel AI Gateway

4. LiteLLM

LiteLLM is one of the most widely used open-source AI gateways for teams that want a common interface across different model providers. Built around Python, it provides an OpenAI-compatible API that lets applications connect to hundreds of models and providers without implementing separate integrations for each one.

Its biggest advantage is flexibility. LiteLLM supports a broad range of providers and gives developers tools for model routing, fallbacks, load balancing, retries, spend tracking, rate limits, and observability. That makes it useful for teams experimenting with different models or building applications that need to switch providers without rewriting their application logic.

LiteLLM can be deployed as a self-hosted proxy, making it attractive to engineering teams that want control over their AI infrastructure. It also offers managed cloud options for teams that do not want to operate the gateway themselves.

Pricing

LiteLLM's open-source gateway can be self-hosted for free, with infrastructure and model-provider costs remaining the main expenses. Managed and cloud offerings have separate pricing based on the services and usage involved.

Best for

LiteLLM is best for developers and engineering teams that need broad model and provider coverage, flexible routing, and an open-source AI gateway they can customize and self-host.

Explore LiteLLM

5. OpenRouter

OpenRouter takes a different approach to the AI gateway problem by providing a unified API for accessing a large catalog of AI models from different providers. Developers can use one API and switch between models without building separate integrations for every provider.

This makes OpenRouter useful when model choice is a major part of the development workflow. Teams can compare models, experiment with different providers, and route requests through a common interface while keeping the application integration relatively simple.

OpenRouter also provides features such as model routing, provider selection, usage tracking, and fallbacks, depending on the configuration and models being used. For developers who want fast access to a broad model ecosystem without operating their own gateway infrastructure, that simplicity can be a major advantage.

Pricing

OpenRouter generally charges based on model usage, with pricing determined by the underlying models and providers. Some models may also be available at no cost, while paid models follow their respective usage rates.

Best for

OpenRouter is best for developers and AI teams that want a single API for accessing and experimenting with a large selection of models without managing multiple provider integrations themselves.

Explore OpenRouter

How to Choose the Right AI Gateway

Choosing an AI gateway is not about looking for the one that offers the most features. It's about understanding your application's needs as it develops.

Here’s what to consider:

How many models and vendors do I need to work with?

If your application relies on different providers, look for broad provider coverage, a uniform API, and consistent behavior across models. A gateway that simplifies switching providers can save significant engineering time as your application grows.

How critical are speed and dependability?

For customer-facing AI applications, gateway overhead and provider failures can directly affect the user experience. Look for fast request processing, automatic retries, availability-aware routing, and high availability. Bifrost is worth evaluating when low latency, throughput, and production reliability are priorities.

Do I want an open-source or a hosted solution?

An open-source gateway gives your team more control over deployment, customization, and infrastructure, but your team is responsible for operating it. A hosted gateway reduces maintenance and can simplify onboarding. Choose based on your team's infrastructure capabilities, security requirements, and need for operational control.

How do I keep track of AI costs?

As AI usage grows across applications and teams, costs can become harder to track. Look for budgets, rate limits, usage reports, and analytics that help you understand spending by model, provider, application, or team. Bifrost is worth considering when centralized cost controls and usage visibility are important.

Where will the gateway be implemented?

Consider your deployment requirements before choosing a gateway. A hosted service may suit teams that want minimal infrastructure work, while organizations with strict data-control requirements may need a private-cloud, VPC, on-premises, or air-gapped deployment. Bifrost supports these deployment models, making it a relevant option for enterprises that need greater control over their AI infrastructure.

A gateway that works perfectly for an early-stage application may not be the right choice once traffic, model usage, and operational requirements increase. Evaluating those constraints early makes the decision easier.

Frequently Asked Questions

What is an AI gateway used for?

→ An AI gateway provides a centralized layer between an application and the AI models or providers it uses. When evaluating the best AI gateways, look for capabilities such as model routing, authentication, retries, monitoring, rate limiting, and cost management.

This becomes more valuable as an application grows and starts using multiple models or providers. A centralized layer can keep provider-specific logic out of individual applications and give engineering teams a consistent way to manage AI traffic.

What is the difference between an AI gateway and an API gateway?

→ An API gateway is designed to manage traffic between applications and backend services, handling concerns such as authentication, routing, rate limiting, and request policies.

An AI gateway applies similar principles to AI workloads, but adds capabilities specific to model traffic. These can include model selection, provider routing, token and usage tracking, AI-specific fallbacks, prompt-related controls, and support for different model providers.

Should I use an open-source or managed AI gateway?

→ The right choice depends on how much infrastructure control your team needs and how much operational work it wants to take on.

Open-source gateways can provide greater control over deployment, configuration, customization, and data handling. They can be a good fit for teams with strong infrastructure capabilities or strict security requirements.

Managed gateways reduce the operational burden because the provider handles much of the underlying infrastructure. They can be attractive to teams that want to integrate multiple AI providers quickly without maintaining another production service.

Can an AI gateway reduce AI costs?

→ An AI gateway can help reduce and control AI spending, but it does not automatically make model usage cheaper.

Cost savings can come from capabilities such as model routing, caching, rate limits, budgets, and usage tracking. For example, an application can route simpler requests to lower-cost models, cache repeated requests, or enforce spending limits for individual teams or applications.

The actual savings depend on how the gateway is configured and how AI traffic is managed.

Do I need an AI gateway if my application only uses one AI provider?

→ Not necessarily. A small application using one provider may not need the additional infrastructure or operational layer.

An AI gateway can still be useful when the application needs centralized observability, rate limiting, cost controls, security policies, or a clean way to introduce additional models later. The decision should be based on the operational requirements of the application rather than simply the number of providers being used.

Final Thoughts

AI gateways are a core part of the architecture of production AI applications. As the number of models, providers, agents, and AI tools a team uses increases, managing each integration separately gets harder.

The five platforms in this guide address that challenge in different ways, but Bifrost is my top pick for production and enterprise AI workloads. Its combination of performance, reliability, routing, governance, and flexible deployment makes it a strong option for teams that need control over their AI infrastructure.

Bifrost unifies LLM gateway, MCP gateway, and agent capabilities in one platform. It also supports self-hosted, VPC, on-premises, and air-gapped deployments, which makes it a strong fit for enterprises with demanding security, governance, and infrastructure requirements.

The other gateways have clear use cases, too. Cloudflare AI Gateway is a natural fit for teams already using Cloudflare. Vercel AI Gateway suits teams building with Vercel and Next.js. LiteLLM is a flexible option for Python teams that want an open-source gateway, while OpenRouter is useful for developers who want broad model access through one API.

When comparing the best AI gateways, consider performance, reliability, model access, observability, cost controls, security, and deployment requirements. For teams running mission-critical AI workloads, Bifrost stands out as the leading choice in this comparison because it combines these production needs with enterprise governance and infrastructure flexibility.

For a simple application, a lightweight managed solution will do. For a larger AI platform that handles heavy production traffic, model routing, agent workflows, and enterprise policies, the gateway becomes an essential part of the architecture.

Choose the AI gateway based on the problems you need to solve. If production performance, reliability, governance, and deployment control are your priorities, Bifrost is the first option I'd evaluate.

Teams evaluating AI gateways can request a Bifrost demo or review the open-source repository.

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

Your Code Editor Says More About You Than You Think

Hadil Ben Abdallah — Thu, 01 Oct 2026 08:47:31 +0000

You might think that your code editor is just a tool you're using to write code, but I think it's a personality type, a lifestyle choice...

If you disagree, you might be using Notepad. And in that case, I think you need help 😄

Let's see which one you're using.

1. VS Code

I think this is the king of the modern dev jungle.

If you use VS Code, you're the kind of person who walks into a coffee shop, orders something complicated, and still finds time to install ten new extensions before the drink is ready.

VS Code users love control. You want customization, but in a click-to-install kind of way. Your workspace has 17 tabs open, GitHub Copilot is writing half your code, and you're still Googling how to center a div.

You don't have one theme. You have a rotating mood board of themes you switch depending on the project, the weather, and your emotional state.

2. IntelliJ

If you're rolling with IntelliJ or anything from JetBrains, congratulations 🥳 You are a serious developer.

You write Java, Kotlin, C#, Python, or something else that somehow requires 14 plugins and a dedicated settings file.

You believe in static typing, design patterns, and paying for software.

You don't just commit code, you architect it. And every time someone suggests using a lightweight editor, you just laugh.

3. Cursor

If you use Cursor, you've decided that writing code yourself is becoming optional.

You type a sentence, watch AI change 17 files, and then spend 10 minutes trying to figure out what it did.

You probably have strong opinions about models, context windows, agents, and which AI is currently "cooking".

You don't just debug anymore. You ask the AI why your code is broken, watch it confidently make things worse, and then ask it to fix the fix.

4. Vim

If you use Vim, I respect you. I also fear you. You operate purely from muscle memory, like a martial artist who's trained in complete darkness.

You don't use a mouse because it's too slow. Your entire coding experience is basically an extreme sport. You once spent 3 hours configuring your .vimrc file.

Sure, nobody taught you Vim. You were summoned by it. And let's be honest, part of you loves that other people can't figure it out.

And you still have to explain to someone how to exit Vim at least once a year.

5. Zed

If you use Zed, you probably looked at every other editor and thought, "This is way too much".

You want your editor fast. Really fast. You don't need 47 extensions, 12 panels, or a sidebar telling you things you didn't ask for.

You open Zed, start typing, and wonder why everyone else is apparently okay with their editor taking 30 seconds to wake up.

You're probably the kind of developer who says, "I just want to write code".

6. Emacs

If you use Emacs, you don't code; you create art.

You've probably written your own Emacs extensions in Lisp. You don't just open files. You open entire ecosystems.

Need a calendar? 👉🏻 Emacs.
Need email? 👉🏻 Emacs.
Need to order lunch? There's probably a package for that too.

You're the kind of person who hears, just use a GUI, and responds with 300 lines of ELISP.

7. Eclipse

If you're still using Eclipse in 2026, stop it. You didn't start with Eclipse. Eclipse started with you. You probably had to use it in school or because the lead developer at your company refuses to upgrade anything that still technically works.

You have patience. You have strength. You waited 5 minutes for it to open, and you stayed anyway. You are a hero.

8. Notepad

Notepad users, I don't know who hurt you, but we're here for you.

If you're writing full applications in Notepad, you either work for the government or you're punished.

Syntax highlighting? Never heard of her.
Autocomplete? That's what your memory is for.

I don't have anything else to say about it.

Final Thoughts

Your IDE doesn't define you as a developer. It just says a lot about how you like to work.

Some of us want a lightweight editor with a few extensions.
Some want a full IDE that analyzes everything.
Some want nothing but a terminal.

And that's fine.

It's not about which editor is “best”. It's about how much time you spend customizing it instead of actually writing code 😅

💬 So, what are you using? Tell me your editor, and I'll try to guess your developer personality.
And if you're still out here using Dreamweaver or Notepad, just give us a sign; we're here to help 😂

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

Top 5 AI Governance Tools for Enterprises in 2026: A Practical Comparison

Hadil Ben Abdallah — Mon, 28 Sep 2026 09:11:53 +0000

AI is becoming part of almost every layer of an enterprise.

Employees are using AI assistants. Developers are connecting coding agents to internal systems. Applications are calling multiple models behind the scenes. Agents can now invoke tools, access data, and take actions with very little human involvement.

That creates a governance problem that goes far beyond choosing a model.

Who can use which AI system? What data can it access? Which models and tools are approved? How are AI risks assessed? Can security teams see what is happening across the organization? And when something goes wrong, is there an audit trail showing what happened?

This is where AI governance tools come in.

Modern enterprise AI governance platforms can help organizations manage AI inventories, assess risk, enforce policies, monitor usage, maintain compliance evidence, and establish accountability across AI systems. The exact approach varies significantly between products, though. Some focus heavily on governance workflows and risk management, and others bring governance directly into AI traffic, model access, agents, and tools.

This guide compares five AI governance tools for enterprises in 2026, looking at the capabilities that matter when AI moves from experimentation into production.

TL;DR

If you need a quick overview before diving into the details, here’s what this comparison focuses on:

Bifrost: A runtime-focused approach to AI governance, giving enterprises control over model requests, MCP tools, agents, access, budgets, guardrails, and auditability across AI traffic.
IBM watsonx.governance: Focuses on AI lifecycle governance, helping enterprises manage AI inventory, risk, compliance, policies, monitoring, and accountability.
Microsoft Purview: Brings AI governance into Microsoft's broader data security and compliance ecosystem, with strong capabilities around sensitive data, AI applications, auditing, and Microsoft 365 environments.
Credo AI: Provides a dedicated AI governance platform for managing AI systems, risks, policies, regulatory requirements, and emerging agent and MCP governance needs.
Holistic AI: Takes an end-to-end governance approach covering AI discovery, risk assessment, testing, compliance, monitoring, and policy enforcement.

The main takeaway is that AI governance is much broader than simply approving AI models. Enterprises may need visibility, risk management, compliance, data protection, identity controls, runtime enforcement, and auditability working together.

What Are AI Governance Tools?

AI governance tools are software platforms that help organizations control, monitor, assess, and document how artificial intelligence is used across the enterprise.

That can include everything from maintaining an inventory of AI systems and evaluating their risks to managing policies, tracking compliance requirements, monitoring model usage, and creating audit evidence.

A useful way to think about AI governance is to split it into several connected questions:

What AI do we have?

Organizations need visibility into the models, applications, agents, AI-powered features, vendors, and tools being used across the business.

What are we allowed to do with it?

Policies define which models, data sources, applications, users, and AI capabilities are acceptable for different teams and use cases.

What could go wrong?

Risk management looks at issues such as sensitive data exposure, unreliable outputs, security risks, regulatory obligations, model behavior, third-party dependencies, and inappropriate AI usage.

Can we prove what happened?

Audit logs, assessments, approvals, monitoring, and evidence help security, compliance, and governance teams demonstrate how AI systems are being managed.

Frameworks such as the NIST AI Risk Management Framework organize AI risk management around activities including governing, mapping, measuring, and managing risks. ISO/IEC 42001 takes a broader management-system approach, providing requirements for establishing and continually improving an organization's AI management system.

But there’s an important distinction for enterprise AI infrastructure.

A governance platform can tell an organization that a particular model, application, or use case has a certain risk level. A runtime governance layer can also enforce controls when AI traffic is flowing.

How We Evaluated These AI Governance Tools

There is no single feature that makes an AI governance tool suitable for every enterprise.

A company managing a few internal models has very different requirements from a financial institution running hundreds of AI applications, multiple model providers, autonomous agents, and strict compliance controls.

For this comparison, the focus is on practical enterprise governance, with attention to the following areas:

AI Visibility and Inventory
Risk Management and Compliance
Policy Enforcement
Security and Access Control
Observability and Auditability
Enterprise Deployment
Operational Fit

Quick Comparison: Top 5 AI Governance Tools

AI governance covers a wide range of problems, so these platforms do not all approach it from the same direction.

Here’s a high-level comparison of the five tools covered in this guide:

AI Governance Tool	Main Focus	Open-Source Version	Enterprise Strength	Pricing	Best For
Bifrost by Maxim AI	Runtime AI governance and infrastructure	✔ (Apache 2.0 core)	VPC, on-prem, air-gapped, self-hosted	Free OSS; Enterprise custom pricing	Enterprises needing governance enforced directly across AI traffic
IBM watsonx.governance	AI lifecycle governance	❌	Cloud and enterprise deployments	From $3,500/month for Risk & Compliance Basic	Organizations managing AI risk and governance across the lifecycle
Microsoft Purview	Data security, compliance, and AI governance	❌	Deep Microsoft 365/Azure integration	From $12/user/month	Microsoft-centric organizations governing AI and sensitive data
Credo AI	AI governance and responsible AI	❌	Enterprise integrations and governance workflows	Custom pricing	Enterprises building structured AI governance and regulatory programs
Holistic AI	AI discovery, risk, testing, compliance, and policy enforcement	❌	Enterprise-focused platform	Custom pricing	Organizations seeking end-to-end AI risk and compliance governance

The differences become much clearer once you look at how each platform handles governance in practice.

1. Bifrost by Maxim AI

Bifrost approaches enterprise AI governance from the infrastructure layer, using a centralized control plane in front of AI traffic.

Here, “AI traffic” refers to requests and interactions involving models, AI agents, MCP tools, and AI applications that pass through the organization's infrastructure.

The Gateway governs model requests, MCP tool calls, and agent activity.

The platform is built for enterprises that want to run AI inside their own infrastructure. Bifrost supports deployment on virtual machines, Kubernetes, private cloud, VPC environments, on-premises infrastructure, and air-gapped networks. Its open-source core is licensed under Apache 2.0, while the enterprise tier adds capabilities aimed at high-availability, identity, security, and compliance requirements.

Governance Across Models, MCP Tools, and Agents

One of Bifrost's main differences is the scope of traffic it can govern.

The Gateway can sit in front of model providers while also handling MCP traffic and agent workflows. Virtual keys can carry budgets, rate limits, and access rules, while MCP policies can control which tools are available to different clients or users. Enterprise features add identity-based governance, access profiles, guardrails, audit logs, and integrations with identity providers such as Okta, Microsoft Entra, Keycloak, Zitadel, and Google Workspace.

Bifrost also supports MCP Code Mode, where large tool definitions can be replaced by a code-based orchestration approach. According to Maxim's published information, this can reduce input-token usage by up to 92.8% across large tool sets. Developers can explore the implementation and contribute through the Bifrost GitHub repository.

Runtime Performance and Overhead

Governance controls eventually become part of the request path, so performance matters.

Bifrost is built in Go and is designed around low gateway overhead, high throughput, and predictable resource usage. Maxim's published benchmark, run on AWS EC2 with 500 concurrent users and 60-second runs, reports 424 requests/second for Bifrost versus 44.84 requests/second for LiteLLM, along with lower reported P50 and P99 latency, lower memory usage, and a higher success rate in that test.

These results come from Maxim AI's published benchmark under the stated test conditions and should not be interpreted as a universal performance comparison. Actual results can vary depending on infrastructure, workload, model providers, network conditions, configuration, and concurrency.

The same published benchmark also reports around 11 microseconds of gateway overhead at 5,000 requests/second on a single instance, with a 100% success rate in that test.

Extending Governance to Employee Devices

A centralized gateway can only govern traffic that actually reaches it.

That creates a problem with shadow AI. Employees can use tools such as ChatGPT, Claude, Cursor, coding agents, browser-based AI applications, and MCP servers directly from their machines, which can create AI traffic that does not pass through a central gateway.

Bifrost Edge is designed to address that gap. It runs on employee devices and routes AI traffic through the Bifrost Gateway. Administrators can inventory supported AI applications and MCP servers, approve or deny them, and apply gateway policies to endpoint traffic. Edge supports macOS, Windows, and Linux, and can be deployed through existing device-management systems.

Pricing

Bifrost's open-source version is available under the Apache 2.0 license, while Bifrost Enterprise uses custom pricing. Enterprise includes a 14-day free trial, and Bifrost Edge is priced per endpoint.

Best for

Enterprises running mission-critical AI workloads that require best-in-class performance, scalability, and reliability. It serves as a centralized AI gateway to route, govern, and secure all AI traffic across models and environments with ultra-low latency. Bifrost unifies LLM gateway, MCP gateway, and Agents gateway capabilities into a single platform. Designed for regulated industries and strict enterprise requirements, it supports air-gapped deployments, VPC isolation, and on-prem infrastructure. It provides full control over data, access, and execution, along with robust security, policy enforcement, and governance capabilities

Explore Bifrost

2. IBM watsonx.governance

IBM watsonx.governance is designed for organizations that need to manage AI risk, compliance, policies, and accountability across the AI lifecycle. The platform provides visibility into AI systems and supports governance processes that span development, deployment, monitoring, and ongoing risk management.

Its approach fits enterprises that already have formal risk and compliance processes in place. IBM positions watsonx.governance as an AI governance layer connected with enterprise GRC capabilities, helping teams manage policies, regulatory requirements, AI risks, and governance activities from a centralized environment.

The platform also supports continuous monitoring, policy enforcement, regulatory alignment, and traceability. That makes it useful for organizations where AI governance needs to connect with existing risk, audit, and compliance operations, not operate as a separate workflow.

Pricing

IBM offers a 14-day free trial, with Risk & Compliance plans starting at $3,500/month for Basic and $6,450/month for Advanced. Pricing can vary by deployment, region, and purchasing model.

Best for

Large organizations that want AI governance integrated with established risk, compliance, audit, and enterprise governance processes.

Explore IBM watsonx.governance

3. Microsoft Purview

Microsoft Purview takes an AI governance approach centered heavily on data security, compliance, and visibility into AI usage. This makes it especially relevant for organizations already using Microsoft 365, Azure, Microsoft Entra, and other Microsoft enterprise services.

Purview's Data Security Posture Management for AI can help organizations discover and understand AI activity, identify data-security risks, and apply existing information protection and compliance controls to AI applications. Microsoft also supports governance and protection for supported AI agents, including Microsoft Copilot and Microsoft Foundry scenarios.

A major strength here is the connection between AI governance and enterprise data governance. Purview can apply capabilities such as data classification, sensitivity labels, data loss prevention, auditing, and compliance management to supported AI interactions.

Pricing

Microsoft Purview uses several licensing and consumption models. The Purview Suite is listed from $12/user/month when paid annually, while some capabilities use separate licensing or Azure consumption-based pricing.

Best for

Organizations already invested in the Microsoft security, compliance, identity, and data ecosystem that want to extend those controls to generative AI and AI agents.

Explore Microsoft Purview

4. Credo AI

Credo AI is a dedicated enterprise AI governance platform focused on helping organizations discover AI systems, assess risk, manage policies, monitor AI usage, and maintain compliance across the AI lifecycle. Its platform includes an AI registry covering models, applications, agents, vendors, and shadow AI.

The platform also uses a governance knowledge graph that connects regulatory requirements, business context, AI systems, risks, and controls. Credo AI supports policy packs and compliance mappings for frameworks, including the EU AI Act, NIST AI RMF, and ISO 42001, with governance workflows designed to turn those requirements into operational processes.

Credo AI has also expanded its focus toward agent governance, including agent registries, agent-specific risk assessments, MCP server governance, dependency mapping, continuous monitoring, and policy controls for autonomous AI systems.

Pricing

Credo AI does not publish standard platform pricing publicly; enterprise customers need to contact the company for a tailored quote based on their governance requirements and deployment.

Best for

Enterprises building a dedicated AI governance and responsible AI program, especially teams that need structured risk management, regulatory mapping, AI inventories, and governance workflows across many AI systems.

Explore Credo AI

5. Holistic AI

Holistic AI takes an end-to-end approach to enterprise AI governance, organizing its platform around three areas: Identify, Protect, and Enforce. The platform is designed to discover AI systems across an organization's cloud, code, SaaS, and vendor environment, then assess risk and apply governance controls.

The Identify layer focuses on AI discovery and inventory, including models, agents, APIs, pipelines, datasets, and shadow AI. Holistic AI also provides an agent graph to map relationships between agents, tools, models, data, and workflows.

The Protect layer covers AI risk assessment and testing. Its published capabilities include automated testing for areas such as bias, robustness, privacy, hallucination, toxicity, and security, alongside red-teaming for agentic AI and continuous monitoring after deployment.

The Enforce layer connects governance policies with compliance workflows and audit evidence. Holistic AI maps controls to frameworks, including the EU AI Act, NIST AI RMF, and ISO/IEC 42001, and its Guardian Agents are designed to monitor AI behavior and apply governance controls based on configured policies and risk thresholds.

Pricing

Holistic AI uses an enterprise, custom-quote pricing model and does not publish standard plans or prices publicly. Organizations need to contact its sales team for pricing.

Best for

Enterprises looking for a broad AI governance lifecycle, from discovering AI systems and assessing their risks to monitoring them and operationalizing compliance controls.

Explore Holistic AI

AI Governance Tools vs. AI Security and Runtime Controls

One of the easiest mistakes when researching AI governance software is treating every product in the market as if it solves the same problem.

A useful way to think about the landscape is through layers:

Governance Layer	Typical Questions
AI inventory	What AI systems do we have? Who owns them?
Risk & compliance	What risks exist? Which policies and regulations apply?
AI lifecycle governance	Was the system reviewed, approved, tested, and monitored?
Data governance	What data can AI access or expose?
Runtime governance	Which models, tools, and agents can actually be called?
AI security	Can unsafe requests, sensitive data, or malicious activity be detected and blocked?
Endpoint governance	What happens when employees use AI tools directly from their devices?
Audit & observability	Can the organization prove what happened?

This layered view also helps explain why two products can both legitimately call themselves AI governance platforms while solving very different problems.

How to Choose the Right AI Governance Tool

Choosing an AI governance tool for an enterprise is not simply about comparing feature lists. Different platforms operate at different layers of the AI stack, so the right choice depends on what your organization needs to control, how AI is being used, and where governance needs to be enforced.

Before choosing a platform, work through these five areas:

1. Define What You Actually Need to Govern

Start by identifying the AI systems and activities that need oversight.

Make a list of the assets you need to govern, models, applications, agents, data, users, tools, and endpoints, before comparing vendors. This makes it much easier to identify which platforms actually match your environment.

2. Separate Governance From Runtime Enforcement

Ask whether you need a system that documents and manages governance policies, or one that can also enforce those policies while AI is being used.

For organizations running production AI, this distinction is important because having a policy that says "only approved models may be used" is different from having a technical control that can actually enforce that requirement.

3. Check Compliance, Security, and Data Requirements

Enterprise AI governance is closely connected to security and regulatory requirements. Check whether the platform supports the frameworks and controls relevant to your organization, such as NIST AI RMF, ISO/IEC 42001, GDPR, or the EU AI Act.

Also look at practical security requirements: SSO, RBAC, audit logs, data protection, guardrails, identity integrations, and secret management.

If sensitive information cannot leave your environment, deployment architecture becomes equally important. Check whether the platform supports the required cloud, VPC, on-premises, or air-gapped deployment model.

4. Consider Your Existing Enterprise Stack

An AI governance platform rarely operates alone. It needs to work with the systems your organization already uses for identity, security, observability, compliance, and infrastructure.

Look for integrations with existing identity providers, SIEM/security platforms, monitoring systems, data platforms, ticketing tools, and cloud infrastructure.

5. Test It With a Real AI Workflow

A vendor's feature list is not enough. Before making a decision, test the platform against a realistic enterprise workflow.

For example, take an AI application that calls multiple models and an MCP tool. Then test how the platform handles identity, permissions, sensitive data, policy enforcement, failed requests, budgets, logging, and auditing.

Also measure operational factors such as performance, scalability, deployment complexity, and administration.

Frequently Asked Questions About AI Governance

What is AI governance in simple terms?

→ AI governance is the collection of policies, processes, responsibilities, and technical controls an organization uses to manage how artificial intelligence is developed and used. It covers areas such as AI risk, security, privacy, compliance, accountability, access control, monitoring, and documentation.
Frameworks such as the NIST AI RMF and ISO/IEC 42001 provide structured approaches for managing these risks and responsibilities.

Why is AI governance important for enterprises?

→ AI governance becomes important as AI moves from experimentation into production.
An enterprise may have hundreds of AI applications, multiple model providers, internal agents, employee-facing AI tools, and external services. Without clear ownership and controls, it becomes difficult to know which systems exist, what data they access, what risks they introduce, and whether organizational policies are actually being followed.
Good governance gives teams a repeatable way to manage those risks while maintaining visibility as AI adoption grows.

What is the difference between AI governance and AI security?

→ They overlap, but they are not identical.
AI governance focuses on policies, accountability, risk management, compliance, ownership, and oversight.
AI security focuses more directly on protecting AI systems, models, data, users, and infrastructure from security threats.
Runtime governance connects some of these areas by enforcing policies during actual AI requests.

Can one AI governance platform govern models, agents, and MCP tools?

→ It depends on the platform.
Traditional AI governance platforms may focus on models, applications, risk, policies, and compliance, while newer platforms can also govern agent and MCP activity. The important consideration is whether the platform can actually observe and enforce controls across the AI components your organization uses.

Bifrost, for example, treats model calls, MCP tool calls, and agent traffic as AI traffic that can pass through the same governance layer. Its MCP capabilities include tool filtering, authentication, and Code Mode.

Do enterprises need more than one AI governance tool?

→ Sometimes.
An organization may already have separate platforms for GRC, data security, model monitoring, identity, endpoint management, and runtime AI infrastructure.
The goal does not necessarily need to be replacing all of them with one product. A better approach is to determine which governance responsibilities each existing system handles and identify the gaps between them.

Final Thoughts

AI governance is becoming an essential part of building and operating AI at enterprise scale.

As organizations adopt more models, AI applications, agents, and automated workflows, governance needs to keep pace with that growth. Simply having an internal AI policy is not enough if teams cannot see what AI systems exist, understand their risks, control access, protect sensitive data, and demonstrate what happened when something goes wrong.

A practical AI governance strategy should connect people, policies, processes, and technology. It should also evolve as the organization's AI footprint changes.

The right approach will depend on the company's industry, regulatory requirements, AI workloads, existing security infrastructure, and level of AI maturity.

Ultimately, effective AI governance should make AI adoption more visible, controlled, accountable, and easier to scale responsibly.

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

7 Lies PMs Tell Engineers

Hadil Ben Abdallah — Wed, 23 Sep 2026 09:04:39 +0000

If you work with software engineers long enough, you start noticing something strange.

PMs have a special talent.

They can take a sentence that sounds completely harmless and make an engineer's entire afternoon disappear.

To be fair, most PMs aren't actually trying to lie to engineers.

Sometimes they genuinely don't know how some things are complicated.

But after hearing the same sentences over and over again, you start developing a little internal translator.

So, for fun, here are 7 lies PMs tell engineers, according to engineers who have definitely never complained about PMs in Slack.

Obviously 😄

1. “It’s just a tiny update. It should take 15 minutes.”

This one deserves to be number one.

A PM comes to you with a request from the client.

“They just want one small change on the dashboard. It shouldn't take more than 15 minutes.”

You look at the ticket. The requested change is one sentence.

You look at the code. The requested change is no longer one sentence.

Maybe that “small” UI change depends on data coming from an API. Maybe the API doesn't return the information you need. Maybe the backend gets its data from another service. Maybe that service has a completely different structure. Maybe changing the backend response will affect three other components.

And then there is testing.

And then there is the possibility that nobody knows why the existing code was written that way because the person who wrote it left the company two years ago.

So, the 15-minute task has become a full day.

And when you finally explain this, you get:

“But the client said it's very simple.”

Of course they did.

The client doesn't have to open the repository. He just sees a button.

You see the 14 things that happen after someone clicks the button.

That's one of the biggest differences between how clients see software changes and how engineers see them.

This is why I think PMs should be allowed to say:

“I don't know how long this will take. Let me ask the engineer.”

2. “We can add it quickly. It’s basically the same feature.”

This one usually arrives right after the previous one.

You already have Feature A.

The client now wants Feature B.

The PM looks at Feature A and says:

“We already have something similar, so we can probably reuse most of it.”

Sometimes that's true.

But sometimes “similar” means the two features have the same color and absolutely nothing else in common.

The problem is that software features can look identical from the outside while being completely different underneath.

A user might see two forms.

An engineer might see two completely different validation rules, API endpoints, permissions, database relationships, error states, and edge cases.

And then we just hear:

“Can't we just copy the existing one?”

Copying something can take five minutes. Making sure the copied version behaves correctly everywhere can take much longer.

This is also where engineers sometimes get blamed for “overcomplicating” something.

But we're not trying to turn a simple button into a distributed system.

We're trying to avoid discovering next week that the button we copied quietly broke something else.

Sometimes the feature really is easy.

Sometimes it only looks easy because the difficult parts are hidden behind the screen.

And engineers have a slightly unfortunate habit of knowing where those hidden parts are.

3. “The client definitely won’t change their mind.”

This sentence should probably come with a warning label.

“Don't worry, this is the final requirement.”

There is no such thing as a final requirement.

Okay, that's unfair.

There probably is.

I've just never personally met one.

You finish the implementation. You test it. You deploy it. You finally feel that moment of peace.

Then the message arrives:

“Small feedback from the client…”

The “small feedback” turns out to be:

Move this section.
Add another filter.
Change how the data is calculated.
Make it work on mobile.
Add an export button.
Also, can we make it available to admins only?
And the client wants the old behavior back.

At this point, the engineer is staring at the screen wondering whether “final requirement” was ever a real concept or just something PMs say to help everyone sleep at night.

Of course, requirements can change. That's normal in software development.

The frustrating part is pretending they won't.

I'd rather hear:

“This is what the client wants right now, but there may be changes after they see it.”

Perfect.

Now I know what I'm dealing with.

No false promises. No magical 15-minute estimates. No emotional damage when the “final” version becomes version 2.7.

And honestly, that's probably the biggest thing engineers want from PMs:

Just tell us what you know, what you don't know, and what might change.

We can work with that.

4. “We don't need to worry about edge cases yet.”

This sentence sounds reasonable until the edge case becomes the thing the customer is experiencing.

You build the feature for the normal situation.

A user enters a valid email. The API returns the expected data. The user has the correct permissions. The database contains exactly what everyone expected it to contain.

Great.

Then someone enters an empty value. Or a name with 200 characters. Or clicks the button twice. Or loses their internet connection at exactly the wrong moment. Or somehow manages to have an account created in 2018 with a data structure that nobody has seen since the dinosaurs walked the Earth.

And 😢

“We should probably handle that.”

Yes.

We probably should.

This is one of those conversations where PMs and engineers can have very different ideas about what “done” means.

I'm not saying every tiny feature needs six days of testing and a 40-page technical specification.

There has to be some balance.

But “we'll deal with edge cases later” has a funny habit of turning into “why did production just explode?”

And the answer is...

Because later arrived.

5. “We don't need a ticket for this. I'll remember it.”

No. You won't. I won't. Nobody will.

We're developers. We already have 37 tabs open because we were afraid we'd forget something.

Please make the ticket.

The request might sound tiny:

“Can you also change the error message?”

Sure.

Then someone mentions it during a meeting.

And it gets mentioned again in Slack.

And someone says they'll add it to the ticket.

But days later, everyone remembers that there was something about an error message, but nobody remembers exactly what it was supposed to say.

And somehow I'm looking at a Slack conversation from Tuesday trying to reconstruct a requirement from four messages and a thumbs-up emoji.

A ticket doesn't need to be a novel.

Even something like:

“Change the login error message from X to Y.”

is enough.

It gives everyone one place to check.

It also protects engineers from the classic:

“But we talked about this!”

Tickets aren't just for project managers.

They're useful for engineers because they give us a written record of what we're actually supposed to build.

And if the requirement changes later, great.

Update the ticket.

Now we have history, and future engineers will thank us.

6. “It's urgent.”

The word urgent is possibly the most overused word in software development.

Everything is urgent.

At some point, if everything is urgent, nothing is.

The problem isn't that PMs have urgent requests. Of course they do. Production issues happen. Customers have deadlines. Business priorities change.

The problem is when every request arrives with the same level of emergency.

Because engineers don't work in a magical universe where we can put our current task on pause without consequences.

If I'm halfway through a feature and you give me an urgent request, something has to move.

Maybe the original feature moves.

Maybe the urgent request moves.

Maybe the deadline moves.

There is always a cost somewhere.

And this is where a simple question can save us confusion:

“Okay, what should I pause to work on this?”

If the answer is:

“Pause the dashboard and fix this first.”

Cool. Now I know what matters.

But if the answer is:

“Don't pause anything. Just do this too.”

Then we have discovered that the request isn't actually a priority.

It's a request for additional hours disguised as a priority.

And engineers have already received enough magical powers in our job description.

Please don't add time manipulation to the list.

7. “This will be the last change.”

“Just one last change.”

Every engineer knows this sentence.

You make the requested change. You send it for review.

Then:

“Looks great! Just one tiny thing…”

You fix the tiny thing.

Then:

“Actually, the client had one more idea.”

You fix that too.

Then:

“Can we also…”

At this point, you stop reading the message and start preparing yourself emotionally.

The funny thing is that I don't even think PMs say this because they're trying to annoy engineers.

Sometimes the client really does send one more change.

Sometimes the PM genuinely thinks it's the final one.

And sometimes the client has apparently discovered a new feature while looking at the old feature for the first time.

That's normal.

People understand software differently once they can see and use it.

I'm not against changes. I'm against pretending that changes don't have a cost.

If we're adding another requirement, that's fine. Just tell me.

If it adds another day, tell me.

If it changes the original scope, tell me.

I'll probably complain for approximately 45 seconds and then start coding.

So, do PMs actually lie to engineers?

Probably not as much as this article makes it sound.

Most of these “lies” aren't really lies.

They're usually a combination of optimistic estimates, incomplete information, client pressure, changing requirements, and two people looking at the same feature from completely different angles.

And that's probably where a lot of the tension between product managers and software engineers comes from.

PMs are often thinking about customers, deadlines, business requirements, priorities, and expectations.

Engineers are thinking about architecture, dependencies, bugs, testing, technical debt, edge cases, and whether touching one innocent-looking function will somehow wake up three other systems.

Neither side gets the complete picture alone.

That's why I think the best PM-engineer relationship isn't built on pretending everything is easy.

It's built on being able to say:

“I don't know.”

“I don't know how long this will take.”

“I don't know whether the client will change it.”

“I don't know if this affects another feature.”

“I need to ask the engineer.”

Those sentences are completely fine.

Actually, they're useful.

Because the fastest way to make an engineer nervous isn't telling them that something is complicated.

It's telling them:

“Don't worry. It's super easy.” 😂

Your turn

What is the funniest or most suspicious sentence a PM has ever told you?

💬 Drop it in the comments.

And PMs, you're absolutely welcome to defend yourselves 😂

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

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

DEV Community: Hadil Ben Abdallah

I Removed Passwords From My App. Here’s What the Login Flow Looks Like Now

TL;DR

Passwords Were Only the Beginning of the Problem

How Passwordless Authentication Works

Passkeys: Prove Your Identity Without Typing a Password

Magic Links: A Different Way to Skip Passwords

Where Does Keycloak Fit Into the Flow?

Passkeys vs. Passwords vs. MFA: What Changes?

Where Skycloak Comes In

Using Skycloak for Passwordless Authentication With Passkeys

What the Skycloak Passkeys Recipe Configures

Prepare Your Development Environment

Connect the Application Through OIDC

Configure and Test Passkey Authentication

What Developers Still Need to Handle

Edge Cases to Test Before Shipping

Frequently Asked Questions

What is passwordless authentication?

How do passkeys work without a password?

Are passkeys the same as MFA?

What happens if a user loses their passkey?

Is passwordless authentication more secure than passwords?

Final Thoughts

Hadil Ben AbdallahFollow

Your Marketing Site Has 40 Scripts. Which Ones Are Actually Worth Keeping?

TL;DR

Why Too Many Third-Party Scripts Become a Problem

How to Find Every Third-Party Script on Your Website

Start with the browser

Check your tag manager

Check your CMS and plugins

Measure the Cost of Third-Party Scripts

Look for Duplicate Functionality

Do Third-Party Scripts Need to Load on Every Page?

A Script Audit Should End With a Decision

Consent Changes the Loading Strategy

The Goal Isn't Fewer Scripts. It's a Website You Can Explain.

Frequently Asked Questions

How many third-party scripts should a marketing website have?

Do third-party scripts slow down a website?

Should I remove Google Tag Manager to improve website performance?

Should every marketing script load on every page?

How often should I audit third-party scripts?

Final Thoughts

Hadil Ben AbdallahFollow

You’re a Real Python Developer Only If...

🤏🏻 You forgot one tiny indentation

📦 You installed a package and broke everything

🧪 You created a virtual environment...

🐼 You imported pandas just to open a CSV file

🤔 You wrote a list comprehension and felt unstoppable

🐞 You used print() to debug everything

📓 Your Jupyter notebook became a crime scene

🧠 You discovered that is and == are not the same thing

🐛 You caught a bug caused by None

🔄 You turned a simple script into a reusable module

📚 You read the documentation and still had questions

🧹 You ran a formatter and discovered how much you needed it

🚀 You wrote a Python script that worked locally...

🧩 You used try/except because you didn't want to see the error

💛 You started learning Python because it looked simple

☕ You said, "I'll automate this little task"

🐍 The Python Developer Paradox

💬 Your Turn!

Hadil Ben AbdallahFollow

5 Best AI Gateways

TL;DR

What Is an AI Gateway (And Why Does It Matter in Production)?

How We Evaluated These AI Gateways

Quick Comparison: The 5 Best AI Gateways

1. Bifrost (by Maxim AI)

Production Performance and Reliability

Routing, Governance, and AI Traffic Control

Deployment and Enterprise Control

Pricing

Best for

2. Cloudflare AI Gateway

Pricing

Best for

🐞 You used `print()` to debug everything

🧠 You discovered that `is` and `==` are not the same thing

🐛 You caught a bug caused by `None`

🧩 You used `try/except` because you didn't want to see the error