AI Engineer Europe 2026
Beyond Code Coverage: Functionality Testing with Playwright
Read the talk
Beyond Code Coverage: Testing What Users Can Do with Playwright
As agents generate more code, behavioral tests provide a stable target: make the feature work, then improve its implementation without breaking what users can do.
From a talk by Marlene Mhangami
Before you start: Basic familiarity with automated tests, browser applications and TypeScript will help you follow the examples.
More commits, but more productivity?
What does a surge in code tell us about developer productivity? Marlene Mhangami, introducing herself as a senior developer advocate working in Core AI at Microsoft and GitHub, opens with GitHub’s activity figures. She cites approximately one billion commits in the 2025 Octoverse reporting period as GitHub’s busiest year yet. That reporting period runs from September 2024 through August 2025, rather than following the calendar year.
For 2026, Mhangami cites a recent post by GitHub COO Kyle Daigle reporting approximately 275 million commits per week, distinguishing it from official statistics that had not yet been released. She annualizes that pace to approximately 14 billion commits, roughly 14 times the preceding report’s total. This is a projection from a weekly rate, not an observed annual total.
Some of that growth comes from agents. In Mhangami’s account, Claude and GitHub Copilot leave coauthor signatures, while Codex does not; wording can also provide clues about AI involvement. The underlying attribution data had not been released. Even if the volume is clear, the central question remains: does producing more code mean developers are accomplishing more useful work?
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Rework can consume the gains
Mhangami turns to a previous AI Engineer presentation describing Stanford research involving 120,000 developers. Its central distinction is how developers use AI: clean codebases can amplify its gains, while unchecked generation can amplify codebase entropy. The condition of the system receiving the new code matters alongside the speed of producing it.
In the company case Mhangami recounts, PR output increased, but declining code quality and additional rework left only about a 1% increase in effective output. That figure describes the cited company case; the talk does not supply its measurement definition or observation period. More changes entering review were not translating into a comparable increase in useful output.
The practical response is to make codebase quality part of the workflow: test coverage, type coverage, documentation and modularity. Mhangami recommends standardizing these practices across teams, while acknowledging the competing preference for simply shipping quickly. Keeping the codebase understandable is part of realizing AI’s value, not a separate cleanup project after generation.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Separate behavior from implementation quality
Test-driven development offers an existing structure for doing this. Mhangami points to Simon Willison’s Red/green TDD as an example of its use with coding agents. The cycle separates three jobs that are easy to blur together: deciding what should happen, making it happen and improving how it happens.
- Red: Start with an incoming feature request and write a test that fails because the feature does not exist.
- Green: Implement enough code to make that test pass. This phase prioritizes speed; Mhangami’s historical example is copying useful code from Stack Overflow.
- Refactor: Revisit the passing implementation and improve its quality, structure and adherence to the project’s practices.
The green phase establishes working behavior. The refactor phase gives code quality its own explicit place in the process.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A green suite can still test the wrong thing
TDD’s usefulness depends on what the tests protect. Rails creator DHH’s 2014 essay TDD is dead. Long live testing. criticized test-first dogma and excessive emphasis on isolated unit tests. The relevant concern here is that a suite can accumulate code coverage without adequately testing the system. This is a critique of testing priorities, not a reason to abandon automated tests or require only system tests.
Consider an order calculation with a discount. If a test directly calls an internal method named calculate, renaming that method can break the test even when the customer still receives the correct final price. The test has become coupled to an implementation choice.
| Test target | What it protects | Effect of an internal rename |
|---|---|---|
Internal calculate method | A particular implementation entry point | May break the test |
| Final discounted price | Observable behavior | Can remain valid |
| Stable API or exported module | A public contract | Can remain valid |
A stable boundary lets the implementation change while the test continues checking the same promise. For a deeper treatment, Mhangami recommends Ian Cooper’s TDD: Where Did It All Go Wrong?.
AI introduces another failure mode: self-affirming tests. An agent can generate tests that agree with the implementation it has produced, rather than independently checking the intended behavior. Coverage can look healthy and every unit test can pass while the system still does the wrong thing. The feature requirement must supply the expectation; the current implementation cannot be its only source.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Express the requirement as a browser interaction
Playwright is Microsoft’s open source framework for automating browser interactions and testing an application end to end. Mhangami names Python, TypeScript and C# among its supported languages. Instead of reaching into an internal calculation method, a browser test can navigate to a page and interact with the controls a customer uses.
The introductory example opens the toys page with page.goto, finds the search field by its placeholder and fills it with Furby. A TypeScript test for that interaction can also assert the visible result. With baseURL configured for the toy application, the pattern is:
typescript
import { test, expect } from '@playwright/test';
test('search finds Furby', async ({ page }) => {
await page.goto('/toys');
await page.getByPlaceholder('Search').fill('Furby');
await expect(page.getByText('Furby', { exact: true })).toBeVisible();
});
The navigation and input drive the browser; the assertion states the expected outcome. Playwright can run with the browser visible in headed mode or without displaying it in headless mode.
With agents doing more of the typing, the proposed allocation of effort changes. The agent generates failing behavioral tests, then generates code to make them pass. Developers spend more of their attention reviewing and refactoring that code. Mhangami presents this as a way to address the complaint that TDD slows teams down, rather than as a measured speedup: accelerate red and green, then give refactoring the largest share of developer attention.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Connect the coding agent to the browser
Mhangami identifies three integration choices: the Playwright MCP server, a CLI tool, and Playwright Test Agents. MCP and the CLI provide ways for a coding agent to use Playwright; the specialized agents divide testing work into explicit responsibilities.
| Agent | Responsibility |
|---|---|
| Planner | Plan which tests to run |
| Generator | Write the tests |
| Healer | Fix the tests |
In the demonstration’s description, initialization installs three agent instruction files, referred to as agent.md files. Their purpose is to give each role specialized guidance rather than asking one undifferentiated prompt to handle every stage.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Turn the Tailspin Toys request into failing tests
The live scenario places the developer at Tailspin Toys. An email from the search product management team requests a search bar and filtering controls:
- Simple searches: Text search for straightforward queries.
- Complex searches: Azure AI Search.
- Product filters: A sidebar for category and price filtering.
These are customer-facing capabilities, so they provide the starting point for the test plan.
Mhangami works in GitHub Copilot CLI and first asks the agent to bring the email’s requirements into the terminal. She uses Microsoft Work IQ, described in the demonstration as a skill connecting the agent to Microsoft 365 applications such as Outlook and PowerPoint. The important handoff is from workplace context to an explicit list of features the coding agent can act on.
A feature request triggers a test; adding a class method does not have to. This changes the unit of planning. Rather than producing a new test whenever the implementation acquires another method, the agent starts from the behavior requested by the product team.
The second prompt asks Copilot to develop the features using red–green TDD, beginning with failing Playwright tests for each feature. For this example, Mhangami also instructs it not to commit changes. Copilot begins by examining the repository; the Playwright MCP server is already installed in the CLI environment. It needs to understand the existing application before writing tests that exercise it.
Generation takes time, so Mhangami switches to another tab for the browser demonstration. This transition matters: the next run uses prepared work, rather than showing the newly submitted request complete immediately.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Watch search and filters work
Earlier that day, the agent had generated failing tests and then completed the green phase by implementing code to pass them. Mhangami now asks it to run the search and filter checks. Using the installed Playwright MCP integration, the agent locates the test file and starts interacting with the application.
The browser opens the correct page and enters search inputs. Furby is found, followed by Simon. Automated clicks then exercise the category filters, with Mhangami’s hands off the keyboard. Finally, the browser checks toys within a specified price range. The visible sequence makes the tested behavior concrete: search for products, select categories and narrow results by price.
Mhangami reports that all the demonstrated tests pass. That establishes the green point in this walkthrough; it is not the end of the development process. The next step is to refactor the generated implementation while retaining those behavioral checks. That refactoring is recommended, but not demonstrated in the session.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Make results reviewable and changes recoverable
Mhangami recommends attaching test screenshots to pull requests so reviewers can see the application alongside the code changes. Screenshot capture must be configured or explicitly requested: Playwright Test does not capture every test automatically by default. The recording options let a project choose when to retain screenshots.
The visible browser is useful for the walkthrough, but routine runs can use headless mode. Before asking an agent to fix tests or change code, Mhangami recommends committing the current work so there is a recoverable checkpoint; an agent may not reliably remember the previous state. This general advice differs from the explicit no-commit instruction used for the demonstration. She also recommends one test per feature, keeping the tests tied to the capabilities being delivered.
For follow-up, Mhangami points viewers to the slides and Playwright documentation. She also acknowledges that she forgot to include the demonstration’s GitHub repository link.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Stateful applications, screen sizes and native apps
The first audience question exposes a limit of the simple storefront example. The questioner already uses Playwright with Storybook to establish application state and asks how to handle more complex applications and admin panels. Mhangami suggests Playwright Agents because their specialized instruction files may help with state handling. She also suggests testing APIs directly where an API is available. These are proposed approaches; the answer does not demonstrate a fixture or state-setup strategy for a complex application.
A second question asks whether the tests can cover different display sizes. Mhangami confirms that mobile and desktop sizes can be checked, without showing viewport configuration.
The final question distinguishes a mobile-sized website from a native application: what about a Mac app or an iPhone app? Mhangami’s answer scopes the workflow presented here to browser-based testing. The mobile-versus-desktop answer concerns the browser experience, not a demonstration of native application automation.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Simon Willison explains prompting coding agents to write tests, observe failure and then implement passing code.
DHH's 2014 critique of test-first design dogma and argument for greater emphasis on system testing.
Ian Cooper revisits TDD's original intent and misunderstandings that can make testing impede development.
Setup and workflow documentation for Playwright's planner, generator and healer agents.
Microsoft's MCP server for connecting AI assistants to Playwright browser automation.
Tools and plugins connecting assistants to Microsoft 365 workplace data, with Copilot CLI setup instructions and tenant consent requirements.
Further reading
Configure test screenshots, videos and traces, including capture on failures and retries.
Read the complete timestamped transcript
- 0:00
[upbeat music] Okay.
- 0:17
Hi, everyone. Um, my name is Marlene, and I am a senior developer advocate at both Microsoft and GitHub. So I work at-- I work in a group called Core AI, which looks at how developers are using AI across our products.
- 0:34
Um, so this is kind of new. To start off today, I wanted to show you some stats about GitHub from GitHub Octoverse, uh, last year's GitHub Octoverse report in twenty twenty-five, which shows data about how developers are using GitHub.
- 0:50
What we saw from our report was that more code was added to GitHub last year than ever before. So about a billion commits were pushed to the platform in twenty twenty-five, which is GitHub's most active year ever.
- 1:08
Okay? What we know now in twenty twenty-six is that this growth is accelerating. So a couple of-- We haven't actually released any official stats yet, but a couple of days ago, our COO, Kyle Daigle, tweeted that we're seeing about two hundred and seventy-five million commits to the platform every week.
- 1:31
And if we extrapolate that over time, we're going to see about fourteen billion commits by the end of the year. So that's fourteen times the amount of growth we saw last year, or commits we saw last year, which, by the way, last year again, was our biggest year ever with a, a billion commits.
- 1:49
One thing that we know is that there's a growing share of these commits that are co-authored by AI agents. We haven't released the data yet, but we can actually track and see or, you know, some Claude, for example, cosigns commits, and so does Copilot, but Codex doesn't.
- 2:06
But we can also kind of track based off of, uh, some wording in, in the code.
- 2:13
I had a question when I saw all of this growth in terms of how much code we were seeing, and that question is: Does AI actually make developers more productive?
- 2:25
We're seeing all of this code. Does it actually correlate with productivity?
- 2:30
One of the best resources I've seen that tries to answer this question is actually from AI engineer from a talk last year, and this graph shares findings from that talk that's from a Stanford University study of a hundred and twenty thousand developers.
- 2:47
And in this study, um, it found that while, yes, AI can make developers more productive, it's actually how the developers are using AI that matters the most. So this graph from the study actually shows us that clean code bases amplify AI gains and AI productivity, while unchecked AI in a code base is going to amplify
- 3:12
entropy. To illustrate this point, the speaker from this talk gave a case study example of a company that used AI in an unchecked way in their database. And what you can see is that the number of PRs that the team was pushing out increased, but at the same time, the code quality that this team was, was seeing
- 3:32
decreased, and actually, they spent a lot more time reworking that code, refactoring that code. And so overall, though there was effective output increase of like one percent, AI didn't really improve the productivity from this team.
- 3:49
So what we learned from this study is that a lot of value that we are wanting to see as developers from AI relies or hinges on us having a clean code base.
- 4:01
So for developers that are using AI tools, we wanna focus on things like good test coverage, type coverage, and things like good documentation, modularity, and so on.
- 4:12
So I'd actually also argue that we need to start standardizing some practices across our teams and across our industry, and this is something that's a bit of a controversial topic because some people at this conference believe in just closing their eyes and shipping, and that's also okay.
- 4:27
But I think in my ideal world, and from this study we've seen, I would recommend standardized practices for keeping a code base clean. So how can developers maintain-- create and maintain clean code?
- 4:41
This question is actually not a new question. In our industry over time, we have seen several methods that have tried to make, uh, maintaining a clean code base a central part of their philosophy.
- 4:54
One of those approaches that I've actually seen a lot of developers that are doing, uh, agentic coding with coding agents talking about is test-driven development or TDD. Uh, Simon Willison, who's very popular, just recently published a blog post about how he's using this specific flavor of TDD called Red-Green TDD.
- 5:13
And here, what happens is a developer-- the first thing that happens is the developer gets an incoming feature request. As soon as they get the, the request, they immediately start by writing a failing test because the feature doesn't exist.
- 5:27
After that, the developer focuses on getting the test to pass. And in this green phase, when they're trying to get the test to pass, historically, you should not be focusing on the quality of the code.
- 5:39
All you're focusing on is speed and getting the test to go green. So in the past, developers maybe would copy code from, uh, Stack Overflow and so on and get the test passing.
- 5:49
But then after that, the final phase of this is the refactor phase. And in this phase, you're just focusing on code quality. So you're taking that code that you made pass and refactoring it so that it follows all the best practices.
- 6:07
So not everyone is a fan of TDD, and like many things in this industry, TDD was pronounced dead in two thousand and fourteen. Um, and one of the most common complaints that I've seen on the internet about TDD is that it focuses too much on code coverage with unit tests and that it doesn't actually test the system.
- 6:28
So DHH, who created Rails, published this blog post in, in two thousand and fourteen and was kind of talking about this, that is an over-focus on unit tests.
- 6:39
And we know that when we over-index on code coverage, there are several issues that come up. One of the issues is that there's a tendency to test implementation details.
- 6:49
So, um, take an example like we see on the screen where we are having an order calculation with a discount. If the test is tied directly to a method like calculate, just simply renaming the name of the test, even if the functionality is still fine, is going to break those unit tests.
- 7:07
So that's not be- going to be great. But even if we test specifically, uh, the behavior of the system, like the final end result of, of the price we're looking for, um, or we test on something like a stable contract like our API or a module that doesn't change, but we export it, it should survive any refactors
- 7:27
of our internal code. I would say that if you're interested in learning more about this and behavior-driven, uh, TDD, I would recommend the talk by Ian Cooper called TDD: Where it All Went Wrong.
- 7:39
It's a very good talk. Another thing that we see is that in the age of AI, that, uh, many developers are using AI to generate tests. What they've noticed is that AI sometimes generates self-affirming tests.
- 7:56
So while the code coverage test might pass and you- your unit test suite is all green, the behavior of the system is not being validated, and that's where the problem lies.
- 8:09
So for the rest of this talk, I'm gonna be focusing on showing you how you can avoid these problems and start to test for functionality using Playwright. Playwright is an open source testing framework that's built by Microsoft, and it automates end-to-end testing in the browser by simulating user interactions.
- 8:27
And the link that you see on the screen there is, uh, is the documentation. So Playwright supports a number of different, uh, languages right now, Python, TypeScript, C#. And the example scripts that you can see on the screen is what a test would typically look like.
- 8:43
So you have that line that says "page.goto" telling the, um, the script that it starts at the toys pa- page is where we wanna start, and then we're going to look for the placeholder search, and then we're gonna fill that search bar with that, uh, let-- with the word Furby, and that will actually do-- run the search
- 9:03
for us automatically in the browser, for example. You can also use headed or headless mode, so you don't necessarily have to look at the browser while your tests are running.
- 9:13
You can actually just have them running in the background as well.
- 9:18
Um, why? Okay. So going back to that idea of TDD, when we're using Playwright with AI, it actually should speed up the full process of TDD for us. So a lot of developers in the past have really complained about how TDD is slow and that it, it's not effective for teams that want to move fast.
- 9:38
But if we have AI, then what happens is that red part and the green part are fast. So we're focusing on getting our agents to generate these behavioral tests, the Playwright tests.
- 9:51
Then we're focusing on getting the agent to quickly generate as fast as it can code that's going to make the test pass. And then I would recommend that developers are going to spend the most amount of time, so it grows bigger, on that refactoring stage.
- 10:04
So they're spending time looking at the code the agent has generated and making that code better.
- 10:12
There's a number of ways you can connect your coding agents today with Playwright. One of those ways is through the Playwright MCP server. You can use the CLI tool if you'd like that instead.
- 10:23
Or you can use something, uh, called Playwright Agents. And when you're using Playwright Agents, you'll run the command that you can see on the screen. And once you run that command, it's going to install for you, um, three agent.md files.
- 10:37
So the first one is gonna be a planner, second is a generator, and the third is a healer. So the planner will plan which tests to run, the, uh, generator's gonna actually generate the, the tests, and then the healer will fix those tests for you.
- 10:51
Okay. So I do want to show you a demo, and I am going to hope the demo gods are smiling today. Uh, so we will-- we'll give this a try.
- 11:07
Oh. Oh, no. Okay. Here we go. So I wanna give us a scenario. The scenario is that... Oh, you can't see my--
- 11:19
You are only looking at my PowerPoint right now, and I don't know how to stop that. [laughs] Uh, let me close the PowerPoint maybe and see if that will help.
- 11:32
Um.
- 11:34
What we can do is-
- 11:34
And I want to just show this screen.
- 11:37
Sorry. Hopefully, they'll give me more time. [laughs]
- 11:44
More time.
- 11:44
Okay. Perfect. That, that's working as expected. Okay. Perfect. So the scenario that we're gonna imagine today is imagine I'm a developer. I'm working at a toy company called Tailspin Toys.
- 11:55
And a few days ago, I got an email from the search product management team, and they asked me to add some new search and filter features to the site.
- 12:03
They asked me to add in a search bar with text search for simple searches and Azure AI Search for more complex ones, and they've also asked me to add in a sidebar so customers can filter by category and price.
- 12:15
So I'd like for Copilot to help me with this task and also- For us to use this, uh, TDD first style of development. So this is GitHub Copilot CLI.
- 12:27
And the first thing that we can do is we're going to try to get the agent to get the information that we saw in that email and bring in the features here into our terminal.
- 12:39
And, uh, for this, we're going to use something called Work IQ, which is Microsoft... It's a skill that Microsoft has developed that lets developers connect to the M365 suite.
- 12:50
So Outlook, PowerPoint, whatever it is you would like, and to bring that information here into the terminal. So if you're using the M365 suite for work, I can definitely recommend it.
- 13:00
And what I will also mention with TDD, in the past when we've done things like unit tests, um, typically people, what would trigger writing a unit test is adding a new method to a class.
- 13:13
But actually, in this new world, what we wanna focus on is the behavior. So we wanna focus on a feature. So if a feature request comes, that is what the trigger is for the test to be written.
- 13:25
So now we have our list of what needs to be actually developed. And I'm passing in a second, uh, I'm passing in the second prompt, and I'm asking Copilot to help me develop these features using Red-Green TDD to start by writing the Playwright tests that fail for each feature.
- 13:44
And I'm telling it not to commit the changes just for the sake of this example. And I do wanna point out that the first thing the agent is gonna do is it's going to start to examine my code base.
- 13:55
So it's gonna understand what's in my code base. I have the Playwright MCP server already installed in my CLI, uh, into Co-Copilot CLI, and it knows what it needs to do to create the tests to be able to test for these functions.
- 14:10
So the agent is gonna understand what the ca- code base is going to look, uh, look like, and then gonna write the test for it. Uh, this process is actually going to take a while, so in the meantime, I'm gonna switch over to a new tab, and I'm gonna run the command to get Playwright, the Playwright test.
- 14:30
So earlier today, I asked, uh, I got the agent to generate those failing tests, and then I got it to do the green phase, where the agent just creates the code to get the test to pass.
- 14:42
And then now I'm asking my agent to go ahead and run the Playwright test to actually test for that search bar and filter feature for us. So like I mentioned before, I have the Playwright MCP server already installed.
- 14:57
You can see it installed here. And our agent is just going to look for the test file, and if everything works correctly, it's gonna start writing some tests, running some tests.
- 15:08
So we see it's opened the correct page. It's typing in different inputs, which is testing for the search bar is working. We saw Furby was correctly found. Simon was correctly found.
- 15:18
And now it's clicking buttons, so also testing the category filter is working correctly. Again, my hands are not on the keyboard. This is all Playwright and Copilot, so super cool.
- 15:29
And now it's correctly finding all of the toys in the specific price range. So when I run these functionality tests, all I can see actively that, okay, the agent has written this code.
- 15:42
The code is working as I expected. The app is working as I expected. So there's so many different ways that you can test your app by functionality, and all of our tests pass.
- 15:52
Uh, now, once our tests have passed, that's when I would say we step into the next phase of actually going ahead and, um, and, and running out our, uh, writing our refactor, so refactoring the code the agent has created to generate these tests that pass.
- 16:09
So a final thing I will do is I will give you some best practices,
- 16:16
um, with Playwright. The first thing I would say is that when Playwright runs those functionality tests, it's going to take screenshots of all the tests that it's run. I've gotten into the practice with adding those screen- screenshots to a PR.
- 16:32
So if I've made some changes, I'll add them to a PR. The second thing is that you don't have to run it where it launches the browser like you saw in the example.
- 16:40
You can run it in headless mode so it runs in the background. And then a final thing is I would say commit your code, uh, before you actually get it to fix the test, or, you know, commit before it starts to make changes to your code.
- 16:53
Because if you don't commit, it might not remember what it, what happened in the past. So that's something to do. And then I would also say to generate one feature, one test per feature as well.
- 17:06
As a final note, these are some resources you could take a look at. Ah, I forgot to add the link to the GitHub repo. But all of these slides are gonna be available at that link there.
- 17:16
You can check out the documentation, and you can also connect with me on social media as well. So yeah. Thanks everyone. I think that's all the time I have today. [clapping]
- 17:29
I think we have two minutes for questions. Does anyone have any questions
- 17:35
about this? Yes, I see a question there.
- 17:38
Um, like, I, I use Playwright together with Storybook because you need to, like, set up to a certain state. Uh, like, how would you... Like now, this example, e-com website is quite simple and like-
- 17:49
Yeah
- 17:50
... easy to run. How would you-- What are tips for more complex apps and admin panels where you have a lot of, uh-
- 17:59
Where you have a lot of, uh-
- 18:00
State management and-
- 18:01
I mean, I think if you have a lot of state management, I would focus on maybe... I would recommend using Playwright agents where it downloads the specific agent.md file because that's going to have some specialized instructions that are better at handling state and things like that.
- 18:20
So I found that agents, um, uh, Playwright agents specifically has a lot of good instructions already built into it that should help with that. Another thing that you could do is if you didn't wanna use Playwright for everything, you could also just directly test your APIs.
- 18:35
If there's an API available, that's something you could do. Um, so yeah. That's what I would recommend. Thanks. Are there any other questions? Maybe one more question. Uh, uh, I'm not sure.
- 18:49
Yeah. [laughs]
- 18:51
Um, can Playwright also check, like, different, uh, like, sizes, like from like-
- 18:56
Mm-hmm
- 18:56
... desktop size to, like-
- 18:58
Yeah.
- 18:58
Okay. I heard that.
- 18:59
Yes. Yes. It can. It can check your d- mobile versus on desktop. It should just work. Yeah. One more. Yeah.
- 19:08
Is it only for browser-based, uh, checking? So if I'm developing a Mac app or a iPhone app.
- 19:14
It's browser-based for the moment. Yeah. For the moment, it's only browser-based. Yeah.
- 19:19
Okay. I think that is all, all the time I have for today. Thanks, everyone.
- 19:26
Thanks. [clapping]
- 19:26
Sorry about the-- no link to the GitHub. [outro music]