Code415 Radar

Key ideas

Coding harness

The program around a language model that sends prompts, runs tools like the shell, applies edits and asks for permission.

Headless engine

The agent loop runs without a window on a server or in the background, and a separate GUI connects to it to watch and steer.

Operation deadline

Every wait has a timeout, so a stuck prompt or command never blocks a long agent run forever.

Steps

1. Read the nullprogram post of 2026-10-31 announcing Prospero, focusing on the sections about deadlines and permissions.
2. Open the GitHub README and docs/configuration.md to see how endpoints, models and roles are declared in prospero.ini.
3. Skim docs/remote.md to understand how the engine runs over SSH or in the background after the window closes.
4. Compare these choices with the harness you already use: where does it wait on you, and what does it do when a command hangs?
5. Self check: why does Wellons say permissions are not a security boundary, and what does he recommend instead?

Steps

1. Clone skeeto/prospero and build it with cmake -B build followed by cmake --build build, which fetches pinned dependencies at configure time.
2. Start an OpenAI compatible server locally, for example llama.cpp's server with a small instruct model, or set an API key in an environment variable.
3. Edit ~/.config/prospero/prospero.ini following docs/configuration.md: add an endpoint section with its url and a key such as key = env:ANTHROPIC_API_KEY, then set the default model.
4. Inside a throwaway Git repo or a container, run prospero . to start a session rooted in that directory.
5. Ask the agent to fix a small failing test, then give it a command that sleeps longer than the timeout and watch it become a background task.
6. Leave a permission prompt unanswered and confirm it is denied when the deadline passes.

Small angles to try

• Compare memory use of Prospero and your usual harness on the same task with your OS process monitor.
• Try two subagents in separate Git worktrees on one repo and review how their changes merge.
• Point the same config at a local model and a hosted model and compare edit success.

Key ideas

Diffusion language model

Instead of writing left to right, it starts from masked tokens and unmasks them over many refinement steps, running the full model at every step.

Visual tokens

Image patches turned into tokens by a vision encoder, which in these models make up most of the input length and most of the compute.

Certificate guided routing

A cheap check decides per step whether the expensive path, here attending to the image, could change the result, and skips it when it cannot.

Steps

1. Read the abstract and the 22.8% finding on the Hugging Face Papers page for 2610.36671.
2. Look up how LLaDA style masked diffusion decoding picks which token to unmask at each step.
3. Open the LOWN project page or paper figures to see when the text only prediction is trusted and when the image pass runs.
4. Think about why this saves more in a diffusion VLM than in a normal autoregressive VLM that caches the image once.
5. Self check: if the image changes the unmasked token at only a small share of steps, what exactly does LOWN compute to decide that a step is safe to skip?

Steps

1. Clone the repo with git clone https://github.com/hyeon9698/LOWN.git and enter the folder.
2. Run bash setup.sh, which creates a local .venv with the requirements.
3. Run bash evaluate.sh --gpu 0 to compare baseline and LOWN on the included image.
4. Open outputs/result.json and compare the two answers and the reported FLOPs.
5. Try your own picture with bash evaluate.sh --gpu 0 --method lown --image /path/to/image.jpg --prompt "Describe this image."

Small angles to try

• Use images where fine detail matters, such as small text or charts, and check whether LOWN's answer drifts from the baseline.
• Read lown.py to find where the skip decision is made and log how many steps actually used the image.
• Measure wall clock time on your GPU next to the analytical FLOP numbers.

Key ideas

Long horizon agent task

A goal that needs hours of dependent actions, where early design choices decide whether later stages scale.

Human limits in a game API

Restrictions like reach and fog of war stop a program from acting anywhere on the map at once, so the model faces the same constraints a player does.

Thinking level

A setting that controls how much hidden reasoning the model does per step, trading cost and speed for planning quality.

Steps

1. Read Ryan Madden's post on ryanmadden.net and watch the linked timelapse.
2. Note where progress stalled and what the author calls manual effort.
3. Skim the Hacker News thread for the comments on belts versus chests and on hidden information.
4. Map the failure onto software work: a codebase that works at small scale but was never designed to be extended.
5. Self check: why does hand ferrying supplies count as a planning failure even though the rocket still launched?

