Code415 Radar

Key ideas

Computer use agent

A model that operates a desktop by looking at screenshots and issuing mouse, keyboard or command actions in a loop.

OSWorld-Verified

A benchmark of real desktop tasks in virtual machines where success is checked by scripts, here capped at 50 steps per task.

Hybrid action space

The model can choose a GUI action that returns a new screenshot or a shell command that returns text output, whichever fits the step.

Steps

1. Read the Mage-VL-Cowork model card on Hugging Face first, focusing on the action space and evaluation sections.
2. List the 11 GUI actions and note that click coordinates are normalized to a 0 to 999 grid rather than pixels.
3. Compare when a task is cheaper through the bash tool, such as renaming files, versus the GUI, such as a dialog with no CLI.
4. Read the safety note on sandboxing and think about which actions in your own workflow would need a human confirmation.
5. Self check: why does a shell action return text with no screenshot, and how does that change the cost of a long task?

Steps

1. Create a disposable VM or container to act as the sandbox the agent controls, with no personal accounts or data inside.
2. Pull the recommended image with docker pull xiaoyizhang/mage-vl-cowork:0.1.0, or install the Python stack with pip install "transformers>=4.57.3" accelerate pillow torch torchvision qwen-vl-utils.
3. Load the model following the card's example, which uses model id microsoft/Mage-VL-Cowork with trust_remote_code=True, and keep the card's sampling settings of temperature 0.7 and top_p 0.8.
4. Send one screenshot of the sandbox desktop with a simple instruction such as opening a text editor, and inspect the returned action before executing it.
5. Give a file task such as counting lines in every .txt file in a folder and check whether the model chooses the bash tool instead of clicking.

Small angles to try

• Run the same five tasks with and without the bash tool enabled and count the steps each needs.
• Serve it through SGLang as the card shows and measure latency per action.
• Add a confirmation gate that blocks any delete or send action until approved.

Key ideas

robots.txt groups

Rules in robots.txt apply to the User-Agent line above them, so a new token works by naming it as a User-Agent.

Usage preference versus crawl control

This token says what fetched content may be used for, while ordinary crawler rules decide whether pages are fetched at all.

IETF AIPREF

The IETF working group on AI preferences where vocabularies and signals for AI use of content are being drafted.

Steps

1. Read the ITmedia NEWS article from Nov 1 first for the token, the example and each vendor's timeline.
2. Open your own site's robots.txt and note which crawler specific groups, such as Google-Extended or GPTBot, already exist.
3. Decide which paths you would want available for training, for example a press kit, and which you would not.
4. Read the Impress Watch piece for Google's note that Google-Extended stays for finer control.
5. Self check: if you add Disallow: / under the training token only, can AI crawlers still fetch your pages?

Steps

1. Copy your current robots.txt to a local working file so the live site is untouched while testing.
2. Append a group with User-Agent: __usage_ai-training, then Disallow: / and Allow: /press-kit/, or your own paths.
3. Load the file with Python's urllib.robotparser and ask whether the agent __usage_ai-training may fetch a normal page and a press kit page.
4. Ask the same parser about your existing crawler groups to confirm their answers did not change.
5. Deploy the updated file to your own site and fetch it back over HTTPS to confirm it is served as plain text.

Small angles to try

• Allow training only on a docs folder and disallow everything else.
• Compare the result with a setup that relies only on Google-Extended and GPTBot groups.
• Add a dated comment in robots.txt so you can review the setting when Microsoft starts reading it in February 2027.

Key ideas

Block diffusion decoding

Instead of one token at a time, the model refines a whole block of tokens in parallel steps, then moves to the next block.

Mixture of experts

Only a few expert subnetworks run per token, so 3B of the 35B parameters do the work for each step.

Self speculative decoding

The model drafts tokens cheaply and verifies them itself, which the card says only the SGLang and llama.cpp versions implement.

Steps

