Full write-up: tvcutsem.github.io/ai-python-ty...
tl;dr — Python builds AI. TypeScript is what AI will use to "get things done"
Posts by Tom Van Cutsem
The security model is compelling too. Projects like IronCurtain expose high-level APIs to agent code, so that when it makes calls like `gmail.sendEmail({to: "bob"})` instead of making raw HTTP requests, the host can enforce semantic policy. It's basically object capabilities, applied to AI.
Results: 98-99% fewer tokens, better composability, and the type-checker validates the agent's code before it runs.
Cloudflare and Anthropic are converging on "Code Mode": instead of LLMs issuing tool calls one at a time, the LLM writes a TypeScript program against a typed host API, executed in a JS sandbox.
Why TypeScript? Not because TS is "better" than Python, but rather because of a quirk of JavaScript's history: the language has zero built-in powers. No file I/O, no network. Everything comes from the host environment. Browser → Node → and now: AI agent harnesses.
"AI was built in Python. But the code AI agents write will increasingly be TypeScript." That's the tagline of my latest post: tvcutsem.github.io/ai-python-ty...
In any case, it's great to see so much continued activity in the area of JS engines. Healthy competition is good for the ecosystem!
Judging from Github activity, both engines seem to be under active development with a roughly equal-sized pool of contributors. Here's their 'star' history. Bun is the younger project but seems to be gaining traction faster.
Both Deno and Bun support TypeScript source files natively, and they both integrate common devtools such as build system, package manager and test runner into the core.
Bun is written in the comparatively less well known Zig programming language, and it embeds JavaScriptCore, the JS engine of Apple/Safari. bun.com
Deno is created by the same person that built the original node: Ryan Dahl. It's a Rust-based project wrapping Google/Chrome's V8 JS engine. A good chunk of its stdlib is written in Typescript. deno.com
Today I was doing some research on standalone Javascript runtimes. The OG in this space is of course node.js. The two contenders for the 'modern alternative' to node seem to be Deno and Bun.
IT Industry professional in Europe? Come to Leuven, Belgium this summer, join the SecAppDev course to plug your brain into everything application security, and you won't regret that you did. This year, a special focus on (how could it not be) AI security.
AI is a huge force multiplier, but only if you have fundamentals to steer it and review it well.
That’s exactly why CS education still matters (arguably more than ever).
#AI #VibeCoding #CSedu #SoftwareEngineering
Main takeaway: low-stakes vibe coding is great for prototyping, but it’s not the same as real software engineering.
Just published a short write-up of a fun experiment: I vibe-coded a Boids simulation with AI copilots in about 30 minutes.
I built it for CS outreach, then documented what worked, what surprised me, and what I got wrong.
tvcutsem.github.io/vibe-coding-...
A few days late, but still: happy 30th ann, JavaScript! Here's a good write-up of the origin story. In my uni class I always remind students of Crock's genius quote: JS is not Java, it's "a Lisp in C's clothing" arstechnica.com/gadgets/2025...
Glad to be in Ghent at the ICP meetup. Giving a talk on Self-sovereign Apps, and the research ongoing in my group on developing scalable Wasm-based smart contracts
✔️ Paper/Poster Submission Deadline: 7 Jan 2026
✔️ Acceptance Notification: 18 Mar 2026
✔️ Conference: June 1-5 2026 (Brisbane, Australia)
I'm serving on the #ICBC 2026 PC, IEEE's flagship conference on Blockchain and cryptocurrency focused research. Consider submitting a paper if you’re working in this area.
Full CFP at icbc2026.ieee-icbc.org
There’s a tool called Lavamoat that can load your deps in an isolated environment, and auto-generate a policy file to regulate per-dependency access to powerful globals. See lavamoat.github.io
Weihong will present our paper on this new protocol at IEEE #ICDCS 2025 in Glasgow next Monday.
For a high-level overview of our work, read my blog:
👉 tvcutsem.github.io/2025/07/parp...
#blockchain #web3 #research
To address this, we designed a new RPC protocol that enables interaction with permissionless blockchains in a way that remains truly depermissioned — without sacrificing data integrity or accountability, two issues that often arise when relying on anonymous public RPC endpoints.
One of our key findings is that, despite the “permissionless” nature of most major blockchain networks, access to them is often highly permissioned in practice. Due to both technical and economic constraints, access is typically funneled through centralized gatekeepers.
🔬 Research update: Depermissioning Web3’s Serving Layer
Over the past few months, my PhD student Weihong Wang and I have been exploring challenges in Web3’s “serving layer” — the infrastructure responsible for making blockchain data accessible to decentralized applications (dapps).
Worth a read: Erik Meijer's latest piece in ACM Queue. He introduces a PL with an interesting mix of natural language instructions, logic variables and Excel-like formulas to let end-users generate readable and verifiable calculations. queue.acm.org/detail.cfm?i...
And obviously humans value clarity in responses ;-) Also, for code and math in particular, one can make the LLM's answers partly verifiable (run the code, check the proof, etc.)
I believe part of it is the RLHF (reinforcement learning with human feedback) - modern LLMs are not only trained to predict the next word in a dataset, they're also trained by producing multiple responses to questions and let humans rank the outputs based on their preference.
So, despite all the flaws and limitations of LLM use in general, for math/coding, I couldn't help but be reminded of Jobs's quote. What do you call a rickety bicycle that usually gets you to where you want to be, but sometimes breaks down unexpectedly? Velocipedes for the mind? :-)