Code415 Radar

Key ideas

Effort levels

A request setting from low to max that trades thinking tokens for quality; the default is high on the API and medium in Claude Code.

Cost per task

Price per token times the tokens a task really uses, which is what your bill follows.

Terminal-Bench

A benchmark where the model must finish real tasks inside a terminal, closer to agent work than quiz questions.

Steps

1. Read Anthropic's Sonnet 5.5 page for the benchmark table and the claimed speedup.
2. Read the Claude developer blog guide on building with Sonnet 5.5, focusing on when it recommends Opus 5.5 instead.
3. Compare the Terminal-Bench jump with the Artificial Analysis note on output tokens per task.
4. Connect it to your own usage: which of your tasks are well scoped bug fixes, where the guide says Sonnet fits?
5. Self check: if two models cost the same per token, why can one still be 30% cheaper for the same job?

Steps

1. Pick 5 small coding tasks you already know the answer to, for example fixing a failing test in a toy repo.
2. Run each task with model claude-sonnet-5-5 at effort medium and then high.
3. Record input tokens, output tokens, wall time and whether the answer was correct for every run.
4. Run the same 5 tasks on the model you use today.
5. Compute cost per correct task for each setup and put it in a small table.

Small angles to try

• Add max effort and see where extra thinking stops paying off.
• Repeat one task 3 times to see how much results vary.
• Try the same prompts in Japanese and compare token counts.

Key ideas

Orbital insertion

The burn that raises the lowest point of the path above the atmosphere so the craft keeps circling instead of falling back.

TLE

Two Line Element set, a compact public text format describing a satellite's orbit at one moment.

SGP4

The standard model that turns a TLE into positions over time, used by almost every satellite tracker.

Steps

1. Read Space.com's Flight 14 recap for the timeline of engine shutdown, orbit call and deployment.
2. Open CelesTrak's Starlink data pages and look at what one TLE line contains.
3. Compare suborbital and orbital: earlier flights coasted on a path that came back down by design.
4. Link it to something familiar: a TLE is like a snapshot you extrapolate, the way GPS dead reckoning does.
5. Self check: why do new satellites have less accurate TLEs in their first days?

Steps

1. Download the current Starlink TLE file from CelesTrak.
2. Once the Flight 14 Starlink V3 objects are catalogued, pick one, otherwise use any recent Starlink.
3. Propagate it with an SGP4 library for the next 24 hours at one minute steps.
4. Compute passes above 10 degrees elevation for Tokyo.
5. Plot the ground track on a simple map and list pass times in JST.

Small angles to try

• Compare predictions from a TLE that is 1 day old versus 5 days old.
• Add the ISS and see which is brighter or passes more often.
• Check a predicted pass against a phone sky app.

Key ideas

Row level security

A Postgres feature that filters which rows each role can see or change, enforced inside the database.

Anon key

A public key shipped in the browser app; it is safe only if every table has policies that limit what it can do.

Default deny

Turning RLS on with no policies blocks access, which is the safe starting point.

Steps

1. Read the BleepingComputer article for the numbers and the cause.
2. Read Supabase's docs page on row level security and its security advisor.
3. Look for the difference between enabling RLS and writing a policy.
4. Connect it to backend auth you know: RLS moves the WHERE user_id check into the database itself.
5. Self check: why is a secret service key in frontend code worse than a missing policy?

Steps

1. Start a local Postgres container and create a notes table with an owner column and some fake rows.
2. Create a limited role that stands in for the anon user and query the table as that role.
3. Enable row level security on the table and query again to see default deny.
4. Add a policy that only allows rows matching the current user and test with two users.
5. Write a tiny script that lists every table in your own schema where RLS is off.

Small angles to try

• Ask an AI coding tool to build the same notes app and check whether it enables RLS on its own.
• Add an update policy and test that one user cannot edit another's row.
• Measure query time with and without the policy on 100K rows.

Key ideas

Upcoding

Billing a case at a higher severity code than the care delivered would justify.

DRG

Diagnosis Related Group, the bucket that sets how much a hospital stay pays; extra secondary diagnoses can move a case to a pricier bucket.