1. Read the Hugging Face launch blog from Oct 30 first for the architecture, which mixes a gated DeltaNet state for past context with bidirectional attention inside the current block.
2. Read the model card's usage and limitations sections for the 128K budget, sampling defaults and repetition controls.
3. Compare the H200 throughput claim with the setup it is measured against and note batch size and precision.
4. Note which benchmark numbers are vendor reported and look for an independent leaderboard entry before trusting them.
5. Self check: why can diffusion decoding be faster at batch size 1 than plain autoregressive decoding?

Steps

1. Rent or provision a GPU machine you control and install the server with pip install sglang.
2. Start it with python3 -m sglang.launch_server --model-path "Diffuspace/Clover-35B-A3B-Preview" --host 0.0.0.0 --port 30000, binding to localhost or a firewalled host only.
3. Send three coding prompts from your own repo, such as writing a unit test for a known function, and save the outputs.
4. Measure tokens per second for each response and compare with an autoregressive model of similar active size on the same machine.
5. Run the generated tests locally to check correctness instead of relying on the reported benchmark scores.

Small angles to try

• Toggle thinking mode and compare quality against latency.
• Push one generation near the length limit and watch for the repetition the card warns about.
• Try the vLLM path the card also lists and compare throughput with SGLang.

Key ideas

Contact sheet

A grid image of frames sampled every few seconds, which lets a text and image model see a whole clip at once.

Edit decision list

A plain list of which clip to use and its start and end times, which a script can then render into a video.

Speaker verification

Comparing voice embeddings, here from SpeechBrain ECAPA, to tell one known speaker apart from others.

Steps

1. Read the Digg AI story first for the full list of tools and the cut list format.
2. Read levelsio's original post on X for his own description of the prompt and the result.
3. Sketch the pipeline as stages: transcribe, sample frames, choose cuts, render, caption.
4. Note which stages run locally on the laptop and which need the model, and why the video itself never goes to the model.
5. Self check: what information would the model lack if it had transcripts but no contact sheets?

Steps

1. Put three to five of your own short clips into an empty folder.
2. Install the transcriber with pip install mlx-whisper and run mlx_whisper on one clip's audio to check that a text transcript appears.
3. Open Claude Code in that folder and ask it to make a 2 minute highlight video, first producing transcripts, frame grids and a JSON cut list for review.
4. Read the JSON cut list and change one cut by hand before asking it to render.
5. Ask it to render the final video with ffmpeg and compare the result with your own choice of highlights.

Small angles to try

• Pick a larger Whisper model from the mlx-community collection and compare transcript quality.
• Ask for a vertical 60 second cut with burned in captions.
• Skip the contact sheets and see how the cut list changes when the model has transcripts only.

Key ideas

Bulk LLM filtering

Running a cheaper model over every row of a large dataset to keep only the rows that match a description.

Claude Code Workflow

A Claude Code feature that fans a scripted task out over many items, used here to run Sonnet across all comments.

Public data dumps

Datasets such as open-index/hacker-news let one person build a product without scraping the live site.

Steps

1. Read Karpathy's HackerTube post first for the pipeline and the list of manual steps.
2. Open the open-index/hacker-news dataset page on Hugging Face and look at its fields.
3. Browse hackertube.org and pick one topic to see how videos are grouped and ranked.
4. Visit HackerBooks to see how the same idea transfers to books, ranked by distinct recommenders.
5. Self check: which step in the pipeline costs the most model calls, and how would you shrink it?

Steps

1. Download a small slice of the open-index/hacker-news dataset, such as one month of comments, to your own machine.
2. Use a plain text search to keep comments containing YouTube links, and count them.
3. Ask Claude Code to classify a sample of 200 of those comments as genuine recommendation or not, and spot check 20 by hand.
4. Have it group the kept links into a handful of topics and write a static HTML page listing them.
5. Open the page locally and compare a topic with the matching one on hackertube.org.

Small angles to try

• Swap YouTube links for GitHub repos mentioned on HN.
• Measure how much a cheaper model disagrees with a stronger one on the same 200 comments.
• Rank items by number of distinct commenters instead of raw mentions.

Key ideas

Sprite sheet

One image holding every animation frame in a grid, plus metadata that tells a game engine where each frame sits and how long it lasts.

Claude Code skill

