Vibe coding won. That's not the interesting part.

Andrej Karpathy coined the term "vibe coding" in early 2025. By the end of that year, Collins Dictionary named it Word of the Year. By February 2026, the debate is over. Everybody vibe codes.

The numbers tell the story. 92% of US developers use AI coding tools daily. 82% globally on a weekly basis. GitHub reports 46% of all new code is now AI-generated. Among Y Combinator's Winter 2025 cohort, 21% of startups have codebases that are 91% or more AI-generated. Google says a quarter of their code is already AI-assisted.

For anyone still asking "what is vibe coding," the definition is simple. You describe what you want in natural language. AI generates the code. You accept it without fully reviewing every line. You iterate by prompting, not by typing code. Andrej Karpathy put it this way: "You fully give in to the vibes, embrace exponentials, and forget that the code even exists."

The adoption war is over. AI won. What's interesting now is what that victory actually costs.

Vibe coding adoption curve showing 92% US developer usage in 2026 with AI-generated code share rising from 10% in 2023 to 46% in 2026.

The numbers contradict each other

Here's where it gets uncomfortable.

The same industry that reports 92% AI tool adoption also reports this:

• CodeRabbit analyzed 470 open-source GitHub pull requests. AI co-authored code contained 1.7x more major issues than human-written code.

• 45% of AI-generated code samples contain OWASP Top-10 vulnerabilities.

• Security firm Tenzai tested five popular vibe coding tools (Claude Code, OpenAI Codex, Cursor, Replit, Devin). They built 15 identical apps. Found 69 vulnerabilities. Six were critical.

• Code churn is up 41%. Code duplication increased 4x. Refactoring collapsed from 25% of changed lines in 2021 to under 10% by 2024, according to GitClear.

• 63% of developers have spent more time debugging AI-generated code than writing the original code themselves would have taken.

And the trust data tells its own story. Developer favorability toward AI tools collapsed from 77% in 2023 to 60% in 2026. Only 33% trust AI code accuracy, down from 43% in 2024.

Usage keeps climbing anyway.

The industry is hooked on something it doesn't trust. That's the state of vibe coding in February 2026.

Bar chart comparing vibe coding adoption rates versus developer trust scores from 2023 to 2026 showing diverging trends.

Three disasters that shaped the conversation

These aren't hypotheticals. They happened. They're documented. And they follow the same pattern: vibe coding builds the product, then the product collapses under real-world pressure.

The Enrichlead collapse

An indie developer built an entire SaaS product with Cursor. Zero hand-written code. He celebrated on social media. It worked. Users signed up.

Within weeks: "Random things are happening, maxed out usage on API keys, people bypassing the subscription, creating random shit on db."

He couldn't debug it. He didn't write it. Cursor kept breaking other parts of the code when he tried to fix things. The product was shut down permanently.

The lesson isn't that vibe coding can't build a product. It clearly can. The lesson is that vibe coding can't maintain one. Not without someone who understands the code well enough to fix it when real users start doing real things.

The Lovable exposure

Lovable, a popular vibe coding platform, generated apps for thousands of users in 2025. Security researchers found that 170 out of 1,645 Lovable-created web applications had vulnerabilities that would allow personal information to be accessed by anyone.

That's more than 10% of apps shipping with user data exposed.

The tool worked. The code it wrote didn't protect anyone's data.

The honeypot that got hacked

This one is almost poetic. Security firm Intruder used AI to generate a honeypot, a tool specifically designed to capture attacker traffic. During testing, attackers exploited a vulnerability in the AI-generated honeypot itself.

The AI had added logic to extract client-supplied IP headers and treat them as trusted data. Headers are user-controllable. An attacker injected a payload and gained partial control of program execution.

A security team. Building a security tool. Using AI to write the code. Missed a basic trust violation because the AI put it there and nobody caught it in review.

Expertise doesn't protect you from AI-generated blind spots. That's the uncomfortable truth.

The open source crisis nobody expected

This section matters because it reveals a second-order effect of vibe coding that nobody predicted.

Daniel Stenberg shut down cURL's six-year bug bounty program in January 2026. Not because of budget. Because AI-generated vulnerability reports were flooding it with noise. Real security researchers couldn't be heard over the slop.

Mitchell Hashimoto banned AI-generated code from Ghostty. Steve Ruiz went further. tldraw now auto-closes all external pull requests. Not just AI-generated ones. All of them. Because maintainers can't distinguish real contributions from AI-generated noise fast enough.

Tailwind CSS saw downloads climb while documentation traffic fell 40% and revenue dropped 80%. Developers are using the framework. They're just not reading the docs. AI reads them instead, sometimes incorrectly, generating code that works until it doesn't.

RedMonk analyst Kate Holterhoff calls it "AI Slopageddon."

The pattern: AI generates code fast. It also generates contributions fast. Pull requests. Bug reports. Documentation fixes. The volume is so high and the quality so inconsistent that maintainers can't keep up. So they shut the door entirely.

Vibe coding isn't just a developer productivity story. It's reshaping the economics of open source. The infrastructure that modern software depends on is maintained by humans who are drowning in AI-generated noise.

The METR paradox

This is the single most counterintuitive finding about vibe coding in 2026. It deserves its own section.

METR ran a randomized controlled trial with experienced open-source developers. Real engineers. Real codebases. Real tasks.

The results:

• Developers using AI tools were 19% slower at completing tasks

• Before the study, they predicted they'd be 24% faster

• After the study, they still believed they'd been 20% faster

Read that again. They were measurably slower. And they didn't know it. Even after the experiment, they believed AI had helped them.

This isn't a one-off finding. Broader survey data shows 95% of developers report feeling productive while measurably producing lower-quality code. 74% report productivity increases. The subjective experience and the objective measurement diverge.

The explanation is probably straightforward. AI tools make the easy parts faster (scaffolding, boilerplate, repetitive patterns). But they make the hard parts harder (debugging unfamiliar code, understanding hidden assumptions, catching subtle logic errors). The time saved on the easy parts feels significant. The time lost on the hard parts is invisible until something breaks.

This is the core tension of vibe coding in 2026. It feels fast. The data says it's complicated.

What actually works

Not everything is broken. An honest assessment has to include what vibe coding genuinely excels at.

Prototyping and MVPs. Median task completion time drops 20-45% for greenfield features. If you're validating an idea and the cost of bugs is low, vibe coding is transformative. Build the prototype in a weekend. Throw it away and build the real thing properly if it works.

Internal tools. IBM reports 60% reduction in development time for enterprise internal apps using AI-assisted coding. Internal tools have a higher tolerance for bugs and a lower bar for security. This is vibe coding's sweet spot.

Boilerplate and scaffolding. Nobody misses writing CRUD endpoints by hand. AI handles repetitive, well-understood patterns reliably.

Senior developers, specifically. Engineers with 10+ years of experience report 81% productivity gains. They know what good code looks like. They can spot when AI generates something wrong. Junior developers show mixed results because they lack the judgment to evaluate what AI produces.

The pattern is clear. Vibe coding works when the cost of failure is low and you have someone who can evaluate the output. It breaks when the code needs to be secure, maintainable, or correct at scale.

The 15 vibe coding tools that matter in 2026

The vibe coding tools landscape splits into two categories: AI code editors that augment developers working in real codebases, and AI app builders that generate entire applications from prompts. Most serious teams use one from each category.

AI code editors

These require programming knowledge. They make experienced developers faster.

AI app builders

These generate full applications from natural language. Programming knowledge optional.

Emerging platforms

Newer tools gaining traction but not yet at the scale of the above.

The best teams in 2026 use two or three tools in combination. A common pattern: prototype in Lovable or Bolt, then move to Cursor or Claude Code for production. The tool matters less than knowing when to switch.

The gap nobody's closing

Development went AI-native. Testing mostly didn't.

Teams ship 3-5x faster with vibe coding. Their test suites are still written by hand, maintained by hand, broken by hand. The math doesn't work.

41% of developers admit to pushing AI-generated code to production without full review. Companies are finding hardcoded API keys, disabled security checks, and logic bombs in code that passed CI because the test suite was written for a human-speed development process.

The question isn't "should we vibe code?" That's decided. Everyone does. The question is: how do you test at the speed of vibe coding?

Three approaches exist today:

Manual QA. Doesn't scale. Your team ships in hours. Manual testing takes days. The backlog grows until you skip it entirely or ship without coverage.

Write more tests by hand. Defeats the purpose. You automated coding but not testing. Your senior engineers spend 10-15 hours per week maintaining test suites they didn't write for code they didn't write. That's \(39K-\)58K per affected engineer annually in hidden cost. (We broke this down in detail: The 2026 Quality Tax.)

AI-native testing. Match the development approach with the testing approach. If code is generated from natural language, tests should be too. If code self-generates, tests should self-heal.

For teams that vibe code without dedicated QA, Bug0 applies the same AI-first philosophy to testing. You describe what matters in plain English. AI generates and maintains the tests. No selectors to maintain. No flaky test debugging at 2am.

The irony of 2026: we automated code generation but left testing in 2019.

What 2026 looks like from here

Vibe coding adoption will keep climbing. The quality gap will too. These aren't opposing trends. They're the same trend viewed from different angles.

The differentiator this year won't be whether your team uses AI tools. Every team does. The differentiator is whether you test what AI produces. Whether you catch the hardcoded API key before your users do. Whether your AI-generated login flow handles edge cases the AI didn't think of.

The best teams will treat vibe coding the way they treat any powerful tool. Use it aggressively. Verify ruthlessly. Don't confuse "it runs" with "it works."

"Vibe coding" as a term might fade. The practice won't. It's just how software gets built now. The companies that survive the quality gap will be the ones that figured out testing before their competitors' vibe-coded apps started breaking in production.

FAQs

What is vibe coding?

Vibe coding is a software development practice where you describe what you want to an AI in natural language and the AI generates the code. The term was coined by AI researcher Andrej Karpathy in early 2025 and named Collins Dictionary Word of the Year. The key distinction: vibe coders accept AI-generated code without fully reviewing every line, relying on prompts and iteration rather than line-by-line coding.

What does vibe coding mean?

The term comes from "vibes," describing the shift from precise programming instructions to conversational intent. You describe the feel of what you want. The AI handles the implementation. Karpathy's original framing: "You fully give in to the vibes, embrace exponentials, and forget that the code even exists." It captures a fundamental change in the developer's role, from writing code to directing AI.

What are the best vibe coding tools in 2026?

The top vibe coding tools in 2026 span two categories. AI-powered code editors include Cursor (\(20/mo), Windsurf (\)15/mo), and Claude Code. Full-stack app generators include Bolt (\(29/mo), Lovable (\)25/mo), Replit, and v0 by Vercel. Most experienced teams use two to three tools in combination: a generator for prototyping and an AI IDE for production code.

Is vibe coding safe for production?

Not without guardrails. Research shows 45% of AI-generated code contains security vulnerabilities. Tenzai found 69 vulnerabilities across 15 test apps built with popular vibe coding tools. Vibe coding works well for prototypes, internal tools, and MVPs. For production applications, you need code review, automated security scanning, and comprehensive testing. The code that "just works" in a demo often fails under real-world conditions.

How do you test vibe-coded applications?

Three paths. Manual QA doesn't scale with AI development speed. Writing tests by hand defeats the purpose of vibe coding. AI-native testing tools like Bug0 match the development approach: describe critical flows in plain English, AI generates and maintains the tests. The key principle: if your code generation is AI-native, your testing should be too.

Will vibe coding replace software engineers?

No. It amplifies them. Senior developers (10+ years) report 81% productivity gains because they can evaluate what AI produces. Architecture decisions, security reviews, debugging, and system design still require human judgment. The role is shifting from writing code to reviewing, directing, and architecting AI-generated systems. The engineers who thrive in 2026 are the ones who understand code well enough to catch what AI gets wrong.

The velocity trap

Most engineering teams figured out the coding part. Tools like Cursor and v0 turned "describe what you want" into "here's the working code." A single engineer can scaffold a full-stack application in an afternoon. Features that took a sprint take a session.

But here's what caught everyone off guard: the bottleneck didn't disappear. It just moved downstream. Writing code isn't the hard part anymore. Knowing whether the code actually works is.

If you generate code 10x faster, you generate bugs 10x faster. Your CI pipeline doesn't care that Cursor wrote the component in 30 seconds. It cares that the login flow breaks because the AI renamed a CSS class without telling you. Your users don't care that v0 generated a beautiful dashboard. They care that the checkout button doesn't respond on mobile.

You cannot solve 2026 speed with 2020 testing. Manual QA, hand-written Selenium scripts, and even basic Playwright suites maintained by humans can't keep pace with agentic workflows that produce dozens of PRs per day.

And here's what the "AI does everything" crowd gets wrong. We're past that hype. The real workflow is human-in-the-loop: the AI proposes, the engineer evaluates. Cursor generates a PR plan, you review it before execution. Bug0 generates a test suite, you audit the assertions before they gate production. The industry calls this "evals," and it's the difference between teams that ship confidently and teams that ship recklessly.

The other shift: multi-agent orchestration. One agent writes the code. Another agent automatically triggers the test. A third surfaces the results. Tools like GitHub Copilot Workspace and OpenAI's Codex started this pattern. The AI-native stack turns it into a pipeline where agents hand off to agents, and the human supervises the chain.

Here's what that chain looks like in practice:

Each step triggers the next. The human reviews at steps 2 and 3. The rest runs automatically. In theory. In practice, you'll spend a non-trivial amount of time on glue code: GitHub Actions configs, webhook integrations, environment variable wrangling. The tools don't natively talk to each other yet. You're the orchestration layer until someone builds the meta-agent that connects them.

You need a fully AI-native lifecycle. Every stage, from design to observability, powered by generative AI tools purpose-built for that stage. With humans reviewing the seams.

We've audited the landscape to find the best generative AI tools for every stage of the SDLC. Five stages. Five tools. One stack that gives a 5-person team the output of 50.

Stage 1: Design (the "no-Figma" era)

The tool: v0 by Vercel

The designer-to-developer handoff used to be a weeks-long process. Figma files. Redlines. "Can you move this 2px to the left?" conversations. Design reviews that blocked sprint planning.

v0 collapsed that entire workflow into a prompt.

You type: "Dashboard with dark mode, sidebar navigation, and Shadcn UI components." You get React code. Not a mockup. Not a wireframe. Production-ready JSX with Tailwind classes and proper component structure. You paste it into your project and it works.

v0 goes further now. Design Mode lets you edit by clicking, not just prompting. Select a component, drag to reposition, change colors visually, and the code updates underneath. It's Figma-speed iteration with code-first output. For engineers who think spatially, this changes the workflow from "describe what I want" to "show what I want."

The caveat: v0 is excellent at generating standard UI patterns. Ask for a dashboard, a settings page, a landing section, and you get clean code. Ask for something highly custom, an interactive data visualization or a non-standard navigation pattern, and you'll spend more time wrestling with the output than building it yourself. Know when to prompt and when to code.

This isn't "AI-assisted design." It's design-as-code. The prompt is the spec. The output is the implementation. There's no handoff because there's nothing to hand off.

Design-to-code vs. full-stack prompting

v0 excels at UI. But "text-to-app" now means more than components. Tools like Bolt.new and Replit Agent handle the full stack in one prompt: database schema, authentication, server logic, and UI. You describe the product. You get a deployable app with a Postgres database, OAuth, and API routes.

The distinction matters. v0 is design-to-code: the best tool for crafting specific UI components and pages with pixel-level control. Bolt.new and Replit Agent are full-stack prompting: better for prototyping entire applications from scratch. Most production teams use v0 for the interface layer and Cursor for the full-stack logic. But if you're a solo founder validating an idea, full-stack prompting tools get you to a working prototype in hours, not days.

Lovable sits between these approaches. Describe the product. Get a deployable app with a clean UI. It's opinionated about design in a way the general-purpose tools aren't.

The handoff is dead, but the pressure is real

When design becomes instant, the downstream pressure on development and testing increases exponentially. You're not waiting two weeks for mockups anymore. You're generating UI faster than your team can verify it works. The designer bottleneck is gone. The QA bottleneck just got worse.

Stage 2: Development (the agentic IDE)

The tool: Cursor (Composer Mode)

The shift here is from copilot to agent.

GitHub Copilot (2022-era) was autocomplete. It finished your line. Cursor's Composer Mode is a collaborator. It reads your entire codebase, understands the architecture, and makes multi-file edits in a single prompt. You don't type functions. You tab through entire features.

Tell Composer: "Add Stripe subscription billing with a pricing page, webhook handler, and database migration." It creates the pricing component, writes the API route, sets up the webhook endpoint, generates the Prisma schema change, and updates the navigation. Across six files. In one shot.

This only works because of how Cursor indexes your project. It builds a semantic map of your entire codebase, your documentation, your .cursorrules, and your git history, then retrieves the relevant context for each edit. Two years ago, you had to paste individual files and pray the model understood the architecture. Now the tooling retrieves the right context automatically, and million-token context windows mean the model can hold enough of your project in memory to make coherent multi-file changes.

This is what agentic workflows look like in practice. The AI isn't waiting for you to guide it line by line. It plans the work, executes across files, and presents the result.

Professional teams don't use Composer raw. They use .cursorrules files, project-level instructions that constrain the AI's behavior. These context rules are the difference between an agent that respects your architecture and one that rewrites it on a whim.

A real .cursorrules looks something like this:

- Never rename existing CSS classes or data-testid attributes.
- Always use the component library in src/components/ui/. Do not create new base components.
- Follow the auth pattern in src/lib/auth.ts for all protected routes.
- Use TypeScript interfaces, never 'any'. If a component exceeds 100 lines, suggest a refactor.

Three minutes to write. Saves hours of "why did the AI restructure my entire auth flow?"

The hidden tax of confident AI

Cursor is confident. Sometimes too confident.

It refactors CSS classes without mentioning it. It renames variables across files because it "improved readability." It imports a library that doesn't exist in your node_modules because it hallucinated the package name from training data. It restructures a component hierarchy because its architecture opinion differed from yours. And it does all of this silently, buried in a 200-line diff you might not fully review.

When Cursor changes that submit-btn class to btn-primary at 2am during a coding session, every test that references the old selector breaks. Every visual regression baseline shifts. Your CI goes red, and nobody knows why until someone diffs every file the AI touched.

Shadow code: the maintenance debt you didn't sign up for

Here's the deeper problem. If your engineer didn't write those 200 lines, they may not understand them well enough to maintain them. AI-generated code that nobody fully comprehends becomes shadow code. It works today. It breaks tomorrow. And when it breaks, debugging takes 3x longer because the developer is reverse-engineering the AI's decisions instead of their own.

Tools like Sourcegraph Cody help with context retrieval, letting engineers ask "why was this code written this way?" across the full codebase. AI-augmented code review, where a second AI model reviews the first model's output, is becoming standard practice.

The practical defense: AI-proof your documentation. Every module gets a DECISIONS.md that explains why the code is structured this way, not just what it does. When Cursor generates code, it reads these files and follows established patterns. When a new engineer debugs shadow code six months later, they have the reasoning, not just the implementation. Teams that skip this step pay for it in debugging hours. Teams that adopt it consistently report faster onboarding, especially in codebases where most code was AI-generated.

But documentation alone doesn't eliminate the core risk: code moving faster than human comprehension.

This is the core tension of agentic development. The speed is real. The risk is also real. You need something equally agentic on the verification side.

You need an agent to verify what the agent built.

Stage 3: Testing (the quality layer)

This is where most AI-native stacks fall apart.

Teams adopt v0 for design. They adopt Cursor for development. Then they test with the same Playwright scripts they wrote by hand in 2023. Or worse, they skip testing and hope staging catches the bugs.

The math doesn't work. If Cursor generates 15 PRs a day, and each PR requires 30 minutes of manual test verification, you need a full-time engineer just to keep up with testing. And that engineer will still miss the visual regression Cursor introduced by silently changing a Tailwind class.

You can't test at the speed of AI with manual scripts. If you use Cursor to build, you need an agent to verify.

This is where generative AI in testing stops being a nice-to-have and becomes the part of your stack that everything else depends on.

In ML, "evals" verify that a model's output matches intent. Bug0 applies the same principle to the UI. It's the eval layer for your frontend: verifying that what the agent built visually matches what the engineer intended. Not string-matching HTML. Not asserting DOM structure. Evaluating whether the user experience works.

The solution: Bug0 Studio

Think of Bug0 Studio as the Cursor for QA. It's an AI-native end-to-end testing platform that uses AI to generate, run, and heal Playwright-based tests using the same agentic approach Cursor applies to development.

One detail that matters more than most teams realize:

Bug0 generates standard Playwright code. Not a proprietary DSL. Not a custom format you can't migrate away from. Standard .spec.ts files that run in your CI with npx playwright test. If you leave Bug0, you keep every test. No export process. No vendor lock-in.

This is the question every CTO should ask before signing an AI testing contract: "If we cancel, do we keep our tests?" With Bug0, yes. With most competitors, no.

Feature 1: Video-first engineering (the killer workflow)

Record a 30-second Loom of the happy path. Upload it to Bug0. That's it.

The AI watches the recording frame by frame. It identifies every click, every form input, every navigation event. It understands the intent behind each action, not just the coordinates. Then it generates a complete Playwright test suite.

Not a rough draft you spend an hour cleaning up. A working test that passes on the first run.

Other tools claim video-to-code. Most produce output that needs 30-60 minutes of manual editing before it passes. Bug0's vision models have been trained specifically on browser interactions, so the generated tests match what actually happened in the recording. Timing, scroll behavior, hover states, dynamic content. All captured. One honest limitation: vision models still struggle with ultra-fast animations and heavy CSS transitions. If your flow relies on a 150ms slide-in drawer that changes DOM state mid-animation, expect to hand-tune that step. The model sees the before and after, but the in-between gets noisy.

The workflow: Record. Upload. Run. Done.

Feature 2: Self-healing (and where it breaks)

Connect this back to Stage 2.

Cursor renames your Submit button class from submit-btn to btn-primary. Your hand-written Selenium script breaks. Your Cypress test referencing [data-testid="submit-btn"] fails. Your CI goes red. A developer spends 45 minutes debugging what changed.

Bug0 sees the button is still there visually. Same position. Same text. Same behavior. It heals the test automatically. The selector updates. The test passes on the next run. No alerts. No manual fixes. No 45-minute debugging sessions.

A team we work with shipped a redesign of their settings page at 11pm on a Thursday. Cursor had rewritten 14 component files. The old class names were gone. Their hand-maintained Playwright suite would have produced 23 failures and a very long Friday morning. Bug0's self-healing caught all 23 selector changes, updated them, and the scheduled 6am test run passed clean. Nobody got paged. Nobody debugged anything. The engineer who shipped the redesign found out the tests healed when they checked the dashboard Monday morning.

To be clear: self-healing doesn't handle everything. If Cursor removes a feature entirely or changes business logic (not just selectors), Bug0 flags it as a real failure, not something to auto-fix. The healing works on structural changes: renamed classes, moved elements, updated component hierarchies. For logic changes, you still get a failure report with video, AI analysis, and console logs. You still have to look at it. The point is that 80% of the test breakage from agentic development is structural, and that's the 80% you shouldn't be debugging manually.

Feature 3: The managed option

Some teams don't want to operate testing tools at all. They want outcomes.

Bug0 Managed pairs AI-generated tests with forward-deployed QA engineers who maintain your entire test suite. You define what "working" means. They make sure it stays working. Starting at $2,500/month with flat billing and no surprises.

For decision-makers evaluating build vs. buy: this is the "buy" option that doesn't lock you into proprietary formats. Every test is standard Playwright. You own the code.

Quick look: Top generative AI testing tools (2026)

If you're evaluating ai tools for testing, here's where the landscape stands. These are the generative AI testing tools that matter for production use, not demos.

Bug0 occupies the gap between "write all your tests by hand" and "pay someone else to handle everything." You get AI-generated Playwright tests with self-healing and video-to-code, at a price point that doesn't require enterprise procurement approval.

The regulatory reality check

The EU AI Act is in phased enforcement, with prohibited AI practices and GPAI governance rules already active and the majority of high-risk obligations hitting in August 2026. Global regulations around AI-generated code, data handling, and automated decision-making are no longer theoretical. If your AI testing tool processes production data or user recordings, you need to know: where does that data go? Who trains on it? Is the tool SOC 2 compliant?

Enterprise buyers now ask a question that didn't exist two years ago:

Where are our agentic traces stored? Every time Cursor edits a file, Bug0 runs a test, or Sentry analyzes an error, that interaction generates a log. Those logs contain code, user flows, and error context. If your team is in the EU and your agentic traces live on a US server without a Data Processing Agreement, you have a compliance problem.

Data residency for agentic traces is the new "where is our data stored?" It applies to every tool in the stack, not just your database.

Every tool in this stack should have a clear answer. Cursor offers privacy mode that prevents code from being used for training. Bug0 runs tests on isolated infrastructure with SOC 2 compliance. Vercel's data residency controls satisfy GDPR requirements. PostHog offers self-hosted deployments for teams that can't send telemetry to third-party servers.

"Does it have a privacy mode?" is now as important as "Does it work?"

Stage 4: Deployment and ops (the invisible infra)

The tool: Vercel

Deployment used to be a ceremony. Merge to main. Trigger the pipeline. Wait for builds. Check staging. Approve production. Hope nothing breaks.

Vercel turned deployment into a side effect of pushing code. Every PR gets a preview URL. Every merge to main deploys to production. The infrastructure disappears.

In the AI-native stack, this matters because of volume. When Cursor generates 15 PRs a day and Bug0 validates them automatically, you need deployment infrastructure that doesn't bottleneck the flow. Vercel handles this with preview deployments for every branch, automatic rollbacks, and edge functions that scale without configuration.

The bigger shift: Infrastructure as Code is becoming Infrastructure from Intent. Tools like Spacelift and Vercel's own configuration layer let you describe infrastructure goals and let the platform figure out the implementation. "I need a globally distributed API with sub-100ms latency" instead of writing Terraform files.

For the AI-native stack, deployment is the stage that should require the least human attention. Push code. Tests pass. Deploy happens. Move on.

Stage 5: Observability (the feedback loop)

The tool: PostHog or Sentry

You shipped fast. The tests passed. The deploy succeeded. Now what?

Observability closes the loop. It tells you what's happening in production after the tests have run. Today, observability tools are getting the same AI treatment as every other stage.

