Smit's Blog

Why I Switched From Neovim to Zed

Smit Patil — Sun, 17 May 2026 00:00:00 +0000

Why I Left Neovim</h2>
I'm moving away from Neovim. I've used it for a while now and I loved it, heck, I even made plugins and a theme</a> for Neovim. It's just that Neovim became a hassle, even when I got my own setup and plugins and customized it to my liking, I never once felt like I was getting work done any faster than if I was using a traditional IDE. So why bother continuously tinkering if I was going to get marginal, or no improvements in my work productivity.</p>
I'm not trying to downplay Neovim by any means, I think it's a great tool for developers who find it useful, and especially those who have mastered the terminal workflow, but people need to understand that Neovim isn't for everyone. You don't automatically become a 10x developer once you switch just because people online told you to. Some people might find it useful right away and stick with it, others might need to tinker with it a bunch to get accustomed to it, and some may not like it at all. It took a while for me to realize Neovim isn't for me. I was trapped under the illusion that it was the only way to go in terms of boosting productivity, when in reality, productivity depends more on your habits as a person than the software you use to edit code.</p>

Why Zed?</h2>
While I was initially going to just go back to VS Code, I realized there's other competitors -- notably Zed Editor</a>. Built in Rust from the ground up, Zed felt fast, sleek, lightweight, while covering everything I needed from a modern editor. It sounded great, so I installed it and tested it. Just using Zed felt like a breath of fresh air. It was amazing and had the familiar structure of VS Code but everything was faster and more polished. Everything just worked, LSPs, themes, extensions, terminal, as well as the agent. This is it. This is the editor I'll stick with.</p>
What stood out the most about Zed to me, was the lack of friction. In Neovim, I needed to set up multiple different plugins for me to code comfortably, and it was sometimes janky. In Zed, I could just open up a project, and get working right away. No need to fiddle around with any plugins.</p>
Everything from the startup time, to the autocomplete, to the built-in terminal just works. My workflow became much smoother and I ended up being more productive than if I was still using Neovim.</p>
And for those who also want to switch from Neovim, but are afraid they'll miss the vim bindings, don't worry, Zed supports vim keybindings natively! (they work great!)</p>

Lessons from Neovim</h2>
Even if I'm moving away from Neovim, I still greatly appreciate all the time I've spent coding in Neovim. It's taught me a lot. It made me more intentional about how I navigate and edit code, and it made me more curious and open-minded as a developer. If I didn't see a solution, I made my own, and it made me better at Lua (to a certain extent). I also had plenty of fun making plugins and my own colorscheme. I don't regret using Neovim at all, but at this point in time, Zed feels like the better tool for me. Maybe i'll return to Neovim someday.</p>

Checking out Tangled

Smit Patil — Sun, 17 May 2026 00:00:00 +0000

What is Tangled?</h2>
Tangled</a> is a new git forge, like Github, Gitlab, and Codeberg. The main difference is that Tangled is built on the AT Protocol</a> (like Bluesky) and is partially decentralized</strong>. The main reasoning behind Tangled is that users can fully own and self-govern their code. The developers hope this will turn coding social and fun again.</p>
Tangled is still very new</strong>, and every contribution counts, if you're interested by the end of reading this article, I suggest you look into contributing to Tangled. I've contributed to tangled</a> a little bit myself.</p>

More about Tangled</p>

