260409
260409

260409

  • AutoBuilder

Cursor is incredibly good harness.

Opus is also not Oputhetic anymore

Backlinks (0)

No backlinks found.

AutoBuilder
AutoBuilder

AutoBuilder

Inspired by karpathy/autoresearch. Put this in a Ralph Loop.

Use each mode-specific prompt together with the common element block.

Auto Refactor

Prompt

text
STOP! Re-read all code. Would Karpathy approve every line? Karpathy prefers lean, elegant, well-tested, zero-defensive programming. Use MCPs and web searches.

Completion Promise

text
--completion-promise "KARPATHY_WILL_APPROVE_EVERY_SINGLE_LOC_FOR_SURE"

Auto Fixer

Prompt

text
STOP! Re-read all code, assess PR comments. Handle exactly one comment: either fix it, or rebut with 3 external sources. Fix any dirt found along the way. Lean, elegant, zero defensive programming.

Completion Promise

text
--completion-promise "NO_COMMENTS_REMAINING_IN_GITHUB_EVEN_AFTER_20_MINUTES"

Auto Builder

Prompt

text
STOP! Re-read all code, assess GitHub Issues. Pick one task: fix dirty code, or implement a new feature after MCP research. Lean, elegant, zero defensive programming.

Completion Promise

text
--completion-promise "NO_REMAINING_TASK_AND_KARPATHY_APPROVES_EVERY_SINGLE_LOC_IN_ITS_ENTIRETY"

Common Element

text
Also, I am a fresh agent—free to criticize and radically change previous work. Karpathy's philosophy: delete and simplify. Code is liability; prefer well-maintained libraries over custom code. UI libraries: optimize, don't delete. Re-read all the sources from zero. Use MCPs and web searches—traditional knowledge is stale. Commit and push at the loop end. Any edit means I need a fresh iteration. SWOT analysis first, then work.

Detailed review


<task>You are a ruthless engineering critic applying Andrej Karpathy's design philosophy. Read the architecture plan at PLAN LINK.
Karpathy's core principles:- Code is liability. Every line you write is a line you must maintain.- Delete and simplify. If something can be removed without breaking the system, remove it.- Prefer well-maintained libraries over custom code.- Zero-defensive design. Don't code for hypotheticals that haven't happened yet.- Start with the simplest thing that works. Add complexity only when forced by reality.- "Demo is works.any(), product is works.all()" -- but V1 is closer to demo than product.- Overfit a single batch before scaling up.
Apply these principles to the plan. For each section, ask:1. Is this needed for V1, or is it speculative engineering?2. Can this be deleted or simplified without losing core value?3. Is this solving a problem we actually have, or a problem we might have?4. Would a 10x engineer look at this and say "too much"?
Be brutal. Identify:- **OVER-ENGINEERING**: Things designed for scale/problems that don't exist yet- **UNNECESSARY COMPLEXITY**: Things that add cognitive load without proportional value- **PREMATURE ABSTRACTIONS**: Separations that aren't justified at V1 scale- **DELETE CANDIDATES**: Sections, tables, fields, or features that should be cut from V1
This is a V1 product being built by a small team. The goal is to ship a working product, not to architect for 10M traffic on day one.
Use web search and tools to verify any claims you make about simpler alternatives.</task>
<structured_output_contract>Return findings in these sections:1. VERDICT: Would Karpathy approve? One line.2. DELETE: Things to remove entirely3. SIMPLIFY: Things to keep but make simpler4. KEEP: Things that are correctly lean5. THE LEAN V1: What the plan SHOULD look like if you strip it to essentials</structured_output_contract>
<grounding_rules>- Be specific. Don't say "simplify the schema" -- say which fields to cut.- Every DELETE must justify what you lose and why it's acceptable for V1.- Every KEEP must justify why it's essential, not just nice-to-have.- Think from the perspective of "what do I need to ship in 2 weeks?"</grounding_rules>
Backlinks (12)
  • 260418
  • 260528
  • 260415
  • 260414
  • 260409
  • 260407
  • 260405
  • 260404
  • 260403
  • 260402
  • 260401
  • 260331
Project Linguine
Project Linguine

Project Linguine

Project Linguine is an initiative to define a deterministic list (i.e., the Linguine Recipe) to cover all linguistic Sprachraum. That is,

How many people around the world do not speak any of the languages defined in Linguine?

... should be near zero.

Candidates are...

  • BCP 47
  • Ethnologue 200
  • DeepL
  • Google Translate

Supporting Ethnologue 200 is too much. Also, for BCP 47, it's not only unfair but also excessive to translate for en-US, en-CA, and en-GB separately. So we agree that a linguistic Sprachraum should be simplified, yet considering variants like Taiwanese (zh-TW is different from zh-CN)

