DEV Community: Yuuki Yamashita

Generating electrode stimulation patterns for a simulated cortical prosthesis

Yuuki Yamashita — Sat, 03 Oct 2026 08:03:34 +0000

Stimulating the visual cortex makes a person see small spots of light called phosphenes. A visual prosthesis built on that has to decide, for every image, which electrodes get how much current. I wrote that step in PyTorch, with a differentiable simulator on the other end that shows what the stimulation would look like. It runs on a laptop CPU, with 100, 1,000 or 10,000 electrodes.

This is a simulation. I did not stimulate anything. The only literature numbers in it are the electrode thresholds, though the cortical map and the simulator's design come from papers too. Here is how it is put together, and the evaluation, which surprised me twice.

Placing electrodes and phosphenes

Vision is distorted on the cortex: the center of the visual field takes far more area than the periphery. The complex logarithm w = log(z + a) approximates that map (Schwartz, Vision Research 1980). I put electrodes on a jittered grid in cortical coordinates, one patch per hemisphere, and mapped them back to the visual field. The value a = 0.75 degrees is my own choice.

z = np.exp(uu + 1j * vv) - A_DEG            # right visual field, in degrees
keep = z.real >= 0.0                        # drop points that cross the vertical meridian
sigma = size_scale * du * (ecc + A_DEG)     # phosphene size grows with eccentricity

Phosphene size is the cortical spread divided by magnification, so it scales with eccentricity plus a. A search over grid sizes gives exactly 100, 1,000 or 10,000 electrodes.

From current to percept

Each electrode has a threshold. Brightness is a sigmoid around it, and the percept is the saturated sum of Gaussian blobs:

def brightness(self, current_ua):
    return torch.sigmoid((current_ua - self.thr) / (SLOPE * self.thr))

def forward(self, current_ua):
    total = self.brightness(current_ua) @ self.basis   # basis: (electrodes, pixels)
    return 1 - torch.exp(-total)

Fernández et al. (2021) reported single-electrode thresholds of 66.8 ± 36.5 µA with a 96-electrode Utah array. I drew thresholds from a lognormal with that mean and SD, clipped to 15 to 140 µA. After clipping the mean is 65.2 and the SD 31.2 µA, so the SD is lower than the paper's. Brightness slope, phosphene size and the 150 µA current limit are my assumptions. The simulator has no timing and no interaction between neighbouring electrodes, and it is a minimal reimplementation inspired by Dynaphos (van der Grinten et al., eLife 2024), not a port.

Three encoders

The encoder decides a target brightness for each electrode, and a mapper turns that into current using estimated thresholds:

def brightness_to_current(b, thr_hat):
    b = b.clamp(0.02, 0.98)
    logit = torch.log(b / (1 - b))
    return (thr_hat * (1 + SLOPE * logit)).clamp(0.0, I_MAX_UA)

Simple sampling: each electrode gets the phosphene-weighted mean of the image
Edges: the same, after a Sobel filter
Learned: a CNN with 107,017 parameters. It looks at the image at three scales and samples its feature maps at each phosphene's position in the visual field. A small head then combines those features with eccentricity, phosphene size, the estimated threshold and the current budget

Because the learned encoder samples features per electrode, one set of weights serves all three electrode counts. A mean-current limit is enforced by scaling all currents down together.

Calibration

A real patient's thresholds are unknown. I simulated the clinic's procedure: for each electrode, a binary search with 7 steps, asking "did you see a spot?" three times per step and taking the majority, against a noisy psychometric response. That is 21 questions per electrode, 21,000 for a 1,000-electrode array. The estimate lands within about 6% of the true threshold, against about 51% when every electrode is assumed to sit at the population mean.

Training

I trained end to end through the simulator for 3,000 steps on synthetic scenes (shapes, lines, letters), taking about 10 minutes on a laptop CPU. Each step picks an electrode count, a layout and threshold set, a calibration state (40% uncalibrated, otherwise noisy estimates up to 35%) and a current limit of none, 40, 25 or 15 µA. The loss is mean squared error plus 0.5 × (1 − SSIM) against a slightly blurred scene, and a small penalty on mean current.

Evaluation

I scored 120 held-out scenes with a simulated patient whose layout jitter and thresholds were not seen in training. Two metrics: SSIM against the blurred scene (large regions), and the correlation between the edge maps of percept and scene (fine detail).

Electrodes	Sampling, uncalibrated	Sampling, calibrated	Learned, calibrated
100	0.030 / 0.351	0.077 / 0.471	0.274 / 0.603
1,000	0.085 / 0.229	0.270 / 0.452	0.540 / 0.568
10,000	0.150 / 0.157	0.470 / 0.431	0.658 / 0.512

Each cell is edge correlation / SSIM. Two results stand out:

Calibration is worth about as much as learning. At 1,000 electrodes, simple sampling goes from 0.085 to 0.270 with calibration, and the learned encoder adds another 0.27
With a 25 µA mean-current limit, the learned encoder at 1,000 electrodes keeps an edge correlation of 0.512, against 0.307 for simple sampling

The two surprises came from looking at things, not from the table. A comparison figure showed a bright vertical stripe down the middle of the simple-sampling percept. The log map overshoots the vertical meridian near the fovea, so left and right electrodes overlapped. Dropping those points and retraining removed it.

The second was SSIM. It did not improve with electrode count and even fell (0.603, 0.568, 0.512 for the learned encoder), which contradicted what the images showed. SSIM against a blurred scene mostly rewards large regions, so a smooth percept from 100 electrodes scores well. I added the edge correlation, which does rise (0.274, 0.540, 0.658). SSIM and MSE are also the training objective, so they favor the learned encoder by construction. Edge correlation was not optimized directly.

Limits

The evaluation uses synthetic scenes, and the simulated patient comes from the same model that trained the encoder, so transfer to a different patient model is unshown. Phosphenes are fixed to the gaze in a real prosthesis, which would need eye tracking that I left out. These are image metrics, not a test with a person.

I ran the demo with my laptop camera, locally and on an EC2 instance behind CloudFront. In both, the image got better as I raised the electrode count. I deleted the AWS resources afterwards.

This covers the output side. For the input side, my earlier post rebuilds a brain-to-text decoder from public neural data.

References

Schwartz, Vision Research 1980: https://www.sciencedirect.com/science/article/abs/pii/0042698980900905
Fernández et al., J Clin Invest 2021: https://www.jci.org/articles/view/151331
Dynaphos (eLife 2024): https://elifesciences.org/articles/85812

Rebuilding a brain-to-text decoder: from 50% to 23.5% word errors

Yuuki Yamashita — Sat, 03 Oct 2026 06:49:28 +0000

People who can no longer speak can still try to, and the motor cortex activity from that attempt can be decoded into text. Willett et al. (Nature 2023) published the neural data behind their speech BCI, so I rebuilt the decoder from it. The model trained on CPUs for about five hours, and the word error rate on 880 test sentences went from 50.0% to 23.5% over four changes (23.0% on a held-out half at the end).

This is an offline reanalysis of recorded data. Here is what each change did and what did not help.

Data

The Dryad release (competitionData, 3.67 GB, CC0) holds 8,800 training and 880 test sentences from one participant with ALS, recorded on 24 days. Following the baseline, I used area 6v only: threshold crossings and spike-band power on 128 electrodes, 256 features per 20 ms bin, z-scored per recording block.

Targets are phonemes, 39 plus silence, from the first CMU dictionary pronunciation. Words missing from the dictionary go through g2p_en.

Model

The model follows the PyTorch baseline (cffan/neural_seq_decoder):

x = F.conv1d(x.transpose(1, 2), self.smooth, padding="same", groups=x.shape[2]).transpose(1, 2)  # Gaussian smoothing
x = torch.einsum("btd,bdk->btk", x, self.day_w[day]) + self.day_b[day]                            # per-day input layer
x = F.softsign(x)
x = self.unfold(x.transpose(1, 2).unsqueeze(3)).transpose(1, 2)                                    # 32 bins, stride 4
h, _ = self.gru(x)                                                                                 # bidirectional GRU
return self.out(h).log_softmax(-1)                                                                 # 40 classes + CTC blank

The per-day input layer absorbs day-to-day drift in what the electrodes pick up. I shrank the GRU from 5 layers and 1,024 units to 3 layers and 512 units (37.8 million parameters) and grouped sentences by length to cut padding. On a c7i.4xlarge with 8 threads that took 1.5 s per batch, against 11.7 s for the baseline size with random batches. 10,000 batches finished in 5 hours 12 minutes.

Greedy phoneme error rate on the test set: 22.2%.

Step 1: nearest words, 50.0%

Splitting the greedy phonemes at silences and replacing each group with the closest word from the training vocabulary gives 50.0% word errors. One wrong phoneme changes the word, and a missed silence merges two.

Step 2: let an LLM write, 34.6%

I gave Claude Sonnet 4.6 (Amazon Bedrock, temperature 0) the top five phoneme strings from a CTC prefix beam search and asked for the sentence. Word errors dropped to 39.2%. The results were uneven, though. With a single candidate, the model rebuilt "do you hear the sleigh bells ringing" perfectly from "dew you he the stable shells using". It also turned the almost-correct "quite a you movie are base off of that" into "why do you think they are based off of that".

When the phonemes are bad, the LLM writes a plausible new sentence. A cheap guard helped. If the LLM's word count differs from the decoder's silence-delimited word count by more than about 11%, keep the no-LLM output. I chose the threshold on one half of the test set and applied it to the other half, which gave 34.6%. Decoder confidence (mean max frame probability, beam score) made a weaker switch, at 38.7 to 39.1%.

