The current infrastructure cannot handle the new load requirements. Either the infrastructure must change, or they must start denying users the ability to use the infrastructure.
I may have come out with a different interpretation than you did of GP's comment. I see how you got to yours. But the way I read them saying they should slow down was, maybe slow down on new features. Which would mean they could shift resources from new features to infra.
"A transcript should contain the instructions, messages, tool calls and tool results. Another sufficiently capable model might not continue identically, but it could understand what happened and take over."
This is so obviously AI generated it is painful. Once or twice in an article is rhetorical flourish, but the entire text is inundated with it.
I would never write such a low information, generic, sentence to begin with.
AI writing is rife with high-level, generic language. AI prose rarely addresses concrete concerns, instead preferring hedged generalizations. The "It may A, B, and C, but it will not X, Y, and Z." Where both lists are broad categories instead of specific mechanisms is a calling-card of AI prose.
A human identifies and addresses specific concerns. They need not hedge with "may", because they are stating known facts to support their premise, and an argument from those facts follows naturally.
"The OpenAI API requires tokenization in proprietary format, unavailable and unusable by other providers. Deepseek and Anthropic are following suit."
I do not think the whole article is AI generated. I do not think this was a simple prompt of "Write an article about proprietary chat session formats". However, much of the rhetoric is either LLM drafted or had an LLM pass over it.
"We're not trying to build a perfect solution here" is not something said to assuage over-engineering or encourage sloppy work.
It's said to head off a specific complaint from a specific kind engineer who will object that the proposed solution won't work because it doesn't cover some obscure edge case which rarely comes up in production.
"We're not trying to build a perfect solution here" is saying "We acknowledge not everything will be covered, we're setting the requirements at the 90th percentile use case".
This was my initial reaction to reading this post as well.
Additionally, as I get older, I find the sentiment of "we're not trying to build a perfect system here" is less about "let's just go fast vroooom" and more akin to saying "I've been humbled before by thinking I had the perfect mental model of the universe before a single user touched the product."
My grandpa used to say "we're not building a piano" when doing things like building a quick shelf or something in the basement and be done after a quick measure and a few cuts. My other grandpa would spend an entire day measuring, sanding, pulling out a router etc. Both valid, but if you just need something to put some paint cans on, it doesn't require a day of work.
hahah I picked that up from a youtube woodworker when I was a CALENDAR YEAR into building my son's toy chest. A lot of measurements I had sweated over didn't matter; they are inside of the channels on shaker panels. A bunch of things I didn't sweat are apparent; not ever pencil mark got sanded off before I oiled it and I didn't notice.
The bane of my engineering career is working under engineers like this. It's like we forget we are doing a very analog thing (collaboration and building) under the guise of something digital. We should accept that there will be edge cases, there will be crashes. And unless you're actually in a life-saving industry, that is ok. (I say this with the idea in mind of a 10+ year old code bases spanning many new coding patterns that achieves over 99.5% crash-free)
Agreed. The much better question is: Are we locking ourselves out of a feature, or do we just leave a gap for a rare case?
At work we agreed that some use cases are very niche. These have guards in place to log an alerted-upon marker + return HTTP/500. They have not tripped for years by customers. So, it's fine to not support some rare cases and to deliberately leave known gaps in some contexts. As long as you don't close these paths forward if you need them.
On the other hand, we have contexts like our PostgreSQL instances. Those have a very well defined scope and rooting out all known problems has been the right choice. Most issues we have ignored in that scope have bitten us in the butt sooner rather than later. Very hard in some cases, I may add.
I find it that in wild it is quite often used by product people to push crap ASAP because they don’t want to spend time finding out even basic constraints in the system they supposed to know like the back of their hand.
Then engineers are on the hook because they run into those constraints while building and everyone always blames „those lazy software developers” ;)
I've been that engineer and with good reason. That obscure edge case which rarely comes up in production is very disruptive when it does come up. The product person waving it off is also not the one that will get paged at 2am to address the issue when it occurs. Accepting that 90th percentile use case is infuriating because it is tacit consent for an unfinished solution with the rest being made up later with additional toil, now constrained by load bearing things you cannot change. Thanks for rushing the thinking and making my life harder later for no reason.
Don’t forget months or years later when shit hits the fan, developers will be blamed for being lazy and not the product person. No one will remember Joe said something on one or two meetings we build for 90th percentile - code in git repository will point to a developer who wrote and GitHub will point to the one that approved merge request.
In online discussions people always blame „lazy developers „ like there would be no product owners, testers, business analysts, scrum masters etc.
This is one of the reason I like a ticket tracker. I make my commit as descriptive as possible and I tag them with the ticket number. Also I add comments when Product says to cut corners. It's nice to spread responsibility around when things take a bad turn.
> We acknowledge not everything will be covered, we're setting the requirements at the 90th percentile use case
I'm ok with this as long as dropped requirements are documented and nobody wakes you up at night when those edge cases show up in production. Also, when the next feature needs to build on top of those dropped edge cases, you are given enough resources to redo the previous solution.
What is the qualifier of "rarely". One in ten, one in hundred, one in thousand? What is the failure in these cases? I could accept rarely if that is one in trillion to one in quadrillion range say. Truly rare cases. But not if it might be for seen reasonably.
"None of the deployments under consideration for this new initiative use that mechanism, that other deployments might is irrelevant to the internal product we are building"
In my space this is usually something like, "X won't work on POSIX make", being a reason not to add X to the build system. Well, it works on Ninja, and on GNU make, so it just won't work on POSIX make and the handful of deployments still using POSIX make just won't use X.
In my experience when a manager says that it means “let’s just ignore the architecture and use a short cut if we can get the security team to rubber stamp it”.
Correct. That is one of the worst types of engineers too. Constant paralysis by analysis. It's why Agile became a thing because those people just refuse to ship anything until it's utterly perfect and spotless. Fortunately they are a minority though.
They aren't. This is a Windows quirk. Most IDE extensions which interface with git (or any other CLI program) from the CWD are "vulnerable" to the same attack.
This is why the upstream didn't take it seriously, this has been known for literal decades.
I don't see how that was implied? Just because someone is part of the "club" doesn't mean many other "members" can't be skeptical of their role.
In fact, it doesn't even seem difficult to simultaneously acknowledge and commend the valuable role they play, while also expressing concern over the influence they wield and how it might contrast with desires and goals of the wider community.
They are the wider community. Programmers working on behalf of corporate actors write open source code in the commons because their organizations have discovered competing on some parts of the stack isn't as viable as collaborating on parts of the stack.
I won't pretend to speak to specific numbers, but a huge amount of work and maintenance is from these programmers, or funded via the corporate actors which employ these programmers. Those actors are either on this list, or don't have a problem with this list.
What remains are the handful of truly independent contributors, which are a minority in terms of LoC (though they often have an outsized impact), and the peanut gallery.
Open source wasn't always this way, it would be a different discussion 30 years ago when independents were the only guys in town, but it is now.
I'm sorry, your response does not adress the real world concern about the powe that for-profit entities wield over the entire software industry. So I am going to assume you just want to focus on part of the problem.
A pointless distinction for OP's (heavy handed, LLM-generated) point:
>The database you are helping build for a trustworthy government does not stay in trustworthy hands. Administrations change. A registry that merely catalogs who you are today becomes, under a future government, a map of who to find.
This is an objection to driver license databases, to passports; they don't want face scans at airports, much less for banking or insurance. They want off-the-grid, untrackable anonymity. This is incompatible with much of modern life, at least in the mainstream.
That rules out classes of problem which we want to teach, or falls back to using lookup tables which is more arduous and limits the number of problems which can be put on an exam.
Teaching students to use lookup tables at all is a largely pointless exercise. Teaching students to graph or use statistical functions on an advanced calculator transfers very well to other environments.
> That rules out classes of problem which we want to teach
Does it? Could you give a contrived example of a high school problem that would be ruled out by a lack of a graphing calculator?
> Teaching students to graph
They should be able to plot any of the functions they'll be working with by hand, very quickly.
> statistical functions
If they are using statistics, they should be able to provide the relevant combinatorial coefficients as the answer (xCy, etc), without actually doing the computation.
Not to mention that scientific calculators all support basic stats functions.
You've already rejected elsewhere in the comments the style of problem these calculators are used for as either "more complicated than a high schooler is taught" or a "your teachers have wasted your time".
Which is fine, you have an idiosyncratic view of modern mathematical pedagogy (at least as it exists in the US). When you're a high school math teacher you can argue with your state dept. of ed. about it.
These calculators are also used at the undergrad level, fwiw, so the "high school level" (whatever limit you're putting on that, many high schools will accelerate students into undergrad stats and as far as Calc II), is not a factor in their use overall.
You are a craftsman, learn your tools. Could you imagine the equivalent from other professionals? A machinist saying, "Understanding the differences and interop places between the DRO, hand controls, and CNC controls for the lathe can be a big confusing time hog."
It takes a couple of hours, and it's a tool you use every single day. Learning how it works is the price of entry, not a mountain to overcome.
It is a fact that some useful things in the software world are a pain in the ass to learn, and that they could be better on that front.
LSP is one of those things, or at least it has been, for a while.
LSP is also something that's not necessary to writing quality code; it's absolutely a major quality-of-life boost, but before rewriting my configs after switching to Rust, my LSP usage was limited to being a slightly faster autocomplete engine more than anything. I didn't have keybinds set up for going to definitions, implementations, or references of symbols. I still put out what I think was decent code. I'm also better off now that I've adopted a more useful config.
IMO it's an important part of this industry (among others) to let developers have whatever workflow they want, within reason. If someone decides they want to invest the time into setting up LSP with their editor, that's their prerogative. If not, that's fine too. I don't know who among my present or past coworkers use LSP outside of occasionally chatting about editor configs with one or two of them, because they've usually figured out a workflow that lets them produce respectable code, and I've never had to question their tooling before questioning their methodology.
The context is a user adopting an editor that has LSP integration and is relying on the language server. That's why I said "it's a tool you use every single day".
If your tool is TextMate, you should learn how TextMate grammars work. If your tool is vi, you should learn how modal editing works. If your tool is Ed, you don't need to learn anything because "Ed is the standard text editor".[1]
To be fair, vi has got its dose of "modal editing is difficult to learn" criticism for years. Why shouldn't zed receive the same treatment if configuring LSP is a pain point for many newcomers?
Because the bar is low and part of the craftsman's job is to learn their tools. If everyone who wanted to use a computer needed to learn how language servers work, that would be a problem.
A programmer having to learn how language servers work isn't a pain point, it's their job. It takes a couple hours to learn. A couple hours to learn how to do part of your job isn't notable. Complaining about learning how to do one's job makes one unqualified.
The only craftsmen are the ones at the edge of the lingo tree?
To use your own analogy, as a machinist myself : I can master the concept of the lathe and bow drill without learning simulation-driven CAM, and I would be no less a machinist than the guy pressing buttons on a brand new Haas.
If you work via notepad.exe and assembly with a compiler and linker ready in the next window, fine! the work is what matters.
It stops at the tools you use, "it's a tool you use every single day". If it's not a tool you use every day, you don't need to learn it.
If you don't use language servers, you don't engage with development environments which rely on them, you need not learn them.
If you're making chips on a Monarch 60 you don't need to learn shit about CNC. If you're pushing buttons on a Haas you do.
If you're coming from a Monarch and want to try pushing buttons on the Haas on the kids are using, you need to learn how CNC works. That's your job. If you want to switch from notepad to Zed, you need to learn how language servers work.
If you do not understand how the underlying language server is configured, what the input and outputs are, how it operates, you will run into errors you are unequipped to deal with.
Some languages are more severe than others on this. For example, in C++ your editor is not going to be able to make efficient use of the clangd language server without intervention from the programmer to understand and configure it. On the other hand, for Python the Pyright LS will be mostly fine without additional configuration.
I only had to silence a couple of unneeded warnings specific to codebase I was working with, which took under five minutes and that only because I finally got annoyed enough. Otherwise it took zero configuration (this was Kate though, but it doesn't matter, there is no clangd-specific default config there).
The compilation database[1] given to clangd needs to be complete, understood by the clangd argument parser, and capable of producing a build.
This starts to hurt bad when the compiler producing the build is not clang. If you try to use a compile database describing C++20 module compile lines for GCC, clangd will choke badly. If you're using MSVC flags that clang-cl hasn't been taught yet, clangd falls over. If you're using CMake to produce the compile database, it will leave out synthetic targets from the database and you will see errors because clangd cannot find the interfaces described by those targets. If you're not using CMake you need to configure bear or ninja or whatever to produce a compilation database for you. Etc, etc.
Because then all entrants would fail the competition.
There has been no significant jump in capabilities such that a meaningful demonstration of general purpose or cryptographically-relevant quantum computing could be performed on "public hardware".
Presumably the organizers know this but still have incentives to drum up news about QC. So they ignore that problem and focus on how to obscure the fact this is a dog-and-pony show.
I mean, I'm sure you're right, but it would seem like the organizers were teeing themselves up for an inevitable "gotcha" moment, given that it is pretty easy for third parties to do exactly what was done here.
Paying 1 BTC for the privilege of getting dunked on in tech media seems like a bad trade.
The current infrastructure cannot handle the new load requirements. Either the infrastructure must change, or they must start denying users the ability to use the infrastructure.