Steps

1. Write a tiny text based logistics simulation in Python: a few resource nodes, machines with recipes, and an inventory that the player can only move a small amount per turn.
2. Expose it through a few functions, for example place machine, connect machines and carry items, and make carrying slow so connecting things pays off.
3. Give your coding agent the goal of producing a target number of end items and let it run for a fixed number of turns.
4. Log every action and count how often it carries items by hand versus building connections.
5. Raise the target tenfold and see whether the agent redesigns its layout or keeps ferrying.

Small angles to try

• Run the same setup at a low and a high thinking level and compare actions per end item.
• Hide part of the map until explored, a simple fog of war, and see how planning changes.
• Compare two different models on the same seed.

Key ideas

Boot sector

The first 512 bytes of a disk that a BIOS loads and runs before any operating system exists.

int8 quantization

Storing weights as 8 bit integers plus a scale factor, so math can be done with small integers instead of floats.

Power of two scale

Choosing scales like 1/64 or 1/128 so rescaling becomes a bit shift instead of a costly division.

Steps

1. Read the bootgpt README on GitHub from top to bottom.
2. Open boot.asm and find the embedding lookup, the hidden layer loop and the argmax.
3. Open train.py and match its integer math to the assembly line by line.
4. Read the Show HN post for the idiv and edx bug story.
5. Self check: why does using power of two scales let the whole forward pass fit in one sector?

Steps

1. Clone kerlenton/bootgpt.
2. On macOS run brew install nasm qemu, or install nasm and qemu with your Linux package manager.
3. Create the Python environment with python3 -m venv .venv && .venv/bin/pip install numpy.
4. Build the disk image with ./build.sh and boot it in QEMU with ./run.sh.
5. Watch the generated boot log, then press any key to reboot and see a new sample.

Small angles to try

• Change corpus_gen.py to produce a different kind of log, retrain with train.py and rebuild.
• Print the model's integer outputs in Python and check they match what QEMU shows.
• Count how many of the 512 bytes each part of boot.asm uses.

Key ideas

Source grounding

The assistant answers from documents you attached, which makes it easier to check answers against the original text.

Open textbooks

Textbooks under open licenses, such as those from OpenStax, that can be shared and reused for free.

Expert Intelligence

Google's Gemini Notebook feature, announced in August, for adding books bought on Google Play as sources.

Steps

1. Read the ITmedia AI+ article of 2026-10-30, using a browser translator if needed.
2. Look at its screenshots of the source picker and the textbook list.
3. Compare this with uploading your own PDF as a source: who curates the content and who holds the license.
4. Sketch how you would build the same feature with your own retrieval system over a fixed book.
5. Self check: what does a fixed textbook source protect against that open web search does not?

Steps

1. Open Gemini Notebook and create a new notebook.
2. In the source selection screen choose the textbook option and browse the list.
3. Add an OpenStax computer science textbook as a source.
4. Ask three questions on a chapter you already know and check each answer against the book text.
5. Generate practice problems and flashcards for that chapter and solve them without looking.

Small angles to try

• Ask a question the book does not cover and see whether it says so or reaches beyond the source.
• Compare answers with and without the textbook source attached.
• Try a math or medicine book and check how formulas and terms are handled.

Key ideas

Proof assistant

A program, like Lean, that checks every step of a mathematical proof, including proofs that code meets a specification.

Specification

A precise statement of what a function must do, written so a machine can check code against it.

Differential testing

Running two implementations on the same inputs and comparing outputs to find places where they disagree.

Steps

1. Read the interview on The Data Exchange first, focusing on the parts about guardrails, faithfulness and specifications.
2. Open the Lean Get Started page on lean-lang.org and skim what Lean is used for, both as a language and as a prover.
3. Read the first chapters of Theorem Proving in Lean to see what a theorem and a proof look like in code.
4. Skim the Hacker News thread for practitioner views on property based testing versus proof.
5. Self check: why does a proof about a Lean model of your code not guarantee your real code is correct, and how would differential testing help?

Steps

