Vegenoid

We have determined that the initial conditions of the universe and the laws of physics are at fault for this incident.

Sounds great! Let’s see the code.

To understand if writing is good for a certain domain or purpose, you really do need to at least be decent at writing for that purpose.

If it’s just about aesthetics or how it makes you feel, then yes I agree because how it made you feel is a signal of whether it’s good. Code is not like this, code is about accomplishing a specific function.

You just described the exact same scenario that I’ve heard over and over for the last 2 years. “I didn’t think AI would take over software engineering. But recently, it blew me away with a greenfield implementation of something that already exists and that I know how to make. It has few users and has spent little time in the wild. Now I’m a believer.”

It’s definitely getting better, but this isn’t the kind of thing that is going to change the world. It needs to be good at things that are much more entangled with the world for that.

People say this, and it sounds reasonable. But, as a user of software, I certainly am not feeling a lot of software getting more reliable and higher quality. Mostly I feel the opposite of that.

I like the idea, but we already have the terminal bell. In my setup, when an agent is done or needs something, it emits a bell. Based on config, this results in a desktop notification if I’m not in the terminal, or a toast from my multiplexer if I’m in the terminal. The terminal pane gets a colored “bell” icon in its title that is cleared when I attach to it.

The total lack of mention of the terminal bell in the article is weird. I think it needs to be addressed for the protocol to be taken seriously. More granular info sounds nice, but also nice is the simplicity of the bell.

It still takes decent hardware to run local LLMs that are at all useful. What would be really cool is if we could get useful LLMs on hardware cheap enough to go into “things”.

1. There are no rules of economics. Economists attempt to understand things that happen and use that understanding to predict future events, but frankly there’s not a lot of consensus.

2. Economics is a function of human behavior, not horse behavior. Economics is about coordinating human effort. Humans make economics, horses don’t. When economics change in a way that is bad for horses, the horses have no recourse. When economics change in a way that is bad for humans, the affected humans seek to change things.

One of the key points of the comment you replied to is that you don’t need a very powerful model to do MCP stuff, such as local Qwen. The “let the agent figure it out” approach works much better with powerful models, such as Claude (which you mentioned you are using).

Yes, and now we are full circle: what is (allegedly) bananas is that using VSCode’s remote edit feature has the potentially surprising and unintuitive behavior of installing a VSCode agent on the target machine.

My absolute greatest skill in my career, that has consistently set me apart from my peers, is that I read documentation thoroughly.

It is shocking how much of a differentiator this is. You will discover that the software you’re already using is much more capable than you realized.

…which we attempt to constrain by encouraging the use of tools that make it harder to fuck shit up.

Spotify, the comment I replied to drew a comparison from Shopify to Spotify.

I think I’ll start a company called Shpoptify.

Spotify has progressively gotten much worse over the last 15 years, all while the size of their engineering team has ballooned.

I am very unsurprised by this outcome.

People wonder why good software becomes bad, and it’s because the people who were good at engineering are often outmaneuvered by corporate-politics savvy people in a growing company. One of the best political moves in a company is to have a lot of people under you.

A couple years ago, an engineer I know who has always been a very poor performer and lacks initiative, but is friendly and non-confrontational, was hired by GitHub. It would not have been hard for GitHub to find a much better engineer, but this person would be an easy person to keep under a manager on a team who wouldn’t leave or make waves. That can be more important to some managers than skills.