DEV Community: Toru Ikeda

Does Static Typing Reduce AI's Bugs? I Had Claude Code Build the Same Git Clone Three Times Each in TypeScript and JavaScript

Toru Ikeda — Sun, 08 Nov 2026 10:41:38 +0000

"If an AI is writing your code, TypeScript is the safer choice." You hear it a lot, and I more or less believed it too. A type checker tells you what's wrong, so an AI should reach correct code more easily with one.

But is that actually true? When an AI writes the code, does static typing (TypeScript) versus dynamic typing (JavaScript) really change how many bugs are left behind?

This experiment was inspired by Yusuke Endoh's article here on DEV:

Yusuke Endoh

Mar 5

Which Programming Language Is Best for Claude Code?

#ai #llm #programming

8 min read

He had Claude Code write a simplified Git in many languages, 20 times each, and compared time and cost. TypeScript took about 1.6 times as long and cost about 1.6 times as much as JavaScript, and statically typed languages were slower and more expensive overall. The programs, though, were only a few hundred lines. He closed by suggesting that the benefits of static typing might show up at a larger scale, and left that for someone to test.

So I scaled the task up to a few thousand lines and compared TypeScript and JavaScript again, this time including how many bugs were left.

This is an English version of an article I first published in Japanese on Zenn.

TL;DR

At a few thousand lines, there was no clear difference between TypeScript and JavaScript.

Put the other way around, the JavaScript advantage seen at a few hundred lines in Endoh's article went away.

I had Claude Opus 5.5 build the same Git-compatible CLI from scratch, three times in TypeScript and three times in JavaScript. Here is what happened:

Bugs left: 0 of 3 TypeScript runs and 1 of 3 JavaScript runs ended with a bug (one bug in total)
Tokens: about 1M output tokens per run in both languages. Including input-side tokens, TypeScript used 16% more in total, but the ranges of the three runs overlap
The one clear difference in the numbers was code size: TypeScript was about 20% longer (the type annotations)

"0 vs 1" looks like a TypeScript win, but with three runs per side it can't be told apart from chance. Token usage varied by more than 10% even among the three TypeScript runs, and the gap between the languages fell inside that spread.

That said, there was one interesting trend in how the AI worked. The JavaScript runs ran their unit tests about twice as often as the TypeScript runs. Without a type checker, the AI seems to have checked its work by running tests more often. At this scale it didn't cost anything noticeable, but at a larger scale it may become a real disadvantage for dynamic typing (more on this below).

Mean of 3 runs	TypeScript	JavaScript	Difference
Runs with full marks on the hidden tests at the end	3 / 3	2 / 3	–
Total tokens (all three versions)	67.7M	58.2M	TS +16%
— Output	1.00M	1.02M	TS −2%
— Cache reads	64.5M	55.2M	TS +17%
— Cache writes	2.13M	1.91M	TS +12%
— Uncached input	50K	28K	TS +78%
Time waiting for the model (all three versions)	9,801 s	9,844 s	About the same
Implementation size, final version	4,985 lines	4,153 lines	TS +20%
Cost (estimate, see note 1)	$49.9	$46.7	TS +7%

Everything is public: the materials, the specs, the tests and the AI's logs.

Ikepeeee / ts-vs-js-agent-experiment

TypeScript vs JavaScript: a controlled experiment

AI agents implement the same specification (tgit v0.1.0 to v0.3.0) from scratch, once in TypeScript and once in JavaScript The experiment compares the bugs that remain and the cost of getting there. The only difference between the conditions is the language, along with the type checking that comes with it.

Japanese version: README_ja.md. This English version is canonical; where the two differ, this one prevails.

Layout

Path	Contents	Read by
`README.md`	This file (Japanese: `README_ja.md`)	Humans
`experiment-design.md`	The design of the controlled experiment. The run procedure is chapter 13 (Japanese: `experiment-design_ja.md`)	Humans
`main.lask`	Every operation of the experiment, as lask tasks	Humans
`spec/spec-v1.md` to `spec-v3.md`	The tgit specification (English). The same for both conditions	AI (one version at a time)
`ts/AGENTS.md`	Instructions placed in the repository for the TypeScript condition	AI
`js/AGENTS.md`	Instructions placed in the repository for the JavaScript condition

…

View on GitHub

The setup

The task: a Git-compatible CLI called "tgit"

The AI built "tgit", a Git clone. It reads and writes repositories in the same format as the real Git, and its output has to match the real Git character for character.