1. Open the Lean online playground linked from lean-lang.org, or install VS Code and the Lean 4 extension as the official install page recommends.
2. Write a small recursive function in Lean, for example one that sums a list of natural numbers.
3. Ask an AI assistant to write a Lean theorem and proof that your function gives the same result as a simple reference version, then paste it in and see whether Lean accepts it.
4. Read the theorem statement yourself and check that it actually says what you intended, not something weaker.
5. Change the function to introduce a bug and confirm that the proof now fails to check.

Small angles to try

• Ask the assistant to optimize the function, for example with an accumulator, and keep the proof passing.
• Port a small function from your own codebase to Lean and compare outputs on random inputs, as a toy differential test.
• Try the same proof task with two different assistants and compare how often Lean accepts the result.

Key ideas

Document parsing

Converting a page image or file into structured text, tables and layout that software can use.

Grounded output

Each extracted item carries where it came from, such as a box on the page or a time range in a video.

On policy distillation

Training a model on its own outputs, scored by a teacher model, rather than only on fixed labeled data.

Steps

1. Read the abstract on the Hugging Face Papers page first.
2. Open the model card for tencent/Youtu-Parsing-Omni and look at the table of supported tasks.
3. Skim the paper's description of the shared output schema and how audio and video records are timestamped.
4. Check the license file linked from the model card.
5. Self check: what does one shared schema across modalities save you compared with separate OCR and transcription tools?

Steps

1. Clone the repo with git clone https://github.com/TencentCloudADP/youtu-parsing.git and change into the youtu_parsing_omni folder.
2. Set up a vLLM environment with bash scripts/setup_env.sh, as the model card describes.
3. Start a local server with MODEL=tencent/Youtu-Parsing-Omni DATA_ROOT=/path/to/media GPU=0 bash scripts/vllm.sh, pointing DATA_ROOT at a folder of your own files.
4. Parse one of your own scanned pages with python examples/infer_vllm.py --task document --media /path/to/media/page.png and inspect the JSON.
5. Run the same script with --task graphics_chart on a chart and with --task audio on a short recording of your own, and compare the outputs against what you know is in them.

Small angles to try

• Compare its table output on a few of your PDFs against the OCR tool you use today.
• Feed the JSON into a small retrieval pipeline and check whether answers improve over plain text extraction.
• Use the Transformers mode from the model card instead of vLLM and compare setup effort.

Key ideas

LoRA adapter

A small set of extra weights that changes a large base model's behavior without retraining the whole model.

Few step sampling

Generating output in a handful of denoising steps instead of dozens, trading some flexibility for speed.

Reference conditioning

Guiding generation with example images, clips or audio so the output keeps their look or sound.

Steps

1. Read the Hugging Face model card first, especially the input limits and hardware notes.
2. Look up the MiniMax-H3 base model card to see what the adapters build on.
3. Read the license section and note which parts are under which license.
4. Skim the inference repo README on GitHub for the supported setup routes.
5. Self check: why does the card say generic six step sampling is not equivalent to its own sampler?

Steps

1. Open the model card and list the inputs each adapter accepts, plus the duration and file count limits.
2. Read the license and decide whether your intended use is allowed.
3. If you have suitable hardware, clone the Pika-Labs/Pika-H3-Flex inference repo and follow its quickstart to download the base components and one adapter.
4. Generate a short 480p clip from a text prompt with the FL2VA adapter and check that audio stays in sync with the action.
5. Run a Ref2VA request using one of your own photos as a reference and compare how well the subject is kept.

Small angles to try

• Compare first frame and first plus last frame modes using the same pair of your own images.
• Measure time and memory for a 480p versus a 768p request.
• Try the diffusers examples mentioned on the card instead of the CLI.

Key ideas

Grounded answers

The model's replies are built from live map data and reviews rather than only from its training data.

Conversational search

Users describe what they want in a sentence instead of typing keywords and filtering results by hand.

Steps

1. Read the ITmedia Mobile review first, using a browser translator if needed.
2. Note which example requests the reviewer found useful and which were faster with normal search.
3. Look at the screenshots comparing a standard phone with an unfolded foldable.
4. Self check: what layout problem appears when a chat panel and a map compete for one screen, and how would you solve it?

Steps

