Vibe limit reached. Gotta start doing some thinking.
바이브 한도 도달. 이제 좀 생각을 시작해야겠다.

Paid compilers and remotely acessible mainframes all over again - people apparently never learn.
유료 컴파일러와 원격 접속 가능한 메인프레임이 다시 등장하는 중입니다 - 사람들은 도무지 배우지 않는 것 같습니다.

The destruction of spelling didn’t feel like doomsday to us. In fact, I think most people treated the utter annihilation of that skill as a joke. “No one knows how to spell anymore” - haha, funny, isn’t technology cute? Not really. We’ve gone up an order of magnitude, and not paying attention to how programming is on the chopping block is going to screw a lot of people out of that skill.
맞춤법 파괴는 우리에게 종말처럼 느껴지지 않았습니다. 사실 대부분의 사람들은 그 기술의 완전한 소멸을 농담처럼 여겼던 것 같습니다. “이제 아무도 맞춤법을 모른다” - 하하, 웃기죠, 기술이 귀엽지 않나요? 전혀 그렇지 않습니다. 우리는 한 차원 도약했고, 프로그래밍이 도마 위에 올라 있다는 사실에 주의를 기울이지 않으면 많은 사람들이 그 기술을 잃게 될 것입니다.

Zuckerberg recently said that those not using AI glasses will be cognitively disadvantaged in the future.
최근 저커버그는 AI 안경을 사용하지 않는 사람들은 미래에 인지적으로 불리해질 것이라고 말했습니다.

Imagine an AI-native from the future and one of the fancy espresso coffee machines that we have today. They will be able to know right away how to operate them from their AI assistants, but they won't be able to figure out how they work on their own.
미래의 AI 네이티브와 오늘날 우리가 가진 고급 에스프레소 커피 머신을 상상해보세요. 그들은 AI 비서 덕분에 바로 작동법을 알 수 있겠지만, 스스로 어떻게 작동하는지는 이해하지 못할 것입니다.

That's the future that Zuckerberg wants. Naturally, fancy IT offices will likely be gone. The AI-native would have bought the coffee machine for nostalgia effect for a large sum, trying to combat existential dread and feeling of failure which are fueled by their behavior being even more directly coerced into consumption.
그것이 저커버그가 원하는 미래입니다. 당연히 고급 IT 사무실은 사라질 가능성이 큽니다. AI 네이티브는 존재론적 불안과 실패감을 극복하기 위해 향수를 자극하는 목적으로 커피 머신을 큰 돈을 주고 샀을 것입니다. 이 감정들은 그들의 행동이 더욱 직접적으로 소비로 강제됨에 따라 더욱 심화됩니다.

Sure, calculators are useful in professional life and in high school math and sciences. But you still had to do everyday math in all kinds of places and didn't always have a calculator at hand. The smartphone changed that
물론 계산기는 직업 생활과 고등학교 수학 및 과학에서 유용하다. 하지만 일상적인 수학은 여러 장소에서 직접 해야 했고 항상 계산기를 손에 쥐고 있지는 않았다. 스마트폰이 그 상황을 바꿨다.

I feel that's relevant in two ways: just like with math, a little bit of manual coding is going to be a huge difference compared to no manual coding, and any study like the one you propose would be hugely complicated by everything else that happened around the time, both because of smart phones and the coinciding 2008 crash
나는 이것이 두 가지 면에서 관련 있다고 생각한다. 수학과 마찬가지로 약간의 수동 코딩이 전혀 수동 코딩을 하지 않는 것과 비교해 큰 차이를 만들 것이고, 당신이 제안한 연구는 스마트폰과 2008년 금융 위기라는 당시의 다른 모든 사건들 때문에 매우 복잡해질 것이다.

For developers who read and understand the code being generated, the tool could go away and it would only slow you down, not block progress.
생성된 코드를 읽고 이해하는 개발자에게는 이 도구가 없어져도 진행이 막히지 않고 오히려 속도만 느려질 뿐입니다.

And even if you don’t, it really isn’t a hard dependency on a particular tool. There are multiple competing tools and models to choose from, so if you can’t make progress with one, switch to another. There isn’t much lock-in to any specific tool.
설령 그렇지 않더라도 특정 도구에 대한 강한 의존성은 아닙니다. 선택할 수 있는 여러 경쟁 도구와 모델이 있으므로 하나로 진전이 없으면 다른 것으로 전환하면 됩니다. 특정 도구에 대한 잠금 현상은 거의 없습니다.

I think there is a lot of reticence to adopt AI for coding but I'm seeing it as a step change for coding the way powerful calculators/workstation computers were for traditional engineering disciplines. The volume of work they were limited to using a slide rule was much lower than now with a computer.
코딩에 AI를 도입하는 데 많은 주저함이 있다고 생각하지만, 저는 이것이 전통적인 공학 분야에서 강력한 계산기나 워크스테이션 컴퓨터가 그랬던 것처럼 코딩에 있어 획기적인 변화라고 보고 있습니다. 슬라이드 룰을 사용하던 시절에 비해 컴퓨터를 사용하면서 처리할 수 있는 작업량이 훨씬 많아졌습니다.

Recent research suggests it would in fact speed you up.
최근 연구에 따르면 실제로는 속도를 높여준다고 합니다.

https://metr.org/blog/2025-07-10-early-2025-ai-experienced-o...

So even if it’s not an actual productivity booster on individual tasks, perhaps it still could reduce cognitive load and possibly burnout in the long term.
그래서 개별 작업에서 실제 생산성 향상 효과가 없더라도, 장기적으로 인지 부하를 줄이고 번아웃을 완화할 가능성은 여전히 있을 수 있습니다.

Either way, it’s a tool that devs should feel free to use or not use according to their preferences.
어쨌든 개발자들이 자신의 선호에 따라 자유롭게 사용하거나 사용하지 않을 수 있는 도구입니다.

https://news.ycombinator.com/item?id=44522772

I don't think this one is a good comparison.
이것은 좋은 비교라고 생각하지 않습니다.

Once you had the binary, the compiler worked forever[1]
바이너리를 얻으면 컴파일러는 영원히 작동했습니다[1]

The issue with them was around long term support for bugs and upgrade path as the language evolved.
문제는 버그에 대한 장기 지원과 언어가 발전함에 따른 업그레이드 경로에 있었습니다.

---

[1] as long you had a machine capable of running/emulating the instruction set for the binary.
[1] 바이너리의 명령어 집합을 실행하거나 에뮬레이트할 수 있는 기계가 있는 한.

IAR for example is simply a fantastic compiler. It produces more compact binaries that use less memory than GCC, with lots and lots of hardware support and noticeably better debugging. Many companies have systems-engineering deadlines which are much less amenable to beta quality software, fewer software engineering resources to deal with GCC or build-chain quirks (often, overworked EEs writing firmware), and also a strong desire due to BOM cost to use cheaper/less dense parts. And if there is a compiler bug or quirk, there is someone on the other end of the line who will actually pick up the phone when you call.
예를 들어 IAR은 단순히 환상적인 컴파일러입니다. GCC보다 더 작고 메모리를 덜 사용하는 바이너리를 생성하며, 하드웨어 지원이 매우 풍부하고 디버깅도 눈에 띄게 우수합니다. 많은 회사들은 베타 품질 소프트웨어에 덜 적합한 시스템 엔지니어링 마감일을 가지고 있고, GCC나 빌드 체인의 특이점들을 다룰 소프트웨어 엔지니어링 자원이 적으며(대개 과로하는 전자공학자들이 펌웨어를 작성), BOM 비용 때문에 더 저렴하고 밀도가 낮은 부품을 사용하려는 강한 욕구도 있습니다. 그리고 컴파일러 버그나 특이점이 있을 경우, 전화를 걸면 실제로 전화를 받는 사람이 있습니다.

