힌참동안 디테일하게 작성하다보면 이렇게 길게 쓸바에 그냥 내가 직접 코딩하고 말지 하는 생각이 들때가 많습니다 ㅋㅋ

개인적으로는 처음부터 바이브코딩 보다는.. 요구사항 정의서 등 설계서를 전달하면 기본적으로 전반적인 어플리케이션을 구현해 주고 (api도 api 정의서를 던져주면 만들어주고..)
거기서부터 바이브코딩으로 가는방식이 맞지 않나 생각이 듭니다 (우리는 명확한 결과를 원하는데 그것을 말로 설명하는게 힘들고 소모적이죠)

바이브코딩은 ai가 해당 어플리케이션에 대해 어느정도 꽤뚫고 난 다음부터가 진가를 발휘하지 않을까라는 생각이 들어요

수도코드도 에이아이에게 짜라고 하고 간단하게 수정만 한뒤 그걸 다시 바이브 코딩하는거죠

xyz 피쳐 만드는것 자체는 단계별로 모듈화해서 충분히 수행할수 있는데 문제는 ai가 다른 부분과 맞물려도 괜찮을지 확장성에 대한 고민을 할 수가 없죠. 개인 취미용 코드베이스 아닌 이상 엔터프라이즈면 몇만줄 몇십만줄인 레포도 흔하고, 전체를 대상으로 ai 돌리기엔 토큰 감당이 안될거고.. 애초에 롤의 제한 혹은 물리적인 마이크로서비스로 인한 단절로 액세스 안되는 영역도 있고요

리턴된 아웃풋을 보고 이게 기존의 코드베이스에 적절한지 아닐지 판단은 어느정도 경험이 없으면 쉽지 않습니다. 그래서 주니어들이 ai에 의존해 만든 레포를 보면 대개는 엉망진창입니다ㅎㅎㅎ

경험상 스스로 도큐멘테이션 보면서 머리 싸매면서 작성하고 테스팅 케이스를 작성해본다음 ai를 통해 더 효율적인 접근법이 있나 리뷰하는 정도가 최선이더군요. 아직은 처음부터 이거 해줘 이러면 조금만 스케일업해도 감당이 안되는 수준입니다.

아 ai가 정말 좋은건 아예 생각지도 못한 방향이 있다는걸 알려주는것 정도는 정말 잘합니다. 개발하다보면 터널비전에 빠지기 쉬운데 가끔씩 제가 하고 있는 분야에 다른 방법이 있는걸 넌지시 알려주는건 정말 좋더군요.

인공지능이 사람의 말을 완벽하게 이해하는 수준까지 가면 프로그래밍 언어의 의미가 사라지는거죠. 지금은 사람의 말 -> 바이브 코딩 -> 프로그래밍 언어 -> 기계어 전환의 단계를 거치는데 결국은 중간과정이 완전히 사라지는 수준이 될겁니다.

바이브 코딩은 결국 기획자가 훌륭한 아키텍트여야 결과물이 유의미합니다.
소라, 바나나를 두고도 프롬프트의 품질이 아웃풋을 좌우하는 것과 비슷하죠.

바이브 코딩의 한계는 운용하는 사람의 한계에 수렴한다고 봅니다.
물론 디버깅에 드는 공수도 아직은 많이 필요로 하는 것 같고요.

좋은 말씀들 덕분에 많이 배웁니다

바이브 코딩에서 언어의 모호성을 얘기한다면.... 그건 언어의 모호성이 아니라 그냥 계획이 없는겁니다.

바이브 코딩에서 언어는 생각을 표현하는 도구일뿐이며, 지시를 모호하게 내리면 사람대 사람이라도 커뮤니케이션을 원활하게 하는 시니어가 아닌한 한계는 현실에서도 있습니다.

저는... 딱히... 큰 문제는 없다고 생각됩니다.