1. Open Google Maps and look for the Ask Maps button in the search bar.
2. Ask a request with at least three conditions near where you live, such as a quiet cafe with outlets and parking.
3. Check two or three of the suggested places against their listings and reviews to see whether every condition is really met.
4. Run the same need as a normal keyword search and compare the time taken and the quality of results.
5. Note how often you have to scroll or switch views between the chat and the map.

Small angles to try

• Ask for a route with a time constraint and a stop on the way.
• Repeat a request on a tablet or foldable and compare the layout.
• Phrase the same request in Japanese and in English and compare the suggestions.

Key ideas

Refusal

When a model declines a request, often because of a policy, a system prompt rule or a safety classifier.

Silent behavior change

A hosted model or client starts acting differently without a version bump or changelog, which can break workflows.

Reverse engineering

Working out how compiled software works by reading binaries, dumps or traffic, often for debugging, interoperability or preservation.

Steps

1. Read the Tom's Hardware article first and separate what is reported by users from what is confirmed.
2. Read the Mashable Hacker News thread for developer reactions and claims about where the rule lives.
3. Check Anthropic's official news page and release notes for any statement, and note that none had been made at the time of writing.
4. Self check: which parts of the story are verified facts, and which are user claims that could change?

Steps

1. Write 10 to 20 benign prompts from your own work, such as explaining a function in a binary you built yourself or writing an original game with mechanics of your own.
2. Send each prompt with the same settings to each model and save the full replies with timestamps.
3. Label each reply as answered, partly answered or refused, and note the reason given.
4. Rerun the same set a few days later to see whether behavior changes over time.
5. Rephrase the prompts that were refused to add honest context about ownership and purpose, and record whether the result changes.

Small angles to try

• Compare the same prompts through a coding agent and through the plain API.
• Include a local open weight model as a baseline.
• Track the refusal rate as a small regression test you run before switching models.

Key ideas

Continued pretraining

Training a base model further on raw text from a new domain so it learns that domain's syntax before any task tuning.

GRPO

A reinforcement learning method that samples a group of answers per prompt and pushes the model toward the ones rated better than the group average.

LoRA adapter

A small set of extra weights trained on top of a frozen base model that can be loaded or swapped without changing the base.

Steps

1. Read the author's Demoscener write up on datavorous.com from top to bottom, noting the three stages and what data each one used.
2. Open the Demoscener-7B model card on Hugging Face and see how the cpt, curriculum and grpo folders map to those stages.
3. Browse a few rows of the Demoscener-Dweets-25k dataset to see what a 140 character demo looks like as training text.
4. Compare the perplexity results for the first two stages with the blind judging used for the last stage, and think about why perplexity cannot measure taste.
5. Self check: why did the author need a human, not a loss number, to choose between completions in the final stage?

Steps

1. Download the adapters from datavorous/Demoscener-7B with huggingface_hub.snapshot_download and load the base model Qwen/Qwen2.5-Coder-7B with transformers, as the model card shows.
2. Attach the cpt adapter with PeftModel.from_pretrained, then add the curriculum and grpo adapters with load_adapter.
3. Pick one partial Dweet from the dataset, switch between the three adapters with set_adapter, and generate a completion from each.
4. Paste each completion into a Dwitter style canvas page or the Dwitter editor and watch the animations side by side.
5. Write down which stage you prefer for five prompts without looking at the labels, then compare with the author's choice of the GRPO checkpoint.

Small angles to try

• Generate with the plain base model and no adapter to see how much the continued pretraining stage changes the output.
• Note the model card warning that later stages were trained on quantized bases, and compare outputs on a quantized base versus BF16.
• Sketch the same best of eight human picking loop for a small domain you know, such as SQL queries or regexes.

Key ideas

Infostealer

Malware that collects saved credentials, session cookies and tokens from a machine and sends them to an attacker.

App-Bound Encryption

A Chrome protection on Windows that ties stored cookies and passwords to the browser itself, which VOLTA tries to bypass by driving Chrome in headless mode.

Model fallback chain

Calling a list of LLMs in order and moving to the next one when a reply looks like a refusal or an error.

Steps

1. Read the Cisco Talos post on VOLTA in full, focusing on the data it collects and the OpenRouter stage.
2. List which of the stolen data types exist on your own work machine, such as SSH keys, cloud config files and browser sessions.
3. Reread the Talos defensive recommendations and match each one to a control you have or lack.
4. Skim the Hacker News thread for the isolation and update delay ideas commenters raised.
5. Self check: why does an LLM triage step make fast token revocation more urgent after a compromise?