PostHog's Max AI is adding session replay summarization. Instead of watching a 12-minute recording of a user struggling with your checkout flow, you get a paragraph: "User attempted to apply a discount code three times. The input field cleared on each attempt due to a re-render triggered by the cart total component. User abandoned checkout after 4 minutes."

Sentry's error grouping uses AI to cluster related errors and explain root causes. Instead of a stack trace that points to line 247 of a minified bundle, you get: "This TypeError occurs when the user's session token expires mid-checkout. The refresh logic fails silently because the error boundary catches the 401 but doesn't retry the original request."

The addition that closes the loop entirely: Sentry now suggests the fix directly and can open a PR in your repository. A production error triggers an AI analysis, generates a patch, and creates a pull request, routing it straight back to Stage 2. The engineer reviews the suggested fix in Cursor, Bug0 runs the regression suite against the PR, and the fix deploys through Vercel. From error to fix to production without a single Jira ticket.

Why this stage completes the stack

Observability is what turns the AI-native SDLC from a linear pipeline into a loop. Production errors feed back into Bug0 as new test cases. User behavior captured by PostHog becomes the next Loom recording you upload for test generation. Sentry alerts map directly to regression tests and, increasingly, to automated fix PRs.

The stack isn't five separate tools. It's a cycle: Design -> Build -> Test -> Deploy -> Observe -> Fix -> Test -> Deploy. Each stage feeds the next. Each AI tool makes the others more effective. And the human stays in the loop at every seam, reviewing the AI's proposals before they hit production.

The 1-person unicorn

Here's the full stack.

With this stack, a single engineer has the output of a pre-2024 product team. Not because they work harder. Because every stage of the lifecycle has an AI agent handling the repetitive work while the human focuses on evaluation and decisions.

v0 proposes design. The engineer reviews it. Cursor proposes implementation. The engineer reviews the diff and checks it against .cursorrules. Bug0 generates verification. The engineer audits the assertions. Vercel deploys. PostHog and Sentry report back. The cycle continues.

Notice the pattern. Every stage is "AI proposes, human evaluates." Not "AI does everything." Not "human does everything." A loop where agents handle volume and humans handle judgment.

This is the 10x engineer, and it's not about typing speed. It's about tool selection and the discipline to stay in the loop.

Start with the hardest part first: fixing the quality bottleneck. The gap between "AI can build it" and "AI can verify it" is where most teams are stuck. Close that gap, and the rest of the stack follows.

Try Bug0 Studio to turn your next screen recording into a test suite.

Your human-in-the-loop checklist

Before every ship, verify the seams:

• [ ] Did you review the Cursor diff, not just the summary?

• [ ] Are your .cursorrules up to date with current architecture decisions?

• [ ] Did you audit Bug0's generated assertions, not just the pass/fail?

• [ ] Does your Vercel preview deployment match staging behavior?

• [ ] Are Sentry's auto-fix PRs reviewed before merge, not auto-merged?

• [ ] Do you know where your agentic traces are stored and who can access them?

The stack handles volume. You handle judgment. This checklist is where the two meet.

FAQs

What is an AI-native SDLC?

An AI-native SDLC is a software development lifecycle where every stage, from design to observability, uses AI tools built specifically for that stage. Not AI-assisted (bolt-on copilots) but AI-native (the tool was designed around AI from day one). v0 doesn't add AI to Figma. It replaces the Figma workflow entirely. Bug0 doesn't add AI to Selenium. It replaces the test-writing workflow entirely.

Is the "1-person unicorn" actually realistic

Mostly realistic for output volume, misleading for everything else. One engineer with this stack can match a traditional team's feature velocity, test coverage, and deploy cadence. But a solo engineer doesn't have anyone to argue with about architecture decisions, catch their blind spots in code review, or tell them the feature they're building isn't what customers want. The stack replaces execution headcount. It doesn't replace the judgment that comes from a team with diverse experience.

What is generative AI in software testing?

Generative AI in software testing means using large language models and vision models to create complete test suites from natural language descriptions, video recordings, or application analysis. The AI generates new tests from scratch, not just autocompleting test code you started. Bug0 Studio is an example: you upload a screen recording, and it generates a full Playwright test suite that runs immediately.

How does agentic testing differ from traditional test automation?

Traditional automation follows a script: click element A, type text B, assert element C. When element A moves or gets renamed, the test breaks. Agentic testing receives a goal ("complete the checkout flow") and figures out the steps dynamically. When the UI changes, the agent finds a new path to the same outcome. It's the difference between turn-by-turn GPS directions and telling someone the destination.

Why do you keep saying testing is the bottleneck? My deploys are fine.

Your deploys might be fine because you're not testing enough. Most teams that "ship fast" with AI tools are actually shipping with less verification than they had in 2023. They've traded slow, thorough testing for fast, minimal testing, and the bugs show up in production instead of CI. The bottleneck isn't visible until you measure how many post-deploy hotfixes you're shipping, how often users hit broken flows, or how many Sentry alerts your team is ignoring.

How much does this full stack cost?

v0 has a free tier, with Pro at \(20/month. Cursor is \)20/month. Bug0 Studio starts at \(250/month. Vercel has a free tier, with Pro at \)20/month. PostHog has a generous free tier. For a solo engineer or small team, the full AI-native stack costs roughly \(300-350/month. Compare that to the \)15K-25K/month a traditional team of designers, developers, QA engineers, and DevOps would cost.

What about security and compliance with AI tools?

Every tool in this stack handles data differently. Ask three questions before adopting any AI tool: Does it offer a privacy mode that prevents your code from being used for model training? Is it SOC 2 compliant? Does it satisfy your data residency requirements (GDPR, EU AI Act)? Cursor, Bug0, and Vercel all offer privacy controls. PostHog offers self-hosted deployment. Don't assume compliance. Verify it.

What is "shadow code" and how do I prevent it?

Shadow code is AI-generated code that works but nobody on your team fully understands. It becomes a maintenance liability when it breaks. Prevent it with three practices: use .cursorrules or similar context files to constrain AI output to your team's patterns. Use AI-augmented code review tools (like Sourcegraph Cody) to help engineers understand generated code. And run agentic tests (Bug0) against every AI-generated PR so that even if the code is opaque, the behavior is verified.

What if I already have a Playwright test suite?

You don't have to start over. Bug0 works alongside existing test suites. Use it to generate new tests from video recordings or natural language while keeping your current tests running. Over time, the self-healing AI tests reduce the maintenance burden on your hand-written suite. Most teams transition gradually, not all at once.

The testing tools you picked last year are already outdated

Selenium is still everywhere. It defined browser automation, and its WebDriver protocol became a W3C standard. Playwright replaced it technically (using CDP instead of WebDriver), but Selenium's patterns and mental models still influence how most teams think about test automation. It's not going away. But the layer on top of raw browser protocols is changing fast.

A year ago, most "AI testing" tools were wrappers around GPT that generated flaky Cypress scripts. You'd spend an hour cleaning up what the AI produced, then another hour debugging why it failed in CI. The value proposition was shaky.

That's shifted. The newer tools use vision models that interpret your UI the way a human tester would. They navigate dynamically instead of following hardcoded selectors. When your team redesigns the settings page, the test finds the new path to the same outcome. Some tools call this agentic testing. Others call it self-healing. The labels vary. The capability is real, when it works.

The problem: most tools still don't work reliably in production CI/CD. They demo well on a clean todo app. They break on your actual product with auth flows, modals, and third-party iframes.

This ranking focuses on what holds up in real pipelines, not what looks good in a 3-minute walkthrough.

