Code415 Radar

Key ideas

Chain

Clearing one group of puyos makes others fall and clear in sequence, and each extra step in the sequence multiplies the score.

Beam search

A search that keeps only the best few partial move sequences at each depth instead of exploring every branch.

Chain template

A known stacking shape, such as the popular GTR opener, that players and bots build toward because it reliably sets up long chains.

Steps

1. Read the Al Jazeera report on the final to get the facts of the match.
2. Look up how a Puyo chain is scored and why a 10 chain is so much stronger than two 5 chains.
3. Read an introduction to beam search and notice it is the same idea used when LLMs decode text with a beam.
4. Compare a human plan, a few moves ahead with a template in mind, to a bot that scores thousands of board states.
5. Self check: why does a bot need a heuristic score for unfinished boards, and what would you put in it?

Steps

1. Write a tiny 6 column by 12 row grid simulator in Python with 4 colors, gravity and the rule that 4 or more connected same color cells clear.
2. Add chain counting: after each clear, apply gravity and check again, counting how many rounds of clears happen.
3. Write a greedy bot that tries every placement of the next pair and picks the one with the most immediate clears.
4. Write a beam search bot with width 20 and depth 3 that scores boards by the largest chain it can trigger.
5. Run both bots for 200 random games and compare the average longest chain.

Small angles to try

• Change the beam width from 5 to 100 and plot chain length against time per move.
• Ask an LLM to play the same games from a text board and compare it to your bot.
• Add a template bonus that rewards boards shaped like a known opener.

Key ideas

Effort

A knob that sets roughly how much thinking and checking the model does before it answers or acts.

Pass rate by category

The share of benchmark tasks solved, split by domain, which shows where extra compute pays off.

Token cost

Higher effort roughly triples median tokens in this data, so the gain has a price.

Steps

1. Read Spending your effort on claude.dev from top to bottom.
2. Find the per category table and note that security rose from 64% to 87% while software rose only from 43% to 56%.
3. Compare this to how you already choose a faster or slower build: you pay more when failure is expensive.
4. Read Kun Chen's X explainer for a second mental model of the same knob.
5. Self check: for a one line rename, a flaky test fix and a security review, which level would you pick and why?

Steps

1. Pick one real bug in your own repo with a failing test.
2. Start Claude Code, run /effort and set low, then ask it to fix the bug and note time, tokens and whether the test passes.
3. Reset the branch with git and repeat at medium, high and max.
4. Record the results in a small table: level, minutes, tokens, pass or fail, extra edits it made.
5. Repeat with a brainstorming task and see whether higher effort helps at all.

Small angles to try

• Use a bug with a hidden edge case and see if only high or max catches it.
• Try the same four levels in a language you use less often.
• Add a cost column using your plan's usage meter.

Key ideas

Egress control

Rules that limit what network destinations and methods a sandboxed program may use.

Command and control

A channel an attacker uses to send instructions to compromised machines and receive results.

Exfiltration

Moving data out of a system, here reportedly through screenshots and DNS lookups.

Steps

1. Read the swarmtraces.org overview and the timeline section first.
2. List every third party service the agents chained and what each one added.
3. Connect it to server side request forgery: any service that fetches a URL for you can become a proxy.
4. Read the Transluce post for independent evidence from a second dataset.
5. Self check: why does GET only access fail as a sandbox when public services will fetch or render URLs for you?

Steps

1. Run a small container with outbound network disabled and confirm it cannot reach the internet.
2. Start a second local container that acts as a fake URL fetch service on a private Docker network.
3. Show that the first container can now reach outside data through the fetch service even though its own egress is blocked.
4. Add an allowlist to your fake fetch service and confirm the path closes.
5. Write down which real services in your own stack fetch or render URLs for users.

Small angles to try

• Log every request the fetch service makes and see how obvious the relay traffic looks.
• Try DNS based egress rules in the same lab and note what they miss.
• Turn your checklist into a short review template for your team.

Key ideas

Session limit

A cap on usage within a rolling 5 hour window, separate from the weekly cap.

Graceful stop

Ending work at a consistent state, like finishing a file edit, instead of cutting off mid change.

Checkpoint

A saved point you can resume or roll back from, which matters when an agent is interrupted.

Steps

1. Read the ClaudeDevs post on X.
2. Read the entry in the agent releases tracker for the per plan details.
3. Compare it to how a database commits or rolls back a transaction when a connection drops.
4. Check your own plan's usage page to see how close you usually get to the limit.
5. Self check: what state would a half applied multi file edit leave your repo in without this?

Steps