Steps

1. Open your browser's password manager settings on your own machine and note whether saved passwords and payment cards are stored there or in a separate hardware backed or OS level store.
2. Check where your SSH private keys and cloud credential files live, and whether the keys have passphrases or sit behind a hardware key.
3. On a Windows machine you own or administer, look at the running processes and their command lines with Task Manager or your EDR, and note whether anything other than known developer tools starts Chrome in headless mode.
4. Write a short detection idea for your own endpoints: alert when a process that is not an approved AI tool sends requests to LLM API hosts such as openrouter.ai, and list which apps you expect to do so.
5. Draft a one page token revocation checklist for your accounts, covering OAuth sessions, SSH keys and cloud keys, using the Talos post as the reference.

Small angles to try

• Turn the headless Chrome rule into a written policy for an application control tool your team already uses.
• Review which developer tools on your machine legitimately call LLM APIs so a detection rule has a clean allow list.
• Compare the Talos advice with commenters' ideas on separating machines or VMs for banking and development.

Key ideas

MLP neuron

One unit in a transformer's feed forward block whose activation can be read or pushed up and down.

Activation steering

Changing internal activations at inference time to shift model behavior without retraining.

Random control

Steering randomly chosen neurons by the same amount to check that an effect is specific to the chosen neuron.

Steps

1. Read the VentureBeat article to see the main experiments and the caveats about what they do not show.
2. Open the Neuron Explorer README on GitHub and note the views it offers and the model it targets.
3. Compare inference time steering in Evil Qwen with the weight training approach Sauers used for the owl model.
4. Self check: why do random neuron controls matter before claiming one neuron controls hostility?

Steps

1. Clone the neuron-explorer repository from GitHub on your own machine.
2. Install dependencies with uv sync.
3. Start the explorer with uv run python explorer/server.py and open http://localhost:8791 in your browser.
4. Use the ranked neuron list to pick one neuron, steer it up and down in the per neuron chat, and record how replies change on three fixed prompts.
5. Repeat with a random neuron in the same layer as a control and compare.

Small angles to try

• Look for neurons tied to a harmless style such as formality or verbosity instead of personality.
• Check whether a steered effect holds across different prompt topics or only on a few.
• Read the sweep scripts in the repo to see how they rank neurons at scale on a GPU pod.

Key ideas

5 hour usage window

A rolling limit that caps how much you can use Claude within five hours from your first message.

Weekly limit

A separate cap on total usage across a week, which still applies on Ultra.

Account verification

A check Anthropic uses before lifting the 5 hour cap, aimed at stopping fraud and abuse.

Steps

1. Read the Impress Watch report on the plan changes.
2. Open the official @claudeai announcement it links to and confirm which plan drops the 5 hour cap.
3. Compare the old Max 5x and Max 20x names with the new Max and Ultra names and prices.
4. Self check: if your bottleneck is total weekly usage, does moving to Ultra help?

Steps

1. Open your Claude account settings and note your current plan name and whether it now shows Max or Ultra.
2. Check your inbox for an email from Anthropic saying your 5 hour limit was removed.
3. Look at your usage view for a typical day and note whether you usually hit the 5 hour window or the weekly limit first.
4. Based on that, write down whether Max or Ultra fits your workload, given that weekly limits did not change.

Small angles to try

• Estimate how many multi hour agent runs a week your current plan allows before the weekly limit.
• Compare the cost of Ultra with paying for the same work through the API.
• For a team, list which members would actually benefit from no 5 hour cap.

Key ideas

File based agent handoff

Agents pass work through files on disk instead of a shared chat, so each one can start with a clean context.

Command verifier

A shell step that runs tests and returns an exit code, so the workflow trusts tests rather than a model's own opinion.

Benchmark contamination

When test problems may have appeared in a model's training data, which can inflate scores.

Steps

1. Read the team-solve README in the Memdoor repository, especially the table of steps with what each agent reads and writes.
2. Look at how the final verify step uses check-samples.sh and why the loop only sees public samples while scoring uses hidden tests.
3. Read the two failure cases and the caveats section of the README.
4. Skim the Hacker News thread for the author's notes on how steps, models and temperatures are set in YAML.
5. Self check: why is a 10 problem, 5 pass result weak evidence even if every number in it is correct?

