AI agents and TypeScript harnesses
TypeScript runtimes, SDKs, MCP servers, agent extensions, structured tools, orchestration, custom agent instructions, and deterministic agent infrastructure.
30%
Best tweets about TypeScript
50 Best Tweets About TypeScript (2026)
Browse the best tweets about TypeScript, from type-system techniques and releases to tooling, architecture, migrations, libraries, and developer workflows.
Technical TypeScript language features, type patterns, tooling, migrations, architecture, releases, and real codebase lessons.
- Creators
- 44
- Updated
Original Xholic analysis
What 50 top TypeScript posts reveal
The dataset is led by posts about AI-agent TypeScript harnesses (30% of tweets) and type-system patterns and correctness (28%), with releases, tooling migrations, and performance-oriented runtime choices also represented. Agent and correctness posts include typed tools, validation, compile checks, and explicit boundary handling; CLI posts include arguments for Go where portability and installation friction are primary constraints.
- Dominant tone
- Positive
- Median score
- 13.5
- Leading format
- Announcement
- Recent posts
- 26%
68% of posts
All-time engagement
58% of posts
Published in 90 days
Conversation map
The themes creators return to
Type-system patterns and correctness
Strictness, null handling, narrowing, generics, discriminated unions, isolated modules, schema validation, and compile-time safety across application boundaries.
28%
Tooling, builds, and migrations
Lint migrations, runtime choices, pnpm monorepos, generated clients, transpilation-free workflows, bundling, package management, and TypeScript-to-other-language tradeoffs.
24%
Language releases and compiler evolution
TypeScript 6.0/7.0 releases, new checking and module features, the Go-based native-speed compiler transition, and editor support for newer toolchains.
16%
TypeScript-native architecture
Using TypeScript as the primary configuration and implementation language for full-stack systems, plugins, APIs, workspace specs, and code-first platforms.
16%
Performance and native interop
Accelerating TypeScript with Rust, Zig, WebAssembly, native cores, and comparisons with Go or compiled languages for CLIs and performance-sensitive workloads.
14%
Codebase modularity and enforcement
Deep modules, dependency boundaries, plugin systems, test seams, circular-dependency prevention, and architecture rules enforced by static tooling.
12%
Domain-specific TypeScript applications
TypeScript applied beyond conventional web apps, including UI layout engines, PCB design, terminal interfaces, deployment models, and infrastructure definitions.
6%
Tone and stance
Sentiment Positive leads
Author posture Supportive leads
Performance benchmark
- Median likes
- 85
- Median reposts
- 7
- Median replies
- 3
- Median views
- 7.1K
Posts with media make up 54% of this collection. Their median all-time score is 13.9, compared with 13.1 for text-only posts.
Format mix
- Announcement 58% · score 19.7
- Opinion 14% · score 5.32
- Tutorial 14% · score 0.82
- Case Study 10% · score 7.92
Consensus and debate
Where creators agree, and where they do not
Shared view
Typed tools and validation recur in agent-harness posts
Several posts describe TypeScript-based agent infrastructure using typed tool calls, schemas or validation, compile checks, and structured state handling. Examples include an n8n workflow SDK with validation, a TypeScript SDK with Zod-backed tools, and a system that validates typed tool calls before database writes.
Shared view
Boundary handling and type-safe interfaces are recurring correctness patterns
Posts highlight converting external nulls and throws at boundaries, handling nulls explicitly, sharing API types across frontend and backend, and designing type-safe plugin interfaces. These are examples of TypeScript being applied to interface and integration boundaries.
Shared view
TypeScript is used to define systems beyond conventional UI code
Examples include defining a Notion workspace in TypeScript, TypeScript React code for PCB design, TypeScript-defined AppHosts, and a TypeScript-native application specification. The posts present TypeScript as both implementation code and a way to describe system configuration or structure.
Open debate
Ultra-strict constraints versus conventional null discipline
One post proposes an experimental TypeScript variant without nulls, undefineds, classes, switches, vars, and with match macros, framing the restrictions as useful for AI-written code. Another argues that production failures from an unhandled null call for using TypeScript and handling nulls. Together, they show different views on how far language constraints should go.
Open debate
TypeScript or Go for portable CLIs
One post reports that Appwrite's CLI move from TypeScript to Go produced a 17× startup improvement, two installed packages rather than 330, a 66 MB-to-14 MB binary change, and one-tenth the memory footprint. A separate post argues that stack choice should follow workload, naming TypeScript as a possible fit for frontend-heavy agent apps and Go for infrastructure-heavy CLIs and TUIs.
What performs
Patterns behind standout posts
Domain-specific applications produced the two largest score outliers
The largest deterministic-analytics outlier was the pure-TypeScript text-measurement post (all-time score 11,119.36). The second was the React-and-TypeScript PCB workflow post (3,934.29). Both concern domain-specific applications rather than a standard tooling or release announcement.
The TypeScript 6.0 availability post was a score outlier
The TypeScript 6.0 availability announcement is listed as an outlier with an all-time score of 899.32. Its text cites better method type-checking, new standard-library features, Node.js module features, and progress toward the upcoming native-speed 7.0 release.
Modularity and enforcement had a higher median score than the tooling-and-migrations theme
Deterministic analytics reports a 31.26 median all-time score for codebase modularity and enforcement, compared with 4.4 for tooling, builds, and migrations. One modularity example describes deep modules, restricted import seams, circular-dependency prevention, and dependency-cruiser enforcement.
Statistical standouts
- View standout post 1 Score 11119.4 · 825.49× median
- View standout post 2 Score 3934.3 · 292.08× median
- View standout post 3 Score 899.3 · 66.76× median
- View standout post 4 Score 596.3 · 44.27× median
- View standout post 5 Score 383.0 · 28.43× median
Creator landscape
Who shapes this conversation
The five most represented creators account for 20% of the selected posts.
-
1. freeCodeCamp.org
@freeCodeCamp
2 posts
-
2. GitHub Projects Community
@GithubProjects
2 posts
-
3. Matija Sosic
@MatijaSosic
2 posts
-
4. Prisma
@prisma
2 posts
-
5. DEV Community
@ThePracticalDev
2 posts
-
6. TypeScript
@typescript
2 posts
The official TypeScript account is a top voice for release updates
The TypeScript account appears among the top voices with two tweets and a 519.08 median all-time score. Its cited posts announce the 6.0 release candidate and the availability of TypeScript 6.0.
freeCodeCamp’s two cited posts focus on implementation guidance
freeCodeCamp’s cited posts cover a type-safe React plugin architecture and end-to-end type safety in full-stack TypeScript apps using tRPC and Hono.
Since the previous snapshot
What changed since Aug 12, 2026
- 70% of the selected posts remained.
- The creator count changed by 0.
- The leading sentiment remained stable.
How this analysis was made
Themes, sentiment, stance, and post format are classified per tweet. All counts, shares, medians, creator concentration, freshness, and performance comparisons are then calculated directly from the published snapshot.
Xholic's all-time score compares engagement while accounting for reach, post age, and creator consistency. It is used for relative comparisons within this collection.
This report analyzes the exact 50-post snapshot shown below. AI identifies editorial categories and drafts explanations; all statistics are calculated from the snapshot, and every narrative claim is checked against cited posts before publication.
Best TypeScript tweets
Top TypeScript tweets from 44 creators
Ranked 01–50
- 01
@_chenglou ·
My dear front-end developers (and anyone who’s interested in the future of interfaces): I have crawled through depths of hell to bring you, for the foreseeable years, one of the more important foundational pieces of UI engineering (if not in implementation then certainly at least in concept): Fast, accurate and comprehensive userland text measurement algorithm in pure TypeScript, usable for laying out entire web pages without CSS, bypassing DOM measurements and reflow
Watch video
- 02
@heynavtoor ·
🚨 Electrical engineers are going to hate this. Someone just turned React into a circuit board factory. Write code. Get a real PCB manufactured and delivered to your door. It's called tscircuit. React for Electronics. No Altium. No $10,000/year licenses. No 6-month learning curve. You write React components. But instead of <div> and <button>, you write <resistor>, <chip>, and <capacitor>. The same way you build a website. That's how you build a circuit board now. Here's what this thing actually does: → Design real circuit boards using TypeScript and React → Edit code in your IDE, watch the circuit update in real time → Auto-generates schematics, PCB layouts, and 3D previews from your code → Automatic part selection and bill of materials generation → Built-in autorouting algorithm for PCB traces → Export to Gerber files and send directly to a manufacturer → Online playground. Design circuits in your browser right now. Here's the wildest part: The creator wrote 40 lines of TypeScript. From that he got a full PCB, a schematic, and a 3D preview. Then he exported it, sent it to a manufacturer, and got a real working circuit board delivered. 40 lines of code. A real physical product. This is free. Write React. Get hardware. $20K+ in bounties already paid to contributors. 8 years in the making. 100% Open Source. MIT License.
Watch video
- 03
- 04
@NotionHQ ·
Now in beta: Notion as code. Define an entire workspace in TypeScript: teamspaces, databases, custom agents, all of it… then deploy it through the API. Build workspaces with coding agents, version-control your setup in git, and reproduce the same setup anywhere you need it. https://t.co/1ENjbBA93k
- 05
@tan_stack ·
LLMs are bad at math. They’re bad at orchestration. But they’re really good at writing TypeScript. So we gave them a runtime. Code Mode in TanStack AI lets the model write & execute TS instead of chaining tools. 🧠 1 call instead of N ⚡ parallel execution 📉 fewer tokens ✔︎ correct results This changes how you build AI apps. Blog ↓ https://t.co/EgvVul84Hd
- 06
@n8n_io ·
n8n's official Claude Code connector can now create and edit workflows! This goes way beyond plugging an API into MCP. It's purpose built for LLMs. Includes a new workflow TypeScript SDK so workflows are written as code instead of JSON, with more reliable validation. Works anywhere MCPs are supported (n8n 2.18.5+). 🔗 Full video: https://t.co/9D8H2VgHaY
Watch video
- 07
- 08
@justinstorre ·
I am experimenting with something I call "Typescript Ultra Strict". Basically, typescript with no nulls, no classes, no undefineds, no switch statements, and no vars + the addition of match macros. Basically forcing AI to write functional AI code through compilation errors that is more deterministic and testable. Back in 2008 Chrome built the V8 Javascript engine and the entire world built edge compute on top of this amazing primitive. However, Javascript had it's short comings so we made Typescript, but Typescript still was "too friendly", mainly to appeal to a human audience. We no longer have humans writing code, so why not give the AI something less clunky and more clanky 😉 UX - write .tsus files - add a one-line plugin to webpack, Vite, esbuild, or Bun Features include: - Option/Result runtime, with boundary helpers that turn the outside world's nulls and throws into Option and Result - match macros - good error messages, so an agent can fix its own errors in a loop
- 09
@mattpocockuk ·
Here's a skill you can run once to set up deep modules in any TypeScript codebase: - Each 'package' lives at src/packages/<name> (name/path is totally customizable) - From outside the package, you can only import from <name>/index.ts - Tests for the package live at <name>/tests, and can only import from index.ts - No circular dependencies between packages - Puts a context pointer inside AGENTS.md so the agent knows about it (no skills needed) - Works with frontend or backend code (even Effect code!) - Enforced by dependency-cruiser This means you can hide stuff inside modules, with only a single test seam exposed. Clear seams, deterministically enforced: no more shit tests. Awaiting a merge. Should I ship it? https://t.co/6VGvNb6tMl
- 10
- 11
- 12
@akshay_pachaar ·
There's an interesting study by GitHub on coding agents! They analyzed 2,500+ custom instruction files across public repos to understand what separates effective agent setups from weak ones. Effective setups give agents a specific persona, exact commands to run, defined boundaries, and examples of good output. Weak ones are vague helpers with no clear job description. This points to the core friction with coding agents today, which is that they don't have a capability problem but rather a context problem. A raw agent can write code, but it doesn't know the team's naming conventions, the specific linting setup, or preferred framework patterns. Without that context, the first PR is often off-target and requires multiple rounds of correction. Getting this right requires structured context, and GitHub Copilot implements a smart, layered customization system that does exactly this. > At the repo level, a `.github/copilot-instructions .md` file defines project-wide rules like coding conventions, naming standards, security defaults, and prohibited patterns. The agent reads this before generating any code. > For granular control, instruction files in .github/instructions/ can target specific file paths using applyTo frontmatter. A TypeScript-specific instruction file only activates when the agent works on .ts files. > The most interesting addition is custom agents. These are `.agent .md` files in `.github/agents/` that define specialized personas with their own tool access and MCP server connections. For instance, a security auditor agent can be configured with only read access and run linters before flagging issues. A test writer agent can follow specific testing patterns defined by the team. Each agent has defined boundaries for what it can and cannot do. These custom agents can also be defined at the organization level in a .github-private repo and inherited across all repositories. Frontend conventions, backend patterns, and security policies apply everywhere without duplicating config files. But the customization doesn't stop at DIY setups. There's more 👇
Watch video
- 13
@freeCodeCamp ·
Large React apps get harder to scale when every feature has to live inside the core codebase. In this tutorial, Jessica shows you how to design a React plugin architecture with TypeScript that is type-safe, lazy-loaded, and secure. You'll also learn about hosting APIs, plugin lifecycles, separate bundling, runtime loading, and more. https://t.co/SsT4uIKAnH
- 14
@cramforce ·
Test your SKILL.md Now that code is free, you can just test things. Here is Chat SDK's chat-skill.test.ts https://t.co/7HlenkDeNY - Does the inline TypeScript compile? - Do the mentioned paths references into node_modules/ exist when you pack the repo with npm? - Does it list all built-in adapters that exist in the repo? - Does it list all community adapters listed in the docs? - Etc.
- 15
@_Evan_Boyle ·
Copilot CLI can now write and hot reload it's own typescript extensions! Here the agent wrote it's own snake extension that only lets me play while copilot is busy, and pauses the game when I need to provide input. Available today in /experimental mode v1.0.3
Watch video
- 16
@GithubProjects ·
OpenTUI is a native terminal UI core written in Zig with TypeScript bindings, used in production by OpenCode and https://t.co/jIwOeYdDq7. - Component-based architecture with flexible layout capabilities - TypeScript bindings with React and SolidJS reconcilers - Three.js WebGPU renderer for browser-based UIs - Extensible C ABI for use from any language Explore it here: https://t.co/leees9XABn
- 17
- 18
- 19
@freeCodeCamp ·
Did you know – you can get end-to-end type safety in full-stack TypeScript apps without schema files or code generation. In this guide, @itsTarun24 shows you how to use tRPC and Hono to build APIs where the backend and frontend share types automatically. You'll learn when to use each tool and how they improve reliability, catch errors at compile time, and speed up development. https://t.co/jPqlzN44oH
- 20
@PentesterLab ·
𝗥𝗲𝘀𝗲𝗮𝗿𝗰𝗵 𝗪𝗼𝗿𝘁𝗵 𝗥𝗲𝗮𝗱𝗶𝗻𝗴 - 𝗪𝗲𝗲𝗸 𝟳, 𝟮𝟬𝟮𝟲 Parser Differential, TypeScript and AI ⨐ 𝗕𝗿𝗲𝗮𝗸𝗶𝗻𝗴 𝗗𝗼𝘄𝗻 𝗖𝗩𝗘-𝟮𝟬𝟮𝟲-𝟮𝟱𝟬𝟰𝟵: 𝗛𝗼𝘄 𝗧𝘆𝗽𝗲𝗦𝗰𝗿𝗶𝗽𝘁 𝗧𝘆𝗽𝗲𝘀 𝗙𝗮𝗶𝗹𝗲𝗱 𝗻𝟴𝗻'𝘀 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆 A great explanation of the recent vulnerabilities impacting n8n. If you are working in security on TypeScript projects, it's a must read. https://t.co/9cqTpEAluI. ⚒️ 𝗜𝗻𝘁𝗿𝗼𝗱𝘂𝗰𝗶𝗻𝗴 𝗔𝘂𝗴𝘂𝘀𝘁𝘂𝘀: 𝗢𝗽𝗲𝗻 𝗦𝗼𝘂𝗿𝗰𝗲 𝗟𝗟𝗠 𝗣𝗿𝗼𝗺𝗽𝘁 𝗜𝗻𝗷𝗲𝗰𝘁𝗶𝗼𝗻 𝗧𝗼𝗼𝗹 Praetorian is back with another tool (one of their 12 Caesars): Augustus... Make sure you check it out! https://t.co/kIgkNwiNMM. 🤺 𝗪𝗵𝗲𝗻 𝗧𝘄𝗼 𝗣𝗮𝗿𝘀𝗲𝗿𝘀 𝗗𝗶𝘀𝗮𝗴𝗿𝗲𝗲: 𝗘𝘅𝗽𝗹𝗼𝗶𝘁𝗶𝗻𝗴 𝗤𝘂𝗲𝗿𝘆 𝗦𝘁𝗿𝗶𝗻𝗴 𝗗𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝘁𝗶𝗮𝗹𝘀 𝗳𝗼𝗿 𝗫𝗦𝗦 If you enjoy parser differential issues, you are going to love this exploit. Don't think "It's a CTF challenge" or "It's just an XSS", read between the lines to find the real gold. https://t.co/rwf2BGnerh. 🤖 𝗥𝗖𝗘 𝗶𝗻 𝗚𝗼𝗼𝗴𝗹𝗲'𝘀 𝗔𝗜 𝗰𝗼𝗱𝗲 𝗲𝗱𝗶𝘁𝗼𝗿 𝗔𝗻𝘁𝗶𝗴𝗿𝗮𝘃𝗶𝘁𝘆 - $𝟭𝟬𝟬𝟬𝟬 𝗕𝗼𝘂𝗻𝘁𝘆 A detailed blog post on hacking Antigravity with a lot of interesting details on its inner workings. https://t.co/3ExHVYrf9X. 🚛 𝗧𝗿𝗮𝗶𝗹𝗶𝗻𝗴 𝗗𝗮𝗻𝗴𝗲𝗿: 𝗲𝘅𝗽𝗹𝗼𝗿𝗶𝗻𝗴 𝗛𝗧𝗧𝗣 𝗧𝗿𝗮𝗶𝗹𝗲𝗿 𝗽𝗮𝗿𝘀𝗶𝗻𝗴 𝗱𝗶𝘀𝗰𝗿𝗲𝗽𝗮𝗻𝗰𝗶𝗲𝘀 Probably one of the lesser-known features of HTTP... Trailers. This post provides details on the feature and explains how they can be leveraged to find security issues. https://t.co/I2J8yvXdpa.
- 21
@gsd_foundation ·
A whole plague of bugs and second-cousin bugs have been fixed and prevented from surfacing in the future for GSD-2 in v2.44.0. Updates and responses to issues and PRs slowed down over the past 48 hours while deep work was done behind the scenes to rebuild one of the core parts of the GSD-2 system. Here's what happened and why it matters. The problem we solved GSD tracks your project's progress – milestones, slices, tasks, what's done, what's next. Until now, all of that state lived in markdown files. The AI had to read, parse, and rewrite those files to track its own progress. Think: regex-matching checkbox states across multiple files, toggling - [ ] to - [x], and hoping the formatting stayed parseable. This was the single biggest source of bugs. The AI is brilliant at writing code and plans – it's unreliable at mechanical bookkeeping. When a checkbox toggle went wrong silently, five different state markers would disagree, and a cascade of reconciliation systems (doctor, stuck detection, self-heal, recovery) would fire trying to fix things. We had ~2,500 lines of code just for reconciliation. What v2.44.0 changes We replaced the entire system. State transitions are now atomic SQLite transactions driven by structured tool calls. The AI says "complete task T01" via a typed tool call → TypeScript validates → writes to DB in a single transaction → renders the markdown as a view. If anything fails, it rolls back cleanly. Two PRs made this happen: PR #2141 – Tool-driven completionsReplaced markdown mutation for task/slice completion with gsd_complete_task and gsd_slice_complete tool calls. Rewrote deriveState() from a 50-200ms filesystem scan to a <1ms SQL query. Removed ~800 lines of dead reconciliation code from doctor. Added crash recovery, rogue file detection (catches when the AI tries to bypass tools and write files directly), and undo commands. PR #2280 – Tool-driven planningThe last major component using markdown as source of truth. Added 5 planning tools (gsd_plan_milestone, gsd_plan_slice, gsd_plan_task, gsd_replan_slice, gsd_reassess_roadmap). The 12-variant regex cascade in the roadmap parser is now legacy code used only for migration. Structural enforcement means the AI physically cannot delete completed work during replanning — TypeScript rejects it before it hits the DB. What this means for you • Fewer mysterious state bugs (no more "why does GSD think this task isn't done?") • Faster state resolution (DB queries instead of filesystem scans) • Safer replanning (completed work is structurally protected, not just prompt-instructed) • Better crash recovery (DB transactions mean no more half-written state) • The ~2,500 lines of reconciliation code that existed to patch over markdown unreliability are being systematically removed Existing projects auto-migrate on first access. No manual steps needed. This was a big one. Back to regular PR velocity now. Update with: `npm i -g gsd-pi@latest`
- 22
- 23
- 24
@mehulmpt ·
Nub by @colinhacks is a big deal and a long time coming. Bun made running TypeScript cool locally, without worrying about transpiling or fighting with your own code. Today in 2026, `tsx` package, and other tooling combined with pnpm, a faster laptop, and a little patience and ecosystem knowledge, allows you to get the stability of Node with the experience you'd want from a runtime like Bun. That bun <> node gap closed a little today with Nub, which I spent some time reading about and playing with. Made me remember the 2021-2022ish broken esbuild local setup systems we used to have to run the code locally. We have come a long way from that. Talking about that in a video today
- 25
@GithubProjects ·
This is the monorepo behind the TypeScript website, containing the playground, sandbox, and documentation tooling. - Uses pnpm workspaces with node 20+ and watchman for file watching. - All packages support `pnpm build`, `pnpm test`, and debug logging via the `debug` package. - Deployment is automatic: pushes to the `v2` branch deploy to production. - Changesets manage version bumps for public packages like `@typescript/twoslash` and `@typescript/sandbox`.
- 26
@tetsuoai ·
https://t.co/66cxhv7svg The X API is now available worldwide with pay-per-use pricing. X has also released official Python and TypeScript XDKs, an MCP server, xurl for agents, and a local Playground that lets you test the X API without using credits. If you spend on X API credits, you can get up to 20% back in XAI API credits. X is uniting real-time data, execution, testing, and developer tools into a single platform. This means X is becoming the go-to platform for agents.
- 27
- 28
- 29
@0xlelouch_ ·
90% of frontend engineering interviews in 2026 come down to these 7 points: 1) Debugging in the browser Repro the bug, read stack traces + network, isolate a minimal case, ship a fix without breaking perf. 2) State + data flow Local vs server state, cache invalidation, optimistic updates, race conditions, and why a stale closure bit you. 3) Performance Core Web Vitals, bundle size, code-splitting, memoization tradeoffs, and how you’d prove the win with a profile. 4) TypeScript in anger Narrowing, generics, discriminated unions, and when to stop fighting the type system and refactor. 5) HTTP + auth basics CORS, cookies vs tokens, CSRF, refresh flows, and why a 401 loop happens behind a reverse proxy. 6) Testing strategy Unit vs integration vs e2e, what to mock, flaky test causes, and how to test async UI without sleeps. 7) Frontend system design Component boundaries, routing, error/loading states, observability, and deploy/rollback with CI + feature flags
- 30
- 31
- 32
- 33
@johncrickett ·
The bug rate per line of code has sat at 15 to 50 per 1,000 for 30 years. Better languages didn't shift it. Static analysis didn't shift it. Claude Code: 512k lines of TypeScript, 10k+ open issues. About 20 per 1,000. AI has changed how fast we generate code. It appears that those lines of code still come with the same defect density. What are you seeing in your projects?
- 34
- 35
@seveibar ·
whirlwind day of optimizations first I wrote a typescript autorouter that I thought was pretty fast then I got chatgpt pro to rewrite it in rust/WASM and that was 40x faster! (darn, bye js?) then I asked chatgpt pro to look at the Rust code and make the Typescript code as fast as the Rust code, and now the Typescript is 25% faster So now I'm around 50x where I started, and the only downside is now I can't read any of the code lol
- 36
- 37
- 38
@pauliusztin_ ·
Most agentic CLIs are built in TypeScript. Here’s why that’s a mistake (and you should use Go instead): We'll use Michael @maximilien as an example… He built his Weave CLI with Go. He's also the former CTO at IBM and former Chairperson of the NodeJS Foundation. So this is not a “TypeScript is bad” take... He knows the ecosystem deeply. But when he started building Weave CLI, an open-source tool for production RAG across 11 vector databases, the constraints were different. He needed something that could run anywhere. And this is where Go shines. It has no: • npm install • Python virtual envs • uv issues • JVM setup • Broken package registries • On-prem network restrictions Just download the binary, make it executable, and run it. Weave CLI has to: • Spin up vector databases • Ingest documents • Run RAG agents • Compare embeddings • Benchmark configurations • Monitor traces & experiments with Opik by @Cometml For this kind of infrastructure tooling, installation friction is product friction. If users can’t run it easily, they won’t use it. But there's a deeper lesson in this: Don’t pick your stack based on the herd. Pick it based on what the system needs. For frontend-heavy agent apps, TypeScript may be the right choice. For infra-heavy CLIs and TUIs that need to run anywhere, Go is hard to beat. Full Weave CLI case study in Decoding AI Magazine: https://t.co/MpJ3bYuH8g
- 39
@ibuildthecloud ·
I'm absolutely fascinated by the fact that frontend developers accept typescript. That means it's possible to build a better language for frontend. Everything frontend people have rejected about compiled and statically typed languages they have brought to JavaScript. So it's definitely possible to create a statically typed compiled language for frontend that would be ridiculously fast compared to typescript. It's a times like this I wish I didn't have a job.
- 40
@MatijaSosic ·
Just spent two hours testing the final Wasp TypeScript Spec with @infomiho, and I got really excited about it. One of the gamechangers is definitely the ability to split your spec file across multiple files and organize features in vertical units. Plus, since it's all just TS now, type safety and go-to-definition work out of the box. Can't wait to ship this.
- 41
- 42
- 43
- 44
@JeremyCMorgan ·
A source-level analysis of Claude Code's publicly available TypeScript finds only 1.6% of the codebase is AI decision logic. The other 98.4% is deterministic infrastructure: permission gates, context management, tool routing, recovery, hooks, isolation. The agent loop is the small part; the harness is the product. https://t.co/uQqMznCGWj
- 45
@buildwithhassan ·
claude code shipped its full TypeScript source again via .js.map in the npm package (v2.1.88) second time this packaging footgun happened and this is a terminal agent people run with --dangerously-skip-permissions / auto-accept sourcemaps = architecture + security assumptions exposed
- 46
@ThePracticalDev ·
When agent deployments become slow and costly, ADK callback hooks are often the overlooked fix. This dev breaks down how beforeModelCallback, afterToolCallback, and others can cut unnecessary LLM calls, track latency, and manage session state. All with real TypeScript patterns. { author: @connieleung404 + @GoogleDevExpert } https://t.co/RhUDbnG1wA
- 47
- 48
- 49
- 50
@ThePracticalDev ·
When Claude Code v2.1.88 shipped with its full TypeScript source exposed via npm source maps, this dev read the tool architecture. The findings: 58 tools share one interface that forces safety declarations, defaults fail closed, and the BashTool runs 22 security validators before any command executes. { author: klement Gunndu } https://t.co/92FctP6POZ
Best Tweets by Topic