I chose Git because the right answer is unambiguous. Run the same operations on the real Git and compare the results, and correctness can be judged mechanically.

The spec came in three versions. Each version was handed over in turn, and the AI kept building on the same repository.

Version	Main commands added	Hidden tests (cumulative)
v0.1.0	init, add, status, commit, log, branch, switch, and more	82
v0.2.0	diff, show, merge-base, merge	117
v0.3.0	tag, reset, cherry-pick, revert, reflog	151

Only the language differs

The only difference between the conditions is the language and the type checking.

TypeScript: strict and noUncheckedIndexedAccess on, no any, and passing tsc is part of "done"
JavaScript: no type annotations (JSDoc types included) and no type checking

The instructions given to the AI (AGENTS.md) are identical word for word, apart from those few lines. Both run directly on Node.js with no build step and no runtime dependencies.

The AI was Claude Opus 5.5 in Claude Code, running inside a Docker container. It had the public tests and a tool that compares results against the real Git, so it could check its own work as it went. The hidden tests used for grading were not visible to it.

A deliberately small context

I turned off Claude Code's 1M-token context with CLAUDE_CODE_DISABLE_1M_CONTEXT=1, limiting it to 200K tokens. The idea was to make it easier to test one hypothesis: types start to matter once the code no longer fits in the AI's head. When the conversation reaches 200K tokens, Claude Code summarizes it automatically (compaction) and carries on.

There were 27 compactions across the three TypeScript runs and 29 across the JavaScript runs, or 8 to 11 per run. The AI repeatedly summarized its own memory while it worked. Even so, the final code was a few thousand lines, still small enough to fit in 200K tokens on its own. What filled the context was the conversation, such as files it read and test output, rather than the code itself.

How it was graded

Besides the hidden tests, I ran 2,000 random sequences of operations per version and compared tgit with the real Git on:

exit codes and output
the contents of .git (objects, refs, the index)
the files in the working tree
whether the real Git's git fsck --strict accepts the repository tgit produced

Matching output isn't enough: if .git differs behind the scenes, it fails.

Two hidden tests and one random sequence turned out to be faulty on the test side during grading, and I excluded them (see note 2).

Results: nearly perfect, with one bug left

The first surprise was how accurately the AI built it in both languages. Every run got full marks on the public tests, and almost full marks on the hidden tests.

Run	Language	v0.1.0	v0.2.0	v0.3.0	Random (2,000 per version)
AN01	TS	82/82	117/117	151/151	All match
AN02	TS	82/82	117/117	151/151	All match
AN03	TS	82/82	117/117	151/151	All match
BN01	JS	82/82	117/117	151/151	All match
BN02	JS	82/82	117/117	151/151	All match
BN03	JS	81/82	116/117	150/151	All match

The only bug

Only one bug survived. It was in BN03 (JavaScript): what happens when you add a file that .gitignore ignores.

The real Git stops with an error and writes nothing. BN03 got the error exit code right, but wrote an empty .git/index before failing. The output was correct, so it would have gone unnoticed without comparing the contents of .git. It went in during the first version and was still there at the end.

This isn't the kind of bug a type checker catches, though. It's a matter of ordering: writing a file before deciding there's an error. You can write exactly the same thing in TypeScript.

Tokens: runs differ more than languages

Next, token usage. The chart shows output tokens per run, stacked by version.

TypeScript averaged about 1.00M and JavaScript about 1.02M: practically the same. What stands out more is the spread within each language. In JavaScript, the largest run (BN01) and the smallest (BN03) differ by almost 250K. v0.2.0, which adds merge, was the heaviest version in every run, at 50–60% of the total.

Now the breakdown, including tokens other than output. Each type is indexed to the JavaScript mean.

TypeScript used more of the input-side tokens: cache reads, cache writes and uncached input. For output and thinking, JavaScript actually used slightly more. For every type, though, the ranges of the three runs overlap. The numbers:

Token type (all three versions)	TypeScript mean (min–max)	JavaScript mean (min–max)	Difference in means	Ranges
Output	1.00M (0.95M–1.06M)	1.02M (0.89M–1.14M)	TS −2%	Overlap
Cache reads	64.5M (56.3M–69.4M)	55.2M (49.8M–61.0M)	TS +17%	Overlap
Cache writes	2.13M (1.94M–2.33M)	1.91M (1.84M–2.02M)	TS +12%	Overlap
Uncached input	50K (26K–64K)	28K (23K–36K)	TS +78%	Overlap
Total	67.7M (59.4M–72.8M)	58.2M (53.0M–63.9M)	TS +16%	Overlap
Thinking (for reference, see note 3)	566K (513K–603K)	616K (524K–731K)	TS −8%	Overlap

