Project ideas from Hacker News discussions.

Bend – A language that blocks AI mistakes via proof, on CPU and GPU

📝 Discussion Summary (Click to expand)

1. Trust and transparency (commit history)
Many commenters reacted strongly to the repository being squashed to a single commit, seeing it as a red flag for reproducibility and openness.
- AlexErrant: “Erm, because it looks weird? Do you know any other language projects that squash their repos down to 1 commit? That's a destruction of trust, which is kinda important if you want people to build on your language.”
- LightMachine admitted the move was to hide personal data and “AI slop,” later restoring the history after feedback.
- NortySpock noted that a single commit makes it impossible to gauge the project’s age, update frequency, or community size.

2. AI involvement and hype (“vibe‑coding”)
The discussion repeatedly questioned how much of Bend was produced by large language models versus hand‑crafted work, and whether the project’s claims were overstated.
- boxed called the compiler “a single typescript file 6k characters long of AI slop. Jesus.”
- AlexErrant warned that “nuking your history is one hell of a way to raise eyebrows” in an era where AI trust matters.
- LightMachine conceded: “Yes, there's a lot of vibe‑coding in many places, but the critical parts (compiler, runtime, kernel) are human designed.”
- stschaef remarked, “I'm glad you're having fun vibecoding…”, highlighting the skepticism around AI‑generated documentation and papers.

3. Technical claims (GPU parallelism, proof checking, performance)
Debates centered on whether Bend truly delivers on its promises of GPU‑accelerated proof checking and competitive speed.
- LightMachine explained: “we implemented a complete allocator, garbage‑collector, closure evaluator and functional evaluator, on the GPU (with zero interaction net overhead this time).”
- stschaef questioned: “How does this benefit from GPU parallelism? … these tasks aren't amenable to running on a GPU.”
- LightMachine replied that GPU proof checking would come later “when we implement Bend in itself.”
- ModernMech stressed that destroying history makes it hard to reproduce the benchmark SHAs cited in the paper.

4. Practical usability of “laws” and specification burden
Several users illustrated how underspecified laws can lead the AI to find loopholes, questioning the approach’s scalability.
- pdpi observed: “having only the one single 'you can't win' law is severely underspecified… writing the laws becomes a bigger problem than writing the code itself.”
- holden_nelson showed the AI making the flag “unenterable” by adding a force field after being told to keep walls away.
- LightMachine agreed: “'you can't win' is grossly under‑specified… they only protect what you remember to write.”
- The exchange highlighted the tension between lightweight specifications and the need for precise, maintainable laws.


🚀 Project Ideas

LawMine

Summary

  • Automatically extracts invariant-like "laws" from existing codebases, unit tests, and property-based tests to reduce the manual burden of writing Bend specifications.
  • Core value proposition: Turns your test suite into a starting point for formal verification, making Bend adoption frictionless for teams already invested in testing.

Details

Key Value
Target Audience Bend early adopters, teams using property-based testing or heavy unit test suites
Core Feature Scans code/tests, infers candidate laws (e.g., range checks, idempotency, ordering constraints) and outputs them as Bend‑compatible .bend law files
Tech Stack Rust (for fast AST parsing), Tree-sitter, optional integration with Hypothesis/QuickCheck parsers
Difficulty Medium
Monetization Hobby

Notes

  • HN commenters complained that "writing the laws becomes a bigger problem than writing the code itself" and wished for automated discovery; LawMine directly addresses that pain.
  • Could spark discussion on what makes a good law vs. an over‑specified invariant, and serve as a practical bridge between test‑driven development and proof‑assisted development.

BendLaw Registry

Summary

  • A centralized, version‑controlled repository of reusable Bend laws (stdlib‑style) covering common domains such as data structures, arithmetic, and concurrency patterns.
  • Core value proposition: Eliminates repetitive law writing by providing a “mathlib” for Bend, letting projects depend on proven, community‑vetted specifications.

Details

Key Value
Target Audience Bend library authors, application developers who want to reuse verified properties
Core Feature Searchable catalog of laws with semantic versioning, changelogs, and one‑click import into a Bend project (via bend add law <name>@<version>)
Tech Stack PostgreSQL for metadata, Git‑LFS for law files, Go backend, React frontend
Difficulty Medium
Monetization Revenue-ready: Sponsored tiers for private law collections ($10/mo per org)

Notes

  • Commenters lamented the lack of a standard library and the need to reprove basic facts; a registry would provide the “mathlib” they requested.
  • Enables discussion around law quality, provenance, and the evolution of verified building blocks—topics that resonated with the academic‑leaning HN audience.

BendProof IDE Extension

Summary

  • VS Code (and JetBrains) extension that shows real‑time proof status, highlights which laws are being checked, and offers quick‑fix suggestions when a law is violated during AI‑assisted coding.
  • Core value proposition: Gives developers immediate feedback on whether their AI‑generated code satisfies the declared laws, turning abstract proof checks into an actionable IDE experience.

Details

Key Value
Target Audience Developers using Bend with AI code assistants (Copilot, Cursor, etc.)
Core Feature Inline diagnostics: green check when a law holds, red underline with explanation when it fails, plus a “suggest law” button that proposes a missing invariant based on the current function signature
Tech Stack TypeScript/VS Code API, communicates with Bend compiler via language server protocol (LSP)
Difficulty High
Monetization Hobby

Notes

  • HN users pointed out that the demo’s AI could “creatively satisfy” underspecified laws; the extension would make those mismatches visible instantly.
  • Provides a tangible tool for the “vibecoding” workflow discussed, likely to generate discussion on how IDEs can better integrate formal verification.

GitSanitizer

Summary

  • CLI tool that scans a Git repository for sensitive data (API keys, personal info, proprietary code) and automatically rewrites history to produce a clean, public‑safe copy—allowing projects to retain full commit transparency without leaking private material.
  • Core value proposition: Solves the trust‑vs‑privacy dilemma that led Bend to squash its history, enabling auditable repos while protecting confidential assets.

Details

Key Value
Target Audience Open‑source maintainers who need to share history but contain secrets (e.g., API tokens, internal algorithms)
Core Feature Regex‑based and entropy‑based detection, interactive review mode, generates a new branch with redacted history and a mapping file for audit
Tech Stack Rust (for speed), git2‑rs, clap for CLI, optional web UI for review
Difficulty Medium
Monetization Hobby

Notes

  • Many commenters expressed frustration over the missing commit history making it hard to verify builds or trust the project; GitSanitizer lets keep that history safely.
  • Would likely be welcomed on HN as a practical solution to a common open‑source dilemma, sparking conversation about responsible history sharing.

Read Later