If you would like to learn more about Tangled, you can check out their own blog post here</a></p> </div> </aside>
Why Tangled Caught My Attention</h2>
I found tangled interesting because unlike Github, no one owns your code. Your code is yours entirely, not locked to the platform. Your code ownership is connected with your identity through the AT Protocol. Even if you don't like where tangled is going, you can just host your own instance, called a knot</a></p>
The idea of a "knot" makes the system feel less like one website and more like a network. This helps when it comes to their idea of "reviving social coding"</p>
The social side also stood out to me, while Github feels like an infrastructure with one company, Tangled seems more interested in community and making code feel more personal and social-driven. An example of this I saw was the vouching</a> system. You can vouch or denounce users that you interact with. This helps with avoiding "ai slop" on the platform and further enhances the sense of "community" that tangled is trying to achieve and builds a web of trust.</p>
It's New, and That's a Good Thing</h2>
Tangled is really new, that's not necessarily a bad thing though. While a lot of its infrastructure is still being put in place, they need help from the open-source community. If everyone contributes to Tangled, they can shape the culture and contribute to making Tangled a better software. From my week of being on the platform, I've seemed to love how everything is so far. Mostly everything works perfectly fine. While they lack some support for features on other Git forges, like project management tools, and mature CI/CD integrations, the core experience is there, it works and feels surprisingly usable.</p>
Who (and who isnt) Tangled for?</h2>
I'll make this short. Tangled is</strong> for...</p>

people who contribute to open-source</li>
people who like decentralized software and self-hosting</li>
people who enjoy social coding</li> </ul>
Tangled is not</strong> for...</p>

teams that want a "Github clone"</li>
people who want an isolated forge</li>
people who do not want dependency on the AT Protocol</li>
people who want private repositories (for now)</li> </ul>
Why You Should Care</h2>
As more and more developers are moving away from Github, it becomes important to explore other options. Tangled is worth paying attention to. The current software development ecosystem is centralized around a few major platforms. It's convenient, but it also means our code, identities, projects, and histories depend on these companies we don't control. This can especially be seen recently with the controversies surrounding Github. Tangled offers a different direction: what if you code was tied to your identity instead of a platform? This unlocks the potential for social coding, secure accounts and identities and peace of mind knowing a major company doesn't own your code. Tangled is a great platform trying to answer that question, and it'll only keep getting better.</p>
Final Thoughts</h2>
Tangled isn't perfect yet and there's still a lot to do, but its a project worth watching. I don't think it's at a stage where everyone should ditch Github and move over but I would say its worth making an account, pushing a few projects, reading the docs, and exploring the platform. Maybe you'll find an issue like I did, and hopefully contribute. And you might find that coding feels a little more personal again.</p>

Codex Is Awesome

Smit Patil — Fri, 08 May 2026 00:00:00 +0000

</p>
Introduction</h2>
I recently got a one-month free trial to ChatGPT Plus, which included access to their flagship coding agent, Codex</a>. I've been using it over the past few weeks, and I wanted to share my experience with the agent.</p>
I started using Codex because I had seen all the hype around people using Claude Code, Codex, and other agents to rapidly develop, test, and review code for their applications. This type of productivity was astounding, and I had to take a look to see what all the hype around coding agents was. Getting a trial for Codex was my opportunity to do so. It's safe to say -- it did not disappoint.</p>
What's Different?</h2>
What's an Agent?</h3>
Codex is a coding AI agent</strong>, not just a chatbot. It can do more than just answer questions. When I'm using it through the Codex CLI, it runs on my device and has access to the files in my project. That means it can inspect my codebase, make edits, run commands, and continuously plan and iterate toward a goal. Essentially -- it can perform tasks on my computer for me. If you want to learn more, you can read this article</a></p>
Agents also have features that normal chatbots usually do not, such as agent skills</strong>, MCP servers</strong>, and hooks</strong>. These make agents more customizable and better at working inside specific workflows, helping them truly integrate as part of the development process. I will talk more about these later.</p>
Why Is It Different?</h3>
Unlike copy-pasting code from ChatGPT into my IDE or coding manually, Codex dramatically sped up the process. When I'm working on a project, I can just use the Codex CLI to plan out the implementation of a feature, and Codex will come up with a plan, edit files to make changes, run tests, and iterate until the feature is implemented. I can ask it to make adjustments or give it design specifications, and it will consider those and make changes accordingly. The big difference is that it helps me move from idea to implementation significantly faster than if I were simply coding manually.</p>
Codex has helped me greatly with implementing new features, debugging errors, refactoring messy code, and writing docs.</p>
My Workflow</h2>