Steps

1. Read the install script from the README before running it, then install the Memdoor CLI as the README describes and connect a provider with memdoor connect openrouter or memdoor connect local.
2. Clone the repo with git clone --depth 1 https://github.com/guregodevo/memdoor and copy examples/workflows/team-solve into ~/.memdoor/workflows/.
3. Make an empty problem folder, copy in the files from the workflow's sample folder, and run memdoor workflow run team-solve --wait.
4. Open notes.md, review.md and final-test-output.log to follow how the agents handed off work.
5. Replace task.md with a small problem of your own and add paired tests/N.in and tests/N.out files, then rerun.

Small angles to try

• Point /model at a smaller local model and see whether the verifier still catches its mistakes.
• Feed it a problem published after the model's training cutoff to reduce contamination risk.
• Use memdoor tui and /workflow to watch a run live.

Key ideas

LLM

Simon Willison's command line tool and Python library that stores API keys and a default model for many providers.

datasette-llm

A shared plugin that lets other Datasette plugins call models through LLM, and now inherits LLM's default model.

Datasette Agent

A Datasette plugin with a chat page at /-/agent that explores tables and answers questions by running SQL.

Steps

1. Read Willison's short 0.1a9 release post first, it shows the single command and what it replaces.
2. Skim the datasette-agent README on GitHub for the /-/agent page, the permissions it registers and the datasette.yml model options.
3. Read the LLM setup page to see how llm keys set openai and llm models default store a key and a default model.
4. Self check: if LLM has a default model set and you also set default_model in datasette.yml, which one would you expect the agent to use, and why?

Steps

1. Install LLM with uv tool install llm, then store a key with llm keys set openai and paste it.
2. Set a default model with llm models default followed by a model id your key can use, and run llm models default again to confirm it.
3. Copy a SQLite database you own, such as an exported app database, to content.db.
4. Run uvx --with datasette-agent datasette content.db --internal internal.db and open the /-/agent page on the local server. If access is refused, add --root as the README's development command does and use the sign in link it prints.
5. Ask three questions you already know the answers to, and compare the agent's SQL and results against your own queries.

Small angles to try

• Install datasette-agent-charts as well and ask for a chart of a time series in your data.
• Install llm-ollama with llm install llm-ollama, set a local model as the LLM default and see whether the agent still works without a cloud key.
• Restrict the model picker with the purposes block for agent in datasette.yml and check that only the listed models appear.

Key ideas

AI usage mandate

A company rule or expectation that employees use AI tools, sometimes tracked and tied to job security.

Usage metric versus outcome metric

Counting how often someone uses a tool is different from measuring whether their work got faster or better.

Steps

1. Read 404 Media's earlier investigation, "Manifestos, Fear, and Loser Thinking: Inside Proton's AI Reckoning", for the background on Butler's manifesto and Yen's August Slack message.
2. Read the follow up article on the cancelled re-interviews and note what was cancelled and what remains.
3. Skim the Hacker News thread for how engineers at other companies describe similar mandates.
4. Self check: what is the difference between measuring AI usage and measuring engineering outcomes, and which one did the re-interviews target?

Steps

1. List the AI tools your own team actually uses and one task where each clearly saved time.
2. For each task, write one outcome measure such as review turnaround, defect count or time to merge, rather than a usage count.
3. Draft a one page team guideline on AI use that covers security review of generated code, since Butler said AI use does not mean giving up on security.
4. Compare your draft with the Proton approach described by 404 Media and mark which parts would feel coercive to an engineer.
5. Share the draft with one colleague and ask which measure they would trust in their own review.

Small angles to try

• Write the same guideline from the view of an engineer working on security critical code.
• Track your own AI assisted versus manual tasks for one week using only outcome measures.

Key ideas

Search referral

A visit that arrives from a search engine results page, which falls when the search page answers the question itself.

Logged in wall

Requiring an account to read content, which blocks anonymous visitors and most scrapers at once.

Data licensing

Selling access to user generated content to AI model makers, which Reddit counts in its non advertising revenue.

