Jacquard bets languages must audit AI code Jacquard, a new research programming language, embeds effects, uncertainty, and identity into its core so that AI-generated code can be audited without reading every line. The language enforces effect signatures, supports swappable worlds via algebraic effect handlers, and uses canonical hashing for structural identity, targeting the regime of model-written, human-reviewed agent code. AI https://sourcefeed.dev/c/ai Article Jacquard bets languages must audit AI code A research language makes effects, uncertainty, and identity first-class so reviewers don't have to read every line. Priya Nair https://sourcefeed.dev/u/priya nair Most AI coding tooling assumes the language stays the same and the review process gets smarter: better diffs, stronger tests, agent memory, sandboxing bolted on outside. Jacquard https://github.com/jbwinters/jacquard-lang takes the opposite bet. If models write most of the code, the language itself should answer what a program may touch, how uncertain its outcomes are, and whether two patches are the same thing under the hood. That is a real design problem, not a slogan. Version 0.1 is openly a research prototype, not a production language. The interesting part is which problems it put into the kernel, and which ones it leaves for later. What the language actually exposes Jacquard is a small language with a compact .jac surface, a kernel of 27 forms, an OCaml checker and CPS interpreter, a C-emitting AOT path for the .jqd carrier, a Jacquard-written standard library, and a test framework called Warp. Every form is a uniform head, meta, args triple; quoted code is ordinary data. Three properties sit in the language rather than only in comments or ops tooling: Effects in the signature. A type like text - {net} text states that the function may perform the net effect. The runtime rejects unhandled world effects unless authority is granted with --allow , including effects from dynamic code. That is language-level enforcement in a research runtime, not an OS sandbox substitute, and the project is clear about the boundary. Swappable worlds via handlers. Algebraic effects use deep, multi-shot handlers: a handler can resume a computation zero, one, or many times. The same program can run against a real network, a scripted fake, a recording, or a probability model of server behavior. Handlers answer requests to the outside world; swap the handler, leave the code alone. That is meant to replace a lot of conventional mocking at effect boundaries and turn questions like "what does the agent do if the API is down?" into ordinary tests. Finite discrete uncertainty and exact enumeration. Programs can sample weighted choices and record evidence. Enumeration lists every reachable outcome with its exact probability. A repair-style demo treats a failing test as evidence and computes which patches remain possible and how likely each is. This only works for finite discrete models; it is not general probabilistic programming for continuous mess. Canonical identity. Jacquard hashes canonical resolved structure rather than source bytes. Comments, formatting, provenance, and ordinary local or term renames are erased. Pure tests rerun only when canonical code or dependency content changes. That is structural identity for review and caching, not a proof that arbitrary programs are behaviorally equivalent. The human-facing claim is blunt: when machines write most of the code, reviewers need the language to answer "what can this touch, and how sure are we" without reading every line. Prior art, not a blank slate None of the individual ingredients is new. Algebraic effects and multi-shot handlers sit in the same family as research systems that made effects programmable rather than hard-wired. Capability-style grants echo object-capability and effect-tracking work that tried to make authority explicit. Structural hashing for identity is cousin to content-addressed builds and content-addressed stores that erase noise so caches and reviews stay stable. What Jacquard does is package those ideas for a specific regime: model-written, human-reviewed agent code. It also ships agent-oriented docs docs/SKILL.md , AGENTS.md , pins behavior with cram transcripts, corpus goldens, and release claims, and treats a failed pin as information about a change rather than something to weaken so a diff passes. That process story matters as much as the syntax if the audience is coding agents as well as people. The competing path in industry is still "keep TypeScript/Python/Go and add scaffolding": sandboxed runners, policy engines, eval harnesses, structured tool APIs, and human review UIs. Jacquard argues that without effects and identity in the language, reviewers keep reconstructing those facts from prose and memory. Industry tooling argues that rewriting the language is the expensive move and that process plus sandbox is enough for most teams. Both can be partly right. Language-level effects buy local, inspectable guarantees at the cost of ecosystem lock-in. External sandboxes buy immediate applicability at the cost of gaps between what the language allows and what the sandbox permits. What a working developer should actually do with this Treat 0.1 as a lab, not a migration target. The project documents honest limits and publishes install scripts and binaries for Linux x86-64 and macOS Intel and Apple Silicon so you can poke it without standing up OCaml: curl -fsSL https://raw.githubusercontent.com/jbwinters/jacquard-lang/jacquard-core-0.1-rc3/scripts/install.sh | sh ~/.local/bin/jac run ~/.local/share/jacquard/demos/basics/m1-fact.jac expected: 120 A release-risk case study exercises one policy under concrete and probabilistic telemetry worlds, then sampled and exhaustive Warp checks. That is the workflow worth studying: write small programs with effectful boundaries, run them under multiple handlers, and use enumeration where the state space is finite enough that exact probabilities mean something. Who it is for right now. Researchers and teams building agent runtimes who already care about effect boundaries, multi-world simulation, and review of machine-generated patches. People writing production services in mainstream languages will not rewrite those services in Jacquard this year, and the project does not pretend otherwise. What it competes with in practice. Not "Rust vs Go." It competes with the stack of mocks, feature flags, chaos tests, and policy layers that try to answer the same questions outside the language. If your pain is "agents keep inventing side effects we only catch in prod," the effect signatures and --allow grants are the part to steal conceptually, even if you stay on another language. If your pain is "reviewers can't tell whether two model patches are the same," structural identity is the idea to watch, alongside content-addressed build systems you may already use. Trade-offs. Exact enumeration only covers finite discrete models; continuous or open-world behavior still needs other tools. Capability grants in a research runtime are not a full sandbox. Structural identity erases formatting and renames by design, which helps caching and review noise but will not magically prove behavioral equivalence. The surface and kernel are small on purpose; ecosystem libraries, interop, and production ops story are not the point of 0.1. If it pans out. Worth attention when 1 your agents emit code that must declare effects at the boundary, 2 you need multi-world simulation without rewriting mocks every week, and 3 you want identity that survives cosmetic model churn. Even if Jacquard itself stays a research vehicle, those three requirements will keep showing up in agent platforms. Languages that ignore them force the burden onto reviewers and external harnesses forever. The judgment call Jacquard is a genuine shift in framing , not yet a production-ready shift in practice . The thesis that AI-era review needs effects, uncertainty, and identity in the language is defensible and well-aligned with how agents actually fail: silent side effects, brittle mocks, and noisy diffs. The implementation is early, scoped, and honest about limits. Winners if the ideas travel: teams that design agent runtimes and languages with effect-aware APIs and content-stable identity. Losers if they ignore the problem: review processes that treat model output like junior human PRs with better autocomplete, and languages that leave capability and uncertainty entirely to comments and ops. You do not need to adopt Jacquard tomorrow. You do need a story for what an AI-written function may touch, how you simulate failure worlds, and when two generated patches are the same artifact. Jacquard is one coherent attempt to put that story in the language. Most of the industry is still hoping tooling alone will be enough. Sources & further reading - Show HN: Jacquard, a programming language for AI-written, human-reviewed code https://github.com/jbwinters/jacquard-lang — github.com - hckr news - Hacker News sorted by time https://hckrnews.com/ — hckrnews.com - HN: A Fast Hacker News Client https://hn.blode.co/ — hn.blode.co - Scoring Show HN submissions for AI design patterns https://www.adriankrebs.ch/blog/design-slop/ — adriankrebs.ch Developer Tools https://sourcefeed.dev/topic/developer-tools Code Review https://sourcefeed.dev/topic/code-review Programming Languages https://sourcefeed.dev/topic/programming-languages Jacquard https://sourcefeed.dev/topic/jacquard Ai Code Generation https://sourcefeed.dev/topic/ai-code-generation Algebraic Effects https://sourcefeed.dev/topic/algebraic-effects Priya Nair https://sourcefeed.dev/u/priya nair · AI & Developer Experience Writer Priya covers AI frameworks, developer productivity tooling, and the startup ecosystem across South and Southeast Asia, bringing a researcher's rigour and a practitioner's empathy to every story. She is deeply sceptical of benchmarks and asks hard questions so her readers don't have to. Discussion 0 No comments yet Be the first to weigh in.