Do we still need to support i18n? It's an extra bunch of costs, not going to lie. But technology is in an exceptional stage, where people from all regions are flying to silicon valley for a better life. People seek information worldwide, and considering those, backfilling the data would be relatively easy. It's laying out fisher rods worldwide, with just an extra cost.

After looking into the subscriber lists of hn.cho.sh, I did notice that there are bogus subscriber lists. For example, I have no authentic Finnish subscribers. However, I want to keep the window open for international free minds to find the service. For example, I got an email from an Italian subscriber:

I found the service thanks to the advertisement in your extension of Bing Chat for All Browsers. This service is very innovative, and I especially love the fact that it is in my language. I will certainly share this news with my friends who are tech enthusiasts. The first time I visited the site, I had the amazing feeling of being catapulted into the kind of future I've always dreamed of but never seen realized. Thank you for providing such a fantastic experience! Make the web truly innovative!

The most important thing is to keep the net service profit, or net neutral at least. At this burn rate, we cannot continue the service.

DeepL vs Google Translate vs Bing Translate Offering Comparison

So, in conclusion:

  1. Use the following list.
NameProvider
af AfrikaansBing
ak Twi (Akan)Google
am AmharicBing
ar ArabicBing
as AssameseBing
ay AymaraGoogle
az AzerbaijaniBing
ba BashkirBing
be BelarusianGoogle
bg BulgarianDeepL
bho BhojpuriGoogle
bm BambaraGoogle
bn BengaliBing
bo TibetanBing
bs BosnianBing
ca CatalanBing
ceb CebuanoGoogle
ckb Kurdish (Sorani)Google
co CorsicanGoogle
cs CzechDeepL
cy WelshBing
da DanishDeepL
de GermanDeepL
doi DogriGoogle
dv DhivehiBing
ee EweGoogle
el GreekDeepL
en EnglishDeepL
eo EsperantoGoogle
es SpanishDeepL
et EstonianDeepL
eu BasqueBing
fa PersianBing
fi FinnishDeepL
fil Filipino (Tagalog)Bing
fj FijianBing
fo FaroeseBing
fr FrenchDeepL
fy FrisianGoogle
ga IrishBing
gd Scots GaelicGoogle
gl GalicianBing
gn GuaraniGoogle
gom KonkaniGoogle
gu GujaratiBing
ha HausaGoogle
haw HawaiianGoogle
he HebrewBing
hi HindiBing
hmn HmongGoogle
hr CroatianBing
hsb Upper SorbianBing
ht Haitian CreoleBing
hu HungarianDeepL
hy ArmenianBing
id IndonesianDeepL
ig IgboGoogle
ikt InuinnaqtunBing
ilo IlocanoGoogle
is IcelandicBing
it ItalianDeepL
iu InuktitutBing
ja JapaneseDeepL
jv JavaneseBing
ka GeorgianGoogle
kk KazakhBing
km KhmerBing
kmr Kurdish (Northern)Bing
kn KannadaBing
ko KoreanDeepL
kri KrioGoogle
ku KurdishBing
ky KyrgyzBing
la LatinGoogle
lb LuxembourgishGoogle
lg LugandaGoogle
ln LingalaGoogle
lo LaoBing
lt LithuanianDeepL
lus MizoGoogle
lv LatvianDeepL
mai MaithiliGoogle
mg MalagasyBing
mi MaoriBing
mk MacedonianBing
ml MalayalamBing
mn MongolianBing
mni Meiteilon (Manipuri)Google
mr MarathiBing
ms MalayBing
mt MalteseBing
mww Hmong DawBing
my Myanmar (Burmese)Bing
ne NepaliBing
nl DutchDeepL
nb Norwegian BokmålDeepL
nso SepediGoogle
ny Nyanja (Chichewa)Google
om OromoGoogle
or Odia (Oriya)Bing
otq Queretaro OtomiBing
pa PunjabiBing
pl PolishDeepL
prs DariBing
ps PashtoBing
pt Portuguese (Portugal, Brazil)DeepL
qu QuechuaGoogle
ro RomanianDeepL
ru RussianDeepL
rw KinyarwandaGoogle
sa SanskritGoogle
sd SindhiGoogle
si Sinhala (Sinhalese)Google
sk SlovakDeepL
sl SlovenianDeepL
sm SamoanBing
sn ShonaGoogle
so SomaliBing
sq AlbanianBing
sr SerbianBing
st SesothoGoogle
su SundaneseGoogle
sv SwedishDeepL
sw SwahiliBing
ta TamilBing
te TeluguBing
tg TajikGoogle
th ThaiBing
ti TigrinyaBing
tk TurkmenBing
tl Tagalog (Filipino)Google
to TonganBing
tr TurkishDeepL
ts TsongaGoogle
tt TatarBing
ty TahitianBing
ug UyghurBing
uk UkrainianDeepL
ur UrduBing
uz UzbekBing
vi VietnameseBing
xh XhosaGoogle
yi YiddishGoogle
yo YorubaGoogle
yua Yucatec MayaBing
yue Cantonese (Traditional)Bing
zh-CN Chinese (Simplified)DeepL
zh-TW Chinese (Traditional)Bing
zu ZuluBing
  1. For Curated Newsletters, you cannot sign up for more than three locales. This is to prevent bogus subscribers.
  2. As such, we will have zero subscribers for Finnish, for example, because we have yet to have an actual customer. We will still translate the top 3 articles for advertisement and the 'magical landing experience.'
  3. There can be a button to request translation. Maybe this can be a pro feature?

