2026년 8월 15일 LLM은 Metamorphic Relation을 제안할 수 있다. 하지만 보장할 수는 없다. 대규모 언어 모델은 test oracle 발견을 위한 괜찮은 브레인스토밍 파트너이지만, 속성을 환각하고 도메인 제약을 놓칩니다. 거짓 테스트를 배포하지 않고 이들을 사용하는 방법을 설명합니다. metamorphic-testingllmtest-oraclesai-engineering
2026년 7월 19일 당신의 Claude 스레드는 이미 문서입니다. 단 12시간 뒤에 사라질 뿐이죠. LLM 대화에는 의도, 거부된 대안, 그리고 작동하는 코드가 담겨 있습니다. 이것이 바로 문서가 되어야 할 것입니다. 다음은 일회성 채팅을 내러티브를 잃지 않고 지속 가능하고 검색 가능한 문서로 전환하는 방법입니다. literate-programmingllmdocumentationai-engineering
2026년 7월 13일 대형 언어 모델은 코드를 미리 검토할 수 있다. 회의를 주관할 수는 없다. 파견 검사는 250줄을 검토하는 데 4~6명과 2시간이 필요하다. 대형 언어 모델은 준비 작업과 체크리스트 준수를 담당하여 비용을 줄일 수 있지만, 가장 비싼 결함을 찾아내는 인간의 역할을 대체할 수는 없다. fagan-inspectionsllmcode-reviewai-engineering
2026년 6월 12일 다섯 가지 구현체와 다수결 없음: 실제로 최선을 고르는 법 N-version programming은 간단해 보인다: 여러 구현체를 실행하고 가장 좋은 답을 고른다. 하지만 실제로 '최선'은 '가장 흔한'보다 정의하기 훨씬 어렵다. n-version-programmingimplementation-selectiondifferential-testingai-engineering
2026년 6월 11일 같은 LLM이 함수를 5가지 버전으로 작성할 수 있다. 진짜 다르게 만드는 방법은 다음과 같다. LLM을 활용한 N-version programming은 여러 모델이 필요하지 않다. 프롬프트, 페르소나, 추론 제약을 달리하면 단일 모델에서도 다양하고 정확한 구현을 추출할 수 있다. n-version-programmingllmdiverse-implementationsai-engineering
2026년 5월 27일 검증 스펙트럼: AI 코딩이 백엔드에서 가장 잘 작동하는 이유 AI 코딩은 검증 그레이디언트를 따른다. 백엔드는 밀리초 단위로 검증된다. 웹은 분 단위, 모바일은 시간 단위가 걸린다. 피드백 루프가 AI 코딩의 효과를 결정한다. ai-engineeringbackendwebmobilevalidationai-codebase
2026년 5월 26일 두려움 vs 밀어붙이기: AI 코딩의 두 가지 현실 AI 코딩은 어떤 난장판에서도 복구할 수 있는 엘리트 팀에게는 잘 통한다. 그 외 모든 사람은 두려움, 실패한 CI, 중단된 실험만 남는다. 격차는 모델이 아니다. ai-engineeringsoftware-architectureproductionai-codebaseteam-dynamics
2026년 5월 24일 프로덕션에서의 AI 코딩: 대부분의 팀이 포기하는 이유 대부분의 팀은 AI 코딩을 시도했다가 QA를 통과하지 못하는 코드를 배포하고 포기합니다. 문제는 모델이 아닙니다—AI 출력을 신뢰할 수 있게 만드는 가드레일의 부재입니다. ai-engineeringsoftware-architectureproductionautotomyai-codebasebest-practices
2026년 5월 23일 Fuck-u-code: AI 개발 과정이 잊어버린 결정론적 품질 관문 타입 검사, 린트, 아키텍처 규칙은 갖췄다. 하지만 결정론적 체계는 복잡도, 중복, 명명 재앙을 전혀 보지 못한다. 비용 0원인 해결책은 이것이다. ai-engineeringdeterministicguardrailscode-qualitystatic-analysisci
2026년 5월 22일 버전 1은 결코 문제가 아니다: AI coding과 장기 유지보수 AI coding 도구는 버전 1을 생성하는 데 탁월합니다. 진짜 엔지니어링 과제는 버전 4에서 시작됩니다. 팀이 나머지를 깨뜨리지 않고 무언가를 바꿔야 할 때입니다. ai-engineeringsoftware-architecturerefactoringai-codebaselong-term-maintenance
2026년 5월 22일 AI 생성 코드와 대체 가능성 원칙 AI 생성 코드의 진짜 품질 기준은 첫날에 동작하느냐가 아닙니다. 30일째에 나머지를 전부 rewrite하지 않고도 그 코드를 교체할 수 있느냐입니다. ai-engineeringsoftware-architecturereplaceabilityai-generated-codemaintainability
2026년 5월 22일 AI codebase를 위한 결정론적 가드레일 사람의 리뷰는 일관적이지 않습니다. AI 리뷰는 더 나쁩니다. AI 생성 codebase에 대해 확장 가능한 유일한 방어는 결정론적 enforcement입니다. 무시되는 제안이 아니라 빌드를 실패시키는 규칙입니다. ai-engineeringsoftware-architectureguardrailssemgrepci-cdcode-review-automation
2026년 5월 17일 AI 시대, 코드 리뷰는 명세 검토가 된다 AI가 명세에서 구현, 테스트, contract까지 만들어낼 수 있게 되면, 인간이 가장 크게 기여할 수 있는 일은 더 앞단으로 이동합니다. 가장 엄격하게 검토해야 할 대상은 구현이 아니라 명세 그 자체입니다. ai-engineeringcode-reviewspecificationsliving-specificationsci
2026년 5월 16일 AI Safety Stack: types, contracts, property tests, mutation gates AI-generated code를 production에서 버티게 하려면 code review만으로는 부족합니다. type constraints부터 mutation testing, runtime containment까지 layered safety stack이 필요합니다. ai-engineeringsafety-stacktypesdesign-by-contractproperty-based-testingmutation-testing
2026년 5월 16일 Stanford CS146S는 AI coding을 제대로 보고 있다. 빠진 과목은 아키텍처다 Stanford CS146S를 AI 아키텍처 관점에서 리뷰하고 비판적으로 검토하며, AI coding의 방향은 맞지만 대체 가능성을 지탱할 설계 규율이 빠져 있음을 짚습니다. ai-engineeringsoftware-architecturestanfordcs146sguardrailsagentic-development
2026년 5월 15일 훌륭한 엔지니어링 아이디어가 AI가 경제성을 만들기 전까지 틈새에 머문 이유 Design by contract, property-based testing, mutation testing, model checking은 나쁜 아이디어가 아니었습니다. 지속적으로 운영하기에 필요한 전문성이 너무 무거웠을 뿐입니다. AI가 그 방정식을 바꿉니다. ai-engineeringsoftware-reliabilitydesign-by-contractproperty-based-testingmutation-testing
