HN user

hypendev

51 karma

ian@hypen.space

Posts2
Comments31
View on HN

Because reasoning is an emergent byproduct of training it on all knowledge. It still doesn't "know" things in this form and just generates tokens, no matter how weird we spin it.

So if you don't train it on a large dataset of a lot of words with a lot of sensible connections, it won't be able to reason, as it won't be able to make proper connections between words and sentences.

You can try training a really small model and seeing the gibberish outputs when you train it on only a small dataset.

Minmaxing the dataset to extract maximum generation with minimal data does sound like fun, but if you want to build SoTA models as a company, the economic tradeoff of doing that vs slapping a few more GPU's together is terrible.

This is kind of a loaded question.

"Google" doesn't understand anything, as it isn't one being. Google has also as many average employees as any other company, and they will also come up with bad, corporate, ideas.

Honestly the worst part about the LLM age is that everyone is suddenly an "expert", and that is why we get shitty things like A2A or MCP or whatever the next "shiny" overengineered thing is.

Just like with any new technology, people will crawl out the woodwork to establish "standards" just so they can claim fame, money and attention that comes with it.

Similar problems here in Croatia, few reasons for it:

- Boom of AirBNB's and apartment rentals with tourism, with real low tax rates

- Limited liability abuse - company opens up, sells 30 apartments in a new building, build out the building, don't get any permits, just close the company down and open a new one. Legally, they are untouchable, and getting the permits is now on the apartment owners. Multiple friends live in such buildings, and maintenance is a PITA, trying to legalize it is a PITA, getting water/power is a matter of making shady deals with the neighbours, basically even living in it is technically illegal but not much they can do.

- Large influx of illegal money into the housing market (we have no law to investigate source of income), so money could be laundered easily.

- "Legalization procedures" where if you built a house before a certain year, or just started construction, it could be legalised. This caused people to build "fake roofs" and then claim it as a real building later on.

- Recently, immigration joined too - workers from non-EU countries are now allowed to get work visa's, and a lot of landlords are renting out a small 50m2 apartment to 10 people at the same time for ridiculous prices. The poor workers have to share bedroom with 10 other people, which is a terrible living condition, causing accidents like a whole floor collapsing due to 50+ people living in the building. While it's not legal, inspections are rare and the grey market is thriving.

- And my favorite - as a large number of apartments are bought as investments and uninhabited - around 22% in the capital, according to official estimates, with about 500k free total, in a country of 3.5 million people - the government got a great idea:

They will free up more housing, by offering the landlords of the empty apartments to rent thenm out with government guarantees. This means the government will pay them out 60% of the future rent money immediately, so the landlord can buy another apartment as an investment immediately using that money, and just get richer.

Now, we're in an interesting situation:

- Prices have risen quite a lot, like 3x over the last 5-6 years

- Existing landlords will get funding from the government to buy more apartments

- Meanwhile, new loan rules came out, prevent people from getting a loan that is more than 45% of their salary (after subtracting the costs, including your current RENT). 10% of the value has to be provided immediately by the buyer, and after loan payment and living expenses, you need to have at least 900 euros remaining each month from your salary.

In a country with a median salary of 1300 euros, with median rent being about 500-700 euros, this puts a lot of people in a locked position - you can't get a loan to buy, because you are renting. So from the 1300 euros of your salary, the bank subtracts 500 euros of rent as your "living expense", leaving you with 800 euros monthly total, which is under the legal limit for getting a loan, even tho once you buy the apartment you would not pay rent anymore.

So to get a 30 year loan to buy a 50m2 apartment, you need to have about double the median salary.

Now, they are talking about property taxes, which will force people barely making ends meet to sell the inherited land/houses/apartments for cheap to people that can afford it.

but the mold in the bathroom and roaches in the kitchen definitely are.

I would not agree.

Having lived in low budget apartments for quite a while as a student, a lot of these things are "a norm" and not really the renters fault, but the owners.

Examples:

I moved into an apartment that was "subterranean" level, meaning not fully basement but also not ground floor. When we were looking at it, it seemed fine, everything great, but bathroom had the tiniest vent window ever. I asked about the mold, and the owner was like "oh no, no need to worry about that, the ventilation is quite good actually even tho the window is tiny, we made sure of that" - and at the moment, it seemed so, the air was dry and there was no "humid" feeling about the room.