Scope note: This list is weighted toward browser-based E2E and visual regression, but includes mobile-native (#9 Maestro) and LLM evaluation (#11 Promptfoo) because no honest 2026 testing list can ignore them. Accessibility-specific tooling and synthetic data generation are addressed in "What's not on this list" below.

How we ranked these tools

Three criteria matter when evaluating generative AI testing tools. Everything else is noise.

Agentic capabilities

Can the tool explore your UI without hardcoded steps? Agentic testing means the AI navigates your application like a real user. It reads the screen, decides where to click, and adapts when the layout changes. Most tools still require you to define every step. A few actually think for themselves.

The difference matters in practice. A traditional test says "click the button with id submit-btn." An agentic test says "submit the form." When your designer renames that button or moves it to a different section, the agentic test still works. The traditional test breaks.

Self-healing tests

Every tool claims self-healing. Few deliver it. Real self-healing means when your #add-to-cart button becomes .btn-cart, the test updates its own selectors and passes on the next run. No alerts. No manual fixes. 90% of tools claim this capability. Maybe 20% handle it reliably in production CI/CD runs.

We evaluated each tool by running identical UI changes against their test suites and measuring how many tests survived without human intervention.

Tech stack and lock-in

Does the tool generate standard Playwright code, or does it lock you into a proprietary format you can never leave? This matters more than most teams realize. If you build 500 tests on a platform that uses a custom DSL, you're stuck. If it generates Playwright under the hood, your tests have value beyond the vendor.

We also factored in pricing model. The industry is moving from flat SaaS subscriptions to usage-based billing (per test minute, per agent hour, per inference call). When comparing tools, we normalized to cost-per-test-run rather than sticker price. A tool at \(250/month that runs 200 tests and a tool at \)2,000/month that runs 5,000 tests have very different unit economics.

#1: Applitools (best for visual AI)

Applitools built visual AI testing before the rest of the industry cared about it. Their "Eyes" technology compares screenshots across builds, browsers, and viewports using AI that understands layout rather than pixel-matching. It catches the visual regressions that functional tests miss entirely.

Starting price: Custom enterprise (typically $10K-50K/year depending on test volume and browser matrix)

Best for: Teams with existing test suites who need visual regression coverage across browsers and devices.

Applitools earns the #1 spot because of maturity and reliability. They've been solving visual testing for years, and their AI has been trained on millions of screenshots. The Ultrafast Grid runs your visual checks across dozens of browser/viewport combinations in seconds, not minutes.

Their root cause analysis feature (shipped originally in 2018, refined since) surfaces the DOM and CSS differences behind visual failures. When a test fails, the platform shows which specific CSS property or DOM change caused the layout shift. That saves your team 15-20 minutes per failure investigation.

What works:

• Visual AI that distinguishes meaningful layout changes from harmless rendering differences

• Ultrafast Grid renders across dozens of browser/viewport/device combinations in parallel

• Integrates with Playwright, Cypress, Selenium, and most existing frameworks

• Root cause analysis that surfaces the specific CSS or DOM change behind visual regressions

What doesn't:

• You still need to write the test scripts yourself. Applitools validates what you see, not what you do

• Enterprise pricing puts it out of reach for startups and small teams

• Setup requires SDK integration into your existing test framework

• No test generation. It's a validation layer, not a creation tool

The verdict: If your users see it, Applitools catches it. But you still need another tool to generate the tests in the first place.

#2: Bug0 Studio (best for agentic E2E and video-to-code)

Bug0 Studio takes three types of input (plain English, video uploads, browser screen recordings) and converts them into Playwright-based test steps. The platform runs tests on its own infrastructure and auto-heals selectors when UI changes break locators.

Starting price: ~$250/month (pay-as-you-go for test minutes, scales with usage)

Best for: Engineering teams that want to generate E2E tests from recordings or natural language without writing Playwright code themselves.

The video-to-code feature is the main differentiator. You record yourself walking through a user flow. The AI produces a Playwright test from the recording. Other tools attempt this, but most generate outputs that need significant manual cleanup before they pass in CI. Bug0's output tends to be closer to runnable on the first attempt, though complex flows with auth tokens or multi-step modals still need editing.

The agentic testing angle is real but worth qualifying. When you write a step like "complete the checkout flow," the AI agent navigates your app dynamically rather than replaying exact coordinates. If the checkout page gets redesigned, the agent looks for the new path. It works well for standard flows (forms, navigation, CRUD operations). It struggles with highly custom UI patterns and edge cases the way any AI agent does.

Self-healing runs during scheduled and manual test runs. When a selector breaks, the AI updates the locator. When it can't fix it, you get an alert. The failure mode is explicit, which matters more than the success rate.

It's a younger platform than most on this list, which cuts both ways. Fast iteration on features, but less battle-testing in large-scale production environments.

What works:

• Video-to-code produces Playwright tests that are close to runnable from screen recordings

• Natural language test creation lowers the barrier for non-Playwright teams

• Failed test reports include video, AI analysis, network logs, and console traces

• GitHub Actions integration for CI/CD

What doesn't:

• Newer platform with a smaller community. Less Stack Overflow coverage when you hit edge cases

• Tests run on Bug0's infrastructure only. You can't export standalone Playwright scripts and can't debug tests locally in VS Code the way you would with standard Playwright

• No self-serve signup yet. Requires a demo call to get started

• Complex auth flows and custom UI components still need manual step editing

The verdict: The strongest option for generating E2E tests from video or natural language. The trade-off is platform maturity and vendor lock-in on test execution. Worth a trial if your team doesn't have Playwright expertise in-house.

#3: QA Wolf (best for service-based hybrid)

QA Wolf isn't a tool. It's a service. You don't write tests. They do.

Starting price: Custom pricing (typically $5K+/month)

Best for: Teams that want test coverage without any involvement in test creation or maintenance.

QA Wolf pairs human QA engineers with AI automation to deliver end-to-end test suites. You get coverage. They handle everything: planning, writing, maintaining, and verifying test results. Their pitch is simple. You build features. They make sure nothing breaks.

The model works well for teams that don't have QA headcount and don't want to hire. You get a dedicated team that writes Playwright tests, maintains them when UI changes, and reviews every failure before it reaches your engineers.

What works:

• Zero maintenance burden on your team. They own the test suite end-to-end

• Human verification of every failure. No false positives reaching your developers

• Strong Playwright expertise. Tests are well-structured and reliable

• Guaranteed coverage timelines

What doesn't:

• Expensive for smaller teams. The service model has higher minimums than self-serve tools

• Less control over test creation. You're trusting their judgment on what to test

• Slower iteration. Requesting new tests means going through their team, not clicking a button

• Dependency on their capacity. Scaling up means waiting for their availability

The verdict: If you'd rather buy results than operate tools, QA Wolf delivers. The trade-off is cost and control. Compare this to Bug0 Studio if you want the same AI-powered testing but with self-serve control at a lower price point.

#4: Testim by Tricentis (best for enterprise stability)

Testim is the tool your procurement team already approved.

Starting price: Custom enterprise (typically $30K-100K+/year depending on seat count and modules licensed)

Best for: Large organizations (500+ employees) with existing Tricentis contracts or compliance-driven QA processes.

Tricentis acquired Testim in early 2022 for $200M and integrated it into their enterprise suite alongside Tosca and qTest. (Testim remains a separately branded, actively maintained product.) The specific feature that matters: Smart Locators. These use a weighted algorithm across multiple element attributes (text content, CSS class, XPath, surrounding DOM structure, visual position) to identify elements. When one attribute changes, the locator falls back to the others. The practical result: fewer false failures from routine UI changes compared to single-attribute selectors.

In practice, Smart Locators handle straightforward UI changes well (button text changes, class renames, minor layout shifts). They struggle when multiple attributes change simultaneously, like during a major redesign. That's the gap between "adaptive locators" and actual agentic testing.

The platform also includes Testim's root cause analysis feature, which groups related test failures and identifies the likely source commit. This works through Git integration, not AI inference. It's useful when 15 tests break from one deploy and you need to know which PR caused it.

What works:

• Smart Locators using weighted multi-attribute element identification reduce false failures

• Root cause analysis links test failures to specific commits via Git integration

• SOC2, SAML SSO, RBAC, audit logs. The full enterprise compliance checklist

• Embedded in the Tricentis ecosystem (Tosca, qTest, NeoLoad) if you already use their stack

What doesn't:

• Tricentis ships major feature updates quarterly. Smaller competitors iterate weekly

• Pricing is five or six figures annually. You're paying for the enterprise wrapper

• Initial setup involves professional services. Expect 4-8 weeks to full deployment

• The AI features (test generation from NLP) were added post-acquisition and feel bolted on compared to the core locator tech

The verdict: If you already use Tricentis products or your security team requires vendor questionnaires with SOC2 Type II attestation, Testim is the path of least resistance. The AI capabilities are real but conservative. You're buying reliability, not innovation.

#5: Qodo (formerly CodiumAI) (best for unit testing and developer workflows)

Qodo (rebranded from CodiumAI in September 2024) solves a different problem than the other tools on this list. It generates unit and integration tests, not browser-based E2E tests.

Starting price: Free tier (75 credits/month). Teams at $30/user/month.

Best for: Individual developers who want AI-generated unit tests inside their IDE.

Qodo Gen (formerly Codiumate) analyzes your code and generates test cases that cover edge cases, boundary conditions, and error paths. It works inside VS Code and JetBrains IDEs, generating tests as you write code. The AI understands your function signatures, dependencies, and logic flow to produce meaningful tests.

This is valuable for improving code-level coverage. But it doesn't replace E2E testing. Qodo won't tell you if your checkout flow breaks after a deploy. It tells you if your calculateTotal() function handles null inputs correctly.

What works:

• Fast, contextual unit test generation inside the IDE

• Good at finding edge cases developers miss

• Free tier (75 credits/month) is generous enough for individual use

• Supports Python, JavaScript, TypeScript, Java, and more

What doesn't:

• Not an E2E testing tool. No browser automation. No visual testing

• Generated tests sometimes need manual adjustment for complex business logic

• Doesn't integrate with CI/CD as a standalone QA solution

• Limited value for QA teams. This is a developer tool

The verdict: Great for developers who want better unit test coverage. Wrong tool for QA engineers evaluating E2E solutions. Include it in your developer toolkit, but don't count on it as your testing strategy.

#6: Mabl (best for low-code testing)

Mabl makes test automation accessible to people who don't write code. That's its strength and its ceiling.

Starting price: Around $499/month for small teams

Best for: Teams transitioning from manual testing to automation, with non-technical QA members.

Mabl's visual test builder lets you create tests by clicking through your application. The platform records your actions and generates tests with built-in assertions. AI-powered auto-healing updates selectors when elements change. It runs tests in Mabl's cloud, so there's no infrastructure to manage.

The onboarding experience is genuinely good. Non-technical QA team members can create meaningful tests within hours. The learning curve is shallow by design.

What works:

• Visual test builder requires zero coding

• Auto-healing keeps tests running after UI changes

• Cloud execution with no infrastructure management

• Good onboarding for non-technical team members

What doesn't:

• Pricing scales up quickly as test volume grows

• Limited flexibility for complex testing scenarios

• You'll hit the ceiling fast if your application has intricate workflows

• Proprietary format. Your tests live in Mabl. No easy migration path

The verdict: Solid training wheels for test automation. If your team is new to automated testing, Mabl gets you started quickly. But expect to outgrow it within 12-18 months as your testing needs mature.

#7-#12: Six more tools worth knowing

#7: Functionize (best for data-heavy applications)

Functionize runs ML models against your historical test execution data to predict which tests are likely to fail after a given code change. The platform prioritizes test runs based on risk scoring, so your CI pipeline runs the most relevant tests first.

Starting price: Custom enterprise (typically $20K-60K/year based on test volume).

The core feature is adaptive test maintenance. Functionize tracks how your application's DOM structure changes over time and uses that history to update selectors before they break, not after. This works better than reactive self-healing for applications with predictable change patterns (e.g., a dashboard that adds new widgets regularly). NLP-based test creation is available but inconsistent. The plain-English-to-test conversion works for simple flows. Multi-step workflows with conditional logic need manual scripting.

The verdict: Useful if your bottleneck is test prioritization across a large suite (500+ tests). The ML-based risk scoring saves CI minutes. But the enterprise-only pricing and 6-8 week onboarding make it hard to justify unless your test suite is already large enough to benefit from intelligent prioritization.

#8: Diffblue (best for Java unit testing)

Diffblue Cover automatically writes unit tests for Java code. It analyzes your codebase and generates JUnit tests that achieve high code coverage. The company raised $6.3M in late 2024 from existing investors and remains independently operated, focused exclusively on Java.

Starting price: Per-seat licensing (typically $500+/seat/year).

The verdict: If your stack is Java and you need unit test coverage fast, Diffblue does it better than any general-purpose AI. Useless for anything else.

#9: Maestro (best for mobile-native agentic testing)

Maestro is the closest thing to Playwright-style agentic testing for iOS and Android. You write flows in a YAML-based DSL, and the framework navigates native UI elements without relying on brittle XPath selectors. It reads the screen's accessibility tree and matches elements by label, type, and hierarchy.

Starting price: Open source (free). Maestro Cloud starts at ~$250/month per device for CI execution.

The framework includes auto-wait logic that adapts to animation timing and network latency. MaestroGPT can help generate YAML flows, but the primary authoring experience is YAML, not natural language. (The team actually built and shut down a pure NL testing product, concluding that declarative YAML was more reliable.) It handles the problem that kills most Appium tests: timing flakiness on real devices. The limitation is ecosystem. Maestro's community is smaller than Playwright's, and complex gestures (multi-finger swipe, drag-and-drop) still need manual scripting.

The verdict: If you ship mobile apps alongside your web product, Maestro is the only tool on this list that covers native iOS/Android. Open source core keeps costs low. But expect to invest in writing flows manually. The AI generation layer isn't as mature as web-side tools.

#10: Percy by BrowserStack (best for visual snapshot testing)

Percy captures screenshots of your application during test runs and flags visual differences between builds. BrowserStack acquired Percy to complement their browser testing infrastructure.

Starting price: Starts at ~$399/month for the Team plan. Free tier includes 5,000 monthly screenshots.

Percy integrates with your existing test framework (Playwright, Cypress, Selenium) and adds a visual review layer. The review UI lets your team approve or reject visual changes per build.

The verdict: A lighter, cheaper alternative to Applitools for teams that need visual regression coverage without the enterprise pricing. Less sophisticated AI, but covers the basics.

#11: Promptfoo (best for LLM output evaluation)

Promptfoo is an open-source framework for testing LLM outputs. If your product includes AI features (chatbots, summarization, search), you need to verify that model responses are accurate, safe, and consistent. Promptfoo runs test suites against your prompts and scores responses on criteria like factual accuracy, toxicity, and format compliance.

Starting price: Open source (free). Promptfoo Enterprise for team collaboration uses custom pricing.

This isn't browser testing. It's a different category entirely. But including it matters because the biggest QA challenge for many teams isn't "does the button work" but "does the AI hallucinate." Promptfoo lets you define assertions like "response must not contain PII" or "answer must reference only provided context documents" and runs them against hundreds of prompt variations. Red teaming presets test for jailbreaks and safety violations out of the box.

The verdict: If you ship LLM-powered features, you need an evaluation framework alongside your browser E2E suite. Promptfoo is the most accessible option: open source, CLI-first, and integrates with CI/CD via an official GitHub Action. Different category than the other tools here, but arguably more critical for teams building AI products.

#12: Checkie.AI / Testers.AI (best for autonomous AI agent testing)

Checkie.AI rebranded to Testers.AI and now positions itself as a "virtual test team." It uses vision AI agents to test web applications by looking at the screen rather than parsing the DOM.

Starting price: Core Coverage at \(1,777/year. Pro at \)4,777/year.

The vision-first approach means it can test applications that resist traditional automation (heavy canvas rendering, complex SVGs, WebGL). The rebrand reflects a shift from pure vision testing to a broader autonomous testing agent that covers functionality, performance, and security.

The verdict: No longer early access but still a small player. Worth evaluating if your application has unusual rendering that breaks traditional DOM-based automation.

What's not on this list (but should be on your radar)

This ranking includes mobile (#9 Maestro) and LLM evaluation (#11 Promptfoo) alongside the browser-focused tools. Three categories still didn't make the cut but affect most teams.

Accessibility testing under the European Accessibility Act

The European Accessibility Act (EAA) enforcement started in mid-2025. If you serve EU customers, automated accessibility testing is a compliance requirement, not a nice-to-have. axe-core handles rule-based a11y checks. The newer tools (Evinced, accessiBe's CI scanner, and Arc Toolkit) use AI to detect issues that rule-based systems miss: poor color contrast in dynamic themes, keyboard navigation dead ends, screen reader incompatibility in SPAs. None of the 12 tools above handle this well. You need a dedicated a11y layer in your pipeline. Budget for it separately.

Synthetic test data generation

Most AI testing tools focus on scripts and ignore the data problem. Your E2E tests need realistic user data: names, emails, addresses, payment details. Using production data in staging is a PII risk. Hardcoding test data makes tests brittle and tightly coupled to specific database states. Tools like Tonic.ai, Gretel, and Snaplet generate synthetic datasets that match your production schema without exposing real user data. If your test failures are caused by bad test data more often than bad scripts, this is where to invest first.

Pricing models are shifting under you

The pricing models on this list still mostly reflect the SaaS subscription era. The industry is moving toward usage-based billing: cost per test minute, per agent hour, or per inference call. When comparing tools, normalize costs to "price per test run on my actual app" rather than comparing monthly stickers. A tool at \(200/month that runs 100 tests and a tool at \)2,000/month that runs 10,000 tests have very different unit economics. Ask vendors for their cost-per-test-run on your specific application before signing anything.

Glossary: What the marketing terms actually mean

Every vendor uses these terms. Most define them loosely. Here's what to look for when a tool claims each capability.

Agentic testing

A test system that receives a goal and decides the navigation steps at runtime. Concrete example: you write "add an item to the cart and check out." The agent opens your app, finds a product (even if the product grid layout changed since last run), clicks "Add to cart," navigates to checkout, and fills the form. If your team moves the cart icon from the header to a sidebar, the agent locates it in the new position. The key distinction from record-and-replay: agentic tests don't store a fixed sequence of DOM interactions. They re-plan each run.

Self-healing

The test runner detects that a selector (#submit-btn) no longer matches any element, searches for the most likely replacement (maybe button.primary-action or the button with text "Submit"), updates the locator, and passes. This happens during the CI run, not after a human intervenes. When evaluating vendors, ask: "What's your self-heal success rate on production UI changes, not demo apps?" Most won't give you a number. The ones that do are worth talking to.

Video-to-code

You record a Loom (or any screen recording) of yourself completing a user flow. The tool's vision model watches the recording frame-by-frame, identifies each interaction (clicks, typing, scrolling, waiting for elements to load), and outputs a Playwright test script. The practical test: upload a 60-second recording of your actual app's login-to-dashboard flow. If the output passes without edits, the tool works. If you spend 20 minutes fixing selectors and adding waits, it doesn't.

Generative AI in software testing

AI that creates complete, new test cases rather than assisting with ones you've already written. The distinction matters: Copilot autocompleting your expect() statement is AI-assisted testing. A tool that analyzes your app's routes and produces 50 test cases covering happy paths, error states, and edge cases is generative AI in software testing. The output is a full test suite, not a code suggestion.

Intent-based testing

Writing test assertions as outcomes ("user sees confirmation page with order number") rather than implementation steps (await page.waitForSelector('.order-confirmation'); expect(page.locator('.order-id')).toBeVisible()). The testing system translates the intent into specific DOM interactions based on the current state of the page. When the confirmation page gets redesigned, the intent stays the same. The implementation steps update automatically.

Stop writing scripts, start auditing results

The generative AI testing tools market has real options now, not just demos. The right choice depends on your constraint.

If pixel-perfect UI matters most, Applitools remains the gold standard for visual regression. Pair it with any test generation tool.

If you want to describe tests in English or record a video and get working Playwright suites, Bug0 Studio is the strongest option for agentic testing and video-to-code.

If you want zero involvement in testing, QA Wolf and similar managed services handle everything. You pay more, but you do less.

If enterprise procurement drives your decisions, Testim by Tricentis checks every compliance box.

The common thread across the best tools: they test intent, not implementation. They heal when UI changes. They generate Playwright code, not proprietary scripts. Your job isn't to write tests anymore. It's to define what "working" means and let the tools prove it.

FAQs

What is generative AI testing?

AI that produces complete test cases from inputs like natural language, video recordings, or application analysis. The "generative" part distinguishes it from AI-assisted testing (like Copilot autocompleting your test code). A generative tool takes "test the login flow with invalid credentials" and outputs a full Playwright script with navigation, input, submission, and error assertion. You run it. It either passes or it doesn't.

How is agentic testing different from traditional test automation?

Traditional automation stores a fixed sequence: click #login-btn, type into #email-field, assert .dashboard is visible. If any selector changes, the test fails. Agentic testing stores the goal: "log in and verify the dashboard loads." At runtime, the agent inspects the current page, identifies the login form regardless of its selectors, fills it, and checks the result. The practical difference shows up after a UI redesign. Traditional tests need manual updates. Agentic tests re-plan the steps automatically. The limitation: agents still fail on ambiguous UIs where multiple valid paths exist, or when your app requires non-obvious interaction patterns.

Do video-to-code tools actually work in production?

Run this test yourself: record a 90-second flow through your actual app (not a demo). Include a login, at least one form interaction, and a page navigation. Upload it to the tool. If the generated test passes in CI without edits, the tool works for your use case. In our evaluation, most tools required 15-40 minutes of manual cleanup per recording on real applications. A few produced near-runnable output. The variable is your app's complexity, specifically dynamic content, custom components, and third-party embeds are where video-to-code breaks down.

Can AI testing replace QA engineers?

It replaces the tasks nobody wants to do: maintaining 300 selectors, re-running regression suites manually, writing boilerplate test setup. It doesn't replace the judgment calls. Deciding which flows are critical, interpreting whether a visual change is intentional or a bug, understanding that "the button works but the UX is confusing" those need a human. The teams getting the most value use AI for coverage and repetition while their QA engineers focus on test strategy, exploratory testing, and release decisions.

Which tool should I choose for my team?

Start with your biggest problem, not the most impressive demo. If your tests break every sprint from UI changes, you need self-healing (Applitools, Bug0 Studio, Testim). If you have no tests at all, you need generation (Bug0 Studio, Qodo, Mabl). If you don't have anyone to own the test suite, you need a service (QA Wolf). If your procurement process takes 6 months and you need to start now, pick a tool with a free tier (Qodo, Maestro) and evaluate enterprise options in parallel.

How much does Bug0 Studio cost?

Starts at ~\(250/month pay-as-you-go for test minutes. Scales with usage. Unlimited tests, test suites, and AI credits included. Bug0 Managed (done-for-you QA with dedicated engineers) starts at ~\)2,500/month flat. For comparison, Applitools runs \(10K-50K/year, Testim/Tricentis runs \)30K-100K/year, and QA Wolf starts around $5K/month.

What should I test during a vendor evaluation?

Don't use the vendor's demo app. Record your actual application's most complex user flow, the one that breaks the most. Upload it or describe it in natural language. Run the generated test in your staging environment. Then change something in the UI (rename a button, move a section) and run the test again without updating it. That second run tells you whether the self-healing actually works. Most vendors will happily demo on their own app. The ones that let you test on yours during the evaluation are the ones worth shortlisting.

If you are anything like us, your browser history is likely a graveyard of Gemini conversations and ChatGPT threads named "Fix this Playwright Selector" or "Generate Test Script."

We have all tried using ChatGPT for testing. It usually goes like this: you open the dev tools, copy a massive chunk of your DOM, paste it into ChatGPT, and pray it understands which <button> is actually the "Submit" button.

It works, but it is exhausting. It feels less like "full automation" and more like advanced copy-pasting.

We recently went down a rabbit hole looking for a better AI testing tool. We needed something that could take the logic of an LLM but apply it directly to the browser without the manual friction. When we couldn't find exactly what we needed, we teamed up with our co-founder, Sandeep, and the Bug0 crew to build it.

It is called Bug0 Studio (at vibe.bug0.com), and it has completely shifted how we generate Playwright scripts. It is the same core technology we use to serve our enterprise customers in our Forward Deployed Engineering (FDE) model in QA testing, so we knew it had to be robust.

Here is the story of why we built it, and why it has become the best AI software testing tool for our own workflow.

The Problem: Why Text Prompts Aren't Enough

The biggest limitation we faced when using ChatGPT for usability testing or script generation was blindness. An LLM (Large Language Model) doesnt see your site; it only reads the text you feed it.

Sure, you can use ChatGPT for guerilla usability testing ideas. You can ask it to generate user personas or hypothetical scenarios. But when it comes to the actual execution, specifically writing the code that clicks the button, it often fails because it lacks context. It doesn't know that your "Login" button is actually hidden behind a cookie banner, or that your specific React component renders differently on mobile.

We wanted a workflow that felt like ChatGPT. It needed to be conversational and smart, but we needed it to have "eyes" on our application.

Enter Bug0 Studio: The "Vibe" Testing Approach

We designed Bug0 Studio as a vibe testing platform. The idea was straightforward: instead of writing code or messing with complex prompts, we simply wanted to show the AI the "vibe" of the user journey and have it generate the script.

We designed the workflow to be as simple as possible:

1. Record, Upload, or Type: We made it flexible - you can record your browser tab directly, upload a video file (mp4/webm), or just describe the flow in natural language text.

2. Describe: You tell it what you are testing in plain English.

3. Get Code: It processes the video recording along with your text description and spits out a fully working Playwright test.

We needed a real AI tool for automation testing that connects the user's view directly to the code logic.

Bug0 Studio Screenshot: The entry point is simple: either record live or upload a video.

The "Lazy Developer's" Dream Setup

What we focused on most wasn't just the AI generation, but the specific configuration options. Most AI tools for testing require a lot of boilerplate setup. We tried to identify the exact pain points developers (including ourselves) have when setting up test suites.

When you start a session, we designed a configuration panel that handles the boring stuff:

1. Site Setup: You just drop in your Base URL.

2. Login Credentials: You can provide optional Email/Password fields so the AI understands authentication flows.

3. Storage State JSON: This is the killer feature we knew we needed.

We are paranoid about security, so we made a specific design choice here. We designed the system so that your Base URL and credentials stay in localStorage on your machine. They aren't stored permanently on our servers, which is a huge relief.

Being able to paste a Playwright storage state JSON means you can test deep-link flows without re-logging in every time.

If you have ever written E2E tests for a dashboard behind a login wall, you know the pain. Usually, you have to script the login steps for every single test. With Bug0, you can just paste your Playwright storageState JSON, and the AI assumes that session. It effectively acts as an AI tool for manual testing logic that automates the setup for you.

A Practical Example

A simple checkout flow is the best way to show how we use it effectively. This is usually a nightmare for brittle selectors.

The Workflow:

1. We clicked "Record Tab" in Bug0 Studio.

2. We clicked on a product, added it to the cart, and proceeded to checkout.

3. We stopped the recording.

4. The Validation Step: We didn't want it to be a "black box," so we built an intermediate step. The AI analyzes the video and extracts a list of ordered steps. We can actually edit, add, or remove steps right there. This allows us to fix a logic error we made during recording before the AI writes any code.

5. We verified the steps and hit "Generate."

The Result: Once the generation started, the tool spun up a live cloud browser session. We watched a split-screen view: on the left, the AI was explaining its logic in real-time; on the right, we saw a live preview of the test actually running on the cloud browser.

It wasn't just "guessing" based on HTML; it was executing the "vibe" of the user journey in front of our eyes, ending with a generated Playwright script that used robust locators like getByRole.

The Landscape: Why We Built This

When searching for an AI testing tool, we mostly found three types of solutions. Here is why we found them frustrating enough to build our own solution:

1. The Chatbots (ChatGPT, Claude)

We love them, but they are blind. You have to feed them HTML snapshots or screenshot uploads manually. If the DOM changes or uses dynamic classes (like CSS modules), the bot often hallucinates selectors that look correct but fail immediately.

Zero real-time visual context; requires constant manual copy-pasting.

2. The "Literal" Recorders (Playwright Codegen)

These tools are technically impressive, but they are literal to a fault. If we accidentally click the wrong field and then correct ourselves, the recorder scripts both actions. They also tend to default to specific hierarchical selectors (e.g., div:nth-child(3)) which break the moment we add a new UI element.

Brittle scripts. They record actions, not intent.

3. The "Black Box" Enterprise Suites

There are plenty of "Autonomous Testing Agents" out there. They promise self-healing and zero-code, but they usually require us to install their heavy SDKs, run tests on their specific cloud infrastructure, and pay enterprise pricing.

Vendor lock-in. We designed Bug0 Studio to just give us standard Playwright code that we can run in our own local VS Code or CI/CD pipeline.

Conclusion

We are seeing a flood of AI tools right now, and it is hard to tell which ones are actually useful. But if you are looking for a ChatGPT for testing alternative that is purpose-built for modern web apps, we invite you to check out what we've built.

It solves the context problem by using video, and it solves the setup problem by handling Auth and Storage States natively.

Give it a spin at Bug0 Studio. Its surprisingly fun to just upload a video and watch clean code appear. We truly believe this is not just a temporary fix, but the blueprint for the best AI software testing tool of the future.

Feel free to hop on into our Discord and share your thoughts or feature requests.

As AI and data platforms grow more complex, one role keeps showing up in every hiring pipeline: the Forward Deployed Engineer.

Companies like OpenAI and Palantir are scaling these teams fast. Job postings are exploding, with some reports citing an 800% spike in FDE job listings this year (Source: Radical Data Science / Indeed Report). Top-tier VC firms and tech media have dubbed it the "hottest job in startups" (Source: Crunchbase News). Why? Because this role is about one thing: execution.

What is a forward deployed engineer?

A Forward Deployed Engineer (FDE), or Forward Deployed Software Engineer (FDSE), is an elite, hybrid technical role. These are your best engineers, the ones you embed directly with your biggest customers to solve their hardest, highest-stakes problems.

They operate with the autonomy of a founder but the technical rigor of a staff engineer. "Deployed" from HQ to the customer's "forward" position: their offices, their data centers, their messy reality. Empowered to build, design, and ship production code to make that customer win.

They aren't just engineers. They aren't just consultants. They are hybrid, high-ownership builders. Below is a breakdown of the current salary data, core responsibilities, and the specific "decomposition" interview format used by firms like Palantir and OpenAI.

What is a forward deployed engineer? The definition and meaning

The forward deployed engineer definition is simple. It's built on two concepts:

1. "Forward Deployed": This is a military term. It means you're on the front lines. You're not safe at headquarters. For an FDE, this means leaving the comfort of the office and living inside the customer's world: with their messy data, their complex security, and their urgent, real-world problems.

2. "Engineer": This is the critical part. An FDE is not a sales rep, a consultant, or a support agent. They are hands-on-keyboard builders. They write, debug, and ship production-grade code. They build data pipelines. They deploy systems. They build.

The meaning of the role in practice is to be the human bridge between a powerful, generic platform (like Palantir's Foundry or OpenAI's GPT models) and a customer's unique, specific problem. They make the technology work for that client.

What does a forward deployed engineer do? (Role and responsibilities)

The forward deployed engineer role has one central mission: own the customer's technical success. Whatever it takes.

A look at a forward deployed engineer job description

Look at any OpenAI forward deployed engineer job description. You'll see these role responsibilities:

• Embed deeply with customers. Lead complex, high-stakes deployments.

• Map customer problems, structure the solution, and ship it. Fast.

• Design, build, and deploy full-stack systems and custom data pipelines that create real value.

• Act as the primary technical owner. Build trust. Guide the customer's own teams.

• Find reusable patterns. Bring field insights back to your core product team.

• Troubleshoot the most complex production outages. Be the last line of defense.

The day-to-day: An FDE's four-stage loop

An FDE's work is a four-stage loop:

1. Scoping: You get a vague problem: "We need to cut fraud" or "We want to use AI in our factory." You dig in, find the real problem, and define a concrete technical plan.

2. Prototyping: You move fast. You build a proof-of-concept (PoC). This is rapid, hands-on coding to show the customer what's possible. You get fast feedback.

3. Deployment: The PoC works. Now, you harden it. You rewrite it to be production-grade, scalable, and secure. You navigate the client's infrastructure and get it live.

4. Feedback: You're the company's eyes and ears. You see what customers need. You take these insights back to the core product and research teams. You help build better products.

Forward deployed engineer vs. software engineer vs. solutions architect

Don't confuse the FDE with other roles. The difference is about shipping and ownership.

The Sales Engineer sells the dream. The core Software Engineer builds the toolbox. The Forward Deployed Engineer uses that toolbox to build the custom, finished solution for the client.

Which companies hire forward deployed engineers?

This role is hottest at companies selling complex, high-value platforms. It's not a job. It's a go-to-market strategy for products that need deep, technical integration to win.

The pioneer: Palantir

The Palantir Forward Deployed Software Engineer (or FDSE) is the original. Palantir built its entire multi-billion dollar company on this model. They embed these elite engineers with massive government and commercial clients (think military, banks, manufacturing) to solve huge, complex data problems. The Palantir forward deployed engineer role is legendary for its autonomy, high stakes, and massive impact. They are the definition of "owning the problem."

• Job Portal: Palantir Careers

The new wave: The AI and data giants

The AI boom created an explosive need for FDEs. GPT-4 is a raw API. The FDE is the one building the enterprise-grade application, RAG pipelines, and security layers that make it usable for a bank or a hospital. This is the new talent war.

• OpenAI: An OpenAI Forward Deployed Engineer is on the front line of the AI revolution. They embed with Fortune 500s to apply generative AI, fine-tuning models, building new agentic workflows, and proving the business case.

  • Job Portal: OpenAI Careers

• Anthropic: As a primary competitor to OpenAI, Anthropic's FDEs (often called "Applied AI Engineers") have the same mission: embed with enterprises to make their Claude models solve real, specific, high-value problems.

  • Job Portal: Anthropic Careers

• Cohere: Another major AI lab, Cohere hires FDEs to work on their "Agentic Platform," helping businesses build and deploy custom AI agents.

  • Job Portal: Cohere Careers

• Databricks: The data and AI giant hires "AI Engineers, FDE" to help customers build and productionize first-of-their-kind AI applications on the Databricks platform.

  • Job Portal: Databricks Careers

• Scale AI: The data infrastructure leader for AI hires "Forward Deployed Data Scientist/Engineers" who thrive on "ambiguity" and "first-principles thinking" to architect data solutions for top AI labs and enterprises.

  • Job Portal: Scale AI Careers

The new breed: Modern startups and scale-ups

The FDE model is now the strategic weapon for the most ambitious, high-growth startups. They build their go-to-market around this role.

• Ramp: This fintech unicorn hires Ramp Forward Deployed Engineers to handle complex enterprise migrations and build custom integrations. Their own engineering blog calls the role a "strategic unlock for modern B2B companies."

  • Job Portal: Ramp Careers

• Bug0: A clear example of the FDE model evolving into "Outcome-as-a-Service." Bug0 offers two tiers: Studio for self-serve teams who generate their own AI-powered Playwright tests, and Managed for teams who want a full FDE pod. The Managed pod owns the entire QA lifecycle: test planning, AI-assisted generation (from natural language or video recordings), human verification, bug filing with repro steps, and release gating. It's the FDE-as-revenue-multiplier model applied to testing, removing the need for a full in-house QA department.

  • Website: Bug0

• Superblocks: A fast-growing internal tools platform, their job postings for "Founding Forward Deployed Engineer" explicitly look for people who are "all-in and committed to building a generational AI company, far beyond a 9 to 5 job."

  • Job Portal: Superblocks Careers

• HoneyHive: An AI observability startup, they hire their "first Forward Deployed Engineer" to be a "foundational role" in the company, acting as the technical bridge to their enterprise customers.

  • Job Portal: HoneyHive Careers

• Matta: An AI startup for manufacturing, their FDE job description is pure founder-speak: "This isn't a role with a playbook You'll roll up your sleeves and get problems sorted."

  • Job Portal: Matta Careers

• Adobe: This model is now being adopted by established tech giants. Adobe hires "Forward Deployed AI Engineers" to help customers build with its Firefly AI models, proving the FDE role is here to stay.

  • Job Portal: Adobe Careers

Forward deployed engineer salary: Why it's one of tech's highest-paid roles

The forward deployed engineer salary is massive for one reason: skill scarcity. You need to be a strong engineer and a high-empathy communicator who can manage a multi-million dollar relationship.

Note: TC = Total Compensation (base + stock + bonus). The 2024/2025 hype was driven by "AI FOMO." The 2026 market has shifted toward proven ROI. Companies are paying these premiums only for engineers who can demonstrate a direct link between their deployments and customer retention.

The benchmark: Palantir forward deployed engineer salary

Palantir pays. Average TC for an FDE is now $238,000, with the range typically between $205,000 and $486,000. Staff-level FDEs are clearing $630,000+.

The new standard: OpenAI forward deployed engineer salary

AI labs are in a talent war. OpenAI and Anthropic TC packages have stabilized at $350,000 - $550,000 for mid-to-senior levels. These roles are benchmarked against top researchers. They need engineers who can fine-tune models and handle a Fortune 500 CTO.

General salary expectations

For a forward deployed engineer salary at other companies:

• Entry-level / new grad: $180,000 - $250,000 TC

• Mid-level (3-5+ yrs): $250,000 - $400,000+ TC

Where the jobs are

One shift worth noting: New York (35% of FDE postings) has surpassed San Francisco (11%) as the primary hub. The demand is concentrated in fintech and highly regulated industries where FDEs navigate complex compliance requirements alongside technical integration.

The high pay reflects the high-stress, high-impact, and high-travel nature of the job. You're paid for leverage.

How to become a forward deployed engineer

Getting a forward deployed engineer job is hard. The interviews are designed to break you. They test for technical skill, problem-solving, and personal grit. You can't just be book-smart. You have to be a builder who can ship.

What background do you need?

Companies don't just hire former FDEs. They look for people who have acted like one. The best backgrounds are:

• Early-stage startup engineer: This is the #1 predictor. If you were one of the first 10 engineers at a startup, you've already done this job. You've talked to customers, worn all the hats, and shipped code to save the company.

• Hands-on solutions architect: Not the SAs who only make diagrams. The ones who build the PoC themselves, write custom scripts, and live in the terminal.

• Data engineer / ML engineer (with engineering chops): If you don't just live in notebooks and you've built and deployed data pipelines or productionized models, you're a fit.

• Full-stack engineer (with product sense): A developer who doesn't just take tickets but talks to the product manager to question why they're building something.

The must-have skills: A "T-shaped" profile

FDE hiring looks for "T-shaped" people. Deep expertise in one area, broad skills in many others.

Deep technical bar (the vertical "I")

You must be a strong, hands-on engineer. "Good enough" isn't good enough.

• Coding: You need to be fluent in Python. It's the language of data and AI. Familiarity with Java, Go, or TypeScript/JavaScript is also key for building full-stack solutions.

• Data: "I know SQL" is the bare minimum. You need to understand data processing (e.g., Spark), data pipelines (e.g., Airflow), and database trade-offs (SQL vs. NoSQL, OLAP vs. OLTP).

• Systems (DevOps/MLOps): You're deploying production code. You must understand the stack:

  • Cloud: Deep knowledge of AWS, GCP, or Azure.

  • Containers: You must know Docker and Kubernetes.

  • Infrastructure: Experience with Terraform or other IaC tools is a huge plus.

• AI / ML (for AI FDEs): This is the 2026 non-negotiable skill set. The industry has moved past chatbots into agentic workflows, where AI systems autonomously execute multi-step tasks (filing claims, routing supply chain parts, running QA suites).

  • Core concepts: You must understand RAG (Retrieval-Augmented Generation), fine-tuning, vector databases, and agentic orchestration (frameworks like LangGraph or CrewAI).

  • Evaluation frameworks (evals): You need to know how to build and run evals that prove an AI agent won't go rogue in production. This is what separates a demo from a deployment.

  • AI observability and guardrails: The 2026 FDE is the person who proves to the customer's security team that the agent is safe. Tools like LangSmith, Braintrust, or HoneyHive for tracing, monitoring, and constraining agent behavior.

  • Frameworks: Hands-on experience with PyTorch or TensorFlow and HuggingFace.

Broad execution skills (the horizontal bar)

This is what separates an FDE from a core engineer. This is the hard part.

• Customer fluency and empathy: You can't just talk to engineers. You must be able to explain a complex system to a non-technical executive and understand their business problem. You translate business needs into technical specs.

• Grit and radical ownership: A deployment fails at 2 AM. You don't file a ticket. You don't blame another team. You don't go to sleep. You fix it. Period. You own the problem from end to end.

• Problem decomposition: You must thrive in chaos. You can take a massive, vague, scary problem (like "Our supply chain is broken") and break it into a clear, shippable, step-by-step plan.

• Product sense: You're the eyes of the product team. You have to spot patterns. When you build the same custom script for three different customers, you identify it and tell the product team to build it into the platform.

The interview process: How to win

The process is multi-stage. Each round tests a different part of your "T".

1. Behavioral / fit interview: This is the "horizontal bar" test.

   • Questions: "Why an FDE?", "Tell me about a time you handled a demanding stakeholder," "Describe a complex project you owned from 0 to 1," "Tell me about a time you failed."

   • How to win: Use the STAR method (Situation, Task, Action, Result). Show ownership, not just participation. Your stories must be about you shipping code and solving a problem, not just being on a team.

2. Technical deep dive(s): This is the "vertical bar" test.

   • Coding: This won't be a simple LeetCode problem. It will be a practical, real-world task. (e.g., "Here's a messy 1GB JSON file, parse it, clean it, and expose an API to query it.")

   • System design: This will be data-heavy. (e.g., "Design a real-time analytics pipeline for a million IoT devices," "Architect a RAG system for a company's internal wikis.").

3. The case study / decomposition interview: This is the hardest round.

   • This is the famous Palantir forward deployed engineer interview. It's now used by almost every company hiring FDEs.

   • You get a massive, ambiguous, real-world problem on a whiteboard.

   • Classic example: "A major city wants to use our platform to reduce 911 emergency response times. They have 911 call data, traffic data, and ambulance GPS data. You have 60 minutes. Go."

   • 2026 agentic example: "A global logistics firm wants an AI agent to handle automated rerouting for delayed shipments. They have SAP data, real-time weather APIs, and 500 different warehouse managers. How do you build the eval suite to ensure the agent doesn't overspend on shipping while maintaining a 99% delivery rate?"

How to prep and pass the "decomposition" interview

This isn't about getting the "right answer." It's about showing how you think.

1. Do not jump to a solution. Your first instinct will be "Build an AI to predict traffic!" Don't. You will fail.

2. Ask questions (clarify and scope): Start by interviewing your interviewer.

   • "What's the actual goal? Is it 30 seconds or 10 minutes?"

   • "Who is the user? The 911 operator? The ambulance driver? The public?"

   • "What does the data look like? Is it clean? How often does it update?"

   • "What are the constraints? What's the budget? What's the timeline?"

3. Decompose the problem: Break the big problem into small, solvable chunks.

   • "Okay, I see three main problems to solve:

     1. Ingestion: We need to get all this messy data in one place.

     2. Visibility: The operators need a real-time map of all ambulances and new incidents.

     3. Optimization: We need a model to suggest the best ambulance for a new incident."

4. Propose an MVP (version 1): Propose the simplest possible thing that delivers value.

   • "Forget the AI model for now. V1 will be a simple data pipeline and a real-time dashboard. Just seeing all the ambulances on a map would be a huge win for the operators."

5. Iterate and discuss trade-offs: The interviewer will now push you. "Okay, the data is messy, what do you do?" "How do you scale that?"

   • Talk through your trade-offs. "I'd use Kafka for ingestion because we need real-time, but it's complex. A simple polling API might be better for the MVP."

Most candidates fail because they try to show off their knowledge of a specific tool (like Kafka or Pinecone) before they even understand the user's latency requirements. Don't be that person. Be the engineer who cares more about the 911 operator's workflow than the database schema.

To win, think out loud. Show them your structured, logical, first-principles thinking. Show them you're a builder who can handle chaos and own a problem.

The future of the FDE role

The Forward Deployed Engineer is not a trend. It's the future of high-value B2B tech.

The integration wall

Most AI projects fail not because the model is bad, but because it can't talk to the customer's legacy SQL databases, handle their OIDC/SAML authentication, or meet their data residency requirements. This is the "integration wall," and it's where FDEs earn their compensation.

The 2026 FDE is the person who breaks through this wall. They understand that getting a demo working in a sandbox is 20% of the job. The other 80% is navigating enterprise SSO, legacy ETL pipelines, regulatory constraints, and the politics of getting production credentials from a customer's security team. No amount of prompt engineering fixes those problems. You need someone on-site, with production access, who can ship.

Why FDEs are the new revenue multiplier

Companies are realizing that the most advanced platform is useless if it sits on a shelf. The AI Forward Deployed Engineer is the key to getting real results from AI. In a world where platforms are becoming commodities, the ability to deploy them and create value is the only thing that matters.

FAQs

What does "forward deployed engineer" mean?

A Forward Deployed Engineer (FDE) is a hybrid technical role where engineers embed directly with customers to solve their hardest problems. They write production code, build custom solutions, and own the customer's technical success end to end. They're embedded at the customer's site, working on the customer's problems, with the customer's data.

How much does a forward deployed engineer make in 2026?

Forward Deployed Engineer salaries are among the highest in tech. At Palantir, average TC is $238,000, ranging from $205,000 to $486,000, with staff-level FDEs clearing $630,000+. OpenAI and Anthropic have stabilized at $350,000-$550,000 for mid-to-senior levels. New grad TC at most companies starts at $180,000-$250,000. New York (35% of postings) has surpassed San Francisco (11%) as the primary FDE hub due to fintech and regulated-industry demand.

What's the difference between a forward deployed engineer and a software engineer?

A core software engineer builds the product for all users. A Forward Deployed Engineer takes that product and builds custom, production-grade solutions for specific customers. The FDE is deeply embedded with the client, owns the relationship, and ships code to solve that customer's unique problems. Core engineers rarely interact with customers directly.

Who hires forward deployed engineers in 2026?

Palantir pioneered the role. Today, AI companies (OpenAI, Anthropic, Cohere, Databricks, Scale AI), fintech companies (Ramp), AI-native QA platforms (Bug0), and established giants like Adobe all hire FDEs. Job listings for the role have spiked 800% as companies realize they need engineers who can deploy complex platforms for enterprise customers.

How do I prepare for a forward deployed engineer interview?

FDE interviews typically include three stages: behavioral/fit interviews testing communication and ownership, technical deep dives testing coding and system design, and the famous "decomposition" case study. For the case study, don't jump to solutions. Ask clarifying questions, break the problem into solvable chunks, propose a simple MVP, then iterate. Think out loud and show structured, first-principles reasoning.

What skills do forward deployed engineers need in 2026?

FDEs need a "T-shaped" profile. Deep technical skills in coding (Python, TypeScript), data (SQL, Spark), and systems (AWS/GCP, Docker, Kubernetes). Plus broad execution skills: customer empathy, radical ownership, problem decomposition, and product sense. For AI FDEs in 2026, the bar has shifted to agentic orchestration (LangGraph, CrewAI), evaluation frameworks, and AI observability/guardrails, on top of RAG and fine-tuning fundamentals.

Is the forward deployed engineer role the same as a solutions architect?

No. A solutions architect designs solutions and demos them during the sales process. A Forward Deployed Engineer builds and deploys production-grade solutions after the deal is signed. The SA sells the dream. The FDE makes it real. FDEs write code, deploy systems, and own the customer's technical success long-term.

How does Bug0 use forward deployed engineers?

Bug0 applies the FDE model to quality assurance as "Outcome-as-a-Service." They offer two tiers: Studio (self-serve AI test generation) and Managed (a full FDE pod that owns your QA). The Managed pod plans tests, generates them using Bug0's agentic AI engine from natural language or video recordings, verifies results with human judgment, files bugs with repro steps, and gates releases. It's a clear example of how the FDE model is expanding beyond data platforms into specialized domains like testing.

Most teams still depend on manual testers or complex automation setups that constantly need fixing. QA was built to ensure quality. Somewhere along the way, it became the blocker.

The broken state of QA today

Manual QA doesnt scale. Every UI change means another round of tests. Bugs slip through. Automation helped. But it also created a new mess. Scripts break. Maintenance piles up. Regressions drag.

Your stack is moving at 2025 speed. Your QA is stuck in 2015.

The first wave: automation and scripts

Tools like Selenium and Cypress helped, but only to a point. Someone still writes, maintains, and fixes tests after every UI update.

Even solid QA teams struggle to cross 60% coverage. When tests flake, they get disabled just to ship. Sound familiar?

The second wave: AI-assisted QA

Then AI entered the picture. Generative models could finally read user flows and turn them into test scripts. Self-healing systems began fixing broken selectors. Coverage improved. Maintenance dropped.

The problem is AI-only tools are dumb. They miss context. They can't tell a critical flow from a minor visual change. AI was a good first step. But it still needed a human to be reliable.

This was also the phase when AI QA tools and AI testing tools for QA automation started emerging. They proved AI could work. But they failed at real scale. They couldn't handle edge cases.

The next leap: agentic QA with human-in-loop

Now we have agentic AI. This AI acts like a real QA engineer. It thinks for itself.

You still need a human in the loop. You get AI speed and human precision. This hybrid model is the new standard.

The rise of the Forward-Deployed Engineer (FDE) model

Modern AI QA now runs automated browser tests on every pull request without slowing developers. This creates faster feedback loops and smoother CI/CD workflows.

Bug0 is pioneering the Forward-Deployed Engineer (FDE) model. It's the next evolution. AI handles test creation, execution, and maintenance. FDEs verify results, catch false positives, and align QA with your sprint goals.

How it works

• AI creates and maintains all critical browser tests automatically.

• FDEs validate and triage issues in real time.

• CI/CD integration ensures every release is tested before users touch it.

Results: 100% of critical flows covered in 7 days 80% total coverage in 4 weeks Zero setup required

Its QA built for the AI era. Machines handle the volume. Humans ensure the precision.

Why this model scales faster than hiring or agencies

Manual QA isnt just slow; its expensive in ways most teams overlook. Bug0 ran the numbers. Most startups waste $600K a year on hidden QA costs. That's developer time, release delays, and test maintenance. These costs add up fast and make traditional QA one of the biggest drains on engineering budgets.

Hiring QA engineers takes months and costs a fortune. Agencies lack product context.

The FDE model gives you both speed and context. Your QA runs inside your sprint. Coverage scales instantly. And it costs far less than building a QA team in-house.

Real-world outcomes

The ROI from AI QA is real. Teams that switch from manual QA to automated AI-driven models recover hidden expenses within months. Many see positive ROI in just two or three months.

Teams using this hybrid AI + human model report:

• 98% of bugs caught before production

• 10K+ per month saved compared to traditional QA

• Full regression coverage in under a week

Bug0 sees this happen all the time. This FDE model helps teams ship faster.

Modern AI QA platforms like Bug0 show that combining automation, AI-driven QA, and human oversight is the fastest way to scale. These systems reduce friction, improve developer velocity, and eliminate most hidden costs.

The future of QA is outcome-driven

Real AI-native QA plugs right into your CI/CD. It tests every single pull request. Developers get instant feedback. This aligns QA with the pace of modern software teams and ensures it scales with pull requests, not after them. Learn more in Bug0s deep dive on pull request testing.

QA isnt about writing test cases anymore. Its about outcomes. The AI learns and adapts on its own. The FDEs keep the AI accountable. They make sure it's aligned with your goals.

The future isnt manual or automated. Its AI for QA testing that is AI-native and agentic. And that future is already here.

Closing thoughts

AI QA with forward-deployed engineers isnt hype. Its how modern teams ship faster and sleep better. Its a safety net. It just catches bugs before your users do.

TL;DR:

The AI QA Engineer is the next evolution of software testing. It's an AI-native system that replaces slow, expensive, and brittle manual scripting. This modern approach, pioneered by companies like Bug0, uses AI to autonomously generate, run, and self-heal Playwright tests. It operates on an AI+Human model. AI handles execution and scale while humans verify critical logic, ensuring production-grade reliability. Unlike a fully autonomous AI QA engineer, this hybrid model provides the necessary context for complex applications. For QA professionals, this signals a shift toward orchestrating AI and mastering modern tools. Ultimately, the AI QA Engineer enables teams to build faster, reduce QA overhead, and ship with confidence.

QA was once slow, manual, and repetitive. Then came automation. Now AI is redefining the discipline.

AI for QA engineer workflows is bridging the gap between speed and accuracy.

This transformation gave rise to the AI QA Engineer.

Its evolution in motion. QA moved from writing scripts to building intelligence. The AI QA Engineer is not a human role. Its an automated intelligence that behaves like one. It understands your product, tests it continuously, and adapts to every change.

Bug0 coined the term and introduced it with its forward-deployed QA team model. Launched a few months back in public beta, it already works with several Series A and B companies that want to stay leaner and ship faster with confidence. It watches your app, creates tests automatically, runs them fast, and keeps you in the loop. Its QA pods verify nuanced cases that AI cant yet interpret perfectly. The result is powerful: faster shipping, fewer regressions, and a testing process that keeps getting smarter.

What is an AI QA Engineer?

An AI QA Engineer isnt just a concept. Its a category defined and coined by Bug0. It represents a testing system that behaves like a QA engineer powered by AI. Instead of depending on repetitive scripts or fragile selectors, it uses intelligence to understand your product, learn flows, and keep your test coverage up to date automatically.

Bug0 introduced this model through its forward-deployed QA team structure. Launched recently in public beta, it already supports several Series A and B companies that want to stay lean while maintaining high-quality releases. These teams use Bug0 to scale QA without scaling headcount, blending automation and human expertise.

In practice, the AI QA Engineer operates as an AI teammate. It observes how users interact with the product, identifies key paths, and builds tests dynamically. When the interface or logic shifts, it adapts and self-heals.

QA AI Engineer vs AI QA Engineer: both terms describe this modern hybrid of automation and intelligence, with human QA ensuring quality and context for every change.

Definition

AI QA Engineer: an AI-native testing system that autonomously generates, maintains, and validates tests with human-in-loop verification. Bug0 is the first production-ready platform to implement this definition at scale.

This marks QAs real turning point; from code-heavy scripts to proactive, self-learning systems that keep improving with every release.

Why QA missed real automation

For years, QA teams believed they had automation figured out. In reality, it was still manual, just wrapped in code. Most companies spent months writing Selenium or Cypress scripts tied to fragile locators, selectors, and XPath structures. A single UI change could break hundreds of tests, forcing engineers to rewrite the same flows over and over.

Enterprise teams poured money into these setups. They hired large QA teams and bought expensive automation tools, yet the maintenance load kept rising. In many cases, budgets ballooned without meaningful coverage gains.

According to Bug0s research in its article 2025 QA Reality Check: Why Your Engineering Budget is $600k Higher Than You Think, mid-sized companies now spend over $600,000 annually just maintaining outdated test automation stacks. Most of that cost comes from human hours wasted on script maintenance and flaky test triage.

The AI QA Engineer model emerged from this pain. It was built to end brittle, script-based automation and replace it with intelligent, self-healing systems that truly scale.

Evolution: from human-only to human-verified intelligence

Testing intelligence has evolved through three clear phases, each shaping how teams approach automation and quality.

• Human-Only Intelligence: For decades, QA engineers manually wrote and maintained every test case. This era was dominated by tools like Selenium and Cypress, where automation meant writing code rather than reducing human effort. Tests relied on fragile selectors, XPath, and locators that broke with every UI change. Companies deployed large QA teams and bought expensive automation suites, yet still spent millions fixing flaky tests and chasing false positives.

• Human-Directed AI: The next step came when AI began assisting human engineers. These QA Engineer AI workflows improved speed but still required humans to define strategies and write scripts. As detailed in the last article Best AI Testing Tools in 2025, this stage was a partial improvement. AI accelerated test authoring, but humans remained in control. It was faster manual work, not true autonomy.

• Human-Verified AI: The current era, defined by Gen AI QA Engineer systems like Bug0s AI QA Engineer, has flipped the paradigm. AI now drives testing independently, generating and maintaining coverage automatically. Humans act as verifiers, adding strategic oversight and contextual understanding. This hybrid model blends AI scale with human precision for production-grade reliability.

QAs shift from manual to human-verified AI mirrors the rise of the AI QA Engineer. Tools like Bug0 have proven that when AI takes the lead and humans validate, testing becomes faster, smarter, and finally scalable.

The rise of AI + human hybrid models

Imagine a pilot and co-pilot. The AI takes control of navigation, flight paths, and monitoring. The human verifies, strategizes, and ensures safety.

That is exactly how hybrid QA models work.

AI agents explore the app, detect issues, and build coverage. QA experts validate tricky UX paths or business-critical logic. The result is predictable quality and confidence at enterprise scale.

Bug0 and QA Wolf take two very different paths to the same goal. Bug0 uses natural language-based Playwright agents to generate and heal tests intelligently. Its AI takes the lead, while its forward-deployed QA team verifies results. This is an AI+Human model built for speed and scale. This approach allows Bug0 to serve both startups and growth-stage companies effectively, providing enterprise-grade QA without enterprise-level overhead.

In contrast, QA Wolf operates as a Human+AI platform. Its model still relies on human engineers who write and maintain tests using traditional identifiers like IDs, selectors, and locators. While it offers reliability and structure, QA Wolfs human-heavy setup can become expensive and less flexible for early-stage startups.

Both tools blend automation with human input, but Bug0 reverses the equation. It lets AI lead while humans refine. It scales up effortlessly from small teams to Series B companies, offering an adaptable model that grows with your product.

Rainforest QA, on the other hand, represents the older, more traditional managed QA model. It operates more like an agency, deploying human testers supported by light automation. While it offers scale through manpower, it lacks the deep AI-native foundation that newer tools like Bug0 bring to the table.

This mix of old-school human-heavy agencies like Rainforest and next-gen platforms like Bug0 and QA Wolf shows how fast the QA world is changing. Bug0s AI+Human structure delivers scalable intelligence. QA Wolfs Human+AI balance delivers structured reliability. Rainforest, though reliable, reflects the past era of manual QA packaged as a service.

This new wave of hybrid QA proves that when AI owns execution and humans guide judgment, testing finally becomes as fast as development.

What makes a true AI-native QA Engineer

A true AI-native QA Engineer works the way Bug0 does. It is built AI-first, not AI-added. It combines agentic reasoning with human judgment, delivering continuous, production-ready QA.

• Learns user flows from observation instead of manual scripting.

• Generates Playwright tests through natural language instructions.

• Uses self-healing logic to repair broken selectors automatically.

• Verifies results via forward-deployed QA pods trained on customer context.

• Runs hundreds of parallel tests integrated directly into CI/CD pipelines.

This is what separates Bug0s model from AI-assisted tools. Instead of adding AI on top of traditional frameworks, it lets AI lead and humans refine. The result is an adaptive QA system that gets smarter and more reliable with every run.

Skills and tools behind an AI QA Engineer

Under the hood, an AI QA Engineer uses:

• Multi-agent orchestration to plan, generate, and heal tests.

• LLMs to turn natural language into executable logic.

• Playwright for cross-browser execution at scale.

• Deep integrations with GitHub, Slack, and CI/CD workflows.

For testers, this is the QA to AI Engineer path. Learn how AI agents reason, how they debug failures, and how they adapt over time.

This shift turns QA engineers into strategic operators guiding AI systems. You will shape how your testing evolves, not just how it runs.

A day in the life

1. The system observes your app and learns your user journeys.

2. It builds a library of tests automatically, with no code needed.

3. Every commit in each PR triggers automated test runs through CI/CD pipelines. Reports are generated instantly. Notifications are sent directly to GitHub, GitLab, Slack, Linear, or wherever your team works.

4. No more waiting for days or weeks for QA teams to review manually, fix scripts, and report bugs.

5. Issues are flagged automatically, validated by Bug0s QA pods, and ready for immediate review by developers.

6. It self-heals broken selectors or DOM shifts, ensuring tests remain consistent across versions.

7. This speed justifies every dollar spent on tools like Copilot or Cursor. Developers ship faster with full confidence that their code is tested.

8. Feedback from each run feeds the model for continuous improvement.

Every loop makes it smarter. Over time, your AI QA Engineer integrates deeper into your workflow. It matches the velocity of your development team and ensures QA never slows you down.

AI QA Engineer vs. The Fully Autonomous AI QA Engineer

Modern QA now divides into two practical models: the AI QA Engineer and the Fully Autonomous AI QA Engineer.

Bug0s AI QA Engineer model defines the new standard for practical autonomy. It blends AIs adaptability and reasoning with a human layer for judgment. Every PR automatically runs end-to-end tests, posts reports to GitHub, GitLab, or Slack, and integrates with developer tools like Linear. Developers act instantly instead of waiting days for manual QA feedback.

By contrast, a fully autonomous AI QA engineer chases complete hands-off automation but often lacks reliability in real-world products. These systems, sometimes referred to under various names like an AIQA, Autonomous AI QA Engineer, risk missing edge cases and business logic without human verification.

Bug0s AI+Human balance delivers the reliability enterprises need and the agility startups love. It is the most scalable and dependable QA model today.

The True Cost of QA: Salary, Jobs, and Modern Skills

AI QA Engineer Salary & The True Cost of Hiring (2025)

The AI QA Engineer salary is a major factor for companies in 2025, but it's only one part of the equation. As detailed in a recent analysis on the true cost of hiring a QA engineer, the actual annual investment is much higher. When you factor in benefits, recruiting costs, tools, and the hidden cost of developer time spent on bug triage, the total expenditure for a single QA engineer in the U.S. can easily range from $102,000 to over $196,000. This financial reality is pushing companies to seek more efficient, scalable alternatives to traditional hiring.

AI QA Engineer Jobs and Job Openings

As companies grapple with the high cost of manual QA, expect a spike in AI QA Engineer jobs and AI QA Engineer job openings. These roles are for professionals who can manage and scale AI-native testing systems, with a strong emphasis on expertise in modern frameworks like Playwright. The focus is shifting from writing scripts to orchestrating intelligent automation, blending SDET practices with AI model interpretation.

AI QA Engineer Job Description

A forward-looking AI QA Engineer job description typically includes:

• Building, monitoring, and refining AI test agents.

• Proficiency in Playwright, including its test generator and new agentic features.

• Designing self-healing strategies.

• Managing human-in-loop verification.

• Connecting test insights into CI/CD for faster iteration.

• Reporting performance and anomaly trends across builds.

AI Courses for QA Engineer

If you are upskilling, the most critical tool to master is Playwright. For any aspiring QA AI Engineer, the path forward is to learn Playwright directly from the official documentation at playwright.dev. Playwright is the future of testing because it simplifies complexities that older tools struggled with. Its powerful auto-waits eliminate most flakiness, it handles single-page applications seamlessly, and it offers deep browser context control. With the introduction of Playwright's Test Agents, you can now generate robust tests using natural language. This makes the process faster and more intuitive than ever before. Explore AI courses for QA Engineer that are heavily focused on Playwright automation and AI integration.

The agentic and generative future

The gen AI QA engineer is rising fast.

Future frameworks will combine multiple AI agents that coordinate. These will include a planner, generator, healer, and reviewer. Each plays a role in continuous, intelligent QA.

Natural language test creation will become standard. The system will analyze every commit, update test coverage automatically, and simulate user flows without human intervention.

The AI QA Engineer of the near future wont just execute tests. It will reason about them, prioritize coverage gaps, and learn from production logs. Thats the real promise of continuous QA, which is a system that evolves with your app.

Definition box

AI QA Engineer: an AI-native testing system that autonomously creates, maintains, and validates tests with human-in-loop verification. Bug0 is a production-grade example of this approach using a forward-deployed team model.

Bug0 in action

Bug0 is the first production-grade AI QA Engineer, already helping Series A and B companies ship faster and leaner. Here's how it delivers on its promise of AI-native, human-verified testing:

• Rapid Coverage: Achieves 100% critical flow coverage in the first week and expands to 80% total coverage within a month.

• Massive Parallelization: Executes over 500 parallel Playwright tests in under 5 minutes, integrated directly into the CI/CD pipeline.

• Agentic Reliability: Uses self-healing AI agents to ensure tests are always up-to-date and reliable.

• Human Verification: Includes dedicated QA pods that provide the human context and verification needed for production-grade confidence.

Bug0 combines autonomous AI with human oversight into a single managed service. It eliminates setup pain and gives teams immediate clarity and control. Learn more.

Conclusion

The AI QA Engineer marks the next chapter of how we test software. AI takes care of repetition. Humans focus on insight. Together, they form the foundation for dependable, high-speed development.

Teams adopting this hybrid approach gain something crucial: peace of mind that every release is battle-tested by both machine precision and human intuition.

FAQs

Are companies hiring AI QA Engineers right now?

Yes. Companies across SaaS, fintech, and healthtech are actively hiring for AI QA Engineer jobs to modernize quality processes. Many of Bug0s customers are already expanding their QA teams with AI-native roles focused on automation and Playwright testing.

Whats the difference between AI QA Engineer and fully autonomous AI QA Engineer?

A fully autonomous AI QA Engineer removes humans completely. The AI QA Engineer model, like Bug0s, includes human verification for greater reliability and context awareness in production systems. This hybrid approach balances AI automation with human judgment.

What should an AI QA Engineer job description include?

A modern AI QA Engineer job description includes ownership of AI pipelines, self-healing frameworks, CI/CD integration, and QA verification design. Teams using Bug0 often look for engineers experienced with Playwright and AI-assisted testing workflows.

Where can I find AI courses for QA Engineer?

Explore hands-on programs teaching Playwright, LLMs, agentic design, and autonomous testing frameworks. Search for AI courses for QA Engineer or AI QA Engineer course to upskill. Bug0s blog and Playwright documentation are great places to start learning.

Im a QA how do I become an AI Engineer?

Follow the QA to AI Engineer journey. Learn Playwright, agentic logic, and model evaluation. Practice building AI test agents until you can connect automation to business outcomes. Bug0s training content and case studies outline this career path clearly.

Why do I see terms like Spur AI QA Engineer in my search?

You might see terms like Spur AI QA Engineer, Spur AI QA Engineer official website, or homepage because the market is curious and new players are emerging. Its important to evaluate which platforms are truly AI-native and which use surface-level AI features. Bug0 is the first production-grade platform implementing this concept at scale.

How does an AI QA Engineer differ from traditional QA automation?

Traditional QA automation relies on manual scripting and brittle locators. An AI QA Engineer, like Bug0s model, learns user flows, generates Playwright tests autonomously, and self-heals reducing human effort while improving reliability and coverage.

What are AI testing tools?

AI testing tools use artificial intelligence to automate how tests are created, run, and maintained. The basic promise: less manual scripting, fewer flaky tests, faster feedback on whether your app actually works after a deploy. In practice, the "AI" ranges from a GPT wrapper that writes Cypress boilerplate to a fully autonomous agent that generates, heals, and runs tests without human involvement. The gap between those two extremes is what this article is about.

In 2024, most "AI testing" meant a GPT wrapper generating flaky Cypress scripts. You'd spend an hour cleaning up the output. Then another hour debugging why it failed in CI.

2025 changed that. Real agentic tools emerged. Vision models that interpret your UI the way a human tester would. Self-healing selectors that survive redesigns. Multi-agent frameworks like Playwright Test Agents that plan, generate, and fix tests independently.

Now, in 2026, the question isn't whether AI testing works. It's which category of tool matches your team's reality. The term "AI" still gets used as marketing more than a technical descriptor. Some tools are true autonomous systems. Others sprinkled machine learning on a legacy framework and updated their landing page. This post separates signal from noise across the real landscape of AI tools for testing in 2026.

The intelligence behind testing has shifted

Where the "intelligence" comes from tells you everything about a tool's capability.

For decades, testing intelligence was 100% human. QA engineers wrote every script. Maintained every selector. When a button moved three pixels, the test broke. The tools were dumb executors. This is still how most teams operate.

Then came the assistant era. AI helped humans write tests faster. Smart locators, element discovery, auto-maintenance. Useful, but the human still decided what to test, when to test, and what a failure meant. Most "AI-assisted" tools on the market today are still here.

The interesting shift is what's happening now. The best tools generate their own intelligence. They observe user behavior in production, figure out which flows matter, and build tests without anyone asking. The human stops writing scripts and starts reviewing results. You go from operating a tool to auditing an outcome. That's a fundamentally different job.

Understanding where a tool falls on this spectrum, executor, assistant, or autonomous agent, is the single most important factor when choosing an AI-powered software testing tool.

The AI testing landscape in 2026

Understanding the nuances between different AI software testing tools is critical for any team investing in QA tooling. It helps you look past marketing claims and evaluate how much of the testing burden actually gets removed. For those building their first QA strategy, the fundamentals of software testing basics are a good starting point.

Every AI automation testing tool on the market falls into one of five categories.

This categorization answers one question: how much of the testing process is actually automated, and how much still depends on humans to create, maintain, and validate?

What makes a tool truly AI-native

AI-native tools are built differently from the ground up. No pre-written scripts. No static element locators. They adapt like a human tester would.

The capability that separates real AI-native tools from everything else is autonomous test generation. The tool analyzes real user traffic, identifies which flows matter most, and generates tests. No human writes a script. This sounds like magic until you realize it's pattern matching on production clickstreams. The hard part isn't generating the test. It's generating one that's stable enough to run 500 times in CI without a false positive.

Then there's self-healing. Every tool on this list claims it. Your #submit-btn becomes .btn-primary? The good ones update the locator and pass. The bad ones flag it as a failure and email you at 3am. Here's a useful filter: ask vendors for their self-heal success rate on production apps, not on their demo todo list. Most won't give you a number. The ones that do are worth talking to.

Continuous learning across runs? Every tool claims this, few prove it. Fast CI/CD integration? Table stakes in 2026. These aren't differentiators anymore.

That's the core difference between the best AI test automation tools and the rest. A tool that helps you do a task versus a system that owns the outcome.

The rise of AI + human hybrid models

A powerful category has matured in the past year: AI tools paired with a human verification layer. The premise is simple. Pure automation can't catch everything.

These platforms combine the speed and scale of AI with the judgment of human QA experts. The AI does the heavy lifting: exploring the app, generating tests, running them continuously. Human experts verify edge cases, investigate complex business logic failures, and catch subtle UX issues that AI misses.

Bug0 is built on this model, but it started self-serve. Bug0 Studio lets you describe a test in plain English or upload a video of your user flow. It generates Playwright-based tests that self-heal when your UI changes. $250/mo, pay-as-you-go. For teams who want the outcome without the involvement, Bug0 Managed adds a Forward-Deployed Engineer pod that handles planning, verification, and release gating. $2,500/mo flat.

QA Wolf and Rainforest QA operate in similar territory, offering managed QA services on top of their automation platforms.

I think this model wins for most teams under 200 engineers. You don't have the headcount to build and maintain a testing platform. You don't want to hire three QA engineers just to keep your regression suite alive. You want someone to tell you "your checkout flow broke after the last deploy" before your customers do.

Deep dive by category

AI-native + human layer (managed AI QA)

Self-learning automation plus expert validation. AI agents with human-in-the-loop QA for a complete, managed solution.

• Bug0: Self-serve via Bug0 Studio: describe tests in plain English, upload video, or record your screen. Playwright-based, self-healing, from $250/mo. For done-for-you QA, Bug0 Managed adds a dedicated AI QA Engineer pod. 100% critical flow coverage in weeks. $2,500/mo flat.

• QA Wolf: Managed service that reaches 80% test coverage by pairing their testing library with human QA engineers.

• Rainforest QA: QA-as-a-service combining automation with a global community of human testers.

AI-native (autonomous)

Full autonomy. AI agents crawl your app, learn patterns, and generate regression suites without scripting. For teams that want to go completely hands-off.

• Momentic: No-code AI that generates and maintains tests by observing user traffic.

• ProdPerfect: Analyzes real user behavior to build, run, and maintain E2E test suites.

• Meticulous: Catches UI regressions automatically by replaying real user sessions against new code changes.

• Testers.AI: Autonomous testing where vision AI agents discover, write, and execute tests with minimal human intervention.

AI-assisted testing

This is the biggest category and the most crowded. AI helps testers write or maintain tests faster, but human input still drives the process. Many generative AI testing tools fall here, using LLMs to turn plain-language prompts into test scripts.

Three stand out:

• TestRigor: The best plain-English test authoring experience. You write "login with valid credentials and verify the dashboard loads." NLP handles execution. If your QA team doesn't write code, start here.

• Mabl: Low-code, cloud-hosted, genuinely good onboarding. ML-powered auto-healing keeps tests running after UI changes. The ceiling is low for complex apps, but the floor is high for teams new to automation.

• Autify: Monitors UI changes and auto-maintains tests. Good for teams transitioning from manual testing who need something that doesn't break every sprint.

The rest of this category is a long tail of tools solving similar problems with different packaging (if I listed the pros and cons of all 15, we'd both be here all day): Virtuoso QA (NLP + self-healing), Functionize (ML for test prioritization), ACCELQ (codeless for CD pipelines), Testsigma (unified web/mobile/API), BlinqIO (Cucumber-focused), BrowserStack Test Observability (root-cause analysis), LambdaTest KaneAI (NL test generation), and TestResults.io (visual AI locators). They're all fine. None are transformative.

Legacy + AI-flavored tools

Traditional testing platforms that added AI to stay relevant. ML-based locators or dashboards, but the core is still a legacy framework.

• Katalon: Bolted AI features like smart wait and self-healing locators onto its existing platform.

• Tricentis: Enterprise-focused platform with AI for risk-based analysis and improved object recognition.

• Testim: Now part of Tricentis. Uses ML to speed up test authoring, execution, and maintenance.

Visual and niche AI testing

Visual regressions, accessibility bugs, and layout issues that functional tools miss entirely.

Applitools is the gold standard here. Their Visual AI compares screenshots across browsers and viewports using layout-aware comparison, not pixel matching. It's overkill for 90% of early-stage startups, but if your users care about pixel-perfect UI (finance, healthcare, e-commerce), nothing else comes close. Reflect.run offers a lighter alternative, combining functional and visual testing with automatic change detection.

Comparison matrix

Trends shaping AI testing in 2026

The landscape of ai automation testing tools is shifting fast. Two developments stand out this year:

Multi-agent testing frameworks went from research to production. What started with Playwright's Test Agents has spread across the ecosystem. A planner explores the app and creates a test plan. A generator turns it into code. A healer fixes tests that fail. This isn't a monolithic AI. It's composable, modular, and you can swap out individual agents. The principles of writing effective QA documentation still matter here. Someone has to review what the planner decided to test.

Playwright MCP changed the build vs. buy equation. The Model Context Protocol lets AI agents control browsers through structured APIs instead of screen scraping. 2-5KB of accessibility tree data versus 500KB-2MB screenshots per interaction. 10-100x faster. Every team building AI testing internally now evaluates whether MCP makes DIY feasible, or whether the operational overhead still favors buying. This is the most consequential technical shift in testing since Playwright replaced Selenium's WebDriver protocol with CDP.

Three smaller trends worth tracking: AI penetration testing tools that simulate attack vectors are moving out of research labs. Free AI testing tools and open-source frameworks make agentic testing accessible to solo developers. And natural language test generation inside IDEs is blurring the line between "who writes tests" and "who defines quality," letting product managers contribute directly.

How to choose the right tool

Choosing the right AI tool for automation testing depends on team size, goals, and resources. This guide focuses on AI-driven E2E platforms, but a complete QA strategy includes stack-specific tools too. PHP teams have code-level QA tools for static analysis and unit testing that complement E2E solutions.

For the E2E layer, one fundamental question: continue with DIY QA, or offload the process entirely?

No QA headcount. Managed AI QA gives you the coverage of a full QA team without the hiring. Engineers stay focused on building.

Existing QA team. AI-assisted tools like TestRigor or Mabl boost your team's efficiency without changing workflows.

Enterprise. AI-native platforms with SOC2 compliance handle complexity, security, and scale across multiple teams.

Design-heavy products. Visual AI tools like Applitools catch what functional tests miss.

Where to start tomorrow

Stop evaluating tools based on their demo. Record your actual app's most painful user flow, the one that breaks every other sprint. Upload it or describe it in plain English. Run the generated test in staging. Then change something in the UI and run it again without updating the test.

That second run tells you everything. If it passes, the self-healing works. If it fails with a clear alert, the failure mode is honest. If it silently passes with wrong assertions, walk away.

The AI testing market has real options now. The trap is spending three months evaluating twelve of them. Pick the category that matches your constraint, trial one tool for a week, and ship it into CI. You'll learn more from one real pipeline run than from ten vendor demos.

FAQs

Are AI testing tools actually autonomous or is it marketing hype?

Mostly hype. Most tools marketed as "AI testing" are AI-assisted at best. They help humans work faster. True autonomy means the system watches how your users behave, figures out what to test, and generates or heals tests without anyone asking. Only a handful of tools do this today. The rest are using "AI" the way food companies use "natural."

How do AI + human hybrid QA models differ from regular automation?

A tool gives you software. A managed service gives you an outcome. With hybrid QA, the vendor's AI generates and heals tests while their human team writes, maintains, and verifies results. You get a Slack message when something breaks. With a regular automation tool, you get a dashboard and a backlog of maintenance work. The trade-off is cost versus control.

Are AI testing tools suitable for startups or only large enterprises?

Both. Startups need coverage without hiring. Enterprises need scale across teams. Different reasons, same tools.

Do I need AI testing tools if I already have a QA team?

Probably not an autonomous platform, but AI-assisted tools can make your team faster. The bigger question is whether your QA team is spending their time on judgment calls (exploratory testing, release decisions) or on maintenance (fixing selectors, re-running flaky tests). If it's mostly maintenance, AI can take that off their plate.

How fast do AI-powered QA platforms deliver results?

Most AI-native or managed platforms automate 100% of critical flows within a week. 80% overall coverage within a month. Compare that to the 3-6 months it typically takes to build a meaningful Playwright suite from scratch.

Can AI testing tools replace human testers?

No. And the teams that think they can are the ones filing P0 bugs in production.

AI catches regressions. It catches selector breakage, broken flows, API failures. It's good at "did the thing that worked yesterday still work today?" What it can't do is look at your checkout page and notice that the discount code field is technically functional but visually buried under a fold that 80% of mobile users will never scroll past. Or that your date picker works perfectly in every test but confuses European users because it defaults to MM/DD/YYYY. Or that the loading spinner runs for 4 seconds on a page that used to load in 1, and that's not a bug by any test assertion, but your users will notice.

The tools handle repetitive coverage. Your team handles the judgment calls. Trying to eliminate the human entirely is how you end up with a green CI dashboard and a support queue full of angry customers.

How do AI testing tools handle flaky tests?

AI-native systems use self-healing locators. When attributes change, the AI identifies elements using text content, DOM position, visual location, and surrounding structure. Flakiness from selector breakage drops to near zero. Flakiness from timing issues and network instability is a different problem, and most tools still struggle with it.

What is next for AI in software testing?

Multi-agent systems. Different AI agents for planning, generation, debugging, and healing, each specialized, working together. Playwright MCP gives these agents structured browser control. QA stops being a phase and becomes a continuous, autonomous feedback loop on every deploy.

API documentation typically includes code examples, tutorials, and detailed information about functions, classes, and return types. It offers developers all the necessary information to create integrations with the API and make API calls with the software.

API documentation provides a clear explanation of the endpoints, describes the purposes for using them, and offers specific examples of their usage.

Tips to write great API documentation

For documentation in general, the simple rule to follow is: keep it simple, know the personas reading the documentation, and document every detail.

For API documentation, however, this is the part that will show developers how to walk the talk, and using this is how you will onboard more developers to your tool.

Here are five top tips to write great API docs:

1. Understand the API: Before you start documenting, make sure you have hands-on experience with the APIs. Use it to test endpoints and get a first-hand understanding of how it works. This will help you guide users accurately, and improve the overall quality of your documentation.

2. Use consistent naming conventions: Ensure endpoints, parameters, and response fields follow a standardized naming convention (e.g., camelCase or snake_case) and maintain consistency across the API.

3. Include every detail: Include every detail needed to correctly learn and build with the APIs. Explain authentication methods (like API keys or OAuth) and any permissions needed for each endpoint. Also, list HTTP error codes (such as 400, 404, 500) and what they mean for each endpoint. Add troubleshooting tips for common problems to help users fix them on their own.

4. Add examples: The API docs should be written so that developers can copy and paste the examples and get them running. Make sure to include examples in multiple languages and frameworks, and have an interactive API playground that makes it easy for developers to test the APIs.

5. Explain rate limits and usage quotas: Specify rate limits and quota restrictions for each endpoint to help users manage API usage effectively. This prevents unexpected throttling and ensures a smoother integration experience.

How OpenAPI and Hashnode Docs can help in writing good API documentation

If you've worked with REST APIs, you likely know OpenAPI and its benefits. If not, this article is a good starting point.

OpenAPI helps with:

• Generating documentation, tests, and mock servers

• Integrating with tools and services for better documentation

• Team collaboration and communication

• Enhancing API security and quality

Documenting APIs with OpenAPI is a great start, but your documentation needs more. This is where Hashnode Docs helps, making API documentation simpler and more interactive.

Hashnode Docs features that help in writing great API docs:

1. One-Click API reference setup and interactive playground - With Hashnode, teams can easily create API reference docs by importing OpenAPI or Swagger specs - all in just one click. This also creates a playground for you that lets developers interact with the API, run requests, and see live responses.

   

2. GitHub Sync: Manage your docs wherever you feel comfortable - in GitHub or directly in Hashnodes editor. The GitHub sync feature keeps both your codebase and docs up-to-date effortlessly.

   

3. Enterprise-level features: Hashnode offers enterprise features like version control, SOC2 and ISO 27001 readiness, and team collaboration tools that make managing your OpenAPI docs seamless and secure.

Conclusion

For devtool companies, having solid API documentation is key to getting more developers to use your tool. Make sure it follows all the tips from the article above, and pick the right tool to document it. APIs can quickly become outdated, and writing documentation at the same time can be a lengthy process, so choose tools or processes that make updates easier. That's where a tool like Docs by Hashnode comes in handy. It takes care of the heavy lifting, so you can focus on writing examples and other details.

I hope this article has given you a good idea of how to write effective API documentation.

What is OpenAPI?

OpenAPI, also called the OpenAPI Specification (OAS), is a standard way to define RESTful APIs. It lets developers create a structured, machine-readable description of their API, which can then be used to generate docs, client libraries, server stubs, and more. With OpenAPI, your APIs are easy to understand, simple to integrate, and well-documented for anyone who needs them.

Whether you're building a public-facing API or an internal service, OpenAPI helps bridge the gap between development and users, providing a clear roadmap for how your services are used.

Why good documentation matters for OpenAPI

Good documentation is key to using APIs effectively. Developers need more than just code they need context, examples, guidelines, and other information to help them integrate smoothly. Great documentation makes for a smooth onboarding experience, while poor docs can lead to endless support requests.

OpenAPI is both human-readable and machine-readable, which is a huge plus. You can use your OpenAPI definition to generate detailed docs, but not all tools are great at presenting the content in a user-friendly way. Traditional methods might need custom setups or force developers to juggle multiple tools to get the job done.

Meet Docs by Hashnode - Content engine for your OpenAPI needs

Hashnode's new docs product is built to simplify the whole API documentation journey - especially for teams using OpenAPI. It's designed to transform OpenAPI specs into beautiful, easy-to-use docs, combining speed, customization, and usability.

Key Features for OpenAPI Docs

1. One-Click API reference setup

   With Hashnode, teams can easily create API reference docs by importing OpenAPI or Swagger specs - all in just one click. This means you can go from raw API definitions to polished docs almost instantly, saving hours of manual work.

   

2. Rich Visual Editor

   The new docs product offers a WYSIWYG MDX editor, letting developers add rich context, examples, diagrams, and other content that elevates basic API docs. This editor makes sure you dont just document your endpoints, but also tell the story around their use.

   

3. Interactive API Playground

   Hashnode's API playground lets developers interact with the API, run requests, and see live responses. This hands-on element encourages experimentation and gives developers a quick way to learn how your API works.

4. Super-Fast Search and Ask AI integration

   Docs by Hashnode come with a blazing-fast Algolia-powered search so developers can find exactly what they need without any hassle. Plus, teams can upgrade to AI-powered search to make finding the right information even easier.

   

Why choose Hashnode for OpenAPI documentation?

• Speed and Convenience: Creating great OpenAPI docs shouldn't take forever. Hashnode's simple setup means rapid deployment, giving developers more time to focus on what matters.

• Customization for your team: Teams can fully customize the look, structure, and integration of their docs. Whether you need a sub-path like /docs or a complete headless setup, Hashnode's got you covered.

• Enterprise-Level Features: Hashnode offers enterprise features like version control, SOC2 and ISO 27001 readiness, and team collaboration tools that make managing your OpenAPI docs seamless and secure.

• Two-Way GitHub Sync: Manage your docs wherever you feel comfortable - in GitHub or directly in Hashnodes editor. The two-way GitHub sync keeps both your codebase and docs up-to-date effortlessly.

Make your OpenAPI docs shine

If your current OpenAPI docs feel lackluster or hard to use, Hashnodes docs product could be just what you need. It's designed for flexibility and rapid implementation, helping you create docs that scale with your APIs and engage your developer community.

With Hashnode's seamless integration, you can link your public or internal docs with your community blog or knowledge hub, creating one unified platform where developers can learn, discuss, and solve problems together.

Getting started is easy

Ready to see the difference in your OpenAPI docs? Docs by Hashnode is now available for startups, enterprises, and open-source projects. If you have existing docs with tools like Docusaurus, ReadMe, GitBook, or Mintlify, Hashnode even offers one-day migration support to make the switch smooth and easy.

Try Docs by Hashnode and transform how you document your OpenAPI specs. Visit hashnode.com/docs to learn more and get started today.

Conclusion

OpenAPI is an amazing asset for API design and collaboration, but great documentation is what makes it all work. Hashnode's new docs product is here to make that process as simple and effective as possible. With rapid setup, seamless integration, and a rich feature set, Hashnode helps you ensure your OpenAPI docs are as reliable and informative as your APIs.

Your developers deserve great docs, and so do your users. Hashnode is here to make that happen.

To begin, clearly outline your goals for the project. Whether you aim to increase monthly active users (MAU), enhance the product, or expand the community, having a clear direction is crucial.

Remember that an open-source project should truly embrace openness. It should be receptive to feedback, welcoming to contributions, and open to improvements.

All the successful projects that you see today (or even use today) have these 5 things:

1. Write good documentation

Building a technical project and writing documentation for it should be a simultaneous process. You might be building the most helpful solution out there, but without documentation, you wont be able to onboard developers. We all know that documentation can be an extensive process, and to ease your job, you should opt for tools that make it easier for you to document, manage, and build effective documentation.

If you're looking for tips on writing good documentation, check out this article I wrote on 5 Tips to Write Good Developer Documentation.

Once you know how to write documentation well, you should find a tool that:

• Offers a great developer experience

• Includes AI features like assisted writing, search, and support assistance

• Supports markdown

• Syncs with GitHub (so people can contribute to your docs)

• Provides interactive code blocks and API playgrounds

Docs by Hashnode offers all of it along with a free lifetime access for all open-source projects.

If you would like to see more of Docs by Hashnode, watch this webinar here 👇

2. Build a community

Community forms the foundation for most open-source projects. They not only help you give direction to your product and build it, but also help you reach your target audience through word of mouth. A lot of open-source tools that I use today are because someone told me, Oh, you should use this open-source alternative. Invest time in building that community.

Key things that work out are:

• Being empathetic with your community members. Making them feel welcome and heard.

• Setting up channels for them to communicate. It does not need to be something fancy. You can start with GitHub discussions and then maybe move to Discord or any forum of choice.

• Communication. Communicate with your community members about the roadmap, the features you are shipping, and the problems you are facing. They will feel like they are a part of it, and that is what the true open-source spirit is about.

3. Be active and responsive

Maintaining an open-source project is challenging, and staying consistent is particularly tough. However, the health of your project relies on how active it is.

Here are some methods to maintain activity:

• Push frequent updates.

• Publish changelogs monthly/weekly.

• Respond to bug reports or feature requests.

Although these tasks may seem daunting, you can use tools and automation to assist you.

For instance, if you have bug reports or feature requests and users are waiting to be assigned, you can implement a GitHub bot that assigns users to issues when they use a command like /assign or /take.

Heres what the Kubernetes community does:

4. Be open

The entire idea of open-source is to collaborate, have more people contribute, and support the community.

Some must-haves while building your open-source projects are:

• A good README - Contributors and users should know what your project is about and how to use it from the start, which is why a good README is essential.

• Have a contributing guide - You want more contributors to contribute to your project and improve it. The best way to do that is by writing a contributing guide. Follow this guide by GitHub to learn how to write one.

• Have a License - Include an open-source license that allows others to use, copy, modify, and contribute to your project. This is the first thing you should do when creating an open-source project. Read more about it here.

5. Have automations in place

CI/CD is an important concept in software development and helps to avoid bugs and code failures. Since it requires less human intervention, it is even more important in open-source projects.

One of the most common examples of CI is: Each time you receive a pull request, the tests are automatically run, and it clearly shows if all the tests pass with the new patch or if something needs to be fixed. This is useful for both contributors and maintainers. You get to maintain a certain quality for PRs, and even contributors get to know if something is breaking or not.

Heres a list of CI services that you can use for your projects 👇

Ending notes

Maintaining an open-source project is a big feat, and I am proud of each one of you for your contributions. However, it requires a lot of commitment and patience to get the first big hit. The worst part of open-source is having a great product, high monthly active users, and checking all the boxes for a good open-source project, yet not having enough funds to run it.

We, at Hashnode, are doing our part to contribute to the open-source community. We recently launched our documentation tool - Docs by Hashnode, and we are offering it for free to all open-source projects (of any size and number).

All you need to do is fill out the form below, and either I or somebody from the team will reach out to you!

In this article, we will learn how to generate a summary of the technical articles you write on Hashnode, and post it on X.

We covered this in a live webinar. If you prefer a video format, head over to our YouTube channel:

Technologies that will be used to build the solution:

• Hashnode Webhooks

• Next.js

• X API

• Vercel AI SDK

What are Webhooks?

A webhook is a way to automate responses in software. Theyre like "event-based APIs." This means when something happens, like a new post created or a specific action, the webhook triggers a response as its set up to do. Webhooks are great for real-time communication and can activate actions in other applications based on certain events.

Hashnode's webhook feature lets you get instant notifications for specific events related to your publication. You can set up webhooks to watch for six main events:

• Post published

• Post deleted

• Post updated

• Static page published

• Static page edited

• Static page deleted

Getting started

The application flow is simple: Hashnode webhook fetches article details, sends them to Vercels AI SDK to summarize and generate a TL;DR, and then posts it using the X API.

Step 1: Fetching posts from Hashnode

Before we move on to fetching posts from Hashnode, you need to add a webhook and you can do that from the blog dashboard.

The video below shows how you can add it:

Fill in the following details:

• Endpoint URL: Should look something like https://example.com/path

• Events: Check the post_published box.

• Secret: Keep it copied, as we will need it for the next steps.

Note: Make sure to create an.env.local file. You can copy the keys from .env.example file and add the values.

The next step is to write handler for the webhook and verify it.

Why you need to verify your webhooks?

Webhooks are simply REST APIs deployed on your server, making them public. You only want these endpoints to be called by Hashnode when an event like post_published occurs. You definitely don't want anyone else to call the webhook endpoint and publish a tweet on your behalf.

Every webhook you create comes with a webhook secret that you copied above. Hashnode sends the payload signed with a secret and also send the resulting signature in the headers of the request sent to your webhook endpoint.

To verify your signature, you need to write some logic, and we've got you covered! Click on the link that says Learn how it works, and copy the code block that starts with import crypto from 'crypto';. You will need to install the crypto npm package for this to work.

This code comes with a validateSignature function that can be used like this

const payload = await req.json();
// This is sent by hashnode with header
const signature = req.headers.get('x-hashnode-signature');
// The secret you copied
const webhookSecret = process.env.HASHNODE_WEBHOOK_SECRET;
const { isValid } = validateSignature({
    incomingSignatureHeader: signature,
    secret: webhookSignature,
});

Now if isValid is false you can return a 401 Unauthorized. If true you can proceed.

Once the webhook is created, we write the code that fetches the post using Hashnodes GraphQL APIs 👇

export const getPostById = async (postId: string) => {
    const response = await fetch('https://gql.hashnode.com', {
        method: 'POST',
        headers: {
            'Content-Type': 'application/json',
            'Authorization': `Bearer ${process.env.HASHNODE_ACCESS_TOKEN}`,
        },
        body: JSON.stringify({
            query: `
                query GetPostById {
                    post(id: "${postId}") {
                        id
                        title
                        url
                        content {
                            markdown
                        }
                    }
                }
            `,
        })
    })

    const data = await response.json();
    return data.data.post;
}

The getPostById function sends a POST request to Hashnode's GraphQL API to fetch details of a post by its postId, including the title, URL, and markdown content. It returns the post data as a JSON object after handling the response.

Step 2: Summarise the fetched article

Now that we have fetched the article details, the next step is to create a summary for it, and for that we will be using the Vercel AI SDK.

First, you need to generate an OpenAI API key and add it to your .env file.

Then, use the following code to generate the summary:

import { openai } from '@ai-sdk/openai';
import { generateText } from 'ai';

export const generateTLDR = async (content: string) => {
    try {
        const { text } = await generateText({
            model: openai('gpt-4-turbo'),
            prompt: `Summarize this article in a concise, engaging TLDR suitable for a tweet. Article content: ${content}`,
            temperature: 0.7, // Adjust for creativity; lower values make the output more deterministic
        });

        return { text: text.trim() };   
    } catch (error) {
        console.error('Exception caught while generating TLDR:', error);
        return { error: 'Exception occurred during TLDR generation. Please try again.' }    ;
    }
}

The generateTLDR function send the prompt to OpenAI to summarize a given article. The prompt specifically requests a concise and engaging TLDR suitable for a tweet, using the provided article content.

Step 3: Post the generated summary on X

The final step is to use the summary generated by OpenAI to create a post on X.

First, create a Developer account on the X developer platform. Then, create a project and within that project, create an app for free. After creating the app, generate and copy the keys and tokens.

Once that is done, move to your IDE and write the code below to make a post on X:

import { TwitterApi } from 'twitter-api-v2';

const client = new TwitterApi({
    appKey: process.env.X_API_KEY!,
    appSecret: process.env.X_API_KEY_SECRET!,
    accessToken: process.env.X_ACCESS_TOKEN!,
    accessSecret: process.env.X_ACCESS_TOKEN_SECRET!,
});

export const tweetThread = async (content: string, postUrl: string) => {
    try {
        const tweets = [
            content,
            `Here is the link to the post: ${postUrl}`
        ];
        const response = await client.v2.tweetThread(tweets);
        return { success: true, data: response };
    } catch (error) {
        console.error('Failed to tweet thread:', error);
        return { success: false, error: 'Failed to tweet thread. Please check the logs for more details.' };
    }
}

We initialize the X API client and define the tweetThread function, which takes the summary and a post URL as parameters. This function creates a tweet thread containing the summary from the generateTLDR function (that we generated in Step 2) and a link to the original post (that is fetched in Step 1), then posts it to X.

Resources

With that, you can see how to easily create a workflow using AI and webhooks to help you make social media posts from your articles.

Here are some resources to help you learn more:

• GitHub repository for the application

• Hashnode webhook docs

• X API docs

• Vercel AI SDK docs

Hashnode is a top publishing platform with millions of developers and companies using it to share articles on their blog and build product and API docs.

Why you should choose Hashnode for your developer documentation:

1. Easy to start Hashnode makes creating product and API docs simple. Just sign up and follow the steps on the homepage. You can use the hosted version of the docs and map it to a custom domain or subdomain. No coding, no infrastructure, no maintenance. The docs are SEO-optimized from the get-go.

2. Create multiple guides and API references in one project With Hashnode, you can create unlimited textual guides and API references under the same project. No need for separate licenses to cover all your products or projects.

3. Write docs like in Notion or Google Docs Hashnodes rich visual MDX editor lets you create and edit docs just like working in Notion or Google Docs. It supports all Markdown syntax for those who prefer it and offers visual tools like slash commands and formatting toolbars for easy styling.

4. Collaborative editing and comments Hashnode enables real teamwork. Your whole team can edit the same document simultaneously, leave review comments, and move quickly.

5. Headless mode for advanced customization Many developers leave products like Readme and GitBook because they don't offer headless options. Teams then turn to open-source tools like Docusaurus (which are tough to manage) or build docs in-house. Hashnodes headless mode lets your frontend team fork Hashnodes Next.js + TailwindCSS docs starter kit, which uses our GraphQL APIs. Your team can deploy this code anywhere, make unlimited tweaks, add custom components, and remove anything they dont need.

6. Faster documentation UX Hashnode's hosted and headless frontends are optimized for speed, performance, and SEO, ensuring a great experience for your users. Both perform exceptionally well on Lighthouse scores.

7. Ask AI search Every Hashnode docs site includes an Ask AI feature thats always up-to-date with your published content. Its accurate, free of hallucinations, and gives instant answers to user queries. This is my favorite feature! ;)

In addition to these features, Hashnode provides an advanced dashboard to track user analytics and insights from your docs. You can also create custom pages, add team members with different roles, and more. Create your developer docs for free.

OpenAPI Reference Setup

Creating an API reference from an OpenAPI spec or Swagger on Hashnode takes under 3 minutes.

1. Log in to your Hashnode account.

2. On your homepage, click the New docs button. If you already have a doc, skip this step.

   

3. Enter the docs name, choose a sub-domain (you can link a custom domain later), optionally add a logo, and click Create.

4. Your docs project will appear under the Docs section. Click the dashboard button to access it.

5. In the dashboard, go to the guides section.

6. Click the New button, then select New API reference.

7. Enter the OpenAPI spec URL, name your guide (e.g., Acme API reference), choose a slug like api-reference, and click Import and create.

Your API reference playground will be ready and live instantly. You can view and test it on your docs site. For easy access, you can add a link to the API reference in the Navbar settings in the dashboard.

We built Hashnodes docs product to help you create and scale developer documentation and API references that evolve with your code. Its designed for teams needing full control, customization, and Stripe-level qualitywithout the hassle. Sign up now and create a free doc today!

While you are in the discovery stage and moving towards the evaluation phase, this is where you should maximize focus on your docs. As they say, Documentation is the product. Your aim should be to have a great developer experience and to reduce the time to hello world (TTHW) to five minutes or less.

When developers discover your tool, you only have a few minutes to get their attention. You need to make sure that your docs provide a good developer experience, have more code, and offer a smooth developer journey.

In this article, I will share the top 5 tips on how to write effective developer documentation that you can follow to write good Stripe-like developer documentation.

Here are some of my favorite developer docs today:

1. Stripe - Every technical writer I know has taken reference from the Stripe docs. It is their simplicity, attention to detail, and structure that make it one of the best developer documentation.

2. Twilio - As somebody who has used Twilio a lot, one of the main reasons why I chose it over other alternatives is because of their quickstarts. Twilio has a great time to hello world (TTHW), which makes developers stick to it.

3. Microsoft - Microsoft docs are extensive and well-structured, showing Microsoft's commitment to developer education. The developer journey, module structure, and sandbox environments make their docs a complete package.

4. AWS - AWS docs are extensive and detailed. They include potential errors and solutions, preventing developers from getting stuck and switching between support forums, which also helps with developer retention.

5. Appwrite - Appwrite treats its documentation as a product. With tutorials and quickstarts in multiple frameworks, it's easy for any developer to get started. They excel in search and versioning, addressing common issues developers face due to version differences and updated methods not well-documented.

Lets see what made them to the top five developer documentation:

1. Knowing your audience.

The first step to writing good documentation is to know who you are writing it for. There are multiple types of developers depending on experience, tech stack, and more.

Who is your target audience? Who are you writing it for? To know the answers, build developer personas, and talk to the developer community.

Here are some ways to identify your audience:

1. Use social media (ask questions, do polls, gather as much information as you can).

2. If you have a developer community, send out user feedback forms and learn what your developers want.

3. Use community tools that help you follow a developers journey on your product, and use that to improve your product and docs.

2. Choosing the right documentation tool.

Developer tools grow fast, and you need to ship your documentation simultaneously. Investing in the right documentation tool is very crucial, as it can build or break the developer experience.

You need to make sure that you choose a tool that:

• Is easy to set up and get started (Documentation in itself is a lengthy process, and you cannot be stuck on getting started using a platform).

• Offers a good developer experience and also gives you all the control to tailor your own experience (like branding, embeddings, and more).

• Allows developers to experiment with your product. Developers want to build, and the best way to get them to use your tool is by providing a playground within your documentation. So, ensure the documentation tool you choose has an option to add a playground.

• Has AI tools that help you fix spelling, grammar, and other details (In this AI era, you shouldnt have to juggle multiple applications and extensions to fix a semicolon).

• Helps you understand how your documentation is performing and includes a feedback system.

A tool that does everything I just mentioned is Docs by Hashnode - you get all the goodness built within.

3. Writing code samples and API references that are easy to follow.

Less talk, more code should be your mantra when writing developer documentation. Every concept needs a code example or real-life implementation. Include API references, quickstarts, examples in various frameworks, and integrations.

If you are not aware, there is a credit card hell that most developer tools have. Before a developer gives you their card details, you need to convince them 100% that they need it and that you are actually a developer tool that makes their lives easier. It is your docs that will do the convincing.

Heres an example of documentation built with Hashnodes documentation tool that includes an API reference and a playground, making it easy for developers to follow:

4. Having a well-defined structure.

Your documentation should have a structure that is easy for your developer audience to follow. Take an example of the Microsoft docs, despite of being extensive, it is very structured. This helps in onboarding all levels of developers quickly, while also educating them about the product.

To improve developer documentation for beginners, you need to create a developer journey that makes it easy for them to build with your tool. Think of it like learning to write: we start with alphabets, then simple words, sentences, and paragraphs. Your developer documentation would follow a similar structurebasic introduction, installation, and a "hello world" program.

Your product adoption relies on both documentation and support. In fact, your documentation is the main source of truth for support. Having an AI-powered chatbot within your documentation can help developers ask questions and get answers instantly. This prevents them from switching between a community channel and the docs, allowing them to get help directly from the source.

The Requestly docs, powered by Docs by Hashnode, are a great example of how clear navigation and AI-powered search and chat can improve the developer experience with built-in features.

5. Introducing a feedback loop to improve your documentation.

Documentation is a continuous process. You need to keep improving it as new frameworks come up, software architecture evolves, and reading patterns change. The best way to do this is by having a feedback loop. Listen to your users and improve based on their input. This is why having a feedback system and tracking analytics is important.

This is where a product like Hashnodes documentation tool can help. With a built-in feedback system, you hear directly from users about your documentation's quality and areas for improvement. It also features a dashboard with detailed analytics and smart reports.

Conclusion

Writing developer documentation is challenging, even more so than writing code. You need to balance providing the right amount of information and enough examples while focusing on the developer experience.

Building developer experience in-house can be a very time-consuming process. Instead, you can choose a documentation tool like Docs by Hashnode that handles all of it for you, making it easier for you to focus on the content and the code.

I hope this article has helped you get a good start and understand the key areas that can make your documentation better, especially when writing user-friendly developer guides.

REST and GraphQL APIs are the most widely used ones in the industry, and in this article, we will cover the basics, along with a demo on how you can integrate GraphQL APIs.

TL;DR

Check out the webinar on GraphQL 101, that covers everything we mention in this article:

Understanding how GraphQL works

When working with REST APIs, data is retrieved from specific endpoints. Each endpoint has a defined structure for the information it returns. This means the data requirements of a client are embedded in the URL it connects to.

GraphQL takes a different approach. Instead of multiple endpoints with fixed data structures, GraphQL APIs usually expose only a single endpoint. This is possible because the data structure is not fixed. Instead, it is flexible and allows the client to specify what data is needed.

Key Concepts

• Schema: Defines the structure of your API, the types of data that can be queried, and how they relate to each other.

• Fields: Specific pieces of data you request from a type in a query.

• Queries: The method by which you request specific data.

• Mutations: Used to modify data (create, update, delete).

• Types: The building blocks of a schema, representing the shape and structure of data (e.g., String, Int, User, etc.).

Schema and types

A GraphQL server connects the client to data sources, allowing flexible and efficient data queries and manipulations. When a client sends a request, the server uses the GraphQL Schema to validate and execute it, then responds with the data or errors. The server relies on its Schema to handle these requests and define available operations.

Types are the building blocks of a GraphQL schema. They describe the shape of the data that can be queried. A GraphQL Type defines entities with their fields. Here are the different available types:

• Scalar Type

• Object Type

• Input Types

• Enumeration Type

• Union and Interface Type

• Lists and Non-Null

Let us understand it with an example query from Hashnode API, which checks if a custom domain is available or not:

query CheckCustomDomainAvailability($input: CheckCustomDomainAvailabilityInput!) {
  checkCustomDomainAvailability(input: $input) {
    domainAvailable
  }
}

In this example:

1. Schema elements:

   • CheckCustomDomainAvailability is the name of the query operation.

   • checkCustomDomainAvailability is a field on the root Query type in the schema.

2. Types:

   • CheckCustomDomainAvailabilityInput! is an input type. The ! indicates that it's a non-nullable type, meaning it's required.

   • There's an implied return type for the checkCustomDomainAvailability field, which includes a domainAvailable field. This return type isn't named in the query, but it exists in the schema.

Mutation

A mutation in GraphQL is an operation used to modify data on the server. While queries are used to read data, mutations are used to create, update, or delete data. Mutations are essential for any operation that changes the state of the data on the server.

Let us understand with an example. The acceptInviteToPublication mutation in Hashnode GraphQL APIs is used to accept an invitation to join a publication.

mutation AcceptInviteToPublication($input: AcceptInviteToPublicationInput!) {
  acceptInviteToPublication(input: $input) {
    success
  }
}

In this example:

1. mutation is the operation type, indicating that this is a mutation rather than a query.

2. AcceptInviteToPublication is the name of the mutation operation.

3. $input: AcceptInviteToPublicationInput! is a variable declaration. It specifies that this mutation expects an input of type AcceptInviteToPublicationInput, and the ! indicates that this input is required (non-nullable).

4. acceptInviteToPublication(input: $input) is the actual mutation being called. It's a field on the root Mutation type in the schema, and it takes the input argument.

5. success is a field on the return type of the acceptInviteToPublication mutation, a boolean indicating whether the operation was successful.

GraphQL Integrations with Client

Now that you have an idea of GraphQL schema, types, and mutations, lets go over several ways to make requests to Hashnode GrapQL API, for example. The same examples used for Hashnode GraphQL API can be used for all GraphQL APIs. Since our client application is mostly built with JavaScript, lets see how to make Graphql API requests with just Vanilla JavaScript before using URQL a graphql client for the final example.

Basic GraphQL Query

A basic query allows you to fetch specific fields from the GraphQL API. In the example below, well get the user Favourite and these fields name, username, profilePicture, and tagline from the Hashnode Graphql API.

const query = `
  query GetUserProfile {
    user(username: "Favourite") {
      id
      username
      name
      profilePicture
      tagline
    }
  }
`;

fetch('https://gql.hashnode.com/', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    query,
  })
})
.then(response => response.json())
.then(data => console.log(data))
.catch(error => console.error('Error:', error));

• query: Defined is the GraphQL query operation as a string.

• fetch: This sends a POST request to the GraphQL endpoint.

• URL: The Hashnode GraphQL API endpoint (https://api.hashnode.com/).

• Headers: The Content-Type is set to application/json

• Body: The request body includes the query serialized into JSON.

Query with Aliases

GraphQL aliases allow you to fetch the same field multiple times with different arguments or rename the results for better clarity. Lets see how we can achieve this below:

const query = `
   query {
      favUser: user(username: "Favourite") {
        name
      }
      anotherUser: user(username: "Haimantika") {
        name
      }
  }
`

fetch('https://gql.hashnode.com/', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    query,
  })
})
.then(response => response.json())
.then(data => console.log(data))
.catch(error => console.error('Error:', error));

