I see the article focuses on tasks and things to do or not do.
These are primarily driven by skills of the junior. Though you should expect they have none.
What sort of comes out between the lines is the attitude of the person, and I think this matters most and should be framed directly.
You want someone curious that will peek beyond what you asked. Someone proactive that will not sit and wait for an assignment. Someone meticulous that will not self-satisfy of quick-and-dirty.
When said like this, the article content resonates as the consequences rather than objectives.
What I meant was a tangent: the HTTP was designed with a strong assumption that the application implementing it (the web server) would be the one providing the logic. Hence all the RFC terminology "should", "must", targeted at the implementor.
But very quickly, the logic was deferred to a layer on top (PHP,...) which would focus on the business aspect. The wiring was strong but the contract intent is loose (the requirements on the transport do not apply to the function).
Different layers, different people involved. What survived are the more or less conventions about it, which for the ease and limitations imposed by the protocol layer, led to infinite discussions about GET having a body or not.
The whole question arises because there is this clash between transport and logic that is wired on top, not built-in.
So while indeed, introducing QUERY solves a protocol gap, the people designing the business method never cared (or even knew) about that gap in the first place. This was another people's job to try to reconcile the two.
That's why I'm saying that digging into the initial assumption that the implementor of the HTTP is bound to business-level contraints is not reflecting the reality that has been going on since the early days of the dynamic web.
This whole thing is non sense. It basically mixes technical constraints (body or not body) with a functional requirement that arises from people that are tied to semantics of the protocol.
HTTP is transfer protocol. It should not ever imply anything at the business level.
Yes REST made it's worst mistake out if it by giving a meaning to the verb.
Yes proxies rule how the body is re-interpreted in spite of the will of the sender (wtf).
But the original RFC states clearly that any verb can be used. This is how WebDav normalised its own.
But playing fancy by introducing a change that all HTTP implementation will have to honor is a very bad and irrational choice.
We have long passed the point where there is more AI generated content than authentic human content.
That will soonish spiral into uniformity and degradation (see the experiments where image generation is recursively trained on generated images).
The idea is good, but the proposal falls in the same trap.
The best case would be to issue whatever method is specified in the "method" attribute.
At the moment, it suggests to add support for PUT, PATCH, DELETE because that is the current bias in using REST. However html should be agnostic of the implementation behind the scenes and allow for any http method akin the http standard itself.
Is it a full blown browser with support for all capabilities (basically a web-view with no title bar?) or does also it attempt to block all fatigue-related bloat, ads, moving parts, auto-play videos,...?
It is all about the power of statistics and the un-humanly conceivable processing power we grant it.
I like the dream analogy framing as it avoids to personify an algorithm.
Though, the article may somewhat underrate the quality of the dream (aka code) we can get from AI. Trivial tasks have been trained so much that high fidelity output is frequent.
It is when your idea is genuine and novel that the divergence is most noticeable because there is less resemblance to mimick.
Indeed, this is ridiculous for a country that says no beer before 21. Arguing that children will learn to bypass the age restriction is equally founded as for alcohol.
This is the reason SBOM is an attempt to force documenting dependencies.
It will not solve everything but it helps.
Other than that, it is a reponse to one's laziness to import a full library to use only one method... it is part of my code review to always question the need for imports and (try to) weight the maintenance cost.
EU companies are judged guilty of negligence because backups were not totally disconnected (even though distant site) and ransomware did destroy them.
So that is starting to dig deeper than a plain mistake. I guess we will soon-ish witness the first AI slop trial going on, this will be interesting to follow
It's not so much about velocity or quality, both of which LLM do (or will) provide.
The real question is about accountability and liability.
When a major data leak is going to happen, who will they sue or fire ? That is the value engineers provide. They understand, confirm, and take ownership.
I can understand the motivation for CLI-based clients, but the browser built-in network inspector overlaps a lot.
There is more to Oproxy with traffic shaping but would it be enough to convince ? Spawning a Docker is easy today but it would be less friction with a normal app imho.
Nice I get it now.
And from your usage, a natural question is how much effort was put by the AI to find the verified answer ? Did it need to run significantly longer or less that without these constraints ?
The most surprising for me is the network continuity. This is nice (I haven't tested it).
Now I am more into stateless things for which the server is somewhat expected to fail, so the whole feature of job continuity is not a switch incentive for me.
They give a tiny example and insist on micro, fast start, but the say it lasts up to 8 hours and is up to 16 vCPU.
What sort of app require faster boot (than lambda or ec2), but only for a limited interval, and with possibly plenty of processing power...
Maybe I am not the right target, but if you have examples so that I can better appreciate, I'd love that