Step 3: decode words, let the LLM pick, 26.0%

The guard treats a symptom. The fix was to stop the LLM from writing. I decoded words directly from the CTC output with a lexicon and a 3-gram, using torchaudio's flashlight decoder, and gave the LLM the 10 best sequences to choose from by number:

dec = ctc_decoder(lexicon="lexicon.txt", tokens="tokens.txt", lm="lm.arpa", nbest=10,
                  beam_size=100, lm_weight=1.5, word_score=-1.0, unk_score=float("-inf"),
                  blank_token="-", sil_token="SIL", unk_word="<unk>")

Each lexicon entry ends with SIL, because the training targets put silence after every word. The 3-gram came from the 8,800 training sentences only, written as an ARPA file with absolute discounting and Katz-style backoff. LM weight and word score were picked by 2-fold cross-validation on the test set.

First candidate, no LLM: 29.7%
LLM picks from the top 10: 26.0%

Two traps on the way:

With the full CMU dictionary (about 130,000 words) the error rate jumped to around 90%. My LM gave <unk> about 7% of the probability mass, so every rare dictionary word scored as well as an unknown word and won often. Restricting the lexicon to the LM's 6,569 words fixed it
The decoder's lexicon trie keeps at most 6 words per pronunciation. I write the lexicon in LM frequency order so the rare homophones are the ones dropped

Step 4: a bigger language model, 23.5%

Language model	First candidate	LLM picks from 10
Training sentences only	29.7%	26.0%
LibriSpeech 3-gram, pruned (openslr SLR11)	29.8%	not run
Tatoeba English (about 2.04 million sentences) + training text counted twice, singletons dropped	25.7%	23.5%

LibriSpeech's LM comes from books and did not help, probably because the test sentences are conversational. Tatoeba's short sentences match better. I removed the 39 Tatoeba sentences that were identical to test sentences before building the LM. With it, 297 of 880 sentences came out exactly right, and the oracle (best of the 10 candidates, chosen with the answer) is 19.4%.

Examples where the LLM picked a better candidate than the decoder's first:

they close sometime after eat → they close sometime after eight
i had the bake done on it → i had the brakes done on it
solving the variables in the occasion → solving the variables in the equation

It swapped a correct first candidate for a wrong one in 3 sentences.

What did not help

By now I had made many choices while looking at the test set, so I split it: even sentences for development, odd sentences for evaluation. I compared methods on development only, then ran two of them once each on evaluation: the Sonnet baseline and Opus, the best on development.

Method	Dev (440)	Eval (440)
No LLM	26.1%	25.4%
Sonnet 4.6, top 10	23.8%	23.0%
Sonnet 4.6, top 20	23.9%	—
Sonnet 4.6, top 10 + phoneme string as a hint	25.8%	—
Opus 4.6, top 10	23.4%	23.1%

Opus won on development but tied on evaluation (bootstrap 95% interval of the difference: −18 to +11 words), so I report the Sonnet baseline, 23.0%, as the held-out number. Twenty candidates raised the oracle from 19.6% to 18.7% on development, but the model could not find the extra correct ones. With the phoneme hint, Sonnet explained instead of answering in 401 of 440 calls, and the picks got worse.

The ceiling is the candidate list. Better candidates come from the language model and the acoustic model, not from a smarter selector.

Limits

The model is smaller than the baseline. Training PER was 4.9% against 22.2% on the test set, so generalization is the first thing to fix
I did not use the official large n-gram, which needs around 60 GB of memory to build the decoder graph
Most method choices used cross-validation on the test set. Only the final dev/eval split is a clean held-out evaluation
The paper's 23.8% comes from a different model, language model, vocabulary and evaluation, so it is not a direct comparison

References

Willett et al., Nature 2023: https://www.nature.com/articles/s41586-023-06377-x
Dataset (Dryad, CC0): https://datadryad.org/dataset/doi:10.5061/dryad.x69p8czpq
PyTorch baseline: https://github.com/cffan/neural_seq_decoder
Card et al., NEJM 2024: https://www.nejm.org/doi/full/10.1056/NEJMoa2314132
LibriSpeech LM (openslr SLR11): https://www.openslr.org/11/
Tatoeba: https://tatoeba.org (English sentences, CC BY 2.0 FR)

What it takes to remove the monitor and keyboard: decoders, projection and phosphenes

Yuuki Yamashita — Tue, 29 Sep 2026 07:37:26 +0000

The question that started this: can AI send signals into a brain so that an image shows up on someone's retina? I wanted to see AI output with my own eyes and skip the keyboard. I have not built anything yet, so this post is a technical survey of the pieces and a plan for what can be reproduced in software. Figures come from papers and official announcements, and I mark the ones I could only confirm through press reports.

One correction to the question first. The retina is the input side of vision, and I found no path that sends an image back to it. An image delivered through the brain forms in the visual cortex instead. That gives two independent problems: getting intent into the AI (input) and getting the AI's output into my vision (output).

Input: how a brain-to-text decoder works

The systems that work today read attempted speech from motor areas, not free thought. The pipeline in Willett et al. (Nature 2023) is a good baseline:

256 intracortical electrodes in total, recorded from a person with ALS
Neural features binned into short time windows
A recurrent network trained with CTC loss that outputs phoneme probabilities
A 3-gram language model over a 125,000-word vocabulary to turn phonemes into words

Result: 62 words per minute, with a 9.1% word error rate on a 50-word vocabulary and 23.8% on 125,000 words. Card et al. (NEJM 2024) later added large language model rescoring, and held 97.5% accuracy for 8.4 months at about 32 words per minute. Metzger et al. (Nature 2023) used 253-channel surface electrodes instead and reported 78 words per minute with a 25.5% error rate on general sentences from a 1,024-word vocabulary.

The hard part is not the model size. Signals drift from day to day as electrodes shift, so these decoders recalibrate. A common trick is a separate input layer per recording day. Here is a sketch in PyTorch, with placeholder sizes, that I have not run:

import torch
import torch.nn as nn

class SpeechDecoder(nn.Module):
    def __init__(self, n_days, n_feat=256, hidden=512, n_phonemes=40):
        super().__init__()
        # one input layer per recording day absorbs electrode drift
        self.day_in = nn.ModuleList([nn.Linear(n_feat, n_feat) for _ in range(n_days)])
        self.gru = nn.GRU(n_feat, hidden, num_layers=3, batch_first=True, dropout=0.3)
        self.out = nn.Linear(hidden, n_phonemes + 1)  # +1 for the CTC blank

    def forward(self, x, day):
        x = torch.tanh(self.day_in[day](x))
        h, _ = self.gru(x)
        return self.out(h).log_softmax(-1)

ctc = nn.CTCLoss(blank=0, zero_infinity=True)

Latency has a floor too. Wairagkar et al. (Nature 2025) synthesized voice from a 256-electrode implant with neural processing inside 10 ms. Listeners transcribing the result had a median word error rate of 43.75%, against 96.43% for the participant's own unaided speech.

Inner speech is an open question. Kunz et al. (Cell 2025) decoded some inner speech in four participants, with word error rates of 26 to 54% at 125,000 words. They also tested a safeguard: the decoder unlocks only when the person imagines a keyword (the paper uses "Chitty Chitty Bang Bang"), and detection exceeded 98%. Without electrodes the numbers drop. The Brain2Qwerty preprint reports character error rates of 32% with MEG and 67% with EEG.

The practical non-invasive route is muscle activity. The Nature 2025 paper behind Meta's Neural Band trained a surface EMG model that works without per-person calibration, at 20.9 words per minute for handwriting in the air. It shipped on September 30, 2025, bundled with the Ray-Ban Display.

Output: two ways to put AI output into my vision

Retinal projection is an optics problem

A beam focused at the pupil center, sometimes called a Maxwellian view, keeps the image sharp regardless of the eye's focus. QD Laser's retinal scanning display works this way, with RGB lasers and a MEMS mirror. Meta's Orion (a 70 degree prototype, per press reports) and Ray-Ban Display (one eye, reported as 600 by 600 pixels) use waveguides, which is a different approach.

The constraints come from the conservation of etendue. Field of view and eyebox trade off, so a wide view with a tolerant eyebox needs bigger optics. Two things follow:

The exit pupil has to track the gaze, so eye tracking latency decides whether the image survives a saccade
At 60 pixels per degree, a 100 by 100 degree view is about 36 million pixels per eye (my arithmetic), so foveated rendering is close to mandatory

Software can help in the loop. Neural holography (Peng et al., SIGGRAPH Asia 2020, code on GitHub) trains the hologram computation with the camera in the loop, which absorbs real hardware error. The point for a cloud design is that gaze tracking and pupil steering must stay on the device. The generated image can come from the cloud.

Cortical stimulation is an encoding problem

A stimulation pipeline needs to answer: for a target image, which electrodes fire, and at what current? A workable structure has four layers:

A map from each electrode to the phosphene it produces (position, size, brightness)
A differentiable simulator that predicts the percept from the stimulation
An encoder network trained end to end through that simulator
Per-patient tuning from the patient's reports

stim = encoder(frame)             # (batch, n_electrodes) currents
percept = simulator(stim)         # differentiable phosphene image
loss = torch.nn.functional.mse_loss(percept, simplified_scene)

Dynaphos (van der Grinten et al., eLife 2024) is a PyTorch simulator for step 2. The evidence for the underlying effect is small so far. Fernández et al. (2021) implanted a 96-electrode Utah array in a fully blind 57-year-old participant for six months, and the participant identified some letters and object outlines. Beauchamp et al. (Cell 2020) traced letters by stimulating electrodes in sequence, and four sighted and two blind participants recognized them. Chen et al. (Science 2020) got monkeys to perceive shapes through 1,024 channels.

