perry VS tsz

On other sites, like github and reddit. This exchange was funny though. He eventually gets called out by the other commenter to stop responding with an LLM: https://github.com/PerryTS/perry/issues/139#issuecomment-429...

Hey HN — I've been building Perry, a compiler that takes TypeScript and emits native binaries. No V8, no runtime, no Electron. It maps to platform-native UI widgets: AppKit on macOS, UIKit on iOS, Android Views on Android, GTK4 on Linux, Win32 on Windows.

Pry is the first real app built with it — a JSON viewer, deliberately small.

It's in the iOS/macOS App Store and Google Play right now. Linux build works, Windows is waiting on code signing.

The compiler itself is written in Rust. It handles TypeScript parsing, type checking, and lowers to native code. The UI bindings aren't a wrapper library — the compiler generates the actual platform API calls.

This is a building-in-public thing. Pry is the proof-of-concept. The bigger goal is a full IDE. Happy to answer questions about the compiler architecture, the app store submission process, or anything else.

Compiler repo: https://github.com/PerryTS/perry

In my project I let the agents communicate in GitHub issues and pull requests like humans do. I kinda stopped trying making orchestration frameworks.

You can see the slop here

https://github.com/mohsen1/tsz

I am taking this attitude to an extreme with tsz. I don't want to announce to the world that tsz is ready until I tested it really really well.

Currently tsz passes nearly 100% of TypeScript tests but that is not enough. I want it to be able to type check complex things like type-challenges solutions or complex utility type packages. I'm stress testing it with a repo with 1.5 million lines of code.

I'm constantly assigning AI agents tasks to find bugs in tsz and open issues.

I'll say this is "alpha" when it can do all those things plus matching tsc exactly in thousands of open source projects where tsc reported type errors. It's easy to find CI runs that tsc reported errors. I'll build a database of all the cases I've verified and will publish those.

For now, tsz is just a work in progress.

https://tsz.dev

> Honest status

> Not at 100% - and I want to be straight about why that's a longer road...

I just want Claude Code to stop giving up on achieving tasks. It's so annoying. Even with `/goal` or the new `ultracode` it gives up constantly.

My project is very complex (https://github.com/mohsen1/tsz) but Codex has no problem keep grinding without stopping like that

in tsz (https://tsz.dev) I am Codex-Maxxing with this:

Give each Codex an AgentName and ask them to mark their PR/issue/comments with those. Have one or two "managers" that manage PRs and overall project direction. I write the project directions and make long lasting issues. Each Codex session has an almost unachievable `/goal` but they are asked to achieve the goal by landing changes in `main` via PRs

I am running about 14 Codex sessions on 4 machines right now for about two weeks since OpenAI 10x'ed my 20x account and I simply can not run out of tokens fast enough.

Side note: I have multiple Claud accounts too but the new Claude Code `/goal` command is seriously broken. It waits long pauses between iterations and sometimes prematurely stops.

I was a little shocked that they could get it fully working in a week to be honest. My side project is a very similar ambition (https://tsz.dev) but I am in no way claiming success. i keep adding more and more tests to ensure things works. Even after all of TypeScript's own tests pass I am finding bugs which I was totally expecting.

The bar for matching tsc's behavior is really _really_ high. see:

https://github.com/type-challenges/type-challenges/tree/main...

I'm not against using LLMs to write a lot of code. But verification should be 100x more robust now that we can output code at this rate.

This is very impressive to me. No matter what your thoughts are on LLMs as code generators, getting 1 million lines of code that compiles and passes tests in a week would have been unimaginable to me just a year ago.

I personally think LLMs are going to write a lot of code in the near future and if we like it or not this is going to become more and more common. I took the extreme path of fully embracing this on my side project to learn what can go wrong and how this stuff is going to impact software development in general.

My side project (https://tsz.dev) is also about 1 million lines of Rust. Since my token budget is a lot more limited than theirs, and also I am not rewriting something line-by-line into a new architecture, things have been A LOT slower than Jarred.

It's a strange time to be a software developer. There is a codebase now that I know by heart (paid work) and refuse to accept large pull requests on it as the team lead. Yet I'm doing this crazy experiment where I let agents write and evolve tsz almost entirely automatically. I am not sure the former role can sustain for too long, where you can read and understand all of the code.

Code reviews are also getting much harder to do. Almost every PR I review is AI generated and reviewed! So I have to really look for the 10k ft view of things and fully understand the system the PR is modifying. It is really exhausting because the quantity of PRs has 10x'ed since LLMs started writing acceptable code.

I hope I'm wrong about LLM coding, but from what I'm seeing the profession has changed a lot. Nobody is fighting Tabs vs. Spaces fights anymore... the passion about every line of code is mostly gone around me...