In my experience everything that affects engineers affects an agent. Good abstractions, reasonably sized methods, good names, principled (intra & inter) service architecture, unit tests, etc.
All of these things have historically been the job of engineers, because it helps other people contribute to the code.
Now it helps other people and other agents contribute to the code.
Related - "The Electric Slide" [0] from NotBoring (a techno-optimist news letter) talks about production of batteries and other parts of the "Electric Stack", and explains where the US/China are relative to each other and the rest of the world, and why China has such a big lead.
Basically MCP is little more than a brand name for "APIs LLM's can use". This means more services are creating APIs, because xyz company who's never been super tech forward doesn't want their tools to be obsolete when everyone uses agents.
Overall, I am in favor of this goal. I'm not sure this is the protocol I'd choose to accomplish it, but it's the one people hear about, and the one they're using.
> If you’re going to use an LLM to write me an email, I’d much rather you just send me the prompt; at least then I’d have an idea of what you actually meant to say.”
I'm excited for when Github starts letting me check in the chain-of-thought that produced a line of code, and git blame it like I can with commits.
In a post Claude Code world that's the job of engineers - the engineering is designing good abstractions, scalable systems, and things that are easy to contribute to. This is what the highest leverage senior engineers have always done, the audience has just changed
Engineering has moved up another layer of abstraction (just like we moved past managing buffers & writing machine code)
I think a more realistic model is not fully open source, but apps with extremely open/flexible APIs and data models that allow arbitrary front-ends (likely with a default one provided by whoever provides the API). Kind of like Stripe's model, but the audience of "developers" is bigger since anyone can be a "developer" with Claude Code
Or maybe it will be the more established open source model where the code is free but the maintainers offer hosting/some default product
I'm really interested in how LLMs will enable more customizable, personal software. Our PMs & Designers are writing a lot of code now, and our engineers are spending time figuring out how to make a system that's easy for PMs & designers to extend/add to.
It's not a big leap to apply that model to a company and its customers, where the company builds a well-abstracted, easily extensible base that 1) Customers can easily extend/customize for their workflows 2) Customers can self-host or run fully isolated, much easier (probably not quite there yet, but is a possible world)
Good engineering has always been about minimizing the amount of effort it takes for someone to understand and modify your code. This is the motivation for good abstractions & interfaces, consistent design principles, single-responsibility methods without side-effects, and all of the things we consider "clean code".
These are more important than ever, because we don't have the crutch of "Teammate x wrote this and they are intimately familiar with it" which previously let us paper over bad abstractions and messy code.
This is felt more viscerally today because some people (especially at smaller/newer companies) have never had to work this way, and because AI gives us more opportunity to ignore it
Like it or not, the most important part of our jobs is now reviewing code, not writing it. And "shelfed" ideas will now look like unmerged PRs instead of unwritten code
I've found it really valuable to pair with people, sit at a computer together while they're driving and using AI. It's really interesting to see how other people prompt & use AI to explore the problem.
Interesting thought (I think recently more than ever it's a good idea to question assumptions) - but IMO abstractions are important as ever.
Maybe the smallest/most convenient packages (looking at you is-even) are obsolete, but meaningful packages still abstract a lot of complexity that IMO aren't easier to one-shot with an LLM
I hear this often, but I think this discounts the fact that this was mostly true for the US/Western Europe at a time where they enjoyed unilateral super-powerism as a result of winning WWII. I'm not sure that kind of prosperity is normal (though I hope it could be).
I'm worried the harsh reality for most humans is that life is often not that easy. And if it is, it won't be for long
Has it been many people's experience that big companies intentionally remove experienced engineers from your team to something unrelated, in the name of fungibility? I've surely seen efforts within a team to make sure that there's not a single person who's necessary for the team to reach full productivity, and I think most would agree this model does not make for resilient teams. But many of the best engineers I know have had much more energy invested in getting them to stay than to leave
At the end of the day writing good code is rarely the "end" someone is shooting for. It's more research, more features, more experimentation, etc. Maybe hobby projects and library maintainers are the exceptions.
In my experience, big companies have the biggest incentive to write good code. They have the highest conviction in their bets, and they know with high confidence they will be around in 10 years. One large tech company I worked at had a rule of thumb that all code would need to be maintained for ~7 years - at which point, as the author points out, the entire team may have been replaced. This is precisely when the time it takes to write good code is a worthy investment
I think we take git for granted as software engineers Software engineering has decades of experience with proposing changes, merging them, staging them, deploying them, and rolling them back, and collaborating with other code-writers (engineers and agents).
I'm very interested in what this will look like for outputs from other job functions. And if we'll end up with a similar framework that makes non-deterministic, often-wrong LLMs easier to work with.
IMO the only concentration OpenAI has is brand. Anthropic & Gemini both have roughly equivalent models. This could change quickly since success compounds, but for now I am actually somewhat surprised at how competitive LLM labs are with each other.
The argument sounds like he believes AI (+ robotics) will take jobs, and breaking up OpenAI could slow it down
Historically the most productive countries are the most prosperous - I think there is a big landscape of local maxima/minima in how healthy & happy a country/economy is, but shunning new technology has never been the path to Quality of Life. The only future where the US maintains its relative success involves American leadership in AI and robotics, with humans supporting them
Interestingly I've often seen this in Claude outputs, especially on long prompts. I've assumed this is because of Claude's XML-based instruction format, but this does make me wonder how related the two are. And if Claude may have a harder time using <output> given it's related to both accessibility and its instructions
I've never understood the risk trade-off for early stage employees (Employees ~4 through ~10-20).
At this stage equity packages are often <0.5% over 4 years. Founders on the other hand may have more like 30% equity at this stage.
But the odds of success are still quite low - <3% is generous.
In venture funded companies I think it's wrong to say that at <10 employees, founders are 60x more responsible for company outcomes (or taking on 60x more risk), even accounting for what they did to start the company.
That being said - I get working hard if you're appropriately rewarded for it. Just less so if it's primarily on behalf of someone else.
ML + Eng
Don't hesitate to email me (seriously don't hesitate)
Comments are my own