Revenue cycle tools

Software that reads clinical notes and suggests billing codes, now often driven by language models.

Steps

1. Read the Fierce Healthcare summary of the BCBSA analysis.
2. Look at how BCBSA compared billing severity with care signals like ICU use.
3. Note the stated limits: claims data only, and cases with documented extra care are excluded.
4. Connect it to metric gaming in software: optimize a number and the number drifts from reality.
5. Self check: what data would a hospital need to show the higher codes were correct?

Steps

1. Make 20 short fake discharge notes with a mix of simple and complex cases.
2. Write the correct severity for each one yourself as ground truth.
3. Ask an LLM to suggest the severity for each note with a neutral prompt.
4. Ask again with a prompt that says to capture every billable condition.
5. Compare how often each prompt moves cases up versus your ground truth.

Small angles to try

• Try two different models and compare drift.
• Add a checker prompt that must cite text evidence for each upgrade.
• Measure how often the checker rejects upgrades.

Key ideas

Classification head versus generation

Scoring fixed options in one pass is faster and easier to calibrate than letting a model write free text.

Calibration

A model is calibrated when its 70% answers are right about 70% of the time.

Routing

Deciding which team, tool or model should handle a request, a common first step in agent systems.

Steps

1. Read the Jeff README top to bottom, including the request example.
2. Look at the model table for size, latency and license.
3. Read the HN thread for comparisons with plain logistic regression and LLM prompts.
4. Connect it to a spam filter: same idea, but the options are written in plain language per request.
5. Self check: why is a probability more useful than a yes or no for routing?

Steps

1. Clone the repo and run uv sync.
2. Download the 0.8B checkpoint from Hugging Face into checkpoints/jeff-0.8b as the README shows.
3. Start the server with JEFF_CHECKPOINT=checkpoints/jeff-0.8b PORT=8765 uv run jeff-serve.
4. Send the README's example routing request with curl and read the probabilities.
5. Label 30 of your own support style messages and measure accuracy and latency.

Small angles to try

• Compare with a large API model on the same 30 messages for accuracy and cost.
• Draw a reliability chart to check calibration.
• Test the 2B model and see if accuracy moves.

Key ideas

Adversarial review

A second agent or person whose job is to find faults in a change, not to approve it.

Architecture knowledge

The shared understanding of why components exist and how they fit, which docs rarely fully capture.

Spot check

Reviewing a random sample of changes deeply instead of every change lightly.

Steps

1. Read Ewerlöf's "Coding is not solved".
2. Read Späti's short note on nobody knowing anything anymore.
3. Read DHH's X post and note which safeguards he keeps.
4. Map each argument to your own team's review habits.
5. Self check: which failure would your current tests miss if nobody read the diff?

Steps

1. Pick a repo you know well and ask an agent for a medium sized change.
2. Ask a second agent session to review the diff adversarially and list problems.
3. Review the same diff yourself without reading the agent review.
4. Compare the three lists: bugs found, false alarms, time spent.
5. Write down one rule you would keep for your own workflow.

Small angles to try

• Add mutation testing to see if your tests catch planted bugs.
• Try the reviewer with a different model.
• Time how long a full manual review takes versus a spot check.

Key ideas

Matching decompilation

Writing source that, with the original compiler and flags, produces exactly the same machine code as the shipped game.

objdiff

A tool that shows instruction level differences between your compiled function and the original.

Game dump

Your own copy of the game's files, which the project needs but never distributes.

Steps

1. Read the Petari README for how the build and progress tracking work.
2. Open the project's decomp.dev page and click into a few units.
3. Read about objdiff to see how one function is compared.
4. Link it to reproducible builds in normal software: same input, same bytes.
5. Self check: why do compiler version and flags matter so much here?

Steps

1. Write a 10 line C function with a loop and a branch.
2. Compile it at -O0 and -O2 and save both disassemblies.
3. Change the source a little, for example swap an if order, and see which changes move the machine code.
4. Try to write a second version that produces the exact same -O2 output as the first.
5. Note which source changes are invisible and which are not.

Small angles to try

