Why a passing npm build doesn't prove AI-generated frontend code works

·4 views

The author argues that AI coding agents can make a build succeed while still shipping frontends that break in real browsers. Compilers cannot detect runtime problems such as hydration mismatches, mobile overflow, undersized touch targets, dark-mode readability issues, or silent API failures. The author also points to generic 'AI slop' design defaults that make pages look interchangeable. To address this, the author maintains open-source tools, including ghost-qa, which runs headless Chromium against a dev server across multiple viewports and color schemes. The tool checks for runtime, layout, accessibility, performance, and SEO issues and produces a scored report with actionable output for agents.

Read the full story at DEV Community

This is an AI-generated summary. ShortSingh links to the original source for the complete article.

Discussion (0)

Developer builds 87,094-line C++ GUI toolkit with no third-party dependencies

A developer has released Zekit, a self-contained C++20 desktop GUI toolkit for Windows and Linux that bundles window creation, the message loop, GPU rendering, widgets, layout, text, and IME into one static library. Its 87,094 lines of code render through three backends on Windows (D3D12, Vulkan, OpenGL) and two on Linux (EGL OpenGL, Vulkan), with X11 supported but Wayland not yet. The author reports that fewer than 7% of the code touches the GPU, with most effort going into widgets, layout, and platform-specific window and input handling. macOS, iOS, Android, and HarmonyOS source exists in the tree but is not offered as a working target. The project is MIT licensed.

0 comments Read more at DEV Community

ProgrammingDEV Community ·

What a Marketing Mix Model Is and Whether Your Team Needs One

Marketing teams facing budget questions often find that last-touch reports and self-reported surveys cannot show which spending actually works. A marketing mix model answers this by using weekly spend per channel and outcomes such as sign-ups, splitting results into a baseline and the portion driven by media. The method works from aggregated totals rather than individual users, so it needs no personal data and can weigh offline channels alongside online ones. It is typically built on around three years of weekly history, and open-source tools from Google and PyMC Labs have lowered the software cost. The article argues that AI-assistant influence, which has no spend line, will need separate measurement.

0 comments Read more at DEV Community

ProgrammingDEV Community ·

Author Logs 10,926 Sites Hunting Free Backlinks; Only 15 Links Stay Live

Between 20 October and 12 November 2026, a developer trying to earn free backlinks for a small B2B software site kept a log of 10,926 candidate domains and rejected each one with a recorded reason. Only 15 domains carried a live, followed link on a publicly indexable page when re-checked on 12 November, and the most common rejection reasons were nofollow attributes, noindex tags, reciprocal-link requirements, paid-only or long-queue access, and dead sites. The author also tested a paid press release service, finding its sample links were nofollow and the page was marked noindex. Most of the surviving links came from software directories and a few came from articles the author wrote for newsletters and community blogs. The author noted that Google and Bing report different link counts and that it is not yet clear whether the remaining links will be counted.

0 comments Read more at DEV Community

ProgrammingDEV Community ·

Measuring AI-generated code: focus on team impact, not individual developers

Teams adopting AI coding tools struggle to tell whether the investment is paying off, and developers often distrust dashboards that might be used to compare them. The author argues that gut feeling is unreliable here, citing a 2025 controlled study in which experienced open-source developers were measurably slower with AI yet believed they were faster. Vendor metrics such as acceptance rates and lines of code show usage but say little about real impact. The article recommends four more telling measures, including follow-up defects after merge and review time in risky areas, collected at team level rather than per person. It also warns that per-person evaluation quickly turns metrics into a way for people to hide problems.

0 comments Read more at DEV Community