HN Debrief

RIP software hackathons. Long live the hardware hackathon

  • AI
  • Hardware
  • Programming
  • Developer Tools
  • Open Source

The post says software hackathons no longer test software skill in any meaningful way because AI can spit out passable prototypes fast enough that the winner is often whoever tells the best story, not whoever hacked the hardest. It argues hardware still resists this because physical constraints are harder to fake, so building with electronics, sensors, or custom enclosures keeps the event grounded in actual making.

If you run hackathons, change the format before blaming AI alone: score code and build quality, ban prebuilt entries, or drop prizes entirely if you want actual making instead of slideware. If you join them, treat most corporate events as recruiting, branding, or idea-harvesting exercises unless the rules clearly reward real technical work.

Discussion mood

Mostly cynical and nostalgic. People are fed up with hackathons that reward polish, pitching, and sponsor goals over real building, and many think corporate events in particular became exploitative long before AI. The upbeat notes came from people who still love hands-on hardware and from those who see hackathons as useful practice for storytelling or a good way to get beginners into making things.

Key insights

  1. 01

    Competition broke the original format

    What people miss is the older meaning of a hackathon as a collaborative sprint, not a judged contest. OpenBSD-style gatherings, open source dev sprints, and community events like g0v were held up as the healthier model because they optimize for shared progress instead of sponsor-friendly winners and polished pitches.

    If you want the event to produce real work, remove or downplay ranking and prizes. A showcase at the end can still give teams a deadline without turning the whole thing into demo theater.

      Attribution:
    • asveikau #1
    • yardie #1
    • pdntspa #1
  2. 02

    Corporate hackathons often extract free product work

    The harshest reading of company-sponsored hackathons is that they are a cheap pipeline for ideas, prototypes, and internal visibility. Teams do speculative work under the banner of fun, then management tries to push the rough prototype into production or absorbs the idea without meaningful credit, pay, or control for the people who built it.

    Treat internal or sponsor-backed hackathons like any other labor arrangement. Clarify ownership, follow-on expectations, and who gets time and budget to turn a prototype into a real product before you sign up.

      Attribution:
    • biglyburrito #1
    • hilariously #1
    • moffkalast #1
    • christoph #1
  3. 03

    Judging criteria decide what gets built

    Presentation-first outcomes were framed as a design bug, not an inevitability. When organizers use nontechnical judges, vague notions of impact, or no code review, teams rationally optimize for slick interfaces and clean stories. Unless organizers actively balance technical and product perspectives, every event drifts toward mockups that feel finished enough to win.

    Publish scoring rules that reward the thing you actually want. If technical depth matters, require code walkthroughs, build logs, or live demos that cannot be faked with canned screens.

      Attribution:
    • odo1242 #1
    • hobofan #1
    • jayd16 #1
  4. 04

    Hardware wins because it feels real

    The strongest case for hardware was emotional as much as technical. Holding a device in your hands, seeing sensors or motors respond, or designing a PCB gives beginners and experienced builders a much clearer sense that something was actually made. That tangibility also makes projects easier to demo and less dependent on storytelling tricks.

    If your goal is engagement, education, or recruiting new builders, physical projects may outperform pure software even when they are simpler technically. Budget for parts, tools, and fast iteration loops, not just cloud credits.

      Attribution:
    • zachlatta #1
    • croshan #1
    • ElijahLynn #1
  5. 05

    Pitching is a real skill hackathons can train

    One commenter embraced the format precisely because it exposed a weakness. Compressing a project into a compelling story for strangers is hard, especially when you are buried in implementation details and have lost sight of the user's starting point. That makes modern hackathons useful practice for product communication, even if they are poor tests of engineering depth.

    If you attend one of these events, be explicit about the skill you are trying to sharpen. A pitch-first hackathon can still be worth it if your goal is storytelling, product framing, or executive communication rather than pure building.

      Attribution:
    • kristopolous #1
  6. 06

    Fast hardware iteration changes the event economics

    Practical constraints came up fast. Real hardware is gated by parts on hand, shipping times, and PCB lead times, which is why many so-called hardware hackathons rely on Arduino, Raspberry Pi, perfboard, sensors, and hacked consumer gear. The Shenzhen example mattered because same-day turnaround and dense supply chains make a much wider range of physical projects feasible inside a week.

    If you want serious hardware output, location and logistics matter as much as talent. Stock common components in advance or run the event near fabrication and supply infrastructure instead of assuming teams can improvise around missing parts.

      Attribution:
    • helsinkiandrew #1
    • sambaumann #1
    • amelius #1

