arijo

Even if you don't like Huberman, it's very worthwhile to learn from someone like Hyman.

The post is about Mark Hyman not Huberman.

I prefer fringe than stupid.

All sweeteners are considered harmful.

Please watch the video:

https://www.youtube.com/watch?v=Kkyv1o8Xp_M

Perhaps that was true 50 years ago, but in an increasingly complex technological world, problems simply cannot be solved without increasingly advanced engineering skills.

You can create a timer with one transistor and an LC feedback loop.

Almost all civil, chemical, electrical, etc., engineering emerged from a practice-first, theory-later evolution.

How many thousands of lines does your AI-generated frontend code have?

Do you have to maintain the code?

Everyone knows that to understand metabolism you should use a parser.

I've already tried Paul.

Check my previous submission.

I realize now my comment was dumb.

Thanks for the correction.

Many chronic illnesses are currently being researched as a KD treatment target.

Continuous ketones measurement is a big deal.

You probably can use these physics to measure many other molecules in a continuous non invasive way.

This will be a revolution in personalized medicine.

Ketones next please.

Wouldn’t a digital servo mitigate the problem?

"So what kind of programming work would be the opposite of this?

* Problems are ill-defined and poorly-scoped

* Solutions are difficult to verify

* The total volume of code involved is massive

In my view, this is describing legacy code: feature work in large established codebases."

If you have used cursor.ai to try to create a moderately sized project you'll see this happen even with newly generated code.

In my experience, if you limit yourself to generate not well thought through prompts and do not work on getting a deep understanding of the generated codebase, the LLM will start duplicating the same code flows in different ways, many time forgetting some of the behaviour already implemented.

Kind of like having dozens of developers working on the same codebase clueless about what each other has done and re-implementing the same functionality until the code turns into a pile of spaghetti code.

It can be done but:

* You must have a deep understanding of the code

* You need to think hard about what you are doing and give very detailed instructions to the AI

It works for trying a quick prototype but when moving on to production grade code you need to slow down and "program" step by step providing precise instructions as you go.

You'll have to design the changes to the minor detail and then you can let the AI do the grunt work.

It's like programming without coding.

I actually took the time to read the tutorial and found it helpful.

Thanks for taking the time to share the walk through.

I actually have the book and I agree it is very good.

This is actually cool, thanks.

That's nice but I was looking more for a simple implementation of the concept from first principles.

I mean an understanding from the view of the internals and not so much the user perspective.

The body generates glucose in an high protein diet via gluconeogenesis.

You'll still have glucose spikes with high protein.

That's why you don't feel satiated.

Eat fat.

I don't really care about the standardized interface.

I just want to know how you'd implement something that would load your services and dependencies from a config file, bind them altogether, distribute the load through several local VMs and make it still work if I kill the service or increase the load.

In less than 1000 lines.

Great opportunity for someone ballsy to write a book about kubernetes internals for the general engineering population.

Bonus points for writing a basic implementation from first principles capturing the essence of the problem kubernetes really was meant to solve.

The 100 pages kubernetes book, Andriy Burkov style.

Keto is not high protein.

It’s high fat, moderate protein, low carb diet.

I follow a 2.5 to 1 fat to protein/carbs diet for example.

It has worked for hundreds of thousands of people when done right.

Unlike caloric restriction diets, keto restricts carbs which is the macro that causes glucose spikes.

Glucose spikes is what makes you hungry.

For folks who prefer to watch the movie:

https://www.youtube.com/watch?v=P-q1makxsN4

LLMs can work if you program above the code.

You still need to state your assertions with precision and keep a model of the code in your head.

Its possible to be be precise at an higher level of abstraction as long as your prompts are consistent with a coherent model of the code.

I'm not sure I follow - your assertion was that 12% is significative.

I personally chose for price on a low-cost model (unless the improvement is to significant that it justifies the higher price).

I wasn't expecting for my comment to be red so literally but ok.

We're talking about the most cost-efficient model, the competition here is on price, not on a 12% incremental performance (which would make sense for the high end model).

To my knowledge deepseek is the cheaper service which is what matters on the low-end (unless the increase in performance was in such magnitude that the extra-charge would be worth the money).

People could be flipping a coin and the score would be the same.

Take mitochondria as an example.

There has been a revolution in the understanding how this organelle works in the last few years.

https://www.sciencedirect.com/science/article/pii/S089865682...