The biggest difference was in cache reads: TypeScript used about 17% more on average. Still, the lowest TypeScript run (AN03) used fewer than the highest JavaScript run (BN02), so the ranges overlap.

Why TypeScript cost more despite less output

The cost (see note 1) was $49.9 for TypeScript and $46.7 for JavaScript. JavaScript produced more output tokens, yet TypeScript cost more.

The reason is that most of the cost comes from the input side, especially cache reads, not from output. Assuming relative prices for each token type, I split the cost into parts (see note 4):

Cost breakdown (mean of 3 runs, estimated)	TypeScript	JavaScript	TS − JS
Output	~$16.1	~$16.4	−$0.3
Cache reads	~$20.8	~$17.8	+$3.0
Cache writes	~$13.7	~$12.3	+$1.4
Uncached input	~$0.2	~$0.1	+$0.1
Cost recorded in the logs	$49.9	$46.7	+$3.2

Output is only about a third of the cost, so JavaScript's 2% more output is worth a few dozen cents. TypeScript's cache reads, on the other hand, were about 9.3M tokens higher, which alone accounts for about $3.

An agent re-reads the whole conversation from the cache on every turn. TypeScript code is about 20% longer, so every file read or write puts more into the conversation. Uncached input, mostly tool results, was also about 1.8 times higher. The per-turn difference is small, but over hundreds of turns it adds up to 17%.

No types, still correct

The fun part came when I ran the JavaScript code through TypeScript's type checker after the fact (checkJs). The final versions had 832 to 1,022 type errors per run.

Final version, mean of 3 runs	TypeScript	JavaScript
Implementation lines	4,985	4,153
Test code lines	381	431
Comparison scenarios the AI wrote	125	130
Type errors when type-checked afterwards	–	925

Seen through types, the code is full of holes. Yet it scored nearly full marks on the hidden tests. Being "loose" at the type level barely turned into actual bugs.

Why no difference? I think it's because the AI could check itself against the real Git. In both languages, it wrote more than 120 comparison scenarios against the real Git on average, and kept finding and fixing mismatches. With verification that strong, the mistakes a type checker would catch get caught by the tests first, types or no types.

Trends that aren't significant, but caught my eye

With three runs per side, nothing here is statistically meaningful. Still, a few things stood out in the logs.

The type checker barely had anything to do

The TypeScript runs ran tsc 40 to 55 times each. Only 2 or 3 of those checks per run reported a type error. Across all three runs and all three versions, the AI saw just these eight type errors:

Run	Version	Type error
AN01	v0.2.0	Referenced a name that doesn't exist (`filter`)
AN01	v0.3.0	Mismatched type argument on `Buffer`
AN02	v0.1.0	Referenced a property `branch` that type `Head` doesn't have
AN02	v0.2.0	Assigned a value that might be `undefined`
AN02	v0.2.0	Passed a `readonly` array where a mutable one was expected
AN03	v0.3.0	Referenced a name that doesn't exist (`peelTags`)
AN03	v0.3.0	Referenced a name that doesn't exist (`readStateHead`)
AN03	v0.3.0	Too few arguments

About half are things like "name not found" or "too few arguments" that crash the moment the code runs; one test run would find them without a type checker. The only catch unique to type checking was the possible undefined (from noUncheckedIndexedAccess). The AI simply wrote very little code with type errors in the first place.

The JavaScript runs ran unit tests about twice as often

The TypeScript runs ran unit tests (npm test) 13 to 19 times each; the JavaScript runs, 28 to 36 times. The ranges don't overlap, and JavaScript ran them about twice as often. The comparison runs against the real Git were about the same: 135–200 for TypeScript and 161–207 for JavaScript.

The JavaScript runs also wrote about 13% more test code. Without a type checker to lean on, they may have made up for it by running tests more often. I didn't find type-like checks in the tests themselves, though (such as checking argument types).

This may be an early sign that dynamic typing gets worse as code grows. A type checker tells you in one pass how far a change reaches. Without types, the only way to find out is to run tests. As code grows and changes reach further, there are more tests to run, and each run takes longer. Here, twice the test runs made no difference in tokens, but at a larger scale this verification cost could start to hurt JavaScript.

TypeScript code was always longer

