← hackathons

Hackathon field report

GPT-6 Astra Hackathon SF

Built WorldKinetics at OpenAI: a prompt-to-product workflow where Astra authors editable geometry, independent checks protect requirements, and the user approves the exact revision.

September 8, 2026 · Built WorldKinetics ·OpenAI, San Francisco · repo ↗ · live ↗
GPT-6 Astrabuild123dOpen CASCADEThree.jsTypeScriptDocker
Project breakdown WorldKinetics Product behavior, architecture, stack, screenshots, and live artifact 9 checks · exact revision

Event photos

Prototype

I built WorldKinetics at the GPT-6 Astra Hackathon SF, hosted by OpenAI and Cerebral Valley at OpenAI on September 8, 2026. The project was submitted but did not reach the five-team final.

The problem I chose

Generating a shape is not the hard part. The hard part is knowing whether the result still satisfies the physical constraints that made the original object work.

WorldKinetics started with a simple consumer problem: a cabinet handle breaks, the original part is gone, and the owner wants a replacement or a more comfortable variation without learning CAD. The product turns the request into editable geometry, checks the protected dimensions, and asks the user to approve the exact result before download.

What shipped during the day

  • A recorded Astra-authored cabinet-handle generation and refinement path.
  • A Three.js before-and-after workspace using the actual exported geometry.
  • Revision-bound requirements, checks, hashes, and approval state.
  • STEP, STL, and editable Python downloads tied to the accepted manifest.
  • A prototype package and supplier handoff that clearly separates guidance from a real quote or order.

The demonstrated handle retained its 96 mm mounting pitch, passed nine checks after refinement, and produced a reviewable curved grip with a blended thumb rest.

Toolset

  • GPT-6 Astra: reads the request and writes the editable design logic.
  • build123d and Open CASCADE: solid geometry, plus STEP and STL export.
  • TypeScript and Zod: contracts for the request, revision, evidence and approval.
  • Docker: CAD generation in bounded job directories.
  • Three.js: the before-and-after viewer, rendering the actual exported files.

What was hard

  • The CAD runtime came late. I built the experience around it before the geometry pipeline was settled, and paid for it at the end of the day.
  • Too few clean-room runs. The full path needed more repeated end-to-end runs than the clock allowed.
  • Scope pulled wide. One cabinet handle was already a lot. The live-generation path should have been narrower still.
  • Digital checks stop at the screen. Nine checks passed, but none of them prove physical fit, strength or comfort.

What I learned

  • Prompt quality is not a safety boundary. Protected interfaces and acceptance rules belong in application logic.
  • A visible model is not proof. The demo needs measurements, checks, revision identity, and the actual files behind the preview.
  • Stale evidence must fail closed. When the geometry or requirement changes, old measurements cannot remain green.
  • A bounded workflow is stronger than a universal claim. One cabinet-handle path with honest checks is more credible than pretending to solve all CAD.
  • The last mile matters. Downloads need units, source, manifests, prototype guidance, and an explicit list of what remains unverified.

What I would change next

Runtime first, experience second, and a narrower first path with time reserved for clean-room runs. I would also bring a measured physical object and close the loop with a printed prototype, because the digital checks don’t establish manufacturing readiness either.

The product architecture and evidence boundaries are documented in the linked WorldKinetics project case study.