The bandwidth gap explains why this is slow. The retina's output is estimated at about 10 Mbps, extrapolated from guinea pig recordings of about 100,000 ganglion cells (Koch et al., 2006). Even counting one bit per pulse, a 1,000-electrode implant stimulated 10 times a second carries about 10 kbps, three orders of magnitude below that (my own estimate). Neuralink's Blindsight got an FDA Breakthrough Device designation in September 2024, but I could not confirm a human implant.

What can be reproduced in software

Datasets exist for each piece:

Piece	Data or tool
Speech decoder	Willett 2023 data on Dryad, and Kaggle's Brain-to-Text '25 built on the data from Card et al.
EMG typing	emg2qwerty (NeurIPS 2024, 108 people, 346 hours, CC BY-NC-SA 4.0)
Phosphene simulation	Dynaphos, and pulse2percept for retinal implants
Hologram computation	The neural holography code from Stanford

On AWS, a replay of recorded data can run through AWS IoT Core or Amazon Kinesis Data Streams into an Amazon EC2 GPU instance for the decoder, with Amazon Bedrock for language model rescoring. A second EC2 GPU instance can run the phosphene simulator, and Amazon DCV can stream the result to a browser. When I checked in September 2026, my account's Amazon SageMaker AI quota for GPU training jobs was 0, so training would use EC2 GPU instances, or CPU for a small GRU.

Where I would start

A simulated cortical vision demo: a webcam frame becomes the phosphene image that 1,000 electrodes could produce. It needs no data collection and runs entirely in software. Replaying a public brain-to-text dataset through the decoder comes next. Electrodes and optics stay out of reach for now, and I would not claim otherwise.

References

Willett et al., Nature 2023: https://pmc.ncbi.nlm.nih.gov/articles/PMC10468393/
Metzger et al., Nature 2023: https://www.nature.com/articles/s41586-023-06443-4
Card et al., NEJM 2024: https://doi.org/10.1056/nejmoa2314132
Wairagkar et al., Nature 2025 (press release): https://www.eurekalert.org/news-releases/1087025
Kunz et al., Cell 2025: https://pubmed.ncbi.nlm.nih.gov/40816265/
Brain2Qwerty (arXiv): https://arxiv.org/abs/2502.17480
Meta sEMG, Nature 2025: https://www.nature.com/articles/s41586-025-09255-w
Fernández et al., J Clin Invest 2021: https://www.jci.org/articles/view/151331
Beauchamp et al., Cell 2020: https://www.cell.com/cell/fulltext/S0092-8674(20)30496-7
Chen et al., Science 2020: https://www.science.org/doi/10.1126/science.abd7435
Koch et al., Current Biology 2006: https://www.cell.com/current-biology/fulltext/S0960-9822(06)01639-3
Dynaphos (eLife 2024): https://elifesciences.org/articles/85812
Neural holography: https://github.com/computational-imaging/neural-holography
Willett 2023 dataset (Dryad): https://datadryad.org/dataset/doi:10.5061/dryad.x69p8czpq
Brain-to-Text '25 (Kaggle): https://www.kaggle.com/competitions/brain-to-text-25
emg2qwerty: https://github.com/facebookresearch/emg2qwerty
Neuralink Blindsight (FDA designation): https://neuralink.com/updates/neuralink-receives-breakthrough-device-designation-for-blindsight/

I Asked Claude Code Why AI Labs Suddenly Want to Slow AI Down

Yuuki Yamashita — Mon, 14 Sep 2026 01:38:18 +0000

The trigger

On September 12, 2026, three competitors, Anthropic, OpenAI, and xAI, all said roughly the same thing within hours of each other: AI development needs to slow down. Companies that fight over the same enterprise contracts and the same researchers do not usually agree on anything in public. So I opened Claude Code and asked it to walk through what was actually going on.

Round one: the nuclear weapons comparison

My first question was whether this looked like the nuclear non-proliferation playbook: the people who built the weapon are the ones who later argue loudest for controlling it.

Claude Code's answer split the comparison into what holds and what does not. What holds: the leading developer warning about the danger of what it built, and a first mover shaping the resulting regulation in a way that locks in its own position, is a real structural echo of the NPT era. What breaks down: nuclear proliferation has a physical bottleneck, uranium enrichment, that can be detected from orbit. AI capability spreads at the speed of compute and data, with no equivalent tripwire. Nuclear weapons are held specifically to never be used; frontier AI models are built specifically to be used, constantly, for profit. The incentive structures point in opposite directions.

Round two: fact-checking the essay itself

Rather than take the "slow down" framing at face value, I had Claude Code pull the actual source: Dario Amodei's essay "We Must Pace the Frontier." Worth doing, because most coverage ("AI CEOs want to slow AI down") undersells what he is actually proposing. He is explicit that pacing "does not mean halting model training." The real ask is third-party testing across four risk categories, permanent embedded evaluators inside Anthropic, and an antitrust carve-out so labs can coordinate on safety without violating competition law.

That last item is the one critics keyed in on. Chamath Palihapitiya's response on X: "Dario makes the case to stop open source and concentrate enormous technological and economic power with Anthropic." Whether or not you buy that read, it is a materially different claim than "Anthropic wants AI to be safer," and it is worth knowing both versions exist before writing a hot take.

Round three: the detail I almost missed

I asked Claude Code to check whether anything else happened around that week that might be relevant. It surfaced a threat intelligence report Anthropic had published two days earlier, on September 10: seven Chinese AI labs, including Moonshot AI (maker of the Kimi models), accused of large-scale distillation of Claude, GPT, Gemini, and Grok. The specific claim against Moonshot: roughly 300,000 requests routed to Claude over ten days through a network of over 5,000 fraudulent accounts, with Claude's answers served back to users labeled as Kimi's own. US intelligence agencies backed the concern.

Two days between that report and the "slow the frontier" essay is a short gap. Claude Code was careful not to claim a confirmed causal link, correctly, since none of the primary sources draw one. But it flagged the sequence as worth including, because both stories run on the same anxiety: capability spreading somewhere it should not.

Round four: the rumor that did not survive fact-checking

The same week, a rumor was circulating that Huawei's founder and his family had fled China. I asked Claude Code to fold that into the piece too. It refused to treat it as established, and pushed back before writing anything: the only source was a single screenshot posted to Chinese social media, the original poster had called it unverified, Huawei and Chinese authorities had not commented, and Chinese social media reaction skewed skeptical. It is in this piece as an unconfirmed rumor that circulated the same week, not as evidence of anything.

It would have been easy to let an interesting-sounding rumor slide into a paragraph about geopolitical pressure without that check. Separating what is verified from what is circulating on social media, before it goes into a draft, is the step that gets skipped most often when writing under deadline.

Takeaway

No single motive explains three competitors agreeing in public. Some of the fear about near-term AGI timelines is probably genuine. The specific regulatory ask looks a lot like regulatory capture. And the timing next to the distillation report suggests a geopolitical containment story running underneath the safety framing. All three can be true at once, which is a less satisfying headline than any one of them alone, but it is the one the primary sources actually support.

Sources: Dario Amodei, "We Must Pace the Frontier", Axios, Chamath Palihapitiya on X, CoinDesk on the Moonshot/Kimi distillation report. The Huawei rumor traces to a single unverified screenshot with no mainstream corroboration; see this Japanese-language writeup for the closest thing to a source trail.

I Tested Whether cdkd Really Deploys Faster Than cdk deploy

Yuuki Yamashita — Thu, 03 Sep 2026 15:58:25 +0000

A tool claiming "up to 15x faster than cdk deploy" showed up in my feed a while back. Drop-in replacement, it said: keep your CDK app exactly as it is, just swap cdk deploy for cdkd deploy.

I've learned to be skeptical of "Nx faster" claims. So I actually deployed something real to AWS with both tools and timed it. Short version: it really is that fast.

What cdkd actually is

cdkd deploys an existing AWS CDK app without going through CloudFormation. It calls the AWS SDK directly instead. It's built by go-to-k (Kenta Goto), an AWS DevTools Hero and CDK top contributor who also maintains cls3 (a fast S3 bucket emptier) and delstack (for cleaning up stuck CloudFormation/CDK stacks) — tools that quietly fix the annoying parts of working with AWS. cdkd feels like the biggest one yet, and I mean that as a compliment grounded in actually using it, not a throwaway one.

The mechanism is straightforward. cdkd runs the exact same CDK synth step as the CDK CLI, producing the same CloudFormation template. What changes is everything after that: instead of handing the template to CloudFormation, cdkd's own engine reads the resource dependency graph (Ref, Fn::GetAtt), builds a DAG, and fires AWS SDK / Cloud Control API calls directly, in parallel, as soon as each resource's dependencies are satisfied.

Worth saying up front: cdkd calls itself not production-ready, dev/test only. This isn't a "replace CloudFormation in prod" pitch.

I actually ran both, on real AWS

cdkd's own README backs up the 15x number with a VPC + Lambda + SQS + CloudFront benchmark. So I wrote that same stack as a CDK app and deployed it twice — DeployRaceCfn via cdk deploy, DeployRaceCdkd via cdkd deploy — to the same AWS account, same region (ap-northeast-1).

The stack:

VPC (2 AZ + NAT Gateway) with a Lambda inside it, fronted by a Function URL
CloudFront, origin set to that Function URL
SQS + EventSourceMapping + a consumer Lambda

