Code415 Radar

Key ideas

Total versus active parameters

The router sends each token to only 8 of 256 experts, so compute per token follows the 42B active count while memory still has to hold all 816B.

NVFP4 quantization

A 4 bit floating point weight format with block scales that shrinks weights to roughly a quarter of BF16 size at some quality cost.

Weights license versus open source

The Muse Model License lets you download and run the weights but adds attribution and revenue based conditions, so it is not a standard permissive license.

Steps

1. Read the Hugging Face model card for Muse-Spark-Open-816B-A42B first, and focus on the architecture block with 62 layers, 256 experts and 8 active per token.
2. Then read Meta's launch post and note which claims come with numbers and which do not, since the key benchmarks section had no figures in the text of the post.
3. Compare the card's own table with the models it trails, Kimi K3 and GLM 5.3, and write down the two benchmarks where it loses.
4. Connect it to something familiar: think of the experts like database shards where each query only touches a few, so you pay for storage everywhere but compute in a few places.
5. Self check: why does an 816B model need hundreds of GB of memory yet run at roughly the per token compute of a 42B model?

Steps

1. Log in to Hugging Face, accept the Muse Model License on the model page, and open the files tab and config for meta-models/Muse-Spark-Open-816B-A42B.
2. Write down from the card: 62 layers, hidden size 8192, 256 experts with 8 active, 816B total and 42B active.
3. Write a short Python script that converts 816B parameters into gigabytes at 16 bit and at 4 bit, and adds a rough 10 percent for scales and buffers.
4. Compare your numbers with the card's minimums of about 700GB for NVFP4 and about 2TB for BF16, and with Apple's figure of about 493GB for the NVFP4 weights, then note where your estimate is low and why, for example KV cache for a 1M token context.
5. Estimate how many 512GB Mac Studios or 80GB GPUs you would need for each format and write a three line verdict on who can realistically self host it.

Small angles to try

• Redo the math for the 42B active path to see the per token compute versus a dense 42B model
• List the hosted providers named on Meta's post and compare their context limits and pricing pages without signing up
• Read the license text and decide whether your own project would need to notify Meta

Key ideas

App Intent

A declared action your app can perform, which the system can discover and run from Siri, Spotlight or Shortcuts.

App entity

A piece of your app's data, such as a song or a recipe, described so the system can pass it around as a parameter.

On device plus private cloud

A split where small tasks run locally and bigger ones go to a server run by the platform maker, which the panel said Apple offers developers free up to a certain scale.

Steps

1. Read the Keitai Watch roundtable and mark the paragraphs on Siri AI, Gemini and App Intents, noting which statements are the panel's opinion.
2. Open Apple's App Intents documentation page and read the overview, then skim the topic list entries named Apple Intelligence and Siri AI and Verifying your App Intents implementation.
3. Connect it to something familiar: an app intent is a lot like a tool definition in function calling or MCP, with a name, typed parameters and a function that runs.
4. Pick one app you use daily and list three actions and two data types you would expose to the system.
5. Self check: when third party apps are involved, why might the structured declaration of actions matter more than which model sits behind Siri?

Steps

1. Create a small iOS app project in Xcode with one screen and a simple domain such as a reading list.
2. Add one entity type for a list item and one intent that adds an item, following the overview in Apple's App Intents docs.
3. Run the app once in the simulator, then open the Shortcuts app and check whether your action appears.
4. Read the page on verifying your App Intents implementation from the docs index and apply one check it describes.
5. Write down in your own words which parts of your app Siri could reach and which it cannot.
6. Without a Mac: write the same intent and entity as a JSON tool schema and compare them field by field with an MCP tool you know.

Small angles to try

• Count how many parameters the system asks for compared with a typical MCP tool.
• Add a second intent that returns data instead of doing an action, and note how the result is displayed.
• Check whether the docs list Japanese among the languages supported for shortcut phrases.

Key ideas

Pipeline parallelism

Each machine owns a slice of the layers and passes activations to the next, which barely helps single stream decoding but overlaps work during long prompt prefill.

Tensor parallelism

Every layer is split across machines, so each token step needs fast communication but decode speed can scale with more machines.

RDMA over Thunderbolt

Direct memory to memory transfers between machines that skip most of the network stack, which is what makes small latency sensitive messages cheap enough.

Steps

