Producta

Producta는 Linear 티켓을 읽고 작업을 계획한 뒤 해결책을 작성했으며, GitHub 풀 리퀘스트를 열기 전에 테스트했다. 채팅 창에 코드를 붙여 넣을 필요가 없었다. 검증과 계획을 거쳐 자동화된 코드 솔루션을 만들어 내는 방식이었다. 결과는 검토 가능한 PR로 도착했고, 평소의 코드 리뷰 절차가 그대로 적용됐다. 리뷰 뒤에 머무는 GitHub의 AI 코드 생성 도구처럼 동작했다. 티켓에서 풀 리퀘스트로 이어지는 흐름 자체가 제품의 핵심이었다.

티켓이 모호하면 Producta는 코드를 쓰기 전에 확인 질문을 던졌다. 요구사항을 먼저 확정하려는 동료처럼 행동했다. 목표는 맥락이 얇아 생기는 오답을 줄이는 것이었고, 창업자들은 이를 AI 코드 결과가 실망스러운 주된 이유로 내세웠다.

두 번째 모드로, Producta는 새 티켓에 적힌 거친 아이디어를 받아 하나 이상의 분명한 기술 작업으로 다듬었다. 프로덕트 책임자나 창업자가 평범한 말로 바람을 넘기면 개발자가 바로 집어 들 수 있는 형태가 돌아왔다. 덕분에 코드가 한 줄도 없는 단계에서 도구가 쓸모 있었다.

제품은 Linear 워크스페이스와 GitHub 저장소에 바로 붙었다. 이미 그곳에서 일을 추적하던 팀에게 이 조합은 Linear의 AI 연동으로 기능했다. 평소 보드와 저장소에서 작업하고, 티켓을 Producta 칼럼으로 옮겨 흐름을 시작했다. 기존 스택 안에 머무니 시험 비용이 낮았다.

풀 리퀘스트를 연 뒤 Producta는 티켓의 댓글에 반응해 해결책을 조정했다. 리뷰는 막다른 길이 아니었다. 의견은 곧바로 다음 시도로 돌아갔다. 이 반복은 리뷰를 받은 사람 동료가 작업을 고쳐 쓰는 모습과 닮았다.

Enterprise 플랜은 R1과 o1을 포함한 모든 지원 모델에 접근을 열어 줬다. 어려운 티켓에는 고정된 기본값 대신 추론에 무게를 둔 모델을 고를 수 있었다. 모델 접근은 유료 플랜에 묶여 있어, 무료 체험에는 전체 라인업이 빠졌다.