Geoffrey Huntley

> No productivity studies of individual developers tackling tasks show a 10x speedup; results tend to be anywhere from +20% to minus 20%.

The only study showing a -20% came back and said, "we now think it's +9% - +38%, but we can't prove rigorously because developers don't want to work without AI anymore": https://news.ycombinator.com/item?id=47142078

Even at the time of the original study, most other rigorous studies showed -5% (for legacy projects, obsolete languages) to 30% (more typical greenfield AND brownfield projects) way back in 2024. Today I hear numbers up to 60% from reports like DX.

But this is exactly missing the point. Most of them are still doing things the old way, including the very process of writing code. Which brings me to this point:

> There have been absolutely zero indicators that this is true.

I could tell you my personal experience, or link various comments on HN, or point you to blogs like https://ghuntley.com/real/ (which also talks about the origanizational impedance mismatch for AI), but actual code would be a better data point.

So there are some open-source projects worth looking at, but they are typically dismissed because they look so weird to us. Here's two mostly vibe-coded (as in, minimal code review, apparently) projects that people shredded for having weird code, but is already used by 10s of 1000s of people, up to 11 - 18K stars now. Look at the commit volume and patterns for O(300K) LoC in a couple of months, mostly from one guy…

> VSCodium is not "designed" to be less functional, since it is a project maintained by developers who are unaffiliated with Microsoft.

In today's (OSS) world, employment or affiliation doesn't matter much. Microsoft can propose what they want and get what they want from the project, at the end of the day. I don't think these independent maintainers have power to say "No" (if a VSCodium developer can chime in here, I'd love to be stand corrected), or they risk VSCodium to be forked to VSCodiumX, by developers who are friendlier to the megacorp which loves Linux.

Yes, VSCodium is a node to Chromium. "-ium" has a ring akin to "-ish" in today's conjecture. Freemium - Free-ish but not. Chromium - Chrome-ish but not. VSCodium - VSCode-ish, but not. This might be curse in the naming, but it feels, looks and works like that, in practice.

The blog post I linked (for further reference, it's [0]) quotes a tweet which supports what I'm saying, heck even the blog post does a much better job of detailing what I was trying to say here in my previous comments.

To circle back, the problem with -ium projects are, they are effectively banned from participating in the main ecosystem which drives these projects forward, and to be in "The Ecosystem", you need to use the closed source versions with pervasive data collection and whatnot. Heck, even Google abuses Chromium with "Experiments and Proposals", which they use to politely yet forcefully push the web to the places they want. VSCodium…

I'm kind of obsessed with this space and have spent way too long setting up VS Code and RStudio IDEs on my homelab.

One area I struggle with when thinking about building container-based development environments is the best way to avoid mixing in your IDE specific dependencies with your project dependencies. I think some of the commercial tools do this, but I haven't gotten in set up well in my homelab.

I just came across two articles by a former GitPod employer who moved to Coder (these are the two main providers of open-source VS Code in the browser solutions). They're both really interesting.

The first is on how effectively Microsoft has used VS Code to fracture the market place to their advantage by strategically open-sourcing parts of VS Code while keeping many of its best features proprietary (Pylance, the python language server is a good example of this). https://ghuntley.com/fracture/

The second article is about why he thinks Coder's strategy is more promising than GitPod's prompting him to go work for them. It's not as detailed, but it touches on some of the parts of container-based development environments that I've found overly limiting. https://ghuntley.com/integrate/

My workflow for that kind of thing goes something like this (I use Sonnet 3.7 Thinking in Cursor):

1. 1st prompt is me describing what I want to build, what I know I want and any requirements or restrictions I'm aware of. Based on these requirements, ask a series of questions to produce a complete specification document.

2. Workshop the specification back and forward until I feel it's complete enough.

3. Ask the agent to implement the specification we came up with.

4. Tell the agent to implement Cursor Rules based on the specifications to ensure consistent implementation details in future LLM sessions.

I'd say it's pretty good 80% of the time. You definitely still need to understand the problem domain and be able to validate the work that's been produced but assuming you had some architectural guidelines you should be able to follow the code easily.

The Cursor Rules step makes all the difference in my experience. I picked most of this workflow up from here: https://ghuntley.com/stdlib/

Edit: A very helpful rule is to tell Cursor to always checkout a new branch based on the latest HEAD of master/main for all of it's work.

>Also, why is he even doing this?

You can find some of the author's motivations here: https://ghuntley.com/a-new-chapter/

I obviously can't speculate beyond what's in there about the author, but for me, living in a bog standard apartment and working remote to support kids isn't exactly blog-worthy content. I used to live in apartments, and most of the new construction in the US is very cookie-cutter and sometimes depressing.

So, here's what mine would be:

1) a challenging hobby that's useful and more engaging in off-hours than more computer hobbies. Building a livable van certainly seems more interesting than living in an apartment to me.

2) changing scenery at a whim, given the time investment to find a place

3) a van that you can resell or give to your kids

I'd still choose a detachable RV though since it's probably way more comfortable for the price. Sure, I lose out on some options to stay for the night, but that isn't an insurmountable challenge if you can plan and live in a van. Living full time in an RV might also not be blog-worthy though.

The beauty of Emacs though is that it puts the user in full control. There is nothing in the world stopping anyone from modifying anything in Emacs (at least on the Elisp layer), hence packages like this.

VS Code on the other hand is designed to fracture [1]. MS can and has given proprietary API access to their blessed tools, forcing others to go through their much less capable extension API, hence the plethora of vscode forks. Even if you had the most motivated, excited group of people wanting to work on the latest and greatest LLM interactions with VS code, they would most likely be forced to fork. On the other hand, it just takes one motivated Elisp dev to implement whatever they want and make any external package they want integrate with it.

Also, I think the derision from the Emacs community may be a bit overblown. I'm constantly seeing AI/LLM related plugins appearing for Emacs and they tend to get decent traction (e.g. https://github.com/karthink/gptel).

[1] https://ghuntley.com/fracture/