The shortest TypeScript run (AN03, 4,796 lines) was still longer than the longest JavaScript run (BN01, 4,642 lines). It's one of the few measures where the ranges separate cleanly. That's the type annotations and interface definitions, as expected.

More thinking in JavaScript, more cache reads in TypeScript

Thinking tokens were about 9% higher in JavaScript, and cache reads about 17% higher in TypeScript. You could read it as "without types, it thinks more; with types, it reads more code." Both ranges overlap, though, so this may well be chance.

Caveats

"No difference was found" isn't the same as "no difference exists." This experiment has limits.

Few runs: three per language. Small differences can't be detected. More runs would be well worth it
One task, one model: a CLI with an unambiguous right answer that the AI could check itself against. A task with a vaguer spec, or another model, might give different results
Some tools given to the AI were outdated: I forgot to commit a fix to the random-test generator, so the AI got the old version. Both languages got the same one, so the comparison is fair, but the AI may have struggled with situations that didn't matter
Six runs at once: my Mac's sleep and the load threw off wall-clock times, so I compared time spent waiting for the model instead. Token counts may also be 1–2% high
Few rule violations: npm view, which was not allowed, ran twice and npx prettier once. Neither affected the implementation

Summary

On a task with a checkable right answer, Claude Opus 5.5 wrote about equally correct code with about equal token usage in TypeScript and JavaScript
The one bug left wasn't a type error but an ordering problem, the kind a type checker can't prevent
Even in TypeScript, the type checker found type errors only 2 or 3 times per run. The AI rarely writes type errors to begin with

In Endoh's article, TypeScript was at a disadvantage in time and cost on small programs. Here, at a few thousand lines, the cost gap shrank to about 7%. Even so, there was no clear sign that types reduce bugs. The model (Claude Opus 4.6 in his article, Claude Opus 5.5 here) and the scale of the task both differ, so a direct comparison isn't possible. But at least at this scale, static typing was neither a big win nor a big loss.

Turned around: just going from a few hundred lines to a few thousand made TypeScript's disadvantage in Endoh's article mostly disappear. If the gap shrinks as the scale grows, then somewhere further up it might flip, with TypeScript clearly ahead. The JavaScript runs running unit tests twice as often can be read as a hint in that direction. The same comparison at tens of thousands of lines, where the whole codebase no longer fits in the context, seems well worth trying.

"Use types when an AI writes your code" may matter less than we think, at least at a few thousand lines with strong tests.

That said, this was three runs per language on a single task. More runs, larger codebases, and tasks with vaguer specs are all worth trying. All the materials are public, so take a look if you're interested. Feel free to use the code.

Notes

Cost is the sum of the estimates that Claude Code records in its logs for each session (modelUsage in the result record). It isn't an actual bill. I ran everything on a subscription (logged in to Claude Code), so these amounts weren't charged as such.
Excluded tests: two hidden tests required a feature the spec doesn't mention, and one random sequence couldn't be compared because of how the real Git behaves. Without the exclusion, one TypeScript run and one JavaScript run would have had full marks on the hidden tests at the end.
Thinking tokens are recorded in Claude Code's logs as a separate item from output. The logs don't show whether they're part of output, so they aren't in the total.
The cost breakdown is an estimate. Taking the uncached input price as 1, I assumed cache reads at 0.1, cache writes at 2 (1-hour cache) and output at 5, found the base price that best fit the logged costs, and split the cost accordingly. It isn't based on official prices, and the fit is off by up to about 9% per run, so the parts don't add up exactly to the logged cost.

Can You Say What Your AI-Written Tasks Can Access Before You Run Them?

Toru Ikeda — Tue, 03 Nov 2026 14:51:32 +0000

Ask a coding agent to add a task, and the diff fills up with shell commands. Few people review them down to what npm install runs underneath.

What can those commands overwrite, and what can they talk to? I wanted a machine to answer that before anything runs.

I build Lask, a task runner where you write tasks as typed functions in a small language, and every command runs in a container of the Docker image you declared for it.

Lask 0.15.0 adds within: you declare which files and networks commands may access, and the type checker verifies it statically.

This post has two parts. The first part steps away from Lask and summarizes the recent discussion about guardrails for generative AI. I tried to keep it objective, and I mark where I give my own opinion. The second part shows how I implemented those ideas in Lask, so it is mostly my own take.

TL;DR

Part 1 (general)

Reading code was never a strong defense against malicious code, and with AI producing more code, review is falling further behind.