First attempt failed. The account had hit its VPC limit (five, the default):

Resource handler returned message: "The maximum number of VPCs has been reached.
(Service: Ec2, Status Code: 400, ...)"

Other test stacks in the same account were sitting on VPCs I'd forgotten about. I tore down the cdkd stack (already measured, no longer needed) to free a slot and reran. cdkd writes a structured event log to S3 on every run (cdkd events), so even the failed attempt was easy to diagnose after the fact.

Timing compares the deploy phase only. Synth is identical work either way (same aws-cdk-lib), so I excluded it, matching how cdkd's own benchmarks are measured. The cdk deploy timeline comes from CloudFormation's DescribeStackEvents; the cdkd deploy timeline comes from cdkd events <stack> --run <id> --format json, reading the RESOURCE_STARTED / RESOURCE_SUCCEEDED events it records itself.

The numbers

	cdk deploy	cdkd deploy
Time	479.3s	95.0s
Resources created	34	33

5.0x. The one extra resource on the CloudFormation side is AWS::CDK::Metadata, a bookkeeping resource that only exists there — both sides build the same 33 real resources.

Watching cdkd deploy run, IAM roles and route tables land in a burst right at the start:

[1/33] ✓ RaceQueueE818AC65 (AWS::SQS::Queue) created
[2/33] ✓ RaceVpcIGW94C1C01D (AWS::EC2::InternetGateway) created
[3/33] ✓ RaceVpcPublicSubnet1EIPC3B3497E (AWS::EC2::EIP) created
[4/33] ✓ ConsumerFunctionServiceRole68E8FEB1 (AWS::IAM::Role) created
[5/33] ✓ MainFunctionServiceRole8C918DF0 (AWS::IAM::Role) created
...
CloudFront Distribution Distribution830FAC52 accepted (not waiting for Deployed; pass --full-wait to wait)
Deployment Summary:
  Created: 33 / Duration: 94.99s

Meanwhile cdk deploy takes 16.6 seconds just to get its first VPC. By that point cdkd already has the Lambda wired up to SQS.

Where the time actually goes

cdk deploy hands the template to CloudFormation, which creates resources one at a time. cdkd reads the same template's dependency graph itself and calls the AWS SDK / Cloud Control API directly, in parallel, as soon as dependencies clear. Cutting out the CloudFormation middleman is most of the story, but two specific waits explain most of the 384-second gap.

The NAT Gateway is the first one. cdk deploy works through the SQS/Lambda side of the graph before it gets around to waiting on the NAT Gateway to come up. cdkd hits that wait much earlier. Same AWS-side wait either way — what differs is how early in the run you eat it.

CloudFront is the bigger one. CloudFormation's default behavior waits until the distribution reaches Deployed — full global propagation, three-plus minutes. cdkd's default returns as soon as CreateDistribution is accepted (there's a --full-wait flag if you want CloudFormation's behavior instead). Of the 479.3 seconds cdk deploy took, 183 of them — over three minutes — are spent solely on that one wait.

This might actually change how people deploy

I'll admit it: the slowness of iterating on a real AWS resource is part of why people reach for Vercel or Amplify instead. Build a VPC + Lambda + CloudFront stack in CDK and every check-your-work loop costs minutes, sometimes double digits of them.

cdkd doesn't replace CloudFormation's state management, drift detection, or rollback handling, and it says so itself. But "CloudFormation in prod, cdkd while iterating" is now a real option, not a hypothetical. A CI pipeline that rebuilds a PR environment on every push, or just the apply-then-check loop on your own machine, running five times faster is enough to make "AWS-native is slower to iterate on than Vercel or Amplify" stop being true for a chunk of use cases.

I also built an interactive replay of the actual measured timeline, plus a narrated demo video, if you want to see the two runs side by side.

cdkd is go-to-k/cdkd (Apache-2.0). Worth a star if this was useful.

Detecting Shadow AI Agents with AWS Agent Registry

Yuuki Yamashita — Tue, 01 Sep 2026 02:56:07 +0000

AWS Agent Registry (GA August 2026) gives a team a private catalog for AI agents, MCP servers, and tools — semantic search, approval workflows, CloudTrail audit trails. What it doesn't give you out of the box is a way to find the agents that were never registered in the first place.

This is a pattern for closing that gap: scan the AWS account for AgentCore runtimes, diff them against what's actually in the registry, and route anything unregistered through a real approval flow before it becomes a permanent record. I built it as Shadow Agent Hunter; this post is about the Agent Registry API details that made it work (and the ones that didn't, at first).

The three API calls that matter

Agent Registry splits into a control plane (agent-registry-control) for managing registries and records, and a data plane (agent-registry) for searching approved ones.

Finding what's already registered. list_registry_records returns every record regardless of status, so pending/draft records don't get re-flagged on a rescan either:

import boto3

control = boto3.client("agent-registry-control", region_name="us-east-1")
registered_names = set()
next_token = None

while True:
    kwargs = {"registryId": registry_id}
    if next_token:
        kwargs["nextToken"] = next_token
    resp = control.list_registry_records(**kwargs)
    registered_names.update(r["name"] for r in resp["registryRecords"])
    next_token = resp.get("nextToken")
    if not next_token:
        break

I originally reached for the provenance field here, expecting to link records back to their source AgentCore runtime ARN. Don't — create_registry_record rejects a caller-supplied provenance with ValidationException: provenance cannot be set by the caller. It's populated only by the service's own auto-detection/sync integrations, not by a plain API call. Matching on record name is simpler anyway, since names are unique within a registry.

Searching for duplicates. search_discoverable_registry_records does hybrid semantic + keyword search, ordered by relevance:

registry = boto3.client("agent-registry", region_name="us-east-1")
resp = registry.search_discoverable_registry_records(
    searchQuery=f"{runtime_name} {runtime_description}",
    registryIds=[registry_arn],
    maxResults=3,
)

There's no numeric score in the response — just an ordered list. With a small registry (say, two or three approved records), that means it always returns something, even for genuinely unrelated runtimes, because there's nothing better to rank against. This isn't a bug so much as a reminder that semantic search needs a reasonably sized corpus to actually discriminate. It's also a decent argument for keeping a human in the approval loop rather than auto-rejecting on any hit.

Writing the approval. Three sequential calls: create, submit, approve.

created = control.create_registry_record(
    registryId=registry_id,
    name=runtime_name,
    description=description,
    recordType="CUSTOM",
    recordVersion="1.0",
    descriptors={"custom": {"data": json.dumps({"runtimeArn": runtime_arn})}},
)
record_id = created["recordArn"].split("/record/")[1]  # not returned directly

# record starts CREATING and must reach DRAFT before you can submit it
for _ in range(15):
    status = control.get_registry_record(registryId=registry_id, recordId=record_id)["status"]
    if status == "DRAFT":
        break
    time.sleep(1)

control.submit_registry_record_for_approval(registryId=registry_id, recordId=record_id)
control.update_registry_record_status(
    registryId=registry_id, recordId=record_id,
    status="APPROVED", statusReason="Reviewed and approved",
)

Two things worth flagging: CreateRegistryRecordResponse only returns recordArn and status — no recordId field, so you extract it from the ARN — and creation is asynchronous, so a record submitted for approval before it leaves CREATING will fail.

Cross-referencing with AgentCore Runtime and CloudTrail

The other half of "shadow agent" detection is enumerating what's actually running, independent of the registry:

agentcore = boto3.client("bedrock-agentcore-control", region_name="us-east-1")
runtimes = agentcore.list_agent_runtimes()["agentRuntimes"]

The IAM action for this is bedrock-agentcore:ListAgentRuntimes — note the namespace is bedrock-agentcore, not bedrock-agentcore-control like the SDK package name would suggest. Getting this wrong produces a plain AccessDeniedException with no hint about the namespace mismatch.

For attribution — who deployed an unregistered runtime — CloudTrail's LookupEvents over CreateAgentRuntime gets you there, with the usual 90-day retention caveat:

cloudtrail = boto3.client("cloudtrail", region_name="us-east-1")
resp = cloudtrail.lookup_events(
    LookupAttributes=[{"AttributeKey": "EventName", "AttributeValue": "CreateAgentRuntime"}],
)
for event in resp["Events"]:
    detail = json.loads(event["CloudTrailEvent"])
    arn = detail.get("responseElements", {}).get("agentRuntimeArn")
    deployer = detail.get("userIdentity", {}).get("arn")

Infra notes

Agent Registry has no CDK construct as of September 2026 — no AWS::AgentRegistry::Registry CloudFormation resource type exists yet. I provisioned the registry and its seed records with the boto3 script above rather than CDK. AgentCore Runtime, by contrast, has a stable L2 construct (aws_bedrockagentcore.Runtime), and AgentRuntimeArtifact.fromCodeAsset() deploys straight from a local Python directory with no Docker step.

If you're running this on Vercel with OIDC federation to AWS: the OIDC provider is scoped per Vercel team, not per project. A second project under the same team hitting new iam.OpenIdConnectProvider(...) will fail deployment, since an AWS account only accepts one provider per issuer URL. Import the existing one with iam.OpenIdConnectProvider.fromOpenIdConnectProviderArn() instead of creating a second.

Result

Scanning an account with a couple of intentionally-similar and intentionally-unrelated AgentCore runtimes: the similar one surfaces a real "possible duplicate" match against an existing approved record, and approving the unrelated one produces a genuine APPROVED record you can see with list-registry-records afterward — not a mock, the actual governance workflow AWS Agent Registry ships.

The Legal Wall I Hit Building a YouTube Clone on AWS