1. Read Apple's post titled Local and Distributed Large LLM Inference with MLX and RDMA on Mac Studio, starting with the section that defines the two parallelism schemes.
2. Find the results tables and note which context size each number refers to, since the pipeline versus tensor ranking changes between 8,192 and 65,536 tokens.
3. Compare with something familiar: sharding a database by table versus by row, and ask which one needs more cross node chatter.
4. Read the caveats about NVFP4 and the experimental synchronization flag before quoting any speed.
5. Self check: why does adding machines not speed up decode for pipeline parallelism, and what would you measure to prove it?

Steps

1. Install the mlx lm package as the post describes and check that mlx_lm.benchmark is on your path.
2. Run the post's single machine benchmark pattern mlx_lm.benchmark --model Qwen/Qwen3.8-27B -p 8192 -g 128 -b 1, swapping in a model that fits your Mac's memory.
3. Repeat with a shorter prompt such as -p 1024 and record prompt processing and generation tokens per second for each run.
4. Start a local server with mlx_lm.server --model <your model> --port 8080 and send a chat request from curl or any OpenAI compatible client to http://127.0.0.1:8080/v1.
5. Write down your decode speed next to the post's single M5 Ultra figure for a similar sized model to see how far your machine is from it.

Small angles to try

• Try a 4 bit and an 8 bit version of the same model and compare speed and memory
• Point an agent tool such as OpenCode at the local server using the config shape in the post
• Run with a context of 8,192 and then 32,768 to see where prefill time starts to dominate

Key ideas

Feature freeze and beta reverts

Once a release freezes, new features stop, and anything found badly broken is removed from the branch instead of being patched under time pressure.

LLM assisted code review

A model reads a patch and lists possible defects, which finds real edge cases but also produces volume that humans must triage.

Post freeze fix count

The number of bug fixes that land on a feature after the freeze, which Robert Haas used as a rough risk ranking of PostgreSQL 19 patches.

Steps

1. Read The Register article first, then the LWN summary of Peter Eisentraut's blog post titled The reverts will continue until morale improves.
2. Read Robert Haas's August 25 scary patch contest message on pgsql-hackers and note the table of post freeze fix counts for six features, which he produced partly by asking Claude to rank them.
3. Compare with your own release branch: if an LLM reviewer filed forty findings on a merged feature tomorrow, who would triage them and what would block the release?
4. Skim the Snowflake explainer for the list of reverted features and the point that many late reversions came from in depth AI generated reviews.
5. Self check: why can a faster bug finder delay a release instead of making it safer at once, and what rule would you set for when AI review findings block shipping?

Steps

1. Pick a feature in one of your own repos that was merged in the last month and gather its diff.
2. List the bug fix commits in your history that touched that feature since it merged.
3. Ask an LLM to review the original diff, list possible defects, rank them by severity and propose a failing test for each.
4. Turn each claimed defect into a real failing test and discard any you cannot reproduce.
5. Record how many findings were real, how long each took to triage, and how many your team would actually have fixed.
6. Write a one paragraph rule for when review findings block a release.

Small angles to try

• Run the same prompt on two different models and compare how much the findings overlap.
• Sort findings into edge cases and design flaws, the two groups Eisentraut separates.
• Ask for reproducing tests only, so every output is checkable.

Key ideas

Verifier voting

A second set of agents independently checks each reported bug and only findings with enough agreement are shown, which trades recall for fewer false alarms.

Risk tiered approval

A classifier decides how many humans must approve a change, from none for low risk to two for high risk, and a bot approval never counts as a human.

Review as an eval set

Incidents and reverts are replayed against the reviewer every day so you can see whether it would have caught them.

Steps

1. Read the claude.dev post How the Claude Code team does code review, starting with the numbered pipeline from before the PR to rollback.
2. Look for the convergence table with passing after one round and five or more rounds, and note the claim about 59 percent of repeated findings being old code.
3. Compare it with your own team's flow: which of the seven layers do you already have and which would add the most?
4. Read Simon Willison's short post on it for an outside view of what is new.
5. Self check: what failure does the three round cap prevent, and what would you do when the cap is hit?

Steps