I write a clear specification of the feature I want implemented. I make sure it's not too broad or too narrow so Codex can do its best work.</li>
If Codex has not indexed the repo before, I will run /init</code> to create an AGENTS.md</code> file, so Codex understands the codebase.</li>
In Plan mode, I will give it the spec and Codex will generate a plan. I'll review the plan to make sure it looks good. Plan mode should definitely be run with high reasoning. If the feature is complex, I will ask Codex to utilize subagents.</li>
Codex implements the plan across the codebase.</li>
Test the feature. If anything seems off, re-prompt Codex with the specific issue.</li>
Ask Codex to run tests, clean up the implementation, and simplify the code.</li>
Manually review the diff to ensure the code is correct, readable, and aligned with the project.</li> </ol>Skills, MCP Servers, and Hooks</h3> I use various skills</strong>, from frontend design to documentation workflows and git commit messages. Skills are useful because they let Codex follow reusable instructions for specific tasks instead of me redundantly typing in the same instructions every time. The extra context helps it become a "master" in the task it's doing.</p> Want to find skills?</p> You can find a whole list of skills here: skills.sh</a></p> </div> </aside> MCP servers</strong> are also useful because they let Codex access external tools and data sources. They let it pull data from other sources, not just the codebase, which makes it smarter and lets it interact with other systems, like Figma or GitHub.</p> Hooks</strong> are also a powerful part of the workflow because they let Codex run commands automatically, every single time. An example of a hook would be: after a feature implementation, Codex can run a linter and formatter to automatically lint and format the code. This helps keep the codebase clean and Codex will do it every time.</p> What Codex Does Well</h2> Codex works best when I have a clear idea of what I want but need help turning that idea into working code. It's really good at taking a specification, indexing the codebase, figuring out a plan, and implementing that plan by identifying which files need to change.</p> Codex is also excellent when reviewing code generated by other people and agents (like Claude Code). It can catch subtle details within the code that are easy to miss, such as inconsistent patterns, unnecessary complexity, or code that doesn't fit the styling of the project.</p> Codex is also great with debugging and cleanup. It can read error messages, inspect the related code, find the issue causing the error, and suggest or apply a fix. It's also a big help in refactoring messy code: it helps simplify functions, update documentation, and optimize code.</p> Real Example: Refactoring Conversia</h3> Codex greatly helped me when it came to refactoring my project, conversia</a>, a Discord bot focused on file utilities. I used Codex to come up with a plan to refactor my codebase for improved performance, security, and readability. Codex changed files, iterated through the plan and utilized subagents and successfully turned hours-long work into just a few minutes. The code had left the codebase neatly organized, safer, faster and much easier to maintain. And it did so while only taking up about 8% of my 5-hour usage! This degree of productivity is exactly why Codex has become such a useful part of my workflow.</p> Why I Prefer Codex for My Workflow</h2> I know people are pretty split between Codex and Claude Code, but here are a few reasons why I prefer Codex for my workflow:</p> Higher usage limits, and usage limits aren't shared between chatgpt.com and Codex.</li> Nicer CLI/TUI. The Codex CLI is open-sourced</a>, written in Rust, and it feels much more polished than Claude Code.</li> ChatGPT Plus gives you access to custom GPTs, and image generation.</li> </ol> Overall, Codex is a better fit for my workflow. It's a strong coding agent with great capabilities.</p> What Codex Still Needs Help With</h2> Believe it or not, AI agents are not</strong> perfect. I still often see Codex needing help with these things:</p> Frontend design. While Codex can build functional frontend code, from my experience, Claude is better in this regard.</li> Vague prompts. This is a problem with every agent, but Codex does not know how to handle vague prompts very well.</li> Super complicated prompts. It struggles with prompts that are too complicated or prompts that try to solve too many things at once.</li> </ul> Conclusion</h2> Codex is a great tool, but it simply isn't a replacement for understanding code. It works best when I know what to build, can review Codex's changes, and can guide it. That's what makes Codex so useful to me. It doesn't completely remove the programmer from the process -- it simply makes the implementation loop faster. I spend less time fighting boilerplate, syntax errors, and repetitive code, and I can spend that time thinking about the actual problem I'm trying to solve.</p> The devs who get the most out of Codex are not the "vibe coders"</em>, they're the problem solvers who understand code and use agents to move faster.</p>
My Coding Setup Smit Patil — Mon, 23 Feb 2026 00:00:00 +0000 Hardware</h2> I primarily do most of my coding on my Macbook Air M2. It's a fantastic laptop for coding (as well as schoolwork), and I can do everything I need to with ease. Sometimes I use my old Microsoft Surface Laptop Go with Arch Linux and Hyprland, but it's not common for me to use it. As per my headphones, I use the AirPods Pro 2. It has great audio quality, bass, and noise cancellation — A must have for coding especially in distracting environments.</p> Software</h2> IDE</h3> I use Neovim</a> btw, and it's a great IDE. I started by using LazyVim</a> and configured it from there, adding my own plugins, themes and changing settings to make it more comfortable to use. You can find my entire Neovim config in my .dotfiles</a></del></p> I use Zed editor. It is fast, good looking and feature-full. If you want to know why I switched from Neovim, read this article</a>.</p> For fonts, I prefer the JetBrainsMono Nerd Font. In my experience, it's an amazing font that's highly readable and aesthetically pleasing. I use the Nerd Font simply because I use Neovim and require Nerd Fonts for my setup.</p> I usually use either the VSCode Dark Modern theme or my own Shale theme.</p> Terminal</h3> I use the Ghostty</a> terminal with starship</a> prompts. I usually use the fish shell</a></p> Browser</h3> I use Zen</a> browser. There's no real reason why, I just wanted a Firefox based browser and Zen looked pretty nice.</del></p> I use Helium Browser</a>. It's based on chromium, it's fast and its bloat-free.</p> Design</h3> Whenever I need to work on designing UI, I use Figma</a>.</p> Languages</h2> For most of my work, I use Rust as my preferred programming language (CLIs, utilities, backend etc.). When I'm working on websites, I tend to use SvelteKit. I've tried React and hated it, and so Svelte seems to be the perfect web framework for me. In fact, this website is made with a Svelte front-end and a Rust powered backend!</p> I also use Java when Minecraft modding.</p> The Making of LQF Smit Patil — Sat, 26 Jul 2025 00:00:00 +0000 How it Started</h3> We all know JSON, YAML, and TOML. They're popular configuration languages. They're great, don't get me wrong, but I wanted something different, something a bit more simple, readable, uniform, and most importantly, something aesthetically pleasing</em>. I also had a lot of time to spend, as it was the end of the school year and all of my exams were over, so this was the perfect time to make my own configuration language, LQF, the Lightweight Quick Format,</p> The Design</h3> I wanted LQF to be extremely simple and revolve around a singular symbol. The symbol of choice is one of my favorite symbols, the ></code> (greater than operator). It represents an arrow to the right, and it's very readable.</p> The Basics</h3> A configuration language needs to have sections</strong> and assignments</strong></p> Sections</h4> Sections</strong> begin with a ></code> followed immediately by a section name.</p> Example:</p> > settings</span></span></code></pre> Assignments</h4> Assignments</strong> are key-value pairs within a section. You can assign using >></code></p> Example:</p> username >> "smit4k"</span></span> active >> true</span></span></code></pre> Comments</h4> Another feature that configuration languages have are comments</strong>. Comments</strong> in LQF start with #</code> and continue to the end of the line.</p> Example:</p> # This is a comment</span></span></code></pre> Supported Values</h4> LQF supports a lot of values, when assigning a key to a value. Read the table below for more info:</p> Type</th> Syntax Example</th> Description</th></tr></thead> String</td> "Hello, world!"</code></td> Double-quoted text</td></tr> Number</td> 42</code>, 3.14</code></td> Integers, Floating points</td></tr> Boolean</td> true</code>, false</code></td> Logical values</td></tr> Null</td> null</code></td> Null value</td></tr> Array</td> [1, 2, 3]</code>, ["a", "b"]</code></td> Comma-separated list of values inside square brackets</td></tr> </tbody></table> That's It</h3> That's the entire language, as of now. It's essentially completed. It's simple</strong>, readable</strong>, and looks awesome</strong> (in my opinion). I'm really happy with how it turned out.</p> If you would like to contribute</strong> to the language, you can check out the specifications in my Github repo, smit4k/lqf-spec</a>, all of the info about the language is there.</p> Here's a full example file for you to enjoy</p> # Example LQF file</span></span> # Designed by smit4k (smit@smit.codes)</span></span> </span> > server</span></span> host >> "localhost"</span></span> port >> 8080</span></span> use_ssl >> true</span></span> </span> > database</span></span> engine >> "postgres"</span></span> host >> "db.internal"</span></span> port >> 5432</span></span> username >> "admin"</span></span> password >> "s3cr3t"</span></span> max_connections >> 20</span></span> </span> > features</span></span> enabled >> ["search", "analytics", "dark_mode"]</span></span> beta >> false</span></span> </span> > logging</span></span> level >> "info"</span></span> file >> "logs/app.log"</span></span> </span> > cache</span></span> backend >> "redis"</span></span> ttl_seconds >> 3600</span></span> enabled >> true</span></span> </span> > meta</span></span> version >> "1.0.0"</span></span> maintainers >> ["bob@example.com", "gus@example.com"]</span></span></code></pre>