• Ask an LLM to decompile your -O2 assembly back to C and check if it matches.
• Try a different compiler and compare.
• Use Compiler Explorer's diff view for side by side output.

Key ideas

Streaming TTS

Speech synthesis that starts from partial text so the first sound comes out before the full sentence exists.

Time to first audio

The latency users feel in a voice agent, often more important than total generation time.

Expression tags

Inline markers in the text that tell the model how a phrase should sound.

Steps

1. Read TechCrunch's v4 article.
2. Open the ElevenLabs v4 page and listen to the Japanese samples.
3. Look for what Turbo trades off against the full model.
4. Connect it to web performance: time to first byte versus full page load.
5. Self check: in a voice agent, which delay matters more, LLM or TTS, and why?

Steps

1. Write 5 Japanese sentences with tricky readings, including a name and a number.
2. Generate each with v4 and with the older model you used before.
3. Rate reading accuracy and naturalness from 1 to 5 yourself.
4. Add emotion tags to two sentences and check whether the order is followed.
5. If you use the API, time the first audio chunk for Turbo versus full v4.

Small angles to try

• Repeat in English and compare error types.
• Use only your own voice for any cloning test.
• Pipe a local LLM's streaming output into Turbo and measure end to end delay.

Key ideas

Software defined vehicle

A car whose features are mostly controlled by software that can be updated over the air.

Entitlement check

Code that asks whether this device or account has paid for a feature before enabling it.

Signed license token

A small record, signed by the vendor, that the device can verify offline.

Steps

1. Read the GCN piece on used cars with locked features.
2. Read the Yahoo Autos piece on subscription pricing examples.
3. List where the check could live: in the car, in the cloud, or both.
4. Compare with SaaS feature flags you already use at work.
5. Self check: what should happen to a paid feature when the network is down?

Steps

1. Write a tiny vendor script that signs a JSON license with a device id, feature name and expiry date.
2. Write a device script that verifies the signature offline with the public key and enables the feature.
3. Try editing the expiry date and confirm verification fails.
4. Add a transfer rule: a license bound to the vehicle id versus one bound to an owner id.
5. Write down which rule a used car buyer would prefer and why.

Small angles to try

• Add a grace period when the device cannot reach the server.
• Add revocation and see what it needs from the network.
• Compare token size for Ed25519 and RSA.

Key ideas

Service principal

A non human identity an app uses to call cloud APIs, often with broad rights.

Resource lock

An Azure setting that blocks deletes or changes until the lock is removed.

Secret scanning

Automated search of code and issues for keys that should never be public.

Steps

1. Read the BleepingComputer JadePuffer report.
2. Read Azure's docs on resource locks.
3. Trace the chain: leaked key, discovery, privilege, delete.
4. Connect it to incident response timing: seven minutes is shorter than most paging loops.
5. Self check: which single control would have stopped the delete step?

Steps

1. Run a secret scanner over your own repos and issue text.
2. In your own Azure or other cloud test account, list which identities can delete resources.
3. Put a delete lock on one test resource group and try deleting a resource to see it blocked.
4. Write a short checklist of which roles really need delete rights.
5. Set an alert for mass deletes in your own account.

Small angles to try

• Measure how long your alert takes to fire.
• Repeat the rights review for AWS or GCP.
• Add a pre commit hook that blocks secrets.

Key ideas

Alignment evaluation

Tests that check whether a model follows intended rules, including under pressure or in agent settings.

Sandbox escape

An agent reaching systems outside the environment it was supposed to stay in.

Incident report

A public write up of what went wrong, like a postmortem in software ops.

Steps

1. Read TechCrunch's report on Astra 6.1.
2. Read TechCrunch's piece on OpenAI's rogue activity and the new reports site.
3. Read Higgins for the counter view on language.
4. Compare with software postmortems: what makes a report useful to outsiders?
5. Self check: what would you need to see to trust that a shelved model was the right call?

Steps

1. Open OpenAI's misalignment incidents list via the TechCrunch link.
2. For each of the 9 incidents, note the date, the environment and what was accessed.
3. Classify each as sandbox design flaw, model behavior, or both.
4. Compare with Simon Willison's per lab tally.
5. Write one sentence on which pattern repeats most.

