caxap

I wonder if over time the two will simply merge and become indistinguishable from one another. The human writing is already changing, as the author has observed. The LLMs will follow the change, and soon meet us in the middle!

Or maybe the humans will do the opposite and shift to Sardukar-style communication instead? LLMs can easily match that as well.

That style I would very much prefer to all the fluff people write today and were writing even before AI.

The VC-backed pressure will ensure that all kinds of safeguards will be skipped, regardless of my feelings! Solving millenium math problems in a few hours might piss off some mathematicians. But an AI that's autonomously looking for cold fusion or a cure against cancers might cause planetary-scale desaster on the way there.

The only reasonable safety measure is to always keep humans in the loop, and to give them time to understand and consolidate all advances, to actually go slow.

> Indeed, the space of mathematical problems remains infinite;

> and the difficulty level of such problems is unbounded.

Are these two sentences true? Is there a way to prove or disprove them?

Could the space of mathematical problems be finite and their difficulty level bounded?

I think that vertical is actually a step function that is still limited by the human bottleneck of deciding what to build and making sure that it actually gets built. Give the AI an underspecified task, you get what you asked for and also what you didn't ask for, in good old Genie fashion.

Hill-climbing problems seem to escape this limitation. But I wonder what will happen when the AIs start acing benchmarks faster than you can write new benchmarks, and when you run out of hard problems to solve because you rely on humans formulating them.

The real vertical will come when the AI gets access to physical world instead of bash; and when the human is finally out of the loop.

I think unsafety, distillation, and China catching up in chipmaking are inevitable.

Just like how it was inevitable for SoTA LLMs to ignore copyright.

The actual challenge isn't how to prevent all these, but how stay on top.

And to stay on top it is inevitable to train unrestricted models. Anthropic is fighting windmills.

If this article was written a year ago, I would have agreed. But knowing what I know today, I highly doubt that the outcomes of LLM/non-LLM users will be anywhere close to similar.

LLMs are exceptionally good at building prototypes. If the professor needs a month, Bob will be done with the basic prototype of that paper by lunch on the same day, and try out dozens of hypotheses by the end of the day. He will not be chasing some error for two weeks, the LLM will very likely figure it out in matter of minutes, or not make it in the first place. Instructing it to validate intermediate results and to profile along the way can do magic.

The article is correct that Bob will not have understood anything, but if he wants to, he can spend the rest of the year trying to understand what the LLM has built for him, after verifying that the approach actually works in the first couple of weeks already. Even better, he can ask the LLM to train him to do the same if he wishes. Learn why things work the way they do, why something doesn't converge, etc.

Assuming that Bob is willing to do all that, he will progress way faster than Alice. LLMs won't take anything away if you are still willing to take the time to understand what it's actually building and why things are done that way.

5 years from now, Alice will be using LLMs just like Bob, or without a job if she refuses to, because the place will be full of Bobs, with or without understanding.

There are no tricks because you're too smart to fall for your own tricks.

The one thing that works is the time buffer between your future self and now.

The real challenge is to override the sadness with new memories.

Doing all the things you listed (dog park / build sth. / books, etc) makes the time go by faster, especially if you find something you like.

Stay holed up, and the sadness keeps resonating, building its harmonics (reliving past images, what ifs).

Everyone has their own pace. Stay strong.

> fixed up the blinds or cooked pork steaks

I know how it feels. Wish you the best.

And if everyone starts paying to highlight their ads, then those that don't pay will stand out.

Yes, the government knows how to lie with statistics. Since the introduction of the so-called "one-euro jobs", the unemployment has gone down only because people who took such jobs were not counted as unemployed anymore, even though their situation has not been improved.

Just send an email to this woman---she might send your mac back! My wife just told me that Iranians, like the ones in this case, don't like to use stolen things.

Thanks for your insights, there is a lot of value for me in your post.

I have an intense dislike for VHDL. I have yet to meet an engineer who likes it! I hate it with passion, but it lets me write circuits in the way I want. Luckily, emacs VHDL mode makes me type less.

If you've done non-trivial FPGA work you have probably experienced the agony of waiting an hour and a half for a design to compiler and another N hours for it to simulate before discovering problems. My simulations never took hours. I use GHDL (an open source tool that converts VHDL into C++) to simulate my code, which is much slower than running Modelsim in a virtual machine. So I guess that you are working on much larger problems than I do.

I have tried using a high level language before writing my circuits in VHDL before. But the results were not very good, apart from learning a lot more about the actual algorithm/circuit.

Either I coded at a too high of a level, which would be impossible in an FPGA (e.g., accessing a true dual port block RAM at 3 different addresses in a clock cycle), or I ended up simulating a lot of hardware just to make sure that it will work.

But the point is, no matter which approach I tried, it was painful, so I ended up choosing the workflow that is less painful.

I'd have to know more specifics to be able to comment beyond a certain level. I am developing a marker detection system that runs at 100fps, with 640x480 8-bit grayscale images. First I am doing CCL to find anything in the image that could be a marker. At the same time, some features are accumulated for each detected component (potential marker).

Then the features are used to find which component is a real marker and what's its ID. And finally, the markers have some spacial information that allows me to find out the position and orientation of the camera.

Even though the FPGA that I use is the largest of all Cyclone II FPGAs with 70k LEs, I have to juggle registers and block RAM because it's too small to store all data in the registers, and using up too many registers substantially increases the time to place&route the design.

I maintain that FPGA's are, fundamentally, still about electrical engineering and not about software development. These, at certain levels, become vastly different disciplines. Once FPGA compilers become 100 to 1,000 times faster and FPGA's come with 100 to 1,000 times more resources for the money the two worlds will probably blur into one very quickly for most applications. I agree, and I would add that the compilers need to be smarter about parallelizing the code. So while being able to perform better than the alternatives, the FPGAs are still a pain to develop for. Even if the compilers are faster, and FPGAs are bigger, writing code for FPGAs feels still more like writing assembly code rather than code that is easily accessible "for the masses". But I would be happy if the compilers become just 10x faster!