• From the query favUser and anotherUser are aliases that rename the results, allowing you to query multiple users - (Favourite & Haimantika) in one request.

The result of the query would be in this structure, where you have different names of users with one request.

{
  data: {
    favUser: { name: 'Favourite Jome' },
    anotherUser: { name: 'Haimantika Mitra' }
  }
}

Query with Arguments

Arguments are inputs you provide to fields or queries to filter or modify the data you retrieve. They allow you to pass specific parameters to control the query results.

If you didnt notice, weve been using arguments in the previous examples to get the user information from a specific user - Favourite. In the example below, we pass two new arguments to a field - posts.

const query = `
  query GetUserWithPosts {
    user(username: "Favourite") {
      id
      name
      posts(page: 1, pageSize: 5) {
        nodes {
          id
          title
        }
      }
    }
  }
`;

fetch('https://gql.hashnode.com/', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    query,
  })
})
.then(response => response.json())
.then(data => console.log(data))
.catch(error => console.error('Error:', error));

Here, page: 1 and pageSize: 5 are arguments passed to the user field, telling the API to return five posts from the user publications on the first page.

Query with Variables

Queries with variables allow you to pass dynamic inputs into a query, making the query flexible and reusable instead of hard-coded like the previous examples. Heres how to query with variables:

const query = `
  query GetUserWithPosts(
    $username: String!, 
    $page: Int!, 
    $pageSize: Int!
  ) {
    user(username: $username) {
      id
      name
      posts(page: $page, pageSize: $pageSize) {
        nodes {
          id
          title
        }
      }
    }
  }
`;