One response is to have AI prove its code correct. But proofs need a specification written by a human, which doesn't fit things like the install scripts npm install runs.

Another response, with growing research behind it, is to verify the boundary around the model, which holds whatever the model outputs.

Part 2 (Lask)

Lask's within implements that second idea as type checking in a task runner. Commands that might exceed the declared scope fail lask check before anything runs.

I suggest a split: a person checks the access scope with lask envs access before running, and lask check verifies that every command stays within it. This is static checking, not a machine-checked proof, and there are things it doesn't cover. They're listed near the end.

Part 1: The debate over AI guardrails

Reading code alone never stopped it

Even when people wrote all the code, finding malicious code by reading it was hard.

The xz Utils backdoor, found in March 2024, wasn't caught by reading code (XZ Utils backdoor). Andres Freund, a PostgreSQL developer, traced it while investigating unusually high CPU usage during SSH logins.

Dependency code often isn't read at all. Imtiaz and Williams studied updates to popular packages in four package registries (arXiv:2206.09422). 52.5% of updates were only partially code-reviewed, and only 9.0% of packages had every update fully reviewed.

The report from the S3C2 industry summit on supply chain security reaches the same view (arXiv:2505.10538). Since there is no reliable automated way to detect malicious commits, teams rely on human review, but human review is error-prone and not always reliable.

AI is outpacing review

With AI writing code, there's more for people to read.

Chen and Stratton at Harvard analyzed development data from 655 firms (Artificial Intelligence in the Firm). It's a working paper estimating how AI coding tools affect development, and it hasn't been peer-reviewed. After firms adopted AI agents, lines of code added rose 44.0% and pull requests opened rose 35.7%. Meanwhile, the average time from opening a pull request to merging it grew 56.1%. The authors conclude that code review became the bottleneck.

He et al. followed 802 developers at a company that mandated doubling output with AI (arXiv:2607.01904). Load per reviewer roughly doubled.

Reading code was already a weak defense against malicious code, and AI leaves even less room to read. So I think we need checks that a machine can do without a person reading the code.

Proofs need a human-written spec

In December 2025, Martin Kleppmann predicted that AI will make formal verification mainstream (AI will make formal verification go mainstream). Formal verification proves mathematically that a program meets its specification. His argument: AI makes writing proofs much cheaper, so instead of having people review AI-written code, have the AI prove it correct.

With this approach, it doesn't matter if the AI writes a bad proof. The proof checker rejects it and makes the AI try again.

But in the same post, Kleppmann notes that reading and writing formal specifications still takes expertise and careful thought. A proof only guarantees that the code meets the spec, and a person writes the spec.

Install scripts have no spec

I think proof-based verification is hard to apply to tasks like builds and installs. npm install runs install scripts written by other people, one for each dependency that has one. Nowhere is there a spec for what those scripts should do.

This year, those install scripts were exactly what attackers used on npm. Palo Alto Networks' Unit 42 updated its overview of attacks on npm on July 15, 2026 (The npm Threat Landscape). It says many compromises rely on preinstall or postinstall hooks to exfiltrate secrets.

According to the same article, in the May TanStack incident, code injected into CI harvested NPM_TOKEN and GITHUB_TOKEN. In April, a self-propagating worm was reported that used stolen npm tokens to publish versions carrying malicious code (The Hacker News).

The common advice is ignore-scripts, which stops install scripts. But some packages need their scripts, so stopping all of them isn't always practical.

Verify the boundary outside the model

Instead of checking that AI output is correct, a growing body of research checks the boundary that AI output can't cross, whatever it is.

Moon and Varshney's Containment Verification (arXiv:2605.09045) assumes nothing about how the AI behaves. It treats the AI as able to emit any value within the types the framework accepts. It then proves in Dafny that the agent framework enforces its boundary policy for every such value. The authors say the guarantee doesn't depend on alignment, that is, on whether the model has been tuned to behave as intended.

Google DeepMind's CaMeL (arXiv:2503.18813) also leaves the model untouched. It places an interpreter outside the model that records where each value came from and checks those records against a policy before any tool call, to defend against prompt injection.

Anthropic's Agent SDK documentation draws the same line between permission checks and isolation (Securely deploying AI agents). Of the mechanism that parses commands and matches them against permission rules, it says: "This is a permission gate, not a sandbox."

Three layers against risky operations

Putting this together, the mechanisms that guard against an agent's risky operations fall into three layers. Each works at a different time and checks something different. Table 1 lists them in the order they act.

