HackerTrans
TopNewTrendsCommentsPastAskShowJobs

readitalready

no profile record

Submissions

[untitled]

34 points·by readitalready·il y a 3 mois·0 comments

[untitled]

3 points·by readitalready·il y a 4 mois·0 comments

Training-Free Group Relative Policy Optimization

arxiv.org
1 points·by readitalready·il y a 5 mois·0 comments

Retrieval-Aware Distillation for Transformer-SSM Hybrids

arxiv.org
2 points·by readitalready·il y a 5 mois·0 comments

HySparse: A Hybrid Sparse Attention Architecture

arxiv.org
5 points·by readitalready·il y a 5 mois·0 comments

comments

readitalready
·il y a 2 mois·discuss
[flagged]
readitalready
·il y a 2 mois·discuss
[flagged]
readitalready
·il y a 2 mois·discuss
[flagged]
readitalready
·il y a 2 mois·discuss
How do you think the tests were generated?

You don't actually think I look at the code, do you?
readitalready
·il y a 2 mois·discuss
I don't micromanage it. I let my projects custom linter micromanage it.

Every project should have a custom linter for their tech stack. It would check for not just syntax errors, but architectural choices as well as taste guidelines.

Whenever the LLM writes bad code, I add it to my linter to check against in the future.
readitalready
·il y a 2 mois·discuss
I let agents break things 30 changes down the line. If something breaks, I add a check to my project validator and start over, with the validator providing instructions on what was wrong and how to fix it. It's all automatic, and now I have a guard against the exact same error in the future.

Some of these checks have caught thousands of the same error, even with the latest Opus 4.7 writing the original code.
readitalready
·il y a 2 mois·discuss
This flow is really for LLM consumption, since Markdown spec documents are for LLMs anyways. And you can always write a JSON-to-markdown converter for human use (actually, LLMs remember Markdown content better than JSON, so you should use that in your flow a well).

The real change is in generation side, and now the spec docs are LLM generated JSON based on other spec docs or human prompts. LLMs seem to write JSON better than Markdown or YAML, if you tell it to follow a schema.
readitalready
·il y a 2 mois·discuss
I moved from Markdown to JSON for all spec writing about 9 months ago. Although not HTML, it still has the same benefits. Claude and the other models are just so much more reliable in a structured format like JSON/HTML/XML.

The most important thing is that I can run static analysis on a structured format. This is important even for my spec documents. I can write data fields and have static analysis analyze it. For example, to confirm database fields match across various spec documents, etc.. The static analysis is also why you use JSON/XML instead of HTML, since you can now have your own custom schema.

Also don't use YAML, as that's far more unreliable. (If you chop a YAML file in half, it's still valid)
readitalready
·il y a 2 mois·discuss
Not for me. 2 Claude Max 20x accounts here both at high usage on weekly allotments.
readitalready
·il y a 2 mois·discuss
This probably started because of Andrej Karpathy's complaint about deployment being more painful than coding itself.
readitalready
·il y a 2 mois·discuss
The point isn't to save money. The point is to make money. And all those companies that are failing because of their fabs, they MADE money because of the fabs.

Intel is now on its way to become another AI chip company. They have no incentive to supply Apple either.
readitalready
·il y a 2 mois·discuss
Your custom linters don't check architectural design?

linters statically check code and provide deterministic recommendations. LLMs are used to make judgement. I specifically write my linters for my project to make recommendations for LLMs.

This is how you save on token usage, so your LLMS aren't wasting tokens on static analysis that a linter could do for free.

That's at least how I make my linters.
readitalready
·il y a 2 mois·discuss
No fixing the mess definitely does not take longer than writing it oneself.

Your linter should identify all issues - including architectural and stylistic choices - and the AI agents will immediately repair them.

It's about 1000x faster than a human code at repairing its own mess.
readitalready
·il y a 2 mois·discuss
Come on Apple at least start the process of building your own fabs. License some of the processes if you must. Otherwise you will always be at the mercy of fabs that are more focused on AI.
readitalready
·il y a 2 mois·discuss
I think companies are charged API prices vs individual prices. That alone is 10x for Anthropic. Not sure though.
readitalready
·il y a 2 mois·discuss
No, you CAN'T raise prices because no one will buy them, destroying your brand and your business. And you won't have supply anyways.

There is no scenario where not having a fab is beneficial.

Apple will have to build their own fabs, whether they like it or not. And they will need to make it competitive if they want to stay in business.
readitalready
·il y a 2 mois·discuss
OMM 0910 is the AI Jesus. We've literally seen this movie before.
readitalready
·il y a 2 mois·discuss
Apple doesn't own TSMC. TSMC is putting Apple in the back burner in favor of Nvidia and other high margin companies.

They are literally being limited by TSMC (as well as the DRAM makers) because they don't have their own fabs.
readitalready
·il y a 2 mois·discuss
You can easily end up like AMD or Intel spending years with your own fab that’s uncompetitive.

You could.

Or you could have no fab and no supply of chips for your business.
readitalready
·il y a 2 mois·discuss
They really need to build their own fabs at this point. AI is going to kill their ASIC and DRAM supply chain if they don't.

"Real men have fabs." - Jerry Sanders, first CEO of AMD.

Actually, AMD, Nvidia, and Apple need to build their own fabs. Maybe Google, Amazon, and Meta too.