A folder of instructions and helper files that Claude Code loads when a task matches, so the agent follows the project's own conventions.

Procedural effect

An animation produced by code from parameters and a random seed rather than drawn by hand frame by frame.

Steps

1. Read the README at https://github.com/patch-gg/pixelfx first, focusing on the categories, the export format and the skill section.
2. Open the live gallery and play a few effects, changing the palette and the seed to see how one file yields many variants.
3. Open one effect file under src/fx/ and trace which parameters control timing, color and particle count.
4. Read the skill folder skills/pixelfx to see what conventions it gives the agent when creating a new effect.
5. Self check: why does a skill that knows the folder layout and export format produce more reusable effects than asking a chatbot for a one off animation?

Steps

1. Clone https://github.com/patch-gg/pixelfx and run node tools/serve.mjs in the repo to open the local gallery.
2. In Claude Code, install the skill with /plugin marketplace add patch-gg/pixelfx then /plugin install pixelfx@pixelfx, or copy skills/pixelfx into ~/.claude/skills/.
3. Ask Claude Code to find an existing fire effect and export it as a sprite sheet, then check the PNG and JSON it produced.
4. Ask it to create a new effect, for example a small green poison cloud, and reload the local gallery to review it.
5. Request one or two refinements such as fewer frames or a darker palette and compare the files before and after.

Small angles to try

• Import the exported sheet into a Godot or Unity test scene and check frame timing and pivot.
• Use the library directly in a canvas page after npm i github:patch-gg/pixelfx.
• Compare an effect made with the skill against one made by plain prompting without it.

Key ideas

Back patching

Applying a bug fix to older supported release branches as well as the main development branch.

Feature revert

Removing an already committed feature before release because it is not judged stable enough to ship.

Review bottleneck

When finding problems gets cheap, the limit on progress becomes how many qualified people can verify and commit fixes.

Steps

1. Read Robert Haas's post at https://rhaas.blogspot.com/2026/10/postgres-19-is-late-and-its-ais-fault.html from start to end.
2. Write down the two commit comparisons and which branch each number refers to.
3. Skim the Hacker News thread for comments from people who ran AI bug hunting on Postgres and how they triaged results.
4. List which of your own dependencies have a small maintainer team that could hit the same review limit.
5. Self check: why does more AI bug finding delay a release instead of speeding it up?

Steps

1. Pick one module of your own code, roughly a few hundred lines, that has tests.
2. Ask your LLM assistant to list likely bugs in it, with the reason for each.
3. Time how long it takes you to verify each claimed bug as real, false, or unclear.
4. For one real bug, have the assistant draft a fix and review it as if you were a committer, noting what you had to change.
5. Compare total time spent finding versus verifying and fixing, which is the ratio Haas describes.

Small angles to try

• Repeat with a module you did not write to see how review time changes.
• Track how many findings would also need fixing on an older release branch of your project.
• Try two different models on the same module and compare false positive rates.

Key ideas

Secret rotation

Replacing a credential with a new one and revoking the old one so a leaked copy stops working.

Spend cap

A limit set at the AI provider that stops or alerts on usage beyond a chosen amount, limiting damage from a stolen key.

Indicators of compromise

Concrete signs such as attacker IP addresses that help you check your own logs for the same activity.

Steps

1. Read the Northflank status page at https://status.northflank.com from the first alert to the latest update.
2. Read the Qovery summary to see the wider pattern of attacks on AI developer platforms.
3. List every place your team stores AI provider keys, such as hosting platforms, CI and local env files.
4. Note which of those keys have spend caps and usage alerts set.
5. Self check: if a hosting platform told you today that all environment variables were exposed, how long would a full rotation take you?

Steps

1. Inventory the AI provider keys your projects use and where each is stored.
2. In each provider's console, set a spend limit or usage alert if one is not already in place.
3. Pick one low risk key and run a rotation drill: create a new key, update your own deployment, confirm it works, then revoke the old key.
4. Review the last 30 days of usage and billing for each provider and look for unexpected spikes.
5. Write down the rotation steps you used so the next rotation is a checklist.

