[{"data":1,"prerenderedAt":2585},["ShallowReactive",2],{"content:\u002Fsoftware-testing\u002Ftest-automation\u002Fstareast-2026-playwright-ai-cost-efficient-testing":3,"category:\u002Fsoftware-testing\u002Ftest-automation\u002Fstareast-2026-playwright-ai-cost-efficient-testing":6,"read-next:\u002Fsoftware-testing\u002Ftest-automation\u002Fstareast-2026-getting-started-ai-driven-automation,\u002Fsoftware-testing\u002Ftest-automation\u002Fstareast-2026-getting-dirty-ai-testing":1258},{"id":4,"title":5,"bmcUsername":6,"body":7,"cover":1248,"date":1249,"description":1250,"draft":1251,"extension":1252,"features":6,"githubRepo":6,"headline":6,"highlight":6,"icon":6,"meta":1253,"navigation":170,"npmPackage":6,"order":6,"path":1254,"seo":1255,"stem":1256,"__hash__":1257},"content\u002Fsoftware-testing\u002Ftest-automation\u002Fstareast-2026-playwright-ai-cost-efficient-testing.md","Playwright AI Testing on a Budget: Locators vs. Computer Vision — StarEast 2026",null,{"type":8,"value":9,"toc":1240},"minimark",[10,14,39,42,49,54,57,60,66,69,72,77,85,89,96,102,109,112,919,934,938,941,944,958,963,966,972,977,1011,1022,1025,1028,1050,1056,1063,1070,1075,1078,1110,1113,1118,1121,1125,1132,1137,1140,1145,1148,1153,1160,1164,1167,1172,1175,1178,1185,1188,1192,1195,1221,1229,1236],[11,12,13],"p",{},"Andy Knight's half-day StarEast 2026 tutorial, officially titled \"Top-Notch Web Testing with Playwright and AI,\" was billed as a hands-on walkthrough, and for most of its four hours, that's exactly what it was. Two claims kept it from being just another how-to for me. Playwright's MCP server can burn through an AI testing budget fast enough to matter (one joke about a junior developer's $5,000 month illustrated that point), and computer vision based testing, despite what a different StarEast tutorial argued the day before, is unlikely to replace locator-based Playwright tests anytime soon.",[11,15,16,17,22,23,28,29,33,34,38],{},"Knight, who goes by Pandy or Automation Panda depending on which corner of the testing internet you found him in, is an actual ",[18,19],"external-link",{"href":20,"text":21},"https:\u002F\u002Fautomationpanda.com","Playwright Ambassador",". His session was the third of four StarEast 2026 tutorials I attended over two days, the first two are their own write-ups, on ",[24,25,27],"a",{"href":26},"\u002Fsoftware-testing\u002Ftest-automation\u002Fstareast-2026-getting-started-ai-driven-automation","getting started with AI-driven automation and AI vision testing"," and ",[24,30,32],{"href":31},"\u002Fsoftware-testing\u002Ftest-automation\u002Fstareast-2026-getting-dirty-ai-testing","evals, vibe coding, and prompt engineering",". Knight acknowledged near the end that the class hadn't gotten through the whole tutorial repository live, \"we only got through about half of what's in the tutorial repository.\" Part of that had a funny explanation: Knight assumed most of the class had simply ignored the prerequisite machine setup instructions he'd sent out ahead of time. It turned out the StarEast organizers never actually emailed those instructions to anyone. So the room spent a chunk of class scrambling to install several hundred megabytes of Playwright's browser dependencies over the now-saturated conference Wi-Fi. The organizers only figured out what happened when they noticed the network anomaly and mentioned it to Knight, at which point I felt vindicated, I'd been ",[35,36,37],"em",{},"certain"," no such instructions were ever sent and had assumed I'd just failed to do my homework.",[11,40,41],{},"Everything below is what we actually built and discussed in the room, plus what I read in his written tutorial chapters afterward to fill in gaps.",[11,43,44],{},[45,46],"img",{"alt":47,"src":48},"Andy Knight presenting his Playwright and AI tutorial at StarEast 2026","\u002Fimages\u002Fposts\u002Fstareast-2026-playwright-ai-cost-efficient-testing\u002Fandy-knight-stareast-2026.webp",[50,51,53],"h2",{"id":52},"playwright-vs-selenium-what-actually-got-fixed","Playwright vs. Selenium: What Actually Got Fixed",[11,55,56],{},"Knight opened by asking the room what makes test automation hard, and the answers came fast: tests are slow, brittle, flaky, don't make sense when you read them back, don't make money (a real line, \"we're not shipping tests to customers\"), and force a context switch every time you flip from building a feature to testing it.",[11,58,59],{},"The classic fix for this was the Testing Pyramid, lots of cheap unit tests at the base, fewer expensive UI tests at the top, because UI tests were \"big, slow, and expensive.\" Knight's pushback wasn't that the pyramid's diagnosis was wrong. It was that the diagnosis got blamed on the wrong cause:",[61,62,63],"blockquote",{},[11,64,65],{},"\"End-to-end tests can be very valuable. Unfortunately, the Testing Pyramid labeled them as 'difficult' and 'bad' primarily due to poor practices and tool shortcomings.\"",[11,67,68],{},"He had a punchier name for what should replace pyramid-style thinking (\"we don't build pyramids anymore, we build skyscrapers\"). We'll revisit that line in a later section because I don't think it holds up quite as cleanly as it sounded in the room at the time.",[11,70,71],{},"What does hold up is the tooling argument. Playwright's actual fix for \"UI tests are slow and flaky\" is architectural: one browser instance per worker, with each test pulling its own isolated browser context out of that instance (\"akin to an incognito session, or a mini container in your browser\"), and each context holding one or more pages. Spinning up a context is nearly instant, which is the opposite of Selenium's per-test full-browser-relaunch model. Knight's own story below, about discovering this, resonated with me because I had a similar reaction when using Playwright for the first time.",[61,73,74],{},[11,75,76],{},"\"I remember the first time I used Playwright, this was back in late 2021... I quickly bang out about a dozen tests or so... I go to the terminal, I'm like npx Playwright test, run it, hit it, and then within a second it comes back and it says 12 tests passed. And I'm like, no, no, no, no, no, it didn't find the tests, it didn't run the tests, it skipped it, something went wrong... then I run it in headed mode, and it was so fast... I was expecting each test to take about a minute, because I came from Selenium, but it's like when I say it's freaky fast man, it is, it screams.\"",[11,78,79,80,84],{},"Playwright avoids the behavior that gives Selenium its flaky reputation by, among other things, polling automatically: locators and assertions keep rechecking until they succeed or time out, instead of failing the instant they're called, if misaligned. Selenium does the opposite by default, checking once, so a test that forgets to include explicit waits fails the moment the page hasn't caught up yet. Playwright's defaults give that polling a generous window: locator actions retry for 30 seconds, ",[81,82,83],"code",{},"expect"," assertions for 5, enough slack to absorb a slower page load between runs without anyone configuring a thing. Knight was fair to say, \"Selenium itself is not flaky, it's the tests that people write with it.\" Playwright's real contribution is removing a specific set of execution-speed and tooling-friction problems that made E2E testing painful for the last decade, not inventing testing concepts from scratch.",[50,86,88],{"id":87},"from-codegen-to-a-real-test","From Codegen to a Real Test",[11,90,91,92,95],{},"The hands-on portion started with ",[81,93,94],{},"npx playwright codegen"," against a local Trello-style Kanban app (a clone built by Filip Hric, used with permission). Codegen records your clicks and fills into a script, and the output is rough on purpose, Knight's framing: \"there's a difference between a script and a test case... we can use this to ruthlessly refine it into a better test case.\"",[11,97,98],{},[45,99],{"alt":100,"src":101},"Trello app being tested","\u002Fimages\u002Fposts\u002Fstareast-2026-playwright-ai-cost-efficient-testing\u002Ftrello-app-under-test-listview.webp",[11,103,104,105,108],{},"Refining it meant three things: trimming the clicks codegen over-records (you don't need to click an input before typing into it), picking stable locators (",[81,106,107],{},"data-testid"," attributes if you control the app, \"these are very nice test hooks to have\"), and adding the assertions codegen never gives you, since codegen only captures interactions, not verifications.",[11,110,111],{},"We iterated from the raw click events through refining the flow so it could be run repeatedly by adding things like pre and post test hooks to ensure the test launches in the correct state and doesn't leave behind past entries that would cause different state between runs. Here's my own rough version of that test, written live in the room.:",[113,114,120],"pre",{"className":115,"code":116,"filename":117,"language":118,"meta":119,"style":119},"language-typescript shiki shiki-themes material-theme-lighter github-light-high-contrast github-dark-high-contrast","import { test, expect } from '@playwright\u002Ftest';\n\ntest.beforeEach(async ({ page, request }) => {\n  \u002F\u002F Added this reset endpoint to erase the board and then naivate to the app at the start of each test run\n  await request.post('http:\u002F\u002Flocalhost:3000\u002Fapi\u002Freset');\n  await page.goto('http:\u002F\u002Flocalhost:3000\u002F');\n});\n\ntest.afterEach(async ({ request }) => {\n  \u002F\u002F Added this explicit reset after each test to erase the board (belt and suspenders with the beforeEach's erase)\n  await request.post('http:\u002F\u002Flocalhost:3000\u002Fapi\u002Freset');\n});\n\ntest.afterAll(async ({ browser }) => {\n  \u002F\u002F Added to close down the browser after all the tests complete\n  await browser.close();\n});\n\ntest('Create a new board with list and cards', async ({ page }) => {\n  \u002F\u002F You'll notice the selector repetition and lack of page objects which we didn't get to during the session \u002F wasn't a primary focus\n  await page.getByTestId('first-board').click();\n  await page.getByTestId('first-board').fill('chores');\n  await page.getByTestId('first-board').press('Enter');\n\n  expect(page.getByTestId('first-board')).toHaveValue('chores');\n\n  await page.getByTestId('add-list-input').click();\n  await page.getByTestId('add-list-input').fill('todo');\n  await page.getByRole('button', { name: 'Add list' }).click();\n  await page.getByTestId('new-card').click();\n  await page.getByTestId('new-card-input').fill('walk the dog');\n  await page.getByTestId('new-card-input').click();\n  await page.getByTestId('new-card-input').fill('mow the lawn');\n  await page.getByTestId('home').click();\n\n  \u002F\u002F Didn't have a chance to add more assertions, was helping classmates with setup.\n});\n","trello.spec.ts","typescript","",[81,121,122,165,172,213,220,248,273,283,288,312,318,341,350,355,380,386,403,412,417,446,452,484,523,562,567,610,615,645,683,733,763,802,831,869,899,904,910],{"__ignoreMap":119},[123,124,127,131,135,139,142,145,148,151,155,159,162],"span",{"class":125,"line":126},"line",1,[123,128,130],{"class":129},"sZTni","import",[123,132,134],{"class":133},"sPJuK"," {",[123,136,138],{"class":137},"sZ-rw"," test",[123,140,141],{"class":133},",",[123,143,144],{"class":137}," expect",[123,146,147],{"class":133}," }",[123,149,150],{"class":129}," from",[123,152,154],{"class":153},"sZi47"," '",[123,156,158],{"class":157},"srGNg","@playwright\u002Ftest",[123,160,161],{"class":153},"'",[123,163,164],{"class":133},";\n",[123,166,168],{"class":125,"line":167},2,[123,169,171],{"emptyLinePlaceholder":170},true,"\n",[123,173,175,178,181,185,188,192,195,199,201,204,207,210],{"class":125,"line":174},3,[123,176,177],{"class":137},"test",[123,179,180],{"class":133},".",[123,182,184],{"class":183},"sb1SK","beforeEach",[123,186,187],{"class":137},"(",[123,189,191],{"class":190},"stWsX","async",[123,193,194],{"class":133}," ({",[123,196,198],{"class":197},"s2xgV"," page",[123,200,141],{"class":133},[123,202,203],{"class":197}," request",[123,205,206],{"class":133}," })",[123,208,209],{"class":190}," =>",[123,211,212],{"class":133}," {\n",[123,214,216],{"class":125,"line":215},4,[123,217,219],{"class":218},"s_gjE","  \u002F\u002F Added this reset endpoint to erase the board and then naivate to the app at the start of each test run\n",[123,221,223,226,228,230,233,236,238,241,243,246],{"class":125,"line":222},5,[123,224,225],{"class":129},"  await",[123,227,203],{"class":137},[123,229,180],{"class":133},[123,231,232],{"class":183},"post",[123,234,187],{"class":235},"sq0XF",[123,237,161],{"class":153},[123,239,240],{"class":157},"http:\u002F\u002Flocalhost:3000\u002Fapi\u002Freset",[123,242,161],{"class":153},[123,244,245],{"class":235},")",[123,247,164],{"class":133},[123,249,251,253,255,257,260,262,264,267,269,271],{"class":125,"line":250},6,[123,252,225],{"class":129},[123,254,198],{"class":137},[123,256,180],{"class":133},[123,258,259],{"class":183},"goto",[123,261,187],{"class":235},[123,263,161],{"class":153},[123,265,266],{"class":157},"http:\u002F\u002Flocalhost:3000\u002F",[123,268,161],{"class":153},[123,270,245],{"class":235},[123,272,164],{"class":133},[123,274,276,279,281],{"class":125,"line":275},7,[123,277,278],{"class":133},"}",[123,280,245],{"class":137},[123,282,164],{"class":133},[123,284,286],{"class":125,"line":285},8,[123,287,171],{"emptyLinePlaceholder":170},[123,289,291,293,295,298,300,302,304,306,308,310],{"class":125,"line":290},9,[123,292,177],{"class":137},[123,294,180],{"class":133},[123,296,297],{"class":183},"afterEach",[123,299,187],{"class":137},[123,301,191],{"class":190},[123,303,194],{"class":133},[123,305,203],{"class":197},[123,307,206],{"class":133},[123,309,209],{"class":190},[123,311,212],{"class":133},[123,313,315],{"class":125,"line":314},10,[123,316,317],{"class":218},"  \u002F\u002F Added this explicit reset after each test to erase the board (belt and suspenders with the beforeEach's erase)\n",[123,319,321,323,325,327,329,331,333,335,337,339],{"class":125,"line":320},11,[123,322,225],{"class":129},[123,324,203],{"class":137},[123,326,180],{"class":133},[123,328,232],{"class":183},[123,330,187],{"class":235},[123,332,161],{"class":153},[123,334,240],{"class":157},[123,336,161],{"class":153},[123,338,245],{"class":235},[123,340,164],{"class":133},[123,342,344,346,348],{"class":125,"line":343},12,[123,345,278],{"class":133},[123,347,245],{"class":137},[123,349,164],{"class":133},[123,351,353],{"class":125,"line":352},13,[123,354,171],{"emptyLinePlaceholder":170},[123,356,358,360,362,365,367,369,371,374,376,378],{"class":125,"line":357},14,[123,359,177],{"class":137},[123,361,180],{"class":133},[123,363,364],{"class":183},"afterAll",[123,366,187],{"class":137},[123,368,191],{"class":190},[123,370,194],{"class":133},[123,372,373],{"class":197}," browser",[123,375,206],{"class":133},[123,377,209],{"class":190},[123,379,212],{"class":133},[123,381,383],{"class":125,"line":382},15,[123,384,385],{"class":218},"  \u002F\u002F Added to close down the browser after all the tests complete\n",[123,387,389,391,393,395,398,401],{"class":125,"line":388},16,[123,390,225],{"class":129},[123,392,373],{"class":137},[123,394,180],{"class":133},[123,396,397],{"class":183},"close",[123,399,400],{"class":235},"()",[123,402,164],{"class":133},[123,404,406,408,410],{"class":125,"line":405},17,[123,407,278],{"class":133},[123,409,245],{"class":137},[123,411,164],{"class":133},[123,413,415],{"class":125,"line":414},18,[123,416,171],{"emptyLinePlaceholder":170},[123,418,420,422,424,426,429,431,433,436,438,440,442,444],{"class":125,"line":419},19,[123,421,177],{"class":183},[123,423,187],{"class":137},[123,425,161],{"class":153},[123,427,428],{"class":157},"Create a new board with list and cards",[123,430,161],{"class":153},[123,432,141],{"class":133},[123,434,435],{"class":190}," async",[123,437,194],{"class":133},[123,439,198],{"class":197},[123,441,206],{"class":133},[123,443,209],{"class":190},[123,445,212],{"class":133},[123,447,449],{"class":125,"line":448},20,[123,450,451],{"class":218},"  \u002F\u002F You'll notice the selector repetition and lack of page objects which we didn't get to during the session \u002F wasn't a primary focus\n",[123,453,455,457,459,461,464,466,468,471,473,475,477,480,482],{"class":125,"line":454},21,[123,456,225],{"class":129},[123,458,198],{"class":137},[123,460,180],{"class":133},[123,462,463],{"class":183},"getByTestId",[123,465,187],{"class":235},[123,467,161],{"class":153},[123,469,470],{"class":157},"first-board",[123,472,161],{"class":153},[123,474,245],{"class":235},[123,476,180],{"class":133},[123,478,479],{"class":183},"click",[123,481,400],{"class":235},[123,483,164],{"class":133},[123,485,487,489,491,493,495,497,499,501,503,505,507,510,512,514,517,519,521],{"class":125,"line":486},22,[123,488,225],{"class":129},[123,490,198],{"class":137},[123,492,180],{"class":133},[123,494,463],{"class":183},[123,496,187],{"class":235},[123,498,161],{"class":153},[123,500,470],{"class":157},[123,502,161],{"class":153},[123,504,245],{"class":235},[123,506,180],{"class":133},[123,508,509],{"class":183},"fill",[123,511,187],{"class":235},[123,513,161],{"class":153},[123,515,516],{"class":157},"chores",[123,518,161],{"class":153},[123,520,245],{"class":235},[123,522,164],{"class":133},[123,524,526,528,530,532,534,536,538,540,542,544,546,549,551,553,556,558,560],{"class":125,"line":525},23,[123,527,225],{"class":129},[123,529,198],{"class":137},[123,531,180],{"class":133},[123,533,463],{"class":183},[123,535,187],{"class":235},[123,537,161],{"class":153},[123,539,470],{"class":157},[123,541,161],{"class":153},[123,543,245],{"class":235},[123,545,180],{"class":133},[123,547,548],{"class":183},"press",[123,550,187],{"class":235},[123,552,161],{"class":153},[123,554,555],{"class":157},"Enter",[123,557,161],{"class":153},[123,559,245],{"class":235},[123,561,164],{"class":133},[123,563,565],{"class":125,"line":564},24,[123,566,171],{"emptyLinePlaceholder":170},[123,568,570,573,575,578,580,582,584,586,588,590,593,595,598,600,602,604,606,608],{"class":125,"line":569},25,[123,571,572],{"class":183},"  expect",[123,574,187],{"class":235},[123,576,577],{"class":137},"page",[123,579,180],{"class":133},[123,581,463],{"class":183},[123,583,187],{"class":235},[123,585,161],{"class":153},[123,587,470],{"class":157},[123,589,161],{"class":153},[123,591,592],{"class":235},"))",[123,594,180],{"class":133},[123,596,597],{"class":183},"toHaveValue",[123,599,187],{"class":235},[123,601,161],{"class":153},[123,603,516],{"class":157},[123,605,161],{"class":153},[123,607,245],{"class":235},[123,609,164],{"class":133},[123,611,613],{"class":125,"line":612},26,[123,614,171],{"emptyLinePlaceholder":170},[123,616,618,620,622,624,626,628,630,633,635,637,639,641,643],{"class":125,"line":617},27,[123,619,225],{"class":129},[123,621,198],{"class":137},[123,623,180],{"class":133},[123,625,463],{"class":183},[123,627,187],{"class":235},[123,629,161],{"class":153},[123,631,632],{"class":157},"add-list-input",[123,634,161],{"class":153},[123,636,245],{"class":235},[123,638,180],{"class":133},[123,640,479],{"class":183},[123,642,400],{"class":235},[123,644,164],{"class":133},[123,646,648,650,652,654,656,658,660,662,664,666,668,670,672,674,677,679,681],{"class":125,"line":647},28,[123,649,225],{"class":129},[123,651,198],{"class":137},[123,653,180],{"class":133},[123,655,463],{"class":183},[123,657,187],{"class":235},[123,659,161],{"class":153},[123,661,632],{"class":157},[123,663,161],{"class":153},[123,665,245],{"class":235},[123,667,180],{"class":133},[123,669,509],{"class":183},[123,671,187],{"class":235},[123,673,161],{"class":153},[123,675,676],{"class":157},"todo",[123,678,161],{"class":153},[123,680,245],{"class":235},[123,682,164],{"class":133},[123,684,686,688,690,692,695,697,699,702,704,706,708,711,714,716,719,721,723,725,727,729,731],{"class":125,"line":685},29,[123,687,225],{"class":129},[123,689,198],{"class":137},[123,691,180],{"class":133},[123,693,694],{"class":183},"getByRole",[123,696,187],{"class":235},[123,698,161],{"class":153},[123,700,701],{"class":157},"button",[123,703,161],{"class":153},[123,705,141],{"class":133},[123,707,134],{"class":133},[123,709,710],{"class":235}," name",[123,712,713],{"class":133},":",[123,715,154],{"class":153},[123,717,718],{"class":157},"Add list",[123,720,161],{"class":153},[123,722,147],{"class":133},[123,724,245],{"class":235},[123,726,180],{"class":133},[123,728,479],{"class":183},[123,730,400],{"class":235},[123,732,164],{"class":133},[123,734,736,738,740,742,744,746,748,751,753,755,757,759,761],{"class":125,"line":735},30,[123,737,225],{"class":129},[123,739,198],{"class":137},[123,741,180],{"class":133},[123,743,463],{"class":183},[123,745,187],{"class":235},[123,747,161],{"class":153},[123,749,750],{"class":157},"new-card",[123,752,161],{"class":153},[123,754,245],{"class":235},[123,756,180],{"class":133},[123,758,479],{"class":183},[123,760,400],{"class":235},[123,762,164],{"class":133},[123,764,766,768,770,772,774,776,778,781,783,785,787,789,791,793,796,798,800],{"class":125,"line":765},31,[123,767,225],{"class":129},[123,769,198],{"class":137},[123,771,180],{"class":133},[123,773,463],{"class":183},[123,775,187],{"class":235},[123,777,161],{"class":153},[123,779,780],{"class":157},"new-card-input",[123,782,161],{"class":153},[123,784,245],{"class":235},[123,786,180],{"class":133},[123,788,509],{"class":183},[123,790,187],{"class":235},[123,792,161],{"class":153},[123,794,795],{"class":157},"walk the dog",[123,797,161],{"class":153},[123,799,245],{"class":235},[123,801,164],{"class":133},[123,803,805,807,809,811,813,815,817,819,821,823,825,827,829],{"class":125,"line":804},32,[123,806,225],{"class":129},[123,808,198],{"class":137},[123,810,180],{"class":133},[123,812,463],{"class":183},[123,814,187],{"class":235},[123,816,161],{"class":153},[123,818,780],{"class":157},[123,820,161],{"class":153},[123,822,245],{"class":235},[123,824,180],{"class":133},[123,826,479],{"class":183},[123,828,400],{"class":235},[123,830,164],{"class":133},[123,832,834,836,838,840,842,844,846,848,850,852,854,856,858,860,863,865,867],{"class":125,"line":833},33,[123,835,225],{"class":129},[123,837,198],{"class":137},[123,839,180],{"class":133},[123,841,463],{"class":183},[123,843,187],{"class":235},[123,845,161],{"class":153},[123,847,780],{"class":157},[123,849,161],{"class":153},[123,851,245],{"class":235},[123,853,180],{"class":133},[123,855,509],{"class":183},[123,857,187],{"class":235},[123,859,161],{"class":153},[123,861,862],{"class":157},"mow the lawn",[123,864,161],{"class":153},[123,866,245],{"class":235},[123,868,164],{"class":133},[123,870,872,874,876,878,880,882,884,887,889,891,893,895,897],{"class":125,"line":871},34,[123,873,225],{"class":129},[123,875,198],{"class":137},[123,877,180],{"class":133},[123,879,463],{"class":183},[123,881,187],{"class":235},[123,883,161],{"class":153},[123,885,886],{"class":157},"home",[123,888,161],{"class":153},[123,890,245],{"class":235},[123,892,180],{"class":133},[123,894,479],{"class":183},[123,896,400],{"class":235},[123,898,164],{"class":133},[123,900,902],{"class":125,"line":901},35,[123,903,171],{"emptyLinePlaceholder":170},[123,905,907],{"class":125,"line":906},36,[123,908,909],{"class":218},"  \u002F\u002F Didn't have a chance to add more assertions, was helping classmates with setup.\n",[123,911,913,915,917],{"class":125,"line":912},37,[123,914,278],{"class":133},[123,916,245],{"class":137},[123,918,164],{"class":133},[11,920,921,922,925,926,929,930,933],{},"Test data was the other rough edge. The app resets its entire backend through a ",[81,923,924],{},"\u002Fapi\u002Freset"," endpoint, called via Playwright's ",[81,927,928],{},"request"," fixture, and Knight was explicit that this was a deliberate, temporary shortcut: \"Remember, this is a tutorial, friends. Don't do this for real... Do not say automation panda told me to drop my whole database as test setup. No, he did not.\" The honest cost of that shortcut showed up immediately: resetting the whole database before every test means tests can't run in parallel, so the class was capped at ",[81,931,932],{},"--workers 1"," for the rest of the session. Fixing that properly (per-test data instead of a global wipe) is exactly the kind of thing that's covered in the tutorial's later, unreached chapters, more on that near the end of this article.",[50,935,937],{"id":936},"the-efficient-ai-workflow-playwright-cli-vs-mcp","The Efficient AI Workflow: Playwright CLI vs. MCP",[11,939,940],{},"Coming into this session, I'd already absorbed the soundbite that Playwright's CLI is more token-efficient than its MCP server, but nobody had explained why, and I had a more basic confusion sitting underneath that one: the CLI is just terminal commands, so in what sense is that even \"AI\"? Knight's session got me most of the way to an answer. It didn't fully click until I went and read more on my own afterward.",[11,942,943],{},"Once the manual test was working, Knight pivoted to AI, with an important framing up front: \"Playwright doesn't bring its own model, it doesn't bring its own magic. Basically what it does is it brings tooling to integrate into existing AI coding agents.\" You still need Claude, Cursor, Copilot, or Codex. Playwright gives that agent two different ways to actually drive a browser.",[11,945,946,950,951,28,954,957],{},[947,948,949],"strong",{},"MCP"," (Model Context Protocol) exposes structured tools like ",[81,952,953],{},"browser_navigate",[81,955,956],{},"browser_snapshot"," to your coding agent. It works well, and it's expensive. Knight's framing of why, in full:",[61,959,960],{},[11,961,962],{},"\"There's a problem with MCP. Does anybody know the problem with MCP? Burns a lot of tokens. It burns a heckin' ton of tokens... Intelligence is a utility. You pay a power bill, you pay a water bill. Guess what we're all paying for next? An intelligence bill.\"",[11,964,965],{},"The joke that opened this article followed directly: a junior developer who ran up a $5,000 month using MCP without understanding the cost. The mechanism, explained later in the session, isn't about which model you use, it's that MCP's tool schemas and structured page snapshots eat far more context window per step than a plain terminal command does, which forces more turns, which burns more tokens.",[11,967,968,971],{},[947,969,970],{},"Playwright's CLI"," does the same browser-driving job as MCP, as plain terminal commands instead of structured tool calls, and according to Knight, \"uses a tenth of the tokens.\" His actual decision rule, given directly in response to \"why would you ever use MCP if the CLI is so much cheaper\":",[61,973,974],{},[11,975,976],{},"\"The CLI is really good if you are doing the workflow that we are doing, for test developers, for grinding out some code, with coding agents CLI is better. But let's say that you wanted a more agentic workflow that wasn't you coding. Let's say you had to use Playwright as a browser automation tool in some way, writing a web scraper or web browser. In those cases the MCP is going to be better than the CLI. Because the MCP can be hosted on a network that you can reach out to it back and forth. CLI is all local to your machine.\"",[11,978,979,980,983,984,987,988,990,991,994,995,998,999,1002,1003,1006,1007,1010],{},"Here's the part that actually answered both of my questions, the AI-or-not question and the why-tokens question, together. Both MCP and the CLI are AI-driven, in both cases the coding agent itself is deciding what to do and reading the result back. ",[947,981,982],{},"The difference is just what vocabulary it uses to act."," MCP issues ",[947,985,986],{},"structured tool calls"," (",[81,989,953],{},", ",[81,992,993],{},"browser_click",") over a protocol built on JSON-RPC, so the call and its ",[947,996,997],{},"full response travel through the model's context every time",". The ",[947,1000,1001],{},"CLI"," has the agent run ",[947,1004,1005],{},"literal shell commands"," against itself, something like ",[81,1008,1009],{},"playwright-cli click e21",", the same way it would run any other terminal command in a coding session.",[11,1012,1013,1014,1017,1018,1021],{},"That's also where the token savings actually come from. ",[947,1015,1016],{},"MCP has to keep the page's structure resident in the session's context for as long as the agent is working with it."," The CLI's skills are markdown files sitting on disk, ",[947,1019,1020],{},"read in only when something needs them",", then left there. One holds everything it might need in memory the whole time. The other fetches what it needs and sets it back down.",[11,1023,1024],{},"That also sharpens Knight's own rule (local machine versus network-hosted) into something more concrete. The CLI needs a real terminal, a filesystem, and the ability to spawn its own processes, exactly what you have during local development, and exactly what you don't have everywhere else. MCP doesn't need any of that, which is why it's the better fit in more locked-down or remote contexts: AI-assisted CI failure triage running inside a pipeline with no terminal session attached, for instance, or a low-code product where an agent runs server-side and a non-technical user just describes a test case in plain English, with no shell ever exposed to that agent at all.",[11,1026,1027],{},"Three more habits from the session genuinely earn their place under an efficiency banner, each backed by Knight's own stated reasoning rather than just a vibe:",[1029,1030,1031,1038,1044],"ul",{},[1032,1033,1034,1037],"li",{},[947,1035,1036],{},"Skills over re-explaining."," Installing CLI skills (markdown files that teach the agent what commands exist) means you're not \"pasting huge help text into every prompt.\" It's explicitly part of why the CLI uses fewer tokens than MCP in his own comparison, skills are loaded only when needed instead of being baked into every tool call.",[1032,1039,1040,1043],{},[947,1041,1042],{},"Save state to markdown instead of letting it evaporate."," When Knight had the agent save a generated test plan to a file rather than leaving it in chat, his reasoning doubled as a genuinely good explanation of why: \"Your context window is only so big... if I didn't save my test plan in this markdown file, I'd have to make it regenerate the test plan again. That sucks.\" He compared it to saving progress in an old Super Nintendo game before your context window (or your save file) gets wiped.",[1032,1045,1046,1049],{},[947,1047,1048],{},"Inside-out test generation."," Rather than guessing a locator, running the test, watching it crash, and correcting, Playwright's CLI and MCP tooling let the agent build a session step by step, discovering real locators as it goes. \"That usually leads to very short loops, not having to repeat a lot of loops.\" It's a real efficiency argument and it's specific to how Playwright's own tooling is built, not a generic prompting tip.",[11,1051,1052,1053,1055],{},"Knight also argued that AI-assisted test generation cuts maintenance cost, since a broken locator can trigger \"a little bit of agentic maintenance... a healing loop, commit that fix back in.\" I think that may be oversold, or at least dependent on your engineering practices. Maybe this has more of an ROI on pages undergoing rapid prototyping or constant redesigns, but outside of those scenarios, I find locators remain relatively stable once they're set up in a page object model, assuming you're using ID attributes (if they aren't randomly generated) or something like ",[81,1054,107],{},". Playwright also has modern locator strategies that preclude a lot of the problems people used to get themselves into with XPath or text-based locators.",[11,1057,1058,1059,1062],{},"The live demos backed up the rest. One had the agent open the app, create a board, add a list, and invent three plausible user stories from a single plain-English prompt, no locators, no Playwright code written by hand. Another had it explore the app, propose a test plan, save that plan to a markdown file, and then generate full ",[81,1060,1061],{},"*.spec.ts"," files from it, self-healing failures as it ran, ending at 74 passed and 1 skipped. Knight's own retrospective on that second demo is worth keeping, because it's a caution about scope, not about cost: \"I would not recommend doing what I showed here, big asks. I would recommend many small asks.\" Review the output like a teammate's pull request, not like a vending machine.",[11,1064,1065,1066,1069],{},"I liked that Knight acknowledged the reality of the quality of test you get straight from AI with a prompt like this. The generated code was unoptimized and raw, similar to what the earlier codegen example created when we recorded our manual steps through the application to build a test case. You ",[35,1067,1068],{},"would not"," want to use these tests in your final test suite as-is:",[61,1071,1072],{},[11,1073,1074],{},"\"There's no page objects here. There's no real library abstraction... these names aren't great.\"",[11,1076,1077],{},"Here's the clean version of the prompt he used, taken from his tutorial notes rather than transcribed live:",[113,1079,1083],{"className":1080,"code":1081,"language":1082,"meta":119,"style":119},"language-txt shiki shiki-themes material-theme-lighter github-light-high-contrast github-dark-high-contrast","Using playwright-cli, open http:\u002F\u002Flocalhost:3000\u002F, reset data if needed via API, then walk through\nthe \"create board → add list → add cards → go home\" flow. Use snapshots to pick stable locators.\nThen add a new Playwright TypeScript test under `tests\u002F` that matches our existing style:\n`test.beforeAll` or `beforeEach` for \u002Fapi\u002Freset, clear test name, getByRole\u002FgetByPlaceholder,\nand expect assertions. Reuse patterns from our existing trello spec if present.\n","txt",[81,1084,1085,1090,1095,1100,1105],{"__ignoreMap":119},[123,1086,1087],{"class":125,"line":126},[123,1088,1089],{},"Using playwright-cli, open http:\u002F\u002Flocalhost:3000\u002F, reset data if needed via API, then walk through\n",[123,1091,1092],{"class":125,"line":167},[123,1093,1094],{},"the \"create board → add list → add cards → go home\" flow. Use snapshots to pick stable locators.\n",[123,1096,1097],{"class":125,"line":174},[123,1098,1099],{},"Then add a new Playwright TypeScript test under `tests\u002F` that matches our existing style:\n",[123,1101,1102],{"class":125,"line":215},[123,1103,1104],{},"`test.beforeAll` or `beforeEach` for \u002Fapi\u002Freset, clear test name, getByRole\u002FgetByPlaceholder,\n",[123,1106,1107],{"class":125,"line":222},[123,1108,1109],{},"and expect assertions. Reuse patterns from our existing trello spec if present.\n",[11,1111,1112],{},"With more deliberate prompt engineering, Claude could have produced a cleaner first draft. But the rawer version is what actually demonstrated the accelerated-scaffolding benefit, and it set up a natural case for why prompt engineering matters in the first place:",[61,1114,1115],{},[11,1116,1117],{},"\"If I were to do full context engineering, I would have my rules for Playwright tests, and I would say things like, use page object model.\"",[11,1119,1120],{},"Left on its own, a prompt like this gets you a fast, working first draft, not a finished one. The written version of this tutorial has a fair name for that tradeoff: \"accelerated scaffolding, not a substitute for judgment.\" Same deal as raw codegen output earlier in this piece, a working draft far faster than typing it by hand, just not something you'd commit as-is.",[50,1122,1124],{"id":1123},"why-locators-still-beat-computer-vision","Why Locators Still Beat Computer Vision",[11,1126,1127,1128,1131],{},"The day before Knight's session, Dionny Santiago's StarEast 2026 tutorial made close to the opposite argument about how AI should interact with a web page. I wrote about ",[24,1129,1130],{"href":26},"his case for AI vision testing over brittle CSS and XPath selectors"," in more detail, but the short version is direct: \"Computer vision is the evolution of the CSS selectors and the XPath selectors,\" reading a page the way a person does instead of hunting for a class name or test ID. Knight never mentioned Santiago's session, and might not have even been aware of it. An audience member raised a version of it anyway, describing tools that skip \"element work\" entirely in favor of a vision-based approach, and Knight disagreed without hesitating:",[61,1133,1134],{},[11,1135,1136],{},"\"I disagree with that. Because even with AI superpowers, image matching is still going to be expensive. Whereas locators are very cheap and quick.\"",[11,1138,1139],{},"He built a full historical case for why, the kind of argument worth quoting at length because it's the most fully-reasoned claim in the entire session. The short version: programming has only ever moved toward higher abstraction (assembly to Fortran and C to Java, Python, and TypeScript), because each higher layer let us trust the layer below it without reading it. His extension of that idea to AI:",[61,1141,1142],{},[11,1143,1144],{},"\"AI is the new compiler. Source code in TypeScript and Java and Python is the new assembly code... It will not be much longer that we still have to dance down at those levels because it's going to get so good. We still have to today because it's not as good yet.\"",[11,1146,1147],{},"Then the part that actually settles the locators-versus-vision question, mapping compiled-versus-interpreted execution onto test automation directly:",[61,1149,1150],{},[11,1151,1152],{},"\"What I showed you before with, hey, let's just explore the app with Playwright CLI and just let it go and not record anything, that was equivalent to an interpreter. That's very slow. That's token heavy. Your image matching thing when it comes to test execution is also going to be inherently slow. Always, because if you're looking at something, you have to image match in the moment... that grinding can never not be done in that kind of model. So that's why I don't think the image matching of locators is ever really going to happen.\"",[11,1154,1155,1156,1159],{},"The distinction matters for accuracy: this is about test ",[35,1157,1158],{},"execution",", how the automation decides where to click while a test runs, not about visual regression tools that diff screenshots to catch rendering bugs. Knight never argues against that second category at all. Within the category he's actually addressing, his case is the more convincing one between these two tutorials. Generating a locator-based script costs tokens once. Running it costs almost nothing, over and over. Vision-based execution pays the image-matching cost every single run, forever, no matter how good the underlying model gets. That's a structural cost difference, not a current-capability gap that better models eventually close.",[50,1161,1163],{"id":1162},"test-pyramids-skyscrapers-and-the-gap-nobody-closed","Test Pyramids, Skyscrapers, and the Gap Nobody Closed",[11,1165,1166],{},"Back to the line I deferred earlier. Here's Knight's full skyscraper pivot, verbatim:",[61,1168,1169],{},[11,1170,1171],{},"\"Today we don't build pyramids anymore. We build skyscrapers. Look up to testing skyscrapers. We need to reframe what we think of for testing in modern times because the world has changed since that previous mental model was created.\"",[11,1173,1174],{},"It's a good line, and it's worth being precise about what it actually claims. Knight never says UI tests are better than unit tests, the literal claim is narrower: \"UI tests are not bad. All tests are good because they mitigate different kinds of risks.\" That's an argument against rigid proportions, not a reordering of the hierarchy. He also never builds out the metaphor itself, there's no mapping of \"floors\" to test types anywhere in the session, the slides, or the written tutorial chapters. The skyscraper is a mood, not a blueprint.",[11,1176,1177],{},"His actual defense for ditching the pyramid's bias against UI tests is the tooling argument from earlier in this piece: Playwright's architecture fixed the execution speed and flakiness problems that gave UI tests their bad reputation. That's a real, demonstrated improvement. What it doesn't touch is the part of the pyramid's logic that was never about execution speed at all. A unit test calling a function in-process will always be faster than even the fastest browser context, that's a difference in kind, not in tooling. Unit tests also stay directly traceable to source lines and branches in a way browser-driven tests can't. Neither Playwright nor the AI tooling covered in this session does anything about that gap, and it never came up once in either half of the tutorial.",[11,1179,1180,1181,1184],{},"The AI-assisted authoring material from the previous section actually extends Knight's case further than he extended it himself, just not far enough to close that gap. If AI assistance genuinely lowers the cost of writing and maintaining E2E tests (and the token and time savings shown live back that up, even if the maintenance claim is softer), that addresses the ",[35,1182,1183],{},"other"," half of the pyramid's original justification, the cost of producing and keeping E2E tests working, which his own tooling argument never reached. So the fuller, more honest position: the case for de-emphasizing strict pyramid proportions is stronger than Knight made it sound, once you add AI-assisted authoring on top of Playwright's execution-speed fix. It's still not a full rebuttal of the pyramid, because the one gap that was never about tooling in the first place is still sitting there untouched.",[11,1186,1187],{},"Page objects, splitting one big test into independent behavior tests, and the parallel-safe test data strategy that actually fixes the \"drop the whole database\" shortcut from earlier in this piece are all covered in Knight's written tutorial chapters, just not in the room.",[50,1189,1191],{"id":1190},"my-takeaways-on-playwright-and-ai-testing","My Takeaways on Playwright and AI Testing",[11,1193,1194],{},"A few things I'm taking back with me:",[1029,1196,1197,1203,1209,1215],{},[1032,1198,1199,1202],{},[947,1200,1201],{},"Default to the CLI over MCP for routine test-development work."," Reach for MCP only when local terminal and filesystem access isn't an option in the first place, not just because it feels more capable.",[1032,1204,1205,1208],{},[947,1206,1207],{},"Treat AI-generated tests as scaffolding, not a finished product."," The first draft comes out raw, the same as old-school codegen output, so the cleanup step (page objects, naming, structure) isn't optional, it's the rest of the job.",[1032,1210,1211,1214],{},[947,1212,1213],{},"Locator-based testing wins for driving test execution, and I don't expect that to change as models improve."," The cost gap is structural, not a capability gap that better models eventually close. (Visual regression testing is a different problem, and a fair use case for vision-based tools.)",[1032,1216,1217,1220],{},[947,1218,1219],{},"Playwright and AI assistance narrow the case for the old Testing Pyramid, but they don't close it."," Knight's argument only ever answered the execution-speed half of the pyramid's old bias against UI tests; AI-assisted authoring answers some of the authoring-cost half too. Neither touches the one gap that was never about tooling: a unit test will always run faster and trace more directly to source than any browser-driven test.",[11,1222,1223,1224,1228],{},"If testing AI systems themselves (not just using AI to write tests) is more your focus right now, ",[24,1225,1227],{"href":1226},"\u002Fsoftware-testing\u002Ftest-automation\u002Fhow-to-test-ai-chatbots-and-agents","how I approached evals on a real agentic chatbot engagement"," is a related read you may find useful.",[1230,1231,1233],"read-next",{":items":1232},"[\"\u002Fsoftware-testing\u002Ftest-automation\u002Fstareast-2026-getting-started-ai-driven-automation\",\"\u002Fsoftware-testing\u002Ftest-automation\u002Fstareast-2026-getting-dirty-ai-testing\"]",[11,1234,1235],{},"::",[1237,1238,1239],"style",{},"html pre.shiki code .sZTni,html code.shiki .sZTni{--shiki-light:#39ADB5;--shiki-light-font-style:italic;--shiki-default:#A0111F;--shiki-default-font-style:inherit;--shiki-dark:#FF9492;--shiki-dark-font-style:inherit}html pre.shiki code .sPJuK,html code.shiki .sPJuK{--shiki-light:#39ADB5;--shiki-default:#0E1116;--shiki-dark:#F0F3F6}html pre.shiki code .sZ-rw,html code.shiki .sZ-rw{--shiki-light:#90A4AE;--shiki-default:#0E1116;--shiki-dark:#F0F3F6}html pre.shiki code .sZi47,html code.shiki .sZi47{--shiki-light:#39ADB5;--shiki-default:#032563;--shiki-dark:#ADDCFF}html pre.shiki code .srGNg,html code.shiki .srGNg{--shiki-light:#91B859;--shiki-default:#032563;--shiki-dark:#ADDCFF}html pre.shiki code .sb1SK,html code.shiki .sb1SK{--shiki-light:#6182B8;--shiki-default:#622CBC;--shiki-dark:#DBB7FF}html pre.shiki code .stWsX,html code.shiki .stWsX{--shiki-light:#9C3EDA;--shiki-default:#A0111F;--shiki-dark:#FF9492}html pre.shiki code .s2xgV,html code.shiki .s2xgV{--shiki-light:#90A4AE;--shiki-light-font-style:italic;--shiki-default:#702C00;--shiki-default-font-style:inherit;--shiki-dark:#FFB757;--shiki-dark-font-style:inherit}html pre.shiki code .s_gjE,html code.shiki .s_gjE{--shiki-light:#90A4AE;--shiki-light-font-style:italic;--shiki-default:#66707B;--shiki-default-font-style:inherit;--shiki-dark:#BDC4CC;--shiki-dark-font-style:inherit}html pre.shiki code .sq0XF,html code.shiki .sq0XF{--shiki-light:#E53935;--shiki-default:#0E1116;--shiki-dark:#F0F3F6}html .light .shiki span{color:var(--shiki-light);background:var(--shiki-light-bg);font-style:var(--shiki-light-font-style);font-weight:var(--shiki-light-font-weight);text-decoration:var(--shiki-light-text-decoration)}html.light .shiki span{color:var(--shiki-light);background:var(--shiki-light-bg);font-style:var(--shiki-light-font-style);font-weight:var(--shiki-light-font-weight);text-decoration:var(--shiki-light-text-decoration)}html .default .shiki span{color:var(--shiki-default);background:var(--shiki-default-bg);font-style:var(--shiki-default-font-style);font-weight:var(--shiki-default-font-weight);text-decoration:var(--shiki-default-text-decoration)}html .shiki span{color:var(--shiki-default);background:var(--shiki-default-bg);font-style:var(--shiki-default-font-style);font-weight:var(--shiki-default-font-weight);text-decoration:var(--shiki-default-text-decoration)}html .dark .shiki span{color:var(--shiki-dark);background:var(--shiki-dark-bg);font-style:var(--shiki-dark-font-style);font-weight:var(--shiki-dark-font-weight);text-decoration:var(--shiki-dark-text-decoration)}html.dark .shiki span{color:var(--shiki-dark);background:var(--shiki-dark-bg);font-style:var(--shiki-dark-font-style);font-weight:var(--shiki-dark-font-weight);text-decoration:var(--shiki-dark-text-decoration)}",{"title":119,"searchDepth":167,"depth":167,"links":1241},[1242,1243,1244,1245,1246,1247],{"id":52,"depth":167,"text":53},{"id":87,"depth":167,"text":88},{"id":936,"depth":167,"text":937},{"id":1123,"depth":167,"text":1124},{"id":1162,"depth":167,"text":1163},{"id":1190,"depth":167,"text":1191},"\u002Fimages\u002Fposts\u002Fstareast-2026-playwright-ai-cost-efficient-testing\u002Fstareast-2026-playwright-ai-cost-efficient-testing-cover.webp","2026-06-22","Playwright's MCP server can burn your AI budget fast. StarEast 2026 lessons on efficient AI testing, and why locators still beat computer vision.",false,"md",{},"\u002Fsoftware-testing\u002Ftest-automation\u002Fstareast-2026-playwright-ai-cost-efficient-testing",{"title":5,"description":1250},"software-testing\u002Ftest-automation\u002Fstareast-2026-playwright-ai-cost-efficient-testing","pwAQ4Sjft0Eb8JWmzBRpd4ye9tjqEYzV88pe1T6NPeI",[1259,1639],{"id":1260,"title":1261,"bmcUsername":6,"body":1262,"cover":1632,"date":1633,"description":1634,"draft":1251,"extension":1252,"features":6,"githubRepo":6,"headline":6,"highlight":6,"icon":6,"meta":1635,"navigation":170,"npmPackage":6,"order":6,"path":26,"seo":1636,"stem":1637,"__hash__":1638},"content\u002Fsoftware-testing\u002Ftest-automation\u002Fstareast-2026-getting-started-ai-driven-automation.md","Beyond Brittle Selectors: AI Vision Testing vs Playwright MCP — StarEast 2026",{"type":8,"value":1263,"toc":1621},[1264,1267,1270,1274,1277,1343,1346,1352,1355,1358,1372,1375,1379,1382,1385,1392,1395,1404,1408,1415,1418,1444,1447,1450,1458,1461,1467,1486,1490,1493,1500,1503,1509,1512,1515,1518,1522,1525,1528,1536,1539,1542,1550,1554,1557,1560,1563,1567,1570,1573,1576,1587,1591,1594,1597,1601,1604,1607,1618],[11,1265,1266],{},"AI test automation has been moving fast enough that keeping your bearings requires deliberate effort. I attended a full-day tutorial at StarEast 2026 on AI-driven test automation partly to validate approaches I was already using and partly to see what peers at other companies were doing in production that I might be missing. That kind of perspective is hard to get from documentation and blog posts alone. It helped that the presenter was someone I'd worked with earlier in my career; I knew going in that whatever they'd put together on this topic would be a real discussion, not a framework pitch.",[11,1268,1269],{},"The session was presented by Dionny Santiago, an Engineering Manager at Indeed and PhD candidate at Florida International University. I came away with my thinking on some things reinforced, some things reframed, and one honest disagreement: whether Playwright MCP might be the more practical starting point for most teams. One small aside worth mentioning: Santiago started his career at Ultimate Software, which is also where I spent a significant part of mine. It's a small world in QA, and that shared history made what could have been a lecture feel more like a conversation.",[50,1271,1273],{"id":1272},"why-test-quality-is-the-gap-the-dora-data","Why Test Quality Is the Gap: The DORA Data",[11,1275,1276],{},"Santiago didn't open with a product demo or a framework overview. He opened with data — specifically, the DevOps Research and Assessment (DORA) metrics, a large-scale survey of software teams across the industry that categorizes organizations into four maturity buckets: elite, high, medium, and low performers. The distribution is roughly normal, with most teams clustering in the middle and smaller tails at each end.",[1278,1279,1280,1296],"table",{},[1281,1282,1283],"thead",{},[1284,1285,1286,1290,1293],"tr",{},[1287,1288,1289],"th",{},"Metric",[1287,1291,1292],{},"Elite Performers",[1287,1294,1295],{},"Low Performers",[1297,1298,1299,1311,1322,1333],"tbody",{},[1284,1300,1301,1305,1308],{},[1302,1303,1304],"td",{},"Deployment Frequency",[1302,1306,1307],{},"On demand",[1302,1309,1310],{},"Monthly or less",[1284,1312,1313,1316,1319],{},[1302,1314,1315],{},"Lead Time for Changes",[1302,1317,1318],{},"\u003C 1 hour",[1302,1320,1321],{},"1–6 months",[1284,1323,1324,1327,1330],{},[1302,1325,1326],{},"Change Failure Rate",[1302,1328,1329],{},"\u003C 5%",[1302,1331,1332],{},"64%",[1284,1334,1335,1338,1340],{},[1302,1336,1337],{},"Mean Time to Restore",[1302,1339,1318],{},[1302,1341,1342],{},"6+ months",[11,1344,1345],{},"The counterintuitive finding — the one Santiago specifically called out — is the change failure rate. Elite teams deploy on demand, potentially hundreds of times a day, and their deployments fail less than 5% of the time. Low performers deploy monthly and fail 64% of the time. The intuitive expectation is the opposite: constant change should produce more breakage. The data says otherwise.",[11,1347,1348],{},[45,1349],{"alt":1350,"src":1351},"Dionny Santiago presenting StarEast 2026 tutorial session","\u002Fimages\u002Fposts\u002Fstareast-2026-ai-driven-automation\u002Fdionny-santiago-stareast-2026.webp",[11,1353,1354],{},"Santiago's framing points toward smaller, more frequent changes as the mechanism, but I think there's another way to read it. Teams that have the testing maturity, tooling, and processes to deploy on demand with confidence are the same teams that have low failure rates. The causality may run in the other direction from how it's often presented: it's less that frequent deployment causes lower failure rates, and more that teams mature enough to ship constantly have already solved the problems that cause failures. Teams that lack that maturity are often constrained to less frequent deployments precisely because deploying is risky for them.",[11,1356,1357],{},"Common justifications from lower-performing teams tend to sound like:",[1029,1359,1360,1363,1366,1369],{},[1032,1361,1362],{},"Regression takes too long",[1032,1364,1365],{},"We have too many manual tests",[1032,1367,1368],{},"Our automation breaks too much",[1032,1370,1371],{},"We keep missing defects",[11,1373,1374],{},"The elite performers have earned their deployment frequency by taking proactive steps to fix these issues. Either way, test quality is central to the picture.",[50,1376,1378],{"id":1377},"the-brittle-selector-problem","The Brittle Selector Problem",[11,1380,1381],{},"Santiago's case for moving beyond scripted automation started with a precise diagnosis of why it fails. Selectors are implementation details. A test that locates a button by its CSS class name or DOM attribute is asserting something about how the code is structured. When the structure changes as new features are added or the UI is updated, the test breaks even when the feature works, creating a maintenance burden and eroding confidence in the automated test suite.",[11,1383,1384],{},"Left unchecked, the cost of keeping tests passing eventually exceeds the value they provide. Teams start skipping test runs, marking failures as known issues, ignoring them, or simply deleting tests that have become too expensive to maintain. For higher-performing teams, reliable automation is a sail. For lower-performing teams running brittle suites, it becomes an expensive anchor. The maintenance problem isn't new. Santiago's proposal was to sidestep it entirely: instead of describing UI elements through markup selectors, teach an AI to see and understand the page the way a human tester would.",[11,1386,1387,1388,1391],{},"Two things from the session are worth carrying into any conversation about this. Santiago shared a quote from Rajesh Natarajan, Senior Director of Quality Engineering at Hiscox, from a recent World Quality Report: ",[35,1389,1390],{},"\"AI can do wonders for you, but not before you make yourself mature.\""," Overlaying AI on a broken testing foundation just accelerates the failure. And a fellow attendee named Emily offered the most practical advice of the day: start small, pick a specific component, iterate. Build a planner first, get that right, then move on to the next problem. One component, not an entire framework or platform migration.",[11,1393,1394],{},"In other words:",[1396,1397,1398,1401],"ol",{},[1032,1399,1400],{},"Experiment first with a small component",[1032,1402,1403],{},"Fix your foundation before adding AI on top",[50,1405,1407],{"id":1406},"ai-visual-testing-how-santiagos-team-does-it","AI Visual Testing: How Santiago's Team Does It",[11,1409,1410,1411,1414],{},"Santiago's core argument for computer vision is direct: ",[35,1412,1413],{},"\"Computer vision is the evolution of the CSS selectors and the XPath selectors.\""," A human tester (or user) doesn't know or care what class name a button has — they see a button and know what it does. A vision model can do the same thing. Instead of describing UI elements by how they're coded, you describe them by how they look. The selector problem dissolves when your automation sees the page the same way a person does.",[11,1416,1417],{},"Santiago walked through the computer vision capability hierarchy, which maps roughly to how precisely you need your model to understand the UI:",[1396,1419,1420,1426,1432,1438],{},[1032,1421,1422,1425],{},[947,1423,1424],{},"Classification"," — What is this element? (\"This is a button.\")",[1032,1427,1428,1431],{},[947,1429,1430],{},"Classification + Localization"," — What is it and where is it? (Adds a bounding box.)",[1032,1433,1434,1437],{},[947,1435,1436],{},"Object Detection"," — Multiple elements identified and located simultaneously.",[1032,1439,1440,1443],{},[947,1441,1442],{},"Instance Segmentation"," — Pixel-level identification of each individual element.",[11,1445,1446],{},"For test automation purposes, Object Detection is the practical sweet spot — you need to know what elements are present and where they are so an agent can interact with them. Full instance segmentation is more precision than the problem typically requires.",[11,1448,1449],{},"This isn't purely theoretical. Before ChatGPT and large language models, Santiago's team at TestAI used computer vision to automate BIOS testing for a major client — a case where there was no DOM, no selectors, no framework to fall back on. They ran an HDMI capture card inline to grab screenshots and built a vision model specifically for the BIOS interface. It worked. That story is worth remembering because it illustrates where computer vision isn't just a better approach — it's the only approach.",[11,1451,1452,1453,1457],{},"What makes his current research unusual is the depth behind it. His fine-tuned vision model was trained on 50,000 labeled screenshots, with the labeling work crowdsourced through approximately 70 students at FIU over time. That represents years of serious research investment, and it's what makes his model actually work rather than roughly work. He also introduced lower-barrier entry points for teams wanting to experiment: ",[18,1454],{"href":1455,"text":1456},"https:\u002F\u002Fteachablemachine.withgoogle.com\u002F","Teachable Machine"," from Google for no-code model training on your own images, Google Cloud Vision for pre-trained element identification, and Roboflow for dataset management and model training.",[11,1459,1460],{},"In the tutorial's hands-on exercise I partnered up with my coworker, Michael Brewer, to train and use Google's Teachable Machine to see how accurate it was in identifying our different faces.",[11,1462,1463],{},[45,1464],{"alt":1465,"src":1466},"Google Teachable Machine entry screen","\u002Fimages\u002Fposts\u002Fstareast-2026-ai-driven-automation\u002Fteachable-machine.webp",[1468,1469,1470,1478],"figure",{},[11,1471,1472],{},[45,1473],{"alt":1474,"src":1475,"className":1476},"David Mello and Michael Brewer using Google Teachable machine face recognition at StarEast tutorial session","\u002Fimages\u002Fposts\u002Fstareast-2026-ai-driven-automation\u002Fdavid-mello-and-michael-brewer-stareast-2026.webp",[1477],"portrait",[1479,1480,1485],"figcaption",{"className":1481},[1482,1483,1484],"text-sm","text-muted","mt-2","Here I am (left) with my coworker Michael Brewer (right) trying out the accuracy of AI image recognition in Google's Teachable Machine during the session's hands-on exercise",[50,1487,1489],{"id":1488},"the-indeed-production-story-agents-running-in-the-wild","The Indeed Production Story: Agents Running in the Wild",[11,1491,1492],{},"The section that made the session concrete was the Indeed deployment. Santiago's teams at Indeed are running approximately 50 autonomous agents in production — on their backend microservices, where his teams own the APIs and infrastructure rather than the UI. The concepts from the tutorial apply broadly, but it's worth noting the production deployment is backend-focused.",[11,1494,1495,1496,1499],{},"The agents operate in two modes. The first is familiar: they run a fixed set of scripted tests on a schedule. The second mode uses whatever compute remains after the fixed tests run. Santiago's instruction to the agents for that idle time: ",[35,1497,1498],{},"\"dream of any test cases that you can dream of — think of some crazy edge cases and run them.\""," His teams had enough fixed tests to fill about 10 minutes of a 50-minute execution window, leaving 40 minutes for autonomous exploration before reporting anything that looked significant at end of day.",[11,1501,1502],{},"Dionny's team created MCP tooling to enable the AI to perform the tasks it dreams up. So, for example, if an agent decides it wants to test creating two jobs and posting them on Indeed.com, there's an MCP tool that lets it do exactly that, posting a real job in a controlled environment.",[11,1504,1505,1506],{},"He did note you have to proceed with caution, ",[35,1507,1508],{},"\"You have to give them parameters, so they don't do things that will destroy your database.\"",[11,1510,1511],{},"There's also a separate classification agent running alongside, purpose-built for triage. When the day's report comes in, it's not a raw dump of every possible failure. Santiago's team built a classification prompt that teaches it what to flag and what to ignore, so the report surfaces only what warrants attention. That feedback loops back into the next execution via MCP. Without that filter, a report of a thousand possible issues every day is a report nobody reads.",[11,1513,1514],{},"The payoff once that foundation is in place: Santiago described it as a mindset shift away from prescriptive test cases. Once the infrastructure is set, any person can come in and tweak the prompt when agents are doing something wrong or missing something. No code change required.",[11,1516,1517],{},"When someone in the room asked about ROI, Santiago's answer was two things: the regressions you catch, and the maintenance cost you stop paying on brittle suites.",[50,1519,1521],{"id":1520},"agent-architecture-skills-context-rot-and-the-idea-im-taking-home","Agent Architecture: Skills, Context Rot, and the Idea I'm Taking Home",[11,1523,1524],{},"Of everything in the session, the agent architecture discussion is the piece I'm most confident I'll apply directly. Not someday. In work I'm doing right now.",[11,1526,1527],{},"Santiago described a four-layer model for production agents:",[113,1529,1534],{"className":1530,"code":1532,"language":1533},[1531],"language-text","┌─────────────────────────────────────────┐\n│              System Prompt              │  Core identity, constraints, persona\n├─────────────────────────────────────────┤\n│                 Skills                  │  Dynamically loaded, task-specific instructions\n├─────────────────────────────────────────┤\n│                  Tools                  │  External capabilities via MCP\n├─────────────────────────────────────────┤\n│                 Memory                  │  State persistence across interactions\n└─────────────────────────────────────────┘\n","text",[81,1535,1532],{"__ignoreMap":119},[11,1537,1538],{},"The system prompt and tools layers are familiar to anyone who has worked with LLM agents. The skills layer is the one worth dwelling on, because it addresses a problem Santiago named that I hadn't seen clearly articulated before: context rot.",[11,1540,1541],{},"Context rot is what happens as a conversation or agent session grows longer. The model's accuracy degrades as the context window fills, and the degradation is significant. Santiago described it as a curve: an agent that starts at close to full accuracy can drop to around 40% accuracy as the context window approaches its limit. Earlier instructions lose weight, the agent drifts from its original task, and decisions start contradicting earlier ones in the same session. If you've noticed an AI assistant getting noticeably worse the longer a conversation goes, that's context rot.",[11,1543,1544,1545,1549],{},"The skills pattern addresses this directly. Rather than front-loading every instruction into one large system prompt, you define skills as discrete, loadable units of instruction with short one-line descriptions. The agent reads those descriptions and decides which full skills to load based on what the current task actually requires — a login skill, a form-fill skill, a checkout skill: each authored once and composed as needed. This keeps the active context lean and ensures the most relevant instructions stay prominent. Agent skills is a specification published by Anthropic, and all the major model providers have adopted it. Santiago referenced ",[18,1546],{"href":1547,"text":1548},"https:\u002F\u002Fagentskills.io","agentskills.io"," as the spec. The pattern enables reuse across agents and is a clean structural solution to a problem that anyone building agents at scale is going to hit.",[50,1551,1553],{"id":1552},"my-honest-reaction-the-vision-gap","My Honest Reaction: The Vision Gap",[11,1555,1556],{},"Santiago's approach has real substance behind it. The reasoning is sound, the BIOS example shows cases where vision is the only viable path, and the production deployment at Indeed demonstrates that autonomous agents with real coverage are achievable today. I left genuinely impressed.",[11,1558,1559],{},"I also left thinking about barrier to entry for the UI testing use case the tutorial covered. Santiago's fine-tuned vision model works because Santiago has a PhD research program, approximately 70 students who helped label 50,000 screenshots, and years of ML expertise to build and maintain it. Those results depend on that investment. The BIOS case is a strong argument for vision — but the BIOS had no alternative. For UI testing where you do have alternatives, the question becomes whether the investment is justified given what else is available.",[11,1561,1562],{},"For most QA teams, the fine-tuning pipeline isn't available. Teachable Machine lowers the floor meaningfully, but it doesn't eliminate the need to curate training data, evaluate model performance, and manage retraining as the UI evolves. There's also an open question I kept coming back to: how does vision-based testing handle high-churn UI? If your front-end team ships frequent visual changes, how often does the model need retraining? Santiago acknowledged this — LLMs are increasingly helping automate the labeling feedback loop, which reduces the cost significantly. But it's still a real ongoing operational consideration.",[50,1564,1566],{"id":1565},"the-shovel-ready-path-playwright-mcp-and-structured-accessibility-snapshots","The Shovel-Ready Path: Playwright MCP and Structured Accessibility Snapshots",[11,1568,1569],{},"Playwright MCP, paired with an LLM, enables AI-driven testing. The difference from Santiago's approach is what the AI uses to understand the UI.",[11,1571,1572],{},"Playwright's own documentation describes it plainly: the Playwright MCP server provides browser automation capabilities through the Model Context Protocol, enabling LLMs to interact with web pages using structured accessibility snapshots. That phrase — structured accessibility snapshots — is doing the same conceptual work as Santiago's vision model. Instead of a screenshot processed by a computer vision model, you get a semantic representation of the UI that exposes what assistive technologies see: element roles, labels, states, hierarchy. An LLM can navigate and interact with a page using that snapshot the same way Santiago's agents navigate using visual understanding. No selectors. No implementation details. What's on the page, described in terms a human would recognize.",[11,1574,1575],{},"I've used Playwright MCP to create exploratory tests — the LLM navigates the application and interacts with elements using the accessibility snapshot rather than hard-coded selectors. That maps directly to Santiago's free-time autonomous exploration concept. The agent explores, builds a model of the application, interacts, and learns through semantic structure rather than pixel recognition. On one side: 50,000 labeled screenshots and a model training pipeline. On the other: a Playwright MCP server and a prompt.",[11,1577,1578,1579,1582,1583,1586],{},"However, there is a tradeoff for the simplicity of the Playwright discovered structure approach. Structured accessibility snapshots ",[35,1580,1581],{},"won't"," catch purely visual regressions — layout shifts, color errors, rendering artifacts, elements that are present in the accessibility tree but visually obscured. For that class of problem, Santiago's pixel-level approach ",[35,1584,1585],{},"is"," the right tool. The brittle selector problem, though, is fundamentally about semantic resilience, and Playwright's accessibility tree addresses that with infrastructure most teams already have.",[50,1588,1590],{"id":1589},"where-ai-vision-testing-and-playwright-mcp-converge","Where AI Vision Testing and Playwright MCP Converge",[11,1592,1593],{},"Vision-based\u002Fvisual testing and accessibility-tree-based testing are solving the same problem from different directions. Both give an automated agent a human-like understanding of the UI — one through what the page looks like, one through what the page means semantically. There's an interesting parallel in that second approach: the accessibility tree is the same representation that screen readers use to describe pages to users who are blind or have low vision. Those users navigate by what elements are and mean — roles, labels, states, hierarchy — not how they look. An AI agent using Playwright MCP is doing the same thing. As vision models get cheaper to train and fine-tune, and as LLMs continue improving at vision tasks, the investment required for the fine-tuning path will decrease. Santiago noted that labeling work that once took days now takes minutes with LLMs helping automate the feedback loop. The gap will narrow.",[11,1595,1596],{},"Santiago's work at Indeed is probably a preview of where the ecosystem is heading. The timeline is different for every team. The context rot and agent skills architecture are the pieces that apply regardless of which direction you're going — if you're building any kind of AI agent for test automation, whether UI or backend, that pattern is worth understanding and applying now.",[50,1598,1600],{"id":1599},"where-to-start","Where to Start",[11,1602,1603],{},"If you're building AI agents or working with LLM-driven test frameworks today, apply the context rot and agent skills pattern. It's tool-agnostic, it addresses a real structural problem, and it will make your agents more reliable regardless of what they're testing.",[11,1605,1606],{},"If you're dealing with brittle selectors and want a practical path forward this quarter, Playwright MCP and its structured accessibility snapshots are where I'd start. Begin with exploratory tests — let the LLM navigate using the accessibility snapshot — and build from there without any model training infrastructure.",[11,1608,1609,1610,1614,1615,1617],{},"If you have the research runway and want to invest in the longer-term vision-based path, Santiago's AGENT project at ",[18,1611],{"href":1612,"text":1613},"https:\u002F\u002Fgithub.com\u002Fdionny\u002FAGENT","github.com\u002Fdionny\u002FAGENT"," is the open source starting point, built on Claude Sonnet 4.6. ",[18,1616],{"href":1455,"text":1456}," is the lowest-barrier way to begin working with custom vision models on your own UI.",[1230,1619],{":items":1620},"[\"\u002Fsoftware-testing\u002Ftest-automation\u002Fstareast-2026-getting-dirty-ai-testing\",\"\u002Fsoftware-testing\u002Ftest-automation\u002Fhow-to-test-ai-chatbots-and-agents\"]",{"title":119,"searchDepth":167,"depth":167,"links":1622},[1623,1624,1625,1626,1627,1628,1629,1630,1631],{"id":1272,"depth":167,"text":1273},{"id":1377,"depth":167,"text":1378},{"id":1406,"depth":167,"text":1407},{"id":1488,"depth":167,"text":1489},{"id":1520,"depth":167,"text":1521},{"id":1552,"depth":167,"text":1553},{"id":1565,"depth":167,"text":1566},{"id":1589,"depth":167,"text":1590},{"id":1599,"depth":167,"text":1600},"\u002Fimages\u002Fposts\u002Fstareast-2026-ai-driven-automation\u002Fstareast-2026-ai-driven-automation-cover.webp","2026-06-13","Brittle selectors slowing your team down? My notes from StarEast 2026 on AI vision testing vs Playwright MCP — and where to start.",{},{"title":1261,"description":1634},"software-testing\u002Ftest-automation\u002Fstareast-2026-getting-started-ai-driven-automation","dZTPE05p7XqZyh4ilLp7sSRde5C4FyfUXLesiX4axc8",{"id":1640,"title":1641,"bmcUsername":6,"body":1642,"cover":2578,"date":2579,"description":2580,"draft":1251,"extension":1252,"features":6,"githubRepo":6,"headline":6,"highlight":6,"icon":6,"meta":2581,"navigation":170,"npmPackage":6,"order":6,"path":31,"seo":2582,"stem":2583,"__hash__":2584},"content\u002Fsoftware-testing\u002Ftest-automation\u002Fstareast-2026-getting-dirty-ai-testing.md","Getting Dirty with AI Testing: A StarEast 2026 Trip Report on Evals, Vibe Coding, and Prompt Engineering",{"type":8,"value":1643,"toc":2568},[1644,1656,1659,1665,1675,1681,1685,1688,1691,1694,1697,1700,1703,1708,1711,1715,1718,1721,1724,1730,1733,1736,1739,1753,1756,1759,1765,1768,1771,1777,1780,1783,1789,1801,1804,1808,1811,1814,1817,1820,1826,1829,1832,1914,1917,1920,1926,1929,1934,1937,1945,1948,1952,1955,1960,1963,1967,1970,1973,1976,1981,1984,1987,1990,1996,1999,2005,2011,2014,2018,2021,2026,2029,2032,2035,2492,2495,2498,2501,2507,2511,2514,2517,2520,2523,2526,2531,2534,2537,2540,2544,2547,2550,2553,2556,2559,2562,2565],[11,1645,1646,1647,1650,1651,1655],{},"My morning tutorial at StarEast 2026, ",[24,1648,1649],{"href":26},"Getting Started with AI-Driven Automation,"," led with DORA metrics and progressed into using AI vision to see the software under test the way a human tester would. ",[18,1652],{"href":1653,"text":1654},"https:\u002F\u002Fwww.linkedin.com\u002Fin\u002Fkevin-pyles\u002F","Kevin Pyles","'s afternoon session was something different. Within the first ten minutes, Pyles had already demonstrated an app he built with AI that morning to randomly draw playing cards for calling on attendees during the icebreaker. Before the formal content started, the point was already made.",[11,1657,1658],{},"\"There is no way I would have taken the time to do this,\" he said. \"I literally would have gotten out a piece of paper, wrote down Ace through King, and checked them off. But instead, boom, I can do this.\"",[11,1660,1661],{},[45,1662],{"alt":1663,"src":1664},"Kevin Pyles presenting his AI testing tutorial at StarEast 2026","\u002Fimages\u002Fposts\u002Fstareast-2026-getting-dirty-ai-testing\u002Fkevin-pyles-tutorial-stareast-2026.webp",[11,1666,1667,1668,1671,1672],{},"The session was titled \"Getting Dirty with Data, Bots, Agents and Code: A Hands-On Approach to AI Testing.\" Pyles was on the ACE team at FamilySearch, ",[35,1669,1670],{},"though I've read he's left the organization shortly after the conference"," (I had followed him on LinkedIn after attending his tutorial). ",[947,1673,1674],{},"By the end of the day I had built four working tools, including a vibe-coded text comparison app in full gothic style and a contact form chatbot that spoke entirely as Count Dracula.",[11,1676,1677,1678,180],{},"Most of what I learned I expected to file away as useful-when-relevant. This is my trip report from that afternoon. Two weeks later, it became immediately relevant when I was asked to ",[24,1679,1680],{"href":1226},"assist testing an agentic insurance chatbot",[50,1682,1684],{"id":1683},"llms-are-like-garbage","LLMs Are Like Garbage",[11,1686,1687],{},"Pyles opened with a simple, or perhaps not so simple, request.",[11,1689,1690],{},"\"Will you please take out the garbage?\"",[11,1692,1693],{},"Simple enough. But what garbage? Which can? Does it need to be bear-safe? Is it safe to take out at this hour?",[11,1695,1696],{},"His point: what you get back from an LLM depends entirely on the context you provide. A request that feels complete to the person making it can be profoundly ambiguous to the system receiving it, because the system has no access to the unstated assumptions you carry about your environment, your goals, or your definitions.",[11,1698,1699],{},"To illustrate this point, he ran a duck-drawing exercise with the room. Small groups received different written instructions, kept secret from other groups, and directed a teammate to draw from them. Instructions ranged from \"draw a duck with a bow tie\" to a highly specific set of constraints: oval body, 50% page height, triangular legs, no feet. I observed rather than participated in this one. Pyles then showed what Gemini produced for those same prompts. One prompt instructed a duck on \"a blank page.\" Gemini put it inside a Microsoft Word document. Another specified \"50% height.\" Gemini's duck took up closer to three-quarters. \"Is it height from the feet? Is it height from the body?\" Pyles asked. \"I don't know, but Gemini likes to hallucinate about ducks.\"",[11,1701,1702],{},"What trips the human artist trips the LLM: the gap between what an instruction says and what the person giving it assumed. The fix in both cases is making those assumptions explicit.",[61,1704,1705],{},[11,1706,1707],{},"\"These are the things that you have to provide to the LLM or you end up with a grumpy teenager. And grumpy teenagers hallucinate really well.\"",[11,1709,1710],{},"Five context categories, he said, shape every prompt: history, location, ability, quantity, and changes. Applied to \"take out the garbage\": which can, which floor, whether you can carry it, how many bags, and whether it's recycling day. Leave any of them implicit and the LLM fills them in without you.",[50,1712,1714],{"id":1713},"vague-prompts-vague-results-why-prompt-specificity-matters","Vague Prompts, Vague Results: Why Prompt Specificity Matters",[11,1716,1717],{},"Pyles opened the data module with a story pre-dating ubiquitous AI tools.",[11,1719,1720],{},"He had been on a team tasked with proving whether a company's website was getting better. Both Pyles and the CEO felt the current site was in bad shape, but Pyles was tasked with collecting real user feedback to prove it either way beyond just their opinion. Pyles collected customer feedback and ran sentiment analysis, tracking the positive-to-negative ratio over time. Pre-ChatGPT, doing this was specialized technical work. The story was context, not an AI success case, but he used this as a lead-in to our tutorial exercise.",[11,1722,1723],{},"The exercise: use generative AI to create fictitious customer feedback data for a cellular phone company. The starting prompt was intentionally bare:",[113,1725,1728],{"className":1726,"code":1727,"language":1533},[1531],"Hey ChatGPT, could you generate some feedback data, just make it up, for a website for a cellphone company?\n",[81,1729,1727],{"__ignoreMap":119},[11,1731,1732],{},"Pyles asked us: What do you notice reviewing that output? Is it useful? What's broken? What would you change?",[11,1734,1735],{},"It was interesting for me because the first pass actually looked pretty good: well-structured JSON with varied data. Others in the class got results that varied widely in format, fields, and content.",[11,1737,1738],{},"Before refining the prompt, he offered four questions to answer first:",[1029,1740,1741,1744,1747,1750],{},[1032,1742,1743],{},"Why are you building this solution?",[1032,1745,1746],{},"What problem are you trying to solve and why?",[1032,1748,1749],{},"What do you want the LLM or AI to do and why?",[1032,1751,1752],{},"What do you want the output to look like and why?",[11,1754,1755],{},"Answering these is prompt engineering in practice. The more explicit and correct a prompt is from the outset, the fewer hallucinations and rework later. They also force you to think through the problem before handing it off.",[11,1757,1758],{},"The refined prompt that followed answered all four questions:",[113,1760,1763],{"className":1761,"code":1762,"language":1533},[1531],"Hey ChatGPT, I am working on a project to analyze feedback data. You are an expert in data creation and analytics. Could you create feedback data that would be given on a cellphone company's website and include the following fields for each feedback item: ID (start at 1000 and increment), Person Name (generate random realistic first names only), Location (go with random states and real cities in the United States), Comments (include comments ranging anywhere from 5 to 100 word comments which should range anywhere from complimentary to very negative), Ratings (between 1 and 5 stars), Date (randomize the dates between April 5, 2025 and September 30, 2025), Device (Smartphone models)\n",[81,1764,1762],{"__ignoreMap":119},[11,1766,1767],{},"Coincidentally, on my machine, the vague prompt happened to already produce data that matched several of the fields the refined prompt would go on to specify.",[11,1769,1770],{},"The verbose prompt produced structured, usable data, more consistently across the class. The next step was analysis:",[113,1772,1775],{"className":1773,"code":1774,"language":1533},[1531],"Hey ChatGPT, could you analyze this feedback data and provide some insights for me?\n",[81,1776,1774],{"__ignoreMap":119},[11,1778,1779],{},"The lead-in story gave the exercise its weight. What had once been specialized technical work was reduced to a one-sentence prompt.",[11,1781,1782],{},"After, we used a prompt to build a shareable dashboard:",[113,1784,1787],{"className":1785,"code":1786,"language":1533},[1531],"Hey ChatGPT, I would like to know how much of the feedback is positive, how much is negative and how much is neutral. I would also like to provide a graph of the sentiment of feedback over time. And I would like to put all of this into an interactive web page that I could easily share with my team, so I need it to be a standalone html page with whatever additional CSS or JS files are necessary. Can you create that for me?\n",[81,1788,1786],{"__ignoreMap":119},[1468,1790,1791,1797],{},[11,1792,1793],{},[45,1794],{"alt":1795,"src":1796},"AI-generated sentiment analysis feedback dashboard from the StarEast 2026 AI testing tutorial exercise","\u002Fimages\u002Fposts\u002Fstareast-2026-getting-dirty-ai-testing\u002Ffeedback-dashboard-screenshot.webp",[1479,1798,1800],{"className":1799},[1482,1483,1484],"My version of the Customer Feedback Dashboard from class",[11,1802,1803],{},"The work Pyles described doing manually took real technical skill. The exercise produced the same output in about fifteen minutes. What the four questions changed was not the underlying work. It was the precision of what got handed to the AI.",[50,1805,1807],{"id":1806},"vibe-coding-a-goth-themed-text-compare-utility","Vibe Coding a Goth-themed Text Compare Utility",[11,1809,1810],{},"Pyles introduced the Comparinator with a question he kept asking himself: \"Wouldn't it be cool if?\"",[11,1812,1813],{},"He kept needing to compare two pieces of text. Free tools existed but none had the right combination of features. Using ChatGPT directly meant rewriting the prompt each time and dealing with hallucinations. Sending text to an online tool meant sharing potentially sensitive customer data with a third party. So he built his own, and walked the class through using vibe coding to create our own.",[11,1815,1816],{},"The workflow ran in four stages. First, conversation in plan mode rather than agent mode. In agent mode, Pyles explained, every question triggers the LLM to start building. \"If you are in agent mode, every time you ask it a question, it goes, 'Can I build it?'\" Plan mode tells the LLM to think, ask questions, and clarify requirements without touching code. In Claude Code, Shift+Tab twice toggles between them.",[11,1818,1819],{},"The starting prompt Pyles provided was long and specific:",[113,1821,1824],{"className":1822,"code":1823,"language":1533},[1531],"Hey ChatGPT, I am working on a project where I will need to compare two pieces\nof text from various scenarios. I would like to build an app that will help me\nwith this. I would like to call it Comparinator. I will need two input boxes that\nallow up to 10,000 characters. Please add a tracker so the user can see how many\ncharacters out of 10,000 have been added to each box. I would like a Compare button\nthat will then calculate the differences between the two pieces of text. I would\nlike options to ignore case and ignore punctuation on demand. I also would like a\nreset button that will clear out the input boxes and all additional fields. I would\nlike to see stats from the comparison of the texts that will show % similarity,\nword count A, word count B. Also track the accuracy % between the two input boxes.\nAlso, I would like a field that shows highlighted in red and green the words that\nare the same (green) and different (red). And for good measure, I would like a\ntoggle that will allow us to switch the theme to dark mode, while maintaining the\nglassmorphism look that we desire. Before you get started could you summarize what\nI have said, and ask any clarifying questions?\n",[81,1825,1823],{"__ignoreMap":119},[11,1827,1828],{},"That last sentence is the point. Establish intent before execution.",[11,1830,1831],{},"After the clarifying conversation, the next prompt asks the LLM to write a spec document in markdown capturing everything discussed. This becomes the grounding artifact: take it to Claude Code, Copilot, Cursor, or Gemini and run the same build. The LLM output will differ between tools, but the requirements stay stable.",[113,1833,1837],{"className":1834,"code":1835,"language":1836,"meta":119,"style":119},"language-markdown shiki shiki-themes material-theme-lighter github-light-high-contrast github-dark-high-contrast","# Comparinator – Specification Document\n\n## 1. Overview\n\nComparinator is a web-based application designed to compare two pieces of text\n(up to 10,000 characters each) and provide a clear, visual, and statistical\nbreakdown of their similarities and differences.\n\n## 2. Core Features\n\n### 2.1 Text Input\n\n- Two input fields (Text A and Text B)\n- Maximum of 10,000 characters per input\n- Live character counter for each input (e.g., 0 \u002F 10,000)\n- Visual warning when nearing character limit (turns red at 9,000+)\n","markdown",[81,1838,1839,1844,1848,1853,1857,1862,1867,1872,1876,1881,1885,1890,1894,1899,1904,1909],{"__ignoreMap":119},[123,1840,1841],{"class":125,"line":126},[123,1842,1843],{},"# Comparinator – Specification Document\n",[123,1845,1846],{"class":125,"line":167},[123,1847,171],{"emptyLinePlaceholder":170},[123,1849,1850],{"class":125,"line":174},[123,1851,1852],{},"## 1. Overview\n",[123,1854,1855],{"class":125,"line":215},[123,1856,171],{"emptyLinePlaceholder":170},[123,1858,1859],{"class":125,"line":222},[123,1860,1861],{},"Comparinator is a web-based application designed to compare two pieces of text\n",[123,1863,1864],{"class":125,"line":250},[123,1865,1866],{},"(up to 10,000 characters each) and provide a clear, visual, and statistical\n",[123,1868,1869],{"class":125,"line":275},[123,1870,1871],{},"breakdown of their similarities and differences.\n",[123,1873,1874],{"class":125,"line":285},[123,1875,171],{"emptyLinePlaceholder":170},[123,1877,1878],{"class":125,"line":290},[123,1879,1880],{},"## 2. Core Features\n",[123,1882,1883],{"class":125,"line":314},[123,1884,171],{"emptyLinePlaceholder":170},[123,1886,1887],{"class":125,"line":320},[123,1888,1889],{},"### 2.1 Text Input\n",[123,1891,1892],{"class":125,"line":343},[123,1893,171],{"emptyLinePlaceholder":170},[123,1895,1896],{"class":125,"line":352},[123,1897,1898],{},"- Two input fields (Text A and Text B)\n",[123,1900,1901],{"class":125,"line":357},[123,1902,1903],{},"- Maximum of 10,000 characters per input\n",[123,1905,1906],{"class":125,"line":382},[123,1907,1908],{},"- Live character counter for each input (e.g., 0 \u002F 10,000)\n",[123,1910,1911],{"class":125,"line":388},[123,1912,1913],{},"- Visual warning when nearing character limit (turns red at 9,000+)\n",[11,1915,1916],{},"The default design target was glassmorphism. The redesign exercise asked attendees to reskin the app in a completely different visual style. I went goth: deep purple palette, Cinzel and Crimson Text fonts, blood-red accents.",[11,1918,1919],{},"When the redesigns were in, Pyles made it official: \"You are all now vibe coders, thank you for ruining the world.\"",[11,1921,1922],{},[45,1923],{"alt":1924,"src":1925},"Comparinator Goth Edition showing word-by-word text comparison with green matching and red differing words highlighted","\u002Fimages\u002Fposts\u002Fstareast-2026-getting-dirty-ai-testing\u002Fcomparinator-compare-result-example.webp",[11,1927,1928],{},"What the redesign revealed was something more than visual non-determinism. Comparing what different attendees produced from the same base prompt, the UI variation was substantial. Pyles attributed this to context contamination: prior conversations, local configuration, and whatever the LLM infers about you from your session history all shape the output. \"Can you tell what I've been talking to my LLM about?\" he said after running his own version. \"It snags some context from somewhere else.\"",[11,1930,1931],{},[35,1932,1933],{},"*This probably explains why the first pass of the customer sentiment data, even with the vague prompt, produced familiar JSON output for me since a lot of my day-to-day usage uses similarly structured data.",[11,1935,1936],{},"For anyone trying to share prompts as repeatable artifacts across a team, that is a real problem. He proved this using the class. Everyone worked off the same prompt and got slightly different results. He emphasized you cannot think that you can use the same prompt to generate the same result deterministically even on your own computer later. Using a spec doc to build from requirements is a safer approach versus a saved prompt string because the same prompt run in a different context will not reliably produce the same result.",[11,1938,1939,1940,1944],{},"At work we are starting to use ",[18,1941],{"href":1942,"text":1943},"https:\u002F\u002Fopenspec.dev\u002F","OpenSpec"," partly to address this among other reasons.",[11,1946,1947],{},"He also mentioned a good practice, something I already use but was glad to have validated: \"Ask the LLM for what is missing or [for] additional ideas.\" When writing a large spec doc or prompt I will tend to end with something like, \"Let me know if anything was unclear or if you have any suggestions before proceeding.\"",[50,1949,1951],{"id":1950},"the-ai-8020-rule-is-a-feature-not-a-bug","The AI 80\u002F20 Rule Is a Feature, Not a Bug",[11,1953,1954],{},"Pyles also touched on what he called the 80\u002F20 rule: even as AI improves, the work still tends to split roughly 80% AI and 20% human.",[61,1956,1957],{},[11,1958,1959],{},"\"If you think that the AI is going to do 100% and it only does 80%, you're really disappointed. It might do 100% of the typing. And then you have to do 20% of the thinking. It will do 100% of the code, but then you have to do 100% of the testing. And somehow that works out to 80-20. It's a magical bug [how the proportion tends to land there].\"",[11,1961,1962],{},"The point was about expectations going in. If you know the 20% is always there, you will not be disappointed when it shows up. What changes as models improve is the form it takes: answering the questions the LLM asks, testing what it produces, refining a prompt that got close but not right. The proportion stays consistent even when the shape does not.",[50,1964,1966],{"id":1965},"chatbots-stop-ai-agents-find-a-way","Chatbots Stop, AI Agents Find a Way",[11,1968,1969],{},"Pyles opened the agents section with a quote he said he had posted on LinkedIn, paraphrased from someone at Anthropic — he couldn't recall exactly who: \"Chatbots stop. AI agents find a way.\"",[11,1971,1972],{},"The distinction he drew was behavioral. A chatbot hits a dead end when no response pattern matches. An agent finds another path. \"It doesn't just respond with whatever it was told to respond to. It can actually go out and do something because of what's been requested or triggered.\"",[11,1974,1975],{},"He showed a seven-level spectrum of chatbot autonomy, from a deterministic contact-us form on one end to a fully autonomous agent with no human required on the other. The testing implication scales with the level. A contact form is 100% deterministic and fully automatable. A fully autonomous agent can take real-world actions that a fixed response set cannot anticipate or constrain.",[61,1977,1978],{},[11,1979,1980],{},"\"I don't know what level is my chatbot or my agent. And that will determine how much effort I really need to put into it.\"",[11,1982,1983],{},"To make this concrete, Pyles first demonstrated Parrot Pete, a pirate-speaking chatbot from his own GitHub repository, showing what an on-page embedded chatbot looks and feels like before attendees built their own. The exercise: build a contact-info-gathering chatbot, embed it in the Comparinator site, and prepare it for AI chatbot testing in the following module.",[11,1985,1986],{},"I was already building in goth. My prompt to the LLM was roughly: build a contact form chatbot as Count Dracula, collecting visitor details so he can come find them.",[11,1988,1989],{},"One sentence of premise. The LLM extrapolated the rest: Shakespearean register, a \"Book of Souls,\" escalating Gothic menace at every step of the form. The greeting:",[113,1991,1994],{"className":1992,"code":1993,"language":1533},[1531],"Ahhh… a visitor crosses my threshold. How delightfully bold. I am Count Dracula,\nlord of these ancient halls. And you, dear mortal… what name shall I inscribe\nin my Book of Souls?\n",[81,1995,1993],{"__ignoreMap":119},[11,1997,1998],{},"The confirmation on submit:",[113,2000,2003],{"className":2001,"code":2002,"language":1533},[1531],"Mwahahaha… it is done. Your details are mine. Sleep well tonight, dear mortal\n— though perhaps not too well. I shall be calling upon you… very soon. 🦇\n",[81,2004,2002],{"__ignoreMap":119},[11,2006,2007],{},[45,2008],{"alt":2009,"src":2010},"Count Dracula AI chatbot contact form embedded as a floating widget in the Comparinator Goth Edition","\u002Fimages\u002Fposts\u002Fstareast-2026-getting-dirty-ai-testing\u002Fdracula-chat-widget.webp",[11,2012,2013],{},"The persona prompt is a simple tool with a larger lesson inside it: giving the LLM a clear character with a clear motivation produces coherent, consistent output across the entire interaction. The character did not need to be specified line by line. The premise was enough.",[50,2015,2017],{"id":2016},"evals-are-just-regression-suites","Evals Are Just Regression Suites",[11,2019,2020],{},"The testing section of the session produced the sharpest reframe of the day.",[61,2022,2023],{},[11,2024,2025],{},"\"What is an eval? It is a regression suite, codename, because developers didn't like testers so they came up with a different name.\"",[11,2027,2028],{},"When you hear that a model \"scored X on this eval,\" Pyles explained, it means a standardized regression suite focused on a particular domain: medical knowledge, code generation, safety. Each test case is a prompt plus an expected result, the same structure testers have used for decades.",[11,2030,2031],{},"For reference on format, he pointed to DeepEval, a publicly available eval framework on GitHub. His recommended approach for generating an eval: share your spec document with the LLM, apply a testing persona (\"you are an expert in testing chatbots and LLMs\"), and ask it to build the eval suite.",[11,2033,2034],{},"The eval generated for the Dracula chatbot during the exercise covered more ground than I would have mapped out in the same time. State machine transitions across all seven conversation states, validation edge cases for email and phone formats, session isolation confirming separate users did not share state. The test data used Jonathan Harker at 1 Transylvania Lane. The theme held all the way to the assertions.",[113,2036,2040],{"className":2037,"code":2038,"language":2039,"meta":119,"style":119},"language-javascript shiki shiki-themes material-theme-lighter github-light-high-contrast github-dark-high-contrast","describe('processMessage — full happy path', () => {\n  test('walks all states in order and contactSaved only on final confirm', () => {\n    const session = newSession();\n\n    let result = processMessage(session, 'Jonathan Harker');\n    expect(session.state).toBe(STATES.GET_EMAIL);\n    expect(result.contactSaved).toBe(false);\n\n    result = processMessage(session, 'jonathan@castle.com');\n    expect(session.state).toBe(STATES.GET_PHONE);\n\n    result = processMessage(session, '555-867-5309');\n    expect(session.state).toBe(STATES.GET_ADDRESS);\n\n    result = processMessage(session, '1 Transylvania Lane, Bistritz');\n    expect(session.state).toBe(STATES.CONFIRM);\n\n    result = processMessage(session, 'yes');\n    expect(session.state).toBe(STATES.DONE);\n    expect(result.contactSaved).toBe(true);\n  });\n});\n","javascript",[81,2041,2042,2065,2087,2107,2111,2142,2177,2207,2211,2237,2268,2272,2297,2328,2332,2357,2388,2392,2417,2448,2475,2484],{"__ignoreMap":119},[123,2043,2044,2047,2049,2051,2054,2056,2058,2061,2063],{"class":125,"line":126},[123,2045,2046],{"class":183},"describe",[123,2048,187],{"class":137},[123,2050,161],{"class":153},[123,2052,2053],{"class":157},"processMessage — full happy path",[123,2055,161],{"class":153},[123,2057,141],{"class":133},[123,2059,2060],{"class":133}," ()",[123,2062,209],{"class":190},[123,2064,212],{"class":133},[123,2066,2067,2070,2072,2074,2077,2079,2081,2083,2085],{"class":125,"line":167},[123,2068,2069],{"class":183},"  test",[123,2071,187],{"class":235},[123,2073,161],{"class":153},[123,2075,2076],{"class":157},"walks all states in order and contactSaved only on final confirm",[123,2078,161],{"class":153},[123,2080,141],{"class":133},[123,2082,2060],{"class":133},[123,2084,209],{"class":190},[123,2086,212],{"class":133},[123,2088,2089,2092,2096,2100,2103,2105],{"class":125,"line":174},[123,2090,2091],{"class":190},"    const",[123,2093,2095],{"class":2094},"sQ79N"," session",[123,2097,2099],{"class":2098},"sE6rD"," =",[123,2101,2102],{"class":183}," newSession",[123,2104,400],{"class":235},[123,2106,164],{"class":133},[123,2108,2109],{"class":125,"line":215},[123,2110,171],{"emptyLinePlaceholder":170},[123,2112,2113,2116,2119,2121,2124,2126,2129,2131,2133,2136,2138,2140],{"class":125,"line":222},[123,2114,2115],{"class":190},"    let",[123,2117,2118],{"class":137}," result",[123,2120,2099],{"class":2098},[123,2122,2123],{"class":183}," processMessage",[123,2125,187],{"class":235},[123,2127,2128],{"class":137},"session",[123,2130,141],{"class":133},[123,2132,154],{"class":153},[123,2134,2135],{"class":157},"Jonathan Harker",[123,2137,161],{"class":153},[123,2139,245],{"class":235},[123,2141,164],{"class":133},[123,2143,2144,2147,2149,2151,2153,2156,2158,2160,2163,2165,2168,2170,2173,2175],{"class":125,"line":250},[123,2145,2146],{"class":183},"    expect",[123,2148,187],{"class":235},[123,2150,2128],{"class":137},[123,2152,180],{"class":133},[123,2154,2155],{"class":137},"state",[123,2157,245],{"class":235},[123,2159,180],{"class":133},[123,2161,2162],{"class":183},"toBe",[123,2164,187],{"class":235},[123,2166,2167],{"class":2094},"STATES",[123,2169,180],{"class":133},[123,2171,2172],{"class":2094},"GET_EMAIL",[123,2174,245],{"class":235},[123,2176,164],{"class":133},[123,2178,2179,2181,2183,2186,2188,2191,2193,2195,2197,2199,2203,2205],{"class":125,"line":275},[123,2180,2146],{"class":183},[123,2182,187],{"class":235},[123,2184,2185],{"class":137},"result",[123,2187,180],{"class":133},[123,2189,2190],{"class":137},"contactSaved",[123,2192,245],{"class":235},[123,2194,180],{"class":133},[123,2196,2162],{"class":183},[123,2198,187],{"class":235},[123,2200,2202],{"class":2201},"sTqCK","false",[123,2204,245],{"class":235},[123,2206,164],{"class":133},[123,2208,2209],{"class":125,"line":285},[123,2210,171],{"emptyLinePlaceholder":170},[123,2212,2213,2216,2218,2220,2222,2224,2226,2228,2231,2233,2235],{"class":125,"line":290},[123,2214,2215],{"class":137},"    result",[123,2217,2099],{"class":2098},[123,2219,2123],{"class":183},[123,2221,187],{"class":235},[123,2223,2128],{"class":137},[123,2225,141],{"class":133},[123,2227,154],{"class":153},[123,2229,2230],{"class":157},"jonathan@castle.com",[123,2232,161],{"class":153},[123,2234,245],{"class":235},[123,2236,164],{"class":133},[123,2238,2239,2241,2243,2245,2247,2249,2251,2253,2255,2257,2259,2261,2264,2266],{"class":125,"line":314},[123,2240,2146],{"class":183},[123,2242,187],{"class":235},[123,2244,2128],{"class":137},[123,2246,180],{"class":133},[123,2248,2155],{"class":137},[123,2250,245],{"class":235},[123,2252,180],{"class":133},[123,2254,2162],{"class":183},[123,2256,187],{"class":235},[123,2258,2167],{"class":2094},[123,2260,180],{"class":133},[123,2262,2263],{"class":2094},"GET_PHONE",[123,2265,245],{"class":235},[123,2267,164],{"class":133},[123,2269,2270],{"class":125,"line":320},[123,2271,171],{"emptyLinePlaceholder":170},[123,2273,2274,2276,2278,2280,2282,2284,2286,2288,2291,2293,2295],{"class":125,"line":343},[123,2275,2215],{"class":137},[123,2277,2099],{"class":2098},[123,2279,2123],{"class":183},[123,2281,187],{"class":235},[123,2283,2128],{"class":137},[123,2285,141],{"class":133},[123,2287,154],{"class":153},[123,2289,2290],{"class":157},"555-867-5309",[123,2292,161],{"class":153},[123,2294,245],{"class":235},[123,2296,164],{"class":133},[123,2298,2299,2301,2303,2305,2307,2309,2311,2313,2315,2317,2319,2321,2324,2326],{"class":125,"line":352},[123,2300,2146],{"class":183},[123,2302,187],{"class":235},[123,2304,2128],{"class":137},[123,2306,180],{"class":133},[123,2308,2155],{"class":137},[123,2310,245],{"class":235},[123,2312,180],{"class":133},[123,2314,2162],{"class":183},[123,2316,187],{"class":235},[123,2318,2167],{"class":2094},[123,2320,180],{"class":133},[123,2322,2323],{"class":2094},"GET_ADDRESS",[123,2325,245],{"class":235},[123,2327,164],{"class":133},[123,2329,2330],{"class":125,"line":357},[123,2331,171],{"emptyLinePlaceholder":170},[123,2333,2334,2336,2338,2340,2342,2344,2346,2348,2351,2353,2355],{"class":125,"line":382},[123,2335,2215],{"class":137},[123,2337,2099],{"class":2098},[123,2339,2123],{"class":183},[123,2341,187],{"class":235},[123,2343,2128],{"class":137},[123,2345,141],{"class":133},[123,2347,154],{"class":153},[123,2349,2350],{"class":157},"1 Transylvania Lane, Bistritz",[123,2352,161],{"class":153},[123,2354,245],{"class":235},[123,2356,164],{"class":133},[123,2358,2359,2361,2363,2365,2367,2369,2371,2373,2375,2377,2379,2381,2384,2386],{"class":125,"line":388},[123,2360,2146],{"class":183},[123,2362,187],{"class":235},[123,2364,2128],{"class":137},[123,2366,180],{"class":133},[123,2368,2155],{"class":137},[123,2370,245],{"class":235},[123,2372,180],{"class":133},[123,2374,2162],{"class":183},[123,2376,187],{"class":235},[123,2378,2167],{"class":2094},[123,2380,180],{"class":133},[123,2382,2383],{"class":2094},"CONFIRM",[123,2385,245],{"class":235},[123,2387,164],{"class":133},[123,2389,2390],{"class":125,"line":405},[123,2391,171],{"emptyLinePlaceholder":170},[123,2393,2394,2396,2398,2400,2402,2404,2406,2408,2411,2413,2415],{"class":125,"line":414},[123,2395,2215],{"class":137},[123,2397,2099],{"class":2098},[123,2399,2123],{"class":183},[123,2401,187],{"class":235},[123,2403,2128],{"class":137},[123,2405,141],{"class":133},[123,2407,154],{"class":153},[123,2409,2410],{"class":157},"yes",[123,2412,161],{"class":153},[123,2414,245],{"class":235},[123,2416,164],{"class":133},[123,2418,2419,2421,2423,2425,2427,2429,2431,2433,2435,2437,2439,2441,2444,2446],{"class":125,"line":419},[123,2420,2146],{"class":183},[123,2422,187],{"class":235},[123,2424,2128],{"class":137},[123,2426,180],{"class":133},[123,2428,2155],{"class":137},[123,2430,245],{"class":235},[123,2432,180],{"class":133},[123,2434,2162],{"class":183},[123,2436,187],{"class":235},[123,2438,2167],{"class":2094},[123,2440,180],{"class":133},[123,2442,2443],{"class":2094},"DONE",[123,2445,245],{"class":235},[123,2447,164],{"class":133},[123,2449,2450,2452,2454,2456,2458,2460,2462,2464,2466,2468,2471,2473],{"class":125,"line":448},[123,2451,2146],{"class":183},[123,2453,187],{"class":235},[123,2455,2185],{"class":137},[123,2457,180],{"class":133},[123,2459,2190],{"class":137},[123,2461,245],{"class":235},[123,2463,180],{"class":133},[123,2465,2162],{"class":183},[123,2467,187],{"class":235},[123,2469,2470],{"class":2201},"true",[123,2472,245],{"class":235},[123,2474,164],{"class":133},[123,2476,2477,2480,2482],{"class":125,"line":454},[123,2478,2479],{"class":133},"  }",[123,2481,245],{"class":235},[123,2483,164],{"class":133},[123,2485,2486,2488,2490],{"class":125,"line":486},[123,2487,278],{"class":133},[123,2489,245],{"class":137},[123,2491,164],{"class":133},[11,2493,2494],{},"One boundary Pyles was explicit about: \"It's not testing security, internationalization, localization, probably not even usability. All it's testing is inputs and outputs, which is good for inputs and outputs. It's awful if you wanted to run on a mobile device.\"",[11,2496,2497],{},"That matters. Evals handle response correctness at scale. The broader test strategy still requires a tester to think about what evals do not reach.",[11,2499,2500],{},"His closing instruction for this section: \"Show your work through your dashboards and evals and results. Don't let it disappear into spent tokens.\"",[11,2502,2503,2504,180],{},"Two weeks after the conference, a team came in with a request to build a test suite for an AI chatbot they had built internally. The eval framing from this session transferred directly. Understanding what an eval is structurally meant not starting from scratch. The tooling was different and the assertion layer required an LLM judge rather than an exact-match comparator, but the test design thinking was the same. The full story of that engagement is in ",[24,2505,2506],{"href":1226},"How to Test AI Chatbots and Agents: A Real-World QA Engagement",[50,2508,2510],{"id":2509},"ai-document-transcription","AI Document Transcription",[11,2512,2513],{},"The final module used Pyles's real work at FamilySearch as its foundation. His team's job was converting historical genealogy documents to structured, searchable data, around 1.7 billion of them across multiple languages, handwriting styles, and centuries. The testing challenge at that scale: when no human can read the original document, how do you verify the AI transcribed it correctly?",[11,2515,2516],{},"The hands-on exercise gave attendees a series of progressively harder document images to transcribe, starting with a fictional driver's license and moving through gravestones, 17th-century Dutch records, and 18th-century Brazilian marriage records.",[11,2518,2519],{},"The base prompt was intentionally underspecified: \"Hey ChatGPT, could you transcribe all the text in this image for me?\"",[11,2521,2522],{},"For most documents, it held up. The Brazilian marriage record was where it broke. The LLM returned Dutch or German text and offered to normalize the spelling into modern Dutch. The document was written in Portuguese.",[11,2524,2525],{},"The revised prompt:",[61,2527,2528],{},[11,2529,2530],{},"\"Hey ChatGPT, you are an expert in transcription of old Brazilian marriage documents. I have a document that is handwritten in Portuguese, and I need help transcribing it. It is a marriage record. I believe it is from the 1740s. Please take your time in understanding the content of the record and verifying the letters and words. There are some signatures in the document as well, and we would like to get as much of that as possible.\"",[11,2532,2533],{},"The output improved dramatically: correct language, correct characters, signatures identified with Portuguese names. The foreign language documents were the hardest in the exercise, and that before\u002Fafter showed more clearly than anything else in the session what the difference between an underspecified and a well-contextualized prompt actually produces.",[11,2535,2536],{},"The garbage metaphor from the morning came full circle. The LLM has access only to what you provide. A transcription request without language, document type, era, and handling instructions is as ambiguous as \"take out the garbage\" without knowing where the cans are.",[11,2538,2539],{},"Pyles's summary: \"You are just like the LLM.\" When you are tired from going down a hallucination rabbit hole, your prompts degrade in quality the same way LLM outputs do. The fix for both is to clear context, take a break, and restart with a complete setup rather than trying to correct from inside a broken session.",[50,2541,2543],{"id":2542},"what-i-took-from-it","What I Took From It",[11,2545,2546],{},"Going in, I expected to file most of this away for later. The team I work with was using AI to co-author code and tests, but testing an AI system directly was not on the near-term roadmap. Two weeks later, that changed without warning.",[11,2548,2549],{},"The concept that transferred most directly was evals as regression suites. The framing cut through the jargon immediately. Knowing what an eval is structurally meant the new ask had a recognizable shape even though the tooling was unfamiliar.",[11,2551,2552],{},"The other thing that stayed with me came from the Comparinator redesign: the same prompt produced notably different UIs on different attendees' machines. Pyles framed it as context contamination from prior LLM sessions. For anyone building shared prompt libraries or trying to replicate AI-generated outputs across a team, that is not a minor nuance. The spec document is the more portable artifact, and the more durable one.",[11,2554,2555],{},"The third thing came from the opening. Pyles built that card-draw app the morning before the session because \"wouldn't it be cool if\" now has a cheap enough answer to be worth asking. Before AI, the thought would have stayed a thought.",[11,2557,2558],{},"That pattern shows up in my own work daily. Ideas that previously had no realistic path from concept to working prototype — small tools, automations, experiments worth trying but not worth a full development sprint — now have one. The 20% is still real: the directing, the refining, deciding what's actually worth building. But the gap between \"wouldn't it be cool if\" and a working version has closed enough that asking the question has become a habit worth keeping.",[11,2560,2561],{},"The session was four hours and four working tools. All of them ran. Most of what it covered showed up in practical use faster than I expected.",[1230,2563],{":items":2564},"[\"\u002Fsoftware-testing\u002Ftest-automation\u002Fhow-to-test-ai-chatbots-and-agents\",\"\u002Fsoftware-testing\u002Ftest-automation\u002Fstareast-2026-getting-started-ai-driven-automation\"]",[1237,2566,2567],{},"html .light .shiki span{color:var(--shiki-light);background:var(--shiki-light-bg);font-style:var(--shiki-light-font-style);font-weight:var(--shiki-light-font-weight);text-decoration:var(--shiki-light-text-decoration)}html.light .shiki span{color:var(--shiki-light);background:var(--shiki-light-bg);font-style:var(--shiki-light-font-style);font-weight:var(--shiki-light-font-weight);text-decoration:var(--shiki-light-text-decoration)}html .default .shiki span{color:var(--shiki-default);background:var(--shiki-default-bg);font-style:var(--shiki-default-font-style);font-weight:var(--shiki-default-font-weight);text-decoration:var(--shiki-default-text-decoration)}html .shiki span{color:var(--shiki-default);background:var(--shiki-default-bg);font-style:var(--shiki-default-font-style);font-weight:var(--shiki-default-font-weight);text-decoration:var(--shiki-default-text-decoration)}html .dark .shiki span{color:var(--shiki-dark);background:var(--shiki-dark-bg);font-style:var(--shiki-dark-font-style);font-weight:var(--shiki-dark-font-weight);text-decoration:var(--shiki-dark-text-decoration)}html.dark .shiki span{color:var(--shiki-dark);background:var(--shiki-dark-bg);font-style:var(--shiki-dark-font-style);font-weight:var(--shiki-dark-font-weight);text-decoration:var(--shiki-dark-text-decoration)}html pre.shiki code .sb1SK,html code.shiki .sb1SK{--shiki-light:#6182B8;--shiki-default:#622CBC;--shiki-dark:#DBB7FF}html pre.shiki code .sZ-rw,html code.shiki .sZ-rw{--shiki-light:#90A4AE;--shiki-default:#0E1116;--shiki-dark:#F0F3F6}html pre.shiki code .sZi47,html code.shiki .sZi47{--shiki-light:#39ADB5;--shiki-default:#032563;--shiki-dark:#ADDCFF}html pre.shiki code .srGNg,html code.shiki .srGNg{--shiki-light:#91B859;--shiki-default:#032563;--shiki-dark:#ADDCFF}html pre.shiki code .sPJuK,html code.shiki .sPJuK{--shiki-light:#39ADB5;--shiki-default:#0E1116;--shiki-dark:#F0F3F6}html pre.shiki code .stWsX,html code.shiki .stWsX{--shiki-light:#9C3EDA;--shiki-default:#A0111F;--shiki-dark:#FF9492}html pre.shiki code .sq0XF,html code.shiki .sq0XF{--shiki-light:#E53935;--shiki-default:#0E1116;--shiki-dark:#F0F3F6}html pre.shiki code .sQ79N,html code.shiki .sQ79N{--shiki-light:#90A4AE;--shiki-default:#023B95;--shiki-dark:#91CBFF}html pre.shiki code .sE6rD,html code.shiki .sE6rD{--shiki-light:#39ADB5;--shiki-default:#A0111F;--shiki-dark:#FF9492}html pre.shiki code .sTqCK,html code.shiki .sTqCK{--shiki-light:#FF5370;--shiki-default:#023B95;--shiki-dark:#91CBFF}",{"title":119,"searchDepth":167,"depth":167,"links":2569},[2570,2571,2572,2573,2574,2575,2576,2577],{"id":1683,"depth":167,"text":1684},{"id":1713,"depth":167,"text":1714},{"id":1806,"depth":167,"text":1807},{"id":1950,"depth":167,"text":1951},{"id":1965,"depth":167,"text":1966},{"id":2016,"depth":167,"text":2017},{"id":2509,"depth":167,"text":2510},{"id":2542,"depth":167,"text":2543},"\u002Fimages\u002Fposts\u002Fstareast-2026-getting-dirty-ai-testing\u002Fgetting-dirty-with-ai-testing-cover.webp","2026-06-14","StarEast 2026 trip report: what a hands-on AI testing tutorial taught me about prompt engineering, evals, and building an AI chatbot as Count Dracula.",{},{"title":1641,"description":2580},"software-testing\u002Ftest-automation\u002Fstareast-2026-getting-dirty-ai-testing","19da0yeyrR1T66jW6PjG-zUTHIZX_XTGNe5GzzGxdtc",1782151301196]