May have what you're looking for. Steps & tools used are in the "parts.rst" file.

There can be other valid perspectives than your own.

Different people code for different reasons.

Some see it as a means to an end... "I want X as an end result and I don't care how I get it."

Others see it as an art form and something special to them; their sense of worth is tied to their knowledge and experience in something that not just anyone can do (without an AI).

OP uses an LLM because they just want the end result. You might write code for different reasons entirely. Neither is "wrong" or "useless."

There will always need a human on the end to check if the LLM didn't hallucinate anything on it, including manually writing the unit tests.

The only bummer I'm seeing with fcc is not having a linker mean not being able to use external libraries. So you're really limited to what you can include in your own project, but if it truly is C89 compliant there are plenty of useful single header libraries you could use for various things.

I'll check it out!

There are outliers where an excellent team of devs produce great quality. SQLite comes to mind. But it's easy to forget that is the 0.x%.

Or is it "To make an apple pie, you must first invent the universe" kind of deal. Which doesn't make sense to me either.

In the same way a program manager is free to say "We build X from scratch" even though they made no code contribution to it. The we is replaced with I since no other person was involved in this case.

That's fine for bread, but for people that see code more like art, they have a preconceived notion that "from scratch" means writing the code yourself.

Some people code to solve a problem and they don't care how it gets done. They have no problems using AI and see other methods as prehistoric. That's fine for them, carry on.

For me, the journey is more important than the destination.

Being able to code "by hand" is what strokes my sense of worth and accomplishment... knowing I can do something that not just anyone can. Pushing a button or prompting an AI isn't the same for me, that's more like a project manager and something I never want to be.

When people bash on the anti-AI crowd, they just don't understand that people code for different reasons, and neither is more right or wrong.

Code can be art, making food can also be art. So I'm don't agree with your distinction that code is materially different from baking.

The terminology "from scratch" and "by hand" are really not interchangeable in my opinion. "By hand" implies something about the process. "From scratch" implies something about the state before you started, not anything about the process.

It's fine to disagree, I don't think you're "wrong", and I don't think I'm "right" either. We just have different perspectives and definitions of words, and that's ok.

I think the more important thing is understanding the intent of the person speaking, instead of just trying to win an argument, as that's derailing the conversation/topic anyways. And in this context, all I was trying to convey by using "by hand" and "from scratch" was the notion of coding without using an LLM.

If people were similar confrontive in calling out such managers ...

https://github.com/rfgplk/micron.cpp

This is an example of a true "from scratch implementation" (as long as you target the freestanding compile option, hosted still depends on pthread for threading). Absolutely zero external code or references anywhere outside the stated repo. (Not even compiler builtins or includes are needed). You can drag and drop it wherever you'd like hit compile and you're done.

I've seen this approach already in practice: LLM+decompiler give better code than the original code that the binary was compiled from.

The task was rewriting an MP3 decoder from Rust into ARM assembly language, Cortex-M33 flavor specifically, optimizing for both speed and code size. The output is approx 3k instructions. The tl;dr is that Opus 5.5 nailed the task, whether writing assembly or symbolasm. It took approximately 2x tokens for the latter, which I think is largely explained by the fact that it was dealing with a novel language nowhere represented in its training set.

The quality of the result was comparable; the raw asm was slightly faster and slightly less dense, which I consider insignificant because I think you can get the same effect just by tuning the prompt. In particular, if I were re-running the experiment, I might set a strict code size budget and then ask it to optimize for speed within that budget, allowing comparison on a single scalar.

The experiment was compelling in another way: the code was 3x denser and 1.5x faster than -O3 output from Rust. So for certain applications, going to assembler will be worth it, especially as the cost of generating the code goes to zero.

[1]: https://github.com/raphlinus/symbolasm

If all this AI thingy is true, the decompiling and recompiling directly from the machine code is a sort of proof that what's the most important is the data model. Additionnaly, when I get into some software which I did not write, I must focus on this data model in order to understand it, and guess what, the direct memory one from 'human' assembly/C is usually much better than those giga-convoluted object oriented abstracted ones (I think the worst one was llvm, usually everything c++ is).

Some are generating "human" assembly code for their everyday software (I am following some of those projects I found here, on HN). Again, if all that is true, the killer feature: you could generate "human" assembly for several ISAs fitting one data model, for instance the IP UNlocked RISC-V (vectorized or not)!

Either my C skills are getting rusty and that is how a C codebase normally looks like, or LLM was trained on some suspicious codebases.

The commits were done by Claude.

LLMs are very good at copying best practices.

It's easily to spot a code base that's build LLM-assisted. But to know that no human actually took interest in the code is hard to know without talking to the humans that prompted the LLM.

Pretty much everyone developing software for a living is using AI. This basically outs you as not having any recent tech involvement.

No amount of nostalgia and wishful thinking overcomes reality.