1. Add or update a CLAUDE.md in the repo with your conventions, and write a short REVIEW.md listing the three things a reviewer should care about most in this code.
2. On a branch with a modest diff, run the local /code-review command from the post and save the output.
3. Run /security-review on the same diff and compare what each one flagged.
4. Mark each finding as useful, noise or already known, and compute your own noise rate.
5. Take two bugs you fixed in the past, check out the commit before the fix, and see whether the reviewer catches them, which is a tiny version of the incident eval set.

Small angles to try

• Change only the REVIEW.md text and see how much the findings change
• Try a very small PR and a 1,000 line PR to check the claim that big PRs get findings and small ones come back clean
• Run the review twice on the same diff to see how stable the findings are

Key ideas

Nothing up my sleeve numbers

Constants in a standard should have a visible, innocent derivation so nobody can suspect they were picked to hide a weakness.

Linear congruential generator

lrand48 is a 48 bit generator whose output leaks its state, so it can be run backwards to a timestamp seed.

Lattice reduction, LLL

An algorithm that finds short vectors in a lattice, used here to recover hidden generator bits from partial outputs.

Steps

1. Read Filippo Valsorda's post first for the story, the bounty and what it means for the backdoor suspicion.
2. Read Anthropic's research post for the method, the timestamp table and how the zero top bit pointed to lrand48.
3. Connect it to a familiar attack: recovering a weak random generator's seed from its outputs, the same idea as predicting Math.random.
4. Find the open questions in both posts, such as the unexplained B-163 seed and the extra valid seeds, and note which are about NIST process and which about the method.
5. Self check: why does a top bit that is always zero across four seeds suggest a 31 bit output generator?

Steps

1. Download the reproduction code from Anthropic's post into a fresh folder and read it before running anything.
2. Run it and confirm it reproduces the 14 seeds and 6 base points the post describes.
3. Check that the P-256 seed starts with C49D3608, matching the table in the post.
4. Write your own small 48 bit generator in Python and compare a few outputs with the reference code.
5. Seed it with the P-256 timestamp from the post and generate candidates up to the index the post gives, confirming the seed appears.

Small angles to try

• Port the reproduction to another language such as Go, as Valsorda did.
• Generate seeds from a weak generator of your own and see whether the zero top bit test spots it.
• Explore a skipped case such as P-256 candidate 876, which the post says also yields a valid curve.

Key ideas

Storefront chart feed

Apple publishes each country's top charts as a public feed from a generator page, with result limits of 10, 25 or 50 and JSON or XML formats.

Snapshot versus trend

One day's rank says where an app is now, while a trend needs the same measurement repeated over days.

Release date field

Each entry carries the app's release date, which lets you spot brand new apps that jumped straight into the top 10.

Steps

1. Open Apple's feed generator page and note the options: media type, storefront, result limit and format.
2. Open the Japan top free JSON and the US top free JSON and find every AI app in each list.
3. Connect it to something familiar: a daily rank is a metric in a time series, one point per day, just like a latency number on a dashboard.
4. Look at the release date of each entry and find any app released in the last two weeks.
5. Self check: why can a single day's chart not tell you whether Claude is rising in Japan?

Steps

1. Write a script that downloads the Japan and US top free feeds at the 50 result limit, using the same URL pattern as the links below with the country code and limit changed.
2. Pick a short list of AI apps to watch, for example ChatGPT, Gemini, Claude, Grok and zeta, and extract each one's rank and name.
3. Append the date, country, app name and rank to a CSV file every run.
4. Run it by hand now, then schedule it daily with cron on your own machine.
5. After a few days plot rank per app with any charting tool.
6. Add a column that flags apps whose release date is within the last 14 days, and note when the feed's updated time changes so you know its refresh cadence.

Small angles to try

• Compare the share of AI apps in the top 25 for Japan and the US over a week.
• Track one local app such as zeta against the global assistants.
• Check whether a rank jump lines up with a launch or news event.

Key ideas

Distilled versus base model

The distilled checkpoint is trained to produce good images in few steps for speed, while the base checkpoint is the one you fine tune.

INT8 and FP8 inference

Storing weights in 8 bit formats halves the memory of BF16 so a 5.6B model fits on consumer cards.

Elo from pairwise preference

Image models are ranked by how often raters pick one output over another, so a gain of 91 Elo means a clear but not absolute preference.

Steps

