Hacker News 의견

• LLM은 새로운 프로젝트의 프로토타입을 빠르게 만들 수 있는 도구임. 그러나 기존 코드나 성숙한 프로젝트에 변경을 가할 때는 맥락이 부족하여 복잡성을 증가시키거나 불필요한 프레임워크를 추가하는 경향이 있음. LLM은 코드를 이해하는 것의 대체물이 아님.

• LLM과의 협업에서 질문을 통해 맥락을 구축하는 것이 중요함. 이는 직접적으로 맥락을 만들기보다 효과적임.

• 최근에는 LLM과 함께 모브 프로그래밍을 시도하고 있음. 한 LLM은 구현을 담당하고, 다른 LLM은 비판 및 개선을 제안함.

• 프로젝트에 의견이 강한 프레임워크를 추가하지 않는 것이 바람직함. 이는 모델이 인식해야 할 맥락의 크기를 증가시키기 때문임. 예를 들어, Plasmo 대신 LLM에게 브라우저 확장 프로그램 설정을 맡김.

• Cursor chat에서 시작해 더 나은 워크플로우로 발전한 사람들의 경험담을 듣고 싶음. 계획에 투자한 시간이 유익한지, 환각이 줄어들었는지, 전체적으로 시간을 절약했는지 궁금함.

• 이 기사는 LLM을 올바르게 활용하는 방법을 설명함. 많은 사람들이 언어 모델과 효과적으로 소통하는 연습이 부족함. 저자는 LLM과의 소통을 마스터했으며, 이 워크플로우는 효율성을 극대화함.

• LLM을 사용한 워크플로우에서 효율성을 극대화하려면 빠른 타이핑 속도, 올바른 판단력, 각 모델의 강점과 약점에 대한 친숙함이 필요함.

• LLM을 사용한 코딩 도구는 재미있지만, 실제로 도움이 되는지 확인하려면 구체적인 목표와 마감 기한을 설정해야 함. LLM은 이러한 조건에서 실패할 가능성이 높음.

• 많은 신입 프로그래머들이 프로그래밍의 명세 및 실행 계획 부분을 잊음. LLM을 성공적으로 사용하려면 명세 및 실행 계획을 만들도록 해야 함.

• Claude에 대한 기대를 이해하지 못함. Apache Spark에 대한 질문에서 많은 환각이 발생함. Claude가 다른 모델보다 나은 이유를 이해하고 싶음.

• 개인 개발자에게는 괜찮지만, 팀에서 같은 코드베이스를 분석하는 여러 LLM 인스턴스는 경제적이지 않고 위험할 수 있음. 팀을 위한 중앙화된 맥락을 제공하는 제품이 있는지 궁금함.