Well, well - the bathroom was humid as hell and would stay that way after the first shower, even with all the vents open and ventilation turned on. Even worse, the humidity in the rooms was so high that the paint on the wall stayed fresh for quite a long time, painting a few of my shirts that touched the wall. When summer came, the rooms became a hotspot for mosquitoes, and the owner would be like "ah just close the windows" - but that kept the humidity and heat in, making life unbearable and causing mold to erupt (also, because a lot of it was just painted over!! just painted over mold, like what the fuck?)

Another one had homeless people which started living around the building, leaving food and booze all over the place. To make it worse, large trash bins were outside our building, which lead to roaches coming in from the bins and from the balconies, under which the aforementioned people "lived". We couldn't do nothing about it, except ensure that there is minimal reason for them to come to us, lay traps around and ensure we have anti-bug powders around the perimeter. I talked to some of the neighbors that lived there for years and they said it happens nearly every summer.

The bed in the apartment started falling apart at some point, and going to fix it I noticed the bed _was fixed_ already, even tho it was said to be new - and it was fixed badly. The same owner charged me 2k for a "designer couch" that "we ruined", even tho before us moving in the couch was welded and nailed together, as it was obviously broken before, and the owner did not want to admit it even when shown the photo evidence.

Once I moved out, I saw what happened to the apartment on the next listing - the owner just painted over the kitchen cabinets, painted the bed, put a new mattress on it and said "all furniture is new".

So a lot of things might sound like they're the authors fault, but having met one too many "bad actors" in the renting game, I'm quite sure that some of these things might be the owners responsibility.

Thanks!

Honestly, in one iteration of Hypen I actually added a `Script` component, but after trying it, it already felt both dirty and confusing, so it's a definitive no for the near future :)

Regarding accessibility - I've also burned myself quite a few times on that bridge and that is why there won't be 1.0 without it being fully solved - I don't want devs to have to retroactively think about it or for it to have a second class implementation.

I believe there is a solution out of the box that should cover at least 80% of the most common needs, and provide primitives for more custom cases. Hopefully this time I can nail it... fingers crossed!

I also have a horse in this race, would love to have it included!

I'm building Hypen (https://hypen.space), a UI framework with a DSL that works in in Rust, TS, Go, Kotlin, Swift, and all over the place, as long as you can use WASM or binaries.

Some cool things about it:

- Renders natively on Desktop, Web (DOM and Canvas), Android and iOS.

- Streaming-first (SSR), so you can stream native apps from the server

- Custom tailwind parser so it supports your favorite shorthands

- Support for streaming apps from CF workers with 5 lines of JS/TS

- You can embed any Hypen app into another Hypen app like its an iframe, with just 1 line of code

- Has a custom "browser" for Hypen apps, both on desktop and on mobile, so you can easily check how your app looks anywhere

- Coming soon - stdlib and WASI interface to enable full WASM portability across platforms

Note: Desktop support is still a bit early and needs more crossplatform testing

I started building this years ago, first manually, now accelerating it with LLM's which are incredible for mindnumbing tasks like writing frameworks like these requires. Its still in an "early alpha" but it's getting closer to maturity and a "stable beta" by the day, hopefully fully stable 1.0 by end of the year.

Sorry, my bad, might be 97 running on windows 98 - but yes, this is a giant corporation serving hundreds of corporate customers and a few hundred thousand private ones, using nearly 30 years old software because the management does not see reasons to upgrade and spend the extra cost associated with it. New machines and Windows XP are only used by upper management.

Worst part?

Their whole software stack is running on some version of Visual Basic, written by a dude that did not trust "others code" so he wrote everything from scratch, and retired about 5 years ago.

Nobody knows how any of it works, or has any clue. The company will continue to run it and pay him for consultations as long as he is able to do it.

It is still "in distribution", that is why when its "distributed" properly, it will surely add much, much more value to the economy.

But it is a generational opportunity - we can remove a lot of barriers that come with knowledge, lack of it, access to it and more. Someone can easily get pretty on point medical advice without access to doctors. Get specific engineering advice without engaging with those engineers. We can apply common sense or specific knowledge on scale - in a world where about 50% of people have IQ under 100 and access to knowledge is gated behind lines and payments, this has a huge chance ot improve their lives.

