I have to be honest. While this is obviously a smart and useful idea, it misses one of the core features of Jev: its confidence scores. Partial confidence could easily be mapped to fractional spaces, using unicode characters like U+2009: THIN SPACE. As it stands, this package is not harnessing the full power of Jev.

> its confidence scores

important to note that the "confidence" score is... maybe not what people think it is - kind of useless, and just a convenience step from the probabilities.

from the docs: "confidence is a statistic computed from the probability distribution the answer already gives you." [0] I actually encourage people to visit the docs because it has a specific page on this with a little applet to really make this clear.

[0] https://docs.typesafe.ai/confidence

What else do people think it is? If Typesafe had found a way to measure arbitrary AI results against objective reality (past, future and present) they'd either be making a killing on the stock market or working for the NRO, not publishing that as a confidence value on their API

Well I think there's an expectation that it's similar to the probability score, something that's outputted by the model itself, and so there's some level of "intelligence" (e.g. being able to recognize if the subject matter is relevant to the data it's been trained on, or as an accumulation of errors e.g. it couldn't figure out the question).

Man we're going full 2015 ML, telling normies that confidence scores mean NOTHING to alleviate false negatives/positives.

Yeah I keep getting this weird sense that Jev is kinda poorly reinventing ML. I guess the graphs don't lie and theoretically I can replace luna with it, but I don't really use luna anyway.

What is the use case for a classifier that works 90% of the time...? I feel like if I'm classifying something, I probably care enough that 90% ain't gonna cut it...

I guess the answer is just agential stuff that effectively gets double checked by the LLM in the driver seat, anyway? That tracks, though it means that jev is mostly just for the people making harnesses. Which is all of us but still!

I think the argument would be that the classifiers of classic ML can be very useful and that Jav is a geenral purpose classifier you can just use that doesn't need to be trained per-task.

I mean when you get your bloodwork done to check for an illness, the test you get will give the right result 90% of the time - and depending on the result, you doc might order more tests, which could be more expensive but no mrpe reliable than the first - but they are going to be statistically independent, and after 2 more, he can be 99.9% sure.

Which begs the question, can Jev retest until it gets the right result? Can it tell how corellated two of its results are? 90% correct makes for a wonderful iterator, but a poor oracle.

Yup, you articulated what I was trying to say but much more clearly (thanks!). I suppose I haven't tried just setting n=3 or something, but presumably the Jev docs would mention that if it were enough to get it from 1 figure to 2 (i.e. 90% -> 99%). I agree that there are places where 90% certainty can help, but it really needs to be an agential system; when a doctor runs more tests, they are experimentally engaging with empirical reality in a context-appropriate way.

I guess, in the end: I think it'll end up being fantastically useful for artificial engineers with their vastly superior ability to keep track of fine details and rapidly context switch, but fairly niche for any of us organic engineers that are left.

All that doesn't apply to low stakes stuff like games, though -- can't wait for the first truly open world game, NGL. A silver lining to the cobalt cloud?

Can't believe it's already been 10 years...

https://joelgrus.com/2016/05/23/fizz-buzz-in-tensorflow/

What an eerie feeling reading this, or was it prescient?:

"""

    def fizz_buzz_encode(i):
        if   i % 15 == 0: return np.array([0, 0, 0, 1])
        elif i % 5  == 0: return np.array([0, 0, 1, 0])
        elif i % 3  == 0: return np.array([0, 1, 0, 0])
        else:             return np.array([1, 0, 0, 0])

interviewer: OK, that's probably enough.

me: That's enough setup, you're exactly right. [<--- !!] [...]

"""

Damn, Claude was there all along

oh, I missed that. Brilliant!

> me: That's enough setup, you're exactly right.

So that's where in the training set current models get that phrase! /j

    The tests mock Jev. 

10/10 no notes

I posted the same observation, then saw yours. Yours is better (at 0.92 certainty) so I deleted my post.

Reading this, I got excited that there may be be a hidden Easter egg, making fun of Jev. I was disappointed to find actual tests.

Instead of using Choice with criteria "space_0", "space_1"..., it could be even more elegant to use criteria names like "", " "... which could be directly inserted into response.

This needs an SBOM and a SonarQube Qualitygate pass to be considered production grade code

Man-made horrors beyond my comprehension, neat.

I have no mouth but I must pad.

What is my purpose?

You pad the text.

Oh, my god.

Make sure to vendor this package if you want reliable operation.

    it('trusts Jev when it chooses the wrong amount', async () => {
    answer('space_2');
    await expect(leftPad('jev', 8)).resolves.toBe('  jev');
    });

> This means the package can add between 0 and 10 spaces. If more than 10 spaces are needed, Jev has no correct option. Which feels appropriate for this project.

I'll raise a PR which uses Jev to check if the target length is beyond this range

I thought you were doing a PR to add an 11th space.

Nah, for ≥11 spaces we should fan out to a GPT-6 Astra agent. On light reasoning of course, lest we be wasteful.

Since the potential error increases with N, I suggest spawning N different models and let them fight it out instead.

Is this package vibe coded with Jev or just old school with an LLM?

Jev-in-the-Loop. Makes sense.

> MIT Licensed

Would have been funnier if it used the GLWTPL: https://spdx.org/licenses/GLWTPL.html