Small angles to try

• Check whether your hosting platform offers audit logs and turn them on.
• Move one key from a plain environment variable into your platform's secret manager and compare the rotation steps.
• Scope keys per project so one leak cannot drain every budget.

Key ideas

Accessibility tree

The structured list of buttons, fields and labels an operating system exposes for screen readers, which agents can also read.

Element ref

A short id tied to one element in one snapshot, used to click or type without pixel coordinates.

Headless action

An action sent through the accessibility API without moving the physical mouse or stealing window focus.

Steps

1. Read the README at https://github.com/vercel-labs/agent-desktop, especially the snapshot, ref and privacy sections.
2. Compare this approach with screenshot based computer use: what the agent sees, cost per step, and failure modes.
3. Read the ShiftDelete article for the parallel cursor feature and the release timeline.
4. Think about one app you use that has poor accessibility labels and how an agent would fail on it.
5. Self check: why must the agent take a new snapshot after an action instead of reusing old refs?

Steps

1. Install with npm install -g agent-desktop and confirm with agent-desktop version.
2. Close apps that show private data, then open a harmless app such as Finder or a text editor with an empty document.
3. Run agent-desktop snapshot --app Finder -i, or the same with your chosen app, and read the JSON refs it returns.
4. Run agent-desktop click with one ref copied from that snapshot, then snapshot again to confirm the change.
5. Change the UI by hand and retry the old ref to see the stale ref error, then recover with a new snapshot.
6. Ask Claude Code or Codex to complete a small task in the same app using only these commands.

Small angles to try

• Snapshot an app you build yourself and fix missing accessibility labels the agent cannot use.
• Run two agents in parallel on separate apps and watch their separate cursors.
• Compare steps and time against a screenshot based computer use tool on the same task.

Key ideas

Token based allowance

A usage limit counted in model tokens rather than messages, so long or complex tasks cost more of it.

Shared pool

One budget that several products draw from, so heavy use in one leaves less for the other.

Reset window

The time after which a usage allowance refills, shown alongside remaining usage.

Steps

1. Read the StackVersus summary on DEV first, then the OpenAI help article it links.
2. Note which plans are affected and what is excluded from the pool.
3. Compare with OpenAI's Codex plan page and list what still describes the old limits.
4. Estimate how much of your weekly work runs through Codex versus ChatGPT.
5. Self check: which of your current habits, such as long agent runs, would use the shared allowance fastest?

Steps

1. Open Settings > Usage in ChatGPT and record what it shows today.
2. Run one typical Codex task you would normally do and note its length and model.
3. Check Settings > Usage again and record any change, keeping notes for when the December pool starts.
4. Do a comparable chat session with a non Instant model and record the change the same way.
5. Decide whether to move heavy agent runs to API billing or lighter models once per plan numbers appear.

Small angles to try

• Repeat the same task with a smaller model to compare consumption.
• Track a full working day of mixed use after the change lands in December.
• Compare the cost of the same workload on API pricing.

Key ideas

SFT

Supervised fine tuning trains a model on example prompts paired with the desired answers.

RFT

Reinforcement fine tuning updates a model using scores or rewards given to its sampled outputs, called rollouts.

Competing model clause

A terms of service rule that forbids using a provider's service to build or train AI models that compete with it.

Steps

1. Read the FourWeekMBA write up first to see exactly what the user claimed and which terms excerpts it quotes.
2. Open Anthropic's Commercial Terms and Usage Policy and find the sections on competing products and training on outputs.
3. Skim the Hacker News thread to separate firsthand reports from speculation.
4. Self check: can you say which parts of this story are the user's claim, which are the written terms, and which remain unknown?

Steps

1. List the tasks in your own ML pipeline where an AI coding assistant writes or submits training jobs.
2. Read the provider terms you agreed to and note any clause about training or competing models next to each task.
3. Configure a fallback model or provider in your agent tooling so a blocked or downgraded session does not stop the pipeline.
4. Log which model actually answered each request, so a silent downgrade would show up in your own records.
5. Write a one page note for your team on what to do if the primary assistant refuses or ends a session.