const variables = {
    username: "Haimantika",
    page: 1,
    pageSize: 5
}

fetch('https://gql.hashnode.com/', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    query,
    variables
  })
})
.then(response => response.json())
.then(data => console.log(data))
.catch(error => console.error('Error:', error));

Explanation:

• Query Name: GetUserWithPosts is the query name that accepts three variables

• Variables: The query accepts three variables:

  • $username: String! a required string for the username.

  • $page: Int! a required integer to define the page of posts.

  • $pageSize: Int! a required integer to define the number of posts per page.

• Query: The query requests the id and name of the user, along with their posts id and title, using pagination (page and pageSize).

Query with Fragments

Fragments allow you to reuse query fields in different parts of the query or across multiple queries. In the example below, we have a fragment named PostDetails, which will be used for the type Post.

const fragment = `
  fragment PostDetails on Post {
    id
    title
    brief
    publishedAt
  }
`;

const query = `
  ${fragment}  # Include the fragment in the query
  query GetUserWithPosts($username: String!) {
    user(username: $username) {
      name
      posts(page: 1, pageSize: 2) {
        nodes {
          ...PostDetails  # Using the fragment here
        }
      }
    }
  }
`;


const variables = {
  username: "Favourite"
};

fetch('https://gql.hashnode.com/', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    query,
    variables
  })
})
.then(response => response.json())
.then(data => console.log(data))
.catch(error => console.error('Error:', error));