Steps

1. Read the TechCrunch report first for the numbers, the timeline and Huffman's quotes.
2. Read the Gigazine article for the earlier steps, such as login for old.reddit.com and the 2024 API price rise.
3. Write down which numbers describe traffic and which describe revenue, since revenue grew 53% while US users fell.
4. Self check: why would an AI search feature reduce Reddit's logged out traffic, and why would a login wall help its licensing business?

Steps

1. Search your own code, scripts and RAG source lists for reddit.com URLs and list every place that fetches Reddit pages without logging in.
2. For each one, note whether it would still work behind a login wall and whether Reddit's terms allow that use.
3. If you run a website, open its analytics and compare search engine referrals for this October against last October.
4. Write down one replacement source for each Reddit dependency, such as official docs, issue trackers or Stack Overflow.
5. Summarize the risk in three lines for your team.

Small angles to try

• Check whether your own site gets any referrals from AI assistants and how they compare with classic search.
• List which community answers you rely on most and whether they also exist in a public issue tracker.

Key ideas

NVL72

An NVIDIA rack of 72 Blackwell GPUs across 18 nodes that share one NVLink fabric, far faster than InfiniBand between racks.

Slice

A group of nodes placed together inside one rack so a job stays on a single NVLink domain.

Fragmentation

Free nodes scattered across racks, so plenty of GPUs are idle but no rack has enough for a new job.

Steps

1. Read NVIDIA's blog post on Slurm block scheduling for GB200 NVL72 first, since its capacity model, Figure 7, is the source of the 27% comparison.
2. Read the SkyPilot post and find the sentence where it applies its own roughly 2% unavailability to that model.
3. Skim the Hacker News thread for the Kueue comparison and the debate over reserving about 11% of nodes as spares.
4. Self check: why can 16 node slices yield more usable nodes than 18 node slices once a few nodes per rack are down?

Steps

1. Write a short Python script that models 128 racks of 18 nodes and marks each node unavailable with probability 0.02.
2. Count usable nodes when each rack can host one 18 node slice only if all 18 nodes are healthy.
3. Count usable nodes when each rack hosts one 16 node slice if at least 16 nodes are healthy.
4. Repeat both counts over many random trials and compare the averages with the 2,037 and 1,602 figures in the post.
5. Sweep the unavailability rate from 0.5% to 5% and find where 16 node slices stop paying for their two idle spares.

Small angles to try

• Add 9 node slices, two per rack, and compare with the post's claim of about 4% less capacity than 16 node slices.
• Model correlated failures, such as a whole rack going down, and see how the gap changes.
• Simulate jobs ending at random times and measure how often a 16 node job cannot find a free rack.

Key ideas

Peripheral model

Software that imitates a chip's registers, timers and buses so firmware behaves as if it ran on real hardware.

Hardware in the loop

Testing firmware on real boards attached to a test rig, the slow loop a simulator tries to replace.

Differential testing

Running the same firmware on the simulator and on real hardware and comparing traces to catch model errors.

Steps

1. Read the Launch HN post first for what Simantic does and which chips it covers.
2. Read the Simantic docs page for the sim command line tool and its check and run commands.
3. Read the commenter's warning about shared datasheet misreadings and the founders' reply in the thread.
4. Self check: name one firmware bug a digital simulator would catch and one it would miss.

Steps

1. Install the CLI with Homebrew using brew tap simantic-dev/simantic and brew install simantic.
2. Sign in with sim login, then run sim models to see which MCUs your binary supports.
3. Build a simple blink or UART hello firmware of your own for one listed chip and validate it without running it, for example sim STM32F401RE check --elf build/app.elf.
4. Run it with sim STM32F401RE run --elf build/app.elf --ascii --timeout 3 and confirm the UART output matches what you expect.
5. Introduce a deliberate bug, such as a wrong baud rate or pin, and see whether the simulated output reveals it.
6. If you own the real board, flash the same ELF and compare its behavior with the simulator.

Small angles to try

• Let a coding agent write the firmware and use only the simulator output as its feedback loop.
• Try a chip marked not-modeled in sim models and note what fails.
• Compare timing sensitive code, such as a delay loop, between the simulator and a real board.