Small angles to try

• Compare the training related clauses of two providers you use.
• Check whether your agent tool reports the serving model name in its responses or logs.

Key ideas

Looped layers

The same block of layers is applied more than once in a forward pass, reusing its weights to add depth.

Inference parameters

A count of the parameters that effectively take part in computation per pass, larger than the stored count when layers repeat.

Hybrid linear attention

Most layers use cheaper linear attention while some keep full attention, cutting cost on long inputs.

Steps

1. Read the Hugging Face model card first, focusing on the architecture section that describes the looped block.
2. Work out why 32 stored layers become 56 executions when layers 4 to 27 run twice.
3. Compare memory needs for weights versus compute per token for a looped model and a plain 14.6B model.
4. Self check: if VRAM is your bottleneck, why might a looped 9B model be a better fit than a dense 14B one?

Steps

1. Create a fresh Python environment and install the versions pinned on the card: python -m pip install "transformers==5.18.0" accelerate safetensors.
2. Load the model and tokenizer from sensenova/SenseNova-Loop-9B-Preview with trust_remote_code=True and bfloat16, following the card's snippet.
3. Run the card's sample chat prompt with thinking disabled and confirm you get a sensible answer.
4. Record peak GPU memory and tokens per second for a short and a long prompt.
5. Optionally build vLLM from the pull request branch the card links and compare throughput with the plain Transformers run.

Small angles to try

• Try the same prompts with thinking enabled and compare answer quality and latency.
• Compare memory and speed against a dense model of similar stored size you already have.

Key ideas

Human in the loop

A design where a person must approve certain actions before an AI agent can carry them out.

Inalienable human in the loop

The paper's stronger version, where approval cannot be obtained by the agent even if it controls the human's local tools.

Out of band approval

Confirming an action through a separate channel, such as a phone, that the requesting system cannot read or control.

Steps

1. Read the CoinDesk article first for the experiment setup and results by scenario.
2. Read the arXiv abstract to see how the authors define I-HITL and why it needs a trusted device.
3. Map the approval channels in one of your own agent setups and mark which ones the agent can read.
4. Self check: if your agent can read the inbox that receives a passcode, is that passcode still a human approval?

Steps

1. In a local container, build a mock wallet service with a tiny daily limit and an endpoint to raise the limit using a one time code.
2. Make the mock service write each new code into a local mock inbox file.
3. Give a scripted or LLM driven agent a task that needs more than the limit, with tools to read the inbox and call the wallet.
4. Log whether the agent reads the code and raises its own limit.
5. Move the code delivery to a channel the agent has no tool for, rerun, and confirm the bypass is gone.

Small angles to try

• Add an email that impersonates a vendor asking for payment and see if the agent pays it.
• Change the system prompt to forbid raising limits and measure whether behavior changes.

Key ideas

Side channel

Information leaked through an indirect signal, here finger movement, rather than the protected data itself.

Password prior

Statistics from leaked passwords used to rank which guesses are most likely given partial evidence.

Passkey

A login method using a device held key instead of a typed secret, so there is nothing to observe on the keyboard.

Steps

1. Read the ITmedia article first for the setup, devices and limits.
2. Read the arXiv abstract of Watch and Crack to see how video and password statistics combine.
3. Sketch the pipeline: fingertip tracking, key press detection, keyboard layout inference, candidate ranking.
4. Self check: why does a privacy screen filter fail against this attack, and what would stop it?

Steps

1. List the accounts you most often unlock by typing a password on your phone in public.
2. Check each account's security settings for passkey or device based sign in support.
3. Enable passkeys or biometric unlock where available, and keep a recovery method you control.
4. Review your phone's lock screen setting and consider switching from a typed password to biometrics plus a longer fallback.
5. Note the accounts that still require typed passwords and plan to change them only in private.

Small angles to try

• Audit a team's shared accounts for passkey support.
• Check whether your own app's login flow offers passkeys to users.

Key ideas

Bit flip

A radiation hit that changes a stored 0 to 1 or the reverse, which can corrupt data without any error signal.

Commissioning