Yuuki Yamashita — Wed, 26 Aug 2026 16:31:29 +0000

Right now I'm testing how far you can push a YouTube-style video platform built entirely on AWS. Upload, transcode, stream — EC2, S3, and CloudFront handle all of that without much drama. Then I started sketching out a comment section and a direct-message feature between users, and I stopped typing.

Wait. Does this need a government license now?

That one question sent me down a rabbit hole through Japan's Telecommunications Business Act, Copyright Act, and a law with an even longer name that regulates online platforms. None of this is legal advice — I'm not a lawyer, just a developer who got nervous enough to read the actual statutes. If you're building something for real users at scale, talk to an actual lawyer. But if you're a solo developer wondering whether your side project is quietly illegal, this is the walkthrough I wish existed.

Japan's Telecommunications Business Act: the "are you a phone company" test

Japan has a law called the Telecommunications Business Act (電気通信事業法). In the simplest possible terms: it's the law that decides whether your app is legally acting like a phone company, and if so, whether you need to tell the government about it.

There are two tracks. Article 9 requires full registration, and it only kicks in if you own and operate your own transmission lines — think an actual telecom carrier laying fiber. Article 16 requires a lighter-weight notification, and it applies to almost everyone else who runs a communications service without owning that physical infrastructure. Since your app sits on AWS rather than your own fiber network, Article 16 (notification) is the one that could apply to you, not Article 9.

Whether it actually applies comes down to one test: are you mediating communication between other people? A one-way video stream — you upload, others watch — is your own communication going out to viewers. It's not you relaying messages between two other people, so it generally falls outside the notification requirement. Add a DM feature, a live chat relay, or real-time comment broadcasting between users, though, and you start looking a lot more like a company that carries other people's messages, which is exactly what the law is watching for.

If you're the only one who can upload, you're basically fine

Here's the scorecard for a video app where you're the only content creator — think a personal portfolio site that happens to look like YouTube.

Telecommunications Business Act notification isn't required, because you're not relaying anyone else's communication. The Information Distribution Platform Act (more on that below) doesn't apply either, since there's no user-generated content for anyone to complain about. Japan's Act on the Protection of Personal Information technically applies the moment you add user accounts or store watch history, but for a small non-commercial project, a basic privacy policy covers you in practice.

If this describes your project, you can build it, ship it, and move on — the same way you'd treat any other side project.

The moment strangers can upload, the rulebook gets thicker

Turn on user uploads for everyone, and you've built a real user-generated-content platform. That changes things.

The Telecommunications Business Act question gets murkier once you add DMs or chat, but realistically, the enforcement risk for a small side project is close to zero — call it a legal gray zone rather than a hard stop.

The law that actually matters here is Japan's Information Distribution Platform Act (情報流通プラットフォーム対処法), which took effect on April 1, 2025. It's the successor to what used to be called the Provider Liability Limitation Act, and at its core it requires any platform hosting user content to have a way for people to report defamatory or copyright-infringing material and get it taken down. If you're running a UGC service, you need this regardless of size — but in practice, for a solo project, that requirement is satisfiable with a single email address people can send takedown requests to.

The obligations scale up hard once you're huge. If your platform averages more than 10 million senders a month, or 20 million total, the government designates you a "large-scale specified telecommunications service provider" and you owe additional obligations like publishing your takedown response record. As of April 2025, the companies actually carrying that designation are Google, LY Corporation (LINE Yahoo), Meta, and TikTok. A solo developer isn't getting anywhere near that threshold, which is why the lightweight version — one inbox, checked occasionally — is a realistic bar to clear.

There's also a quieter risk: if your platform lets anyone upload anything, someone eventually will upload something they don't own the rights to. If your code is open source on GitHub, that's a separate reputational problem worth thinking about even before the legal one.

The real trap was copyright law

After all that, the thing that actually surprised me wasn't the telecom law or the platform law. It was copyright.

Japan's Copyright Act defines "the public" in a way that's broader than it sounds. Article 2, paragraph 5 states that "the public," for purposes of this law, includes "specific and numerous persons" — not just strangers off the street. In plain English: even if everyone who can see your content is someone you personally know and approved individually, if that group gets large enough, the law can treat it the same as posting it publicly. There's no hard headcount in the statute, but the widely cited rule of thumb among Japanese IP lawyers is that once you're past roughly 50 people, you're squarely in "many" territory, and past legal disputes have used numbers like 300+ as clearly qualifying.

Then there's Article 23, covering the public transmission right. For anything automatically deliverable over a network — which covers basically all web and app content — this right also covers something Japanese law calls "making transmittable" (送信可能化). That means the right is triggered the moment content becomes available for someone to access, whether or not anyone has actually clicked play yet. "Nobody's actually watched it, so I'm fine" doesn't hold up as a legal argument under this framework.

