LLM 기반 코딩 에이전트(coding agents)는 대개 익숙한 소프트웨어 환경, 즉 주류 언어, 일반적인 라이브러리, 그리고 공개 리포지토리(public repositories)에서 평가됩니다. 이러한 벤치마크(benchmarks)들은 여전히 중요하지만, 언어 자체가 생소할 때 에이전트가 어떻게 행동하는지는 숨길 수 있습니다. 우리는 파일 편집, 로컬 실행(local execution), 그리고 숨겨진 테스트 채점(hidden-test grading)을 포함하는 순차적 설정(sequential setup)을 사용하여, 네 가지 난해한 프로그래밍 언어(esoteric programming languages)에 대해 여섯 가지 현대적 코딩 에이전트를 평가합니다. 우리의 프로토콜은 SWE-Bench Verified 및 Terminal-Bench 2.0과 같은 주류 코딩 및 에이전트 벤치마크가 훨씬 더 좁은 범위로 압축해버리는 에이전트 간의 능력 차이를 드러냅니다. 우리는 가장 강력한 에이전트인 Claude Opus 4.6 및 GPT-5.4 xhigh가 대상 언어를 직접 작성하는 것을 종종 피한다는 점을 관찰했습니다. Brainfuck 및 Befunge-98에서 이들은 대상 언어의 코드를 생성하는 Python 프로그램을 작성하고, 해당 생성기(generators)를 로컬에서 디버깅합니다. 이러한 메타프로그래밍(metaprogramming) 전략을 금지하면 성능이 크게 하락합니다. 이 전략에서 추출된 텍스트 가이드(Text guidance)는 약한 에이전트들을 실질적으로 개선하지 못합니다. 반면, 해결된 벤치마크 프로그램이나 숨겨진 테스트 정답이 없는 상태에서 생성기를 구축하기 위해 Opus로부터 유도된 Python 헬퍼 코드(helper code)를 사용했을 때, 동일한 문제에 대해 Sonnet 4.6 및 GPT-5.4 mini의 성능은 급격히 향상되었으나 Haiku 4.5는 낮은 수준에 머물렀습니다. 더 많은 인터프리터 호출(interpreter calls)과 출력 토큰(output tokens)은 강력한 에이전트의 성능을 향상시키지만, 약한 에이전트들은 원래 성능 근처에 머물게 하여, 이러한 자원들이 유용한 전략을 만들어내기보다는 기존의 유용한 전략을 증폭시킨다는 것을 나타냅니다. 종합적으로, 이러한 결과들은 강력한 코딩 에이전트가 도구, 피드백, 그리고 워크스페이스 상태(workspace state)를 사용하여 대상 언어에 대한 작동 모델을 구축함으로써 생소한 언어에 적응한다는 것을 보여줍니다. 메타프로그래밍이 가장 명확한 사례이지만, 더 넓은 의미의 격차는 대상 언어의 규칙 하에서 작동하는 전략을 구축하고 디버깅하는 능력에 있습니다.