simon84

I am wondering what type of workload this is for.

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

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.

You are correct, better concede than argue.

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.

Any idea how it got there in the first place?

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.

Is there a way to bypass the tamer? i.e. if the implementation is actually needed for some subtle task

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 ?

I'm not sure if the feature is intersection or the use of AI to write it...

Polygon intersection is a well known thing. Video games and geographic information systems (topology) do that for decades.

Tell me more, what should I look at ?

Can you explain how it passes through firewall and lands on a somewhat listening socket on the remote, without being abused meanwhile ?

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.

I think the hype does not quite cover the use cases it provides.

It is not ordinary computing, is applies to a very limited set of problems.

The buzz is that it is strong at cracking cryptography, but that's about it with what we have today. The rest is scientific exploratory statistics.

Is the cost of infrastructure and tokens accounted for ? You should add this to your dashboard to be fair.

Posting on a Saturday at Middle-of-the-Atlantic-ocean time might not be the best audience catcher

About the same feeling here. I guess not everything is about global banking scale.

I've tried clever tricks to get AI produce unsupervised stuff and came back from it. The slop and loss of cognitive knowledge about what it did was uncomfortable to me... I cannot understand how you would hand off critical job to it.

I wish :) The style could have been mine, but it diverges quickly if context is too long.

Since I didnt write the content, my brain does not have the same ownership feeling.

I think the thought process, doing and undoing makes it yours, in this case we skip that part.

I actually did this once, it was great, it actually added credibility somehow I think.

After an article, I told Claude that he can add its own note at the end as the "author" and he shall tell how I promptes him and then give a honest self-assessment.

You can check this post (regardless of the content, just check the P.S. section at the end)

https://www.linkedin.com/pulse/aeonics-simon-uyttendaele-ozt...

AI is not so good at identifying a writing style by name.

Instead I feed it a few articles I wrote and tell it to follow the same style.

This gives way better results imho

While I second that, Im not convinced that the quality of the content is altered by use (or not) of AI.

A click-bait for brainless content will not stick long on the front page anyhow.

If legit contributors feel more comfortable with AI reviewing their posts, I think that is fair. And I'd rather read a structured post instead of fuzzy ideas.

My take is that if you use it for supervized coding then max5 is more than enough.

It becomes a bottleneck when using agents that spawns to tackle larger tasks and do random trial and errors to correct itself autonomously.

As a dev, understanding the code is a vital part of my job, hence I cannot let agents write more than I can review (and not only review, but fully understand). So I'm also not benefiting from x100 coding speed, but I'm not losing control either.

Are those random people or do you have somewhat categories? I.e. I want to challenge a mechanical engineering idea, not everyone even knows what that is.

Rate limit from Cloudflare, so much for moving to EU Stack :/