One not mentioned in the article, but being built by someone I know is https://schist.app/
497 karma · joined September 15, 2012
The summary is
The beauty is in the simplicity: 1. One loop - while (true) 2. One step at a time - stopWhen: stepCountIs(1) 3. One decision - "Did LLM make tool calls? → continue : exit" 4. Message history accumulates tool results automatically 5. LLM sees everything from previous iterations This creates emergent behavior where the LLM can: - Try something - See if it worked - Try again if it failed - Keep iterating until success - All without explicit retry logic!
I get what you're saying that AI could write something that executes user input but with the way I'm using the tools that shouldn't happen.
Overall, React / Typescript I heavily let Claude write the code.
The flip side of this is my server code is Ruby on Rails. Claude helps me a lot less here because this is my primary coding background. I also have a certain way I like to write Ruby. In these scenarios I'm usually asking Claude to generate tests for code I've already written and supplying lots of examples in context so the coding style matches. If I ask Claude to write something novel in Ruby I tend to use it as more of a jumping off point. It generates, I read, I refactor to my liking. Claude is still very helpful, but I tend to do more of the code writing for Ruby.
Overall, helpful for Ruby, I still write most of the code.
These are the nuances I've come to find and what works best for my coding patterns. But to your point, if you tell someone "go use Claude" and they have have a preference in how to write Ruby and they see Claude generate a bunch of Ruby they don't like, they'll likely dismiss it as "This isn't useful. It took me longer to rewrite everything than just doing it myself". Which all goes to say, time using the tools whether its Cursor, Claude Code, etc (I use OpenCode) is the biggest key but figuring out how to get over the initial hump is probably the biggest hurdle.
Before the emergence of tools like Zero I wouldn't have ever considered attempting to recreate the experience of a Google Sheet in a web app. I've previously built many live updating UIs using web sockets but managing that incoming data and applying it to the right area in the UI is not trivial. Take that and multiply it by 1000 cells in a Sheet (which is the wrong approach anyway, but it's what I knew how to build) and I can only imagine the mess of code.
Now with Zero, I write a query to select the data and a mutator to change the data and everything syncs to anyone viewing the page. It is a pleasure to work with and I enjoy building the application rather than sweating dealing with applying incoming hyper specific data changes.
My friend and my lender has built up a giant Google Sheet which he uses with his clients and I've been slowly working to translate the logic in that Sheet into an application. It's been a lot of fun as I've been learning how to replicate the multiplayer aspects of Sheets into a React application.
It was the first time I felt like I could write up a large prompt, walk away from my laptop, and come back to a lot of work having been done. I've been super happy with the experience so far.
However, I added my CV to own personal website so that it can viewed by people online who come across my website through my blog posts. The intent being that if they enjoyed reading my content and wanted to learn a bit more about me, they wouldn't have to jump over to LinkedIn.
I've learned to work around the loss of some functionality over the past 6 months since I've switched and it hasn't been too bad. The AI features in Zed have been great and I'm looking forward to the debugger release so I can finally run and debug tests in Zed.
Example: main -> Branch A -> Lots of commits on A -> Branch B -> Lots of commits on B
Now we squash and merge A into main. B now has all of A's commit history, plus some of its own, instead of just it's own. Rebasing main in causes a lot of conflicts.
I also received feedback from people who reached out that they went and read my personal website / blog; that gave them better insight into who I was. Don't underestimate the fact that soft skills and communication go a long way in the interview process and software engineering as a whole. Having a blog, which demonstrates the ability the communicate over a written medium, I feel is a great way help yourself stand out. It isn't a requirement to land a job, but I think it helps.
This is what I've been running into. My approach comes out of writing a bunch of code or re-writing the same sort of code across multiple projects and realizing it would be useful to share. Next I'll dump all the code into a blog post and have to start formulating what the structure of the post will be. What content do I need to add to support my claims that this code is correct (or correct enough to use)? Add in time to research alternative approaches to the code, research and write about the alternatives.
I've found that I'm proud of my finished articles but it takes awhile to get them written. I'm in the midst of one that I've kind of hit a writers block on because I have a fair bit of research left to do. I haven't been motivated to do the research and write up the findings. However, I feel like thats normal and I'll get back to it at some point.
In particular it is mentioned
"For Ractors to be viable to run a full-on application in, Ruby would need to provide at least a few basic data structures that would be shareable across ractors, so that we can implement useful constructs like connection pools.
Perhaps some Ractor::Queue, maybe even some Ractor::ConcurrentMap, and more importantly, C extensions would need to be able to make their types movable."
Which we see in Mike's library he has started work on a Queue and a Map.
I haven't fully wrapped my head around all the nuances to using Ractors nor have I tried to do anything with them yet. But its encouraging to see the discussion around them ramping up
You could use Next.js + any API to create an application.
You could use Next.js + a sync engine to create an application.
You could use React Router + Vite + any API to create an application.
You could use React Router + Vite + a sync engine to create an application.