To see how fragment shines, in the same query, lets get the publication details of a blog using the same fragment PostDetails.

const fragment = `
  fragment PostDetails on Post {
    id
    title
    brief
    publishedAt
  }
`;

const query = `
  ${fragment}  # Include the fragment in the query
  query GetUserWithPosts($username: String!) {
    user(username: $username) {
      name
      posts(page: 1, pageSize: 2) {
        nodes {
          ...PostDetails  # Use the fragment here
        }
      }
    }
    publication(host: "blog.favouritejome.dev") {
      id
      title
      post(slug: "why-learn-nextjs-if-i-already-know-reactjs") {
          ...PostDetails # Use the fragment here
      }
    }
  }
`;


const variables = {
  username: "Favourite"
};

fetch('https://gql.hashnode.com/', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    query,
    variables
  })
})
.then(response => response.json())
.then(data => console.log(data))
.catch(error => console.error('Error:', error));

Mutation

As mentioned earlier, mutation operation allows for the modification of data. When creating, deleting or updating action needs to be done, we use a mutation.

With Hashnode API, all mutations require an authentication header to make sure the correct user is updating their data, and you can get your Personal Access Token from the developer settings.

Once youve got your Personal Access Token, lets see how we can create a draft post using the createDraft mutation from Hashnode API.

const mutation = `
  mutation CreateDraft($input: CreateDraftInput!) {
    createDraft(input: $input) {
      draft {
        id
        title
        slug
      }
    }
  }
`;

const variables = {
  input: {
    title: "My New Post",
    slug: 'new-post',
    publicationId: "PUBLICATION_ID",
    contentMarkdown: "This is the content of the post.",
    tags: [],
  }
};

fetch('https://gql.hashnode.com/', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'Authorization': `YOUR_PERSONAL_ACCESS_TOKEN` // Replace with your API key
  },
  body: JSON.stringify({
    query: mutation,
    variables
  })
})
.then(response => response.json())
.then(data => console.log(data))
.catch(error => console.error('Error:', error));

You need to get the PUBLICATION_ID from your dashboard URL:

Starter Kit Code Example

Now that you have a solid foundation of GraphQL operations, that is, query and mutations, lets go over the Hashnode starter-kit, to build with GraphQL in production. In the example, well be making use of the hashnode theme.

To follow along, kindly clone the starter-kit repository: https://github.com/Hashnode/starter-kit

We will be using Hashnodes GraphQL APIs, to list the followers our publication has, and this is how it will look 👇

Lets start by creating a new file in the queries folder: lib/api/queries/UserFollowers.graphql

query UserFollowers($username: String!, $page: Int!, $pageSize: Int!) {
  user(username: $username) {
    id
    followers(page: $page, pageSize: $pageSize) {
      nodes {
        ...User
      }
    }
  }
}

And the user fragment: lib/api/fragments/User.graphql

fragment User on User {
  id
  username
  profilePicture
  name
  tagline
}

In the pages folder, create a followers.tsx file with the following code:

import request from 'graphql-request';
import { GetServerSideProps } from 'next';
import Head from 'next/head';
import { useEffect, useState } from 'react';
import { useQuery } from 'urql';
import { AppProvider } from '../components/contexts/appContext';
import { Header } from '../components/header';
import { Layout } from '../components/layout';
import {
    PublicationByHostDocument,
    PublicationByHostQuery,
    PublicationByHostQueryVariables,
    PublicationFragment,
    UserFollowersDocument,
    UserFragment,
} from '../generated/graphql';

const GQL_ENDPOINT = process.env.NEXT_PUBLIC_HASHNODE_GQL_ENDPOINT;

type Props = {
    publication: PublicationFragment;
};

const Followers = (props: Props) => {
    const { publication } = props;

    const [page, setPage] = useState(1);
    const [followersList, setFollowersList] = useState<UserFragment[]>([]); // To append followers
    const [loadingMore, setLoadingMore] = useState(false);

    const [{ data, fetching }] = useQuery({
        query: UserFollowersDocument,
        variables: {
            username: publication.author.username!,
            page: page,
            pageSize: 20,
        },
    });

    // Effect to append new followers when data changes
    useEffect(() => {
        if (data?.user?.followers?.nodes) {
            setFollowersList((prev) => [...prev, ...data?.user?.followers.nodes!]);
            setLoadingMore(false); // Stop loading state after fetching
        }
    }, [data]);

    // Load more function to increment the page
    const loadMore = () => {
        setLoadingMore(true);
        setPage((prevPage) => prevPage + 1);
    };

    return (
        <>
            <AppProvider publication={publication}>
                <Layout>
                    <Head>
                        <title>Followers - {publication.title}</title>
                    </Head>
                    <Header isHome={true} />
                    <div className="feed-width mx-auto my-10 md:w-2/3">
                        <h1 className="mb-5 text-3xl font-bold">Followers</h1>

                        <div className="grid grid-cols-2 gap-2">
                            {followersList?.map((follower) => (
                                <div key={follower.id} className="flex gap-2 bg-slate-400/20 p-3">
                                    <img
                                        src={follower.profilePicture!}
                                        alt={follower.name}
                                        className="h-10 w-10 rounded-full"
                                    />
                                    <div className="flex-1">
                                        <h2 className="font-bold">{follower.name}</h2>
                                        <p>{follower.username}</p>
                                    </div>
                                </div>
                            ))}
                        </div>

                        {/* Load More Button */}
                        <div className="mt-5 text-center">
                            {!fetching && (
                                <button
                                    onClick={loadMore}
                                    className="bg-primary-600 rounded-full  px-4 py-2 text-white"
                                    disabled={loadingMore}
                                >
                                    {loadingMore ? 'Loading...' : 'Load More'}
                                </button>
                            )}
                        </div>
                    </div>
                </Layout>
            </AppProvider>
        </>
    );
};

export default Followers;

export const getServerSideProps: GetServerSideProps = async () => {
    const data = await request<PublicationByHostQuery, PublicationByHostQueryVariables>(
        GQL_ENDPOINT,
        PublicationByHostDocument,
        {
            host: process.env.NEXT_PUBLIC_HASHNODE_PUBLICATION_HOST,
        },
    );

    const publication = data.publication;
    if (!publication) {
        return {
            notFound: true,
        };
    }

    return {
        props: {
            publication,
        },
    };
};

Resources

If you have made it this far, we hope you have not only learned the basics but also how to integrate GraphQL APIs into your code.

Here are some resources to help you learn more:

• GraphQL documentation

• Hashnode API documentation

• URQL documentation

• Hashnode starter kit

Even if we all know the importance of having a portfolio, we often end up not building at all, because of contemplation or wanting to over-complicate it.

In this article, I will show you how you can build a simple yet effective portfolio using:

• HTML

• Tailwind CSS

• Hashnode and

• Vercel for deployment

You can either follow this guide or watch me build it live here:

Getting started

The first step in building a portfolio or any project is to have a clear design or structure in mind. For a developer portfolio, we need to include a homepage that introduces us and highlights our skills, a section showcasing our projects, a list of articles that we have written, and links to our social media profiles.

Here's how I envisioned it to be 👇

Let us divide it into three smaller tasks:

• Building the homepage that includes our bio, and projects.

• Using Hashnode to build our blog section

• Deploying it using Vercel.

Part 1: Building the homepage

To get started, make sure you have a repository setup on GitHub, and have cloned it on an IDE of your choice.

The next step is to install Tailwind:

1. On your terminal type npm install -D tailwindcss followed by npx tailwindcss init.

2. Add the paths to all of your template files in your tailwind.config.js file.

    /** @type {import('tailwindcss').Config} */
    module.exports = {
      content: ["./src/**/*.{html,js}"],
      theme: {
        extend: {},
      },
      plugins: [],
    }
   

3. Add the @tailwind directives for each of Tailwinds layers to your main CSS file.

    @tailwind base; 
    @tailwind components; 
    @tailwind utilities;
   

4. Run the CLI tool to scan your template files for classes and build your CSS npx tailwindcss -i ./src/input.css -o ./src/output.css --watch

5. On your index.html file, add <link href="./output.css" rel="stylesheet"\>

For this demo, we will be using Flowbite components to design the portfolio.
Here are the commands to get started:

• npm install flowbite

• On you tailwind.config.js file add flowbite as the plugin:

    module.exports = {
  
        plugins: [
            require('flowbite/plugin')
        ]
  
    }
  

• Before the end of the body tag, add the JavaScript code that powers the interactive elements: <script src="../path/to/flowbite/dist/flowbite.min.js"></script>

Building the header and the bio section:

<nav class="bg-white border-gray-200 dark:bg-gray-900">
    <div class="max-w-screen-xl flex flex-wrap items-center justify-between mx-auto p-4">
        <a href="https://www.linkedin.com/in/haimantika-mitra/" class="flex items-center space-x-3 rtl:space-x-reverse">
            <img class="w-10 h-10 rounded-full" src="img/hm.jpg" alt="Rounded avatar">
            <span class="self-center text-2xl font-semibold whitespace-nowrap dark:text-white">Haimantika Mitra</span>
        </a>
      <button data-collapse-toggle="navbar-default" type="button" class="inline-flex items-center p-2 w-10 h-10 justify-center text-sm text-gray-500 rounded-lg md:hidden hover:bg-gray-100 focus:outline-none focus:ring-2 focus:ring-gray-200 dark:text-gray-400 dark:hover:bg-gray-700 dark:focus:ring-gray-600" aria-controls="navbar-default" aria-expanded="false">
          <span class="sr-only">Open main menu</span>
          <svg class="w-5 h-5" aria-hidden="true" xmlns="http://www.w3.org/2000/svg" fill="none" viewBox="0 0 17 14">
              <path stroke="currentColor" stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M1 1h15M1 7h15M1 13h15"/>
          </svg>
      </button>
      <div class="hidden w-full md:block md:w-auto" id="navbar-default">
        <ul class="font-medium flex flex-col p-4 md:p-0 mt-4 border border-gray-100 rounded-lg bg-gray-50 md:flex-row md:space-x-8 rtl:space-x-reverse md:mt-0 md:border-0 md:bg-white dark:bg-gray-800 md:dark:bg-gray-900 dark:border-gray-700">
          <li>
            <a href="#home" class="block py-2 px-3 text-white bg-blue-700 rounded md:bg-transparent md:text-blue-700 md:p-0 dark:text-white md:dark:text-blue-500" aria-current="page">Home</a>
          </li>
          <li>
            <a href="https://starter-kit-ophg-git-new-portfolio-haimantikas-projects.vercel.app/blog" class="block py-2 px-3 text-gray-900 rounded hover:bg-gray-100 md:hover:bg-transparent md:border-0 md:hover:text-blue-700 md:p-0 dark:text-white md:dark:hover:text-blue-500 dark:hover:bg-gray-700 dark:hover:text-white md:dark:hover:bg-transparent">Blog</a>
          </li>
          <li>
            <a href="#projects" class="block py-2 px-3 text-gray-900 rounded hover:bg-gray-100 md:hover:bg-transparent md:border-0 md:hover:text-blue-700 md:p-0 dark:text-white md:dark:hover:text-blue-500 dark:hover:bg-gray-700 dark:hover:text-white md:dark:hover:bg-transparent">Projects</a>
          </li>

        </ul>
      </div>
    </div>
  </nav>
    <main class="max-w-4xl mx-auto flex flex-col">
    <section id="home" class="flex flex-col sm:flex-row p-20 items-center gap-8 mb-12">

    <h1 class="mb-4 text-3xl font-extrabold text-gray-900 dark:text-white md:text-5xl lg:text-6xl"><span class="text-transparent bg-clip-text bg-gradient-to-r to-emerald-600 from-sky-400">Generalist & </span> Developer Advocate.</h1>
    <p class="text-lg font-normal text-gray-500 lg:text-xl dark:text-gray-400">Hello, I am Haimantika. Currently working as a Developer Advocate at Hashnode. I help B2D+ companies bridge the gap between developers and the product with code, content and community. As a community builder and a product of the community myself, I strongly believe that technology is for everyone. I am passionate about learning, sharing, and building with the community.</p>

    </section>

Building the projects section using Flowbite's card component:

 <main class="max-w-4xl mx-auto flex flex-col">
    <section id="home" class="flex flex-col sm:flex-row p-20 items-center gap-8 mb-12">

    <h1 class="mb-4 text-3xl font-extrabold text-gray-900 dark:text-white md:text-5xl lg:text-6xl"><span class="text-transparent bg-clip-text bg-gradient-to-r to-emerald-600 from-sky-400">Generalist & </span> Developer Advocate.</h1>
    <p class="text-lg font-normal text-gray-500 lg:text-xl dark:text-gray-400">Hello, I am Haimantika. Currently working as a Developer Advocate at Hashnode. I help B2D+ companies bridge the gap between developers and the product with code, content and community. As a community builder and a product of the community myself, I strongly believe that technology is for everyone. I am passionate about learning, sharing, and building with the community.</p>

    </section>
    <main class="max-w-4xl mx-auto flex flex-col">
        <section id="projects" class="flex flex-col sm:flex-row p-20 items-center gap-8 mb-12">