1. Read the Black Forest Labs blog post on FLUX 3 Image Klein and note the size, license and VRAM table first.
2. Open the two Hugging Face repos named in the post, the distilled and the base, and read the model cards for the intended use of each.
3. Connect it to something familiar: distillation here is like precompiling a slow interpreter into a fast path.
4. Read the license summary to decide if your use counts as free commercial use.
5. Self check: why does the same 5.6B model need 11.2GB in BF16 but only 5.6GB in FP8?

Steps

1. Check your GPU memory, then download the distilled weights from the black-forest-labs/flux-3-image-klein repo on Hugging Face, choosing the INT8 or FP8 build if you have under 12GB.
2. Load it in ComfyUI or Diffusers by following the README of the GitHub repo black-forest-labs/flux-3-image-klein, since the blog did not list install commands.
3. Generate the same 1 megapixel prompt five times and record seconds per image, then compare with BFL's stated 4 to 9 seconds.
4. Run the Gradio demo from that repo to test bounding box control with a short prompt for the boxed region.
5. Write down your VRAM peak, speed and one quality note, such as text rendering or hands.

Small angles to try

• Compare the INT8 and FP8 builds on speed and visible quality
• Try a multi reference edit with two reference images
• Test prompts with embedded text such as a poster headline

Key ideas

Generalist computer use agent

A model that decides for itself how to observe the screen, act through clicks or code, and organise its own work.

Harness to model decision transfer

Moving choices such as what to observe and how to track task state out of hand written harness rules and into the model.

Code execution as an action

The agent runs programs so intermediate results feed later steps, instead of doing everything through clicks.

Steps

1. Read the arXiv abstract, then the experimental HTML version, starting with the method section.
2. Find the OSWorld-v2 results and note which models gained the most from the full configuration.
3. Connect it to scripting: it is like replacing a brittle click macro with a small program that can inspect its own output.
4. Look at the real macOS token comparison and ask what the extra reasoning tokens cost in practice.
5. Self check: when would batching GUI actions beat letting the model write code, and what new risks does code execution add?

Steps

1. Set up a disposable desktop VM with a few offline apps and a small spreadsheet.
2. Define five tasks such as renaming files by a rule and copying data between two apps.
3. Run each task with the agent restricted to GUI actions and record steps taken and success.
4. Run the same tasks again while allowing the agent to execute shell or Python code.
5. Compare success rate, step count and tokens between the two modes.
6. Note where code execution broke something or needed an approval.

Small angles to try

• Allow only read only code to see how much of the gain remains.
• Compare a fixed screenshot schedule with letting the model choose when to look.
• Run two models on the same tasks and track reasoning tokens, as the paper did.

Key ideas

Universal Commerce Protocol

An open standard that gives platforms, AI agents and businesses a shared way to handle catalog, cart, checkout and orders.

Merchant of record

The seller stays legally responsible for the sale even when an agent builds and submits the order.

Identity linking

An OAuth 2.0 step that lets an agent act for a user without ever holding the user's credentials.

Steps

1. Read the short TechCrunch article on the US launch and note what Universal Cart does beyond saving items.
2. Open ucp.dev and read the capabilities list, then write down which one maps to cart, checkout and order.
3. Connect it to something familiar: it looks like a payment provider's checkout session plus OAuth, except that the caller is an agent instead of a browser.
4. Open the GitHub repository README and the source folder of JSON schemas, and find the checkout schema.
5. Self check: why does it matter that the merchant remains the merchant of record when an agent does the checkout?

Steps

1. Clone the UCP repository from GitHub onto your own machine.
2. Install the schema tool with cargo install ucp-schema.
3. Run ucp-schema lint source/ inside the repository and read what it reports.
4. Open the checkout related JSON schema in source/ and list its required fields.
5. Hand write a sample checkout session for a cart with two items and validate it with any JSON Schema validator.
6. Read what the README says about the separate samples and conformance repositories and decide which one you would run next.

Small angles to try

• Ask an LLM to produce a valid checkout payload from the schema alone and count the validation errors.
• Compare the UCP cart fields with a Shopify or Stripe object you already know.
• Read the identity linking sample metadata at /.well-known/oauth-authorization-server and explain each field.

Key ideas

O*NET

The US Department of Labor taxonomy of 923 occupations and 18,797 tasks used here as the yardstick for what work exists.

Benchmark coverage

The share of real tasks that at least one public test measures, defined here as 5 or more mapped prompts.

LLM as judge tagging