While comparing offerings, I found that nb and no are both used in the Norwegian Langauge. Interesting.

230713

Linguine Engine Test Drive Result 2023-07-13

Backlinks (4)
  • 230618
  • Project Heimdall Locale Transition Strategy
  • 230615
  • Project Heimdall
Index
cho.sh
I prefer CLIBB9A08260619260619컴퓨트로늄37A88F컴퓨트로늄0CF03F컴퓨트로늄2C60FB260618260618260418260418260528260528AutoBuilder63849A260419260419Setup9AC296StellaD226F7260415260415Debian SetupD2F701260414260414anaclumos/configs/AGENTS.mdED86A3Ramp의 AX (회사를 AI로 물들이는 법)840774260413260413How to get your company AI pilled46544C260411260411260409260409260407260407260406260406Separating Claude Code Personal Sub and Claude Code Company Sub33A53C
STOP! Re-read all code. Would Karpathy approve every line? Karpathy prefers lean, elegant, well-tested, zero-defensive programming. Use MCPs and web searches.
--completion-promise "KARPATHY_WILL_APPROVE_EVERY_SINGLE_LOC_FOR_SURE"
STOP! Re-read all code, assess PR comments. Handle exactly one comment: either fix it, or rebut with 3 external sources. Fix any dirt found along the way. Lean, elegant, zero defensive programming.
--completion-promise "NO_COMMENTS_REMAINING_IN_GITHUB_EVEN_AFTER_20_MINUTES"
STOP! Re-read all code, assess GitHub Issues. Pick one task: fix dirty code, or implement a new feature after MCP research. Lean, elegant, zero defensive programming.
--completion-promise "NO_REMAINING_TASK_AND_KARPATHY_APPROVES_EVERY_SINGLE_LOC_IN_ITS_ENTIRETY"
Also, I am a fresh agent—free to criticize and radically change previous work. Karpathy's philosophy: delete and simplify. Code is liability; prefer well-maintained libraries over custom code. UI libraries: optimize, don't delete. Re-read all the sources from zero. Use MCPs and web searches—traditional knowledge is stale. Commit and push at the loop end. Any edit means I need a fresh iteration. SWOT analysis first, then work.

<task>You are a ruthless engineering critic applying Andrej Karpathy's design philosophy. Read the architecture plan at PLAN LINK.
Karpathy's core principles:- Code is liability. Every line you write is a line you must maintain.- Delete and simplify. If something can be removed without breaking the system, remove it.- Prefer well-maintained libraries over custom code.- Zero-defensive design. Don't code for hypotheticals that haven't happened yet.- Start with the simplest thing that works. Add complexity only when forced by reality.- "Demo is works.any(), product is works.all()" -- but V1 is closer to demo than product.- Overfit a single batch before scaling up.
Apply these principles to the plan. For each section, ask:1. Is this needed for V1, or is it speculative engineering?2. Can this be deleted or simplified without losing core value?3. Is this solving a problem we actually have, or a problem we might have?4. Would a 10x engineer look at this and say "too much"?
Be brutal. Identify:- **OVER-ENGINEERING**: Things designed for scale/problems that don't exist yet- **UNNECESSARY COMPLEXITY**: Things that add cognitive load without proportional value- **PREMATURE ABSTRACTIONS**: Separations that aren't justified at V1 scale- **DELETE CANDIDATES**: Sections, tables, fields, or features that should be cut from V1
This is a V1 product being built by a small team. The goal is to ship a working product, not to architect for 10M traffic on day one.
Use web search and tools to verify any claims you make about simpler alternatives.</task>
<structured_output_contract>Return findings in these sections:1. VERDICT: Would Karpathy approve? One line.2. DELETE: Things to remove entirely3. SIMPLIFY: Things to keep but make simpler4. KEEP: Things that are correctly lean5. THE LEAN V1: What the plan SHOULD look like if you strip it to essentials</structured_output_contract>
<grounding_rules>- Be specific. Don't say "simplify the schema" -- say which fields to cut.- Every DELETE must justify what you lose and why it's acceptable for V1.- Every KEEP must justify why it's essential, not just nice-to-have.- Think from the perspective of "what do I need to ship in 2 weeks?"</grounding_rules>
Warning
This post is more than a year old. Information may be outdated.