And there is the whole shadow inference economy - just for example, a few corporations I have worked with in insurance and telecommunications have been slowly introducing it inside their workflows and their data tooling, being able to clean data, tag it, analyse it in a way that before would probably cost them billons in human costs.

One of them has a database going back to the 80's, with data being formatted and reformatted in all shapes and sizes, coming back all the way from paper records for some of their oldest clients. Cleaning this up was unimaginable before as a "something we can do in a day" project, but was more of a "possible with insane costs". This lead to all further activity being shaped by decisions someone made 40+ years ago, details being lost, data being thrown away or saved in random notes.

And there's millions of companies like that all around the world, which can now do "impossible" and become much more efficient and productive for a much cheaper price and in way less time than ever.

I wouldn't argue the same.

My parents love using ChatGPT, asking it all kinds of questions. My mom discovered Claude and helps her immensely with her job - where she would have to take it home and work a few hours to be able to finish the tasks on her computer, as her company that still uses Office 98, now Claude does it in 5 minutes.

They fixed so many random issues using it, it is insane. My dad had a bike issue which would otherwise be solved by either trying to find obscure manuals from 20 years ago on random forums with me translating it from english to our language, or by taking it to a mechanic which could take months. This way, he just snapped a few photos, said what the problem is, and in a few minutes he had the fix.

I've built software that uses LLM's for a specific usecase - besides general adoption, professionals in the field contacted me and thanked me for making their lives easier, as the tasks would often take a lot of manual work. These people are earning way more from using my software, than I am from their subscriptions, which is still about 20x more than my API costs are.

While most non-dev people are behind the curve, the impact it has on their lives is becoming bigger and bigger by the day.

Back in the times of GPT3 text completion, right before the API came out, a contemporary art museum asked me to collaborate on a project. The project was supposed to include a chatbot, and I was like okay I can probably hook something up.

Then I remembered the "text completion LLM thingy" I saw on HN, and tried it out in the playground. Once I gave it an IRC style example of a conversation to complete, I was like hm, this could work. Then I figured out I could "sort" people into different groups based on personality using the same text completion engine and some answers they provided. Then I noticed I could have it provide me with JSON directly.

That's when I realized how big this could be for code and data analysis - even tried to convince an at the time cofounder to pivot into AI coding, but to no avail.

Once the API was released and the art project chatbot got launched (and the theater show associated with it, which even won some awards), people who used it loved the chatbot, got into heated arguments with it, tried to teach it things, talked about their lives and were sad when it didnt remember something.

That was when I understood the social impact this could have on people - they really behave like its a person on the other side. They show interest, think it displays emotion, try to entertain it, be polite, ask about its thoughts and hopes and dreams. And even when they knew they were talking to a machine, they were still trying to be friends and make it happy, which was quite beautiful to see.

Later on, I had a third oh shit moment - once the 3.5 API was out and about, I prototyped a Rust code generation harness for a client, akin to a primitive claude code. That was the "I'm getting a bit worried" oh shit moment, and it caused a lot of reflection and thinking about the future. And I happily welcome it.

What is a larger scaler for you? What is "outside harness an LLM"?

What is _the proof_ if all the proofs are not _proofs_?

I don't babysit my LLM based services which are used by coaches and clients around the world. One of my LLM based solution get 30-4k daily hits and I have users coming back on the regular to use it. without babysitting, doing things that would take them hours of manual work and research.

I don't babysit the developers I work with and our clients, which both use LLM's themselves and at scale with their clients, serving all kinds of LLM powered services to millions of users worldwide.

You are not "seeing" the large adoption because:

- The technology is "a few years old" in its usable state - The corporate adoption cycle is slow - You have to understand the technology to use it in a good way, which most corporate devs and PM's do not

So it will take a bit for the "obvious" adaptation on large scale.

But you won't "know" when the large adoption happens.

Silent inference is growing every day, and that is what real adoption looks like - not an LLM being in your face chatbox, but running in the background, sorting, finding, fixing things, aligning data, figuring out analytics, tuning the ads, cleaning the datasets.

