Learn Http, Playwright and Ramda

Debugging complex web forms can be a grind. You manually input data, check console logs, and painstakingly try to reproduce bugs. This lesson unveils a powerful, largely automated workflow using Cursor's AI agent in conjunction with the Playwright MCP to thoroughly test a web form, identify issues, and even fix the underlying code.

First, you'll see how to instruct the AI to instrument your form's code with exhaustive console logging. Then, by providing only the URL of the live form, you'll delegate the testing process to the AI, which uses Playwright to interact with the form in multiple ways, attempting to break it and discover edge cases. The AI then analyzes the generated console logs to produce a detailed report of its findings. Finally, armed with this report and the original code, the AI can attempt to fix the identified bugs and re-verify its changes, all while you "go get a sandwich."

**Workflow demonstrated in this lesson:**

*   Instruct Cursor's AI agent to add comprehensive `console.log` statements to your form's TypeScript (.tsx) file.
*   Provide the live URL of the web form (running on `localhost`) to the AI, without giving it direct access to the updated code file.
*   Direct the AI to use the Playwright MCP to open the URL in a browser.
*   Task the AI with devising and executing multiple test scenarios (e.g., empty submission, invalid inputs, mismatched passwords) to fill out and submit the form.
*   Have the AI retrieve and analyze the browser's console logs after each test attempt.
*   Generate a consolidated report detailing the form's behavior, observed errors, and potential bugs based on the logs.
*   Instruct the AI to use this report and the original form code (now brought back into context) to fix the identified issues.
*   Optionally, have the AI re-run the tests to verify the fixes.

**Key benefits:**

*   **Automated Test Execution:** Leverage Playwright through Cursor to automatically interact with your live form.
*   **AI-Driven Test Case Generation:** The AI devises different input strategies to uncover bugs.
*   **Log-Based Bug Reporting:** Automatically capture and analyze console output to pinpoint issues.
*   **Hands-Off Debugging:** Delegate the testing and initial bug reporting to the AI.
*   **Efficient Bug Fixing Cycle:** Use AI-generated reports to quickly guide AI-assisted code corrections.
*   **Focus on High-Level Direction:** Instead of manual testing, you guide the AI's testing strategy and bug-fixing process.

By the end of this lesson, you'll have a robust method for delegating the tedious aspects of form testing and debugging to Cursor's AI, allowing for more efficient development and a more reliable end product.

---

**Phase 1: Instrumenting Code with Exhaustive Logging**

**Context:**
*   `{@filePath}` (e.g., `App.tsx`) is in Cursor's context.

**Prompt:**
"In `{@filePath}`, add exhaustive console logging for all form events, state changes, and validation logic. Focus on capturing input values, current errors, and the outcome of validation checks. The goal is to have detailed logs for later analysis. Do *not* fix any existing code errors; only add logging. Stop after modifying the file."

---

**Phase 2: AI-Driven Form Testing with Playwright and Log Analysis**

**Context:**
*   `{@formURL}` (e.g., `http://localhost:5173`) is in Cursor's context.
*   The live form at `{@formURL}` should be running the version of the code that *includes the exhaustive logging* added in Phase 1.
*   Playwright MCP is available.

**Prompt:**
"Using the Playwright MCP and the live form at `{@formURL}`:
1.  Devise [N, e.g., 3-5] distinct test scenarios to fill out and submit the form. Include scenarios designed to trigger validation errors and edge cases (e.g., empty submission, invalid data types, boundary values, mismatched passwords).
2.  For each scenario:
    *   Execute the form interaction using Playwright.
    *   Retrieve all browser console logs generated during that interaction.
3.  Compile a consolidated 'Form Behavior Report' detailing:
    *   Each test scenario and the inputs used.
    *   Observed behavior/UI state (e.g., error messages displayed).
    *   Key console log outputs relevant to errors or unexpected behavior.
    *   Any discrepancies or potential bugs identified.

---

**Phase 3: Fixing Bugs Based on AI Report and Re-Verification**