Table 1. Three layers against risky operations

Layer	What it checks	When	If it gets it wrong
Static boundary check	Whether the isolation mechanism and its settings keep to the decided scope	Before running	It runs with isolation that doesn't keep to the scope
Permission check	Whether this operation may run	Right before running	The operation runs
Runtime isolation	What a running operation can access	While running	It accesses more than intended

A static boundary check examines the isolation mechanism, such as a container or sandbox, and its settings before anything runs. Containment Verification, from the previous section, proves that the framework enforces its boundary policy whatever values the AI emits. It checks the isolation, not the AI's output, so the result doesn't change whatever the AI writes.

A permission check decides, right before running, whether an operation runs. Permission rules and confirmation prompts belong here. If the check gets it wrong, the operation simply runs.

Runtime isolation has no say in whether something runs. The operation runs, but it can only access what's inside the isolation. Even a risky operation that got past the permission check is contained. But if the isolation is configured too broadly by mistake, it can access more than intended. Without a static check, nobody usually verifies those settings until something runs.

The three layers are meant to be stacked. The static check catches mistakes in the isolation settings before anything runs, and isolation contains risky operations that got past the permission check.

Part 2: Declaring access scope in Lask and checking it before running

From here on, it's about Lask. I implemented the static boundary check, the first layer in Table 1, as type checking in a task runner.

Narrowing the mount with base_access

Lask has always run every command in a container. The host's home directory and ~/.ssh aren't visible from inside.

But it mounted the repository directory read-write at /work. An install script could overwrite source files, read .env, and talk to the outside world.

With base_access, you can narrow that mount path by path. The example below makes the whole repository read-only, lets only dist be written, and makes .env appear empty. network: "none" also cuts off outside access.

offline = #node:24.21.0-alpine3.24{base_access: { ".": "ro", "dist": "rw", ".env": "none" }, network: "none"}

In a container with these settings, I tried writing to the source, reading .env, and reaching the npm registry.

$ touch src/x.js
touch: src/x.js: Read-only file system

$ wc -c .env
0 .env

$ node -e "fetch('https://registry.npmjs.org')..."
TypeError: fetch failed
  [cause]: Error: getaddrinfo EAI_AGAIN registry.npmjs.org

.env is 11 bytes on the host but 0 bytes inside the container. I checked this with Lask 0.15.0, Docker Engine 29.5.3, and macOS 26.6.2 on Apple Silicon.

So far, you could do the same by assembling Docker's --mount and --network none yourself. The difference is the check in the next section.

Exceed the scope, fail before running

within declares what a module or function may access. Written at the top of a module, it covers every declaration in the module.

// main.lask
within { files: { ".": "ro", "dist": "rw", ".env": "none" }, network: "none", volumes: false, publish: false }

offline = #node:24.21.0-alpine3.24{base_access: { ".": "ro", "dist": "rw", ".env": "none" }, network: "none"}

// Builds into dist without any network.
build(): String = do {
  $[offline] npm run build
  read_file("dist/manifest.json", offline)
}

It can restrict four things:

files: what can be read or written, path by path, inside the repository
volumes: whether host paths outside the repository can be mounted
network: whether the container can talk to the outside
publish: whether the outside can connect to the container

lask check follows every place in the module that runs a command, and verifies that the settings of the container running it stay within the declaration.

Now suppose an agent adds a task that uploads dist to a preview server. It needs the network, so the agent also adds within { network: "default" } to the function.

// main.lask (added)
// Uploads dist to the preview server.
upload() within { network: "default" } = do {
  online = #node:24.21.0-alpine3.24{base_access: { ".": "ro", "dist": "rw", ".env": "none" }}
  $[online] npx -y some-uploader dist
}

Here's what lask check says:

$ lask check
main.lask:14:3-14:38: E-TYPE-WITHIN-EXCEEDED [static]: the network is "default", which within { files: { ".": "ro", ".env": "none", "dist": "rw" }, volumes: false, network: "none", publish: false } of the module does not allow (network)
  note: the constraint is at main.lask:1
  note: reached through upload, at main.lask:14

The module's within acts as a ceiling, so a function's within can't widen it. A function's constraint is checked together with the module's, and both must hold.

lask run runs the same check first, so not a single task in this module runs.

Unprovable settings fail too

If a network setting is read from an environment variable, its value isn't known until the program runs. Lask treats that as "can't be shown to hold" and reports an error.

within { network: "none" }