<div class="max-w-sm p-6 bg-white border border-gray-200 rounded-lg shadow dark:bg-gray-800 dark:border-gray-700">
    <a href="#">
        <h5 class="mb-2 text-2xl font-bold tracking-tight text-gray-900 dark:text-white">Melody Matcher</h5>
    </a>
    <p class="mb-3 font-normal text-gray-700 dark:text-gray-400">Happy? Sad? Angry? Want a music blend made just for you? Try out the soul music generator. Built using: Next.JS, and QuickBlox API.</p>
    <a href="https://music-suggester.vercel.app/" class="inline-flex items-center px-3 py-2 text-sm font-medium text-center text-white bg-blue-700 rounded-lg hover:bg-blue-800 focus:ring-4 focus:outline-none focus:ring-blue-300 dark:bg-blue-600 dark:hover:bg-blue-700 dark:focus:ring-blue-800">
        Try it here
        <svg class="rtl:rotate-180 w-3.5 h-3.5 ms-2" aria-hidden="true" xmlns="http://www.w3.org/2000/svg" fill="none" viewBox="0 0 14 10">
            <path stroke="currentColor" stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M1 5h12m0 0L9 1m4 4L9 9"/>
        </svg>
    </a>
</div>



<div class="max-w-sm p-6 bg-white border border-gray-200 rounded-lg shadow dark:bg-gray-800 dark:border-gray-700">
    <a href="#">
        <h5 class="mb-2 text-2xl font-bold tracking-tight text-gray-900 dark:text-white">Diss Track</h5>
    </a>
    <p class="mb-3 font-normal text-gray-700 dark:text-gray-400">Got hate comments? Time to turn it into a rap! Try out Diss Track. Built using: TailwindCSS (DaisyUI components), and QuickBlox API.</p>
    <a href="https://disstrack.vercel.app/" class="inline-flex items-center px-3 py-2 text-sm font-medium text-center text-white bg-blue-700 rounded-lg hover:bg-blue-800 focus:ring-4 focus:outline-none focus:ring-blue-300 dark:bg-blue-600 dark:hover:bg-blue-700 dark:focus:ring-blue-800">
        Try it here
        <svg class="rtl:rotate-180 w-3.5 h-3.5 ms-2" aria-hidden="true" xmlns="http://www.w3.org/2000/svg" fill="none" viewBox="0 0 14 10">
            <path stroke="currentColor" stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M1 5h12m0 0L9 1m4 4L9 9"/>
        </svg>
    </a>
</div>
</main>

Building the footer:

<footer class="bg-white rounded-lg shadow dark:bg-gray-900 m-4">
    <div class="w-full max-w-screen-xl mx-auto p-4 md:py-8">
        <div class="sm:flex sm:items-center sm:justify-between">

            <ul class="flex flex-wrap items-center mb-6 text-sm font-medium text-gray-500 sm:mb-0 dark:text-gray-400">
                <li>
                    <a href="https://www.linkedin.com/in/haimantika-mitra/" class="hover:underline me-4 md:me-6">LinkedIn</a>
                </li>
                <li>
                    <a href="#" class="hover:underline me-4 md:me-6">GitHub</a>
                </li>
                <li>
                    <a href="#" class="hover:underline me-4 md:me-6">Twitter</a>
                </li>
                <li>
                    <a href="#" class="hover:underline">Resume</a>
                </li>
            </ul>
        </div>

</footer>

Part 2: Building the blog section

To build the blog section, we will make use of Hashnode in Headless mode and it's open-source starter kit.

1. The first step is to fork it and create your own copy.

2. Clone it locally using any IDE of your choice.

3. Currently, Hashnode has three themes: personal, hashnode and enterprise. You can use any, but in this demo, we will use the enterprise theme.

4. It's a monorepo, so cd into packages/blog-starter-kit/themes/enterprise, and then type pnpm install to install all the necessary packages.

5. The repository, will include a .env.example file. Copy the contents and create a .env file that includes your blog publication details. You will only need to update NEXT_PUBLIC_HASHNODE_PUBLICATION_HOST, rest everything remains the same.

This is where you will find your Hashnode publication name, for me, it is haimantika.dev 👇

6. Once all of it is done, use the command npm run dev to run it locally.

7. The starter kit uses Next.js and Tailwind, allowing you to customize the styling. In this demo, we modify the footer to match our homepage footer. The code for that looks like:

    import Link from 'next/link';
    import { Container } from './container';
    import { useAppContext } from './contexts/appContext';
    import { SocialLinks } from './social-links';
   
    export const Footer = () => {
   
        return (
            <footer className="bg-white rounded-lg shadow dark:bg-gray-900 m-4">
        <div className="w-full max-w-screen-xl mx-auto p-4 md:py-8">
            <div className="sm:flex sm:items-center sm:justify-between">
                <ul className="flex flex-wrap items-center mb-6 text-sm font-medium text-gray-500 sm:mb-0 dark:text-gray-400">
                    <li>
                        <a href="https://www.linkedin.com/in/haimantika-mitra/" className="hover:underline me-4 md:me-6">LinkedIn</a>
                    </li>
                    <li>
                        <a href="#" className="hover:underline me-4 md:me-6">GitHub</a>
                    </li>
                    <li>
                        <a href="#" className="hover:underline me-4 md:me-6">Twitter</a>
                    </li>
                    <li>
                        <a href="#" className="hover:underline">Resume</a>
                    </li>
                </ul>
            </div>
        </div>
    </footer>
   
        );
    }
   

If you want to make other changes, check out this video:

Part 3: Deploying it using Vercel

We will need to deploy the homepage and the blog separately. To deploy the homepage, you can follow Vercel's documentation.

Let us learn how to deploy the blog section:

• Create a new project on Vercel and connect this starter-kit repo.

• Since it's a monorepo, and you choose the enterprise theme, you need to choose packages/blog-starter-kit/themes/enterpriseas the root directory while importing on Vercel.

• Choose Next.js as framework preset.

• Set the following environment variables

    NEXT_PUBLIC_HASHNODE_GQL_ENDPOINT=https://gql.hashnode.com 
    NEXT_PUBLIC_HASHNODE_PUBLICATION_HOST=engineering.hashnode.com -> Change this to your Hashnode blog URL i.e. handle.hashnode.dev 
    NEXT_PUBLIC_BASE_URL=/blog -> This could be /blog if you are installing on subpath; otherwise remove this var 
    NEXT_PUBLIC_MODE=production
  

• Then click on deploy. If you see a 404 error, do not worry, as you set the subpath as /blog you need to add it to Vercel's auto generated domain to see your blog.

Hosting your blog to your domains subpath

The next step is to map your blog to yourdomain.com/blog. Currently, the homepage and blog is hosted in two different domains, but we want it to be on the same domain with the /blog subpath. Something like 👉 https://haimantika.dev/blog

Since, we have used HTML and TailwindCSS to build the portfolio, we will need to work with Cloudflare workers.

Note: If you decide to build your portfolio with Next.js at any point in the future, you do not need to go through the Cloudflare route and you can simply follow the steps mentioned here.

Deploy the Worker, and updating the script and map it to yourdomain.com/blog:

• Login/Signup on Cloudflare.

• Create and deploy worker as shown in the image below.

  

• Once deployed, click on Edit code to update the worker script.

• Add the following code and save it.

    const subpath = '/blog'; // Replace with your subpath
    const blogBaseUrl = 'https://yourdomain.com'; // Replace with your blog URL
  
    addEventListener('fetch', event => {
      event.respondWith(handleRequest(event.request))
    })
  
    /**
     * Respond to the request
     * @param {Request} request
     */
    async function handleRequest(request) {
      const url = new URL(request.url)
  
      if (url.pathname.startsWith(subpath)) {
        // Proxy blog requests
        return proxyBlog(request)
      } else {
        // Passthrough everything else
        return fetch(request)
      }
    }
  
    /**
     * Proxy blog requests
     * @param {Request} request
     */
    async function proxyBlog(request) {
      const path = new URL(request.url).pathname;
      return fetch(`${blogBaseUrl}${path}`, request)
    }
  

  Once you've deployed the worker, the next step is to add the worker to your website domain on cloudfare.

  For the domain you'll be using on your Cloudflare account, you need to add a worker route. The route should be *, and the worker should be the script you created in the steps above.

  Note: Make sure that your domain - yourdomain.com is on Cloudflare. If not, you should transfer it to make it work!

  

  For the final step, go to the Hashnode blog dashboard, and under the Domain section, make sure to turn on the Headless mode and mention the blog base URL.

  

  And now you are done! When you browse to yourdomain.com/blog you will see your blog live on the subpath!

Resources

Thank you for reading to the end. If you have followed the tutorial or the webinar and created a portfolio, feel free to tag us on X (Twitter) @Hashnode, and we will retweet it!

Here are some resources to help you learn more:

• Hashnode's open-source starter kit

• Portfolio code

• TailwindCSS documentation

• Vercel documentation

Millions of developers use Hashnode daily to read and share stories. We've always been focused on providing the best platform for developers and teams to run and host their blogs.

Our goal has always been to help individuals share their knowledge and enable teams to maintain a strong brand voice.

As we've grown, one of the most requested features has been the ability to create and manage detailed documentation. This aligns perfectly with our mission.

So today, I'm excited to introduce Docs by Hashnode the content engine for developers to build and run API and product documentation on Hashnode.

Why we built another documentation SaaS for developers?

We believe developer documentation should be more than an afterthought it should be a seamless extension of your brand. With Docs by Hashnode, were empowering teams to build, customize, and scale their docs just as quickly as they code.

We hate rigid templates and endless maintenance ourselves. It's time for documentation that evolves with your product.

Our vision is clear: we want to give you full control over your documentation while ensuring it integrates effortlessly into your product. This means providing headless mode with first-class support for GraphQL APIs.

Youll have the flexibility to design your frontend exactly as you envision it, with all the power and scalability you need to keep pace with your development.

Why is Docs by Hashnode ideal for large teams and companies?

Our docs tool provides features that give you full control and ensure a smooth user experience:

Headless mode with GraphQL support.

Take control with headless mode and GraphQL support. Integrate your docs easily, scale without hassle, and give your developers the flexibility they need.

Customizing and optimizing the theme is as simple as tweaking the TailwindCSS classes in our docs starter kit. This allows you to match your theme with your main website and even host the frontend code on /docs.

Creating and editing docs.

We've prioritized editing and performance to make sure your docs not only look great but also run at lightning speed:

• Best-in-class editor powered by MDX: Our visual WYSIWYG editor, powered by MDX, allows you to create interactive docs that seamlessly blend Markdown with React components.

• Lightning-fast speed and SEO optimization: Our docs are built for speed and optimized for SEO, ensuring top performance in Lightspeed tests and a fast experience for your users.

Search, discovery, and API management.

Finding the right information is crucial, and our tools are built to make it effortless:

• AI-Powered search and chat: For teams looking to enhance their search, upgrade to AI-powered search. It evolves into a chat-like experience, making it easier for users to find the right content.

• Super fast search powered by Algolia: Get instant results with our Algolia-powered search, delivering fast and reliable results to keep your users moving forward.

Managing your API references is now simpler than ever:

• API reference playground: Quickly set up API references with a one-click import of Swagger or OpenAPI specs. It's fast, developer-friendly, and perfect for modern teams.

• Show custom code samples: Our docs can auto-generate code examples for your APIs, but you can also add custom snippets. Whether it's JavaScript, Python, or another language, provide clear examples to help developers easily understand and use your APIs.

Insights, feedback, and collaboration.

Understanding how your documentation is used and enabling smooth team collaboration are crucial for improving your docs:

• Analytics and intelligence: Gain insights with detailed analytics and smart reports to help you improve your content.

• User feedback feature: Allow users to send feedback directly from the docs. Gather insights on API performance, report errors, fix typos, and enhance guidesall in one place.

• Scale to unlimited members: Grow your team without limits, enabling everyone to contribute to your docs, regardless of your organization's size.

• Versioning and permissions: Maintain control with robust versioning and permissionsperfect for managing complex documentation workflows.

Docs by Hashnode is designed for seamless team collaboration. With real-time editing and reviewing, your team can work together in one editor:

• Real-time editing: Collaborate with your team instantly, ensuring everyone stays aligned without version conflicts.

• Inline review comments: Simplify feedback with inline comments directly in the editor. Team members can review and suggest improvements, maintaining clarity and accuracy at every step.

• Collaborative workflow with roles: Assign roles to team members to control who can edit, review, or approve docs. Keep workflows organized by assigning the right tasks to the right people.

Built for growing teams and enterprises.

Security, scale, and reliability are central to Docs by Hashnode. We offer SSO, audit logs, custom SLAs, and uptime guarantees to keep your docs secure and always available. By the end of 2024, we'll also be SOC2 and ISO 27001 ready, giving your enterprise peace of mind.

Join us on this journey.

Were incredibly proud of what weve built with Docs by Hashnode, and this is just the beginning. As we step into this new chapter, we invite you to join the waitlist and be among the first to experience the future of developer documentation.

Thank you for being part of the Hashnode community and for inspiring us to keep pushing the boundaries of whats possible. We cant wait to see what you create with our new docs product.

GA Fall 2024.

Available in public beta today. Sign up. 🚀

PS: A tip to get early access fasteruse your company email address when signing up. :)

Today, were going to learn how to publish blog posts using our custom editing interface. We will use Hashnode API and MDXEditor for demo purposes.

Step 1: Creating a new React project

With node.js, npm installed, please run the following command to install the React boilerplate using Vite.

npm create vite@latest my-editor -- --template react-ts

Dont worry if you dont have Vite installed locally, npm will prompt you to do so. Lets install all the dependencies, including MDXEditor:

cd my-editor
npm install --save @mdxeditor/editor

Now, we are ready to serve our project using the CLI command npm run dev:

npm run dev

  VITE v5.1.3  ready in 80 ms

    Local:   http://localhost:5173/
    Network: use --host to expose
    press h + enter to show help

Hot Reloading is enabled by default. Any changes will have an immediate effect on the browser window. Navigate to http://localhost:5173/

Step 1.2: Styling

Vite serves our project from src/main.tsx. We also have an example component in src/App.tsx. Lets clean up the boilerplate code in the following places:

• Delete public/vite.svg

• Delete src/assets/react.svg

• Clean up everything in src/index.css, so the file should be completely empty. Were going to add Tailwind in the next steps and use this file.

• Delete src/App.css

• Clean up the src/App.tsx The App component should look like this after the cleanup:

function App() {
  return (
    <>
        <h1>My Blog Editor</h1>
    </>
  )
}

export default App

Step 1.3: Setting up Tailwind

Install Tailwind and @tailwindcss/typograph package, using npm and npx,

npm install -D tailwindcss postcss autoprefixer @tailwindcss/typography
npx tailwindcss init -p

We also need to set up the Tailwind config file, tailwind.config.js:

/** @type {import('tailwindcss').Config} */
export default {
  content: [
    "./index.html",
    "./src/**/*.{js,ts,jsx,tsx}",
  ],
  theme: {
    extend: {},
  },
  plugins: [
    require('@tailwindcss/typography'),
  ],
}

Next, we can add the base Tailwind styles in the src/index.css file:

@tailwind base;  
@tailwind components;  
@tailwind utilities;

Were ready to use Tailwind. Now, the npm run dev command will build Tailwind styles too! We can already wrap our app into a container by adding the following in main.tsx:

  <React.StrictMode>
      <div className="container mx-auto px-4 w-1/2 py-8">
          <App/>
      </div>
  </React.StrictMode>

Thats it! We will continue with styling later when we set up our custom editor interface.

Step 2: Setting up the editor

We can import the MDXEditor React component and use it in our project. We need to include the CSS file as well, we can do this directly in our App component:

import { MDXEditor } from '@mdxeditor/editor'
import '@mdxeditor/editor/style.css'

This is the basic setup, and this setup doesnt allow advanced text editing. It only supports bold, italic, underline, and inline code. We can already add some other plugins to support advanced editing. MDXEditor is highly customizable, you can head to the MDXEditor docs and get more information about all available plugins and usages. For demo purposes, we will only add some of them. Lets set up the editor component with plugins:

import {
  MDXEditor,
  BlockTypeSelect,
  UndoRedo,
  BoldItalicUnderlineToggles,
  toolbarPlugin,
  headingsPlugin,
  markdownShortcutPlugin,
  linkPlugin,
} from "@mdxeditor/editor";
import "@mdxeditor/editor/style.css";

function App() {
  const editorRef = React.useRef<MDXEditorMethods>(null);

  return (
    <>
      <h1 className="text-5xl">My Blog Editor</h1>

      <div className="prose max-w-none">
        <MDXEditor
          ref={editorRef}
          className="my-5"
          markdown="Hello world"
          plugins={[
            headingsPlugin(),
            linkPlugin(),
            markdownShortcutPlugin(),
            toolbarPlugin({
              toolbarContents: () => (
                <>
                  {" "}
                  <UndoRedo/>
                  <BlockTypeSelect/>
                  <BoldItalicUnderlineToggles/>
                </>
              ),
            }),
          ]}
        />
      </div>
    </>
  );
}

export default App;

Viola! Were ready to write our blog posts! 🎉

Step 2.2 Adding the title input and publish button

Lets create an input to write our blog titles! We can replace the h1 My Blog Editor element with a text input. Then, we can add the Publish button next to it. Its really easy to style them using Tailwind. We just need to wrap it into an outer box and add the button after the h1 element. We will also leverage flexbox and ml-auto Tailwind class:

const [title, setTitle] = useState<string>('');  

return (  
  <>  
    <div className="flex">  
      <input  
        onChange={(event: React.ChangeEvent<HTMLInputElement>) => setTitle(event.target.value)}  
        value={title}  
        className="text-3xl focus:outline-none"  
        placeholder="Title..." />  
      <button  
        onClick={publishPost}  
        className="ml-auto bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded">Publish  
      </button>  
    </div>
    {/* Editor code... */}
  </>  
);

Here is our initial editor design!

Did you notice the publishPost reference on onClick attribute? Now, we can program its functionality, the publishPost method itself. First, lets define the API request were going to send to Hashnode GraphQL API. We'll use the publishPost mutation but if you don't want to publish your posts immediately, you can also use the createDraft mutation.

// imports

const publishPostMutation = `
mutation ($input: PublishPostInput!) {
  publishPost(input: $input) {
     post {
      url
     }
  }
}
`

// App component

Lets create a corresponding type to this request so we can map the response output and use it in a type-safe way.

// imports

type ApiResponse = {
  data: {
    publishPost: {
      post: {
        url: string
      }
    }
  }
}

// mutation

// App component

Almost all Hashnode GraphQL queries can be accessed without any authentication mechanism. But, all mutations need an authentication header. Were going to use publishPost mutation for this tutorial, therefore, we need to authenticate our user. Its really easy to do, we just need to include our Personal Access Token (PAT) in the Authorization header. Please go ahead and grab your token from the Hashnode Developer Settings page. Click the Generate new token button and copy the generated token.

Lets put this in a const, so we can use it later. Of course, in a bigger project, you can store this information somewhere secure, and access it as you wish. For the demo purposes, we will store in a const.

const PERSONAL_ACCESS_TOKEN = 'XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX';

Next, we need our publication ID. We can easily copy the publication ID from our blogs dashboard URL.

Now, using both the recently generated token and the publication ID, we can send a publish post request. Lets go back to creating the publishPost function:

  const publishPost = () => {
    const response = await fetch("https://gql.hashnode.com", {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
        Accept: "application/json",
        Authorization: PERSONAL_ACCESS_TOKEN,
      },
      body: JSON.stringify({
        query: publishPostMutation,
        variables: {
          input: {
            publicationId: "65d99cd9447d15d98a2fc264",
            title: title,
            contentMarkdown: editorRef.current?.getMarkdown(),
          },
        },
      }),
    });
  };

Step 3: Showing success message

Now, we can add a little container that gives us feedback when we successfully publish our blog post! We can store preview URL in state and show that container based on the previewUrl state changes.

const [previewUrl, setPreviewUrl] = useState<string>("");  

return (  
  <>  
    <div id="preview-link" className={previewLink === "" ? "hidden" : "" + "absolute top-20 z-10 left-1/2 transform -translate-x-1/2 -translate-y-1/2 bg-green-200 border-2 border-green-500 rounded-lg w-1/2 px-8 py-4"}>  
       Successfully published the blog post! <br />  
      <a href={previewLink} className="text-blue-900" target="_blank">{previewLink}</a>  
    </div>
    {/* Other parts */}

Lets add a state modifier to our request function and combine things:

const publishPost = async () => {
const response = await fetch("https://gql.hashnode.com", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    Accept: "application/json",
    Authorization: PERSONAL_ACCESS_TOKEN,
  },
  body: JSON.stringify({
    query: publishPostMutation,
    variables: {
      input: {
        publicationId: "65d99cd9447d15d98a2fc264",
        title: title,
        contentMarkdown: editorRef.current?.getMarkdown(),
      },
    },
  }),
});

const result = await response.json() as ApiResponse;

setPreviewLink(result.data.publishPost.post.url);
};

Ta-da! 🎉 We can click on the preview URL and see our new shiny blog post!

Here is everything combined, the whole code of the App.tsx component:

import {
  MDXEditor,
  BlockTypeSelect,
  UndoRedo,
  BoldItalicUnderlineToggles,
  toolbarPlugin,
  headingsPlugin,
  markdownShortcutPlugin,
  linkPlugin, MDXEditorMethods,
} from "@mdxeditor/editor";
import "@mdxeditor/editor/style.css";
import React, {useState} from "react";

type ApiResponse = {
  data: {
    publishPost: {
      post: {
        url: string
      }
    }
  }
}

const PERSONAL_ACCESS_TOKEN = "REPLACE_THIS_WITH_YOUR_PERSONAL_ACCESS_TOKEN";

const publishPostMutation = `
  mutation ($input: PublishPostInput!) {
    publishPost(input: $input) {
       post {
        url
       }
    }
  }
`;

function App() {
  const [title, setTitle] = useState<string>("");
  const [previewLink, setPreviewLink] = useState<string>("");
  const editorRef = React.useRef<MDXEditorMethods>(null);

  const publishPost = async () => {
    const response = await fetch("https://gql.hashnode.com", {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
        Accept: "application/json",
        Authorization: PERSONAL_ACCESS_TOKEN,
      },
      body: JSON.stringify({
        query: publishPostMutation,
        variables: {
          input: {
            publicationId: "65d99cd9447d15d98a2fc264",
            title: title,
            contentMarkdown: editorRef.current?.getMarkdown(),
          },
        },
      }),
    });

    const result = await response.json() as ApiResponse;

    setPreviewLink(result.data.publishPost.post.url);
  };

  return (
    <>
      <div id="preview-link" className={previewLink === "" ? "hidden" : "" + "absolute top-20 z-10 left-1/2 transform -translate-x-1/2 -translate-y-1/2 bg-green-200 border-2 border-green-500 rounded-lg w-1/2 px-8 py-4"}>
         Here is your preview link: <br />
        <a href={previewLink} className="text-blue-900" target="_blank">{previewLink}</a>
      </div>
      <div className="flex">
        <input
          onChange={(event: React.ChangeEvent<HTMLInputElement>) => setTitle(event.target.value)}
          value={title}
          className="text-3xl w-full focus:outline-none"
          placeholder="Title..."/>
        <button
          onClick={publishPost}
          className="ml-auto bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded">Publish
        </button>
      </div>

      <div className="prose max-w-none">
        <MDXEditor
          ref={editorRef}
          className="my-5"
          markdown="Hello world!"
          plugins={[
            headingsPlugin(),
            linkPlugin(),
            markdownShortcutPlugin(),
            toolbarPlugin({
              toolbarContents: () => (
                <>
                  {" "}
                  <UndoRedo/>
                  <BlockTypeSelect/>
                  <BoldItalicUnderlineToggles/>
                </>
              ),
            }),
          ]}
        />
      </div>
    </>
  );
}

export default App;

Conclusion

Weve learned how to use Hashnode GraphQL API to create a custom React text editor. There are many examples on the API Docs page that you can use to extend your blogs functionality.

It comprises their Next.js Starter Kit and GraphQL APIs to construct your blog's homepage, articles, comments, search functionality, and more.

In this article, lets embody the saying ''Hashnode's publishing power, your custom design" as we customize Next.js Starter Kit blog using TailwindCSS

Setup and Installation

Let start by installing the Nextjs Starter Kit locally, first head to the projects Github repository and you can either fork or clone the project.

In this article I will go with the cloning approach by running this command

git clone https://github.com/Hashnode/starter-kit.git

The Starter Kit repository is organized as a mono-repo, housing multiple themes. To begin customization, navigate to the "packages/blog-starter-kit/themes/" directory in your local repository, where three distinct themes await: enterprise, hashnode, and personal.

Choose your preferred theme and open it in your editor by either using the terminal with commands like cd packages/blog-starter-kit/themes/enterprise or navigating through your file explorer.

In this walkthrough, we'll focus on the enterprise theme, but the principles apply on all themes. Once inside your chosen theme, the folder structure becomes accessible for modification.

Within the theme, locate the .env.example file and rename it to .env.local. Customize the environment variables as needed for your site integration or leverage existing variables like shown in image below

Next, in your terminal, run the command pnpm install to install the required packages. Ensure that you have pnpm installed globally on your machine for this to work

Once the packages are installed, fire up the development server with pnpm dev. Now, you can preview it on the browser

Tailwind Customizations

By default the project comes with tailwindcss, this can be observed by the presence of tailwind.config.js file, so we can start customizing the project according to our likings lets start with:

• Colors Customizations

  By default the enterprise version uses blue color as the primary color as seen below in the tailwind.config.js file snippet

    /** @type {import('tailwindcss').Config} */
    const colors = require('tailwindcss/colors');
  
    module.exports = {
        content: ['./components/**/*.tsx', './pages/**/*.tsx'],
        darkMode: 'class',
        theme: {
            extend: {
                colors: {
                    'accent-1': '#FAFAFA',
                    'accent-2': '#EAEAEA',
                    'accent-7': '#333',
                    success: '#0070f3',
                    cyan: '#79FFE1',
                    primary: colors.blue, //primary color
                },
    .....
    }
  

  You will also notice an import to tailwindcss/colors at the top of the configuration file. This enables to curate your colors from tailwind default color palette instead of defining your own custom palette.

  In this starter-kit you will notice 'primary' set to inherit all blue colors from tailwind blue color palette

  To make your project unique, consider changing the primary color. For instance, lets switch it to red and observe the visual impact.

• 

• Customizing UI elements

  By using tailwind we can also customize the UI elements lets say the cards, images, fonts and other by adjusting their tailwind classes in their respective components. We can also customize the blog by creating a new components style them with tailwindcss and set them up in the UI

Theme Switcher

Now, lets wrap up the customizations by building a simple theme switcher and customize it using tailwind

Tailwind includes a dark variant that lets you style your site differently when dark mode is enabled

The main two methods used are to achieve dark-mode in tailwind are:

• Media strategy

  The media strategy that uses prefers-color-scheme CSS media feature that sets dark or light mode based on system preference and this is tailwind's default strategy

• Selector strategy

  The selector strategy which before tailwindv3.4.1 was known as class strategy support toggling dark mode manually instead of relying on the operating system preference, now because this is not the default to use it we need to add this line in our tailwind.config.js file

    /** @type {import('tailwindcss').Config} */
    module.exports = {
      darkMode: 'selector',// for v3.4.1 and above
      darkMode: 'class' // for version less than 3.4.1
      // ...
    }
  

Because our project as the time of this writing uses tailwind v3.3.3 you will observe it uses the class strategy in the tailwind.config.js file instead of the newer selector strategy (a possible pull request).

Now that we have understood the different strategies used to achieve dark-mode in tailwind lets proceed by installing a package that will enable as to achieve theme switching easily in Next.js called next-themes

Lets install it using the command

pnpm install next-themes

Then we can create a ThemeProvider on the pages/_app.tsx file like shown below

// pages/_app.tsx
import { AppProps } from 'next/app';
import '../styles/index.css';
import { ThemeProvider } from 'next-themes'

export default function MyApp({ Component, pageProps }: AppProps) {
        return (
        <ThemeProvider attribute="class">
            <Component {...pageProps} />
        </ThemeProvider>
    );
}

The ThemeProvider attribute prop is set to value class because our Nextjs application uses tailwind class strategy to achieve dark-mode.

Now our provider is set lets add the required components to toggle the theme

Inside the root directory navigate to components\icons\svgs .Inside the directory we are going to create two more SVG icons the Moon(MoonSVG.js) and Sun( SunSVG.js) icons.

//SunSVG.js
import React from 'react';

export default class SunSVG extends React.Component {
    render() {
        return (
            <svg
                className={this.props.className}
                viewBox="0 0 15 15"
                fill="none"
                xmlns="http://www.w3.org/2000/svg"
            >
                <path
                    d="M7.5 0C7.77614 0 8 0.223858 8 0.5V2.5C8 2.77614 7.77614 3 7.5 3C7.22386 3 7 2.77614 7 2.5V0.5C7 0.223858 7.22386 0 7.5 0ZM2.1967 2.1967C2.39196 2.00144 2.70854 2.00144 2.90381 2.1967L4.31802 3.61091C4.51328 3.80617 4.51328 4.12276 4.31802 4.31802C4.12276 4.51328 3.80617 4.51328 3.61091 4.31802L2.1967 2.90381C2.00144 2.70854 2.00144 2.39196 2.1967 2.1967ZM0.5 7C0.223858 7 0 7.22386 0 7.5C0 7.77614 0.223858 8 0.5 8H2.5C2.77614 8 3 7.77614 3 7.5C3 7.22386 2.77614 7 2.5 7H0.5ZM2.1967 12.8033C2.00144 12.608 2.00144 12.2915 2.1967 12.0962L3.61091 10.682C3.80617 10.4867 4.12276 10.4867 4.31802 10.682C4.51328 10.8772 4.51328 11.1938 4.31802 11.3891L2.90381 12.8033C2.70854 12.9986 2.39196 12.9986 2.1967 12.8033ZM12.5 7C12.2239 7 12 7.22386 12 7.5C12 7.77614 12.2239 8 12.5 8H14.5C14.7761 8 15 7.77614 15 7.5C15 7.22386 14.7761 7 14.5 7H12.5ZM10.682 4.31802C10.4867 4.12276 10.4867 3.80617 10.682 3.61091L12.0962 2.1967C12.2915 2.00144 12.608 2.00144 12.8033 2.1967C12.9986 2.39196 12.9986 2.70854 12.8033 2.90381L11.3891 4.31802C11.1938 4.51328 10.8772 4.51328 10.682 4.31802ZM8 12.5C8 12.2239 7.77614 12 7.5 12C7.22386 12 7 12.2239 7 12.5V14.5C7 14.7761 7.22386 15 7.5 15C7.77614 15 8 14.7761 8 14.5V12.5ZM10.682 10.682C10.8772 10.4867 11.1938 10.4867 11.3891 10.682L12.8033 12.0962C12.9986 12.2915 12.9986 12.608 12.8033 12.8033C12.608 12.9986 12.2915 12.9986 12.0962 12.8033L10.682 11.3891C10.4867 11.1938 10.4867 10.8772 10.682 10.682ZM5.5 7.5C5.5 6.39543 6.39543 5.5 7.5 5.5C8.60457 5.5 9.5 6.39543 9.5 7.5C9.5 8.60457 8.60457 9.5 7.5 9.5C6.39543 9.5 5.5 8.60457 5.5 7.5ZM7.5 4.5C5.84315 4.5 4.5 5.84315 4.5 7.5C4.5 9.15685 5.84315 10.5 7.5 10.5C9.15685 10.5 10.5 9.15685 10.5 7.5C10.5 5.84315 9.15685 4.5 7.5 4.5Z"
                    fill="currentColor"
                    fill-rule="evenodd"
                    clip-rule="evenodd"
                ></path>
            </svg>
        );
    }
}

//MoonSVG.js
import React from 'react';

export default class MoonSVG extends React.Component {
    render() {
        return (
            <svg
                className={this.props.className}
                viewBox="0 0 15 15"
                fill="none"
                xmlns="http://www.w3.org/2000/svg"
            >
                <path
                    d="M2.89998 0.499976C2.89998 0.279062 2.72089 0.0999756 2.49998 0.0999756C2.27906 0.0999756 2.09998 0.279062 2.09998 0.499976V1.09998H1.49998C1.27906 1.09998 1.09998 1.27906 1.09998 1.49998C1.09998 1.72089 1.27906 1.89998 1.49998 1.89998H2.09998V2.49998C2.09998 2.72089 2.27906 2.89998 2.49998 2.89998C2.72089 2.89998 2.89998 2.72089 2.89998 2.49998V1.89998H3.49998C3.72089 1.89998 3.89998 1.72089 3.89998 1.49998C3.89998 1.27906 3.72089 1.09998 3.49998 1.09998H2.89998V0.499976ZM5.89998 3.49998C5.89998 3.27906 5.72089 3.09998 5.49998 3.09998C5.27906 3.09998 5.09998 3.27906 5.09998 3.49998V4.09998H4.49998C4.27906 4.09998 4.09998 4.27906 4.09998 4.49998C4.09998 4.72089 4.27906 4.89998 4.49998 4.89998H5.09998V5.49998C5.09998 5.72089 5.27906 5.89998 5.49998 5.89998C5.72089 5.89998 5.89998 5.72089 5.89998 5.49998V4.89998H6.49998C6.72089 4.89998 6.89998 4.72089 6.89998 4.49998C6.89998 4.27906 6.72089 4.09998 6.49998 4.09998H5.89998V3.49998ZM1.89998 6.49998C1.89998 6.27906 1.72089 6.09998 1.49998 6.09998C1.27906 6.09998 1.09998 6.27906 1.09998 6.49998V7.09998H0.499976C0.279062 7.09998 0.0999756 7.27906 0.0999756 7.49998C0.0999756 7.72089 0.279062 7.89998 0.499976 7.89998H1.09998V8.49998C1.09998 8.72089 1.27906 8.89997 1.49998 8.89997C1.72089 8.89997 1.89998 8.72089 1.89998 8.49998V7.89998H2.49998C2.72089 7.89998 2.89998 7.72089 2.89998 7.49998C2.89998 7.27906 2.72089 7.09998 2.49998 7.09998H1.89998V6.49998ZM8.54406 0.98184L8.24618 0.941586C8.03275 0.917676 7.90692 1.1655 8.02936 1.34194C8.17013 1.54479 8.29981 1.75592 8.41754 1.97445C8.91878 2.90485 9.20322 3.96932 9.20322 5.10022C9.20322 8.37201 6.82247 11.0878 3.69887 11.6097C3.45736 11.65 3.20988 11.6772 2.96008 11.6906C2.74563 11.702 2.62729 11.9535 2.77721 12.1072C2.84551 12.1773 2.91535 12.2458 2.98667 12.3128L3.05883 12.3795L3.31883 12.6045L3.50684 12.7532L3.62796 12.8433L3.81491 12.9742L3.99079 13.089C4.11175 13.1651 4.23536 13.2375 4.36157 13.3059L4.62496 13.4412L4.88553 13.5607L5.18837 13.6828L5.43169 13.7686C5.56564 13.8128 5.70149 13.8529 5.83857 13.8885C5.94262 13.9155 6.04767 13.9401 6.15405 13.9622C6.27993 13.9883 6.40713 14.0109 6.53544 14.0298L6.85241 14.0685L7.11934 14.0892C7.24637 14.0965 7.37436 14.1002 7.50322 14.1002C11.1483 14.1002 14.1032 11.1453 14.1032 7.50023C14.1032 7.25044 14.0893 7.00389 14.0623 6.76131L14.0255 6.48407C13.991 6.26083 13.9453 6.04129 13.8891 5.82642C13.8213 5.56709 13.7382 5.31398 13.6409 5.06881L13.5279 4.80132L13.4507 4.63542L13.3766 4.48666C13.2178 4.17773 13.0353 3.88295 12.8312 3.60423L12.6782 3.40352L12.4793 3.16432L12.3157 2.98361L12.1961 2.85951L12.0355 2.70246L11.8134 2.50184L11.4925 2.24191L11.2483 2.06498L10.9562 1.87446L10.6346 1.68894L10.3073 1.52378L10.1938 1.47176L9.95488 1.3706L9.67791 1.2669L9.42566 1.1846L9.10075 1.09489L8.83599 1.03486L8.54406 0.98184ZM10.4032 5.30023C10.4032 4.27588 10.2002 3.29829 9.83244 2.40604C11.7623 3.28995 13.1032 5.23862 13.1032 7.50023C13.1032 10.593 10.596 13.1002 7.50322 13.1002C6.63646 13.1002 5.81597 12.9036 5.08355 12.5522C6.5419 12.0941 7.81081 11.2082 8.74322 10.0416C8.87963 10.2284 9.10028 10.3497 9.34928 10.3497C9.76349 10.3497 10.0993 10.0139 10.0993 9.59971C10.0993 9.24256 9.84965 8.94373 9.51535 8.86816C9.57741 8.75165 9.63653 8.63334 9.6926 8.51332C9.88358 8.63163 10.1088 8.69993 10.35 8.69993C11.0403 8.69993 11.6 8.14028 11.6 7.44993C11.6 6.75976 11.0406 6.20024 10.3505 6.19993C10.3853 5.90487 10.4032 5.60464 10.4032 5.30023Z"
                    fill="currentColor"
                    fill-rule="evenodd"
                    clip-rule="evenodd"
                ></path>
            </svg>
        );
    }
}

Now we can create a component to render the Icons conditionally: Sun icon when its dark mode and Moon Icon when it is light mode.

//components/theme-switcher.tsx
import { useTheme } from 'next-themes';
import { useEffect, useState } from 'react';

import MoonSVG from './icons/svgs/MoonSVG';
import SunSVG from './icons/svgs/SunSVG';

const ThemeSwitch = () => {
    const [mounted, setMounted] = useState(false);
    const { theme, setTheme } = useTheme();

    useEffect(() => {
        setMounted(true);
    }, []);

    if (!mounted) {
        return null;
    }

    return (
     <>
       <button 
          onClick={() => setTheme(theme === 'light' ? 'dark' : 'light')}>
            <SunSVG className="h-[1.5rem] w-[1.3rem] dark:hidden" />
            <MoonSVG className="hidden h-5 w-5 dark:block" />
            <span className="sr-only">Toggle theme</span>
        </button>
     </>
    );
};

export default ThemeSwitch;

In the code snippet above, we are using the useTheme hook to get the current theme (theme) and the function to set the theme (setTheme).

The useEffect hook is used to set mounted to true after the initial render. This ensures that the component is mounted before attempting to render the theme switch button.

The onClick event of the button triggers a function that toggles the theme between 'light' and 'dark'.

The visibility of these icons is controlled based on the current theme. The dark:hidden and dark:block classes are used to show/hide the icons based on whether the dark theme is active or not.

We can now add our ThemeSwitch component to the header component.

//components/header.tsx

//other imports
import ThemeSwitch from './theme-switcher';

export const Header = () => {
// other code   
    return (
    <header className="border-b bg-slate-950 py-10 dark:border-neutral-800 dark:bg-neutral-900">
        <div className="col-span-2 flex flex-row items-center justify-end gap-5 text-slate-300 lg:col-span-3">
            <nav className="hidden lg:block">{navList}</nav>
            <Button href={baseUrl} as="a" type="primary" label="Book a demo" />
            <!--Add theme-switch component here-->
            <ThemeSwitch/> 
        </div>
    </header>
    );
};

By doing just that we have successfully implemented the Theme Switcher functionality.

Conclusion

In summary, Tailwind CSS allows us to quickly and easily change the look of our blog. We can tweak things like card layouts, fonts, colors, and more using simple classes. Feel free to play around with it! If you have any questions or ideas, drop them in the comments, and I'll be happy to help. Happy coding!

In this tutorial, I will show you how to use the content-driven commerce approach to improve your top-of-funnel (TOF) and middle-of-funnel (MOF) marketing goals by creating a business blog. More importantly, I will show you why you should integrate Hashnode Headless CMS with your ecommerce store. We'll explore how this integration can revolutionize your approach to content-driven commerce, enabling you to deliver compelling experiences that drive brand awareness, conversions, and foster long-term customer relationships.

Prerequisites

To get the best out of this tutorial, you need to have the following:

• An existing Hashnode account (you can create one here).

• An existing ecommerce store built using any platform (I will also show you one).

• The ability to navigate through a web browser, IDE, and terminal on your computer.

• A smile on your face :).

The State of Content-Driven Commerce

Usually, brands build their e-commerce stores with a monolith, headless, or composable architecture (don't panic, these are just expensive words that explains how the ingredients that make up an e-commerce store are used to actually cook the store 😅). They handle the commerce logic with a custom implementation or use platforms like Shopify, Magento, etc. and product content using dedicated CMSs like Contentful, Sanity, etc.

After sorting the technical details, what comes next is how to generate revenue with that beautiful ecommerce website. According to Insider Intelligence, we expect global e-commerce sales to hit $6.3 trillion worldwide in 2024 with 2.71 billion people shopping online. This rise will lead to increased demand and competition, forcing businesses to find innovative ways to find potential customers wherever they are and convert them. One of such ways is content!

In today's competitive age, more than simply having a storefront is required to win customers' hearts. Customers expect more than just a list of products and categories; they want a curated experience that guides them through their purchasing journey. Content-driven commerce allows businesses to integrate engaging content with their e-commerce product data to deliver an attractive shopping experience. This usually includes product images and videos on a product page, but it shouldn't stop there. As an e-commerce business owner or a marketing specialist working for an e-commerce business, you need to leverage other content commerce activities in your marketing funnel activities. These activities can include:

• Writing about new product launches, product news, targeted articles, buyer guides, hot and trending highlights, product comparisons, etc.

• Announcing new discounts, giveaways, sales events, or special promo offers.

• Curating gift guides for different seasons, holidays, and personas.

• Collaborating with brand ambassadors or influencers to create promotional content, product guides, product tips, etc., featuring your products.

• Telling customer stories and highlighting exceptional customer reviews to build trust and credibility like Nike and Adidas does.

• And many more!

With this approach, you can also make your blog a marketplace where customers can directly shop from by promoting your brand and products or curating catalogs arranged by tags and categories. A good example is The Strategist, a site for helping people shop smartly with different curated products packaged with good storytelling. These types of SEO-optimized content will bring more inbound traffic and potential customers to your store. Imagine a customer searching for the query "What can I buy for my wife who loves running?" and the search engine recommends a content piece from your store's blog that suggests different sportswear products and enough information to make the reader decide to purchase on your store 🤯.

All the content ideas above suggest that you need a blog! Somewhere, you can write and publish different articles, arrange them together, and deliver them on the internet. When you add a business blog to your e-commerce store, you can use these content pieces to improve the SEO/SEM of your e-commerce business, drive sales, and increase retention. While there are so many ways you might want to do this, I'd like to introduce you to Hashnode Headless CMS, a powerful CMS optimized for building blogs for independent publishers and brands.

Hashnode for Ecommerce Brands

Hashnode was built to provide a hassle-free blogging platform for developers and engineering teams. One of the key selling features is the great editor, the ability to set up a custom domain easily, and an API you can use to fetch your posts anywhere else you want. Recently, Hashnode announced a new product that extends the capabilities of their API, offering more customization for blog owners. You now get the option to use their upgraded GraphQL APIs to build your blog's UI using any tech stack of your choosing or use their superb Next.js starter kit. Now, e-commerce businesses like yours can create a team blog and customize it to match the styling of your e-commerce store!

As discussed earlier, having a blog is key for e-commerce businesses wanting to win. You can create one using all the traditional existing platforms or even an actual headless CMS, but Hashnode offers even more benefits than those. Most traditional CMSs lack an editorial content review process and are not cost-efficient, amongst other key issues, unlike Hashnode, which is optimized for blogging from the roots (including SEO, unique features, editor, etc.). Using Hashnode Headless CMS will offer you the following:

• A powerful editor: With both a WYSIWYG and markdown editor, you can structure your text, add callouts, widgets, embeds (including product videos and direct links to purchase or checkout products!), etc. There are also AI features you can use to generate outlines, optimize your content for SEO, etc.

• A seamless content review process: You can create a team blog and add multiple employees with different permissions. Each staff member can submit their article drafts, and the editors can review them before publishing.

• In-built analytics dashboard: You view the data (views, unique visitors, demographics, device details, etc.) in the Hashnode dashboard or the advanced public analytics dashboard like this one.

• Tags and series: You can add multiple tags to blog posts, making it easier for your readers to filter posts. In the demo blog, I have created (which I will show you soon), you can see this in action with the #product-releases tag. You can also create series, add multiple posts to them, and pin them on your blog's navbar like this one!

• Webhooks: You can set up a webhook integration to trigger some external automation (with platforms like Zapier, n8n, etc.) when certain events occur (like a published blog post). You can use this to make an automated social media post or send notifications to unique customers in your loyalty program.

There are just so many more features you can access right on the spot once you create a blog with Headless Hashnode CMS. You can utilize all these features to supercharge your e-commerce business at a low cost and with little to no technical knowledge. All you need is to have one of your tech support staff (or do it yourself if you have the experience) set up the blog, and your content team can click around in the dashboard to set up the blog as you desire and publish new posts! Even better, if your e-commerce store sells products for developers like mechanical keyboards, blue-light glasses, electronics, etc., you can list your blog posts on the Hashnode community feed, which is viewed by thousands of developers like me.

Integrating Hashnode with an Ecommerce Store

Now that you're familiar with the numerous benefits of Headless Hashnode let's create one from scratch and sync it with the ecommerce store. There are different ways you can use Headless Hashnode; you can:

1. Use the GraphQL API to build a custom blog using any tech stack you want (there's documentation you can read to do this) and deploy anywhere.

2. Use the pre-built Next.js Starter Kit that comes with all the UI components you need and deploy anywhere. You can also extend the UI and add further features you need. This will save you all the development time and enable you to ship your blog before you need to drink another cup of water :).

For this tutorial, we will use the Starter Kit approach and set up a blog on a sub-path like yourdomain.com/blog, but you can also use a subdomain like blog.yourdomain.com. You can even go for non-traditional names like /articles, /hub, /stories, etc. 🙂. This way, your customers can find your blog from the store and vice versa.

Building a Demo Ecommerce Store

To show you the power of Headless Hashnode coupled with an e-commerce store, I have built a demo international e-commerce store using the commercelayer-sanity-template and deployed it with Vercel on the https://hh-store.vercel.app domain. This store comes with:

• A user-friendly and performant storefront (with products, categories, i18n, cart, checkout, demo data, etc.) built with TypeScript, React18, Nextjs, Commerce Layer React Components library, and Tailwind CSS.

• International transactional functionalities powered by Commerce Layer API.

• Structured content and a customizable Sanity CMS authoring environment (including demo data), accessible on <domain>/studio.

• PSD2-compliant and production-ready checkout functionality powered by Commerce Layer React Checkout application.

• Localization support (including Italian and French translations).

You can create your store using any tech stack or even platform of your choosing, like Shopify, WooCommerce, Medusa, Wix, Swell, Magento, etc. The image below shows what the deployed version looks like (you can also test it live here):

To learn how to build the e-commerce store in detail, I advise you to read this comprehensive documentation. But here's a quick guide on what you need to do.

1. Create a free Commerce Layer and Sanity CMS account. With Commerce Layer, you will create your inventory (markets, SKUs, prices, stock locations, stock items, etc.), and in Sanity, you will add all the product content (text, images, etc.). This is because some ecommerce platforms separate transactional logic from content for many reasons and benefits. For this tutorial, there will be seed data to import.

2. Clone or fork the template (learn how to do this).

3. Rename the /env.local.example file to .env.local and add the following required credentials:

4. Install the required dependencies with the command below:

pnpm install

5. Start the development server with the command below:

pnpm run dev

The store should start running now on localhost:3000. As mentioned earlier, kindly read the documentation to learn more (including how to import the seed data for both the transactional commerce data and product content data). We won't cover all of these since it's out of scope for this tutorial. If you're reading this tutorial, I'd assume you already have your sleek ecommerce store set up somewhere using your chosen e-commerce platform :).

Building the Blog with Hashnode Headless CMS

Now that we have an e-commerce store running, let's set up a new Headless Hashnode Blog using the Starter Kit! First, ensure you have created a Hashnode account and a Team Blog. You can use Headless Hashnode with the Personal Blog too, but the Team Blog offers more features suitable for an ecommerce business. Headless Hashnode for team blogs is currently in beta, but you can fill out this form to inquire about pricing and additional details.

Once your blog is up and running, head to the "Advanced" tab (just at the left-bottom section of the page) in the dashboard and toggle the "Enable Headless Mode" option. This will let Hashnode know that you intend to host your blog yourself, and you can provide the base URL. In this case, my store is deployed on https://hh-store.vercel.app, and I intend to host the blog on the https://hh-store.vercel.app/blog subpath.

Now that we have this configured follow the steps below to get your blog shipped:

1. Head to the open-sourced GitHub repository and fork the Starket Kit into your personal or organization account. The project comes with different themes in a monorepo, which you can find in the packages/blog-starter-kit/themes directory. For this tutorial, we will use the enterprise theme.

2. Now, you will deploy your fork of the repository to Vercel, a cloud hosting platform. Once you're signed in, click on the "Add New" button at the top right section of the page and select "Project". You will then be redirected to a new page.

3. In the new page, choose the repository you want to import (the same one you forked earlier).

4. Select packages/blog-starter-kit/themes/enterprise as the Root Directory and Next.js as the Framework Preset, and then enter the environmental variables seen below.

NEXT_PUBLIC_HASHNODE_GQL_ENDPOINT=https://gql.hashnode.com
NEXT_PUBLIC_HASHNODE_PUBLICATION_HOST=hh-store.hashnode.dev
NEXT_PUBLIC_BASE_URL=/blog
NEXT_PUBLIC_MODE=production

NEXT_PUBLIC_HASHNODE_PUBLICATION_HOST should contain your Hashnode blog's default URL (yourhandle.hashnode.dev), and NEXT_PUBLIC_BASE_URL is the subpath you want to deploy the blog on. If you're deploying on a subdomain, you can exclude this variable, proceed to deploy the project, and then connect the custom domain in Vercel. The same process will apply if you're using any other cloud hosting platform.

With this process, I have deployed the blog on a new domain: https://hh-store-blog.vercel.app (you can choose any name you want here). But since we chose the subpath method, we need to add rewrites to the deployed ecommerce store. Since the store is also built with Nextjs, we can update the next.config.js file like so:

const nextConfig = {
  async rewrites() {
    return [
      {
        source: "/blog",
        destination: "https://hh-store-blog.vercel.app/blog"
      },
      {
        source: "/blog/:path*",
        destination: "https://hh-store-blog.vercel.app/blog/:path*"
      }
    ];
  }
};

export default nextConfig;

Nextjs Rewrites allow us to map an incoming request path to a different destination path. So when a user goes to https://hh-store.vercel.app (the store) and clicks a link to the /blog subpath, it will render the project in https://hh-store-blog.vercel.app/blog (the blog) on the same subpath. And that's about it!

Conclusion

You will agree with me now that Headless Hashnode is more suited for your next blog. You can even create an independent business from this, like The Strategist, without owning an e-commerce business and leveraging the content-driven approach to offer value to e-commerce brands and customers. I look forward to seeing the ideas you will bring to life from this; please let us know whenever you do :).

For the purpose of this tutorial, I have consolidated both the code for the ecommerce store and blog in this GitHub repository, just in case you want to explore all the customizations I have done. It's not a monorepo, and both projects are currently not sharing any data. I only extracted the enterprise theme from the starterkit and pulled in the ecommerce store. But for your case, you might want to share some UI between your store and blog (like header and footer), so you might consider going this route then. That said, you can now customize the blog as you desire and start publishing engaging content for your brand and customers.

As Guillermo Rauch said, Hashnode reminds us of what Substack did for journalists; but now, Hashnode is doing something for enterprise teams, e-commerce entrepreneurs, and businesses. I hope you enjoyed reading this tutorial and learned something new. You should also read this one to learn more about how Headless Hashnode offers more benefits than the traditional CMS platforms.