nichoth nichoth

Verification-Driven Development (VDD)

Methodology: Iterative Adversarial Refinement

Overview

Verification-Driven Development (VDD) is a high-integrity software engineering framework designed to eliminate "code slop" and logic gaps through a generative adversarial loop. Unlike traditional development cycles that rely on passive code reviews, VDD utilizes a specialized multi-model orchestration where a Builder AI and an Adversarial AI are placed in a high-friction feedback loop, mediated by a human developer and a granular tracking system.

I. The VDD Toolchain

This week, I wrote about using the CSS @import rule to modularize CSS, and some performance challenges with that approach.

tl;dr: the issue isn't the @import rule itself, but that files under 1kb often end up the same size or even bigger when gzipped, so you get no compression benefits.

I ran a few additional tests, and wanted to share the data I found.

Current Setup

40 modular CSS files
All imported from a single kelp.css file hosted on JSDelivr

FFlate is the fastest, smallest, and most effective JavaScript compressor/decompressor currently; to create it, I used a variety of modified or optimized algorithms.

Part 1: The DEFLATE spec

The core of most popular compressed file formats is DEFLATE, or RFC1951. GZIP data, Zlib data, .zip files, PNG images, and more all use some variant of DEFLATE under the hood. At its core, the DEFLATE format is actually not too complex: it's merely a combination of Huffman coding and LZ77 compression.

If you don't understand either of these concepts, feel free to read the following subsections, or skip to Part 2 if you already know what these are and just want to get to implementation details.

Section I: Huffman Coding

Computers think of basically everything as numbers. The smallest unit of information in a computer is a single bit, which can only be either a 0 or a 1. When multiple bits are stringed together, they can be interpreted as a ba

	# Conformance suites: what they are, when they help, how to build one

	A conformance suite is a third axis of testing — distinct from unit tests
	and integration tests. Where unit tests prove that a function does what
	its body says, and integration tests prove that subsystems compose, a
	conformance suite proves that **what the public API claims it does
	matches what it actually does, against an external ground truth**.

	This document explains the pattern, when it earns its keep, and how to
	set one up. The case study is ferrotorch (a pure-Rust PyTorch

	<!DOCTYPE html>
	<html>
	<head>
	<meta charset="utf-8" />
	<title>Automerge (Vanilla JS, Unbundled) Demo</title>
	<meta name="viewport" content="width=device-width, initial-scale=1" />
	</head>
	<body>
	<script type="module">
	// The ?bundle-deps here is very dodgy...

	<!DOCTYPE html>
	<html lang="en">
	<head>
	<meta charset="UTF-8">
	<meta name="viewport" content="width=device-width, initial-scale=1">
	<title>Signals</title>
	</head>
	<body>
	<button id="decrement">
	-

	accordion-group {
	background-color: #f7f7f7;
	border-radius: 0.25em;
	display: block;
	margin-block-end: 1.5em;
	padding: 0.5em 1em;
	width: 100%;
	}

	accordion-group [accordion-trigger] {

	import Database from 'better-sqlite3';
	import { createDatabaseClient } from './proxy.ts';

	// 1) Create an in-memory DB and your table(s).
	const db = new Database(':memory:');
	db.exec(`
	CREATE TABLE users (
	id TEXT PRIMARY KEY,
	data JSON
	);

	var client = window.client = new WebTorrent({
	tracker: {
	rtcConfig: rtcConfig
	}
	})
	client.on('warning', onWarning)
	client.on('error', onError)

	torrent = client.add(TORRENT, onTorrent)

	async function forceSync(account: Account) {
	const { syncManager } = account._raw.core.node;

	const peer = Object.values(syncManager.peers)[0];
	if (!peer) {
	throw new Error("no peer");
	}

	const values = Object.values(account._raw.core.node.coValues).flatMap((x) => {
	if ("coValue" in x.state) {