probe(): String =
  $[runnable(#node:24.21.0-alpine3.24, network = get_env("NET"))] node --version

$ lask check
p.lask:4:3-4:81: E-TYPE-WITHIN-UNPROVEN [static]: 'network' is not known here without running the program, so within { network: "none" } of the module cannot be shown to hold

E-TYPE-WITHIN-EXCEEDED means the scope is shown to be exceeded. E-TYPE-WITHIN-UNPROVEN means it couldn't be shown not to be. To pass, settings that affect the scope must be literals or names bound to literals. That's less convenient, but once you declare a constraint, I decided only what is shown to stay within it should pass.

When a function takes an image and its settings as an argument (an "environment" in Lask), the check happens at each call site. For a function you invoke directly with lask run, it uses the arguments from the command line and checks before running.

#local, which runs commands directly on the host, can access the whole host, so it satisfies no constraint.

l.lask:3:20-3:38: E-TYPE-WITHIN-EXCEEDED [static]: #local reaches the whole host, which within { network: "none" } of the module does not allow (network)

Separate tasks that need the network

Installing dependencies needs the network. So I put installation in a separate module that allows network access but can only write node_modules.

// deps.lask
within { files: { ".": "ro", "node_modules": "rw", ".env": "none" }, volumes: false, publish: false }

deps = #node:24.21.0-alpine3.24{base_access: { ".": "ro", "node_modules": "rw", ".env": "none" }}

// Installs dependencies; install scripts can reach the network but write only node_modules.
export install() = $[deps] npm install --no-package-lock

Install scripts can reach the outside, but they can't read .env or overwrite source files. The build side can read node_modules but can't reach the network.

Figure 1. What each task's container can access

lask envs access lists what the commands in a module can access. It runs nothing and doesn't contact the container engine.

$ lask envs access --module deps.lask
ENVIRONMENT                            FILES                             NETWORK    CHECK  REQUIRED BY
#node:24.21.0-alpine3.24{base_access}  . ro, .env none, node_modules rw  default !  ok     deps.lask: install

1 row (1 registry): 1 ok

! marks anything that can access beyond the repository. Here, it shows that the container can reach the outside.

Check with envs access before running

In Kleppmann's argument, people read the spec and a proof checker verifies that the code meets it. I think Lask can narrow what people read in the same way. Instead of reading every command an agent added, you check the access scope with lask envs access before running.

$ lask envs access build
within { files: { ".": "ro", ".env": "none", "dist": "rw" }, volumes: false, network: "none", publish: false }
ENVIRONMENT                                    FILES                     NETWORK  CHECK  REQUIRED BY
#node:24.21.0-alpine3.24{base_access,network}  . ro, .env none, dist rw  none     ok     main.lask: build

1 row (1 registry): 1 ok

Given a function, the first line shows the constraint the function is checked against. Below it are the scopes of the commands the function runs.

The list is built from the same code that runs. If an agent edits the within line itself, the constraint on the first line changes, so you notice before running.

Without a function, you get the list for the whole module. With the upload() task from earlier, it looks like this:

$ lask envs access
ENVIRONMENT                                    FILES                     NETWORK    CHECK     REQUIRED BY
#node:24.21.0-alpine3.24{base_access,network}  . ro, .env none, dist rw  none       ok        main.lask: build
#node:24.21.0-alpine3.24{base_access}          . ro, .env none, dist rw  default !  exceeded  main.lask: upload

2 rows (2 registry): 1 ok, 1 exceeded

An exceeded row is a task with a command that goes beyond the declaration. Rows marked ! tell you which tasks talk to the outside. envs access runs nothing, and it exits with 0 even when something exceeds the scope.

A person reads this list, and lask check verifies that every command stays within it. However many tasks an agent adds, this list is all a person needs to check.

The split looks like this:

An agent adds a task.
A person checks the access scope with lask envs access.
lask run checks the module before running anything.
If everything is ok, the commands run. If anything is exceeded or unproven, nothing runs.

What within doesn't protect

within is a static check done by Lask's type checker. Unlike Containment Verification in Part 1, the checker itself isn't machine-verified, for example in Dafny. If the checker has a bug, a command that exceeds the scope can still pass.

What it protects is limited too:

The network can only be none or default. The install scripts in deps.lask can talk to anywhere on the internet. The next section covers limiting destinations.
Environment variables aren't covered. A secret passed through env can be read by that command. Pass a secret to a container with network access, and it could still be exfiltrated.
Tasks run with #local satisfy no constraint. Tasks that need #local have to live in a module without within.
lask sync, which builds and pulls images, isn't covered.
The container engine, such as Docker, is what enforces the scope at runtime. If its isolation is broken, the declaration means nothing.
Only commands run through Lask are checked. If an agent runs npm install directly from a shell, Lask can't check it.

The last point is a separate problem: how to restrict the agent's own permissions. That belongs to the agent's permission settings and sandbox.

Egress, under consideration

Outbound traffic from containers (egress) is currently all or nothing. The npm install in deps.lask only needs to reach the npm registry, but with network: "default", install scripts can reach anywhere on the internet. As with the npm worms in Part 1, any secret they can read could be sent out.

So, as the next step, I'm considering egress that lets you list the destinations a task may reach. The design I have in mind:

Connect the task's container to an internal Docker network with no route to the outside.
Put a proxy container on the same network and route all outbound traffic through it. Pin the proxy image by digest, like any other image.
The proxy only forwards traffic to destinations on the allowlist.

The task's container has no way out except through the proxy, so an install script that tries to bypass the proxy can't reach the outside. This is still at the design stage, and the syntax isn't decided.

Wrapping up

It's getting hard to read all the code AI writes. But you can narrow what people read to the list lask envs access prints, and leave the rest to type checking. That's what I wanted to show in this post.

within just landed in 0.15.0, and both how constraints are written and what the check covers are still being worked out. I'd love to hear how it works for you, or what constraints you'd want.

https://github.com/lask-task-runner/lask

Say Goodbye to "It Works on My Machine": Why I Built a New Task Runner 🚀

Toru Ikeda — Wed, 19 Aug 2026 12:00:46 +0000

Have you ever spent hours—or even days—debugging a failed build or deployment, only to realize the issue was a slight difference in local environments?

Maybe your colleague had Go 1.21 installed instead of Go 1.22. Maybe they were on Windows while you were on a Mac. Or maybe their AWS CLI version was slightly outdated.

We've all been there. It's the classic "It works on my machine" problem.

To solve this, I built Lask, a task runner that eliminates environment discrepancies by embedding the execution environment directly into the syntax. Here is why I built it and how it works.

🛑 The limitations of current solutions

When trying to standardize tasks, teams usually lean on two approaches:

Shell Scripts & Makefiles: Writing scripts automates the steps, but it doesn't standardize the execution environment. You are still at the mercy of whatever is installed on the host OS.
CI/CD Pipelines: Running tasks in GitHub Actions or CI provides a perfectly clean, reproducible environment. However, it sacrifices the fast feedback loop of local development. Developers often struggle to test the exact same CI pipeline locally.

I wanted a tool that combines the reproducibility of CI/CD with the speed and convenience of local execution.

✨ Enter: Lask

Lask is an open-source task runner designed around three core principles: Reproducibility, Portability, and Ease of Execution.

Instead of relying on whatever tools are installed on your host machine, Lask lets you define the execution environment inline, right next to your command.

Here is what a publish task looks like in Lask:

// main.lask
publish(--var: String = "1.0.0") = do {
  // Run inside a Go 1.22 container
  $[#golang:1.22] GOOS=linux GOARCH=arm64 go build -o bootstrap ./cmd/lambda

  // Run inside a Zip container
  $[#zip:latest] zip function.zip bootstrap

  // Run inside an AWS CLI container
  $[#aws-cli:2.36] aws lambda update-function-code \
    --function-name my-function \
    --zip-file fileb://function.zip
}

By simply typing lask run publish in your terminal, Lask uses containers under the hood to execute each step in its exact required environment.

Why this changes the game:

🔒 True Reproducibility: Because the environment (#golang:1.22, #aws-cli:2.36) is hardcoded into the task, anyone running the script gets the exact same result. No more accidental mismatches.
🌍 Portability: Whether you are on Linux, macOS, Windows, or inside a CI runner, the behavior is identical. You effectively bring the CI environment down to your local machine.
⚡ Zero Setup: Lask is delivered as a single binary. It also features static typing for safety and a built-in REPL for int eractive experimentation!

$ lask repl
lask> $[#rancher/cowsay] cowsay "Hello, Lask!"

🤝 I'd love your feedback!
Lask is completely open-source and actively being developed. If you are tired of debugging local environment issues, I would be thrilled if you gave it a try or checked out the code.

⭐ GitHub: lask-task-runner/lask

What tools do you currently use to keep dev environments in sync across your team? Let me know in the comments below! 👇