GPT 5.5 turned a single prompt into a 50 line custom HTML element, a small browser native viewer that takes a GitHub blob URL and renders the requested lines with numbers and no syntax highlighting.
GPT-5.5 turned a single natural-language prompt into a working, dependency-free Web Component: a custom HTML element that takes a GitHub file URL, fetches the raw source, and renders a numbered line-range excerpt inside any web page. The result is roughly 50 lines of JavaScript, published under [Simon Willison's tools repository](https://github.com/simonw/tools).
The component, github-code, sits in the same browser-native family as the built-in <video> and <details> tags: a single custom tag that does one job and styles itself. Authors write <github-code href="github.com/owner/repo/blob/SHA/file.py#L9-L18" />; the element parses the GitHub blob URL, rewrites it to the matching raw.githubusercontent.com file, fetches the bytes, and renders the requested line range inside the tag with line numbers printed beside each line. There is no syntax highlighting by design. The live demo at tools.simonwillison.net/github-code-component shows the element rendering a ten-line excerpt of a Python parser.
Passing the artifact test required three things at once. A Web Component in the browser is a JavaScript class that registers a custom tag and decides how that tag updates when its attributes change. To get from prompt to working element, the model had to know that GitHub blob URLs map to raw.githubusercontent.com raw files by swapping the host and dropping the blob/ segment, that browsers expose [customElements.define](https://developer.mozilla.org/en-US/docs/Web/API/Web_components) for registering tags, and that the Shadow DOM lets a tag style its own contents without leaking CSS to the host page. All three are visible in the component's source.
What Willison's prompt gist asks for reads as a tight spec rather than a wish list: a single GitHub URL input, a line range parsed from the URL fragment, a fetch against the raw file, and a numbered listing with no syntax coloring. The published element handles cases the prompt does not enumerate, a sign the model carried behavior choices beyond the literal spec.
A 50-line UI primitive is well within what large language models can produce end-to-end, so the single-prompt result tells the reader something about prompt ergonomics and about how small the Web Components API surface has become. It is not, on its own, evidence that general coding capability has moved. Components at this scale are plausible test cases for prompt-engineering experiments because they have few moving parts, a stable browser API to talk to, and an easy visual check. Larger components, anything that holds multi-file state, runs asynchronous user flows, or ships production-grade error reporting, are where the test gets harder.
github-code does not include the surrounding lines that GitHub's own paste-as-embed views render, does not link the rendered excerpt back to the source file on github.com, and does not preserve wrapping or indentation settings. It is a viewer, not a replacement for a syntax-highlighting library. The project page is explicit about that scope. It is also a single-author artifact: no independent third party has yet run the same prompt through the same model to see whether the output is reproducible.
What to watch next is whether other small front-end artifacts get built the same way and shipped as live, single-file components. Willison's project page flags adjacent July 2026 work in the same pattern, including a sqlite-utils 4.0 release and a separate SQLite AST library. If a second independent team publishes a working, prompt-only Web Component on the first try, the case for single-prompt front-end generation moves from tile to trend without anyone having to announce it.