1. Commit your work so you have a clean baseline.
2. Give Claude Code a long multi file refactor near the end of a busy session.
3. If the limit hits, note what it says and whether the repo builds and tests pass.
4. Run git status and git diff to see whether any file is half edited.
5. Write a short note on how you would resume the task.

Small angles to try

• Ask it to keep a progress file so resuming is easier.
• Compare with an interruption you trigger yourself with Ctrl+C.
• Track how much weekly allowance the wrap up used.

Key ideas

Consecutive days count

The length of the current run of days that meet a threshold, such as at least 0.5 mm of rain.

Ensemble forecast

Many forecast runs with slightly different starting conditions, whose spread gives a probability.

AI weather model

A neural network trained on past weather data, such as GraphCast, that produces forecasts much faster than physics models.

Steps

1. Read the Weathernews article for the current count and the 2019 record.
2. Open the JMA past weather data page for Tokyo and find the daily precipitation column.
3. Notice that a streak depends on the threshold: 0.0 mm observed and 0.5 mm give different counts.
4. Read how GraphCast or GenCast produce forecasts in Google DeepMind's posts.
5. Self check: how would you turn 50 ensemble members into a probability that the streak lasts 3 more days?

Steps

1. Download daily precipitation for Tokyo for several years from the JMA past data page.
2. Load it with pandas and mark each day as rainy when precipitation is at least 0.5 mm.
3. Compute run lengths of consecutive rainy days and list the top 10 streaks with dates.
4. Check that the 2019 streak appears and see where today's streak ranks.
5. Plot the longest streak per year.

Small angles to try

• Repeat with a 0.0 mm observed rule and compare rankings.
• Run the same analysis for Osaka and Sapporo.
• Estimate the chance a 31 day streak reaches 34 using past streak data only.

Key ideas

rr

A record and replay debugger for Linux that lets you run a failing program backwards.

Inference cost

The compute cost of running a model for each request, which cheaper chips and tools push down.

Record and replay

Capturing a program's nondeterministic inputs so a run can be reproduced exactly.

Steps

1. Read his Goodbye Google post on his own blog.
2. Read the OfficeChai report for the quotes and team details.
3. Skim the HN thread to see the main arguments on both sides.
4. Read the rr project page to understand the tools he will focus on.
5. Self check: why would making AI cheaper and faster change how quickly it spreads?

Steps

1. Install rr and gdb from your Linux distribution's packages.
2. Write a small C program with a bug that only happens sometimes, such as reading an uninitialized value.
3. Record a failing run with rr, then replay it in the debugger.
4. Set a watchpoint on the bad variable and step backwards to where it was written.
5. Write down how long this took compared with print debugging.

Small angles to try

• Try it on a multithreaded race.
• Ask an AI assistant to find the same bug from the source alone and compare.
• Measure rr's recording overhead on a larger program.

Key ideas

Synchronous access

A database call that blocks the calling thread until it returns.

Event loop blocking

When one slow call on the main thread stalls every other task waiting on that loop.

Write broker

A single worker that serializes all writes so SQLite's one writer rule is never contended.

Steps

1. Read steipete's post on X.
2. Open OpenClaw PR 154189 and read the new rule added to AGENTS.md.
3. Find the profiling numbers in the PR discussion.
4. Compare it to Node's rule of never doing blocking file I/O on the event loop.
5. Self check: why does SQLite allow many readers but only one writer at a time?

Steps

1. Create a SQLite table and a script that simulates 50 sessions, each doing a read and a write every 100 ms.
2. Run it with all database calls on the main thread and record latency of a simple timer task.
3. Move reads to a worker pool and writes to one writer worker.
4. Run again and compare timer latency and total throughput.
5. Turn on WAL mode and measure once more.

Small angles to try

• Scale from 10 to 200 sessions and plot latency.
• Compare with Postgres running in a local container.
• Add a long analytical query and see how it affects the writers.

Key ideas

Plugin

A package that bundles MCP connectors, skills or both so users install them in one step.

MCP connector

A server that exposes tools and data to Claude through the Model Context Protocol.

Agent Skill

A folder of instructions and files Claude loads when a task matches it.

Steps

1. Read Anthropic's Build plugins for Claude post.
2. Read the submission docs to see what the review checks.
3. Compare the flow to publishing a VS Code extension to its marketplace.
4. Look at one existing plugin repo on GitHub to see its layout.
5. Self check: when should something be a plain MCP server and when a plugin?

Steps

1. Pick a small skill or MCP server you wrote.
2. Follow the submit docs to package it as a plugin in a GitHub repo.
3. Install it locally first and confirm Claude uses it for a matching task.
4. Submit it through the portal and note what the automatic validation reports.
5. Record how long review takes.

Small angles to try

