When the solution becomes the problem, an opportunity for disruption opens up. Lots of chatter around this right now. I'd be curious to see if any of the many alternatives popping up gain traction before Github course corrects.
I think the problem is that Microsoft committed to AI totally. There is no way back for them. And this also means that Github will suffer from this. Microsoft PR will tell people that AI is the solution to everything, but in reality it will lead to problems that keep on coming up again and again. Now, people may say "but Github services being down, does not have anything directly to do with AI" - while that may be true, the problem is that Microsoft shifted its strategy already, so most of its considerations will go about AI top down control. Whether people's workflow using Github is disrupted, is at best only of secondary interest to Microsoft - and that specific problem will keep on resurfacing again and again and again. Perhaps it will be silent for 3 months or so - but I am 100% certain that in the not so distant future, you'll have a new drama story about how Github is declining.
This is like step-wise deterioration. Ghostty won't be the last here.
Whether alternatives arise ... that will be interesting to see. I mean those alternatives need to not suck, but a lot of those websites etc... kind of suck.
The future might look something like instead of paid software or open source software what you get is a set of requirements documents for a code forge, like a recipe. You bake your own.
Then you alter it to your particular use case and set of preferences.
Some of the drawbacks include:
1. The time & effort you spend dicking around making something you could buy is time & effort not spent on your core business 2. Understanding what to build is not trivial. Sure, the tool you built works for your use case, but does it work for other teams? CS? Legal with all their fiddly requirements? Congrats, you're a product manager now. 3. Understanding what to build is not trivial. Jira is not a trivial CRUD app, it's a workflow engine builder. 4. User training and support is not something you can prompt away. The minute your software gets in anyone's critical path, you're on the hook for a lot of handholding. Congrats, you're user support now 5. Congrats on your new role in ops and getting called when stuff goes down
Any software engineer will tell you writing code is the easy part. Believe them lol.
Here's the thing: I don't think so in the age of LLMs.
>I’ve noticed that people who have never worked with steel have trouble seeing this—that the motorcycle is primarily a mental phenomenon. They associate metal with given shapes—pipes, rods, girders, tools, parts—all of them fixed and inviolable, and think of it as primarily physical. But a person who does machining or foundry work or forge work or welding sees “steel” as having no shape at all. Steel can be any shape you want if you are skilled enough, and any shape but the one you want if you are not. Shapes, like this tappet, are what you arrive at, what you give to the steel. Steel has no more shape than this old pile of dirt on the engine here
Like the common person vs. a metalworker thinking about steel I think we've all gotten this rigid view that software we work with is fixed and unchangeable and the LLM boom is going to change that by making ALL of the software we use "any shape we want".
I think libraries and open source software are going to have to move to looking more like building blocks with standards and instructions for modifications and people are actually going to DO those modifications to suit themselves instead of just being satisfied with whatever their SaaS providers want to give them.
And the pendulum of "we don't do it because it's not our core competence" is going to swing back to having developer tools teams that actually build and maintain developer tools.
The old advice about the time spend writing your tools is tempered by the fact that LLMs make it very very much easier for a focused smart team to build things.
> we've all gotten this rigid view that software we work with is fixed and unchangeable and the LLM boom is going to change that by making ALL of the software we use "any shape we want"
What? Literally nobody in software engineering has this view lol. We take open source code and libraries and adapt them all the time. And make new ones.
Your steel analogy is bad, because you're missing what's complicated about both manufacturing and coding.
I've taken welding and shop classes, I could make a motorcycle. Turning a part on a lathe isn't that hard. Bending steel just needs the right tools. So should I build instead of buying, if I want the motorcycle itself and not a hobby project? Haha absolutely not.
I'm not buying from Honda because I think vehicles are immutable and unchanging things, I'm buying from Honda because it'll be quicker, cheaper, safer, and far more reliable than anything I could do. If I want a hobby project, sure, but otherwise it's a bad idea. [0]
Same thing with code and for the same reason.
> The old advice about the time spend writing your tools is tempered by the fact that LLMs make it very very much easier for a focused smart team to build things.
Yeah, you misunderstand the problem lol. Building is the easy part. It was never the gate.
You can't prompt your way out of understanding what to build. It's so much harder than you think it is.
You also can't prompt your way out of the hassle of running a biz critical system, dealing with outages, supporting users, etc.
[0] After taking a welding class, you'll instantly understood why it's a trade. Making consistent, quality welds is not easy.
Uh, I'm not guessing what it will be like, I'm doing it. Both reflecting on a better past when organizations did much more of their computing in house and advocating for modern organization use the new tools we have at our disposal to return to building our own tools.