A model labels each benchmark prompt with the occupational tasks it resembles, and the labels are checked against human experts.

Steps

1. Read the Mercor page from the top, spending most of your time on the method and caveats sections.
2. Open the job family table and find the family you work in, then compare it with two others.
3. Connect it to test coverage in software: this is a coverage report for AI evaluation, with the labour taxonomy playing the role of the codebase.
4. Check how a task counts as covered and judge whether 5 mapped prompts is a fair bar.
5. Self check: if most working hours are uncovered, what does a high score on coding benchmarks tell you about a non coding job?

Steps

1. Choose one occupation you know well and list its main tasks from the public O*NET data.
2. List three public benchmarks you know and write down which real tasks each one actually tests.
3. Hand map a sample of 20 benchmark prompts to the O*NET tasks you listed.
4. Mark a task as covered when 5 prompts map to it and compute coverage for your occupation.
5. Compare your number with Mercor's figure for the matching job family.
6. Write down what evaluations you would add to cover the largest gaps.

Small angles to try

• Do the mapping with a model as judge and measure how often it agrees with your own labels.
• Weight tasks by the share of time you really spend on them, as Mercor does with time share estimates.
• Apply the same idea to your own team's work to design an internal evaluation set.

Key ideas

Long horizon agentic evaluation

Instead of one answer, the model gets a time budget and tools and must improve its own artifact over many iterations.

Win rate against a fixed roster

Version 0.2 dropped Elo for plain win rates against fixed opponents so scores stay comparable across model generations.

Score versus cost frontier

Plotting score against average dollars per run on a log scale shows which model is the best value, not only the best.

Steps

1. Read the v0.2 post on starskirmish.com first, then skim the v0.1 methodology page for the harness description.
2. Note the three tools given to the agent, compile, play practice batches and read game transcripts, and the rule that the model keeps working until the hour ends.
3. Connect it to something familiar: it is a CI loop where the test suite is a set of stronger opponents.
4. Look at the run to run spread chart and the cost chart, and write down which model you would pick for a budget.
5. Self check: why would practicing early against the strongest bots matter more than a better first draft?

Steps

1. Pick or write a tiny two player game with a bot interface and three fixed opponent bots of increasing strength.
2. Give your coding agent a 20 minute budget to write a bot, with a script that plays practice matches and prints win rate and a short transcript.
3. Run it once with the practice script available and once with only the rules and no practice feedback.
4. Record the final win rate of each bot against the same fixed roster over at least 50 games.
5. Write down whether early practice against the strongest opponent changed the result, and compare with the v0.2 claim.

Small angles to try

• Run the same task three times to measure the spread between best and worst run
• Give two different agents the same budget and compare cost per run
• Hide the transcripts and give only win rates to see how much feedback detail matters

Key ideas

Trace diffing

Record what a working driver sends to a device, record what your driver sends, and compare the two so differences point straight at bugs.

USB passthrough in a VM

A virtual machine is given direct access to a real USB device so the vendor driver can run while the host watches the bus.

Software ISP

Image processing steps such as white balance and lens shading done in software on raw sensor data instead of inside camera hardware.

Steps

1. Read Schaller's post on the GNOME blog and note the four step harness workflow: record, capture, repeat on Linux, diff.
2. Study the before and after camera table and match each kernel or libcamera fix to the metric it changed.
3. Connect it to snapshot testing: the Windows driver is the golden output and the new driver must reproduce it.
4. Find where he explains extracting configuration data instead of copying code, and decide whether that line is clear enough for your own comfort.
5. Self check: why does he capture on the Linux host below the passthrough layer instead of inside the guest, and what does he do for devices with no bus to tap?

Steps

1. Pick a cheap USB device you own, such as a webcam or serial adapter, that already works with a vendor driver in a VM.
2. Pass it through to the VM, perform one simple operation, and capture host side USB traffic with usbmon, the kernel facility the post names.
3. Save the trace, then repeat the same operation on bare Linux with the native driver and save that trace.
4. Write a small script that normalises both traces, dropping timestamps and sequence numbers, and prints the differences.
5. Optionally give both traces to a coding agent and ask for a list of differences with evidence, then verify each against the device.
6. Note which differences were real behaviour and which were noise.

Small angles to try