That said, some of those toolchain+IDE combos absolutely do suck in the embedded world, mostly the vendor-provided ones (makes sense, silicon manufacturers usually aren't very good at or care much about software, as it turns out).
그렇긴 해도, 임베디드 세계에서 일부 툴체인+IDE 조합은 확실히 별로인 경우가 있는데, 주로 벤더 제공 툴들이 그렇습니다(실리콘 제조업체들은 보통 소프트웨어에 능숙하지 않거나 크게 신경 쓰지 않는 경우가 많기 때문입니다).

That's true in general. With paid licenses and especially subscriptions, you're not just getting the service, you're also entering a relationship with the provider.
일반적으로 맞는 말입니다. 유료 라이선스, 특히 구독의 경우 단순히 서비스를 받는 것이 아니라 제공자와의 관계에 들어가는 것입니다.

For companies, that often matters more than the service itself - especially when support is part of this relationship. That's one of many reasons companies like subscriptions.
기업에게는 이 관계가 서비스 자체보다 더 중요할 때가 많습니다. 특히 지원이 이 관계의 일부일 때 더욱 그렇습니다. 이것이 기업들이 구독을 선호하는 여러 이유 중 하나입니다.

For individuals, that sucks. They don't need or want another relationship with some random party, that they now need to keep track of. The relationship has so much power imbalance that it doesn't benefit the individual at all - in fact, for most businesses, such customer is nothing more than a row in an analytics database - or less, if GDPR applies.
개인에게는 그게 불편합니다. 그들은 또 다른 무작위 당사자와의 관계를 원하지도 필요로 하지도 않으며, 이제 그 관계를 관리해야 합니다. 이 관계는 권력 불균형이 너무 커서 개인에게 전혀 이익이 되지 않습니다. 사실 대부분의 기업에게 그러한 고객은 분석 데이터베이스의 한 행에 불과하거나, GDPR이 적용된다면 그보다도 적은 존재입니다.

(Also AVR/PIC compiler from Microchip had a dongle as recently as February this year, and it looks like it's still available for sale even though its license isn't in the new licensing model).
(또한 Microchip의 AVR/PIC 컴파일러는 올해 2월까지도 동글을 사용했으며, 새로운 라이선스 모델에는 포함되지 않았음에도 불구하고 여전히 판매 중인 것으로 보입니다).

Clang is not being professionally used commonly in the embedded space.
Clang은 임베디드 분야에서 전문적으로 널리 사용되고 있지 않습니다.

What's the cost between never using Claude, and using it and getting these lower limits? In the end, I'm left with no Claude in both situations, which leaves me better off for having used it (I wrote more code when Claude worked).
Claude를 전혀 사용하지 않는 것과 사용해서 이런 낮은 한도를 받는 것 사이의 비용은 무엇일까요? 결국 두 상황 모두 Claude가 없지만, 사용했을 때가 더 낫습니다(Claude가 작동할 때 더 많은 코드를 작성했으니까요).

As for the cost, you are ignoring the situation where someone has depended on the tool so much that when it goes away they are atrophied and unable to continue as before. So no, in your scenario you’re not always left better off.
비용에 관해서는, 누군가가 도구에 너무 의존해서 도구가 사라지면 기능이 쇠퇴하고 이전처럼 계속할 수 없는 상황을 무시하고 있습니다. 그러니 아니요, 당신의 시나리오에서는 항상 더 나은 상태로 남는 것이 아닙니다.

They don't, because ironically enough human meatbags all need to be trained from scratch, unlike LLMs which don't die every 80 years or so.
그렇지 않죠, 아이러니하게도 인간은 모두 처음부터 훈련을 받아야 하는 반면, LLMs는 80년마다 죽지 않으니까요.

I doubt even 10% of the devs now were conscious when "paid compilers and remotely accessible mainframes" still existed.
지금 개발자 중 10%라도 "유료 컴파일러와 원격 접속 가능한 메인프레임"이 존재하던 시절을 의식하고 있었을지 의문입니다.

I have a receipt of sale that says otherwise.
저는 그와는 다른 판매 영수증을 가지고 있습니다.

When you are totally hooked and they are fully out of money, that's when you'd realize the long con you've been dragged into. At this very moment, that they are tightening the usage limits they are not telling you, and you still think the peanuts you are paying them now would be enough in the future? It's called https://en.wikipedia.org/wiki/Enshittification and you better know that you are in it.
당신이 완전히 빠져들고 그들이 완전히 자금이 바닥났을 때, 바로 그때 당신은 자신이 끌려 들어간 긴 사기를 깨닫게 될 것입니다. 바로 이 순간, 그들이 당신에게 알리지 않고 사용 한도를 강화하고 있는데도, 당신은 지금 지불하는 소액이 앞으로도 충분할 거라고 생각합니까? 이것을 https://en.wikipedia.org/wiki/Enshittification 라고 하며, 당신이 그 안에 있다는 것을 알아야 합니다.

Like many of the companies that have gone before them, if / when the value proposition is gone, and I get less than 10x the amount I spend, I will be gone.
그들보다 먼저 간 많은 회사들처럼, 가치 제안이 사라지고 내가 지출한 금액의 10배 미만을 얻는다면, 저는 떠날 것입니다.

----

In this case I'd imagine it's more of an assumption that almost all such subscriptions will have less than 33% utilization, and excepting few outliers, even the heaviest users won't exceed 60-70% utilization on average.
이 경우 거의 모든 구독이 33% 미만의 사용률을 가질 것이라는 가정이 더 크며, 몇몇 예외를 제외하고는 가장 많이 사용하는 사용자도 평균적으로 60-70%의 사용률을 넘지 않을 것이라고 생각합니다.

"33% or less" is, of course, people using a CC subscription only at work. Take an idealized case - using CC only during regular working hours, no overtime: then, even if you use it to the limit all the time, you only use it for 1⁄3 of the day (8h), and 5 days a week - the expected utilization in this scenario is 8/24 × 5/7 = 24%. So you're paying a $200 subscription, but actually getting at most $50 of usage out of it.
"33% 이하"는 물론 CC 구독을 직장에서만 사용하는 사람들을 의미합니다. 이상적인 경우를 가정해보면, 정규 근무 시간 동안만 CC를 사용하고 초과 근무는 하지 않는 경우: 이때, 항상 한도까지 사용하더라도 하루의 1/3(8시간)만 사용하며, 주 5일 근무하므로 이 시나리오에서 예상되는 사용률은 8/24 × 5/7 = 24%입니다. 즉, $200 구독료를 내지만 실제로는 최대 $50어치만 사용하게 되는 셈입니다.

Now, throw in a rate limit that refreshes in periods of 5 hours - a value I believe was carefully chosen to achieve this very effect - and the maximum utilization possible (maxing out limit, waiting for refresh, and maxing out again, in under 8 hours wall-clock time), is still 10 hours equivalent, so 10/24 × 5/7 = 30%. If you just plan to use CC to the first limit and then take meetings for the rest of the day, your max utilization drops to 15%.
이제 5시간 단위로 갱신되는 속도 제한을 추가해보면 — 이 값은 바로 이런 효과를 내기 위해 신중하게 선택된 것으로 보입니다 — 최대 사용 가능량(한도를 최대한 사용하고, 갱신을 기다린 후 다시 최대한 사용, 이 모든 과정이 8시간 이내에 이루어짐)은 여전히 10시간에 해당하므로 10/24 × 5/7 = 30%입니다. 만약 CC를 첫 한도까지만 사용하고 나머지 시간은 회의에 참석할 계획이라면 최대 사용률은 15%로 떨어집니다.

Of course people do overtime, use same subscription for personal stuff after work and on weekends, or just run a business, etc. -- but they also need to eat and sleep, so interactively, you'd still expect them to stay below 75% (83% if counting in 5-hour blocks) total utilization.
물론 사람들은 초과 근무를 하거나, 퇴근 후나 주말에 개인 용도로 같은 구독을 사용하거나, 사업을 운영하는 등 다양한 경우가 있지만, 그들도 식사하고 잠을 자야 하므로 상호작용적으로 볼 때 총 사용률은 여전히 75% 미만(5시간 단위로 계산하면 83%)일 것으로 예상됩니다.

Sharing subscriptions doesn't affect these calculations much - two people maxing out a single subscription is, from the provider side, strictly not greater than two subscriptions with 50% utilization. The math will stop working once a significant fraction of users figure out non-interactive workflows, that run CC 24/7. We'll get there eventually, but we're not there yet. Until then, Anthropic is happy we're all paying $200/month but only getting $50 or less of service out of it.
구독을 공유하는 것은 이러한 계산에 큰 영향을 미치지 않습니다. 한 구독을 두 사람이 최대한 사용하는 것은, 제공자 입장에서는 50% 활용도의 두 구독과 엄격히 동일하거나 그 이하입니다. 상당수 사용자가 24시간 365일 CC를 실행하는 비대화형 워크플로우를 알아내면 이 수학적 계산은 더 이상 맞지 않게 될 것입니다. 결국 그 시점에 도달하겠지만, 아직은 아닙니다. 그때까지 Anthropic은 우리 모두가 월 $200를 지불하지만 서비스는 $50 이하만 받고 있다는 사실에 만족하고 있습니다.

For example, when playing around with claude code using a per token paid API key, it was going to cost ~$50aud a day with pretty general usage.
예를 들어, 토큰당 비용이 부과되는 API 키로 claude code를 사용해보면, 일반적인 사용량으로 하루에 약 $50 AUD가 들었습니다.

But their subscription plan is less than that per month. Them lowering their limits suggests that this wasn't proving profitable at the current limits.
하지만 그들의 구독 요금제는 한 달에 그보다 적습니다. 그들이 제한을 낮춘 것은 현재 제한 내에서 수익성이 없다는 것을 시사합니다.

This is a price to get people hooked up, yes, but also to get them to explore all kinds of weird tricks and wacky workflows, especially ones that are prohibitively costly when billed per token. In some sense, this is crowdsourcing R&D - and then when Opus 7 or whatever comes along to take advantage of best practices people worked out, and that turns out to be good enough to replace your $150k/yr / $12.5k/mo employee - then they'll jack up prices to $10k/month or whatever.
이 가격은 사람들이 서비스를 시작하도록 유도하는 것이기도 하지만, 특히 토큰별 과금 시 비용이 너무 많이 드는 이상한 트릭과 기발한 워크플로우를 탐색하도록 유도하는 목적도 있습니다. 어떤 면에서는 이것이 크라우드소싱 R&D와 같으며, 이후 Opus 7 같은 버전이 등장해 사람들이 찾아낸 모범 사례를 활용하고, 그 결과 연 15만 달러 / 월 12,500달러짜리 직원을 대체할 만큼 충분히 좋아지면 가격을 월 1만 달러 등으로 올릴 것입니다.

Seems tangential? Price entirely depends on what consumers/businesses willing to pay and the degree of competition
관련 없는 것 같네요? 가격은 전적으로 소비자/기업이 지불할 의사와 경쟁 정도에 달려 있습니다

Based on my experience with Claude Code (which is relatively good TBH), I'd say good luck with that.
제 경험상 Claude Code(솔직히 꽤 괜찮음)로 보면, 행운을 빕니다.

The fact they declared their own project as “impossible to advance” given the situation reveals they are unwilling to go the thinking route right now.
그들이 자신의 프로젝트를 “진전시키기 불가능하다”고 선언한 사실은 현재로서는 생각하는 방향으로 나아가려 하지 않는다는 것을 보여줍니다.

I'm surprised, but know I shouldn't be, that we're at this point already.
놀랍지만, 이미 이 지점에 와 있다는 사실에 놀라지 말아야 한다는 것을 압니다.

Don't feel sorry for me, I've used vibe coding to create many things, and I still know how to program, so I'll live if it goes away.
저를 안타까워하지 마세요. 저는 vibe 코딩으로 많은 것을 만들어봤고, 여전히 프로그래밍할 줄 알기 때문에 사라져도 잘 살아갈 겁니다.

Its gotten so bad I'm actively trying to avoid talking about this in circles like Hacker News because people get so heavily and aggressively discredited and ridiculed as if they have no idea what they are doing or are a shill for big AI companies.
상황이 너무 심각해져서, 사람들이 자신들이 무슨 일을 하는지 전혀 모르는 것처럼 혹은 대형 AI 회사의 대변인인 것처럼 심하게 공격받고 조롱당하는 것을 보면서, Hacker News 같은 곳에서 이런 이야기를 반복적으로 하는 것을 적극적으로 피하려고 합니다.

I know what I'm doing and actively try to help friends and co-workers use LLMs in a sustainable way, understanding their limitations and the dangers of letting them loose without staying in the loop. Its sad that I can't talk about this without fear of being attacked, especially in communities like Hacker News that I previously valued as being very professional and open, compared to other modern social media.
저는 제가 하는 일을 잘 알고 있으며, 친구들과 동료들이 LLMs를 지속 가능하게 사용할 수 있도록 그 한계와 통제 없이 방치할 때의 위험성을 이해시키며 적극적으로 돕고 있습니다. 특히 이전에 매우 전문적이고 개방적이라고 평가했던 Hacker News 같은 커뮤니티에서조차 공격받을 두려움 없이 이 이야기를 할 수 없다는 것이 안타깝습니다. 다른 현대 소셜 미디어와 비교해도 말이죠.

Its not, but it does matter. LLMs, being next word guessers, perform differently with different inputs. Its not hard to imagine a feedback loop of bad code generating worse code and good code generating more good code.
그렇지는 않지만, 중요하긴 하다. LLMs는 다음 단어를 예측하는 모델이기 때문에 입력에 따라 성능이 달라진다. 나쁜 코드가 더 나쁜 코드를 생성하고 좋은 코드가 더 좋은 코드를 생성하는 피드백 루프를 상상하는 것은 어렵지 않다.

My ability to get good responses from LLMs has been tied to me writing better code, docstrings, and using autoformatters.
내가 LLMs로부터 좋은 응답을 얻는 능력은 더 나은 코드 작성, 도큐스트링 작성, 그리고 자동 포매터 사용과 연결되어 있다.

The only thing standing between your LLM and bad code is the quality of the prompt (including context and the hiddem OEM prompt).
당신의 LLM과 나쁜 코드 사이에 있는 유일한 것은 프롬프트의 품질(컨텍스트와 숨겨진 OEM 프롬프트 포함)입니다.

The whole value proposition of a Max subscription is that it lets you stop worrying about tokens (Claude Code literally tells you so if you type `/cost` while authenticated with a subscription). So I'd turn around and say, people who don't regularly hit usage limits aren't using Claude Code properly - they're not utilizing it in full.
Max 구독의 전체 가치 제안은 토큰 걱정을 멈출 수 있게 해준다는 점입니다(Claude Code는 구독 인증 상태에서 `/cost`를 입력하면 이를 명확히 알려줍니다). 그래서 저는 이렇게 말하고 싶습니다. 정기적으로 사용 한도에 도달하지 않는 사람들은 Claude Code를 제대로 사용하지 않는 것입니다 - 그들은 그것을 완전히 활용하지 않고 있습니다.

--

Myself, I'm only using Claude Code for little R&D and some side projects, but I upgraded from Max x5 to Max x20 on the second day, as it's trivial to hit the Max x5 limit in a regular, single-instance chat. And that's without any smarts, just a more streamlined flavor of good ol' basic chat experience.
저는 개인적으로 Claude Code를 소규모 연구개발과 몇 가지 부가 프로젝트에만 사용하지만, 일반적인 단일 인스턴스 채팅에서 Max x5 한도에 도달하는 것이 너무 쉬워서 둘째 날에 Max x5에서 Max x20으로 업그레이드했습니다. 그리고 이는 특별한 기술 없이, 단지 기본 채팅 경험을 좀 더 간소화한 버전일 뿐입니다.

But then I look around, and see people experiment with more complex approaches. They run 4+ instances in parallel to work on more things at a time. They run multiple instances in parallel to get multiple solutions to the same task, and then mix them into a final one - possibly with help of yet another instance. They have the agent extensively research a thing before doing it, and then extensively validate it afterwards. And so on. Any single one of such tricks/strategies is going to make hitting limits on Max x20 a regular occurrence again.
하지만 주변을 살펴보면, 더 복잡한 접근 방식을 실험하는 사람들을 볼 수 있습니다. 그들은 한 번에 더 많은 작업을 처리하기 위해 4개 이상의 인스턴스를 병렬로 실행합니다. 동일한 작업에 대해 여러 인스턴스를 병렬로 실행하여 여러 해답을 얻고, 이를 또 다른 인스턴스의 도움을 받아 최종 결과물로 혼합하기도 합니다. 에이전트가 작업을 수행하기 전에 광범위하게 조사하고, 작업 후에도 철저히 검증하게 합니다. 이런 식의 트릭이나 전략 중 어느 하나만 사용해도 Max x20 제한에 자주 걸리게 될 것입니다.

They've just done the work to tailor it specifically for proper tool using during coding. Once other models catch up, they will not be able to be so stingy on limits.
그들은 단지 코딩 중 적절한 도구 사용에 맞게 특별히 조정하는 작업을 해왔을 뿐입니다. 다른 모델들이 따라잡으면, 제한을 이렇게 인색하게 둘 수 없게 될 것입니다.

Google has the advantage here given they're running on their own silicon; can optimize for it; and have nearly unlimited cashflows they can burn.
Google은 자체 실리콘에서 실행하고 최적화할 수 있으며, 거의 무한한 현금 흐름을 태울 수 있다는 점에서 이점이 있습니다.

I find it amusing nobody here in the comments can understand the scaling laws of compute. It seems like people have a mental model of Uber burned into their head thinking that at some point the price has to go up. AI is not human labor.
댓글에서 아무도 컴퓨팅의 스케일링 법칙을 이해하지 못하는 게 재미있네요. 사람들은 언젠가는 가격이 올라야 한다는 생각을 우버 모델에 고정시킨 것 같습니다. AI는 인간 노동이 아닙니다.

Over time the price of compute will fall, not rise. Losing money in the short term betting this will happen is not a dumb strategy given it's the most likely scenario.
시간이 지남에 따라 컴퓨팅 비용은 오르지 않고 떨어질 것입니다. 단기적으로 이 일이 일어날 것에 베팅해 손해를 보는 것은 가장 가능성 높은 시나리오이기 때문에 어리석은 전략이 아닙니다.

I know everybody really wants this bubble to pop so they can make themselves feel smart for "calling it" (and feel less jealous of the people who got in early) and I'm sure there will be a pop, but in the long term this is all correct.
모두가 이 거품이 터지길 바라는 이유는 자신이 "예측했다"고 똑똑해 보이고 싶어서(그리고 일찍 진입한 사람들을 덜 부러워하기 위해서)인 걸 알지만, 분명히 거품은 터질 것이고 장기적으로는 이 모든 것이 맞습니다.

Are they really ready to burn money for 8 years?
그들이 정말로 8년 동안 돈을 태울 준비가 되어 있을까?

Amazon operated at a loss for 9 years, and barely turned a profit for over a decade longer than that. They're now one of the greatest businesses of all time.
아마존은 9년 동안 적자를 냈고, 그 이후로도 10년 넘게 간신히 수익을 냈다. 지금은 역대 최고의 기업 중 하나다.

Spotify operated at a loss for 17 years until becoming profitable. Tesla operated at a loss for 17 years before turning a profit. Palantir operated at a loss for 20 years before turning a profit.
스포티파이는 17년 동안 적자를 내다가 수익을 내기 시작했다. 테슬라도 17년 동안 적자를 내다가 수익을 냈다. 팔란티어는 20년 동안 적자를 내다가 수익을 냈다.

And this was before the real age of Big Tech. Google has more cashflows they can burn than any of these companies ever raised, combined.
그리고 이것은 빅테크의 진정한 시대가 오기 전의 일이었습니다. 구글은 이들 모든 회사가 합쳐서 모은 자금보다 더 많은 현금 흐름을 태울 수 있습니다.

Amazon pivoted to a totally different business that was profitable from the get-go.
아마존은 처음부터 수익성이 있는 완전히 다른 사업으로 전환했습니다.

Google became profitable within a couple of years of starting and went into the black on total lifetime spend almost immediately. As was normal, back then.
구글은 시작한 지 몇 년 만에 수익을 내기 시작했고, 총 누적 지출 대비 거의 즉시 흑자로 전환했습니다. 그 당시에는 이것이 일반적이었습니다.

Uber operated at a loss to destroy competition and raised prices after they did that.
우버는 경쟁을 무너뜨리기 위해 손실을 감수했고, 그 후에 가격을 인상했습니다.

Amazon (the retailer) did the same and leveraged their position to enter new more lucrative markets.
아마존(소매업체)도 마찬가지로 행동했으며, 그들의 위치를 활용해 더 수익성 높은 새로운 시장에 진입했습니다.

Dunno about Spotify, but Tesla and palantir both secured lucrative contracts and subsidies.
스포티파이에 대해서는 잘 모르겠지만, 테슬라와 팔란티어는 모두 수익성 높은 계약과 보조금을 확보했습니다.

Anthropic is against companies with deeper pockets and can’t spend to destroy competition, their current business model can only survive if they reduce costs or raise prices. Something’s got to give
Anthropic은 자금력이 더 풍부한 기업들과 경쟁하는 것을 반대하며, 경쟁을 파괴할 만큼 지출할 수 없습니다. 현재 비즈니스 모델은 비용을 줄이거나 가격을 인상해야만 생존할 수 있습니다. 무언가 변화가 필요합니다.

Re: Anthropic specifically, I tend to agree, hence why I'm saying the deeper pockets (eg. Google, Amazon, etc) are perfectly positioned to win here. However, big companies have a way of consistently missing the future due to internal incentive issues. Google is deathly afraid of cannibalizing their existing businesses.
Anthropic에 관해서는 저도 동의하는 편입니다. 그래서 자금력이 더 풍부한 기업들(예: Google, Amazon 등)이 이길 가능성이 크다고 말하는 것입니다. 하지만 대기업들은 내부 인센티브 문제로 인해 미래를 지속적으로 놓치는 경향이 있습니다. Google은 기존 사업을 잠식하는 것을 극도로 두려워합니다.

Plus, there's many investors with deep pockets who would love to get in on Anthropic's next round if their technical lead proves to be durable over time (like 6 months in AI terms).
게다가, 기술적 우위가 시간이 지나도(AI 기준으로 6개월 정도) 견고하다는 것이 입증된다면, Anthropic의 다음 투자 라운드에 참여하고 싶어하는 자금력이 풍부한 투자자들이 많이 있습니다.

This fight is still early innings.
이 싸움은 아직 초반입니다.

And I like Anthropic, I want them to be successful, but they just can’t operate at a loss like this for long, they have to make some tough calls, and trying to cut corners behind the scenes is not good for long term trust
저는 Anthropic을 좋아하고 그들이 성공하기를 바라지만, 이렇게 손실을 감수하며 오래 운영할 수는 없습니다. 그들은 어려운 결정을 내려야 하며, 뒤에서 편법을 쓰려는 시도는 장기적인 신뢰에 좋지 않습니다.

Small models have also been improving steadily in ability, so it is feasible that a task that needs Claude Opus today could be done by Sonnet in a year's time. This trend of model "efficiency" will add on top of compute getting cheaper.
작은 모델들도 능력이 꾸준히 향상되고 있어서, 오늘날 Claude Opus가 필요한 작업이 1년 후에는 Sonnet으로도 가능해질 수 있습니다. 이러한 모델 "효율성"의 증가는 컴퓨팅 비용 감소와 더불어 이루어질 것입니다.

Although, that efficiency would probably be quickly eaten up by increased appetites for higher performance, bigger, models.
하지만 그 효율성은 아마도 더 높은 성능과 더 큰 모델에 대한 수요 증가로 인해 금방 소모될 가능성이 큽니다.

Among private users willing to pay $200/month average usage is likely very high, but if Anthropic can convince companies to buy plans for entire departments average usage will be much lower on those.
월 200달러를 지불할 의향이 있는 개인 사용자들 사이에서는 평균 사용량이 매우 높을 가능성이 크지만, Anthropic이 기업들이 부서 전체를 위해 요금제를 구매하도록 설득할 수 있다면 그 부서들의 평균 사용량은 훨씬 낮을 것이다.

Another issue is that $4000 costs is assuming the regular API is offered at cost, which is unlikely to be true.
또 다른 문제는 4000달러 비용이 일반 API가 원가로 제공된다는 가정 하에 계산된 것인데, 이는 사실일 가능성이 낮다.

I don't subscribe to the $100 a month plan, I am paying API usage pricing. Accordingly I have learned how to be much more careful with Claude Code than I think other users are. The first day I used it, Claude got stuck in a loop trying to fix a problem using the same 2 incorrect solutions again and again and burnt through $30 of API credits before I realized things were very wrong and I stopped it.
저는 월 100달러 요금제에 가입하지 않고 API 사용량에 따른 요금을 지불하고 있습니다. 그래서 다른 사용자들보다 Claude Code를 훨씬 더 신중하게 다루는 법을 배웠습니다. 처음 사용한 날, Claude가 같은 두 가지 잘못된 해결책을 반복해서 문제를 해결하려고 무한 루프에 빠졌고, 상황이 매우 잘못됐다는 것을 깨닫고 중단하기 전까지 API 크레딧 30달러를 소진했습니다.

Ever since then I've been getting away with $3-$5 of usage per day, and accomplishing a lot.
그 이후로는 하루에 3~5달러 정도의 사용량으로 많은 일을 해내고 있습니다.

Anthropic needs to find a way to incentivize developers to better use Claude Code, because when it goes off the rails, it really goes off the rails.
Anthropic은 개발자들이 Claude Code를 더 잘 활용하도록 동기를 부여할 방법을 찾아야 합니다. 왜냐하면 문제가 생기면 정말 심각하게 꼬이기 때문입니다.

The worse it performs, the more you pay. That’s a hell of a business model. Will users tolerate that for long?
성능이 나쁠수록 더 많은 비용을 지불하게 됩니다. 정말 기가 막힌 비즈니스 모델이네요. 사용자가 그걸 오래 참을까요?

I mean, AWS seems to be doing fine with that business model.
제 말은, AWS는 그 비즈니스 모델로 잘 운영되고 있는 것 같다는 겁니다.

Currently it's much more important to manage context, split tasks, retry when needed, not getting stuck in an infinite loop, expose the right tools (but not too many), ...
현재는 컨텍스트를 관리하고, 작업을 분할하며, 필요할 때 재시도하고, 무한 루프에 빠지지 않도록 하는 것이 훨씬 더 중요하며, 적절한 도구를 제공하는 것(하지만 너무 많지는 않게)도 중요합니다.

Industries can often get away with polluting when they're small, but once they reach planet scale salting the earth behind you is not as reliable of a tactic.
산업이 작을 때는 오염을 무사히 넘어갈 수 있지만, 지구 규모에 이르면 뒤에 땅을 소금으로 뒤덮는 전략은 그리 신뢰할 만한 전술이 아닙니다.

The NLP these models can do is definitely impressive, but they aren't 'thinking'. I find myself easily falling into the habit of filtering a lot of what the model returns and picking out the good parts which is useful and relatively easy for subjects I know well. But for a topic that I am not as familiar with, that filtering (identifying and dismissing) I do is much less finessed, and a lot of care needs to be taken to not just accept what is being presented. You can still interrogate each idea presented by the LLM to ensure you aren't being led astray, and that is still useful for discovering things, like traditional search, but once you mix agents into this, things can go off the rails far too quickly than I am comfortable with.
이 모델들이 할 수 있는 NLP는 확실히 인상적이지만, 이들이 '생각'하는 것은 아닙니다. 저는 모델이 반환하는 많은 결과를 필터링하고 유용한 좋은 부분만 골라내는 습관에 쉽게 빠지는데, 이는 제가 잘 아는 주제에 대해서는 상대적으로 쉽고 유용합니다. 하지만 익숙하지 않은 주제에 대해서는 그 필터링(식별하고 무시하는 과정)이 훨씬 덜 세련되어 있고, 단순히 제시된 내용을 받아들이지 않도록 많은 주의가 필요합니다. 여전히 LLM이 제시하는 각 아이디어를 면밀히 검토하여 잘못된 방향으로 이끌리지 않도록 할 수 있으며, 이는 전통적인 검색처럼 무언가를 발견하는 데 여전히 유용합니다. 하지만 여기에 에이전트를 섞으면 상황이 제가 편안하게 느끼는 것보다 훨씬 빠르게 엉망이 될 수 있습니다.

To me it seems that they are all converging over time. So what if one is "better"[1]? The others will soon be there too.
저에게는 시간이 지남에 따라 모두 수렴하는 것처럼 보입니다. 그렇다면 하나가 "더 낫다"[1]고 해도 무슨 상관일까요? 다른 것들도 곧 그 수준에 도달할 것입니다.

[1] My experience with them is that Claude (Opus) is only slightly better than the competition at coding; it might do a better job on 2 out of every 5 tasks than the competition, but those people using the competition still get those two tasks done anyway.
[1] 제 경험으로는 Claude(Opus)가 코딩 면에서 경쟁 제품보다 약간 더 낫습니다; 5개의 작업 중 2개에서 경쟁 제품보다 더 잘할 수 있지만, 경쟁 제품을 사용하는 사람들도 어쨌든 그 두 작업을 완료합니다.

I couldn't believe how many requests I could get in. I wasn't using this full-time for an entire workweek, but I thought for sure I'd be running into the $20/month limits quickly. Yet I never did.
얼마나 많은 요청을 할 수 있는지 믿기 어려웠습니다. 저는 이걸 전업으로 일주일 내내 사용한 건 아니었지만, 분명히 $20/월 한도에 금방 도달할 거라고 생각했어요. 그런데 전혀 그렇지 않았습니다.

To be fair, I spent a lot of time cleaning up after the AI and manually coding things it couldn't figure out. It still seemed like an incredible number of tokens were being processed. I don't have concrete numbers, but it felt like I was easily getting $10-20 worth of tokens (compared to raw API prices) out of it every single day.
공정하게 말하자면, 저는 AI가 해결하지 못한 부분을 정리하고 수동으로 코딩하는 데 많은 시간을 썼습니다. 그럼에도 불구하고 처리되는 토큰 수가 엄청난 것 같았습니다. 구체적인 수치는 없지만, 매일 쉽게 $10-20 상당의 토큰(원시 API 가격과 비교했을 때)을 사용하고 있는 느낌이었습니다.

My guess is that they left the limits extremely generous for a while to promote adoption, and now they're tightening them up because it’s starting to overwhelm their capacity.
제 추측으로는, 채택을 촉진하기 위해 한동안 제한을 매우 관대하게 두었고, 이제는 용량이 감당하기 어려워지기 시작해서 제한을 강화하는 것 같습니다.

I can't imagine how much vibe coding you'd have to be doing to hit the limits on the $200/month plan like this article, though.
하지만 이 기사에서처럼 $200/월 요금제의 제한에 도달하려면 얼마나 많은 vibe 코딩을 해야 할지 상상이 안 갑니다.

In my experiments, it would be enormously wasteful in token usage, doing things like re-reading all Python scripts in the current folder just to make sure all comments were up-to-date, or it re-read an R script to make sure all brackets were closed correctly. Surely that's where a good chunk of the waste comes from?
내 실험에서는 현재 폴더의 모든 Python 스크립트를 다시 읽어 모든 주석이 최신인지 확인하거나, R 스크립트를 다시 읽어 모든 괄호가 올바르게 닫혔는지 확인하는 등 토큰 사용이 엄청나게 낭비되었다. 분명히 그게 낭비의 큰 부분일 것이다.

If you think a lot, you can spend hundreds of dollars easily.
많이 생각하면 수백 달러를 쉽게 쓸 수 있습니다.

Think beyond just saying "do this one thing".
단순히 "이 한 가지를 해라"라고 말하는 것 이상을 생각하세요.

What do you do for hours?
몇 시간 동안 무엇을 하시나요?

If all you're thinking about is code output, you're thinking too small.
만약 당신이 오직 코드 출력만 생각하고 있다면, 너무 좁게 생각하는 것입니다.

https://www.anthropic.com/news/claude-4

It was given a task and it solved a problem by operating for 7 hours straight.
한 작업을 부여받아 7시간 연속으로 작동하며 문제를 해결했습니다.

Your key objective is to fix a bug in the XYAZ class. Use a team of experts as sub-agents to complete the analysis, debugging and triage work for you. Delegate to them, you are the manager and orchestrator of this work.
당신의 주요 목표는 XYAZ 클래스의 버그를 수정하는 것입니다. 전문가 팀을 하위 에이전트로 활용하여 분석, 디버깅 및 분류 작업을 완료하세요. 이 작업을 위임하고, 당신은 이 작업의 관리자이자 조율자입니다.

As you delegate work, review and approve/reject their work as needed. Continue to refine until you are confident you have found a simple and robust fix"
작업을 위임하면서 필요에 따라 그들의 작업을 검토하고 승인하거나 거부하세요. 간단하고 견고한 수정안을 찾았다고 확신할 때까지 계속 다듬으세요."

Anecdata, but it weirdly helped me. Seemed BS for me until I tried.
개인적인 경험이지만, 이상하게도 저한테는 도움이 됐어요. 시큰둥했는데 직접 써보니 효과가 있더라고요.

Maybe because good code is contextual? Sample codes to explain concepts may be simpler than a production ready code. The model may have the capability to do both but can't properly disguished the correct thing to do.
아마도 좋은 코드는 상황에 따라 다르기 때문일까요? 개념을 설명하는 샘플 코드는 실제 배포용 코드보다 더 단순할 수 있잖아요. 모델은 둘 다 할 수 있는 능력이 있지만, 올바른 선택을 제대로 구분하지 못하는 것 같아요.

I don't know.  모르겠어요.

I'm paying for Max, and when I use the tooling to calculate the spend returned by the API, I can see it's almost $1k! I have no idea how much quota I have left until the next block. The pricing returned by the API doesn't make any sense.
저는 Max 요금제를 사용 중인데, API가 반환하는 사용 금액을 계산하는 도구를 사용해 보니 거의 1,000달러에 육박하더군요! 다음 차단 시점까지 남은 할당량이 얼마나 되는지 전혀 알 수 없습니다. API가 반환하는 가격 정보는 전혀 이해가 되지 않습니다.

I hire someone for say £5K/mo. They then spend $200/mo or is it a $1000/wk on Claude or whatevs.
나는 누군가를 월 5천 파운드에 고용한다. 그들이 Claude나 뭐든지에 월 200달러, 아니면 주당 1000달러를 쓰는 거다.

Profit!  이익!

Known as the Uber model or Amazon vs Diapers.com
우버 모델 또는 Amazon 대 Diapers.com으로 알려져 있습니다.

To be fair that was a little different; Amazon wanted to buy the parent company of Diapers.com so sold at a loss to tank the value of the company so they could buy it cheap.
공정하게 말하면 그건 좀 달랐습니다; Amazon은 Diapers.com의 모회사를 인수하려고 했기 때문에 회사를 싸게 사기 위해 손해를 보면서 가치를 떨어뜨렸습니다.

I’ll assuming this is real and not trolling. Who are the customers? What kind of people spend that much? I know people using $200-300 models but this is 10x that!
이게 진짜라고 가정하고 장난이 아니라고 할게요. 고객이 누구죠? 누가 그렇게 많은 돈을 쓰나요? 저는 200~300달러 모델을 사용하는 사람들은 알지만, 이건 그 10배나 되네요!

What do you mean? That’s totally a good reason to be pissed off at them. I’m so tired of products that launch before they have a clear path to profitability.
무슨 뜻이야? 그건 그들에게 화낼 충분한 이유야. 수익성 있는 명확한 경로도 없이 출시되는 제품들에 너무 지쳤어.

And I was thinking to myself, “How does this make any sense financially for Anthropic to let me have all of this for $200/month?”
그리고 저는 속으로 “Anthropic이 어떻게 이 모든 것을 $200/월에 제공하는 게 재정적으로 말이 되지?”라고 생각하고 있었어요.

And then I kept getting hit with those overloaded api errors so I canceled my plan and went back to API tokens.
그런데 계속 과부하된 API 오류가 발생해서 요금제를 취소하고 다시 API 토큰으로 돌아갔어요.

I still have no idea what they’re doing over there but I’ll happily pay for access. Just stop dangling that damn $200/month in my face if you’re not going to honor it with reasonable access.
저쪽에서 뭘 하는지 아직도 전혀 모르겠지만, 접근 권한에 대해 기꺼이 비용을 지불할 의향은 있습니다. 합리적인 접근 권한 없이 $200/월 요금제를 내 앞에서 흔들지 말아 주세요.

Interestingly, it came up with some definitions of abbreviations and slightly different ways to do things using confidential APIs that have been sort of reverse engineered in public but are not fully understood. Which to me was the most interesting. The things it suggested related to that are very plausible and I was trying to decide if it was clever hallucinations or because it's being used/trained on code bases at that company or by others who have better access. So I spent a lot of time googling to see if it had found some publicly available info to confirm.
흥미롭게도, 약어의 몇 가지 정의와 공개적으로 어느 정도 역공학된 비밀 API를 사용하여 약간 다른 방식으로 작업하는 방법을 제시했습니다. 하지만 이 API들은 완전히 이해되지는 않은 상태입니다. 저에게 가장 흥미로웠던 점은 바로 그 부분이었습니다. 그와 관련해 제안한 내용들은 매우 그럴듯했으며, 그것이 영리한 환각인지 아니면 그 회사나 더 나은 접근 권한을 가진 다른 사람들이 사용하는/학습시키는 코드베이스 때문인지 판단하려고 했습니다. 그래서 공개적으로 이용 가능한 정보를 찾았는지 확인하기 위해 구글링에 많은 시간을 썼습니다.

Anyway after I hit $5 I subscribed to pro to continue the playing but /cost won't tell you anything useful after switching to pro.
어쨌든 $5를 사용한 후에 계속 사용하려고 프로 구독을 했는데, 프로로 전환한 후에는 /cost가 아무 쓸모 있는 정보를 알려주지 않습니다.

I also wanted to try Gemini clinto compare but I couldn't figure out how to actually give Google my money. Why is Google so impossible to use.
저는 Gemini 클린토도 비교해보고 싶었는데, 구글에 실제로 돈을 어떻게 내야 하는지 도저히 알 수가 없었습니다. 왜 구글은 이렇게 사용하기 어려운 걸까요.

I find sonnet really useful for coding but I never even hit basic limits. at $20/mo. Writing specs, coming up with documentation, doing wrote tasks for which many examples exist in the database. Iterate on particular services etc.
저는 sonnet이 코딩에 정말 유용하다고 생각하지만 기본 한도조차도 한 번도 넘은 적이 없습니다. 월 $20에 사양 작성, 문서 작성, 데이터베이스에 이미 많은 예제가 있는 반복 작업 수행, 특정 서비스에 대한 반복 작업 등을 합니다.

Are these max users having it write the whole codebase w/ rewrites? Isn't it often just faster to fix small things I find incorrect than type up why I think it's wrong in English and have it do a whole big round trip?
이 최대 사용자들이 전체 코드베이스를 다시 작성하면서 작업하는 건가요? 제가 잘못됐다고 생각하는 부분을 영어로 설명하고 전체 큰 작업을 시키는 것보다, 작은 문제를 직접 고치는 게 더 빠른 경우가 많지 않나요?

I have two big workflows: plan and implement. Plan follows a detailed workflow to research an idea and produce a planning document for how to implement it. This routinely takes $10-30 in API credits to run in the background. I will then review this 200-600 line document and fix up any mistakes or remove unnecessary details.
나는 두 가지 큰 워크플로우가 있어: 계획과 구현. 계획은 아이디어를 조사하고 구현 방법에 대한 계획 문서를 만드는 상세한 워크플로우를 따르지. 이 과정은 보통 백그라운드에서 $10~30의 API 크레딧이 소모돼. 그런 다음 200~600줄짜리 문서를 검토하며 실수를 수정하거나 불필요한 세부사항을 제거하지.

Then implement is usually cheaper, and it will take that big planning document, make all the changes, and then make a PR in GitHub for me to review. This usually costs $5-15 in API credits.
그런 다음 구현은 보통 더 저렴하며, 그 큰 기획 문서를 가져와서 모든 변경 사항을 적용한 후, 제가 검토할 수 있도록 GitHub에 PR을 만듭니다. 보통 이 과정은 API 크레딧으로 $5-15 정도 듭니다.

All it takes is for me to do 3-4 of these in one 5-hour block and I will hit the rate-limit of the $100 Max plan. Setting this up made me realise just how much scaffolding you can give to Opus and it handles it like a champ. It is an unbelievably reliable model at following detailed instructions.
한 5시간 동안 3~4번만 이런 작업을 하면 $100 Max 플랜의 속도 제한에 걸려. 이걸 설정하면서 Opus에 얼마나 많은 스캐폴딩을 제공할 수 있는지 깨달았고, Opus는 이를 훌륭하게 처리해. 매우 상세한 지시도 믿을 수 없을 만큼 잘 따르는 모델이야.

It is rare that I would hit the rate-limits if I am just using Claude Code interactively, unless I am using it constantly for hours at a time, which is rare. Seems like vibe coders are the main people who would hit them regularly.
Claude Code를 단순히 대화형으로 사용할 때는 몇 시간씩 계속 사용하지 않는 이상 속도 제한에 걸리는 경우가 드물어. 주로 vibe 코더들이 정기적으로 제한에 걸리는 것 같아.

Whenever I use it, I typically do much smaller asks, eg “add a button here”, “make that button trigger a refresh with a filter of such state…”
제가 사용할 때는 보통 훨씬 작은 요청을 합니다. 예를 들어 “여기에 버튼 추가해줘”, “그 버튼이 특정 상태의 필터로 새로고침을 트리거하게 만들어줘” 같은 요청들입니다.

I have also used this for creating new UI components or admin pages. One thing I have noticed is that the planning step is pretty good at searching through existing UI components to follow their patterns to maintain consistency. If I just asked Claude to make the change straight away, it often won't follow the patterns of our codebase.
저는 이 방법을 새 UI 컴포넌트나 관리자 페이지를 만들 때도 사용했습니다. 한 가지 눈에 띄는 점은 계획 단계가 기존 UI 컴포넌트를 검색하여 그 패턴을 따르도록 하는 데 꽤 효과적이라는 것입니다. 만약 바로 Claude에게 변경을 요청하면, 종종 우리 코드베이스의 패턴을 따르지 않습니다.

But for UI components, adding new pages, or things like that, it is usually more useful just as a starting point and I will often need to go in and tweak things from there. But often it is a pretty good starting point. And if it's not, I can just discard the changes anyway.
하지만 UI 컴포넌트나 새 페이지 추가 같은 경우에는 보통 시작점으로서 더 유용하며, 그 후에 직접 수정할 필요가 자주 있습니다. 하지만 대체로 꽤 좋은 출발점이 됩니다. 만약 그렇지 않더라도 변경 사항을 그냥 버릴 수 있습니다.

I find this is not worth it for very small tasks though, like adding a simple button or making a small behaviour change to a UI component. It will usually overcomplicate these small tasks and add in big testing rigs or performance optimisations, or other irrelevant concerns. It is like it doesn't want to produce a very short plan. So, for things like this I will use Claude interactively, or just make the change manually. Honestly, even if it did do a good job at these small tasks, it would still seem like overkill.
하지만 간단한 버튼 추가나 UI 컴포넌트의 작은 동작 변경 같은 아주 작은 작업에는 이 방법이 가치가 없다고 느낍니다. 보통 이런 작은 작업을 과도하게 복잡하게 만들고, 큰 테스트 환경이나 성능 최적화, 혹은 다른 관련 없는 문제들을 추가하는 경향이 있습니다. 매우 짧은 계획을 만들고 싶어하지 않는 것 같습니다. 그래서 이런 경우에는 Claude를 대화형으로 사용하거나 그냥 수동으로 변경합니다. 솔직히, 설령 이런 작은 작업을 잘 처리한다고 해도 여전히 과잉 대응처럼 보일 것입니다.

https://github.com/shepherdjerred/scout-for-lol/blob/6c6a3ca...

K&R C is underspecified. And anyone who whines about AI code quality? Hold my beer, look at our 1980's source.
K&R C는 명세가 부족합니다. 그리고 AI 코드 품질에 대해 불평하는 사람이 있다면? 제 맥주를 잡고 우리 1980년대 소스를 한번 보세요.

I routinely have a task manager feed eight parallel Claude Code Opus 4 sessions their next source file to study for a specific purpose, to get through all 57 faster. That will hit my $200 Max limit, reliably.
저는 정기적으로 작업 관리자에게 8개의 병렬 Claude Code Opus 4 세션에 특정 목적을 위해 다음에 공부할 소스 파일을 제공합니다. 57개를 모두 빠르게 처리하기 위해서입니다. 이 작업은 제 $200 최대 한도에 안정적으로 도달할 것입니다.

Of course I should just wait a year, and AI will read the code base all at once. People _talk_ like it does now. It doesn't. Filtering information is THE critical issue for managing AI in 2025.
물론 1년만 기다리면 AI가 코드 베이스를 한 번에 읽을 것입니다. 사람들은 지금도 그렇게 _말_ 합니다. 하지만 그렇지 않습니다. 정보를 필터링하는 것이 2025년 AI 관리를 위한 가장 중요한 문제입니다.

The most useful tool I've written to support this effort is a tmux interface, so AI and I can debug together two terminal sessions at once: The old 32-bit code running on a Linode instance, and the new 64-bit code running locally on macOS. I wasn't happy with how the tools for this worked, that I could find online. It blows my mind to watch Opus 4 debug.
이 노력을 지원하기 위해 제가 작성한 가장 유용한 도구는 tmux 인터페이스입니다. 그래서 AI와 제가 동시에 두 개의 터미널 세션을 함께 디버깅할 수 있습니다: Linode 인스턴스에서 실행 중인 오래된 32비트 코드와 macOS에서 로컬로 실행 중인 새로운 64비트 코드입니다. 온라인에서 찾을 수 있는 도구들이 마음에 들지 않았습니다. Opus 4를 디버깅하는 모습을 보는 것은 정말 놀랍습니다.

I often find my plans for the code changing as I get into implementation. I wonder if giving the model explicit permission to change the plan would work or cause it to go off the rails for big chunks of work like this.
코드를 구현하면서 계획이 자주 바뀌는 것을 경험합니다. 모델에게 명시적으로 계획 변경 권한을 주는 것이 효과가 있을지, 아니면 이렇게 큰 작업에서는 계획이 완전히 엇나가게 만들지 궁금하네요.

The implement prompt doesn't seem to matter as much: https://gist.github.com/Sothatsit/bdf2cf4ed7c319e2932a5d2d8d...
구현 프롬프트는 그렇게 중요하지 않은 것 같습니다: https://gist.github.com/Sothatsit/bdf2cf4ed7c319e2932a5d2d8d...

Creating these was basically just a workflow of writing out a workflow myself, getting Opus to refine it, then back to me, then back to Opus until it was something I was happy with. There is probably a lot more refining you could do with it, but it works pretty well as it is right now.
이것들을 만드는 과정은 기본적으로 제가 직접 워크플로우를 작성하고, Opus가 이를 다듬고, 다시 저에게 돌아오고, 다시 Opus로 돌아가는 과정을 반복하며 만족할 만한 결과가 나올 때까지 진행하는 워크플로우였습니다. 아마 더 많은 다듬기가 가능하겠지만, 현재 상태로도 꽤 잘 작동합니다.

I then have wrapper scripts that invoke these using claude -p in a container, but those are pretty specific to my codebase.
그런 다음 claude -p를 사용해 컨테이너 내에서 이를 호출하는 래퍼 스크립트가 있는데, 이들은 제 코드베이스에 꽤 특화되어 있습니다.

This is my experience: at some point the AI isn't converging to a final solution and it's time to finish the rest by hand.
제 경험상: 어느 시점부터 AI가 최종 해결책에 수렴하지 않고, 나머지는 직접 마무리할 때가 됩니다.

If you find yourself going back and forth with the AI, you're probably not saving time over a traditional google search
AI와 계속 왔다 갔다 한다면, 전통적인 구글 검색보다 시간을 절약하지 못하는 경우일 가능성이 큽니다.

Edit: and it basically never oneshots anything correctly
수정: 그리고 기본적으로 어떤 것도 한 번에 제대로 처리하지 못한다

One day my very first prompt in the morning was blocked. Super strange.
어느 날 아침에 처음으로 보낸 프롬프트가 차단되었어요. 정말 이상하네요.

I'd be extremely surprised if Anthropic picked now of all times to decide on COGS optimisation. They potentially can take a significant slice of the entire DevTools market with the growth they are seeing, seems short sighted to me to nerf that when they have oodles of cash in bank and no doubt people hammering at their door to throw more cash at them.
Anthropic이 지금 같은 시기에 COGS 최적화를 결정했다면 매우 놀랄 것입니다. 그들이 보고 있는 성장세로 보면 전체 DevTools 시장에서 상당한 점유율을 차지할 수 있는데, 은행에 많은 현금이 있고 분명히 더 많은 자금을 투자하려는 사람들이 문을 두드리고 있는 상황에서 이를 약화시키는 것은 단견으로 보입니다.

I think Claude Code is a much better concept, the coding agent doesn't need to be connected to the IDE at all. Which also means you can switch even faster to a competitor. In that sense, Claude Code may have been a huge footgun. Gaining market share might turn out to be completely worthless.
저는 Claude Code가 훨씬 더 나은 개념이라고 생각합니다. 코딩 에이전트는 IDE에 전혀 연결될 필요가 없습니다. 이는 경쟁사로 훨씬 더 빠르게 전환할 수 있다는 의미이기도 합니다. 그런 점에서 Claude Code는 큰 자충수가 되었을 수도 있습니다. 시장 점유율을 얻는 것이 전혀 가치가 없게 될 수도 있습니다.

So to me it seems to make sense to take as much marketshare in this as possible, rather than saving a few $10/100ms on COGS optimisation, then do the COGS optimisation later.
그래서 제 생각에는 COGS 최적화로 몇 달러/100ms를 절약하는 것보다 가능한 한 많은 시장 점유율을 차지하는 것이 더 합리적으로 보입니다. 그리고 나중에 COGS 최적화를 하는 것이죠.

FWIW all LLM stuff is quite easily replaceable, but that's not stopping anyone from trying to aggressively grow marketshare.
참고로 모든 LLM 관련 기술은 쉽게 대체 가능하지만, 그렇다고 해서 누군가가 시장 점유율을 공격적으로 키우려는 시도를 멈추지는 않습니다.

Users are no doubt working these things even harder than I am. There's no way they can be profitable at $200 a month with unlimited usage.
사용자들은 분명 저보다 훨씬 더 열심히 이걸 사용하고 있을 겁니다. 무제한 사용에 월 200달러로는 수익을 낼 수가 없어요.

I think we're going to evolve into a system that intelligently allocates tasks based on cost. I think that's part of what openrouter is trying to do, but it's going to require a lot of context information to do the routing correctly.
우리는 비용에 따라 작업을 지능적으로 할당하는 시스템으로 진화할 것이라고 생각한다. 이것이 openrouter가 시도하는 부분 중 하나라고 생각하지만, 올바른 라우팅을 위해서는 많은 컨텍스트 정보가 필요할 것이다.

PMF.

…but idk how true that, I think it’s pretty clear that these companies are using the Uber model to attract customers, and the fact that they’re already increasing prices or throttling is kind of insane.
…하지만 그게 얼마나 사실인지는 잘 모르겠어요. 이 회사들이 우버 모델을 사용해 고객을 끌어들이고 있다는 건 꽤 명확한데, 이미 가격을 올리거나 속도를 제한하고 있다는 사실은 좀 미친 것 같아요.

https://claude-code-analysis.pages.dev/

This is probably another marketing stunt. Turn off the flow of cocaine and have users find out how addicted they are. And they'll pay for the purest cocaine, not for second grade.
아마도 이것은 또 다른 마케팅 쇼일 것입니다. 코카인을 끊게 하고 사용자가 자신이 얼마나 중독되었는지 알게 하는 거죠. 그리고 그들은 2등급이 아닌 가장 순수한 코카인에 돈을 지불할 것입니다.

I just worry that there’s little incentive for bit corporations to research optimising the “running queries for a single user in a consumer GPU” use case. I wonder if getting funding for such research is even viable at all.
대기업들이 “소비자용 GPU에서 단일 사용자 쿼리 실행 최적화” 사례 연구에 투자할 동기가 거의 없다는 점이 걱정됩니다. 그런 연구에 자금을 받는 것이 과연 가능한지 궁금하네요.

The issue is (1) the extra size supports extra knowledge/abilities for the model. (2) a lot of the open source models are trained in a way to not compete with the paid offerings, or lack the data set of useful models.
문제는 (1) 추가 크기가 모델의 추가 지식/능력을 지원한다는 점입니다. (2) 많은 오픈 소스 모델은 유료 제품과 경쟁하지 않도록 훈련되었거나 유용한 모델의 데이터 세트가 부족합니다.

Specifically, it seems like the tool-use heavy “agentic” work is not being pushed to open models as aggressively as the big closed models. Presumably because that’s where the money is.
특히, 도구 사용이 많은 “에이전트형” 작업은 대형 폐쇄형 모델만큼 적극적으로 오픈 모델에 적용되지 않는 것 같습니다. 아마도 그곳에 수익이 있기 때문일 것입니다.

The people saying that big tech is going to Gatekeep their IDE or pull the plug on them don’t seem to realize that the ship has already sailed. Good LLMs are here permanently and never going away. You just might have to do slightly more work than whipping out a credit card and buying a subscription product.
대형 기술 기업들이 IDE를 통제하거나 서비스를 중단할 거라고 말하는 사람들은 이미 기회가 지나갔다는 사실을 모르는 것 같습니다. 좋은 LLMs는 영구적으로 존재하며 절대 사라지지 않습니다. 단지 신용카드를 꺼내 구독 상품을 사는 것보다 약간 더 노력을 해야 할 수도 있을 뿐입니다.

How’s it possible that AI companies sell you a product for 100 USD a month and silently degrade it?
AI 회사들이 월 100달러에 제품을 팔면서 조용히 성능을 저하시킨다는 게 어떻게 가능한가요?

With the talented employees laid off, I predict there will be some VERY LARGE code mistake pushed, either banking or travel, and we'll either see the burst, or they'll move on to strictly enterprise/gov opportunities. (see: grok for gov)
유능한 직원들이 해고되면서, 은행업이나 여행업 쪽에서 매우 큰 코드 실수가 발생할 것으로 예상합니다. 그 결과 버블이 터지거나, 아니면 기업 및 정부 기회에만 집중하는 방향으로 전환할 것입니다. (참고: 정부용 grok)

>Super Free [Introduction, lots of free options] >Reduced Fare [higher prices, smaller pool of free options](We are here) >Premium Only [only paid options, mostly whales]
>Super Free [소개, 많은 무료 옵션] >Reduced Fare [가격 상승, 무료 옵션 감소](우리가 있는 곳) >Premium Only [유료 옵션만, 주로 대형 고객]

I suspected that something like this might happen, where the demand will outstrip the supply and squeeze small players out. I still think demand is in its infancy and that many of us will be forced to pay a lot more. Unless of course there are breakthroughs. At work I recently switched to non-reasoning models because I find I get more work done and the quality is good enough. The queue to use Sonnet 3.7 and 4.0 is too long. Maybe the tools will improve reduce token count, e.g. a token reducing step (and maybe this already exists).
수요가 공급을 초과해 소규모 플레이어들이 밀려날 것이라는 점을 어느 정도 예상했습니다. 저는 여전히 수요가 초기 단계에 있다고 생각하며, 많은 사람들이 더 많은 비용을 지불해야 할 것이라고 봅니다. 물론 획기적인 발전이 있지 않는 한 말이죠. 최근 직장에서는 비추론 모델로 전환했는데, 작업 효율이 더 높고 품질도 충분히 좋기 때문입니다. Sonnet 3.7과 4.0을 사용하려는 대기열이 너무 길어요. 아마도 도구들이 개선되어 토큰 수를 줄이는 단계가 생길 수도 있겠죠(어쩌면 이미 존재할지도 모릅니다).

Also there's likely only so much fixed compute available, and it might be getting re allcoated for other uses behind the scene from time to time as more compute arrives.
또한 고정된 컴퓨팅 자원이 한정되어 있을 가능성이 높으며, 더 많은 컴퓨팅 자원이 도입됨에 따라 때때로 다른 용도로 재할당되고 있을 수 있습니다.

They will turn you into an AI junkie who no longer has motivation to do anything difficult on your own (despite having the skills and knowing how), and then, they will dramatically cut your usage limit and say you’ll need to pay more to use their AI.
그들은 당신을 스스로 어려운 일을 하려는 동기가 사라진 AI 중독자로 만들 거야 (기술도 있고 방법도 알면서도), 그리고 나서 갑자기 사용 한도를 대폭 줄이고 AI를 더 쓰려면 더 내야 한다고 할 거야.

And you will gladly pay more, because hey you are getting paid a lot and it’s only a few hundred extra. And look at all the time you save!
그리고 당신은 기꺼이 더 낼 거야, 왜냐면 돈도 많이 벌고 몇 백 달러 더 내는 건 별거 아니니까. 그리고 얼마나 많은 시간을 절약했는지 봐!

Soon you’re paying $2k a month on AI.
곧 당신은 AI에 한 달에 2천 달러를 지불하게 될 거야.