mohsen1

Code is here https://github.com/mohsen1/axial-flux-motor-explainer

Feel free to steal! This was one shot with Claude Code. You can take it and adopt it to your need

I was curious how this thing works and asked Claude to visualize it -- mostly to see how good Fable is and I have to say, what it made was good enough for me to get a gist of it. Posted it here

https://azimi.me/axial-flux-motor-explainer/

Shameless plug. I'm writing a TypeScript checker in Rust. It's not a port. I made this with a different architecture that hopefully once is done will be proven to be a better set of trade-off

https://github.com/tsz-org/tsz

A compiler and type checker is very special case where you can fix something in the lexer or parser and break another thing in AST walker etc. tsz is well architected but those things can happen if you're not careful and that's precisely what I meant in my original comment. Fable can think how changing parser can impact checker etc...

the setup is solid. there are thousands of tests and CI won't let things to merge if tests are failing.

But overall, this is pretty normal for compilers to have this sort of "unexpected" tests failing due to some work in an area. It happened to me when I was coding everything manually back in the day too

I had a few of the benchmarks left alone and was working on tech debt knowing that a new model is going to be released soon. For my project (tsz.dev) Opus 4.8 was running in circles without producing results for a while for those tasks

I have been using it for less than an hour so take this with a grain of salt of being excited for the new tech.