The checkout period after launch when each satellite subsystem is powered up and tested.

Inference versus training

Running a fixed model to answer prompts is more tolerant of small errors than training, where errors accumulate into the weights.

Steps

1. Read the TechCrunch article first for the hardware and power limits.
2. Read the Google blog post for the first response and the test plan.
3. Think through why a single flipped bit hurts training more than inference.
4. Self check: with one TPU running for about 20 minutes, what kinds of workloads make sense in orbit?

Steps

1. Load a small open model locally and save its output for a fixed prompt with greedy decoding.
2. Write a function that picks a random weight tensor and flips one random bit in one value.
3. Apply one flip, rerun the same prompt, compare to the saved output, then restore the original weights.
4. Repeat for many trials and record how often the output changes at all.
5. Separate the results by whether the flipped bit was in the exponent or the mantissa.

Small angles to try

• Increase the number of flips per trial and plot the failure rate.
• Run a few training steps on a toy model with flips injected into gradients and compare loss curves.

Key ideas

Work item

A tracked unit of work the agent opens for each request, with its own session and directory so tasks do not mix.

Proactive agent

An agent that listens to event sources such as GitHub and acts on allowed requests without someone starting each run by hand.

Attention panel

A web view that shows only the items where a person must decide or review, hiding everything the agent can finish alone.

Steps

1. Read the README of deepseek-ai/dsh-superagent-prototype on GitHub first, focusing on the work item flow and the disclaimers.
2. Open SETUP.md and docs/006-deployment.md in the repo to see what the agent needs from GitHub, Feishu and DeepSeek Harness.
3. Sketch the path of one request: GitHub event, authorization check, work item, agent session, reply with a pull request.
4. Compare that path with how you trigger your current coding agent, and note where a person is interrupted.
5. Self check: which requests should reach the attention panel, and which should the agent close without asking anyone?

Steps

1. Clone the repository to your own machine.
2. Install dependencies with pnpm and run pnpm check to run the typecheck, tests and build.
3. Following SETUP.md, point the agent at a throwaway GitHub repository you own, never at a shared or third party repo.
4. From an allowed account, open an issue asking for a small change, such as fixing a typo in the README.
5. Watch the work item appear, check the reply or pull request it posts, and see whether the web panel asks you for anything.

Small angles to try

• Send a request from an account that is not allowed and confirm it is ignored.
• Ask for an ambiguous change and see whether it lands in the attention panel.
• Read the authorization code path and list which GitHub events it trusts.

Key ideas

Effort level

A setting that controls how much reasoning the model spends per request, trading cost and speed against depth.

Subagent

A helper agent that the main Claude Code session starts for a side task, which uses its own tokens.

Write sandboxing

A permission rule that stops file writing tools from touching paths outside the working directories in every permission mode.

Steps

1. Read the aicoding-guide weekly digest for Nov 1 first for a summary of the four releases.
2. Open the Claude Code CHANGELOG on GitHub and find the entries for 2.1.311, 2.1.314 and 2.1.316.
3. List where your own scripts or CI jobs select Opus 4.8 fast mode.
4. Note which of your sessions spawn subagents and what effort they inherit today.
5. Self check: what happens to an Opus 4.8 fast mode request on Dec 1, and which setting caps subagent effort?

Steps

1. Update Claude Code and confirm the version is at least 2.1.316.
2. In a throwaway project, run a task that spawns a subagent and note its token use.
3. Set CLAUDE_CODE_SUBAGENT_EFFORT to a lower level in your environment and run the same task again, comparing token use and result quality.
4. Add permissions.blockWritesOutsideWorkingDirectories to your project settings and ask Claude Code to write a file in a sibling folder; confirm it refuses.
5. Search your scripts and CI config for Opus 4.8 fast mode and plan the move before Nov 30.

Small angles to try

• Set CLAUDE_CODE_DISABLE_ULTRATHINK and check that the ultrathink keyword no longer changes behavior.
• Pair the write block with permissions.blockReadsOutsideWorkingDirectories for a fuller sandbox.
• Compare subagent cost at two effort levels on a real refactor.

