I have switched to Cursor for UIKit development.
It turns out that the LLM-generated UIKit code needs handholding. Cursor as an editor plus agent becomes the only form that helps me tightly control the generation process to avoid code bloat. For every feature I build, I can quickly fix the issue in the editor using the autocomplete. It works far better than Codex+Xcode.
The funny thing is that I thought Cursor was already dead. Not at all. In fact, I now prefer Cursor more. It is really powerful to have an editor with autocomplete ready at any time for me to take control, and in the same environment to have an agent to kickstart prototypes.
My point is this: creating a new window using a split layout sacrifices the wrong thing. I always find that a half-split weakens the content in the old window in some way: creating a bottom window makes the existing one jump, sometimes pushing content out of the viewport. Creating a right window causes the text in the left window to wrap awkwardly.
When the user creates a new window, the existing window’s size shouldn’t change at all. Don’t make the user wonder whether the view of the existing window will be compressed. It simply shouldn’t.
IMO, this is where Niri makes a much better design choice: none of the existing windows are squeezed/resized, so my content stays exactly the same.
My point is this: creating a new window using a split layout sacrifices the wrong thing. I always find that a half-split weakens the content in the old window in some way: creating a bottom window makes the existing one jump, sometimes pushing content out of the viewport. Creating a right window causes the text in the left window to wrap awkwardly.
When the user creates a new window, the existing window’s size shouldn’t change at all. Don’t make the user wonder whether the view of the existing window will be compressed. It simply shouldn’t.
IMO, this is where Niri makes a much better design choice: none of the existing windows are squeezed/resized, so my content stays exactly the same.
It would be interesting to build an operating system providing simple yet rich building blocks for LLM so the user can build whatever they want in it using natural languages. That will truly be a "personal" computer.
@gregisenberg Yikes. I think there are very few car brands trying to put ultra-ultra wide screen in front of the front seats though. How did you even find one and bought it in the first place?
I have been sitting at my desk reviewing merge requests for 5 straight hours. It simply takes a lot of time to review 30K lines of rust generated by LLM.
4 years ago, every 100 lines of C++ code took me roughly 10min to review. A diff under 500 lines took me roughly half an hour to go through. You can tell the bar has increased significantly.
Things change. These days, I often received MRs with 5k lines of code that touched everything. I always shouted, make it clean! Remove irrelevant changes! The next revision came in, boo, irrelevant comments changed again.
I don’t know how long this messy period will last. It has to do with a combination of prompting LLM too much, caring too little about the sanity of the work.
I still like reviewing code though. It exercises my brain to truly think differently of each feature.
@cosmiclibe57707 Skill issue is one thing. I think another important aspect is the lack of strategic planning in building out large features. Yes, the feature building process (short or long) is the process to maintain backward compatibility.
I think a subtle issue here is: previously when I gave comments, I learned a thing or two, and the author would learn a thing or two, which leads to some improvement of the whole organization over time. Now I am still learning, but I am not sure the author learns, and it seems hard for the information in the comments to get encoded in the next diffs generated by LLM.
Based on my current heavy use of Claude Code and Codex, I don't think they along can really replace good engineers to do clean work at scale as of today.
But! I really like the way they assist low cost brainstorm experiments:
- Show me what the common architecture looks like if I want to track network lost duration for both layer 3 and layer 4.
- Show me what the transaction history looks like if I implement an auto-save in the iCloud-backed core data with this typing behavior.
- Show me what the ClickHouse schema looks like if I switch from event based data to state based data.
It truly helps expose tradeoffs among solutions, with lightening fast iteration.
Then I let it finish 80% of work at probably 1% of the original time, and I fine tune the rest.
@joshmanders I have switched to Omarchy, but then I switched to CachyOS+Niri because I noticed the design of factorial spiral window opening is flawed and funny.