Against the grain

  1. 01

    Results matter more than visible effort

    The cleanest pushback was that if a few Markdown files or prompts solve the problem, then complaining that it did not look like hard engineering misses the point. Users care that the tree moved out of the road, not whether the solution involved solder fumes or an all-nighter.

    Do not confuse difficulty with value when you judge projects. If the event is meant to reward usefulness, score outcomes directly and accept that some winning work may look deceptively simple.

      Attribution:
    • klustregrif #1
  2. 02

    Software hackathons could survive by banning LLMs

    Some people rejected the idea that software hackathons are obsolete and argued the fix is straightforward. If the point is to test what participants can build under time pressure, then prohibiting LLMs restores the challenge, the learning value, and the portfolio value without needing to switch mediums entirely.

    If you care about individual software skill development, run an explicitly no-LLM event and enforce it socially or technically. That gives participants a reason to show up for craft rather than prompt leverage.

      Attribution:
    • feverzsj #1
    • Silamoth #1
  3. 03

    AI may make software hackathons better

    The pro-AI minority argued that previous software hackathons were already dominated by fake polish and shallow demos, while AI can now let teams explore ideas much more deeply in the same fixed time. In that framing, the point is not to admire the robot but to see how far a team can shape a concept into something users can actually try.

    If you lean into AI, redesign the event around ambition and validation instead of raw implementation effort. Ask teams to prove user value, reliability, or novelty rather than pretending hand-written code volume is still the scarce resource.

      Attribution:
    • esikich #1
    • s4i #1
    • fluffybucktsnek #1
  4. 04

    Much of this so-called hardware is still software

    Several commenters were unconvinced by the software-versus-hardware split because the examples relied on Raspberry Pi boards, microcontrollers, and existing modules. Wiring peripherals to a commodity board can be great fun, but it does not automatically create a different category of difficulty or prove that hardware is somehow purer than software.

    Be precise about what kind of making you want to encourage. If the goal is embedded systems, robotics, or physical computing, say that directly instead of using "hardware" as a catch-all badge of authenticity.

      Attribution:
    • killerstorm #1
    • sublinear #1

In plain english

AI
Artificial intelligence, software systems that perform tasks such as generating text, code, images, or decisions.
Arduino
A popular microcontroller platform used for learning electronics and building small hardware projects.
Bootstrap
A popular front-end toolkit for quickly building web page layouts and styles.
g0v
A Taiwanese civic tech community that organizes collaborative projects, often focused on public-interest software and open data.
OpenBSD
A free and open source Unix-like operating system known for security-focused engineering.
PCB
Printed circuit board, the board that electrically connects and physically supports electronic components.
Raspberry Pi
A low-cost single-board computer often used for education, prototyping, and embedded projects.
VC
Venture capital, investment money provided to startups in exchange for ownership.

Reference links

Community hardware and hackathon programs

  • Hack Club event video at GitHub HQ
    Shared as an example of teenagers building electronics and PCBs in a hands-on hackathon setting.
  • Hack Club Fallout
    Linked as an upcoming week-long hardware hackathon in Shenzhen built around fast PCB iteration.
  • g0v Taiwan YouTube channel
    Offered as a living example of collaborative no-judging hackathons where projects continue over time.
  • Jugend hackt
    Mentioned as a program for kids in Germany who want to get into hacking and building.

Project examples and technical references

  • Electronic banjo
    One of the hardware hackathon projects cited as memorable and tangible.
  • Spin to Win
    Another hardware hackathon project shared to show the appeal of physical builds.
  • Rigol DHO824 MCP GitHub repo
    Used to argue that AI-assisted tooling can already inspect hardware measurements like oscilloscope traces.