Perry definitely looks interesting, was just looking at getting one of these to include into my framework.

Would love to see more about it, or see more about the actual compiler docs.

While the UI framework part is neat, I prefer not to force everything into TS. Combining it means UI definitions and semantics get mixed into AST, making the unbundling of them a humongous task in itself.

Exactly the reason I built my own with pretty similar native UI semantics which supports Rust, Go, Kotlin and more (https://hypen.space) - would love to integrate Perry with it to compile TS apps directly into the runtime - but while the idea itself is great, looking at the documentation makes it hard to implement, and a lot of parts seem confusing.

Can I just use the compiler without the rest of the framework? What is the architecture? What are the limits?

After digging through the documentation, I'm unfortunately just more confused honestly. There are dozens of packages and slop markdown files such as `BUG_STRING_COMPARISON.md` and or `PERRY_UI_IMPLEMENTATION.md` which is an instruction file left for the LLM that just makes me trust the project less.

So while the idea is cool and the performance seems cool, the AI slop presentation would definitely need improvement. Adding a human touch would make it much, much better, as one could actually understand what they are dealing with.

Motorola's history is so unfortunate.

They were a great brand, cool phones, one of early Android players.

After being bought out by Google, Motorola had some of the best devices out there with stock android, especially in the budget segment (and loved among android devs).They had one of the best smartwatches in the game at the time - Moto 360 (2014!!).

Then, after dropping the Nexus 6, Google stripped the patents and sold them to Lenovo. For a while it was ok, even dropping the relatively innovative Moto Z which had all the cool "modular" addons, played with it for a bit and seemed cool.

And then, things seemed to start taking a turn for the worse as Lenovo kept enshitiffying it more and more, using the brand name as a wedge in the market in which they are basically forgotten. They have the Razr brand which is cool, but the segment that was their best (budget phones) is now ruined with adware so they can extract every bit of value from it.

Such a sad ending for a company that was so early in the space.

Interesting, agents seem to always fall in a spectrum between overengineering and underengineering, where they will either go wild and overengineer a simple solution, or do the minimal effective thing to pass with "//TODO fix for prod".

It's the same patterns we see with human devs, just applied on codebases at scale.

The conclusion has an interesting tibid tho - maybe the frameworks and their developers should start including more abstract focused primitives instead of just the low level ones, similar to what Encore did, as that way the behavior is encoded at the framework level.

I'm actually working on that - it's called Hypen - (hypen.space).

You can build your core in Go or any other supported language, and write the UI in the Hypen DSL.

While desktop is still in the works and should be out in the next week or two, currently the alpha supports Native iOS, Android, Web and Web Canvas, and just like mobile, the Desktop will be _real_ native.

Forking the Web 2 months ago

I mostly agree with the article - I believe the differentiation should be between documents and applications.

While HTML serves its purpose, especially for documents, the modern web is a giant mess of that legacy, combined with unfriendly ergonomics and glue/hacks built on top just so we as developers can have better DX for creating complex software on top of it.

Building a browser means having to deal with all that legacy, wether we like it or not, so most of the browser market got captured by the big players who have enough manpower to cover all those edge cases. That also means we have to deal with whatever technical choices or bloat they make, causing an infinite stream of issues, from memory usage, to size, to limitations that don't make sense in 2026 but are still there because someone 20 years ago decided to write them like that. As I deal with mobile webviews a lot in my daily work, I unfortunately had to get familiar with quite many gotcha's and edge cases, and some are just... absurd in this day and age.

I believe we need a separation between an application layer and the document layer, and especially between the UI language and the actual application code - script tags serve their purpose, but again, they are a hacky solution with its own bag of tricks, and those tricks impact all of the software built upon it.

Now, a bit of a shameless plug I've been working on something to fill that gap, at least for myself and hopefully for others who encounter the same issue - it's called Hypen (https://hypen.space) and it's a DSL for building apps that work natively on all platforms, with strict separation of code/UI/state, and support for as many languages and platforms as I can maintain, not "just javascript". While currently it's focused on streaming UI, it's built with Rust and WASM at it's core and will soon allow fully "compileable" apps.

While it may not be the future of software, once you get into building something like that, it becomes obvious that the way we are building now is at least wrong, and at best kafkaesque.

I was pissed off at the same thing today.

I tried ticking every part - not working. Then I tried just the core. Not working. It took me 5 captchas until I got to one that had different images.

Terrible experience. Most of the time I just close the site now as I can't be arsed.

Is this maybe in Hamburg? :)

Back in the heyday, I used to work in a startup devoted to the cinema world, where with one app you could buy tickets for all cinemas - even those that did not "officially" support it.

Among them were arthouse theaters in Hamburg, which I often used for testing, as most of the time reserving a few seats would not matter as they would be empty, at least during the day. Some of them had projections of old movies, and I was like "if I lived there, I'd go every day".

Ironically, now I live between 2 art cinemas in my city and rarely go to any of them :)