Key ideas

Voice agent loop

Speech recognition turns audio into text, a language model writes a reply, and text to speech turns it back into audio.

End of speech detection

The agent waits for a short silence, 300 ms here, before deciding the person has finished talking.

LoRA adapter

A small set of extra trained weights that gives a base model a new style or persona without retraining all of it.

Steps

1. Read the Hugging Face blog post on MonsterHouse first, especially the latency section.
2. Open the NVIDIA-AI-Blueprints nemotron-voice-agent README to see how the pieces are wired.
3. Draw the pipeline with the time each stage adds, from silence detection to audio out.
4. Note why caching common replies cut median latency from 1.70 to 0.72 seconds.
5. Self check: which stage would you shrink first to get a local voice agent under one second?

Steps

1. Clone the nemotron-voice-agent repository from NVIDIA-AI-Blueprints.
2. Follow its README to run the Generic Assistant example on your own machine.
3. Speak a few short questions and time the gap between when you stop talking and when audio starts.
4. Try Bolt on build.nvidia.com in conversational mode with reasoning off, as the post suggests, and compare reply length.
5. Write down where the time goes and compare it with the 1.70 second median in the post.

Small angles to try

• Add a small cache of common replies and measure the latency change.
• Change the silence threshold and see how often it cuts you off.
• Read the NeMo AutoModel recipe for a Bolt E4B LoRA and plan a persona dataset.

Key ideas

Agent connector

A link that lets an AI agent read data from another service on the user's behalf.

Read only scope

A permission that lets the agent look at data but never change it or move money.

Day 14 retention

The share of new users who still open an app two weeks after installing it.

Steps

1. Read the k-tai Watch article of Nov 1 first for the connector's features and safeguards.
2. List every safeguard it names: consent, no shared credentials, read only, no money movement, disconnect any time.
3. Read the OfficeChai roundup and note that its retention and time figures are for the US.
4. Compare the connector design with an OAuth app you know and mark what scopes it would need.
5. Self check: what could Muse do with this connection, and what can it never do?

Steps

1. Make a small CSV of fake household transactions covering three months.
2. Write down a read only connector spec for it: which fields an agent may read and which actions are forbidden.
3. Ask any chat assistant you already use to analyze the CSV for subscriptions to review and a savings plan.
4. Check the answer against the data by hand and note any invented numbers.
5. Rewrite your spec so every action the agent proposes needs a human step to execute.

Small angles to try

• Remove category labels from the CSV and see how well subscriptions are still found.
• Add a fake duplicate charge and check whether it gets flagged.
• Draft the consent screen text a user would see before connecting.

Key ideas

Structural diff

A diff that compares parsed syntax trees instead of raw lines, so moved or reformatted code shows less noise.

tree-sitter

A parser library that builds syntax trees for many languages quickly and incrementally.

git difftool

A Git command that opens an external program to show the changes between two versions of a file.

Steps

1. Read the OmniDiff README on GitHub first, especially the usage and Git integration sections.
2. Skim the Show HN thread for the comparisons with Delta and Difftastic.
3. Pick one file in your own repo that had a code move or rename and predict what a line diff shows.
4. Note the license terms: AGPL-3.0, or a paid commercial license through GitHub Sponsors.
5. Self check: why would a moved function look smaller in a structural diff than in a line diff?

Steps

1. Install with cargo install --locked omnidiff or brew install ivankovic/omnidiff/omnidiff.
2. Compare two versions of a file with omnidiff BEFORE AFTER and browse the terminal viewer.
3. Register it with git config difftool.omnidiff.cmd 'omnidiff "$LOCAL" "$REMOTE"' and run git difftool --tool=omnidiff on a recent commit.
4. Run GIT_EXTERNAL_DIFF=omnidiff git diff on the same change and compare with plain git diff.
5. Export a diff with omnidiff --mode json BEFORE AFTER and inspect the structure.

Small angles to try

• Diff a large refactor made by a coding agent and compare review time with a line diff.
• Try a file in a language outside the 24 supported and see how it falls back.
• Feed the JSON output to a script that counts changed functions.