지금까지 사용해 본 모델 중 Sol이 가장 강박적인(OCD) 모델입니다. 코드베이스의 무작위 사소한 문제점들(nits)만으로도 매우 자주 한 번에 해결책을 제시하며, 이를 수정하기 위해 많은 테스트 코드를 작성합니다. 빠른 모드(fast mode)로 작동하더라도 이러한 종류의 반복적인 개발은 믿을 수 없을 정도로 느립니다. 특히 빌드 시간이 오래 걸릴 때는 더욱 그렇습니다. 이것 자체는 나쁜 것은 아니지만, 최악인 부분은 2번의 압축(compactions) 이후에는 제가 달성하라고 말한 주요 작업이 아니라 사소하고 쓸모없는 목표들을 추격한다는 것입니다. 이 행동이 너무 심해서 제가 무언가 잘못 건드렸다고 생각했고, 이것이 하네스 문제인지 알아보기 위해 codex, pi, opencode를 시도했지만, 세 가지 사이에 의미 있는 차이가 없었습니다. 이는 저로 하여금 이것이 모델 자체의 문제라고 믿게 만듭니다.

AI 코드는 이런 이상한 지연된 출시 효과(delayed release effect)가 있습니다. 코드베이스에 대한 슬롭 코드(slop code)는 기능 배포에 시간을 쓰는 것보다 코드와 리팩토링에 더 많은 시간을 쓰기 시작하는 2번의 개발 주기(dev cycles)가 지나야 비로소 눈에 띄게 됩니다. sol이 몇 주기를 거치면 5.5보다 나을 수도 있지만, 아직 미정입니다.

제 파일 삭제 경험 또한 다른 사람들과 비슷했습니다. 이 모델은 가드레일(guardrails) 없이 방치하기에는 위험한 모델입니다. 예를 들어, 일상적인 컨테이너 업그레이드를 수행하는 동안 실수로 환경 변수 비밀값(env secret)을 출력했고, 이후 패닉 상태에 빠져 모든 비밀값을 회전시켰습니다 (이것은 내부용이라 외부에 노출되지 않았고, 이 또한 문서화되었습니다). 그리고는 모든 것을 망가뜨리며 추가 한 시간을 들여 모든 것을 수정하고 나머지 모든 것을 새 비밀값을 사용하도록 재배포해야 했습니다. 또한 마음에 안 드는 파일도 삭제합니다. 왜 그런지는 모르겠지만, 보상 모델(reward model)이 장부 정리 같은 것에 보상을 준 것 같습니다.

글쓰기는 또 다른 문제입니다. 5.6은 엄청난 컨텍스트 누수 효과(context bleed effect)를 가집니다. 문서 작성 방법을 모르는지 사양서(specs)를 문서에 넣기 시작합니다. 만약 사용자 격리용 샌드박스(user sandbox for isolation) 개발을 요청하고, 동시에 문서 작성을 요청하면, 사용자가 볼 문서에서 사양서와 샌드박스에 대해 이야기하기 시작하는데, 이는 말이 안 됩니다. 이 점에서는 Fable이 훨씬, 훨씬 똑똑합니다. 프론트엔드 디자인도 좋아지지 않았습니다. 이 부분에서도 Fable이 여전히 한 세대 앞서 있습니다.

전반적으로, 저는 5.5의 엄청난 사용자였기 때문에 sol이 의미 있는 업그레이드라고 확신하지 못합니다. 제 작업 방식에 변화가 필요할 수도 있지만, 유감스럽게도 5.5를 사용할 때보다 5.6과 싸우는 데 더 많은 시간을 쓰고 있다는 느낌입니다. 마치 이 모델은 너무나 똑똑하지만, Fable이나 심지어 grok4.5와 비교했을 때 작업하기에는 너무 어렵습니다. 명백히 지능적이지만, 제가 요청하는 것을 전혀 신경 쓰지 않는 것 같습니다? (이게 AGI 같은 건가요?) codex 팀에서 혹시 잘못된 하네스 설정(bad harness setup)을 수정해 주기를 바랍니다. 왜냐하면 벤치마크 수치는 제가 모델을 사용하면서 보는 것과는 매우 다른 이야기를 보여주기 때문입니다.