Most companies don't do that much of a regular demo to customers anyways - turns out most customers aren't even interested for the first 30-50% of the project, then they become mildly amused, until the final 80% - that's they start getting incredibly interested and opinionated.

Agile as "devs can do what they want" never really existed ;-)

No real agile ever really exists in the end :)

But it's not devs not doing "what they want" that bothers me - it's the absurdly over-planned project estimates and timelines, with every detail of the project being specced out, not a lot of margin room for errors, invoking the name of "agile principles" as a way to deal with exactly things the PM's don't want to deal with in that moment.

I'd be fine with some degree of planning ahead, or starting with prototypes/PoC's, but such a huge part of the industry just chunks it into "same boat but we'll put agile stickers on the holes", and there is a whole industry of ceremonies around it, that it breaks the "core principles" of agile.

What a beautiful irony have we built :)

We never left waterfall in the end. Working with and for dozens, collaborating with probably a hundred software companies in different scales, every single one said:

We do agile

Guess what? Every single one of them was doing waterfall.

Their agile included preplanning and pre-specifying the full spec and each task, before the project kicked off. We'd have meetings where we'd drill down into tasks, folks would write them down so detailed that there would be no other way than doing that. Agile would be claimed, but the start date, end date, end spec and number of developers was always concrete.

Sometimes, the end date was too late, so a panic would ensue. Most of the time, the date was too late because developers had "unknowns" which then had to be "drilled down and specced so they wouldnt be unknowns". Sometimes, nearly 50% of the workweek was spent on meetings.

A few times, a project was running late - so to make sure we are _really_ doing it agile, we'd have morning standups, evening standups, weekly plannings, retrospectives, and backlog refinement. It would waste the time, and the "unknowns" aka "tickets to refine" were again, as always, dependant upon the PM/PO/CEO's wishes, which wouldn't get crystallized until it was _really last minute_.

One customer wanted us to do a 2 year agile plan on building their product. We had gigantic calls with 20+ people in them, out of which at least half had some kind of "Agile SCRUM Level 3 Black belt Jirajitsu" certificates.

To them, Agile was just a thing you say before you plan things. Agile was just an excuse to deal with project being late by pinning it on Agile. Agile was just a cop out of "PM didn't know what to do here so he didnt write anything down". Agile was a "we are modern and cool" sticker for a company.

And unfortunately, to most of them, agile was just a thing you say for the job, as their minds worked in waterfall mode, their obligations worked in waterfall mode, companies worked in waterfall mode, and if they failed their obligation to the waterfall, their job would go down one.

So while we were doing the Agile ceremonies, prancing around with our Scrum master hats, using the right words to fit into the Agile™ worldview - we were doing waterfall all along.

And after 15 years, I'm not even sure - did agile really ever exist?

Sorry if it sounded like that, not trying to have a flame war, just trying to understand which part we don't _understand_, as it seems silly to me.

Yeah, we cannot predict with 100% accuracy the results of a model, not mentally, as to be able to do that we should be able to do the same math in our head and that's just ultra rare next level intelligence. And we can make a reliable predictor, but making a reliable prediction model of a models results would be the same model in the end.

So the closest that we can get to "understanding" it fully, is learning how it works, and developing intuition around it. And I think we pretty much have that, at least among the people in the field. Those who worked on training it especially have some intuitive understanding of what is going on, otherwise they would not know where to "test and hack".

It's math all the way down, but I feel like the angle some people in early days used about "magic emergent properties" or "signs of consciousness" ended up making it seem more mystical than it is.