**Context:**
*   The 'Form Behavior Report' from Phase 2 is in the chat history.
*   `{@filePath}` (e.g., `App.tsx` – the original file, *not* the one Playwright interacted with, unless it's the same deploy) is in Cursor's context.
*   The live form at `{@formURL}` can be updated/re-deployed with fixes.
*   Playwright MCP is available.

**Prompt:**
"Based on the 'Form Behavior Report' (from our previous conversation) and the code in `{@filePath}`:
1.  Analyze the reported issues and implement the necessary code changes in `{@filePath}` to fix them.
2.  After applying the fixes and assuming the live form at `{@formURL}` is updated with these changes:
    *   Re-run *all previously defined test scenarios* using the Playwright MCP.
    *   Retrieve and analyze the console logs for each.
3.  Provide a verification summary: confirm if the original bugs are fixed and if any new regressions were introduced."

John Lindquist

Capture Browser Logs with Playwright MCP in Cursor to Generate Reports

Fixing runtime errors in web applications, especially those that require browser interaction or appear in stages, can be a tedious back-and-forth. This lesson demonstrates how to create a powerful, automated debugging loop using Playwright MCP integrated into Cursor IDE via custom Rules, allowing the AI to interact with your live application, identify errors, and iteratively fix them.

**Workflow demonstrated in this lesson:**

*   Install and configure the Playwright MCP server in Cursor settings.
*   Create a custom Cursor Rule (e.g., "autofix") instructing the AI to:
    *   Use Playwright MCP to open a specified URL in a browser.
    *   Check for any errors displayed on the page.
    *   Automatically attempt to fix those errors in your codebase.
    *   Iterate this process until all errors are resolved.
*   Invoke the custom rule within Cursor's AI Agent, providing the application's URL.
*   Observe the AI agent launch Playwright, navigate the browser, identify errors, and apply code changes.
*   For errors hidden behind UI elements (like an error button), provide a screenshot to the AI, instructing it to interact with the UI to reveal and then fix subsequent errors.

**Key benefits:**

*   **Automated Debugging Cycle:** Let the AI handle the repetitive task of launching, testing, and fixing common web application errors.
*   **Iterative Problem Solving:** The AI can tackle multiple errors sequentially, making changes and re-testing.
*   **Browser Interaction:** Leverages Playwright to understand the application's state directly from the browser.
*   **Visual AI Assistance:** Use screenshots to guide the AI in interacting with UI elements to uncover and fix deeper issues.
*   **Reduced Manual Effort:** Spend less time manually debugging and more time on feature development.

By combining Playwright MCP with Cursor's AI Agent and custom Rules, you can significantly streamline your web development workflow, turning a frustrating debugging process into an automated one.

---

```json
    "playwright": {
      "command": "pnpm",
      "args": ["dlx", "@playwright/mcp@latest"]
    }
```

```
Please use the Playwright MCP to open a browser to the URL I provide, check for any errors, and then automatically fix those errors in my codebase, then continue to iterate until all the errors are gone.
```

Autofix Browser Errors with the Playwright MCP in Cursor

Automate browser-based debugging in web apps using Playwright MCP and Cursor IDE Rules—AI detects and fixes errors in real-time with minimal dev effort.

Astro is a flexible web framework that allows you to build fast websites to suit your needs.

By default, Astro will build your site using Static Site Generation (SSG). This means the data in your site is loaded at build time so that the end-user gets served static pages that load quickly.

While Astro defaults this way, it also has Server-Side Rendering (SSR) that you can enable if you have more serverful needs in your application.

Along similar lines, Astro utilizes HTML and the browser as a default but when you need more flexibility you can opt into an Astro Island. Islands use React, Vue, Angular, or any frontend JavaScript framework you are used to enhance the user experience in your site.

astro

Now that we have our database set up, we need to use it!

On our blog post page, we have a likes button waiting for us to implement the likes feature. On page load, we'll make a fetch call to a `/api/likes/[slug].ts` GET end point to return the number of likes for the page. 

Similarly, when someone clicks the like button we want to send a POST request to that same endpoint.

On the server side we will set up `GET` and `POST` handlers to implement this functionality. In those functions we'll use Drizzle to return the likes for that blog post and in the case of a `POST` we'll create a record if it doesn't exist or increment a like if it does and return.

Astro API endpoints utilize browser `Response` API so you'll get a chance to handle returning different status's based on the data present.

Create Astro API Endpoints to Get and Update Database Records using Drizzle ORM

Playwright is a framework for reliable end-to-end testing of modern web apps.

playwright

Playwright provides a simple library that you can install via npm for automating various browser engines. That is what we demo in this lesson.

Playwright Library for Browser Automation

In this lesson we look at the Playwright Test concept of Fixtures. We demo the creation of various fixtures and explain the idea behind browser, context and page.

Playwright Test Fixtures, Browser Context and Page

In this lesson we demonstrate how you can create Page Objects in Playwright. The Page Object Model (lovingly called pom) is a great way to simplify your test code and make it more easy to understand and maintain in the long run.

Page Object Model Pattern with Playwright

In this lesson we look at various ways you can select different elements on page using Playwright Selectors. We also demo playwright selector engines and selector chaining

Playwright Selectors

A common post mortem debugging tool for e2e tests is screenshots and videos. These can be enabled via options in the Playwright config and that is what we demo in this lesson.

Capture Failed Test Videos and Screenshots with Playwright

Playwright provides a powerful tool in the form of the trace viewer to help you debug any issues in your test after they have failed. That is exactly what we demo in this lesson.

Postmortem Debugging Failed Tests with the Playwright Trace Viewer

In this lesson we introduce the codegen feature of Playwright which can be used to quickly generate automation / test code.

Quickly Generate Playwright Tests with Codegen

In this lesson we look at how you can use the playwright inspector to debug any issues in your tests. We run through a sample test and guide you through the various portions of the playwright inspector UI.

Debugging Playwright Tests with Inspector

GitHub fosters a fast, flexible, and collaborative development process that lets you work on your own or with others.

github

In this lesson we look at why you would need to generate snapshots on your CI server. We follow this up by creating a simple Github Action that will generate new snapshots against a pull request once you leave a specially formatted "slash command" style comment.

Generate Playwright Snapshots on your CI Server

In this lesson we look at how you can do simple VRT (visual regression testing) using Playwright tests.

Visual Regression Testing with Playwright

Visual Studio Code is an integrated development environment (IDE) built and maintained by Microsoft. It is offered free of charge.

vscode

We look at the various features of the VSCode Extension for Playwright and how it can help you with your testing workflow.

Playwright VSCode Extension

In this lesson we look at how you can add playwright to your existing web application. Along the way we also look at other neat stuff like beforeEach, describe, async web-first matchers and the hasText locator option.

Adding Playwright to your Web App

This lesson covers the basics of Playwright's testing API such as the page object, locator, locator methods and expect.

Playwright Tests API Basics

In this lesson we demo how you can quickly get setup and start using Microsoft Playwright for cross browser Web Application testing.

Setting up Microsoft Playwright

The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers.

http

We're adding Github authorization to our client app

Create a function that is called on window load. In that function store the parameters that get sent over to the Github auth server. 

In our query params, we will set the response_type parameter to "code" in order to ask the auth server for a code. Asking for a code from the auth server is more secure than asking for the access token through a browser

Finally, create a URL from the params and an authorization endpoint. Using a query selector select an anchor tag and set the href attribute to the URL that you created.

Add GitHub Authorization to an OAuth Client App

Express is a minimal and flexible Node.js web application framework that provides a robust set of features for web and mobile applications.

express

We'll create our client-server using the `express` and `cors` packages

Express will be used to create our HTTP application. We'll need it to post to our endpoints and listen to our port.

We need the `cors` package to make cross-origin requests since the front-end will be a different origin than the server.

Create an OAuth Client-Server for code/token exchange

We'll be parsing the authorization code sent in our query before sending it to the server.

We do this by creating a function that parses our query and retrieves the code parameter. If we find a code in the query we send the code to our server by using `fetch` to make a `POST` request. In the body of the request we send the code and the state in stringified JSON.

Once we make the request we can await a response and store its JSON data (the auth token) in a variable. In a real application, we might also redirect to the homepage or the page the user was just on.

Parse for the Auth Code in a Query before Sending It to a Server

We're going to refactor some of our HTTP application code in order to create the ability to exchange the code inside our HTTP request for a token. 

We can do this by creating a function that takes the code from a request and posts a query that contains our client id and secret to our token endpoint. We then await a response, parse the data from the response, and then return the parsed data.

Exchange Auth Code in a Request for an Access Token

Hardcoding your script to search for only one type of file (like `.md`) is a major limitation. This lesson shows you how to make your script smarter by teaching it to infer the desired file type directly from the user's natural language prompt.

You'll implement a two-stage AI process. The first stage analyzes the user's request to determine the file extension they're interested in (e.g., `md`, `txt`). The second stage then uses that file type to dynamically search the file system, find the relevant files, and execute the command.

**Workflow demonstrated in this lesson:**

* Add a preliminary `generateObject` call to extract a `fileType` from the user's initial prompt.
* Define a list of supported `fileTypes` (e.g., `['md', 'txt']`) and use a detailed prompt to guide the AI, instructing it to choose from the list or use a default.
* Dynamically construct the `globby` pattern using the inferred `fileType` (e.g., `*.$[fileType]`).
* Implement error handling to inform the user if they request an unsupported file type or if no files of the specified type are found.
* Demonstrate how the script defaults to searching for Markdown files but can correctly search for other types when specified (e.g., "summarize my profile from my pdf").

This technique adds a significant layer of intelligence to your script, allowing it to adapt its behavior based on the user's intent and making it a far more flexible and intuitive command-line tool.

Dynamically Inferring File Types from User Prompts in Local AI Scripts

Hardcoding command logic and prompts directly into your script makes it rigid and difficult to extend. This lesson demonstrates a more flexible and powerful pattern: defining your script's commands as individual Markdown files in a dedicated directory.

This approach allows you to easily add, remove, or modify commands without touching the core script logic. You'll learn how to dynamically load these command files, present them as options to the AI, and inject the corresponding instructions into your prompt, creating a truly modular and extensible tool.

**Workflow demonstrated in this lesson:**

* Create a `commands` directory to house your command definitions (e.g., `summarize.md`, `translate.md`).
* In each file, write the specific prompt or instructions for that command.
* Use `globby` to discover all available command files at runtime.
* Create a `commandMap` that maps the filename (e.g., "summarize") to its file content.
* Update the Zod schema to use an `enum` of the dynamically discovered command names.
* Dynamically construct the final text generation prompt by injecting the instructions from the user-selected command file.
* Add a `profile.md` file to demonstrate how the script can act on user-created content with the new file-based commands.

By the end of this lesson, your script will be architected for easy expansion, allowing you to build a robust library of custom commands simply by adding new text files.

Creating Dynamic, File-Based Commands for Local AI Scripts

AI models won't always give you the answer you expect; sometimes they'll return invalid data or "hallucinate" a response that doesn't fit your schema. This lesson teaches you how to make your local AI script more robust by implementing essential error handling for user commands.

You'll learn how to validate the AI's output against a predefined list of valid commands and gracefully catch errors when the model generates an unexpected response, ensuring your script fails predictably and provides helpful feedback to the user.

**Workflow demonstrated in this lesson:**

* Define a list of `validCommands` (e.g., `summarize`, `translate`, `review`) to constrain the AI's choices.
* Wrap the `generateObject` call in a `try...catch` block to handle cases where the AI's output doesn't match the Zod schema.
* Implement a type guard function (`isValidCommand`) to check if the command returned by the AI is in your list of valid commands.
* Provide clear error messages to the user, indicating what went wrong and what the valid commands are.
* Test the script with invalid commands (like "taco" or "delete") to confirm that the error handling works as expected.

By adding these checks, you make your script significantly more reliable and user-friendly, preventing it from crashing on bad input and guiding the user toward correct usage.

Handling Invalid Commands and AI Errors in Local Scripts

Once your script can understand a user's command and identify a target file, the next step is to perform an action. This lesson shows you how to use the Vercel AI SDK's `generateText` function to process a file's content and produce a relevant, AI-generated response.

You'll learn how to read the content from the file path you've already identified, combine it with the inferred command into a new, more detailed prompt, and then pass it back to your local AI model to generate a final text output, such as a summary or a review.

**Workflow demonstrated in this lesson:**

* Import the `generateText` function from the `ai` SDK.
* Read the file content from the `filePath` returned by `generateObject`.
* Construct a new, structured prompt that includes the original command (e.g., "summarize") and the full content of the file.
* Pass this new prompt to the `generateText` function.
* Log the resulting AI-generated text to the console.
* Run the script with commands like "Summarize our TypeScript config" or "Review my package file" to see the full, context-aware output.

This lesson completes the core cycle of your AI script: understanding a command, reading the relevant context, and generating a useful, text-based result, all on your local machine.

Generating Text with a Local AI Model Based on File Content

A command is useless without knowing what to act upon. This lesson elevates your local AI script by giving it context from your project's file system. You'll learn how to find all relevant files and empower the AI to intelligently select the correct one based on your prompt.

The core technique involves using the `globby` package to scan for files and then feeding that list into a Zod `enum`. This constrains the AI's choices to a valid set of files, allowing it to accurately determine which file you're referring to in a natural language command.

**Workflow demonstrated in this lesson:**

* Install and import the `globby` library to find files based on a pattern (e.g., all `.json` files).
* Add a `filePath` field to your Zod schema.
* Define the `filePath` as `z.enum(files)`, where `files` is the array of file paths returned by `globby`.
* Pass a natural language prompt like "Summarize our typescript config" to the script.
* Observe how the AI correctly identifies `tsconfig.json` from the list of available JSON files and returns it as structured data.

This lesson is a crucial step toward building powerful, context-aware tools that can intelligently interact with your project's files based on simple, human-readable commands.

Providing File System Context to Local AI Scripts with Globby and Zod Enums

Hardcoded prompts are great for testing, but a truly useful script needs to respond to dynamic user input. This lesson shows you how to make your local AI script interactive by capturing command-line arguments.

You'll learn how to use Node.js's built-in `parseArgs` utility to take a user's natural language command directly from the terminal and pass it to your local language model for processing.

**Workflow demonstrated in this lesson:**

* Import the `parseArgs` function from the `node:util` module.
* Configure `parseArgs` to accept positional arguments from the command line.
* Replace the static, hardcoded prompt with the dynamic input provided by the user.
* Run the script with different sentences (e.g., `"Download a file"` or `"I want to download a file"`) to demonstrate that the AI can correctly infer the core command regardless of the phrasing.

By the end of this short lesson, your script will be able to accept and process commands directly from the user, making it a flexible and reusable command-line tool.

Processing Dynamic User Input in Local AI Scripts

While command-line chats with local AI models are useful, the real power comes from scripting. This lesson walks you through the initial setup for creating powerful, local AI-driven scripts by combining Ollama, the Vercel AI SDK, and Zod.

You'll learn how to take a natural language command, like "Concatenate all of the markdown files in my Downloads folder into a single file," and use the `generateObject` function to intelligently extract structured, actionable data from it.

**Workflow demonstrated in this lesson:**

* Install and set up the `ollama-ai-provider`, `ai`, and `zod` packages.
* Create a local AI model instance using Ollama and the Gemma 3 model.
* Define a Zod schema to specify the exact data structure you want to extract (e.g., `{ command: string }`).
* Use `generateObject` to pass a natural language prompt to the local model and receive a structured JSON object that matches your schema.
* Run the script using `bun` to see the local model successfully infer the "concatenate" command from a full sentence.

This foundational lesson unlocks the ability to build sophisticated, automated workflows by translating human language into machine-readable commands, all running entirely on your local machine.

Scripting Local Language Models with Ollama and the Vercel AI SDK

### **Build Powerful, Local AI-Driven Command-Line Scripts**

Go beyond simple AI chats and unlock the true potential of local language models by learning to script them. This course will guide you step-by-step through the process of building a flexible and intelligent command-line tool that can understand natural language, interact with your file system, and automate complex tasks—all running entirely on your local machine.

Starting with a blank TypeScript file, you'll learn how to combine the power of **Ollama**, the **Vercel AI SDK**, and **Zod** to create a script that's not just functional, but smart. We'll begin by teaching the AI to parse a simple command from a sentence. From there, we'll progressively add layers of sophistication: processing dynamic user input, making the script aware of your project's files, and generating meaningful text-based output.

You'll also learn critical patterns for building robust and extensible tools. We'll cover how to handle invalid commands and unexpected AI responses gracefully. Then, you'll refactor the script to use a modular, file-based system for its commands, allowing you to easily add new functionality without touching the core logic. Finally, we'll add a layer of intelligence that allows your script to infer exactly what you mean, right down to the type of file you want it to process.

By the end of this course, you will have built a powerful, personalized AI assistant and gained the foundational skills to create sophisticated local automations for any task you can imagine.

**What You'll Learn:**

* How to script local language models using Ollama and the Vercel AI SDK.
* To parse and process dynamic user input from the command line.
* To use Zod schemas, including `enums`, to validate and structure AI model output.
* Techniques for providing file-system context to your scripts with `globby`.
* How to generate context-aware text based on file content.
* Robust error handling for invalid user commands and unexpected AI responses.
* To build a modular and extensible tool by defining commands in separate files.
* To intelligently infer user intent, such as dynamically determining file types from a prompt.

Build a local AI-powered command-line assistant from scratch. Learn to use Ollama, Vercel AI SDK & Zod to parse input, automate tasks, and run scripts offline.

This lesson demonstrates how to give Cursor direct access to your terminal output using the [Nx MCP extension](https://nx.dev/getting-started/ai-integration?utm_source=youtube&utm_medium=videos&utm_campaign=Nx-AI&utm_id=Nx-AI), enabling automatic error detection and fixing in monorepo projects.

**Workflow demonstrated in this lesson:**

- Encounter a runtime error when serving a Vite application in an Nx monorepo
- Install and configure the Nx Console extension with MCP integration
- Ask Cursor to check your terminal for errors and fix the underlying issues
- Watch as the AI accesses running task details and terminal output through Nx MCP tools
- Observe how it analyzes workspace relationships to identify incorrect imports and missing dependencies

**Key benefits:**

- Seamless Error Handling: AI gains direct access to terminal output and running task information
- Automatic Diagnosis: Accurately identify the root cause of errors without manual copying
- Context-Aware Fixes: Leverage workspace knowledge to implement proper solutions
- Reduced Context Switching: Eliminate the need to manually relay information between terminal and AI



Juri Strumpflohner

Enable Cursor to directly access the terminal to read the output and fix issues

See how Nx MCP gives AI coding assistants direct access to terminal output and running tasks, enabling automatic error detection and fixing.

This lesson demonstrates how to solve the predictability problem when using AI to generate code in monorepos by combining Cursor with Nx generators.

**Workflow demonstrated in this lesson:**

- Explore how Nx generators provide predictable scaffolding for new libraries
- Set up [Nx Console with MCP](https://nx.dev/features/enhance-AI?utm_source=egghead&utm_medium=videos&utm_campaign=Nx-AI&utm_id=Nx-AI) integration to expose generator capabilities to Cursor
- Use the AI assistant to brainstorm a new feature with the help of the Nx MCP tools
- Have Cursor leverage the Nx MCP tools to trigger the appropriate Nx generator for creating a React-based feature library
- Observe how the AI assistant takes the generated library and further integrates it into the codebase

**Key benefits:**

- **Predictable Code Structure**: Ensure generated libraries follow your project's and organization's conventions
- **Consistent Setup**: Maintain uniform configuration across TypeScript projects and package.json files
- **Guided Implementation**: Combine AI instructions with structured, predictable code generation

Enable Cursor to generate predictable project setups

Learn how to combine Cursor AI with Nx generators for predictable library creation in monorepos, ensuring consistent structure across your codebase.

Search

Search Results