• For a device with no bus to tap, compare configuration data from the other OS, such as ACPI tables and device properties, as Schaller did for the camera.
• Measure a before and after number as he did, for example average frame brightness.
• Try a non camera device such as a keyboard backlight controller.

Key ideas

Regional editing

You mask or box part of an image and the model changes only that region while keeping the rest consistent.

Multi reference conditioning

The model takes several input images, such as a product and a style, and uses them together to guide one output.

Vendor benchmark hygiene

Check whether a comparison is a live run or pre rendered clips, and whether speed and cost are measured on the same task.

Steps

1. Read the Krea 3 page and list every numeric claim in one table, with the claimed unit and the comparison model.
2. Mark which claims are checkable by you in 30 minutes, such as time per edit and pixels changed outside the box.
3. Read a few of the HN comments for first hand tests and note where users disagree with the page.
4. Connect it to something familiar: a pixel diff is a unit test for an editing model.
5. Self check: if an output is re encoded as JPEG, can the pixels outside the box still match exactly, and how would you allow for that?

Steps

1. Open the Krea 3 edit page from the launch post and sign in.
2. Take five of your own photos, draw a box on each, and make one small edit per photo, timing each edit with a stopwatch.
3. Download each result and the original at the same size.
4. Write a short Python script that compares original and result pixel by pixel outside your box and reports the share of pixels that differ by more than a small tolerance.
5. Compare your median edit time and changed pixel share with the page's claims of under 8 seconds and 0.00 percent.

Small angles to try

• Test hex color matching by asking for a specific brand color and sampling the result
• Try an edit with three reference images to see how well it keeps a character consistent
• Repeat the same edit twice to check how repeatable the output is

Key ideas

Schedule coordination agent

An AI that proposes candidate dates, collects each participant's answer and picks the best slot.

Structured extraction from images

Turning a photo of a poster or timetable into fields such as title, date, start time and place.

Confirmation before save

Showing the parsed event to the user for approval before it is written to a shared calendar.

Steps

1. Read the Keitai Watch article and write down the roadmap month by month.
2. Find the sentence about safeguards against sharing with the wrong user or group and note why that matters once an agent can act on your behalf.
3. Connect it to something familiar: reading a poster photo into an event is the same job as receipt scanning, OCR plus filling a form.
4. Sketch the event fields you would need, such as title, start, end, place and notes, as a small JSON object.
5. Self check: what would you show the user before saving an event extracted from a blurry poster?

Steps

1. Collect ten photos of posters, class timetables or flyers you own.
2. Write a prompt that asks the model for JSON with title, start, end, place and a short confidence note.
3. Run all ten photos and write the correct answer by hand for each one.
4. Score exact match on the date and the time separately.
5. Export the correct ones as an ICS file and import them into a throwaway calendar to confirm they open cleanly.
6. Record the failure types you see, such as wrong year, twelve versus twenty four hour clocks, or Japanese date formats.

Small angles to try

• Add a check that the weekday printed on the poster matches the weekday computed from the extracted date.
• Compare two models on the same ten photos.
• Try photos taken at an angle or in low light and see which fields break first.

Key ideas

Agent harness

The software around a model, including prompts, memory, tools and workflows, that turns it into an agent.

Admission rule

A test on fresh independent validation data that a proposed harness change must pass before it is kept.

Regression budget

A limit on how much past performance a change is allowed to lose.

Steps

1. Read the abstract on the Hugging Face paper page, then open the project page and the GitHub repository it links.
2. Skim the section that separates what gets updated from how changes are proposed and admitted.
3. Connect it to CI: the admission rule is a gate, with a fresh test set as the pipeline and the agent's own config as the code under review.
4. Check what the reference code covers and what it leaves out.
5. Self check: which of your agent's files can it edit today, and what stops a bad edit from persisting?

Steps

1. Pick ten small repeatable tasks, score your agent on them and commit its current instructions file.
2. Ask the agent to review its failures and propose one edit to its own instructions.
3. Score the edited version on a fresh set of ten different tasks, not the ones it saw.
4. Keep the edit only if the fresh score does not drop by more than a budget you set in advance.
5. Repeat for three rounds and commit each accept or reject decision.

Small angles to try

• Compare an edit to instructions with an edit to an executable helper script, the distinction the paper draws.
• Admit changes using the same tasks that inspired them and watch for overfitting.
• Add a human approval gate for any change that grants new permissions.