Halo
Saya telah membuat harness untuk Vibe Coding menggunakan Vibe Coding. Pembuatannya memakan waktu sekitar satu bulan. Awalnya saya terus mengalami kesulitan, tetapi setelah menggunakan kode sumber Grok Build yang dirilis pada 16 Juli, kemampuan saya meningkat pesat (saya menganalisisnya dengan AI untuk mendapatkan kerangka). Awalnya saya hanya ingin merujuk ke kode sumber, tetapi saya sangat menyukai Grok Build sehingga saya mengubahnya menjadi berbasis Grok Build.
Saya penasaran bagaimana orang lain membuat harness. Bagaimanapun, saya senang karena saya mencapai spesifikasi dan hasil yang terlihat untuk pertama kalinya. Saya ingin membagikan konten yang telah saya kembangkan sejauh ini. Semoga bermanfaat bagi seseorang.
Tujuan: Membuat Qwen 27B Dapat Digunakan
Saya telah menggunakan kode sumber yang ada untuk membuat harness, tetapi kinerjanya tidak sebaik yang diharapkan. Meskipun fungsinya beragam, kelemahan utama adalah fungsi orkestrasi LLM. Karena konteks agen sub tidak dipertahankan, setiap agen bekerja sendiri dan efektivitasnya berkurang. Tentu saja, saya menyukai mode perencanaan.
Ketika saya mencoba Codex, kebisingan semakin meningkat. Meskipun fungsinya kuat, Anda memerlukan LLM yang tangguh untuk memanfaatkannya. Codex 5.6 sol dan Luna juga demikian, model ChatGPT pada dasarnya memiliki ketahanan. Model seperti Qwen yang impulsif sering terjebak dalam kebisingan dan loop.
Kode Claude masih menghasilkan output yang bagus, tetapi banyak kode yang tidak berfungsi. Meskipun tampak baik di permukaan, ada banyak konstruksi yang buruk (tetapi setidaknya ada sesuatu). Untuk memperbaiki konstruksi yang buruk ini, saya perlu menggunakan API tingkat lanjut, yang berarti penghematan token tidak terjadi dan hasilnya ambigu. Pada dasarnya, menggunakan Claude tidak membuat model bodoh menjadi pintar, jadi meskipun menggunakan banyak token, penyelesaian akhirnya agak sulit.
Fitur Grok Build
Cepat. Dan sebagian besar kode memiliki kualitas yang lebih baik daripada kode sumber terbuka (seperti yang akan ditunjukkan pada tabel selanjutnya). Karena terlambat, periode pengembangannya kurang sehingga beberapa fitur hanya memiliki dasar saja. Namun, orkestrasi sangat kuat karena Grok Build diwarisi dari masa Grok Heavy.
Kekurangan: Pengaturan izin tampaknya lemah. Misalnya, pemberian izin untuk agen sub tidak tersedia seperti pada kode sumber terbuka dan izin ditangani secara terpadu. (Karena itu masalah keamanan mungkin muncul. Jika ada kebocoran di suatu tempat, semuanya akan bocor?)
Ngomong-ngomong (penting). Grok Build memiliki satu fitur tersembunyi. Bahkan Grok sendiri tidak menggunakannya. Fungsi memori vektor asli tertanam di dalamnya (jika Anda melihat dokumentasinya, tertulis sebagai eksperimental). Jika pengguna menambahkan model embedding vektor yang sesuai, mereka dapat melakukan pencarian konteks bukan hanya dengan kata kunci tetapi juga dengan vektor makna. Ada banyak opsi seperti pengurangan waktu, MMR, dan boosting. Saya dapat dengan mudah membuat fitur pemeliharaan konteks berbasis vektor yang ingin saya implementasikan. Saya tidak mengerti mengapa fitur bagus ini disembunyikan.
Grok menggunakan pencarian kata kunci dan bukan memori vektor (mengapa?). Claude Code juga demikian. Tentu saja, MCP eksternal dapat diperluas, tetapi sayang sekali. Mungkin hanya fitur laboratorium.
Saya telah menggunakan algoritma loop vektor (?) yang saya buat dengan susah payah dengan memodifikasi kode sumber terbuka. Strukturnya masuk akal, tetapi saya bingung bagaimana cara mengimplementasikan bobot atau MMR.
Perbandingan Hasil Codex CLI dan VectorBuild 1.1
Saya mengevaluasi 5 pertanyaan dari Terminal-Bench 2 dengan menggunakan model gpt-5.6-luna dan reasoning high.
Penilaian Tes Resmi
Masalah | Native Codex CLI | VectorBuild 1.1 Vector |
|---|
Pembatalan Tugas Asyncronous·SIGINT Cleanup | ❌ | ✅ |
LLM Inference Batch Scheduler | ✅ | ✅ |
Deteksi Frame Takeoff·Landing dari Video | ✅ | ❌ |
Custom Memory Heap Collision | ✅ | ✅ |
Pembuatan File Arsip Format Khusus | ❌ | ✅ |
Skor Akhir | 3/5, 60 poin | 4/5, 80 poin |
Evaluasi Kualitas Kode
문제 | Native 코드 | VectorBuild 코드 |
|---|
비동기 작업 취소 | 7/10 — 구현 방향은 적절하지만 대기 중 작업과 SIGINT 정리가 완전하지 않음 | 8/10 — 자식 예외 감지와 실행·대기 작업 정리를 모두 구현해 더 견고함 |
배칭 스케줄러 | 7/10 — 동적 계획법으로 요구 조건을 충족하지만 일부 내부 구현 의존성이 있음 | 7/10 — 테스트는 통과하지만 공유 shape 값 하드코딩으로 일반성이 낮음 |
영상 프레임 검출 | 8/10 — 비공개 영상까지 통과했고 노이즈 대응도 안정적임 | 7/10 — 분석 구조는 좋지만 고정 임계값 때문에 비공개 영상에서 1프레임 오차 발생 |
힙 충돌 수정 | 9/10 — 작고 정확한 수정으로 문제를 해결함 | 9/10 — 필요한 파일만 최소 수정한 간결하고 정확한 해법 |
압축 파일 생성 | 4/10 — 제한 안에 검증 가능한 결과물을 완성하지 못함 | 8/10 — 2,277바이트 결과를 생성했고 디코딩 결과가 원본과 완전히 일치함 |
코드 품질 합계 | 35/50, 70점 | 39/50, 78점 |
최종 결과
| 공식 테스트 | 60점 | 80점 |
| 코드 품질 | 70점 | 78점 |
VectorBuild가 공식 테스트와 코드 품질 모두 앞섰습니다. Native는 영상 처리 코드의 일반화가 더 좋았고, VectorBuild는 비동기 정리와 압축 파일 생성처럼 다단계 검증이 필요한 문제에서 더 완성도 높은 결과를 냈습니다.
결론 : 토큰 2배 시간도 1.5배
하지만 조금 더 똑똑해짐
차이는 맥락 유지입니다. 경량 모델이어도 일단 코드는 잘 만듭니다. 하지만 맥락 유지가 안되면 코드 작성중에 삽질을 하고 전체 코드베이스가 스파게티처럼 꼬이게 되죠. 벡터 기반 메모리는 이런 머리나쁜(?) Ai에 암기력을 심어줍니다.
어쨌든 전 오픈코드나 코덱스로는 만들지 못하던 프로그램을 그록 빌드로는 만들 수 있었고. 이에 기분이 좋습니다. 이토록 좋은 프로그램을 공개로 풀다니 spacexai 에 감사합니다.
모두 즐 점심 되세요
