Trying out Product Engineer: widening the scope of work
Product Engineer 도전: 업무 영역의 확장
B · Useful, limited First-person account by a Yogiyo Android developer of a one-person, AI-coded feature pilot across backend, Android and iOS; clear on where time went, but one feature, no time or outcome figures.
Summary based on the full text·Original: about 12 minutes to read
In short
A Yogiyo tech blog post (late October 2026) by an Android developer who joined a Q2 2026 "product engineer" pilot: one engineer owns a feature from problem definition to release in a company organised by function. He chose a discount-ranking bottom sheet on the home screen, did the analysis and PRD himself, and had AI write all the code for backend, Android and iOS from a single spec. Code came fast; delivery did not. Time went to logger agreement and on-device verification, review waits on three PRs, QE capacity and the biweekly release slot. AI also failed where business history lived only in people's heads.
Key numbers
- 3platforms (backend, Android, iOS) built in parallel by AI from one shared spec document
- 2 weeksrelease cycle; missing a release slot meant waiting two more weeks
- Q2 2026quarter of the product-engineer pilot; the mobile team took over the BFF server from Q3
- about half a yearthe author's tenure at the company when he worked across unfamiliar backend microservices
As reported by the source.
Korean·Web page·opens techblog.yogiyo.co.kr
What it reports
- Three rules for the pilot: drop platform expertise and approach the problem fresh; write no code, focus on problem definition and verification; ask AI first, from docs and code, before asking colleagues.
- He found in BigQuery that exposure of the discount ranking, a surface with proven click-through and conversion, had dropped sharply versus the prior quarter, and built a GMV hypothesis from past CTR, traffic and order value.
- The PRD covered display format, target users, re-display interval, requirements and primary, secondary and guardrail metrics. Page view, impression and click loggers were defined with the data team to fit the existing taxonomy.
- The single spec had background and goals (including a monthly GMV target, value withheld), design principles and user flows, UI states, DTOs, priority, cooldown, A/B and RemoteConfig rules, per-platform scope, rollout and QA items, and open decisions. Platform differences were caught by comparing documents before code review.
- AI misread the microservices: one service still used both v1 and v2 APIs for business reasons, and the AI saw only v2. He dropped the ask-AI-first rule and went to the owning teams.
- A colleague's time-deal feature was about to ship a second home-screen bottom sheet in the same app version; he found it by chance in a PR review. The backend was redesigned into a generic bottom-sheet service by priority and condition, later reused for order-status nudges.
- Defining and verifying loggers cost more than writing them; three PRs waited for separate reviewers; QE time and the release calendar set the pace.
- Since Q3 the mobile team also owns the BFF server. It is moving scattered knowledge into a single source of truth, automating E2E tests and logger checks, and has already automated code review and responses.
How they got it
The author's own account of the pilot, with the spec structure and incidents described. No figures on duration, effort or the feature's results.
Limits
- One feature, one engineer; no comparison with how long the functional teams would have taken.
- The GMV goal and test results are not disclosed.
- The author was relatively new, which made undocumented history a bigger obstacle.
Why it matters for companies
The pilot repeats a pattern seen across many firms this year: AI removes code writing as the bottleneck and exposes verification, review queues, test capacity, release cadence and undocumented context. The useful details are the fixes: one spec all platforms build from, generic shared surfaces instead of feature-specific ones, and documenting business history so agents and new staff stop hitting the same walls. Firms trying full-stack or product-engineer roles should fund those foundations first, or the role mostly moves waiting time around.
Key passages in translation
Korean original
코드 생성은 더 이상 병목이 아닙니다. 병목은 맥락, 검증, 프로세스입니다.
Code generation is no longer the bottleneck. The bottlenecks are context, verification and process.
Korean original
AI 가 길을 잃은 곳은 문서가 아니라 누군가의 머릿속에만 있던 맥락이었습니다.
Where the AI got lost was not in the documents but in context that existed only in someone's head.
Korean original
코드를 작성하는 비용보다 로거를 정의하고 검증하는 비용이 더 컸습니다
Defining and verifying the loggers cost more than writing the code.
Summary based on the full text. Read the original for the full argument and data.Read the original on techblog.yogiyo.co.kr
- Tags
- Future of work