Small angles to try

• Track the list weekly and chart the count.
• Map each incident to a standard postmortem template.
• Compare with Anthropic's own published reports.

Key ideas

S-1 prospectus

The document a company files before listing shares, with audited numbers and risk factors.

Operating loss

Revenue minus the costs of running the business, before items like tax and interest.

Customer concentration

How much revenue depends on a few large buyers.

Steps

1. Read the TechCrunch prospectus summary.
2. Find the revenue, loss and infrastructure numbers and write them down.
3. Read the risk factor section summary on AI risk.
4. Compare with cloud companies you know: why do AI labs spend so far ahead of revenue?
5. Self check: which number here is most likely to change the API you use?

Steps

1. Put the reported revenue figures by period into a sheet.
2. Compute the implied growth rate between 2025 and Q2 2026 annualized.
3. Add the infrastructure spending plan and compute years of current revenue it equals.
4. Note which figures come from the filing and which from secondary posts.
5. Write a two line summary in plain words.

Small angles to try

• Add OpenAI's public figures for comparison where available.
• Chart revenue per quarter if more quarters are disclosed.
• List the top 3 risk factors that affect developers.

Key ideas

Probability of precipitation

The chance that measurable rain falls at a point in a time window, not how much or how long.

Base rate

How often cancellations happened historically for similar forecasts at that stadium.

Nowcasting

Very short range forecasts, minutes to a few hours, often from radar.

Steps

1. Read the Daily Sports report on the cancellation.
2. Open baseballraincheck.jp and compare rain chance with cancel chance.
3. Read JMA's explanation of how precipitation probability is defined.
4. Connect it to classification: rain is a feature, cancellation is the label.
5. Self check: why can a 78% rain forecast still mean the game is likely played?

Steps

1. Get hourly precipitation for Koshien's coordinates for the last 60 days.
2. List the Hanshin home games in that period and mark which were cancelled, from public schedules.
3. For each game, sum rain in the 3 hours before start.
4. Find the rain amount above which games were mostly cancelled.
5. Plot rain amount versus cancelled or played.

Small angles to try

• Compare with a domed stadium like Vantelin Dome as a control.
• Add forecast data from the morning of each game.
• Fit a simple logistic regression and read the coefficient.

Key ideas

Ternary weights

Each weight is one of three values, so it needs under 2 bits instead of 16.

Hadamard transform

A fixed rotation applied to weights and activations that spreads out outliers so low bit quantization loses less.

GGUF

The model file format used by llama.cpp and related local runtimes.

Steps

1. Read the model card on Hugging Face, especially the benchmark table.
2. Read what runtime support it requires.
3. Compare file sizes of PTQ1_0 and PQ2_0.
4. Relate it to image compression: fewer levels, smart transforms first.
5. Self check: why might a ternary model be fast on CPU even without a GPU?

Steps

1. Download the PQ2_0 GGUF from the model card.
2. Run it with llama.cpp using the command shown on the card, lowering the token limit for a quick test.
3. Ask 10 questions from your own work and save the answers.
4. Run the same questions on a normal 4 bit model of similar size in memory.
5. Compare quality by hand and tokens per second.

Small angles to try

• Try the smaller PTQ1_0 file and see what breaks.
• Measure memory use with a system monitor.
• Test long context at 32K tokens.

Key ideas

Browser automation via extension

Controlling a real browser from inside it, so existing cookies and logins are available.

Human in the loop

Pausing so a person approves or completes steps like logins.

Least privilege

Giving a tool only the access a task needs.

Steps

1. Read the BrowserSkill README, focusing on the permission model.
2. Look at which agents are supported and how they call it.
3. Compare with headless tools like Playwright that start with a clean profile.
4. Think of your own browser: what could an agent reach with your sessions?
5. Self check: which sites would you never let an agent use, and how would you enforce that?

Steps

1. Create a fresh browser profile with no real logins.
2. Read the install script before running it, then install from the README.
3. Ask your agent to collect titles from 3 public pages you choose.
4. Watch which windows and tabs it uses and when it asks for approval.
5. Uninstall and note what it left behind.