Type</th>	Syntax Example</th>	Description</th></tr></thead>
String</td>	`"Hello, world!"</code></td>`	Double-quoted text</td></tr>
Number</td>	`42</code>, 3.14</code></td>`	Integers, Floating points</td></tr>
Boolean</td>	`true</code>, false</code></td>`	Logical values</td></tr>
Null</td>	`null</code></td>`	Null value</td></tr>
Array</td>	`[1, 2, 3]</code>, ["a", "b"]</code></td>`	Comma-separated list of values inside square brackets</td></tr> </tbody></table> That's It</h3> That's the entire language, as of now. It's essentially completed. It's simple</strong>, readable</strong>, and looks awesome</strong> (in my opinion). I'm really happy with how it turned out.</p> If you would like to contribute</strong> to the language, you can check out the specifications in my Github repo, smit4k/lqf-spec</a>, all of the info about the language is there.</p> Here's a full example file for you to enjoy</p> # Example LQF file</span></span> # Designed by smit4k (smit@smit.codes)</span></span> </span> > server</span></span> host >> "localhost"</span></span> port >> 8080</span></span> use_ssl >> true</span></span> </span> > database</span></span> engine >> "postgres"</span></span> host >> "db.internal"</span></span> port >> 5432</span></span> username >> "admin"</span></span> password >> "s3cr3t"</span></span> max_connections >> 20</span></span> </span> > features</span></span> enabled >> ["search", "analytics", "dark_mode"]</span></span> beta >> false</span></span> </span> > logging</span></span> level >> "info"</span></span> file >> "logs/app.log"</span></span> </span> > cache</span></span> backend >> "redis"</span></span> ttl_seconds >> 3600</span></span> enabled >> true</span></span> </span> > meta</span></span> version >> "1.0.0"</span></span> maintainers >> ["bob@example.com", "gus@example.com"]</span></span></code></pre>