- Pure speculation, but I feel the inference money is tiny compared to the speed and permanence of Office integrations MCP enables through the consultancy swarm.
MCP lets you glue random assed parts of services to mega-ultra-high critical business initiatives with no go between. Delivered through a personalized chat interface that will tell you how sexy you are and how you deserved to win at golf yesterday… from salesman to auto interface to forever contract in minutes.
MS sells to insecurities of incompetent management and facilitates territory marking at the expense of governments and societies around the world for mega bucks. MCP, obvious as it is technically, also lets them plug a library into existing services for a quick upgrade then an atomized upsell directly to the chat interfaces of upper management.
Microsoft’s CEO has talked about his agent swarm. Much like RPA this woo appeals strongly to the barely technical.
- Templates and templating languages are still a thing. Source generators are a thing. Languages that support macros exist. Metaprogramming is always an option. Systems that write systems…
If these AIs are so smart, why the giant LOCs?
Sure, it’s cheaper today than yesterday to write out boilerplate, but programming is about eliminating boilerplate and using more powerful abstractions. It’s easy to save time doing lots of repetitive nonsense, stopping the nonsense should be the point.
- I find that technology really exciting. Partly because it’s a polished and comprehensive version of something I was implementing around my MCP cluster anyways.
Mostly, though, because it seems like we’re mere minutes away from having Star Trek style LCARS adaptable GUIs managed by an AI computer system simultaneously so smart it runs mission critical operations yet so dumb we have to remind it that we want our tea “hot” five times a day.
It’s happening. We’re gonna be living in the future!
- No nulls, no nullability bombs.
Forcing devs to pre-fix/avoid bugs before the compiler will allow the app means the programs are more correct as a group.
Wrong, incomplete, insufficient, unhelpful, unimpressive, and dumb are all still very possible. But more correct than likely in looser systems.
- Another red flag vis-a-vie energy source is ignoring hydro electric. High energy consumers and areas with a constant surplus of hydro are a good match. One of the new mega dams on Central Asia was restarted and funded primarily by an aluminium conglomerate - cheap and stable pricing at industrial scales.
- Amazon didn’t pay zero taxes, robbing the commons. Amazon engaged in trade and investment, taxed on all sides and at multiple points in the exchange of goods and services. Then Amazon invested their profits into further tax-creating transactions, reducing their tax burden that year.
When Amazon stopped investing and started extracting those profits everyone paid taxes on that giant money pile that wouldn’t exist without the investment. Every Amazon worker, CEO included, paid taxes all along. Amazon’s service providers and partners did. Amazon now does too, and the tax coffers have won big.
Taxation offsets from investments should be broadened (to individuals), not shamed.
- Vibedetector
- Bourdain didn’t initiate the cultural practice of going on safari and congratulating one’s self. The Michelin guide was founded in 1900.
Bourdains travels also weren’t the curated tourist jaunts you’re describing. They often showing the grim and lesser known sides of conflicts and situations while presenting genuine local cuisines. It’s what the unconcerned tourist aspire to, not what they do.
- Imagine if that dev team could create some kind of hyper intelligent interface to git so powerful even a marketer could use it…
Like a couple icons and some basic platform scripts for the 99% use cases of picking a branch, adding content, and occasionally saying “oops”?
Powered by Git doesn’t have to mean using Git raw.
- Customized, self-guided, tailor made kids content isn’t slop per se.
Colouring pages autogenerated for small kids is about as dangerous as the crayons involved.
Not slop, not unhealthy, not bad.
- I have had similar experiences, and wonder how the subjective experience is impacting my estimations of progress and productivity.
Specifically: what if I just started downloading repo’s and aggressively copying and pasting to my needs… I’d get a whole bunch of code kinda quick, it’d mostly work.
It feels less interactive, but shares a high level similarity in output and understanding.
- Religions are about faith, faith is belief in the absence of evidence. Engineering output is tangible and measurable, objectively verifiable and readily quantifiable (both locally and in terms of profits). Full evidence, testable assertions, no faith required.
Here we have claims of objective results, but also admissions we’re not even tracking estimations and are terrible at making them when we do. People are notoriously bad at estimating actual time spent versus output, particularly when dealing with unwanted work. We’re missing the fundamental criteria of assessment, and there are known biases unaccounted for.
Output in LOC has never been the issue, copy and paste handles that just fine. TCO and holistic velocity after a few years is a separate matter. Masterful orchestration of agents could include estimation and tracking tasks with minimal overhead. That’s not what we’re seeing though…
Someone who has even a 20% better method for deck construction is gonna show me some timetables, some billed projects, and a very fancy new car. If accepting Mothra as my lord and saviour is a prerequisite to pierce an otherwise impenetrable veil of ontological obfuscation in order to see the unseeable? That deck might not be as cheap as it sounds, one way or the other.
I’m getting a nice learning and productivity bump from LLMs, there are incredible capabilities available. But premature optimization is still premature, and claims of silver bullets are yet to be demonstrated.
- Well put. In that broken metaphor we’ve seemingly enter into a web ‘inclusiveness’ discussion focused on pronouns over, say, accessibility for visually impaired readers and readers reliant on tool-based assistance…
Degenerative diseases and chronic functional limitations are super, duper, inclusive to start with.
From SGML and crystallizing the dreams of archivists, librarians, and academics for centuries we’ve ended in a place where actual Microsoft has to use other companies’ web engine because “too ‘spensive” and the ability to even copy text from a website isn’t a guarantee. If you can even see the text under the ads, inline ads, the cookie popup, the delayed email list popup, and then the helpful ai chat agent pop-up.
Stricter markup yields simpler tooling yields better accessibility and transformations. Letting the public web degenerate hurts humanity, every race and creed included.
- The amount of tap dancing and philosophizing some developers are willing to do to dodge estimates is hilarious.
It’s a skill… a basic part and critical part of engineering. IME the common thread between objectors is that they haven’t made a consistent effort to improve — developing, iterating, and refining their estimation process over time.
Yeah, every line of code is a unique snowflake piece of undefinable research the universe has never seen, equally unknowable and inscrutably enigmatic. But the workers at EngiCorp building EngiCorp products using EngiCorp project routines and resources first, second, and third quarter of 2025 are literal world experts at EngiCorp outcomes. They very reasonably should be able to estimate EngiCorp work in Q4, and account for EngiCorp realities, providing maps of future costs that can drive EngiCorp process improvement and investment.
If I ask for a decking estimate and get back sophistry and smug incompetence, I’m not talking with a super skilled professional deck builder. Doesn’t matter how they hammer, saw, or draw.
- With poor abstractions I can improve abstractions and ensure holistic impact because of the reuse. Then I’m left with well factored reusable code full of increasingly powerful abstractions. Productivity increases over time. Abstractions improve and refine over time. Domain understanding is deepened.
With duplicated messes you may be looking at years before a logical point to attack across the stack is even available because the team is duplicating and producing duplicated efforts on an ongoing basis. Every issue, every hotfix, every customer request, every semi-complete update, every deviation is putting pressure to produce and with duplication available as the quickest and possibly only method. And there are geological nuances to each copy and paste exercise that often have rippling effects…
The necessary abstractions often aren’t even immaturely conceived of. Domain understanding is buried under layers of incidental complexity. Superstition around troublesome components takes over decision making. And a few years of plugging the same dams with the same fingers drains and scares off proper IT talent. Up front savings transmutate to tech debt, with every incentive to every actor at every point to make the collective situation worse by repeating the same short term reasoning.
Learning to abstract and modularize properly is the underlying issue. Learn to express yourself in maintainable fashion, then Don’t Repeat Yourself.
- Looking at that unwrap as a Result<T> handler, the arguable issue with the code was the lack of informative explanation in the unexpected case. Panicking from the ill-defined state was desired behaviour, but explicit is always better.
The argument to the contrary is that reading the error out-load showed “the config initializer failing to return a valid configuration”. A panic trace saying “config init failed” is a minor improvement.
If we’re gonna guess and point fingers, I think the configuration init should be doing its own panicking and logging when it blows up.
- I’m reminded, by the ascii art d’s, about a metric used in game dev where users can shape content, something to the effect of time to penis (TTP): defined as the time from tool availability to when users abuse said tool to craft dong.
Supposedly it’s pretty quick.
- I see profits and outsourcing.
Selling an on-premise service requires customer support, engineering, and duplication of effort if you’re pushing to the cloud as well. Then you get the temptations and lock in of cloud-only tooling and an army of certified consultant drones whose resumes really really need time on AWS-doc-solution-2035, so the on premise becomes a constant weight on management.
SaaS and the cloud is great for some things some of the time, but often you’re just staring at the marketing playbook of MS or Amazon come to life like a golem.
- OOP without inheritance is exactly what VB6 had… now its cool again, I guess.
In startups I’ve competed against companies with 10x and 100x the resources and manpower on the same systems we were building. The amount of code they theoretically could push wasn’t helping them, they were locked to the code they actually had shipped and were in a downwards hiring spiral because of it.