I’d be curious to see how reliable it is in practice, it sounds like a cheap and (hopefully) easy benchmark

How did this guy get a single-letter GitHub username?

i maintained a system where for .. reasons (like other systems) from early days have users with id: null "null" "" and some i do not even know how to write here

so probably early bird

His oldest repository was updated in 2011. Looks like he's been there a long time.

It's funny, i actually worked with this guy (same small startup, not closely), and recognized him from that unique username on this post. It's been so long i wouldn't have had any idea if not for the oddness of the single letter username.

GitHub clearly didn’t use his left pad

Would be fun to have a test runner that uses Jev for assertions.

Btw, this model also has very tiny inherent bias: https://jev-bias-analysis.stupidlabs.lol/

Flaky tests by design is a diabolical idea

Done: https://github.com/freakynit/jev-test-runner

On the npm doomsday thing, the scarier version is someone vendoring it and the padding silently drifting between runs.

JEV seems similar to BERT. Where would it be useful?

I use it mainly to check whether this code fits the rules I defined, just a yes or no. But I'm not sure if that's the right way to use it.

But is it Web Scale.

It's surely on the Pareto Frontier of something

I already have Jev fatigue.

what if 11 spaces are needed

You need to get the Pro version, please contact sales.

Run it twice

im so confused about what i should bring up at the 10am today

Aren't we all. Aren't we all.

Terrorist

Can someone ELI5?

Jev is a new type of model that just makes decisions based on given options. It's small and really really fast.

Leftpad is a npm package that chooses if it should or shouldn't pad the left side of a string. It was famous for bringing down everyone's npm installs a few years ago.

This combination is a double joke. Put something stupid in something stupid.

  > Jev is a new type of model that just makes decisions based on given options. 

something like “if x > y then x else y”?

Uses JEV to do something that's one line of code. Also, "leftpad" was a useless package from years ago that many important packages used instead of writing the code themselves. Its outage at some point broke a lot of packages.

why useless? it did one thing that js didn't natively do

It did one thing that you could write in one line of code. But it wasted space as a packaged dependency instead.

It also ended up inadvertently highlighting a massive problem with the JavaScript ecosystem.

And yet we learned nothing from it and all the same problems keep popping up, only this time in the form of supply chain attacks.

github.com/f is more impressive to me than jev-leftpad lol

> Please don't use this in production. Or anything important.

5 to 10 years from now, after this has worked itself deep into the npm dependency chain, we'll be lamenting how Jev-Leftpad is causing outages in critical services.

why

funny

yeah but i have PTSD from the og leftpad stuff

Jev mania at its peak? HN is full of Jev like today.

nowadays i can’t even start a day without a fresh cup of jev in the morning…

wait.. is it just me or are we going overboard? I am waiting for jev assistance to exit vim, no wait.. a decision if we should exit vim or not.

Now that's a rare GitHub Username!

Though, again, a yet another project for a yet another "AI" to make someone else more dependent on it...

Related:

    https://en.wikipedia.org/wiki/Jev_(AI_model)  
    https://typesafe.ai/

One might even say it's unique.

This is funny, because I just implemented the same feature, but mine is calling OpenAI’s Astra on High (very capable for this kind of feature).

It works great, but maybe your implementation could save me some money. I’ll test it and report back.

I can't tell if this comment is satire or not lol

I can. It is indeed satire.

Next: jev-is-even

This makes about as much sense to me as AI-powered air traffic control

poor implementation

jev should only have the choice of space_0 or space_1, then recurse on n-1

this extends the implementation to infinite padding and is cleaner code

Maybe for Enterprise scale, for ramen scale hackers if you need 15 spaces you just add 5 to start with then use space_10. Clean and, importantly, dry.

Is there a local model that can run this?

I think some people are missing the joke here

https://en.wikipedia.org/wiki/Npm_left-pad_incident

Subtlety in a joke is a beautiful art. BUT AT WHAT COST.

People who were in high school in 2016 and therefore not being aware of leftpad are currently in their 6th year of their career if they went directly to college and then a job.

Tech doesn't teach it's own history in a useful way, so we keep repeating it too.

Another multi-volume textbook to carry for the students of the future!

It's fun so far seeing the new trend from the sidelines, never bothered and never will bother learning what JEV is, but I'll see the occasional meme.

I feel for the people whose 'AI strategy' is keeping up with every vibecoded vibecoding junk that releases

I must admit, I stopped keeping up with the new AI terms after J-space. Absolute peace of mind.

I'm very curious about the performance. Where's the quantitative analysis? Got any graphs or charts? How's the recall/precision? Show me the data!

I'm afraid the performance won't be great. Definitely needs a caching layer.

This comes just in time. My app has been using Amazon Mechanical Turk for left-pad queries, and that service is shutting down in less than two weeks.

I should have know that beforehand, I have terraform ready for quickly moving off of mechanical turk into agentic AI left padding, this load-bearing workload has to be clowd powered

Quick, we need a jev-isBoolean(value) so we can code YAML with confidence.

Cracker news upvotes the stupidest shit to the front page

Maybe 90% of people are antiintellectual. Maybe internet is overrun with bots. Maybe they all caught the mind virus /s.