The counterweight is Article 30, the private-use exception. Using copyrighted material within a genuinely private circle — yourself, your family, people you live with — is exempt. Courts have described the boundary as "an extremely limited circle of personal relationships." A 2022 Supreme Court case involving JASRAC (Japan's music licensing body) and music schools is a good real-world illustration: the court found that a teacher performing music for students, one at a time, still counted as a "public" performance, because the audience rotated through an effectively unlimited stream of students over time. The lesson generalizes: an audience made of individually-approved people can still add up to "public" if it's large enough or churns enough.

Passwords don't automatically make something private

I went into this assuming that if I gated content behind a login and personally approved every viewer, I was safely inside the private-use exception. That turned out to be only half true.

What decides the boundary isn't whether there's a password. It's who's on the other side of it, and how many of them there are. Family and people you live with land solidly inside the private-use exception — courts have consistently protected that "extremely limited circle." Once you're individually approving friends and acquaintances, the calculus shifts: the more people you add, and the less close the relationship, the more likely a court would call that group "specific and numerous" rather than private, regardless of whether you technically required a password to get in. A login screen controls access technically. It says nothing about whether the underlying use is legally private.

The uncomfortable implication is that "approve anyone who asks" as a growth strategy — the design pattern, not any specific headcount — reads legally closer to "public" than "private," because the pool has no real ceiling.

One important caveat, since a reader flagged this after the Japanese version of this post went semi-viral on X: all of this only matters if the content isn't fully yours to begin with. If you personally shot, wrote, and own every frame of what you're distributing, the public-transmission and private-use analysis above is close to irrelevant — copyright belongs to the creator, and you're free to distribute your own original work to as many people as you want. Where this actually bites is content that includes someone else's copyrighted material without permission: a recording that happens to pick up background music, a clip of broadcast TV, a screen recording that captures someone else's copyrighted app or footage. The moment third-party material is baked into what you're distributing, the "how many people, how close are you to them" analysis above is what determines your exposure.

Add payments or age gates, and yet more laws show up

Everything above covers just the core of a video platform. Add features, and you pick up more regulatory surface.

The moment you're storing watch history or account data, Japan's Act on the Protection of Personal Information kicks in — a privacy policy that states your purpose of use is the baseline expectation. If minors might realistically use your service, the Act on Development of an Environment that Provides Safe and Secure Internet Use for Young People brings in expectations around age verification and filtering. And if you add tipping, subscriptions, or ad revenue sharing — anything that moves money — the Payment Services Act and the Act on Specified Commercial Transactions apply separately.

For a personal, non-commercial project, this tier is "know it exists, revisit it if you add the feature" rather than something to solve up front.

So what does a solo developer actually need to do

The pattern that emerged after all this reading: the real dividing line isn't "can other people upload," it's "is this actually public." A fully private deployment — access-controlled, URL not shared anywhere — falls inside the private-use exception with real room to spare. Even if a video you personally recorded happens to capture copyrighted material in the background, keeping it to private viewing is generally fine.

The moment you deploy publicly, or post the URL on a blog where anyone can find it, you've crossed into public transmission, and the private-use exception no longer covers you — even if you're the only person who ever uploaded anything, placing unlicensed third-party material there can be infringing.

Three things made this manageable for a solo project. First, keep access genuinely locked down — authentication plus a URL you don't publish — if you want to stay inside the private-use exception. Second, for anything you do deploy publicly or show in a GitHub README, use only material you made yourself or that's explicitly license-free; no copyrighted broadcast footage, no commercial music tracks. Third, add a line to your README or terms of service stating the app is intended for the creator's personal use and isn't designed for uploading third-party copyrighted material — it won't prevent a determined bad actor, but it's a reasonable statement of intent if the question ever comes up.

Building something like automated audio fingerprinting to detect infringing uploads is overkill for a single-user, access-controlled personal project. Locking down access and being deliberate about demo content covers the realistic risk at this scale.

Closing thought

I genuinely expected video streaming to be a solved, boring technical problem by now. I did not expect to spend this much time in statute text. The good news is that a personal, single-user version of this project needs essentially no legal paperwork. The part that actually changed my mental model was realizing that "I put a password on it" doesn't automatically mean "this is private" under Japanese copyright law — that one took a re-read to sink in.

Still testing how far this goes on AWS. More to come if there's more to find.

Autonomy for $20, a Human Above It: A Pattern for AI Agents That Spend Money

Yuuki Yamashita — Wed, 26 Aug 2026 08:27:21 +0000

At some point every "agentic" product roadmap runs into the same uncomfortable question: what happens when the agent needs to actually spend money, not just recommend an action to a human who then clicks a button? Recommending is easy to sandbox. Spending isn't. And the usual answers — "just require approval for everything" or "just trust the agent" — both fail in an obvious way. Approve-everything means the agent isn't really autonomous, it's a slow suggestion box. Trust-the-agent means the first bad prompt injection or hallucinated tool call has a direct line to your bank balance.

I wanted to see what a middle position actually looks like in code, not in a slide. So I built a small agent, sera-gate-agent, that pays multi-currency invoices for you and enforces a rule most people would agree with intuitively: small payments go through on their own, larger ones stop and wait for a person.

The trigger: a protocol that treats a keypair as a login

The settlement side runs on Sera, an on-chain FX protocol with an MCP server (sera-mcp) released under MIT specifically so agents can call it. What made me want to build on it wasn't the currency coverage, it was the auth model: there's no signup form. You generate a keypair, sign an EIP-712 message with it, and that signature is your API key request. A human finds this mildly inconvenient. An agent finds it exactly as convenient as an auth flow can be — no page to navigate, no CAPTCHA, no session cookie, just a key it already has.

That detail is what made "give the agent a wallet" feel like a natural next step rather than a stunt. If the whole point of an agent is that it acts without a human driving each click, an auth system built around clicking a human through steps is already fighting the premise.

The design: one number, one gated function

The rule I wanted was simple enough to say in one sentence: under $20, the agent executes on its own; over $20, it issues an approval card and a human has to click "approve" in a browser before anything moves. The part that took actual thought wasn't the rule, it was making sure the rule couldn't be talked around.

The threshold check itself is almost embarrassingly small:

def decide_auto_or_approval(amount_usd):
    threshold = Decimal(os.environ.get("SERA_GATE_AUTO_THRESHOLD_USD", "20"))
    return "AUTO" if amount_usd <= threshold else "REQUIRE_APPROVAL"

What matters more is where it's called from. The underlying protocol exposes tools that actually move funds — execute a swap, send a transfer, pay an invoice directly. None of those are given to the language model. The only thing the model can call is a wrapper function, and that wrapper is the only code path that's allowed to reach the real execution tools. The threshold check lives inside that wrapper, not in a prompt instruction telling the model to "please ask before spending more than $20."

That distinction is the whole point, and it's easy to gloss over. A system prompt is a request. A model that's very good at following instructions will follow it correctly almost all the time — but "almost all the time" is a bad security property for something that moves money, whether the failure mode is prompt injection, a weird edge case in tool output, or the model just deciding the instruction doesn't apply this time. Removing the tool from the model's reachable set removes the failure mode instead of making it rarer.

I also didn't want the agent-side threshold to be the only backstop. Sera has its own server-side policy preset that caps what any single API key can move per transaction and per day, independent of anything my code does. I keep that ceiling well above my $20 agent-side threshold, so it's a true second layer rather than a duplicate of the first — if my code has a bug, or the signing key leaks, there's still a hard ceiling that doesn't route through my logic at all.

What this generalizes to

None of this is specific to on-chain payments. The same shape applies to an agent that can issue refunds, send emails to customers, delete records, or push a deploy: pick a dimension the org already has intuitions about (dollar amount, blast radius, reversibility), pick a threshold, and make the boundary a property of which functions are reachable rather than a property of what the model has been told. The dollar threshold is just the easiest one to make legible in a demo, because everyone already has an intuition for what $20 versus $5,000 means.

The uncomfortable part, and I don't think there's a clean answer to it, is that the threshold is still a judgment call, and it's a judgment call about how much you trust a system that doesn't get tired, doesn't get talked into things the way a person does, but also doesn't have the context a person has for "this specific invoice looks off." Setting it too low turns the agent back into a suggestion box. Setting it too high means the day it's wrong, it's wrong at a scale a human never got the chance to catch. I don't think that number should be static — the next version of this probably ties it to something like payee history or a running risk score instead of a flat constant — but getting the enforcement boundary right, structurally, felt like the part worth building first.

sera-gate-agent runs on Sepolia testnet today, built on AWS Bedrock AgentCore Runtime and Strands, with a Next.js front end for the approval cards a human actually clicks through.

Amazon Leo vs Starlink: The 2026 Satellite Internet Race

Yuuki Yamashita — Thu, 20 Aug 2026 18:09:22 +0000

Project Kuiper quietly became Amazon Leo in November 2025. Enterprise beta opened on April 8, 2026. So the natural question: how close is Amazon actually getting to Starlink?

Short answer: not close at all. And Amazon just missed a federal deadline in the process.

The numbers, side by side

Metric	Amazon Leo	Starlink
Satellites in orbit	~345-400 (Aug 2026)	~10,020 (Apr 2026)
Subscribers	Not yet public (enterprise beta only)	10M+
Countries served	5 targeted for mid/late 2026 launch	150+
Consumer pricing	Not yet announced	$50-120/mo (Residential)
Standard hardware	Not yet announced (aiming smaller/cheaper)	$499 ($199 for Mini)
Launch method	Atlas V / Falcon 9 / Ariane 6 (outsourced)	Falcon 9 (in-house, reusable)
FCC status	Missed the 50% deployment target, waiver carries a spectrum-priority penalty	N/A

The snapshot dates don't line up exactly (Starlink's count is from April, Amazon Leo's from August), but the order of magnitude tells the story either way.

The satellite count isn't even in the same order of magnitude

As of April 2026, Starlink had 10,020 satellites in orbit versus 241 for Amazon Leo. By August 2026 Amazon Leo had climbed to roughly 345-400 satellites after a string of launches. Starlink is still ahead by more than 20x.

Subscriber numbers tell the same story. Starlink serves over 10 million subscribers across 150+ countries. Amazon Leo isn't selling to consumers yet — it's still in enterprise beta, with residential service targeted for mid-2026 in five countries: the US, Canada, the UK, France, and Germany.

Amazon actually missed its FCC deadline

This is the part that surprised me most.

Amazon's FCC authorization for its 3,236-satellite constellation came with a condition: launch 50% (1,616 satellites) by July 30, 2026, or risk losing priority status. Actual count at the deadline: 331 satellites — about 20% of target.

The FCC granted a waiver, but not for free. Under the terms of the extension, any Gen1 satellite launched after July 30 temporarily loses the spectrum priority status Amazon earned in earlier FCC processing rounds, until March 30, 2028, or until it hits the 50% mark, whichever comes first. In a business where orbital slots and spectrum priority are genuinely scarce, that's a real cost, not just a paperwork inconvenience.

Why the gap exists: nobody owns Amazon's rocket

SpaceX runs Starlink and also builds the rocket that launches it. Falcon 9 is reusable, flies constantly, and SpaceX controls its own launch cadence end to end. That vertical integration is the actual root of Starlink's lead.

Amazon Leo has no equivalent. It buys launches from Atlas V, Falcon 9, and Ariane 6, and depends on other companies' schedules. Vulcan Centaur and Blue Origin's New Glenn are coming online too — Blue Origin being Bezos-founded but organizationally separate from Amazon — with a target of 20+ missions in 2026 and 30+ in 2027. Still nowhere near Starlink's cadence.

Where Amazon Leo could still win

The one card Starlink genuinely can't match: native AWS integration. A company already running workloads on AWS can get satellite backhaul into its own AWS region as part of one coherent stack. Starlink has no cloud platform to offer alongside it.

The engineering also reflects a later start. Amazon Leo uses optical inter-satellite links and a custom baseband chip called Prometheus, and flies at a lower inclination (30-51°) that concentrates coverage on populated mid-latitudes rather than the wider polar coverage Starlink offers.

Starlink, for reference

Pricing as of 2026: Residential $50-120/mo, Roam $50-165/mo, Mini $30/mo plus $199 hardware, Business from $250/mo. Standard hardware holds steady at $499.

The more interesting move is T-Satellite, Starlink's direct-to-cell partnership with T-Mobile: $10/month, free on higher-tier plans, works across 60+ phone models regardless of carrier. No military or first-responder discount currently exists on the core service.

Bottom line

On raw numbers, this isn't a race yet — it's a head start plus a company still finding its footing. Amazon has committed more than $10 billion to closing the gap, and the AWS integration angle is real. Whether it matters depends entirely on whether Amazon Leo can fix its launch cadence before the spectrum penalty clock runs out in March 2028.

Sources

I Rebuilt YouTube on AWS Alone (and Hit Every Wall)

Yuuki Yamashita — Tue, 18 Aug 2026 15:54:36 +0000

It started as a simple question: how is YouTube actually built? One thing led to another, and a few hours later I had a single-user, self-hosted video platform running in production on AWS — after redesigning the auth layer from scratch mid-build, chasing down an "exec format error," and discovering that avoiding a NAT Gateway didn't actually save me any money. Here's the whole story, including the parts that didn't work the first time.

What YouTube is actually made of

Before writing any code, I wanted to understand what I was copying. Roughly:

Upload and transcoding: uploaded video gets converted into 144p through 4K/8K across multiple codecs, processed by a huge fleet of parallel workers
CDN: Google Global Cache — dedicated caching nodes placed directly inside ISP networks — plus adaptive bitrate streaming
Metadata: Vitess (a sharding layer over MySQL) and Bigtable/Spanner
Recommendations: a two-stage candidate generation + ranking ML system
Content ID: audio/video fingerprinting to detect copyright infringement
Ads: backed by Google Ad Manager

Can AWS alone reproduce it?

Most of the functional skeleton maps cleanly onto managed AWS services: S3 for upload, MediaConvert for transcoding, CloudFront for delivery, DynamoDB for metadata, OpenSearch for search, Personalize for recommendations. That part is genuinely achievable.

A few pieces aren't:

Content ID has no AWS-managed equivalent. You'd need a third-party SaaS like Audible Magic or ACRCloud, or roll your own fingerprinting with something like Chromaprint against a reference database you'd also have to build
ISP-embedded caching — CloudFront has a global edge network, but nothing at the density of nodes sitting inside individual ISPs
Ad auctions at Google Ad Manager's scale aren't something you build yourself; you'd hand this off to an existing ad network

For a personal project, I decided not to build Content ID or ad serving at all. That decision turned out to be tied directly to a legal question I hadn't expected to spend time on.

The legal research I didn't expect to do

Building a video-sharing app in Japan, even a personal one, touches a surprising number of regulations, so I checked before writing any infrastructure code.

First, the Telecommunications Business Act. One-way video distribution generally doesn't require registration, since you're not "mediating someone else's communication." Add a comment section or DMs between users, though, and that changes.

Second, the Act on the Limitation of Liability for Damages of Specified Telecommunications Service Providers (Japan's provider-liability law, recently renamed to something closer to "platform accountability act"). Any platform accepting user-generated content is expected to run a takedown-request contact point; cross a large-user threshold (10M+ monthly users in Japan) and heavier obligations kick in.

Third — and this is the one that actually shaped the design — Article 30 of the Copyright Act, the private-use reproduction exception. Keep something fully private, accessible only to yourself, and it falls under private use. Make it public and it becomes "transmission to the public" (公衆送信), where that exception no longer applies. I also checked whether gating access behind a login would be enough to stay private if I let a few people in. It isn't automatically: under Japanese copyright law, "the public" includes "a specific but numerous group," so the real question isn't whether there's a login screen, it's how many people, and how close a relationship. Family-sized is safe; a wider circle of friends risks crossing into "specific but numerous."

Given all that, I decided the app would support exactly one user — me. No sign-up, no invite flow. That sidesteps the Telecommunications Business Act and the platform-liability law entirely, and keeps everything inside the private-use exception.

The plan

Single user only, no sign-up
AWS only (I use Vercel for most other projects, but not this one)
No Content ID, no ad serving
Upload → S3 → MediaConvert (transcode to HLS) → CloudFront
Web UI on ECS Fargate + ALB + CloudFront (App Runner was already off the table — AWS stopped accepting new App Runner services)

I wrote the CDK for VPC, S3, DynamoDB, a Lambda to kick off MediaConvert jobs, ECS, CloudFront, and Cognito. So far, so normal.

Cognito's ALB integration needs HTTPS, and I didn't have a domain

My first pass at auth used the ALB's native authenticate-cognito listener action — no app code needed, ALB handles the redirect to Cognito's hosted UI for you. Clean, until deploy:

Resource handler returned message: "Actions of type 'authenticate-cognito' are supported only on HTTPS listeners"

That action only works on HTTPS listeners, which means an ACM certificate, which means a real, DNS-verifiable domain — something this project didn't have. Buying a domain just for this felt like the wrong trade, so I moved authentication into the app itself instead, using Next.js's proxy.ts.

Moving auth to the app ran straight into "no NAT Gateway"

I reconfigured the Cognito App Client as a public client (no secret) and switched to PKCE for the authorization code exchange, so the browser could talk to Cognito directly instead of routing through the ALB's constraints.

Redeployed, logged in, and got a 500 on the callback:

⨯ [TypeError: fetch failed] {

      at ignore-listed frames {
    code: 'ETIMEDOUT',

The ECS task had no path to the internet. To keep costs down I'd built the VPC with interface endpoints instead of a NAT Gateway — but there's no VPC endpoint for Cognito's Hosted UI/OAuth domain (*.auth.<region>.amazoncognito.com). The container simply couldn't reach it.

The fix was to move the token exchange itself into the browser. The only thing that actually needs to happen server-side is JWT verification (fetching the JWKS), which is covered by the cognito-idp VPC endpoint. The browser already has internet access, so it can talk to Cognito's token endpoint directly. That change got login working without ever adding a NAT Gateway.

Forgot to pin the CPU architecture, container wouldn't start

Redeployed again, and this time the ECS task crash-looped indefinitely. CloudWatch Logs had exactly one line to offer:

exec /usr/local/bin/docker-entrypoint.sh: exec format error

Building the Docker image on an Apple Silicon Mac produces an arm64 image. Fargate defaults to x86_64. Nothing about the mismatch surfaces until the container tries to actually execute. Setting runtimePlatform to ARM64 on the FargateTaskDefinition fixed it. I also turned on the ECS deployment circuit breaker at the same time — without it, a failing deployment can take up to three hours to be reported as failed, and I'd already lost about 40 minutes not noticing.

The health check was hitting the login redirect

Next failure: the ALB health check was pointed at /, which — like every other route — goes through the app's auth gate. An unauthenticated health check gets a 302, the ALB reads that as unhealthy, and the deployment fails outright. Added a dedicated /api/health route that skips the auth check, and that was that.

Video played, but the manifest path was broken

Deployment finally succeeded, upload worked, MediaConvert finished the job — and the video was just a black rectangle.

The cause: MediaConvert's completion event returns outputGroupDetails.playlistFilePaths as a full s3://bucket/key URI, not a bucket-relative key. I'd been storing that value directly as manifestKey, so the app's /${manifestKey} template produced a broken /s3://bucket/... path. Since I already control the output prefix at job-creation time, I switched to deriving the key deterministically instead of trusting the event payload. Don't take an AWS event field at face value if you can compute the same thing yourself.

CloudFront's signed cookies ignored my wildcard

To lock down /renditions/* (the actual video files) behind CloudFront's Key Group, I used @aws-sdk/cloudfront-signer's getSignedCookies with a url + dateLessThan — the "canned policy" form — expecting a wildcard path to cover everything under it. It didn't:

{"error":"AccessDenied","message":"Access denied"}

(Along the way I also discovered this AWS account already had a CloudFront Public Key from a different project, and my first debugging attempt had grabbed the wrong Key Pair ID entirely — worth checking aws cloudfront list-public-keys before assuming there's only one.)

The actual fix was switching to an explicit custom policy — passing policy with a JSON statement whose Resource includes the wildcard — rather than the canned url/dateLessThan shortcut. The SDK happily accepts a wildcard in the canned form; CloudFront just doesn't honor it the same way.

Deleting a video brought it back from the dead

With everything working, I added delete. It's supposed to be a simple DynamoDB + S3 cleanup, but it hit two separate bugs.

First, IAM: grantWrite/grantDelete only cover object-level actions (s3:PutObject*, s3:DeleteObject*), not the bucket-level s3:ListBucket that ListObjectsV2 needs during cleanup. Adding grantRead fixed it.

Second, and more interesting: deleting a video that was still processing let the MediaConvert-completion Lambda fire after deletion, calling UpdateItem on a videoId that no longer existed. DynamoDB's UpdateItem creates the item if it's missing — so the "deleted" video would silently reappear, partially populated. Adding ConditionExpression: 'attribute_exists(videoId)' made that update a no-op instead of a resurrection.

The security group I "locked down" wasn't actually locked down

I wanted the ALB reachable only through CloudFront, so I restricted its security group to CloudFront's managed prefix list (pl-58a04531). Deployed, checked the actual rule set, and found this:

{
  "IpRanges": [{"CidrIp": "0.0.0.0/0", "Description": "Allow from anyone on port 80"}],
  "PrefixListIds": [{"PrefixListId": "pl-58a04531"}]
}

Both rules were live at once. The culprit was the ALB listener's open property, which defaults to true and silently adds its own 0.0.0.0/0 ingress rule regardless of what you've configured on the security group yourself. Setting open: false on addListener removed it. This is the kind of gap you only catch by actually reading the deployed state back from the AWS CLI — the CDK code alone looked correct.

Avoiding a NAT Gateway didn't actually save money

Once things were stable, I priced out the fixed monthly cost:

Item	Monthly (approx.)
5x VPC interface endpoints	~$50.40
ALB	~$20–23
ECS Fargate (0.25 vCPU / 0.5GB, ARM64)	~$8.90
Secrets Manager	$0.40
Total	~$83

I'd built five interface endpoints specifically to avoid a NAT Gateway (roughly $44.60/month in Tokyo, plus data processing). Adding them up, the endpoints cost about the same as the NAT Gateway would have — sometimes more. Consolidating to a single NAT Gateway would save maybe $5–6/month at the cost of a single point of failure, which is a fine trade for a personal, single-user app. I ended up leaving the endpoint-based setup as-is; the savings weren't worth the churn.

What's actually running

Login via Cognito with PKCE, one user account, no sign-up flow
Upload → S3 → Lambda → MediaConvert → HLS
CloudFront with signed cookies gating the video files themselves
Delete, a Japanese/English toggle, and a dark, YouTube-ish UI

The code is public on GitHub, including the README section explaining, in plain terms, why multi-user upload was never on the table.

Mobile

The part that actually took the time

None of the individual fixes here were hard once I knew what was wrong. What took the time was reading logs — exec format error, AccessDenied, InvalidKey — each one terse, each one caused by something completely different. Past a certain point, building on managed AWS services stops being about writing code and starts being about getting fast at figuring out why something isn't working.

AWS Instance Store: Built to Disappear, On Purpose

Yuuki Yamashita — Fri, 14 Aug 2026 05:32:58 +0000

Instance Store gets introduced in almost every AWS storage comparison the same way: "NVMe SSD physically attached to the host, faster than EBS, but the data disappears when the instance stops." That last clause usually reads like a warning label. Most guides then walk you straight into the safe, well-worn use cases — Cassandra nodes that don't mind losing a replica, Spark shuffle space, a scratch disk for sorting temp files. All correct, all a little boring.

What if the disappearing part isn't the catch, but the whole point?

Two workloads make that case surprisingly well: blockchain nodes doing a fast state sync, and compute jobs that touch data you'd rather not still have lying around tomorrow. They don't look related at first. One is about speed, the other about disappearance. But they're actually the same trick told twice — you get a disk that works blazingly fast for a short, defined burst, and then erases itself as a side effect of you being done with it. You're not fighting the ephemerality. You're renting it.

What instance store actually promises

Worth being precise here, because the security argument later depends on it. Instance store data does not persist through a stop, a terminate, a hibernate, or an underlying host failure. It does persist through a plain reboot, since that keeps you on the same physical host. AWS documents that the storage is not accessible to whoever gets the host next, which is the property that makes both ideas below work at all.

What instance store is not: a certified secure-erase mechanism. If your compliance framework requires a documented, auditable wipe procedure — HIPAA, PCI-DSS, that kind of thing — "the disk went away when I stopped the instance" is not a control you can point an auditor at. Keep that distinction in mind as you read the rest of this, because the two ideas here are architectural thought experiments, not a substitute for whatever your compliance team actually needs signed off.

Idea one: the node that only exists to catch up

Syncing a blockchain node from genesis, or even from a recent snapshot, is an I/O-bound slog. You're writing and reading state data continuously for hours, sometimes days, and once the node is caught up, most of that historical grind stops mattering — what you actually want going forward is a warm, synced node.

The usual move is to provision an instance with a big EBS volume, let it sync, and keep paying for that volume indefinitely. Instance store flips the framing: treat the sync itself as the disposable part. Spin up an instance with local NVMe, let it rip through the sync at NVMe speeds instead of network-attached-storage speeds, and once it's caught up, snapshot the resulting state to S3 or EBS. The instance that did the syncing was never meant to be the long-term home for that data — it was a sprinter, not a warehouse. If it dies mid-sync, you weren't attached to it anyway; you just launch another one and let it catch up again, ideally from a recent checkpoint instead of genesis.

This is basically the render-farm mentality applied to sync jobs: the compute is consumable, the output is what you keep. It also pairs naturally with Spot — losing a spot instance mid-sync is annoying, not catastrophic, precisely because you never treated its disk as the source of truth.

Idea two: compute that isn't supposed to remember anything

Now the other direction. Imagine a batch job that has to touch something sensitive for a few minutes — decrypting a payload, running a one-off transformation on data you were only ever supposed to process, not retain. The usual anxiety with EBS-backed compute is the tail: did the volume get deleted on termination, did a snapshot get left behind by accident, is there a stray AMI somewhere with that data baked in.

Instance store sidesteps most of that tail by construction. Launch the instance, do the job, terminate it. There's no volume to remember to delete, because there was never a persistent volume to begin with. The "forgetting" isn't a cleanup step you have to remember to run — it's what happens automatically when the job's done and you walk away. It's less "secure deletion" and more "the environment was never built to have a memory."

I'll be upfront that this is the idea I'd stress-test hardest before trusting it with anything actually regulated. It's a genuinely nice property for internal tooling, dev/test data that's sensitive but not audited, or a proof of concept where "the disk goes away" is a reasonable enough story. It is not, on its own, a story you'd want to tell a security auditor for anything under a real compliance regime — that needs KMS-backed encryption, documented key destruction, and probably a paper trail instance store just doesn't produce.

The thread connecting them

Both ideas lean on the same underlying shift: stop treating the disk's short lifespan as a constraint to architect around, and start treating it as the reason the architecture works. The blockchain sync node is fast because nobody's paying the tax of durable storage during the grind. The confidential job is simple because nobody has to remember to clean up after it. In both cases the disappearing act isn't a workaround — it's doing actual work.

None of this replaces the orthodox use cases. Cassandra nodes, EMR clusters, and CI runners are still the bread and butter of instance store, and for good reason — they're proven, well-documented, and nobody's going to ask you hard questions about why you picked them. But it's worth remembering that "the data goes away" is a spec, not a bug report, and specs can be designed around on purpose. Sometimes the most interesting infrastructure decision is picking the tool that forgets on schedule, and building the rest of the system to expect exactly that.

How to Pause an AI Agent for Human Approval Without a WebSocket

Yuuki Yamashita — Thu, 13 Aug 2026 15:54:18 +0000

If an AI agent needs a human to approve something mid-task, the instinct is usually to reach for a websocket, a message queue, or some kind of push notification service to bridge the backend and the frontend. I ended up not needing any of that. One DynamoDB row, polled from both sides, does the whole job. I built this for SubSentry, an agent for AWS's Agents for Humans Hackathon that renews clean subscriptions on its own and asks a human before touching anything that looks like a price hike, a duplicate charge, or an unrecognized merchant. This post is about the mechanism underneath that "asking," not the subscription-tracking part.

The shape of the problem

An agent tool call that needs human approval has to do two contradictory things at once. It has to actually block, because the agent's next step depends on the answer, and it has to somehow let something completely separate (a browser tab, a Slack bot, a CLI) deliver that answer whenever a human gets around to it, which could be five seconds or five minutes later. The backend process and the thing collecting the human's decision don't share memory, don't share a request, and in my case run on entirely different platforms (Bedrock AgentCore Runtime for the agent, Vercel serverless functions for the UI).

The trick is to stop thinking of it as backend-talks-to-frontend at all. Neither side needs to know the other exists. They both just need to agree on one row.

The row as a mailbox

Here's the actual store, trimmed slightly:

def request_approval(*, subscription_id, suggested_action, reasons, amount_usd, ttl_seconds=120):
    approval_id = str(uuid.uuid4())
    now = time.time()
    entry = {
        "approval_id": approval_id,
        "subscription_id": subscription_id,
        "status": "PENDING",
        "suggested_action": suggested_action,
        "reasons": reasons,
        "amount_usd": amount_usd,
        "created_at": str(now),
        "expires_at": str(now + ttl_seconds),
        "decision": None,
    }
    _dynamo_put(entry)
    return entry


def wait_for_decision(approval_id, *, poll_sec=1.0):
    while True:
        entry = get_approval(approval_id)
        if entry["status"] != "PENDING":
            return entry
        if time.time() > float(entry["expires_at"]):
            entry["status"] = "EXPIRED"
            _dynamo_put(entry)
            return entry
        time.sleep(poll_sec)

The agent's tool calls request_approval, gets back an approval_id, and immediately calls wait_for_decision on it, which just sits there polling DynamoDB once a second. That's the entire "block" side. It's a plain Python while True loop, nothing fancier, because AgentCore Runtime is already paying for a long-running invocation, so there's no reason to make the waiting clever.

The other side never has to know it's being waited on

The frontend's job is smaller than it sounds: read rows where status = PENDING, render them as cards, and when a human clicks Approve or Reject, write the decision back. Here's the write, as a DynamoDB UpdateItem call from a Next.js API route:

const r = await ddb().send(
  new UpdateCommand({
    TableName: TABLES.approvals,
    Key: { approval_id: id },
    UpdateExpression: "SET #s = :d, decision = :d, #r = :r, decided_at = :t",
    ExpressionAttributeNames: { "#s": "status", "#r": "reason" },
    ExpressionAttributeValues: { ":d": body.decision, ":r": body.reason ?? "", ":t": String(Date.now() / 1000), ":pending": "PENDING" },
    ConditionExpression: "attribute_exists(approval_id) AND #s = :pending",
    ReturnValues: "ALL_NEW",
  })
);

The ConditionExpression is doing more work than it looks like. It means two people can't both approve the same card and have it silently double-apply, and it means a decision can't land on a row that already expired. If the condition fails, DynamoDB throws ConditionalCheckFailedException, which the route turns into a 409. No locking, no transactions, just a condition on a single-item write.

And that's the whole contract. The agent doesn't call an API on the frontend. The frontend doesn't call an API on the agent. A CLI can write the same UpdateItem and it works identically, which is why agent.py approve <id> from a terminal resolves the exact same pending card as clicking Approve in the browser. Neither side was written with the other in mind, they just both read and write the same table with the same status field.

Where this breaks if you're not careful

The failure mode I actually hit wasn't in this mechanism, it was one level down. Strands dispatches multiple tool calls from the same agent turn concurrently, and my first pass at local storage (before I had a real DynamoDB table wired up) was a plain read-JSON-modify-write with no locking. Two tool calls landing at nearly the same instant would both read the file, both append their own entry in memory, and whichever one wrote last won, silently dropping the other's write. I found it because a local .approvals.json file had two writes visibly tangled together mid-file, not because a test failed cleanly.

The fix was five lines, a threading.Lock around the read-modify-write section:

with _LOCK:
    data = _local_load()
    data[approval_id] = entry
    _local_save(data)

DynamoDB's per-item UpdateItem doesn't have this problem at all, since each write targets one item atomically. The bug only existed because my local dev fallback was reinventing a worse version of what DynamoDB gives you for free. Worth remembering next time a "just write it to a JSON file for now" shortcut feels harmless.

Why not just use a websocket

I did consider it, mostly out of habit. But a websocket needs a persistent connection on both ends, which means something has to stay alive to hold it, and AgentCore Runtime invocations and Vercel serverless functions are both built around not staying alive longer than they have to. Polling a table every one to three seconds costs nothing worth optimizing at this scale, and it means either side of the system can restart, redeploy, or die completely mid-wait and the other side won't even notice, because the DynamoDB row is the only thing that has to survive.

If you want to see the whole thing running, live demo and code are here:

Live demo: https://sub-sentry-xi.vercel.app
Code: https://github.com/yama3133/sub-sentry

Built for AWS's Agents for Humans Hackathon. #AgentsforHumans