We do understand tho, it is exactly what they were made for.

If you train it on a dataset of Othello games, or a dataset including these, you are basically creating a map of all possible moves and states that have ever happened, odds of transitions between them, effective and un-effective transitions.

By querying it, you basically start navigating the map from a spot, and it just follows the semi-randomly sampled highest confidence weights when navigating "the map".

And in the multidimensional cross-section of all these states and transitions, existence of a "board map" is implied, as it is a set of common weights shared between all of them. And it becomes even more obvious with championship models in Othello paper, as it was trained on better games in which the wider state of the board was more important than the local one, thus the overall board state mattered more for responses.

The second research you linked is also has a pretty obvious conclusion. It's telling us more about us as humans than about LLM's, about our culture and colors and how we communicate it's perception through text. If you want to try something similar, try kiki bouba style experiments on old diffusion models or old LLM's. A Dzzkwok grWzzz, will get you a much rougher and darker looking things than Olulola Opolili's cloudy vibes.

The active research is as much as:

- probing and seeing "hey lets see if funky machine also does X"

- finding a way to scientifically verify and explain LLMs behaviors we know

- pure BS in some cases

- academics learning about LLM's

And not a proof of where our understanding/frontier is. It is basically standardizing and exploring the intuition that people who actively work with models already have. It's like saying we don't understand math, because people outside the math circles still do not know all behaviors and possibilities of a monoid.

A joke says that its because once you get it, you lose the ability to explain it like a normal person :)

And another joke says the best way to explain a monad tutorial is to write another one, so sorry for this.

Just think of it as a box.

If amazon sent items themselves, it would be hard to pack, no way to standardize, things would break often or fall out of their respective boxes.

Now, if you put it into one of the standardized boxes, that makes things 100x easier. Now you can put these on a conveyor belt, now you can have robots sorting these, now you can use tape to close them, standardization becomes easy as it's not "t-shirt,tennis ball,drill" but just "box box box".

So now you can do all kinds of things because it's all a box. And you can also stress test the box.

It's the same with these.

A. You can just have a function that: calls a something on IO, maps it's values, does a calculation, retries if wrong, stores the result, spits it out.

Or B. you can have functions that calls any function on IO, functions that map any value to any other value, functions that take any other function and if that function fails calls another function or retries, one that stores any value given to it and returns with information if it saved or not etc.

The result is the same in the end, but while 1 makes the workflow be strictly defined only for that case, and now you have to handle every turn and twist manually (did the save save? what if not? write a check, write a test that ensures its not and the check works, same if it does...) the 2 lets you define workflows with pre-tested, pre-built blocks that work with any part of your codebase.

And it makes your life 1000x easier because now you have common components that work with any data type inside your codebase, do things your way always, are 100% tested and make it easier to handle good cases, bad cases, wiring and logistics. And you can build pipelines out of them. Because at the end, what it does is just lets you chain functions that return wrapped values.

And you end up with code like:

val profileData = asAsync { network.userData(userId) } //returns a Async<Result<UserData, Error>

.withRetries(3) // Works on Async, and returns Result, retries async if fails

.withTraceId(userId) //wrapped flatmap that wraps success into Trace<T> and adds a traceId

