Developer Showdown: Vibe Coder vs Senior Developer  🔗 **Source:** [Developer Showdown: Vibe Coder vs Senior Developer](https://www.youtube.com/watch?v=7ZWB79HRRUw) > [!note]+ Document Notes > tags: [vibe-coding, ai-coding-agents, developer-productivity, css-animation, ui-fidelity] > author: Wes Bos, CJ Reynolds & Randy (Syntax) > source: Syntax (YouTube) > reference: https://www.youtube.com/watch?v=7ZWB79HRRUw > date created: 2026-09-25 08:50 > > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > # 🏷️ Title: Developer Showdown: Vibe Coder vs Senior Developer > <!-- deep-read:sections start --> ## 🧭 Table of contents - [📝 Summary](#-summary) - [📖 Main content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning styles assessment](#-learning-styles-assessment) - [📊 Accessibility assessment](#-accessibility-assessment) - [🌍 DEIB assessment](#-deib-assessment) - [✅ Logical validity](#-logical-validity) - [🛡️ DARVO analysis](#️-darvo-analysis) - [🎯 Conclusion](#-conclusion) - [🔄 Refactor appendix](#-refactor-appendix--developer-showdown-vibe-coder-vs-senior-developer) ## 📝 Summary - **What happened.** Syntax published a 27:17 timed build race on 2026-09-25. CJ Reynolds hosts and scores. Wes Bos (senior web developer, allowed any tool including AI) and Randy (Syntax's video producer, self-described vibe coder with no hand-coding background) each get 20 minutes to recreate Raul Dronca's Pixel Ripple Button from an X post, then 5 more minutes to publish a public URL. The auto-transcript renders Randy's surname as "Recctor" (the description's handle is @randyrektor) and the designer as "Raul Drunka" (description: Raul Dronca). - **The tools.** Randy uses Claude Desktop with dictation, on the model the transcript calls "Fable" and later "Fable 5.1" (00:03:34, 00:26:42), pointed at a starter repo, and asks it to open the result in Chrome with hot reload. Wes uses the Claude CLI (transcript: "cloud CLI") for generation plus hand-written CSS in his editor, with a color picker for the palette. Both dictate their prompts. Both start from the same starter template: an HTML file, a base CSS file, and a link to the original X post (00:02:09). - **The claim.** The title asks whether a vibe coder can outcode a senior developer. CJ's verdict at 00:25:59: Randy 4 out of 5, Wes 3.5 out of 5, "the vibe coders prevail." The scoring rubric announced at 00:00:42 is overall aesthetics first, with code quality as "a small portion." - **Why it matters.** This is a live, unedited-feeling record of how a non-coder and an expert each drive the same model family on a taste-heavy front-end task under a hard clock. It shows where natural-language prompting stalls (subtle motion, shading, easing) and where the expert's habits cost him time (pixel-level fussing, environment debugging). - **Key stakeholders.** Syntax (publisher; Sentry is the named sponsor at 00:04:17), Wes Bos, CJ Reynolds, Randy, Raul Dronca (original designer), Anthropic as the vendor behind both tools, and Cloudflare and Claude's hosted artifact page as the two deploy targets. - **Risks and tradeoffs.** n=1 per condition. The judge is a colleague of both contestants. The rubric weights looks over code, and the scores are announced before CJ inspects the code. Randy's winning page renders its background as roughly 660 inline-styled `<i>` tags at about 5 frames per second (00:25:59). The cost figure at 00:26:42 is caption-garbled ("$745"; the follow-up joke about being "paid more than $7 to make a button" implies $7.45). - **Bottom line.** A 20-minute race scored on visual closeness can tell you who reaches a convincing first render faster. It can't tell you who produced maintainable code, and this one didn't try to. The useful finding is in the failure modes both contestants narrate, not in the 0.5-point margin. ## 📖 Main content **The setup.** CJ frames it as a question at 00:00:00: can a vibe coder outcode a senior developer? Randy's stated background is video editing and running Python scripts inside DaVinci Resolve, "not actually coding it, just telling the English language how to fix it" (00:00:00 to 00:00:42). Wes describes Randy as "an absolute dangerous vibe coder" who shows up with working Python. The target is a single UI component: a button over a blue pixel-mosaic background with a 3D tilt on hover, a cursor-following brightening effect, and a ripple ring on click (Wes's own decomposition at 00:01:26). **The rules.** 20 minutes to build. A 10-minute check-in. Grading on overall aesthetics against the original video first. Code is a stated but minor criterion: does it work at multiple screen sizes, does it look decent, would CJ want to work in the codebase (00:00:42 to 00:01:26). A surprise final round at 00:20:15 adds 5 minutes to produce a public URL. **Two workflows.** Randy's approach is descriptive and whole-picture. His first prompt names the visual ("monochromatic blue pattern behind it") and his second asks for the result to open in his Chrome instance with hot reload so he can see tweaks live (00:02:09 to 00:02:52). Wes's approach is decompositional. He opens a color picker to extract the palette, dictates a specific canvas-mosaic function (tile size 20, gap 2, 13 high by 50 wide, colors randomized between two blue variables, everything parameterized) and then hand-writes CSS around what the model returns (00:02:52 to 00:03:34, 00:05:00 to 00:05:44). CJ observes at 00:02:52 that a screenshot might have been a faster prompt than either. **Timeline as narrated.** Randy has a base button rendering in his real Chrome at about 4 minutes (00:05:00). Wes's first render is described by CJ as looking "like Windows XP" (00:04:17). By 5 minutes Randy has a hover glow and a click ripple and CJ calls it "looking amazing for 5 minutes in" (00:05:44). Wes spends the 6-minute mark waiting on the model to inject CSS variables and considers opening a second session to parallelize (00:06:29). At the 10-minute check-in both report confidence; Randy says he can finish in one more prompt (00:10:51), a forecast he retracts at 00:13:41. From 00:11:33 onward Randy is in a loop of describing 3D tilt, inner shadow, overlay dissolve, vignette, and ring glow in plain English, and calls it "iteration hell" at 00:18:48. Wes builds the 3D transform by hand (perspective, `transform-style: preserve-3d`, `translateZ`, then rotateX/rotateY) at 00:12:15 to 00:13:41, then switches to prompting for the same effect when hand-tuning runs long (CJ's observation at 00:14:25). Wes also spends time on an environment problem: the model injects the canvas mosaic as a base64 data URL, which he diagnoses as the cause of rendering issues and asks it to swap for a `canvas.toBlob` object URL; the swap doesn't fix it and he moves on with "close enough" (00:15:10 to 00:15:53). **Deploy round.** Wes says "Deploy to Cloudflare" and keeps tweaking styles while the agent works (00:20:15 to 00:20:57). Randy asks his agent for a shareable demo and it chooses Claude's hosted artifact page; the first publish is "not my button" because the agent removed some of his code during the deploy step, then a second attempt with the share menu produces a link (00:20:57 to 00:22:28). CJ notes Cloudflare now allows deploys without an account, which would have served Randy's case too (00:21:44). **Judging.** Wes's build: the hover state doesn't reset when the pointer leaves, the button lacks the top bevel that makes the original protrude, the tilt is exaggerated with no easing back, and the hover is "a white box" rather than a see-through top layer. CJ also notes he's viewing in Firefox, which lacks the squircle corner shape. Score 3.5 of 5 (00:23:10 to 00:23:54). Randy's build: resting state closer to the original, shadow at the bottom present, top a little too white, tilt a little too strong, mouse-off animation praised. Score 4 of 5 (00:24:36 to 00:25:59). Then CJ opens the code: the background is "literally 660 italic tags" with inline styles, and a frames-per-second meter reads 5 fps (00:25:59). Wes's response at 00:26:42 is that the model implemented an interface this close, and the `<i>` tag problem is one follow-up prompt away. **Cost.** Randy runs `/usage`. The transcript renders the answer as "$745" (00:26:42). Wes's rejoinder, that he has "certainly been paid more than $7 to make a button," makes $7.45 the plausible reading. Treat the exact figure as unverified. **What this race can and cannot show.** It can show, for one task and one pair of people, that a non-coder dictating to a frontier model reaches a visually convincing render of a small widget faster than an expert who splits time between prompting and hand-coding. It can show what kinds of requests stall in plain English: Randy's own list is tilt, easing, shadow spread, and vignette shape. It cannot show anything about code quality, because the rubric weights it lightly and the scores are announced before the code is opened. It cannot separate "vibe coder vs senior developer" from "one workflow vs another," because both contestants use Claude models and Wes prompts 8 or so times by my count. It cannot generalize past a single component with no state, no data, no accessibility requirement, and no second developer who has to read it later. Both contestants say versions of this themselves at 00:19:29 to 00:20:15. ## 🗒️ Notes #### ⏱️ [00:00:00](https://www.youtube.com/watch?v=7ZWB79HRRUw&t=0) Premise, contestants, and rules - CJ hosts. Wes Bos and Randy (transcript "Randy Recctor"; description handle @randyrektor) will recreate a button "found on Twitter by Raul Drunka" (Raul Dronca per the description). Wes may use any tool, including AI. - Randy's background: produces and edits the Syntax YouTube videos; runs Python scripts inside DaVinci Resolve without hand-writing them. - Rules at 00:00:42: 20 minutes, a 10-minute check-in, then grading. Aesthetics first; code quality (screen sizes, readability, "would I want to work in that codebase") is "a small portion." > [!quote] [00:00:42] > So, I'm going to grade you first just on overall aesthetics. How close is it to the original video of the button that you're trying to recreate? #### ⏱️ [00:01:26](https://www.youtube.com/watch?v=7ZWB79HRRUw&t=86) First moves: decomposition versus description - Wes decomposes the target into four parts: blue mosaic background, 3D effect, cursor brightening, click ring. - Randy has dictation set up and points the agent at a repo folder. Wes notes Randy is in Claude Desktop while Wes uses the CLI; both start from a shared starter template with HTML, base CSS, and a link to the X post (00:02:09). - Wes reaches for a color picker to build the palette "the standard I'm a web developer way." CJ suggests a screenshot would be simpler (00:02:52). - Randy's second prompt asks for the page to open in his Chrome with hot reload. #### ⏱️ [00:03:34](https://www.youtube.com/watch?v=7ZWB79HRRUw&t=214) Specific prompt, big-picture prompt, and a forecast - CJ identifies Randy's model as "Fable" and speculates it will spin up a dev server. - Wes dictates a canvas mosaic function with fixed parameters: tile size 20, gap 2, 13 rows by 50 columns, colors randomized between two blue variables, everything as named variables. - Randy predicts the shape of the race before it plays out: fast start, then a plateau at pixel pushing. > [!quote] [00:04:17] > When it comes to pixel pushing, I think that's where the limitation of being a vibe coder is really going to live. - Sentry is named as the sponsor paying for tokens (00:04:17). CJ notes both contestants use speech-to-text. Wes's first render "looks like Windows XP." #### ⏱️ [00:05:00](https://www.youtube.com/watch?v=7ZWB79HRRUw&t=300) First renders at four minutes - Randy's base button opens in his real Chrome at about 4 minutes in; he taunts Wes ("get wrecked"). - Wes is hand-editing CSS: width 100%, padding 50px, border radius, dropping uppercase. - Randy's second feature prompt (00:05:44): white glow outward on hover; a waterlike ripple from center on click, "one single ripple with no decay." CJ: "Looking amazing for 5 minutes in." #### ⏱️ [00:06:29](https://www.youtube.com/watch?v=7ZWB79HRRUw&t=389) Waiting on the agent, and the limits of words - Wes asks the agent to inject the blue variables into the body as CSS custom properties, then notes he's been waiting "a couple of minutes" and considers a second parallel session. - Randy's ripple works but isn't centered under the cursor. Wes decides not to fuss over small details ("I always start fussing too much"). - Randy notices the grid lines between tiles don't brighten on hover and prompts for it (00:07:13). He guesses at the word for the 3D motion: "yaw." - CJ states the thesis of the episode. > [!quote] [00:07:13] > These little subtle interactions like hover effects and and everything else like that's a lot harder to just express in words. - Wes structures the button as three elements: text, a glow span, and an "explosion" span for the click (00:07:55). Randy's grid lines now brighten. #### ⏱️ [00:08:38](https://www.youtube.com/watch?v=7ZWB79HRRUw&t=518) Dialing values by adjective - Randy's tuning prompts: ripple "wider and slightly less strong," then "faster," "less visible," "like 60% of what it currently is" (00:08:38 to 00:09:23). - Wes has the agent track pointer X/Y and write them to CSS variables on the button, then positions the glow with `var(--mouse-x)` / `var(--mouse-y)`. He mentions CSS anchor positioning as an option he knows less well and skips it (00:09:23). - CJ's read on Randy at 00:10:07: the hover is "a white opaque blob" rather than a per-cell color change. Randy asks for squircle corners (transcript: "squirles"). #### ⏱️ [00:10:07](https://www.youtube.com/watch?v=7ZWB79HRRUw&t=607) Ten-minute check-in - Wes: "way farther than I thought." Randy: "pretty confident." - CJ notes Randy writes in words developers don't normally use and the model still resolves them. - Randy: "I think I can finish it in one more prompt" (00:10:51). Wes: "Maybe we are cooked." - Wes tunes a box-shadow by hand and hits a jitter bug: too many decimal places in the transform, fixed by rounding to the nearest pixel (00:11:33). #### ⏱️ [00:11:33](https://www.youtube.com/watch?v=7ZWB79HRRUw&t=693) The 3D tilt, two ways - Randy prompts for "yaw and skew" and tells the model to reference the original video ("Good luck, AI"). - Randy's build goes jittery and the border radius collapses to square on fast mouse moves; he asks the model why (00:12:15). - Wes builds the tilt by hand: perspective on the parent, `transform-style: preserve-3d`, `translateZ`, then rotate on X and Y. "I've built this so many times in my career" (00:12:15 to 00:13:41). - Randy notices the inner shadow and the dark overlay in the original and describes both: an embossed inset shadow, plus a darker blue layer that dissolves where the cursor is (00:12:57). CJ calls that "a good way to describe it." - Randy retracts the one-more-prompt forecast (00:13:41). CJ: Randy's blue overlay "is looking much better." #### ⏱️ [00:14:25](https://www.youtube.com/watch?v=7ZWB79HRRUw&t=865) Four minutes left: Wes switches to prompting - Randy: overlay reads purple, wants it bluer; asks for a more gradual, "prettier" hover transition. - Wes dictates the 3D tilt as a prompt after hand-tuning runs long: bottom-right corner rotates down, rotation follows the pointer on X and Y. CJ: he "resolved to prompting to get it out." - Wes tells the agent to stop rebuilding on every step because a dev server is already running, then asks for clamp variables on X and Y (00:15:10). - Wes diagnoses a rendering problem: the mosaic is injected as base64. He asks for `canvas.toBlob` and an object URL instead. It doesn't fix the issue; he settles for "close enough" (00:15:53). - Randy: more yaw, base layers still purple, "make them all the same sort of monochromatic blue." Asks to double the inner shadow (00:16:36). #### ⏱️ [00:16:36](https://www.youtube.com/watch?v=7ZWB79HRRUw&t=996) Last two minutes - Randy adds an outer blue glow and expects "the ugliest glow"; it's "actually decent." - Wes prompts for the click explosion element as a growing glowing ring, and reflects on his own process. > [!quote] [00:17:21] > I did not expect to be prompting this much. I expected to be coding a lot more by hand - Randy spots a shadow across the bottom of the original and a radial vignette from top-middle (00:18:04). CJ: Randy's click ring is "a solid circle" but the hover interactions look good. - Randy's last prompt bundles the vignette, an inset box-shadow, and a softer ring, at 23 seconds left, and names the failure mode. > [!quote] [00:18:48] > my vocabulary might not match up to what a developer is looking for. - Wes adds saturation and considers `mix-blend-mode` as time expires (00:19:29). #### ⏱️ [00:19:29](https://www.youtube.com/watch?v=7ZWB79HRRUw&t=1169) Time, reflections, and the deploy round - Wes: "That was not enough time." He prompted "way more than I thought." He calls his result "a crappy version of the button." > [!quote] [00:20:15] > There are so many little things that the original designer did that are hard to put into words unless you like sit down and are able to tweak each individual thing. - CJ's surprise round: 5 minutes to produce a public URL. Wes: "Deploy to Cloudflare." Randy asks the agent to set the button up for others to try. - Randy's agent picks Claude's hosted artifact page as the fastest public link (00:20:57). Wes keeps restyling his glow as a radial gradient while his deploy runs. - Randy's first published page is "not my button": the agent removed code during deploy. Second pass via the share menu works (00:21:44 to 00:22:28). CJ notes Cloudflare deploys without an account now. - Wes is still changing colors when CJ calls time; "It's my show. Producer Randy, I do what I want" (00:22:28). #### ⏱️ [00:23:10](https://www.youtube.com/watch?v=7ZWB79HRRUw&t=1390) Judging Wes - The template's embedded reference video survives in Wes's build; Randy's agent removed it. - CJ glimpses Randy's markup early: "hundreds of eye tags with inline styles" (transcript spelling for `<i>` tags). - Wes's defects: hover doesn't reset on mouse-out, no top bevel so the button looks flat, tilt too exaggerated, snap-back with no easing, hover is a white box rather than a see-through layer. CJ is on Firefox, which lacks squircle corners. - Score: 3.5 out of 5 (00:23:54), after a brief "out of 10" slip. #### ⏱️ [00:24:36](https://www.youtube.com/watch?v=7ZWB79HRRUw&t=1476) Judging Randy, and the code - CJ: "shocked at how good this is." Randy explains the palette: two blues, randomized per square. - Squircle dispute: CJ says only border-radius was used; Randy says open it in a browser that supports squircles; the caption "It's work in Firefox" is ambiguous about who's right. - CJ mocks the AI-added instruction text at the bottom of Randy's page ("Hover to reveal the grid"). - Defects: top too white, tilt too strong. Praise: resting state closer than Wes's, bottom shadow present, mouse-off animation. > [!quote] [00:25:59] > But I I think I would I would give Randy a four out of five. So he beat you by.5 here on this one. But the vibe coders prevail. - Then the code: the background is 660 inline-styled italic tags. CJ runs an fps meter. > [!quote] [00:25:59] > Five frames a second it's rendering at. It's really good though. #### ⏱️ [00:26:42](https://www.youtube.com/watch?v=7ZWB79HRRUw&t=1602) Model, verdict on the field, and cost - Wes confirms Randy used "Fable 5.1." > [!quote] [00:26:42] > Yeah man. The day that it's going to be implement interfaces this close like I think we're there man. - Wes: he could take Randy's result and follow up with "don't use 660 italic tags." - Randy runs `/usage`; the caption reads "$745." Wes's joke about having "been paid more than $7 to make a button" implies $7.45. Unverified either way. ## 📚 References The transcript itself contains no links; the following come from the video description or are primary sources for named entities. - [Developer Showdown: Vibe Coder vs Senior Developer (Syntax)](https://www.youtube.com/watch?v=7ZWB79HRRUw): the source video, 27:17, uploaded 2026-09-25, no chapters. - [Button challenge starter repo](https://github.com/wesbos/button-challenge): Wes Bos's repo from the description; the starter template both contestants began from (HTML, base CSS, link to the original post, per 00:02:09). - [Raul Dronca's Pixel Ripple Button](https://x.com/raul_dronca/status/2093270659824529461): the original design being recreated. The transcript renders the name as "Raul Drunka." - [Syntax](https://syntax.fm): publisher. - [Sentry](https://sentry.io/syntax): named sponsor at 00:04:17. - [Randy Rektor on YouTube](https://www.youtube.com/@randyrektor): the contestant the transcript calls "Randy Recctor." - Claude Desktop, Claude Code CLI, and the hosted artifact page (Anthropic): Randy's client and deploy target, and Wes's client. The transcript renders the CLI as "cloud CLI." The model is "Fable 5.1" at 00:26:42. - Cloudflare: Wes's deploy target at 00:20:15; CJ notes at 00:21:44 that account-free deploys are now possible. - CSS `corner-shape` / squircle corners: the feature CJ says Firefox lacks at 00:22:28 (transcript: "squirle border"). ## 🗣️ Paraphrase Syntax runs a race. CJ gives Wes Bos and producer Randy 20 minutes each to rebuild Raul Dronca's pixel-mosaic ripple button, and says he'll score mostly on how close it looks, with a small weight on code. Randy talks to Claude Desktop and asks for the page to open in Chrome with hot reload. Wes color-picks the palette, dictates a tightly specified canvas mosaic to the Claude CLI, and hand-writes the CSS around it. Randy has a recognizable button in about 4 minutes and a glow-plus-ripple in 5. Wes spends minutes waiting on a variable-injection step and later on a base64 rendering bug. Then the hard part arrives for both. Randy's plain-English requests for tilt, easing, inner shadow, overlay dissolve, and vignette turn into what he calls iteration hell, and he says out loud that his vocabulary may not match what the model expects a developer to say. Wes builds the 3D transform by hand, then gives up hand-tuning and prompts for it, and admits he prompted far more than he planned. Time runs out with both calling their results rough. A surprise 5-minute deploy round follows: Wes says "deploy to Cloudflare"; Randy's agent publishes to a Claude artifact page, breaks the button on the first try, and fixes it on the second. CJ scores Wes 3.5 of 5 (hover doesn't reset, no bevel, tilt too hard) and Randy 4 of 5 (closer at rest, nicer mouse-off animation, a bit too white). Only afterward does he open Randy's code: 660 inline-styled `<i>` tags rendering at 5 frames per second. Wes's take is that the interface fidelity is the news, and the markup is one more prompt away. Randy's `/usage` shows a single-digit dollar cost for the session. ## 📰 Newsletter **Twenty minutes, one button, two ways to drive the same model.** Syntax's new showdown puts Wes Bos (Claude CLI plus hand-written CSS) against producer Randy (Claude Desktop, dictation, zero hand-coding) on Raul Dronca's Pixel Ripple Button. Randy has a convincing render in 4 minutes and takes the aesthetic score 4 to 3.5. Then CJ opens the code: 660 inline-styled italic tags at 5 fps. Both things are true at once, and that's the lesson. For WordPress folks the interesting part isn't who won. It's the list of things neither contestant could get out of the model in plain English under a clock: easing on the tilt return, the spread of an inner shadow, a top bevel, a see-through overlay instead of a white blob. Those are the same details that separate a block pattern that ships from one that gets sent back in theme review. Randy's own diagnosis at 18:48, that his vocabulary doesn't match what the model expects a developer to say, is a good argument for teaching front-end vocabulary as a prompting skill, not a coding skill. Also worth a look: the deploy round. "Deploy to Cloudflare" worked in one line for Wes. Randy's agent chose a hosted artifact page and dropped some of his code on the way out. If you're building Playground demos or pattern previews with an agent, budget a verification pass after publish. Try the challenge yourself at [github.com/wesbos/button-challenge](https://github.com/wesbos/button-challenge), and see the [original button](https://x.com/raul_dronca/status/2093270659824529461). [Watch the episode](https://www.youtube.com/watch?v=7ZWB79HRRUw). ## ✅ Action items #### DevRel - Developer advocacy: run the button challenge as a livestream format, but publish the rubric with weights before the clock starts and score code before announcing a winner. That fixes the two design flaws this episode shows. - Education: build a 30-minute workshop on "front-end vocabulary for prompting" using Randy's stall list at 00:11:33 to 00:18:48 (tilt, easing, inset shadow, overlay dissolve, vignette) as the exercise set. - Developer experience: the starter repo pattern (HTML, base CSS, link to the reference) is a good quickstart shape for any "recreate this UI" tutorial. Fork it for a WordPress block variant. - Developer marketing: don't quote "vibe coder beats senior dev" from this source. Quote the timings (4 minutes to first render, 20 minutes to a 4/5) and the code finding (660 tags, 5 fps) together. - Community management: when this video circulates, pair it with the 00:25:59 code inspection so the aesthetic score doesn't travel alone. - Internal/external/cross-project: ask Syntax whether the two final builds are in the challenge repo; a diff is worth more than the scores. #### OSPO - Policy & Governance: no direct action from this source; nearest relevance: an agent removed template code during a deploy step (00:21:44). Any contribution policy for agent-assisted PRs should require a post-publish diff review. - License Compliance: none from this source. - Security Management: none from this source. The deploy targets (Cloudflare account-free deploy, hosted artifact pages) are worth a note in any guidance about where internal demos may be published. - Software Inventory: none from this source. - Developer Support: collect the "AI removed my code" failure at 00:21:44 as a support FAQ entry for agent users. - Community Engagement: none from this source. - Strategic Alignment: if productivity claims from timed races reach leadership decks, attach the rubric and the code-quality finding. This episode is a clean example of why. #### Community - Maintainers: no direct action from this source; nearest relevance: a first-render-fast, fix-later workflow generates PRs that look done and aren't. Ask for an fps or bundle check on UI PRs from agent users. - Contributors: use the challenge repo as a pairing exercise: one person prompts, one person hand-codes, then swap. - Sponsors: none from this source beyond noting Sentry underwrote the tokens (00:04:17). - Ecosystem: none from this source. #### WordPress - Core: no direct action from this source. - Core Performance: the 5 fps result at 00:25:59 from 660 inline-styled elements is a teaching case for why DOM count and paint cost belong in review, not just Lighthouse scores. - Core AI: add "visual fidelity is not code quality" as an explicit evaluation axis for any AI-assisted block or pattern generation pilot. - **Core Program Team:** none from this source. - Mobile: none from this source. - Playground: the deploy round (00:20:15 to 00:22:28) is a template for a Playground-based "publish your button" variant with a blueprint instead of a third-party host. - Community: the format itself (two contestants, one judge, one reference design, 20 minutes) is a WordCamp contributor-day activity. Publish the rubric first. - Training: draft a lesson on describing motion and shading in CSS terms (easing, inset shadow, radial gradient, transform-style) aimed at non-coders who prompt. - Marketing: none from this source. - Support: none from this source. - Design: Randy's descriptive stall list is a list of design vocabulary gaps. A one-page glossary of hover, focus, and motion terms serves both designers and prompters. - Documentation: none from this source. - Photos: none from this source. - TV: if this format is adapted for WordPress.tv, add chapters; this video has none across 27 minutes. - Polyglots: none from this source. - Accessibility: neither build was checked for keyboard focus, reduced motion, or contrast, and the rubric didn't ask. Any WordPress version of the challenge should put those in the rubric. - Meta: none from this source. - CLI: none from this source. - Hosting: no direct action; nearest relevance: two one-line deploy paths (Cloudflare, hosted artifact) set the bar for how easy publishing a demo now is. - Tide: none from this source. - Openverse: none from this source. - Themes: the 660-tag background is the kind of markup theme review should catch. Add a DOM-count heuristic to review notes. - Plugins: none from this source. #### The WPOCC - Programs: no direct action from this source; nearest relevance: if The WP Open Community Collective funds contributor training, front-end vocabulary for prompting is a cheap, high-return module. - Projects: none from this source. - Funding experiments: none from this source. ### FAIR - Technical independence: no direct action from this source; nearest relevance: both deploy paths in the episode depend on a single vendor's hosting. A FAIR-style demo path should have a self-hostable option. - Policies and covenants: none from this source. - Productized governance artifacts: none from this source. ## 🧪 Hypotheses 1. On single-component visual tasks under 30 minutes, a non-coder dictating to a frontier model reaches a judge-rated "recognizable" render faster than an expert who alternates prompting with hand-coding, by at least 2 minutes on median. (This episode: about 4 minutes versus a "Windows XP" first render at a similar time, then divergence.) 2. Blind aesthetic scoring of agent-generated UI is uncorrelated with a code-quality score on the same artifact (DOM node count, fps, inline-style ratio) at r below 0.2. 3. The categories of request that stall plain-English prompting on UI are stable across prompters: motion easing, shadow spread and inset, layered opacity, and 3D transforms account for more than 60% of retry prompts. 4. Prompting with a domain-vocabulary glossary (easing, inset, radial gradient, transform-style) reduces retry prompts on the same task by at least 30% versus unaided description. 5. An expert's time-to-first-render is slower than a novice's on this task class because experts front-load decomposition and palette extraction (Wes at 00:02:52), and this ordering is a habit, not a necessity. 6. Agent-driven deploy steps modify or remove source in more than 10% of runs when the deploy prompt is open-ended ("set this up so others can try it") versus under 2% when it names the target ("deploy to Cloudflare"). ## 📊 Methodology - **Design for H1 and H5.** Recruit 20 pairs (one non-coder, one senior front-end developer). Same starter repo, same reference design, same model, 20 minutes. Record screen and audio. Two blinded judges rate "recognizable render" at 1-minute intervals from the recordings. Report time-to-recognizable per condition and the order of first actions (decompose, palette, first prompt). - **Design for H2.** Take every artifact from H1. Judges score aesthetics blind on a 5-point scale. Separately, compute DOM node count, inline-style ratio, and frames per second under pointer movement with an automated harness. Report correlation. - **Design for H3.** Transcribe every prompt from H1. Two coders classify each retry prompt by target property (motion, shadow, layering, transform, color, layout). Report the share per category and inter-rater agreement. - **Design for H4.** Split the non-coder arm: half get a one-page CSS motion and shading glossary before the clock; half don't. Count retry prompts per participant. Pre-register the 30% threshold. - **Design for H6.** Run 50 deploys with an open-ended prompt and 50 with a named target on the same finished artifact. Diff source before and after. Count runs with any non-config change. - **Controls throughout.** Fix the model version (the episode used Fable 5.1). Fix the judge's browser (CJ's Firefox lacked squircle support at 00:22:28, which affected one contestant). Announce the rubric with weights before the clock, and score code before revealing aesthetic scores. ## ❓ Questions - What did the two final builds actually contain? Are they in the challenge repo, and can they be diffed? - Was Randy's 4 of 5 scored on a browser that rendered his squircles, and Wes's 3.5 on one that didn't (00:22:28, 00:24:36)? - What was the real `/usage` figure at 00:26:42: $7.45, or something the caption garbled differently? - How many prompts did each contestant send? My transcript count is roughly 15 for Randy and 8 for Wes, plus Wes's hand edits. - Would Wes's time have gone differently without the base64 rendering detour at 00:15:10 to 00:15:53? - What did Randy's agent remove during the first deploy at 00:21:44, and why did the open-ended prompt cause it? - How would a second 20 minutes change the ranking, given both contestants said they were mid-iteration when time ran out? - If the rubric had weighted code at 50%, would 660 inline-styled tags at 5 fps have flipped the result? ## 🔮 Future research - **Vocabulary as the bottleneck.** Randy names it at 00:18:48: the model resolves developer vocabulary better than lay description. Nobody has measured how much a small glossary closes that gap on UI tasks. - **Time-to-first-render versus time-to-done.** This episode shows a fast first render and a long tail. A study that runs the clock to a fixed quality bar rather than a fixed time would show whether the novice advantage persists or inverts. - **Aesthetic-score bias in agent evaluation.** Judges anchored on looks before opening code, then kept the score. Whether visual polish inflates code-quality ratings in blinded review is testable and matters for any AI-assisted PR process. - **Agent deploy safety.** The "not my button" failure at 00:21:44 is a small instance of an agent altering source during an unrelated step. Rates and triggers are unstudied for consumer deploy flows. - **Expert habit cost.** Wes's palette extraction, decomposition, and environment debugging are correct engineering behaviors that cost him time on this rubric. Whether experts can switch modes on demand, and whether they should, is an open question about skill transfer. ## 💡 Implications - **Practice.** For small visual widgets, prompt for the first render and reserve hand-coding for what the model can't hear: easing, shadow spread, layering. Wes reached that split by 00:14:25 under pressure; start there. - **Policy.** Any evaluation of AI-assisted work needs the code criteria scored before the visual ones are revealed. This episode shows the anchoring in real time at 00:25:59. - **Security.** Open-ended deploy prompts changed source in one of two attempts here (00:21:44). Treat "publish this" as a code change and diff it. - **Education.** Front-end vocabulary is now a prompting skill. A non-coder who knows "inset box-shadow" and "ease-out" gets further than one who says "stronger" and "prettier" (Randy at 00:08:38, 00:14:25, 00:18:48). - **Funding models.** A single-digit dollar session produced a 4/5 render. That price makes timed races cheap to run at scale, which is the only way the n=1 problem here gets fixed. - **Productivity claims.** This is an n=1 entertainment format with a colleague judge and a looks-first rubric. It supports the narrow claim that novices reach convincing first renders fast, and it undercuts, in its own final minute, the broad claim in its title. ## 🧠 Learning styles assessment - **Reading level estimate.** Flesch-Kincaid Grade Level on the transcript body: approximately grade 6 to 7. Flesch Reading Ease near 80, reflecting short spoken sentences and heavy use of "like" and "okay." Domain terms (preserve-3d, translateZ, base64, canvas.toBlob, squircle, mix-blend-mode) push effective comprehension of the technical thread to an intermediate front-end audience. #### 👀 Visual learners - Present: two live screens, the reference video, and a final side-by-side judging pass at 00:23:10 to 00:25:59. - Improve: no chapters, so a visual learner can't jump to the judging. A before/after strip of both buttons next to the original at the 10- and 20-minute marks would compress the whole argument into one frame. #### 🔊 Aural learners - Present: continuous three-way commentary; both contestants think aloud as they dictate prompts. - Improve: a music bed overlaps speech at 00:11:33, 00:12:15, 00:16:36, and 00:21:44 (the transcript marks [music] mid-sentence). Duck it. Cross-talk between Wes and Randy makes attribution hard in the captions. #### 🗣️ Verbal learners - Present: Randy narrates his lay vocabulary and its failure (00:18:48); Wes names CSS properties as he types them (00:12:15). - Improve: nobody defines squircle, yaw, base64, or object URL for the audience. One clause each. #### 🧩 Kinesthetic learners - Present: the starter repo is linked in the description, so the challenge is reproducible. - Improve: link the two finished builds so a learner can open, inspect, and fix the 660-tag background as an exercise. #### 🧠 Logical learners - Present: a stated rubric (00:00:42), a mid-point checkpoint, and a scored result. - Improve: the rubric weights are never quantified and the code inspection happens after scoring. Publish weights and a scoresheet. #### 🧑‍🤝‍🧑 Social learners - Present: banter, a live judge, and a Syntax community around the show. - Improve: no prompt to viewers to post their own attempt; the description links the repo but the video never says "try it and share." #### 🧘‍♀️ Solitary learners - Present: the repo plus the original design make a complete self-paced exercise. - Improve: a reflection prompt ("which of Randy's stall words do you know the CSS term for?") would turn watching into practice. #### 🌿 Naturalistic learners - Present: nothing explicit. Randy's "waterlike ripple" at 00:05:44 is the only natural analogy. - Improve: the 5 fps result is a paint-cost story; naming the energy and battery cost of a page repainting 660 elements would land with this group. ## 📊 Accessibility assessment #### Screen reader semantics - Present: YouTube supplies player landmarks; the auto-transcript is machine-readable. - Improve: the entire subject (a button's visual behavior) is shown, not described. A blind viewer gets three people reacting to something never narrated. WCAG 2.2 AA 1.2.5 (Audio Description, Prerecorded) isn't met; 1.1.1 (Non-text Content) fails for the code shown at 00:25:59. #### Keyboard navigation - Present: the YouTube player is keyboard operable with visible focus. - Improve: nothing in the video adds barriers; 2.1.1 and 2.4.7 pass via the platform. Neither contestant's button was tested for keyboard focus, and the rubric didn't ask. #### Contrast and readability - Present: unverifiable from a transcript. Editor and browser windows on a dark theme are the likely presentation. - Improve: small editor text at default resolution risks 1.4.3 (Contrast Minimum) and is unreadable on mobile. Zoom into code during the judging segment. #### Text resizing and reflow - Present: the player scales; captions resize independently. - Improve: on-screen editor text and the countdown don't resize. 1.4.4 (Resize Text) and 1.4.10 (Reflow) fail for burned-in text. #### Media and captions - Present: an auto-generated transcript exists, which is how this analysis was produced. - Improve: captions garble every proper noun and several technical terms: "Recctor" for Rektor, "Drunka" for Dronca, "cloud CLI," "squirle," "eye tags" and "itallic tags" for `<i>` tags, and "$745" for what is likely $7.45. Cross-talk is unattributed. That's a 1.2.2 (Captions, Prerecorded) failure in substance. Human-corrected captions and speaker labels are the fix. No chapters across 27:17. #### Forms and interactions - Present: none in the video itself. - Improve: the two published buttons are interactive pages. Neither was checked for 2.4.7 (Focus Visible), 2.5.8 (Target Size, Minimum), or 2.3.3 (Animation from Interactions) despite a 3D tilt and ripple that would trigger motion sensitivity. Add prefers-reduced-motion to the rubric. #### Standards reference - Primary gaps against WCAG 2.2 AA: **1.2.2** (inaccurate captions, no speaker labels), **1.2.5** (no audio description of a visual-only subject), **1.1.1** (code conveyed visually only), **1.4.4 / 1.4.10** (burned-in text). For the artifacts produced: **2.3.3** and **2.4.7** untested. Captions are the highest-impact, lowest-cost fix. ## 🌍 DEIB assessment #### Cultural breadth - Present: the reference design comes from Raul Dronca, credited by name at 00:00:00 and linked in the description. - Improve: idiom-heavy commentary ("get wrecked," "we are cooked," "iteration hell") assumes fluency in US developer slang. A non-native viewer loses the jokes and some of the content. #### Inclusive language - Present: no gendered generalizations; contestants are addressed by name. - Improve: at 00:25:18 the caption reads "It's so AIDS" in reaction to AI-generated instruction text. This is most likely an ASR mishearing of "AI" plus a trailing sound, but if spoken as captioned it's a disease name used as a pejorative and should be cut or corrected in the captions. Flag for the editor. #### Neurodiversity support - Present: a fixed structure (rules, build, check-in, build, deploy, judge) that the host announces in advance at 00:00:42. - Improve: three overlapping voices, music under speech, and no chapters make this hard to follow for viewers who process audio serially. Chapters at the 10-minute check-in, time-up, deploy round, and judging would help most. #### Representation - Present: three named participants, all Syntax staff. - Improve: all three are men on the same team. The original designer is only present as a linked post. Inviting the designer to judge, or a judge outside the show, would add both representation and independence. #### Psychological safety - Present: the losing contestant (Wes) takes the result with humor and credits the model's output at 00:26:42; Randy's self-deprecation ("crappy AI design," 00:18:48) is met with encouragement from CJ. - Improve: the taunting ("get wrecked," 00:05:00) is friendly between colleagues but models a competitive register that a viewer new to coding may read as the norm. A closing line that the point is the process, not the win, would cost 10 seconds. ## ✅ Logical validity #### Strong reasoning - **Falsifiable forecast, 00:04:17.** Randy predicts he'll get ahead fast, then plateau at pixel pushing while Wes passes him. Half confirms (he leads at 4 minutes and hits "iteration hell" at 00:18:48); half doesn't (Wes doesn't pass him on the rubric used). Making a prediction that can fail, and then narrating where it did, is the best reasoning in the episode. - **Mechanistic diagnosis, 00:15:10.** Wes identifies the base64 data URL as the cause of rendering issues and proposes `canvas.toBlob` with an object URL. The fix doesn't land in time, but the causal chain (large inline data URL, repaint cost) is a real mechanism, not a guess. - **Stated limit, tested live, 00:07:13.** CJ's claim that subtle interactions are hard to express in words is checked over the following 11 minutes as Randy's retries cluster exactly there. - **Self-diagnosis, 00:18:48.** Randy's observation that the model resolves developer vocabulary better than his own is a specific, testable explanation for his stall, and it matches the pattern of his retries ("stronger," "prettier," "less strong"). - **Concession against interest, 00:26:42.** Wes, having lost, argues the model's interface fidelity is the real result and the markup is one prompt away. Whether or not he's right, he's arguing against his own position. #### Fallacies - **Hasty generalization, title and 00:25:59.** "Can a vibe coder outcode a senior developer?" is answered with one pair, one component, one judge, and a 0.5-point margin on a 5-point aesthetic scale. *Fix:* frame the result as "on this task, on this rubric," which CJ nearly does and the title doesn't. - **Rubric drift, 00:00:42 versus 00:25:59.** Code quality is announced as a criterion, but both scores are given before any code is inspected, and the 660-tag, 5-fps finding doesn't change the result. *Fix:* score code first, or publish weights and apply them. - **False dichotomy, 00:00:00.** "Vibe coder vs senior developer" implies a human-versus-AI contrast, but both contestants use Claude models and Wes prompts roughly 8 times. The real contrast is two prompting workflows plus one person's hand-coding. *Fix:* name it as such. - **Uncontrolled judging environment, 00:22:28 and 00:24:36.** CJ judges in Firefox, which lacks squircle corners, and this affects at least one contestant's rendering. *Fix:* fix the browser before the race. - **Non-independent judge.** CJ is a Syntax host judging two Syntax colleagues and delivers the verdict as "the vibe coders prevail," a narrative line, not a scoring statement. *Fix:* an outside judge, or blind scoring from screenshots. - **Garbled quantity, 00:26:42.** "$745" as captioned is unusable as a cost figure; context implies $7.45. Not the speakers' error, but it's the kind of number that gets repeated. *Fix:* corrected captions and the figure on screen. #### Tone of voice - Fast, joking, and competitive in the standard developer-YouTube register, with contractions and second person throughout. The taunting peaks early (00:05:00, "get wrecked") and the self-criticism peaks late (00:18:48, 00:20:15) as both contestants run out of time. The judging segment shifts to careful, specific critique (bevel, easing, overlay) at 00:23:10 to 00:25:59, then back to banter for the code reveal. The most candid lines come from the loser: Wes's "I did not expect to be prompting this much" at 00:17:21 and "I think we're there" at 00:26:42 are the episode's real conclusions, delivered casually. ## 🛡️ DARVO analysis Not applicable to this source. DARVO (Deny, Attack, Reverse Victim and Offender) describes a response pattern to accusation or criticism. This is a friendly competition among colleagues with no accusation and no defensive posture. For completeness across the three prongs: **Deny**: nothing is denied; both contestants volunteer their shortfalls (Wes at 00:20:15, Randy at 00:18:48) and Wes accepts the code-quality critique of Randy's build as a model limitation rather than disputing the scoring. **Attack**: the taunts at 00:05:00 and the "It's my show" line at 00:22:28 are jokes between coworkers, not attacks on a critic's credibility. **Reverse victim/offender**: no such move appears; the loser credits the winner's tool. ## 🎯 Conclusion Strip the title and the scoreline and what remains is a well-documented n=1 on a narrow task. A non-coder dictating to a frontier model reached a convincing render of a small visual widget in about 4 minutes and a 4-of-5 aesthetic score in 20. An expert who split time between prompting and hand-coding reached 3.5 of 5 while spending minutes on palette extraction, a variable-injection wait, and a base64 rendering bug, and said afterward that he prompted far more than he planned (00:17:21). Both hit the same wall: easing, shadow spread, overlay dissolve, and 3D tilt are hard to get out of a model in plain English, and Randy named the mechanism at 00:18:48: the model resolves developer vocabulary better than lay description. What the race can't show is anything about code quality, because the rubric barely weighted it and the scores were locked before CJ opened the code. When he did, the winning build was 660 inline-styled tags rendering at 5 frames per second (00:25:59). Wes's response, that the fidelity is the news and the markup is one prompt away, is a fair claim and also untested in the episode. **Next steps for readers:** if you're tracking coding-agent productivity claims, log this as evidence for "fast first render on small visual tasks" and as counter-evidence for anything broader, and note that both contestants used the same model family. If you run a version of this, publish the rubric weights before the clock, score code before looks, fix the judge's browser, and put the two finished builds in the repo so someone can diff them. And build the glossary: the cheapest intervention this episode suggests is teaching prompters the CSS words for what they're seeing. ## 🔄 Refactor Appendix — Developer Showdown: Vibe Coder vs Senior Developer > Density: 2–5 Literature atoms (H3 pad), 0–3 Permanent candidates (H4 pad). > Emitted: 4 Literature, 1 Permanent. Resonance filter applied. The cost figure was > dropped as caption-garbled and the scoreline as n=1. > > Konik claim-header rules: present tense, declarative, ≤10 words, searchable, unique. > > Atomicity: one declarative sentence per atom. "and"/"also" → split. > > Tag pool: #bmf · #addendum · #xref · #articleseed · #storystem · #share · #aphorisms ### 📚 Literature Split Pad #### [H1] Subtle UI interactions resist plain-English prompting > [!quote] [00:07:13] > These little subtle interactions like hover effects and and everything else like that's a lot harder to just express in words. **Context & use**: - 00:07:13, CJ commentating as Randy prompts for grid-line brightening and starts guessing at the word for the 3D motion. - The claim is tested over the next 11 minutes: Randy's retries cluster on tilt, easing, shadow spread, and overlay dissolve. Pair with [H4] for the mechanism. **Tags**: #xref #articleseed <!-- atomicity: 1 idea ✓ --> #### [H2] Senior developers prompt more than they plan to > [!quote] [00:17:21] > I did not expect to be prompting this much. I expected to be coding a lot more by hand **Context & use**: - 00:17:21, Wes with under 2 minutes left, having switched from hand-tuning the 3D transform to dictating it at 00:14:25. - Under a clock the expert converges on the novice's workflow. Useful as a counterweight to the "vibe coder vs senior developer" framing: both were prompting Claude. **Tags**: #xref <!-- atomicity: 1 idea ✓ --> #### [H3] Aesthetic scores hide paint-cost failures > [!quote] [00:25:59] > Five frames a second it's rendering at. It's really good though. **Context & use**: - 00:25:59, CJ running an fps meter on Randy's winning build after awarding 4 of 5; the background is 660 inline-styled italic tags. - The two clauses sit next to each other and don't interact: the score was locked before the code was opened. Specimen for evaluation design in any AI-assisted UI review. **Tags**: #xref #share <!-- atomicity: 1 idea ✓ --> #### [H4] Prompters stall on missing developer vocabulary > [!quote] [00:18:48] > my vocabulary might not match up to what a developer is looking for. **Context & use**: - 00:18:48, Randy at 23 seconds left, after a run of "stronger," "prettier," and "less strong" prompts that didn't land. - Randy's own explanation for the plateau he predicted at 00:04:17. It points at a cheap intervention: a CSS motion and shading glossary for non-coders who prompt. **Tags**: #xref #articleseed <!-- atomicity: 1 idea ✓ --> ### 🧠 Atomic Split Pad #### [P1] A looks-first timed race can't measure code quality **Claim** (one sentence, Courtney's voice): A build race scored on visual closeness before the code is opened measures time-to-convincing-render and nothing else. **Evidence pointer**: [[#H3]] · [[#H1]] **Scope & conditions**: Holds for any evaluation where the visual score is locked before code inspection, regardless of who or what produced the code. Breaks if code criteria are scored first or weighted explicitly; then the race measures a composite, and this episode never ran that version. Doesn't speak to whether the code would be fixable in one more prompt (Wes's claim at 00:26:42), only to what the race observed. **Links**: - [[AI Coding Agents Excel at Mechanical Bulk Work]] — because contrasts on task type: this is a taste-heavy visual widget, not bulk mechanical work, and the agent's win here is on speed to first render rather than on volume - [[Every claim carries a fact]] — because applies-in reading productivity claims: the 4-vs-3.5 scoreline travels without the 660-tag, 5-fps fact attached - [[Verify delegated work before calling it done]] — because extends: the judging order in this episode is the anti-pattern that rule exists to prevent <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Check whether the two finished builds are in github.com/wesbos/button-challenge; a diff of Wes's and Randy's output is worth more than the scores #fleeting #inbox - [F2] Confirm the `/usage` figure at 00:26:42: caption says "$745," Wes's joke implies $7.45 #fleeting #inbox - [F3] Open question: did CJ's Firefox (no squircle support, 00:22:28) penalize one contestant's render and not the other's? #fleeting #inbox - [F4] Article seed: "Front-end vocabulary is a prompting skill" from Randy's stall list at 00:11:33 to 00:18:48 (tilt, easing, inset shadow, overlay dissolve, vignette) #fleeting #inbox #articleseed - [F5] Log in the coding-agent productivity notes: n=1, same model family both sides, aesthetic rubric, code scored after the verdict, 660 tags at 5 fps #fleeting #inbox - [F6] The agent removed source during an open-ended deploy prompt at 00:21:44; collect as an instance for the "diff after publish" rule #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] Look for the final builds in the button-challenge repo and diff them against each other and the starter — coding-agent productivity research, 20 min #things - [ ] Draft a one-page CSS motion and shading glossary for non-coders who prompt (easing, inset box-shadow, radial gradient, transform-style, corner-shape) — training material seed #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/Developer Showdown Vibe Coder vs Senior Developer.md|Developer Showdown: Vibe Coder vs Senior Developer by Syntax]] ## Highlights - [00:07:13] there's going to be two things that follow the mouse. Okay. So, see see the grid in between here? How it's the there's the grid lines in between? They're not getting lighter as I do that. Okay, great job. The hover effect looks pretty good, but one challenge is that the dark grid lines in between don't also illuminate from the hover effect. Those also need to go up in brightness. All right, so we'll give it that. I think that's pretty good. We'll get the the hover effect last, like the the sort of um side to side skewing that's happening here. Panning, tilting, yaw, yaw. might be yaw. >> These little subtle interactions like hover effects and and everything else like that's a lot harder to just express in words. We'll see what Randy comes out with, but I I feel like we're reaching [00:07:55] the limits of exactly what you can just describe to the AI without really knowing how how I guess how UI works or how code works. I don't know. So, let's go into our button and we're going to have three elements. We're going to have the button text. We're going to have the We're gonna have a span with the button glow. There's a second one. If we put the controls on this video and start to scrub it. Yeah. You see when he clicks, there's like a a button explosion. Now, that will be the next one. We'll call that an explosion. Oh, this is looking good. Okay. So, yeah. See this? Now, it's actually starting to make the grid lines lighter, too. So, the grid lines ([View Highlight](https://read.readwise.io/read/01m3cajskm703qgb00fq1she74)) - Note: [H1] Subtle UI interactions resist plain-English prompting - Tags: atom/literature/h1 - [00:17:21] >> Add a another element for the button explosion. This is going to be similar to button glow, but it will only show up when I click and then it will grow in size and sort of explode out. Think of it as a glowing ring. I did not expect to be prompting this much. I expected to be coding a lot more by hand, but 20 minutes up against producer Randy, that's not a lot. Um, let's tweak these values here. Max Y rotation. Let's take that to 15. Oh, there's a there's a shadow across the whole bottom of the button. Wes is probably hoping I didn't see stuff like that cuz he's going to notice stuff like that. He's like so dialed on this stuff. There is a shadow [00:18:04] across the entire bottom of the button. And it looks like there's like a slight radial. See, I'm I'm accomplishing it with like a sha uh I don't know what the word is I'm looking for, but a shadow on the outside. And I think it's actually a radial gradient if you look at this here, cuz it's like the brightest right here, and then it gets darker vignettes as it goes out. Oh, shoot. It just messed that up. See, it just made the border like smaller and stronger. >> That looks pretty good. We got the click. Oh, the click. See, this this looks like an AI did it, right? >> He's getting there in the last minute. It's looking much better, though. Yeah, his explosion click is not quite there. It's like a solid circle, but I saw his hover interaction. Those are looking really good. >> Like 20%. It still looks like This is such a crappy AI design. There should be a ([View Highlight](https://read.readwise.io/read/01m3cajwrmnkbvprpm3zb0a1ht)) - Note: [H2] Senior developers prompt more than they plan to - Tags: atom/literature/h2 - [00:18:48] slight vignette toward the outside starting from the top middle. This is sort of what I've been trying to accomplish with the shadow on the outside. Look at the original frames. It needs to have a bit of a shadow specifically across the bottom of the button and in the corners. The lightest spot should be the top middle. The box shadow also needs to be inset. The ring is too defined. It needs to have a glow inward and outward. 23 seconds. Boom, boom, boom, boom. See, this is Yeah, this is iteration hell. Like, I did say make it stronger, and this is what CJ's talking about how like my vocabulary might not match up to what a developer is looking for. And I think Claude is looking for what a developer [00:19:29] would say here. I I said earlier embossed and I think it's adding that. There we go. Okay, that's way better. Okay. >> You know what? I also didn't do this glow. when you hover over top of the glow, it's like it's making the >> and more saturation on the whole thing behind it brighter. So, what I'm going to do is let's go back to our >> more saturation >> and maybe we could pop a mix >> blend mode pretty close to time here. Oh, CJ's waving mode. >> I got that last prompt in. We're good. >> Oh, time's up. Time [laughter] is up. >> How are you feeling after those brutal 20 minutes? >> That was not enough time. [laughter] And it it just goes to show the difference in UI of like I I prompted way more than ([View Highlight](https://read.readwise.io/read/01m3cak2ec5p2ajv2gx20akbmz)) - Note: [H4] Prompters stall on missing developer vocabulary - Tags: atom/literature/h3 - [00:25:59] through. But I almost think that there shouldn't even be white. It's almost like you need the base layer with all of its colors and then the top layer it just becomes see-through as you hover versus having like a white circle where your mouse is. But yeah, I I love the animation when your mouse goes off. But I I think I would I would give Randy a four out of five. So he beat you by.5 here on this one. But the vibe coders prevail. >> Can we look at a couple things here? Which is Ry's background. >> Yeah. Oh, the code >> is literally 660 itallic tags. Is that weird? >> Yes. With inline and I'm I'm just I'm running a frames per second meter on here. Five frames a second it's rendering at. It's really good though. [00:26:42] I'm going to say like you use Fable for this. >> Fable 5.1. Yep. >> Yeah man. The day that it's going to be implement interfaces this close like I think we're there man. Like that is very very good. And like I could take this and then be like hey don't use 660 italic tags. Yeah. >> So, Randy, can you do slash usage? How much did that cost you? >> That cost me $745 [laughter] >> for a button. >> It's a nice button, though. >> I've certainly been paid more than $7 to make a button in my career, though. [laughter] >> True. ([View Highlight](https://read.readwise.io/read/01m3cajzm29042t8ncg5svzyg7)) - Note: [H3] Aesthetic scores hide paint-cost failures - Tags: atom/literature/h3