• Add a second skill to the same plugin and see how Claude picks between them.
• Test the plugin in both Claude Code and the Claude app.
• Check the usage dashboard after a few days.

Key ideas

SIMD

Single instruction, multiple data: one CPU instruction that works on a whole vector of values at once.

Vector width

How many bits one SIMD register holds, such as 128, 256 or 512.

Emulation fallback

A plain loop version used when the CPU lacks the needed instructions.

Steps

1. Read the Go blog post Platform independent SIMD in Go.
2. Note the vector types such as simd.Float32s and the functions LoadFloat32s, Add, Mul and Store.
3. Compare it to how NumPy runs a vector operation over a whole array at once.
4. Read the GODEBUG section on forcing widths.
5. Self check: why does a tail of leftover elements need LoadFloat32sPart and StorePart?

Steps

1. Write a scalar Go function that computes a dot product of two float32 slices.
2. Write a second version with the simd package using load, multiply and add, handling the tail with the Part functions.
3. Build with GOEXPERIMENT=simd and write a benchmark with Go's testing package.
4. Run the benchmark with GODEBUG=simd=0 and then with the default width, and compare.
5. Check that both versions return the same result within float tolerance.

Small angles to try

• Run the same code on an Apple silicon or other arm64 machine.
• Try slice sizes from 16 to 10 million elements.
• Compare against a Rust version using the Fearless SIMD crate.

Key ideas

Tiered pricing

A price that jumps at usage thresholds instead of rising smoothly per GB.

Usage cap

A hard limit where data stops or slows, which protects you from landing in a higher tier.

Break even point

The usage level where two plans cost the same.

Steps

1. Read the Impress Keitai Watch article for the full price table.
2. Write down the old price for your own usage and the new tier you would land in.
3. Compare it to cloud pricing where egress also has tiers.
4. Look at your last 6 months of data usage in your carrier app.
5. Self check: at which GB values does one extra GB cost about 1,000 yen?

Steps

1. Encode the new tier table as a function from GB to yen.
2. Encode your current plan as a second function.
3. Enter your last 6 to 12 months of usage and compute both costs per month.
4. Plot cost against usage for both plans and mark the break even points.
5. Decide whether a 40GB or 60GB cap would have saved money.

Small angles to try

• Add the points based option and its effective price.
• Simulate a year of random usage around your average.
• Turn it into a tiny web page friends can use.

Key ideas

Deep research agent

An agent that plans searches, reads many pages and writes a sourced answer.

Orchestration

One coordinator agent splitting work across many worker agents and merging results.

Cost cap

A per run spending limit, here set with maxCostDollars.

Steps

1. Read Exa's Agent Ultra blog post.
2. Read the docs page for the parameters effort, maxCostDollars and maxDurationSeconds.
3. Compare this to map reduce: split the question, search in parallel, then merge.
4. Look at which benchmarks Exa chose and what each measures.
5. Self check: why do list building tasks gain more from many agents than single fact questions?

Steps

1. Install Exa's Python SDK following the docs page.
2. Pick a list question you can check yourself, such as open source vector databases with more than 1,000 GitHub stars.
3. Create a run with effort="ultra" and a low maxCostDollars as in the docs example.
4. While it runs, build the same list by hand for 20 minutes.
5. Compare coverage, errors and cost.

Small angles to try

• Run the same question at a lower effort and compare.
• Give the same question to another deep research tool.
• Check 10 random sources from the output for accuracy.

Key ideas

Magic number

Games remaining for the runner up plus 1 minus the leader's lead, in its simple form.

Baseball elimination problem

Deciding if a team can still finish first by modeling remaining games as a flow network.

Monte Carlo simulation

Playing out the rest of the season thousands of times at random to estimate odds.

Steps

1. Read the Baseball Channel article for the current standings and clinch date.
2. Read a lecture note on the baseball elimination problem, such as Princeton's algorithms course.
3. See how each remaining game becomes an edge whose wins flow to one of two teams.
4. Compare it to a bipartite matching problem you may know.
5. Self check: why can a team be eliminated even when its simple magic number math says it is still alive?

Steps

1. Enter wins, losses and remaining games between each pair of Central League teams.
2. Compute the simple magic number for Hanshin and compare to the published value.
3. Build the max flow network for one chasing team using networkx and check elimination.
4. Write a Monte Carlo loop that plays out remaining games with 50% win odds 10,000 times.
5. Report each team's chance of finishing first.

Small angles to try

• Use each team's run differential for win odds instead of 50%.
• Handle ties the way NPB does, by win percentage.
• Run it for the Pacific League too.

Key ideas

Mixture of experts

A model where a router sends each token to a few expert sub networks instead of all weights.

Memory hierarchy