.mapTrace(onError = { ErrorMappingProfile }, { user -> Profile(user.name, user.profileId) } // our mapTrace is a flatMap for Trace objects, so it knows how to extract trace objects, call the functions and wrap them again

.store("profile_data") //wrapped mapCatching again for storage explicitly that works on Trace objects, knows how to unwrap them, stores them,

.logInto(ourLogger) // maps trace objects into shared logger

Each of these things would before have to be manually written inside the function, the whole function tested for each edge case. if/else's, try/catch, match/when/switch.

This way, only thing you need to cover with tests now is `network.userData()`, as all other parts are already tested, written and do what they say they do. And you can reuse this everywhere in your projects. Instead of being a function you call with data, it becomes a function you give a box and it returns a box. Then you can give it to any other function that needs a box. If boxes make no sense, think of the little connectors on lego bricks, or pipe connectors in plumbing, or stacking USB adapters or power strips.

I can't stress enough how much this approach helped me in real life cases - refactoring old codebases especially, as once you establish some base primitives, the surface area starts massively collapsing as the test surface area increases.

Not sure if we read the same post, as I cannot agree with this claim, especially under this post that exactly goes into details of what happened.

LLM is a sorcery tech that we don't understand at all

We do, and I'm sure that people at OpenAI did intuitively know why this is happening. As soon as I saw the persona mention, it was clear that the "Nerdy" behavior puts it in the same "hyperdimensional cluster" as goblins, dungeons and dragons, orcs, fantasy, quirky nerd-culture references. Especially since they instruct the model to be playful, and playful + nerdy is quite close to goblin or gremlin. Just imagine a nerdy funny subreddit, and you can probably imagine the large usage of goblin or gremlin there. And the rewards system will of course hack it, because a text containing Goblin or Gremlin is much more likely to be nerdy and quirky than not. You don't need GPT 5 for that, you would probably see the same behavior on text completion only GPT3 models like Ada or DaVinci. They specifically dissect how it came to this and how they fixed it. You can't do that with "sorcery we dont understand". Hell, I don't know their data and I easily understood why this is going on.

they want you to think that LLMs are smart beasts (they are not)

I mean, depends on what you consider smart. It's hard to measure what you can't define, that's why we have benchmarks for model "smartness", but we cannot expect full AGI from them. They are smart in their own way, in some kind of technical intelligence way that finds the most probable average solution to a given problem. A universal function approximator. A "common sense in a box" type of smart. Not your "smart human" smart because their exact architecture doesn't allow for that.

and that we know what LLMs are doing (we don't)

But we do. We understand them, we know how they work, we built thousands of different iterations of them, probing systems, replications in excel, graphic implementations, all kinds of LLM's. We know how they work, and we can understand them.

The big thing we can't do as humans is the same math that they do at the same speed, combining the same weights and keeping them all in our heads - it's a task our minds are just not built for. But instead of thinking you have to do "hyperdimensional math" to understand them 100%, you can just develop an intuition for what I call "hyperdimensional surfing", and it isn't even prompting, more like understanding what words mean to an LLM and into which pocket of their weights will it bring you.

It's like saying we can't understand CPU's because there is like 10 people on earth who can hold modern x86-64 opcodes in their head together with a memory table, so they must be magic. But you don't need to be able to do that to understand how CPU's work. You can take a 6502, understand it, develop an intuition for it, which will make understanding it 100x easier. Yeah, 6502 is nothing close to modern CPU's, but the core ideas and concepts help you develop the foundations. And same goes with LLM's.

personally side with Yann Le Cun in believing that LLM is not a path to AGI

I agree, but it is the closest we currently have and it's a tech that can get us there faster. LLM's have an insane amount of uses as glue, as connectors, as human<>machine translators, as code writers, as data sorters and analysts, as experimenters, observers, watchers, and those usages will just keep growing. Maybe we won't need them when we reach AGI, but the amount of value we can unlock with these "common sense" machines is amazing and they will only speed up our search for AGI.

I have a similar story, but I was playing on the beach. There was a mound right next to it and I would love to play there, and the mound had some funny stones. One of them was square with something painted on it, I was fascinated by romans so I annoyed my parents with "I found a mosaic!" and took it with me.

Turns out, years later, they excavated a roman villa there. Funnily enough, the same beach has roman villas, dinosaur prints, austro-hungarian tunnels and yugoslavian bunkers. Quite a lot of history in one pretty beach.

I am building Hypen, a UI framework that enables you to stream native UI to any platform (Android, iOS, Web, Desktop soon) from the server.

It supports languages like Rust, TS, Kotlin, Swift and Go for the backend. Comes with things like reactivity, tailwind support, routing out of the box. It basically lets you update apps without the app store, use the same codebase for all platforms or have custom server-driven modules in your apps.

Upcoming cool things: - Working on canvas support so you can easily switch or render anything in canvas. - Building an stdlib so apps can also be compiled and client-only - Easy way to deploy apps

Open sourcing this in a few days, it's still early alpha now.

https://hypen.space

1D Chess 3 months ago

Don't know when was the last time I had so much fun with chess. Quite intuitive, clicked on the first click.

Would enjoy so much if there were more of these, feels like an obligation-free chess puzzle.