These 2 Apps made My LLM-Based Dev Environment awesome

Over a year has passed since my last post about using Large Language Models (LLMs) for development. I’ve gone from forcing myself to like the new tools emerging from the GPT Revolution to, now, loving my set up. The two tools I always have up while building are Perplexity and Cursor.

Perplexity.ai

Perplexity AI leverages Retrieval-Augmented Generation (RAG) to provide up-to-date and accurate information. This is especially useful when development relies upon recently released documentation or versions. My “rubber duck” is AI, and it surpasses my human counter parts, and my own ability to google for best practices and implementation guidance. It helps me crash course on new topics, or help me understand errors or issues that may span across multiple platforms in my stack.

Cursor.com

Cursor.com’s IDE offers multi-file editing capabilities. I have yet to find any product come close to it, and waited longingly for it to arrive. It significantly streamlines coding workflows, especially for tasks like refactoring where breaking up files and re-inserting blocks of code can be arduous without it. The Composer feature allows developers to make changes across multiple files simultaneously, presenting diffs in a familiar format in each file with explanations in the chat window. This SIGNIFICANTLY beats out Microsoft Co-Pilot which still feels like a hyped up autocomplete, and I find it more expansive in its capabilities than competitors like Codeium. I see Cursor as “State of the Art”, and Best-in-Class, hands down.

One of Cursor’s strengths is its use of Visual Studio Code (VSCode) as the underlying interface. Although wrapped as the “Cursor App”, it retains all the functionality of VSCode; and doesn’t leave me wanting. Initially, I was wary of adopting a new IDE instead of installing an integration into my existing VSCode app, but this skepticism wore off quickly as I experienced the seamless blend of familiar VSCode features with Cursor’s innovative AI-powered capabilities.

Key features of Composer include:

  • Editing multiple files at once by referencing them with the # symbol
  • Viewing suggested code changes across files before applying them
  • Side-by-side comparison of proposed changes
  • Creating new files as part of larger code modifications
  • Leveraging AI that understands the entire codebase context for relevant edits

Cursor maintains an indexed representation of the full codebase, enabling contextually appropriate suggestions even for complex refactoring tasks. This allows developers to describe high-level changes and have Cursor generate code that fits seamlessly into the existing project structure and coding patterns.

In practice, Cursor shows all necessary changes as diffs in multiple locations with one action, allowing review and acceptance. It even understands developer preferences demonstrated throughout the existing code base (even if not in the immediate file being worked on), such as using twMerge for className merging, without explicit instructions (as shown in the screenshot above).

Another exceptional feature is Cursor’s ability to recognize intent throughout a file when a single change is made. It proactively suggests updates to the rest of the code in a non-distracting way, and only when multiple tab taps are made. For instance, changing a typedef in one location prompts reviews and suggestions for implementing the change elsewhere with impressive accuracy.

The trust I’ve developed in Cursor’s updates and suggestions has been a game-changer. I often find myself hinting to Cursor’s prompts as a primary development method instead of coding myself. It isn’t 100% there yet, but multiple factors beyond my interest in doing so with competitor products. When I’m unable to use Cursor, I genuinely miss it.

This shift in my setup with AI-assisted development tools represents a significant change to what I was using months ago. I am not trying to leverage the tools, or impressed in the concept, but truly experiencing an evolution in my development experience that yeilds continued moment-by-moment results. We have finally broken through the hype!


GitLab and My Transition from GitHub

I was a heavy Github user. That is to say, I used them exclusively for my code projects. For a long time, there was no question in my mind of who to give my projects to. Even when Gitlab entered the market, my first thought was, these guys are just copying GH, why would I convert? Not to mention, hearing the rumors  that the CEO is was a jerk didn’t entice me to rush to adopt.

A few crucial moments, and Gitlab releases, changed that way of thinking within a year. 

The Conversion

Initially, it was sheer curiosity that got me clicking around on their product.  That and the very low barrier to entertain that curiosity.

I had reached my “private repo” limit on Github, and of my private repos few were businesses and mostly projects that I experimented ideas with and/or coded up prototypes. So, I had reached that limit right when I had another idea I wanted to flesh out, and upgrading for a cost didn’t seem worth it. Out of curiosity, I went to GitLab and logged in.

As the name implies, GitLab did not shy away from their copy-cat beginnings as a GH clone. Because of that, I was able to login using GH credentials and import all my private repos for free. The conversions was instant and easy, and my access to an unlimited store of private repos sure did help. The copy-cat look and feel played to my advantage since there was no ramp-up required. What was different about the site were things I hated about GH. Like the wording on PRs (“MRs” in GitLab), or how I could create new files from within the UI.

All in all, an unexpectedly pleasurable experience.

Top of the Hill

My first experience was my gateway drug. Each new idea/project I started, I started in GitLab. It wasn’t too long after that I used them almost exclusively. Gradually, feature after feature, GitLab took that initial win with me and solidified it with feature I really loved having all in once place, like CI and CD.

Successful startups typically take one of two approaches: innovating on one thing and the rest is copy and paste, or, finding innovation as a combination of many non-innovations and putting them together in a beautiful way. For example, the first utensil was not a spork, and sliced bread did nothing more than combine bread and a knife in a novel, simple, and less expensive way.

GitLab is like sliced bread in that, they took a few things I already used (docker, git, CI/CD), and combined them seemlesless, and cost effectively,  as their innovation.

I can very easily go from a concept-project, into a full blown production sized deployment suite in a matter of minutes. In its most basic form, GitLab is very easy to use and can be entirely free.

What keeps me happy is that they keep pumping useful improvements out; and I emphasize useful. It is not getting cluttered with features that get in the way, or as a way to prove they are hard at work. Rather, they seem to have a pulse on the dev community.

Where are they Still Losing?

One thing that has yet to change is the stronghold GitHub has on the community driven aspects of development. Their attention to open-source, from links to NPM package repos, to issues for projects, all keep me returning to GH on my google searches.

 

Will GitLab take that on next? We will have to wait and see!

 

 

Zero to One


I really loved this book. Peter Theil’s blunt and sometimes abrasively honest concepts are very “Purple Cow” and right up my alley. E.g. make big claims from observations and work out why they are wrong or right. Although there are some things I didn’t agree with they are done so in a way that pushes me to reevaluate my reasoning. For the many things I did agree with, it is always nice to have someone better articulate concepts and back you up with some solid experience.  10X yo self.

You can see my running read book list on Facebook here https://www.facebook.com/sshadmand/books