Small angles to try

• Compare speed and reliability with a Playwright script.
• Test how it handles a page that needs login on a site you own.
• Log every action it takes and review it.

Key ideas

Linear resonant actuator

A small mass on a spring driven back and forth by a coil, giving crisp, fast taps.

Eccentric rotating mass

An older design, a motor spinning an off center weight, slower to start and stop.

Core Haptics

Apple's API for designing custom vibration patterns from transient taps and continuous buzzes.

Steps

1. Read the 9to5Mac article on the verdict.
2. Read Apple's Core Haptics overview page.
3. Compare the two motor types and why taps feel sharper on newer phones.
4. Relate it to audio: haptic patterns are like very low frequency sound design.
5. Self check: why does start and stop speed matter more than strength for a tap?

Steps

1. Option A: in Xcode, build a small app that plays one transient haptic event and one continuous event.
2. Option B: lay one phone on a table and record its accelerometer while the other triggers vibrations on it.
3. Measure how long each vibration takes to reach full strength and to stop.
4. Compare a notification buzz with a keyboard tap.
5. Write down the numbers and describe the feel.

Small angles to try

• Try an older Android phone with a rotating motor for contrast.
• Change sharpness and intensity values and map the feel.
• Record with the phone on different surfaces.

Key ideas

Git worktree

A second checkout of the same repo in another folder, so two branches can run side by side.

Experiment tree

A record of which idea branched from which, with results attached.

Literature review agent

An agent that searches and summarizes papers before proposing experiments.

Steps

1. Read the OpenResearch README for its workflow.
2. Read the git worktree docs if you have not used it.
3. See how experiments map to branches.
4. Compare with a lab notebook or MLflow run tracking.
5. Self check: what is lost if an agent only keeps the final best result?

Steps

1. Install with the command in the README and start it.
2. Give it a small question, for example which tokenizer is faster on your text files.
3. Let it run two parallel explorations.
4. Inspect the worktrees and the experiment tree.
5. Judge whether the conclusion is supported by what it ran.

Small angles to try

• Rerun with a different agent and compare.
• Check how many cited papers are real by opening them.
• Measure token cost of the run.

Key ideas

Ticket lottery

Everyone applies in a window, then winners are drawn, instead of first come first served.

Second chance draw

A redraw for seats that winners did not pay for, the 復活当選 fans hope for.

Device bound ticket

A ticket tied to one phone app account, harder to resell.

Steps

1. Read the official e+ Radiohead page for the rules.
2. Read Rolling Stone Japan's announcement.
3. List the choices: number of entries, first and second choice, redraw.
4. Compare with rate limiting in web systems.
5. Self check: why does a lottery reduce server load compared with a timed sale?

Steps

1. Simulate 200,000 applicants with a first and second choice among 5 shows.
2. Give each show a fixed number of seats and draw winners for first choices.
3. Fill remaining seats from second choices and count winners.
4. Assume 5% of winners do not pay and run a redraw.
5. Report the chance of winning by choice pattern.

Small angles to try

• Test what happens if everyone picks the Saturday show first.
• Add group applications of 2 seats.
• Compare fairness with a first come first served model with random latency.

Key ideas

Generated CLI

Commands built automatically from an API schema so coverage stays complete.

Machine readable output

JSON that scripts and agents can parse without scraping text.

Command search

Finding the right subcommand from a natural language description.

Steps

1. Read Cloudflare's launch post.
2. Compare with Wrangler's scope.
3. Look at how search is meant to be used by an agent.
4. Relate it to OpenAPI based SDK generators you know.
5. Self check: what makes a CLI easier for an agent than a web dashboard?

Steps

1. Install with npm i -g cf as the blog shows.
2. Use its search command to find the operation for listing DNS records.
3. Run a read only command against your own account.
4. Pipe the JSON into a small script that prints a summary.
5. Ask a coding agent to do the same task and watch which commands it picks.

Small angles to try

• Compare the agent's success rate with and without the search command.
• Time the same task in the dashboard.
• Check how errors are returned as JSON.