Verdict: The agent produced a convincing, useful interactive in one directed pilot, but the strongest result was not the first render. It was the combination of a clear brief, inspectable mechanics, browser testing, and several concrete fixes before delivery. The finished exhibit is good enough to publish as a Kingy AI Lab when it is presented as a kinematic teaching model—not an engineering simulation.
Evidence status: Kingy-tested Production candidate and hosted preview tested 7 September 2026 Chrome 152 on macOS
The assignment
I gave an AI coding agent a production brief for “Inside the Machine”: an explorable cutaway of a traditional cross-plane V8. The app had to show eight pistons, four shared crank journals, a cam turning at half crank speed, sixteen valves, and the 1–8–4–3–6–5–7–2 firing order. Every moving part and the linked two-dimensional diagram had to come from one crank-angle state.
The interface also needed real controls: pause and play, a 0–720° scrubber, cylinder selection, assembled, section and exploded views, and an 18-second guided tour. Desktop and phone layouts had to work. The output had to remain editable and include screenshots, a video, a static GLB export, source notes, and verification records.
This was an original Kingy pilot inspired by public examples. It was not an attempt to recover another creator’s private prompt. You can inspect the directed build brief and the full dispatch prompt.
What the agent delivered
The finished web app uses React and Three.js. The geometry is procedural, so the pistons, connecting rods, crankshaft, cam, pushrods, rockers and valves can be inspected and changed in source rather than being baked into a video.
| Deliverable | Observed result |
|---|---|
| Interactive exhibit | Three working inspection views, eight selectable cylinders, playback and 0–720° scrubbing |
| Guided sequence | 18 seconds, five chapters, deterministic timeline |
| Responsive interface | Tested at 1440×1000, 390×844 and 360×844 browser viewports |
| Video export | H.264, 1440×1000, 30 fps, 540 frames, 18.000 seconds |
| 3D export | Static GLB section pose with 308 meshes and 337 nodes |
| Editable project | Source, exact package lock, tests, local run instructions and third-party notices |
The complete authoring and verification run took 32 minutes and 28 seconds. That includes research, implementation, debugging, builds, browser checks, captures and packaging. The final production build itself took 4.96 seconds in the original run. Those times describe this machine and this assignment; they are not a general coding-agent benchmark.
What the tests actually prove
The visual result looks plausible, but a clean render does not prove that linked parts agree. The verification therefore checked both the mathematical helper and the rendered Three.js world transforms.
Kingy-tested: Four numerical test groups passed. The helper swept all eight cylinders from 0° through 720° in 0.5° increments: 11,528 cylinder-angle cases. The tests checked firing order and 90° spacing, rod length, piston axes, the shared crankpin orbit, valve windows, the piston’s 360° repetition, the full cycle’s 720° repetition, half-speed cam motion, and the guided-tour boundaries.
Kingy-tested: The rendered objects were sampled at twelve crank angles, including 37° and the cycle boundaries. The maximum connecting-rod length error was 8.88×10−16 normalized units. The maximum crank-journal X/Y mismatch was 2.05×10−15. Piston-to-rod wrist-pin mismatch was zero. Valve-axis drift was 4.45×10−16, and pushrod-length error was 8.87×10−10 normalized units.
These very small errors show that the implemented rigid-link relationships stay internally consistent within floating-point precision. They do not establish real dimensions, pressure, temperature, torque, balance, wear, contact stress or combustion performance.
The first render was not the finished result
The useful part of this case study is what failed before delivery.
- The valves moved sideways. The first rocker implementation attached a valve stem directly to a moving rocker tip. That made the stem drift out of its guide. The corrected version keeps each stem on a fixed axis and uses a sliding contact pad at the rocker tip.
- The phone diagram was unreadable. Shrinking the desktop diagram also shrank its labels and clipped the mechanism. The phone layout now uses a dedicated cropped graphic and a separate normal-size valve-status line.
- The assembled engine exposed the valve train. The rocker-cover dimensions were adjusted so the assembled view actually contains the visible mechanism.
- The exploded view crowded the frame. The camera field of view now expands with housing separation.
- One screenshot caught the wrong tab state. The capture helper was taking the image before the selected tab had visually settled. It now waits for the selected state before capture.
These were implementation and presentation defects, not preference changes. Catching them required tests and visual inspection that the initial code generation could not replace.
How the public candidate differs from the frozen pilot
The initial candidate is preserved as a byte-identical ZIP with a recorded SHA-256 checksum. The release candidate keeps its mechanism and interaction design, then adds the Kingy AI Lab identity, a direct Apps & Labs route, a fuller build disclosure, an evidence summary, and a link back to this case study.
The dependency graph was also upgraded before release review. The frozen pilot’s npm audit reported 11 advisories: eight high, two moderate and one low, concentrated in the React server, image, build and Cloudflare development toolchain. The candidate now installs with zero known npm advisories after compatible upgrades to React, Vinext, Vite and Cloudflare tooling. Mechanics tests, source lint and the production build still pass after that migration.
No advisory was waived. “Zero known” means the current npm advisory database returned no findings for the locked dependency graph at the review time; it is not a permanent security guarantee.
What remains unverified
The prompt requested GPT-6 Astra at Ultra effort. The task runtime did not expose authoritative per-run model, effort or speed telemetry, so this article does not present those requested settings as verified execution facts. Per-task token use and dollar cost were also unavailable. Shared account-usage snapshots were confounded by other work and are excluded from any cost claim.
The app is a schematic kinematic model. Its display dimensions are normalized. Valve timing uses ideal 180° windows. Cam-lobe and tappet contact are illustrative, the timing chain is a static envelope, and many passages, fasteners and accessories are omitted. The colored chamber indicates the named stroke; it does not show simulated pressure or temperature.
Phone checks used responsive Chrome viewports rather than physical devices. WebGL 2 is required. The test did not cover Safari, Firefox, older GPUs, assistive-technology combinations, real engine hardware, or physical manufacturing tolerances.
Why this is a useful AI-build case study
The result supports a narrower claim than “AI can build anything.” A coding agent can turn a well-bounded visual-mechanical brief into a substantial interactive prototype quickly when the project gives it:
- one source of truth for state;
- equations and coordinate conventions it can test;
- explicit controls and responsive acceptance criteria;
- permission to inspect and repair material defects; and
- a publication gate that separates a working local result from a live release.
That matches the practical sequence in Kingy’s Build With AI Academy: choose a useful project, define the build, test it, and ship with staging and rollback. The interesting evidence is not that the agent generated a polished screen. It is that the same build left behind source, reproducible checks, known limits, and a release candidate that can be reviewed before it touches production.
FAQ
Did the AI build the whole interactive?
The directed pilot was produced through an AI coding-agent workflow, including research, implementation, automated checks, browser inspection, exports and packaging. A human supplied the assignment and publication decision. The runtime did not expose verified model or effort telemetry.
Is the V8 mechanically accurate?
It is internally consistent for the tested ideal rigid-link relationships and firing schedule. It is not a calibrated Chevrolet replica or a thermodynamic, structural or manufacturing simulation.
Can I use the 3D model in CAD?
The included GLB is a static visual export of the section pose. It has no animation or engineering tolerances and should not be treated as CAD validation.
Why publish the app separately from the article?
The interactive is a static WebGL application with its own asset bundle. Keeping it on an isolated lab origin prevents its runtime and styles from interfering with the WordPress editorial site while the article remains the canonical evidence record.
Sources and evidence
- Official source: General Motors, 1961 Chevrolet Corvette specifications. Supports the 90° V8/OHV configuration, bank numbering and 1–8–4–3–6–5–7–2 firing order. Reviewed 7 September 2026.
- Official source: NASA Glenn, Four-Stroke Internal Combustion Engine. Supports the four-stroke sequence and the two-to-one crank-to-cam relationship. Reviewed 7 September 2026.
- Kingy-tested: Download the evidence package. Contains the frozen prompt and brief, test records, browser QA, dependency audits, screenshots, video metadata, source notes and checksums.
- Method: Kingy AI Research Methodology. Explains the evidence labels and publication gate used here.
Editorial disclosure: This is an independent Kingy AI build case study. No vendor sponsored the assignment, supplied access, paid for inclusion, or approved the verdict. No paid generation service, credit purchase or usage reset was used. AI tools assisted the build and drafting process; Curtis Pyke remains responsible for the final claims, links, disclosures and publication decision.