The Real Lesson from a Flying Tesla: Derivative Doesn’t Mean Unoriginal

Tesla shows off a Roadster that can lift itself into the air, and somewhere an aspiring entrepreneur thinks “I need to invent something even more spectacular to be successful”. I admire the ambition and showmanship. I worry about the lesson people take from it.

The ingredients have histories of their own. The Chaparral 2J used fans to generate suction and grip decades before this Roadster demo. SpaceX developed reusable rockets, tackling the engineering challenges of bringing boosters back to land. These are different applications, but they put the spectacle in context: suction, thrust, and controlled landings each have substantial work behind them.

The same pattern extends to autonomous driving. In 2004, DARPA’s Grand Challenge pushed teams to build vehicles that could navigate a desert course themselves. None finished. Government-backed experimentation helped advance technology that would later find commercial applications. Turning those advances into reliable products required substantial additional engineering and development.

Watch a Tesla demo and you see one company’s vision. Look behind it and you find a much longer history of inventions, experiments, and accumulated knowledge.

Spectacular demos compress that history into a single moment. It looks like someone invented the future from scratch. The aspiring founder walks away thinking that’s the assignment.

What gets lost is the distinction between inventing a technology and combining existing technologies into something extraordinary. Both create value. But they require different amounts of time, money, and patience.

Building on existing work doesn’t diminish what a founder accomplishes. The opportunity is knowing which pieces are ready, which solve problems people care about, and how bringing them together can create something more useful.

When your money, time, and attention are limited, every additional breakthrough your business depends on is another uncertainty you have to fund and resolve. You can spread yourself across so many invention problems that you never get to solve the customer’s problem.

I talk a lot about focus. This is one of its most consequential applications. My advice: choose where you actually need to invent, and limit it to one thing at most.

Which part of your product requires something new? Which parts can use something that already works? Where will the difference matter enough for someone to pay?

Bread and knives existed long before Otto Rohwedder’s machine made commercially sliced loaves possible in 1928. That machine took real invention and persistence. He focused that effort on a specific problem without having to reinvent everything around it.

You don’t have to invent bread and the knife to create the next sliced bread.

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