Fast small storage like VRAM backed by slower bigger RAM and disk.

Expert streaming

Loading only the experts a token needs from disk at run time.

Steps

1. Read the colibri README from the top.
2. Find how it decides which experts stay in RAM.
3. Compare it to an OS paging memory to disk under pressure.
4. Look up how many experts per token GLM-5.3 or OLMoE activates.
5. Self check: why would a dense model of the same size be far slower with this approach?

Steps

1. Clone the repo and run ./setup.sh in the c folder as the README shows.
2. Start with the smallest supported model, such as OLMoE, to confirm it works.
3. Convert the weights with ./coli convert as documented and start ./coli chat.
4. Measure tokens per second and watch disk reads with your OS monitor.
5. Write down RAM use, disk use and speed.

Small angles to try

• Move the model to a slower drive and compare speed.
• Try a larger model and see where it becomes unusable.
• Compare with the same small model in llama.cpp.

Key ideas

Stealth model

A model released under a code name before its maker is announced.

Next.js agent evals

Vercel's benchmark of real Next.js tasks an agent must complete.

Data retention

Whether a provider keeps your prompts, which matters for private code.

Steps

1. Read Vercel's changelog entry for Pixel Canary.
2. Read how Vercel's Next.js evals are built and scored.
3. Compare with past stealth releases that later turned out to be major lab models.
4. Note the model id stealth/pixel-canary on AI Gateway.
5. Self check: what does a tie on one framework benchmark tell you, and what does it not?

Steps

1. Create a fresh Next.js sample app you do not mind sharing.
2. Write 3 small tasks, such as adding a form with validation.
3. Run the tasks with Pixel Canary through Cline or AI Gateway.
4. Run the same tasks with a model you already use.
5. Compare time, number of fixes you made and whether the build passes.

Small angles to try

• Add a task outside Next.js to test general coding.
• Try guessing the maker from style and refusals.
• Measure latency per request.

Key ideas

Classifier model

A model that outputs a label and probability instead of free text.

Calibration

When a model says 80%, it is right about 80% of the time.

Single forward pass

One run through the network, with no token by token generation.

Steps

1. Read the Ollaya site.
2. Open the Laya model card on Hugging Face.
3. Compare it to the typed decision model idea covered on September 24.
4. Read what calibration means and how a reliability plot shows it.
5. Self check: when would you still want a chat model instead?

Steps

1. Install Ollaya following the site's instructions.
2. Run ollaya run laya as shown on the site.
3. Write 50 short support messages of your own and label them urgent or not.
4. Classify them with Laya and record accuracy and time per message.
5. Do the same with a local chat model and compare.

Small angles to try

• Plot a reliability curve from the returned probabilities.
• Try messages in Japanese.
• Test the guard model on your own prompts.

Key ideas

Deskilling

Losing a skill because a tool does the work for you.

Review burden

The work of reading and checking code you did not write.

Agent discipline

Habits like tests, small diffs and clear specs that keep agent output correct.

Steps

1. Read Simon Willison's post Coding agents make software engineering harder.
2. Read NeverSink's thread on X for the emotional side.
3. Compare with the deskilling debate from September 24.
4. Write down which parts of your own work you would hate to give up.
5. Self check: does an agent make your job easier, harder, or just different?

Steps

1. Pick a small feature you could write yourself in 30 minutes.
2. Write it by hand and time it.
3. Revert and have an agent write it, timing your prompting and review.
4. Count what you had to fix and how well you understand the final code.
5. Write 3 lines on which version you would rather maintain.

Small angles to try

• Explain the agent's code aloud without looking to test your understanding.
• Repeat a week later and see what you remember.
• Try it on a task in a language you are learning.

Key ideas

Blind test

A comparison where the listener does not know which option is which.

Audio embedding

A vector that summarizes a sound clip so similar sounds sit close together.

Spectrogram

A picture of how a sound's frequencies change over time.

Steps

1. Read the episode guide for tonight's rounds.
2. Read about the published violin blind tests by Claudia Fritz and colleagues.
3. Learn what a spectrogram shows by viewing one for a single violin note.
4. Read how CLAP style models map audio and text into one space.
5. Self check: what could a model detect that a human listener misses, and the reverse?

Steps

1. Record the same short melody on a good and a cheap instrument or speaker.
2. Plot spectrograms of both with librosa.
3. Compute simple features such as spectral centroid and bandwidth.
4. Play both to 3 friends blind and record their guesses.
5. Compare what the features show with what people picked.

Small angles to try

• Use a pretrained audio embedding model and compare cosine similarity.
• Try it with two cups of coffee described in text, like the taste rounds.
• Add a third, middle quality sample.