In a project like mine (https://github.com/tsz-org/tsz) I am constantly frustrated that models were not doing enough research and were not taking into account other situations. Again and again models would produce code that would fix one thing and break 2 other tests that were "unrelated".

With Fable it seems like tasks are taking much longer (I have not seen a pull request from Fable sessions yet) but reading the transcription of those sessions I can see how it is doing the right thing by not leaving any stone unturned.

As the article says, it's hard to communicate this "feeling" about models because it is very project specific but I thought I share

It seems like Fable will refuse to do any work when it comes to developing LLMs or even asking questions about topics related to LLM. Simple things like asking to explain a paper fails!

From the model card:

In light of the ability of recent models to accelerate their own development, we've implemented new interventions that limit Claude's effectiveness for requests targeting frontier LLM development (for example, on building pretraining pipelines, distributed training infrastructure, or ML accelerator design. Using Claude to develop competing models already violates our Terms of Service, but enforcing this restriction through our safeguards avoids accelerating the actors most willing to violate these terms. Unlike our interventions for cybersecurity, biology and chemistry, and distillation attempts, these safeguards will not be visible to the user.

A foldable iPhone will definitely solve one of the biggest problems at Apple. Foldable phones won't last 5-10 years. I can see Apple making all iPhone offerings foldable down the road

I get the criticism and all your previous judgments samples are valid. I also agree that title is click-bait BUT:

I know people are desperate for a Siri that works. The convince of just talking to your phone is priceless. If Apple gets this right, this is a huge deal – which it seems they are on the right track.

People are still talking to Siri for basic stuff like timers and alarms because it works, doesn't need an app, works when phone is locked or even away from you. If this works for more complex tasks like texting and general questions Apple will have the upper hand over Meta and Google in this new way of using computers/internet.

Apple also took a very clever approach for Capex and general AI strategy. Everyone knows that the best intelligence will eventually become a commodity and Apple decided to step aside from this expensive experiment. That's worth pointing out too.

I made yek for myself because I realized unless I give models the entire relevant code I wasn't getting good results

https://github.com/mohsen1/yek

"coming later this year" – still behind the schedule

I have an iPhone 16 that was promised to have it. Now they are saying some features are available only on 17+ models

Works for Linear because the tab stays open, and worse case if tab is closed you can recover later when the tab is opened again and deal with conflict resolution. Won't work if:

1. user clicks a button and closes the tab thinking transaction is done and it's important that transaction is done

2. conflict resolution is difficult or impossible in future client wake up

Maybe just maybe here in HN we are in an echo chamber that is convincing us that there is a theoretical limit to how far the LLMs can make progress. It’s not unthinkable that LLMs will make better overall architectural decisions or follow the good practices better or understand the problem in bigger picture (more access to company/product context already makes a huge difference)

Lots of jobs have been automated away and careers based on those jobs faded away in history. Maybe in near future there won’t be a ton of opportunities for software engineers in the traditional form. I’m also embracing for that future.

There were people called calculators that did manual calculations in the past. There were people hand weaving all the fabric. There were people painting cars in the factory. All those jobs are gone for the most part.

We are sitting here portending there is going to be demand for software engineers managing those engineer robots but let’s be real. The demand for software is not increasing at the rate software engineering is becoming efficient using those robots. Some (many) of us have to find new careers.

I've been doing the same experiment in tsz[1] for a while now (the same past five months in fact) and I have come to very similar conclusions. Lots of harness to enforce good architecture splits. Lots of tests and CI.

My point of working on tsz is to learn how to do very big projects with AI. Eventually the same workflows and attitude can be leveraged to build customer product apps with UI as well. I see that OpenAI is leveraging automated browser testing and even videos as part of their workflow. I think as models get better this direction for making software would eventually make sense. I don't think we're there yet though. But at least, unlike OpenAI vague claims I can share the output with you to see!

Most of the solutions that offer a very high level of automation like Lovable are a bit too optimistic and solutions are not tightly coupled with lots of automated testing.

[1] https://github.com/tsz-org/tsz

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

This space is so crowded but I can see how OpenAI is positioned well to compete. My partner has never coded in her life but using one of those site builders she was able to build a very impressive dashboard for her sales team with accurate data flowing from company's Metabase.

It's exciting that many can build useful things today. I'm a little existentially upset that I'm not so special anymore though.

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 tsz with and will publish those. Hoping that can give folks confidence that tsz is robust

For now, tsz is just a work in progress.

https://tsz.dev

Just a clarification that tsz is not a port of tsgo or tsc. It's an entirely different architecture. Inspired by Chalk and Salsa it does all of the type computations to a solver crate that does not know about the AST. This allows me to do very fast type equity and assignability computations without carrying the weight of AST nodes while walking the type graph etc.

It's already showing results that is nearly 3x faster than tsgo. For multi-file large projects I have some ideas to implement to make it faster there too.

Once tsz is fast and stable I'll shift focus on making sound mode a reality.

There is a market for an S&P 500 ETF without those companies. I'll immediately switch over

> Honest status

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

https://github.com/user-attachments/assets/961eff6c-0060-45d...

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

I’m gonna try this one on tsz. So far Codex /goal has been great

https://tsz.dev

So far Codex /goal has been amazing but Claude Code /goal or even /loop does not work hard enough and gives up. I have observed it just claiming it’s “iterating” in a broken loop or simply giving up.

Now PRs are piling up! https://github.com/mohsen1/tsz/pulls

oh man spent so much time trying to debug what's going on. I have a complex setup with GitHub Actions and self hosted runners so I thought it's something broken in my CI setup

> Deno now defaults to npm:

This is an interesting development. npm after all is the de-facto ecosystem and leaning into it makes sense.

I'm wondering how Deno would've been received if it supported npm and package.json from day 1.

I agree with you. A lot of "AI code is not clean" is hopeful thinking. In two years it might be able to design and architect better than most humans too.

I'm a fan of the website. Sorry to see it's happening. Not sure what the AI models would train on when nobody has incentives to put out useful information on the web? Grim situation :(

tsz is an experiment in giving coding agents full control. On my day job I am a lot more careful. But I've moved on from manually approving every change and instead review the final diff. I noticed manually approving was counterproductive.

Lots and lots of guardrails to not allow slop.

In tsz I have hard gates that disallow doing work in the wrong crate etc.

https://github.com/mohsen1/tsz

Fun fact: This video was made accessible to sighted people because no blind person would ever listen to voice at that speed. Honestly if you ever observe a blind person using computers you'd impressed how they can listen to audio at unimaginable speeds.