AI Collaboration Report – - snuhcs-course/swpp-2026-project-team-14 GitHub Wiki
AI Collaboration Report – Iteration 1
Document Revision History
| Version | Date | Author | Changes |
|---|---|---|---|
| 0.1 | 2026-10-06 | Dongkun Moon | Created the page with the Iteration 1 report for body analysis (P9, P10). |
| 0.1 | 2026-10-06 | KiHwan Kim | Add content for infrastructure & gitops deployment (P6, P7, P15). |
| 0.1 | 2026-10-07 | Hyeon U Jeong | Added the Iteration 1 wardrobe report: AI-assisted development, Korean prompts, human corrections and reflection. |
| 0.1 | 2026-10-09 | Juhyeon Choi | Added the Iteration 1 report for project planning, documentation, wireframes, and iteration coordination. |
Iteration 1 — Planning and Prototyping
Team summary
During Iteration 1, our team used AI tools across implementation, infrastructure, testing, planning, and documentation.
- Claude Code was used for body-analysis implementation, debugging, benchmarking, Android/backend integration, and testing.
- Codex was used for wardrobe implementation and integration, infrastructure configuration, deployment workflows, and related testing.
- ChatGPT was used for project planning, requirements and design documentation, user-flow and wireframe review, and iteration-level coordination.
Across these tasks, we found AI most effective when prompts included concrete project context, constraints, and expected outputs. Broad prompts often produced plausible but unnecessary or unsupported results, while more specific follow-up prompts led to better outcomes.
We therefore treated AI outputs as drafts or implementation assistance rather than final decisions. Product scope, technical trade-offs, real-device testing, cross-feature coordination, and final verification remained the responsibility of team members.
Body analysis (P9 screen, P10 AI integration) — Dongkun Moon
| Scope | P9 body analysis screen · P10 body analysis AI integration |
| Tool / model | Claude Code (Anthropic), Claude Opus 5.5, used as a coding agent in the local repository |
| Period | 2026-09-23 ~ 2026-10-06 |
| Merged work | PR #12, #15, #17 |
| Full prompt log | Iteration 1 – Prompt Log |
a) Where AI was used
| Area | Files | Evidence |
|---|---|---|
| Measurement pipeline: MediaPipe pose + mask, geometric measurement, quality checks | backend/body_analysis/pipeline.py, pose.py, measurer.py |
715887e, aa76d1d (PR #12) |
| Synthetic benchmark, learned correction, loose-clothing detector | backend/scripts/synthetic_benchmark.py, train_clothing_detector.py, backend/body_analysis/regressor.py, clothing.py |
79a72b5, cd3fbac, 005160d |
REST API POST /api/body-profile/analyze/ |
backend/apps/body_profiles/views.py |
0a4e754 |
| Android screens: capture guide, photo input, results, My Profile | frontend/app/src/main/java/com/swpp/stylemate/ui/profile/ |
daa1cf8, faa6fc8, 960da7c |
| Photo input fixes, benchmark accuracy display | pose.py, pipeline.py, reference.py, PhotoInputScreen.kt |
PR #15, PR #17 |
| CI and Docker | .github/workflows/backend-ci.yaml, frontend-ci.yaml, backend/Dockerfile L22–24 |
3c6f084 |
| Documents | docs/body-analysis/01–07, iteration-1-demo README |
e1ad3f4, 817a8f9 |
Deliberately not done by AI
- Product decisions: both photos required, no clothing question, neutral insight wording, photos deleted after analysis.
- Final checks: I checked every screen on the emulator myself.
- Publishing: I approved every issue and PR text before it was posted, and merged the PRs myself.
- Team agreements: for example, the backend memory limit was agreed with Kihwan before it was changed.
b) Prompt history
Representative prompts, as recorded in the Iteration 1 – Prompt Log:
| Date | Stage | Prompt |
|---|---|---|
| 09-23 | Design | "Context: [app description and tech stack]. Our wiki will later need requirements (user stories, wireframes, non-functional requirements, constraints) and design documents (architecture, APIs, data models, class diagrams). Task: design my part, the body profile analysis in My Profile. Ask me about any decision you cannot infer." |
| 09-24 | Model | "Task: (a) replace the Android fake analyzer with calls to the backend pipeline; (b) improve the body analysis model as far as the evidence supports. Output: before/after accuracy on the benchmark and a list of changes." |
| 10-01 | Debugging | "Context: a teammate reports that analysis keeps failing for some gallery photos, apparently depending on the image's pixel size. Task: reproduce it, find the root cause and fix it. Output: the cause, the fix and evidence that it works." |
c) What AI did well
| Case | Evidence | Effect |
|---|---|---|
Root-caused a teammate's crash. MediaPipe kills the server when the image width is not a multiple of 4 (image_frame.cc:415). The width is now padded, with a regression test that fails without the fix. |
backend/body_analysis/pose.py L81–92; b0b1186 (PR #15) |
About 20 minutes from report to verified fix |
| Stress-tested every input in one pass. It tried 11 image formats, sizes from 30×40 to 6000×8000, and concurrent requests. It found 4 more bugs: an upside-down photo gave a 176 cm chest, an empty file returned 500, an unreadable photo crashed the app, and a blank gender returned 400. | 29346bf, b62d1c8 (PR #15) | Each bug fixed with a regression test, in about 20 minutes |
| Made accuracy measurable without real ground truth. It built a benchmark of synthetic 3D bodies whose true measurements come from the mesh, then trained a correction on top. | docs/body-analysis/05-learned-correction.md L62; 07-accuracy-report.md L13 |
Held-out error −40–90 %; mean accuracy 98.7 % on synthetic bodies |
Found deployment-only bugs before deploying. Inside the container, every analysis returned 500 (missing libEGL), and the server ran out of memory at 256 Mi. |
backend/Dockerfile L22–24; 3c6f084 |
backend-ci.yaml now builds the image and loads the model on every PR |
| Asked before guessing. Before showing an accuracy %, it asked what the number should be based on. | Prompt Log, 10-02 | No baseless number reached the screen |
d) Hallucinations and errors
| What the AI asserted | Why it was wrong | How it was caught | Cost |
|---|---|---|---|
"Once #15 is merged and its branch deleted, GitHub retargets #16 to develop automatically." |
#16 was merged 19 seconds after #15, before any retarget, and landed in 13-fix-photo-input. |
The agent's later check of the repository | Reopened as PR #17: one extra PR and CI run |
| The app's downscaling makes measurements "3 cm worse" (it changed the code). | The two runs used different gender settings. Under equal conditions the difference was under 1 cm. | The agent's own re-run | Change reverted before any PR |
| Lengths are not affected by clothing. | Loose trousers hide the gap between the legs, so the inseam came out 13 cm short. | Clothing benchmark (09-24) | Loose-clothing warnings added (faa6fc8) |
| The measurement code was correct, and its unit tests passed. | The neck was measured across the trapezius (+26.7 cm), and arms were found for only 15 % of bodies. | Synthetic benchmark (04-synthetic-benchmark.md L92–94, 05-learned-correction.md L92) |
Fixed in aa76d1d |
| The test suite covered photo input. | Every sample photo was 960 px wide, so the width crash never appeared in tests. | A teammate, with real gallery photos | Fix and regression test in PR #15 |
e) Prompt revisions
1. Accuracy display
| Prompt | Result | |
|---|---|---|
| Before (10-02) | "Show the measurement accuracy as a percentage." | The agent had nothing to compare against; one option it offered was fixed percentages with no basis. |
| After (10-02) | "Base it on the benchmark bodies' known measurements: show a per-measurement accuracy % only when one of our benchmark photos is analyzed." | Accuracy shown only for marked benchmark photos (91a8f75, PR #17) |
Why it worked: it named the ground truth and limited where the number appears, so the percentage means something.
2. Results screen
| Prompt | Result | |
|---|---|---|
| Before (09-23) | "Build the Android prototype for this design and update the design documents to match." | A plain list of measurements and a clothing selector |
| After (09-28) | "Context: feedback after testing the results screen on the emulator. Task: (1) replace the plain list with a friendly body figure: tapping a highlighted part shows its measurement, and key measurements are always visible; (2) add body-shape insights; (3) do not ask users what they wear: detect it … and warn them when loose clothing is detected; (4) …" | Tappable body figure and insight cards (960da7c); automatic loose-clothing detection (005160d) |
Why it worked: it described concrete screen behaviour and named what to remove, instead of leaving the design to the agent.
f) Manual fixes and why
I did not edit code by hand this iteration. Every change could be checked by tests, benchmarks or the emulator, so prompting with that evidence was always faster than editing myself. My manual work was overriding the AI's design where the decision was mine to make:
| What I changed | Why |
|---|---|
| Removed the optional front-only mode; the side photo is required (aa76d1d) | Circumferences need body depth. The benchmark showed front-only chest values 12.3 cm too small. |
| Removed the clothing selector (005160d) | On the emulator, I saw users would answer it carelessly. Detection is more reliable. |
| Neutral insight wording (no "비만"-type labels) | Insights are styling hints, not judgements. A test now fails if any insight contains 비만, 뚱뚱, 체중 or 몸무게. |
| Accuracy % kept to benchmark photos, labelled as synthetic | A number on screen must not overstate real-photo accuracy. |
AI-generated code markers: a one-line header in 49 files I own and 15 files shared with teammates, e.g. # AI-generated with Claude Code (Claude Opus 5.5), 2026-09-24, reviewed by Dongkun Moon (PR #23). Search the code for AI-generated with to find them.
Takeaways for Iteration 2
- Reproduce before fixing: report the symptom with the failing photo attached. The reported condition ("multiples of 4") was the opposite of the real one.
- Test with real phone photos early: synthetic and sample data hid the width crash.
- Avoid stacked PRs, or retarget them before merging.
- Mark AI-generated code in the same commit that adds it.
Infrastructure and GitOps deployment (P6, P7, P15) — Kihwan Kim
| Scope | P6 architecture · P7 application and infrastructure setup · P15 integrated flow test |
| Tool | Codex (OpenAI) |
| Period | 2026-09-24 |
| Merged work | PR #2, #4, #5, #7, #8, #10 |
| Full prompt log | Iteration 1 – Prompt Log |
a) Where AI was used
| Area | Files | Evidence |
|---|---|---|
| Kubernetes and Argo CD manifests | infra/apps/namespace.yaml, infra/apps/backend.yaml, infra/argocd/team14.yaml |
3260866, 38c8a23, 5fb809f (PR #2) |
| Test Django server with a ClusterIP Service | backend/app.py, backend/Dockerfile |
5fb809f (PR #2) |
| Build-and-deploy CI | .github/workflows/backend-release.yaml |
46bbae0 (PR #2); simplified in PR #4, #5 |
| Image pull secret and test-server fixes | infra/apps/backend.yaml, backend/app.py |
PR #7, #8, #10 |
Deliberately not done by AI
- Directory and namespace design:
frontend/backend/infraand theteam14namespace were my decisions. - Namespace setup on the cluster (PR #2): shell work that was faster by hand.
- P15 integrated flow test: tested manually end to end.
b) Prompt history
Representative prompts; all six are in the Iteration 1 – Prompt Log.
| Date | Stage | Prompt |
|---|---|---|
| 09-24 | Design | "내가 현재 구축한 azure VM 위에 k3s 설치하고 main 브랜치 대상으로 ArgoCD 배포하려고 함. 각 구성 요소가 구체적으로 어떤 역할을 하는지, 그리고 지금 상황에서 Image 레지스트리는 어떤걸 사용하는게 좋을지 선택지들 구현 난도 측면에서 설명해줘." |
| 09-24 | Manifests | "디렉토리는 기본적으로 frontend, backend, infra로 나누고 기본 배포 네임스페이스는 team14로 정함. 이 구조를 기준으로 k3s와 ArgoCD 설정 yaml 파일 작성해주고, 이 파일들은 infra 폴더 내에서 작업하도록 해. …" |
c) What AI did well
| Case | Evidence | Effect |
|---|---|---|
| Wrote the deployment YAML from a structure I chose. | infra/apps/, infra/argocd/team14.yaml; 3260866, 38c8a23, 5fb809f |
YAML writing was automated, while the directory and namespace design stayed mine |
| Explained the deployment flow. GitHub Actions builds and pushes the image and updates the tag; Argo CD syncs the manifests to Kubernetes. It also compared registry options by implementation effort. | Prompt Log, 09-24 (first prompt) | GHCR chosen; helped me understand how the deployment components connect |
d) Hallucinations and errors
| What the AI produced | Why it was wrong | How it was caught | Cost |
|---|---|---|---|
| A pre-deploy CI with API endpoint checks I had not asked for (46bbae0) | The checks kept failing; the endpoint was called before the container had fully started | Repeated CI failures on main |
Two follow-up PRs (#4, #5) to cut the workflow back |
| k3s and Argo CD setup instructions | It mixed up commands for my local machine and the Azure VM, although I had described both environments | The instructions did not match the environment | I finished the setup by hand |
e) Prompt revisions
1. CI validation flow
| Prompt | Result | |
|---|---|---|
| Before (09-24) | "서버 deploy 전에 main에서 검증하는 CI 짜줘" | Build plus endpoint checks that kept failing (46bbae0) |
| After (09-24) | "CI는 컨테이너 환경에서 빌드했을때 서버가 정상적으로 healthy하게 뜨는지만 확인 후 정리하면 충분해" | Endpoint checks removed; build, push and deploy steps only (501cd9c, 6c60a6d; PR #4, #5) |
Why it worked: "verify before deploy" left the scope open, so Codex added extra tests. The follow-up named the one check that mattered: the container builds and the server starts.
f) Manual fixes and why
Although I had given Codex the cloud and CLI environment details, it kept mixing up commands for my local machine and the Azure VM, so its setup instructions were inconsistent. I stopped prompting and installed and configured k3s and Argo CD by hand.
AI-generated code markers: a one-line header in infra/apps/namespace.yaml, infra/argocd/team14.yaml and .github/workflows/backend-release.yaml, and in the shared infra/apps/backend.yaml and backend/Dockerfile, e.g. # AI-generated with Codex, 2026-09-24, reviewed by Kihwan Kim (PR #23).
Wardrobe (P11 screen, P12 AI integration) — Hyeon U Jeong
| Scope | P11 wardrobe screen · P12 garment analysis and registration |
| Tool / model | Codex (OpenAI), used as a coding agent with local repository access; the session metadata records gpt-6-astra |
| Period | 2026-09-25 ~ 2026-10-07 |
| Merged work | PR #18, PR #20; integrated into iteration-1-demo through PR #21 |
| Selected prompt log | Iteration 1 – Prompt Log, 19 wardrobe entries |
a) Where AI was used
I used Codex to turn the wardrobe requirements into an Android and Django implementation, then revise it after trying the app on my Galaxy S23 Ultra. Gemini and GarmentIQ HRNet are components of the application; Codex was the development tool. We used pretrained HRNet weights rather than training a garment model in this iteration. Codex also assisted with documentation drafts and translations, which I reviewed before publication.
Paths below refer to the integrated project. Earlier commits may contain the same work under the former prototype directory.
| Area | Files | Evidence |
|---|---|---|
| Capture, automatic points and measurement geometry | ui/wardrobe/capture/MeasurementActivity.kt, data/wardrobe/MeasurementGeometry.kt, backend/apps/wardrobe/landmarks.py |
daff82c; W11, W15–W16 |
| Gemini analysis, editable results and MySQL persistence | backend/apps/wardrobe/analysis.py, schema.py, editor.py, models.py, views.py; ui/wardrobe/GarmentEditor.kt |
1d342c1, d96049c; W09–W10 |
| Smaller schema and color selection | backend/apps/wardrobe/schema.py, analysis.py; ui/wardrobe/WardrobeColorField.kt |
77c70b2, a03026e, cecaa4a; W18, W23 |
| Integration with the team app and shared UI | ui/wardrobe/WardrobeScreen.kt, ui/components/ScreenComponents.kt, ui/theme/Theme.kt |
d96049c, 0aaa127, 115238c; W19, W20, W22, W23 |
| Model preparation during the Docker build | backend/scripts/prepare_landmarks.py, backend/Dockerfile, .github/workflows/backend-ci.yaml |
a979d55, PR #20; W26 |
| Checks | backend/apps/wardrobe/test_landmarks.py, tests.py; frontend/app/src/test/java/com/swpp/stylemate/wardrobe/MeasurementGeometryTest.kt |
daff82c |
Android paths starting with ui/ or data/ are relative to frontend/app/src/main/java/com/swpp/stylemate/.
Decisions and checks I retained
- I chose the requirements: reference-free measurement, visible points, editable results, and which fields to keep.
- I supplied camera input and checked the interaction on a real phone. Codex could operate the connected app, but I positioned the garment and phone and judged the visible behavior.
- I supplied environment credentials and decided when changes could be committed, merged or published. Codex prepared and sometimes executed those operations after my instructions.
b) Prompt history
The selected log in Iteration 1 – Prompt Log contains 19 dated requests about implementation, integration and deployment. The Korean prompts below are edited summaries of actual requests, not verbatim quotations. Outcomes summarize the resulting work.
| Date | Stage | Edited prompt |
|---|---|---|
| 09-28 · W09 | API selection | 의상 분석에는 gemini-3.1-flash-lite를 사용해주세요. API 키는 제가 환경 파일에 입력하겠습니다. 해당 파일을 .gitignore에 포함하고 백엔드에서 키를 읽어 연동하도록 구성해주세요. |
| 10-03 · W20 | Team integration | 기존 테스트용 local-dev를 제거하고, develop 브랜치의 실행 방식과 FE·BE 구조에 옷장 기능을 통합해주세요. |
| 10-04 · W23 | Schema and UI simplification | 촬영 화면에서 기울기 표시와 배경 제거 기능을 없애주세요. 스키마에서는 촉감, 신축성, 비침, 두께, 계절, 소재 등 착용정보를 모두 제거해주세요. 분석 결과의 “AR 추정” 문구와 상세정보의 격식, 여밈, 디테일, 어깨, 넥라인 항목도 제거해주세요. |
c) What AI did well
| Case | Evidence | Effect |
|---|---|---|
| Carried a change through the whole registration flow. It connected analysis results to editable fields, measurements, notes, validation and persistence. | 1d342c1, d96049c; analysis.py, editor.py, views.py, GarmentEditor.kt |
I could try capture → analysis → correction → save as one flow, then give feedback on the actual screen. |
| Separated point detection from physical measurement. HRNet supplies 2D points; Android maps points onto the ARCore plane and computes distances. Gemini supplies descriptive attributes. | daff82c; landmarks.py, MeasurementGeometry.kt; landmark mapping and geometry tests |
Each part had a clear responsibility. Users could review or replace points instead of treating every model output as a correct measurement. |
| Applied a smaller data contract across layers. It removed pattern and relative length, later removed wearing properties, and replaced checkbox colors with palette and photo-pixel selection. | 77c70b2, a03026e, cecaa4a; W18, W23 | The fields shown to users and accepted by the backend followed the same decisions. Measured cm values remained editable. |
| Made model setup reproducible in the image build. It reviewed the pinned source/weight downloads, checksum checks and ONNX export used by the Docker build. | a979d55; backend/scripts/prepare_landmarks.py, backend/Dockerfile |
The deployment image can contain the runtime model without committing the weight file to Git or depending on my local download. |
d) Hallucinations and errors
The main problems were model suggestions that needed further feasibility checks and a prototype whose schema and UI became too broad.
| What the AI produced or left unclear | Why it was a problem | How it was caught | Cost / correction |
|---|---|---|---|
| Model and project suggestions mixed research examples with options I could immediately integrate. | A relevant paper or repository did not establish that usable weights and a compatible runtime were available. | During model review, I asked for options that could be integrated immediately. The later KGDet replacement attempt could not be completed with the checked weights/runtime. | Extra investigation; the initial path used manual points with ARCore, then HRNet automatic points. KGDet did not replace HRNet. |
| The evolving prototype had long labels, extra capture explanations and a broad schema. | Some detail came from my earlier requests, but the resulting UI asked for more than the feature needed. A photo did not reliably establish material or wearing properties. | I tried the app and requested specific removals (W08, W18, W23). | Follow-up changes to screens, schema and validation; background removal and wearing properties were removed. |
e) Prompt revisions
1. From a fixed capture height to the actual measurement requirement
| Edited prompt | Result | |
|---|---|---|
| Before (09-30 · W14) | 지금은 구현하지 말고 다음 변경 방향만 기록해주세요. 지면에서 30~32cm 떨어진 위치에서 촬영하도록 자이로스코프를 활용하는 방안을 생각하고 있습니다. 기존 모델로 측정점을 표시한 뒤 ARCore와 각도 계산으로 치수를 추출하는 기능을 구현하고자 합니다. | A plan was recorded, not executed in that turn. Codex explained that a gyroscope alone does not measure height above the floor. |
| After (10-03 · W16) | 30cm는 예시이며 더 높은 위치에서 촬영해도 됩니다. 핵심은 기준 물체 없이 치수를 계산하는 것과 의상 측정점을 자동으로 선택하는 것입니다. 우선 오차 개선보다 기존 모델을 활용한 자동 측정점 구현에 집중하고, ARCore 기반 치수 계산 방식도 구현·검증해주세요. | Automatic garment points were connected to ARCore plane geometry. In a subsequent revision, the separate height display/calculation was removed while metric AR geometry remained (daff82c). |
Why it worked: the follow-up separated two problems: finding garment points and converting them into physical distances.
2. From prototype compatibility to one team implementation
| Edited prompt | Result | |
|---|---|---|
| Before (10-03 · W19) | develop 브랜치의 프로젝트 구조와 디자인 방향을 확인하고, 현재 로컬 개발 파일을 팀 프로젝트에 통합하는 방법을 검토해주세요. |
Codex compared the prototype with develop and described how they could connect. |
| After (10-03 · W20) | 기존 테스트용 local-dev를 제거하고, develop 브랜치의 실행 방식과 FE·BE 구조에 옷장 기능을 통합해주세요. |
The separate prototype was removed and the feature was integrated into the shared frontend/backend structure (d96049c). |
Why it worked: “connect” left room to keep two setups. The revised prompt named the target structure and explicitly removed the old execution path. The isolated prototype had been requested earlier; removing it was a later integration decision.
f) Manual fixes and why
Code corrections in this record were implemented by Codex after my follow-up prompts. My hands-on contributions were:
| What I did | Why it required my input |
|---|---|
| Positioned the phone and garment, supplied capture input, and checked the screens | The agent could not decide whether the physical setup and visible interaction were acceptable without real input. |
| Entered environment values locally | Database access and API credentials came from my environment, not from generated placeholder values. |
| Reduced the schema and removed unnecessary UI controls | These were product decisions based on the screen I used, not something passing tests could settle. |
| Helped reproduce garment-recognition and invalid-measurement screens | These cases needed real input to check error messages and recovery behavior. |
AI-generated code markers: a one-line header in 34 files I own and 14 files shared with teammates, e.g. # AI-generated with Codex, 2026-09-29, reviewed by Hyeon U Jeong (PR #23).
Takeaways for Iteration 2
- Agree on the smallest useful data contract before expanding the UI.
- Check available weights, preprocessing, license and runtime before treating a model as an integration candidate.
Project Planning and Documentation (P1–P5, P13–P16) — Juhyeon Choi
| Scope | Project planning · proposal · requirements and design documentation · wireframes · iteration coordination |
| Tool / model | ChatGPT (OpenAI) |
| Period | 2026-09-21 ~ 2026-10-09 |
| Main outputs | Project proposal, Requirements & Specifications, Design Documentation, wireframes/user flows, project schedule |
| Full prompt log | Iteration 1 – Prompt Log |
a) Where AI was used
I used ChatGPT mainly as a planning and documentation assistant. It helped turn team discussions and implementation details into structured project documents and review them against the course guidelines.
| Area | How AI was used |
|---|---|
| Project proposal | Revised target customers, motivation, core features, and product differentiation |
| Requirements & Specifications | Organized user stories, functional/non-functional requirements, constraints, and screen descriptions |
| Design Documentation | Structured architecture, data flow, component responsibilities, and screen-level design |
| Wireframes / user flow | Reviewed navigation and identified missing screens, states, and transitions |
| Project schedule | Helped organize tasks, owners, iterations, planned hours, and progress tracking |
Deliberately not done by AI
- Product scope and priorities: these were decided through team discussion.
- Task ownership and deadlines: AI helped organize the schedule, but assignments were decided by the team.
- Final verification: I checked generated documents against the actual implementation and information from feature owners.
b) Prompt history
Representative prompts are edited summaries of the Korean prompts I used during Iteration 1.
| Date | Stage | Edited prompt |
|---|---|---|
| 09-23 | Proposal | "지금까지 작성한 StyleMate proposal을 전체적으로 검토해주세요. Target Customers, Motivation, Innovation이 서로 잘 연결되는지 보고, 우리 서비스의 특징이 더 잘 드러나도록 수정하려면 어떻게 하면 될지 알려주세요." |
| 09-30 | User flow | "현재 정리한 StyleMate 기능을 기준으로 전체 user flow를 어떻게 구성하면 좋을지 정리해주세요. 온보딩부터 체형 분석, 옷장 등록, 코디 추천까지 사용자가 어떤 화면을 거쳐야 하는지 검토해주세요." |
| 10-07 | Documentation | "Requirements & Specifications와 Design Documentation을 가이드라인과 비교해서 검토해주세요. 현재 문서에서 빠진 내용이나 더 보완해야 할 부분이 있는지 알려주세요." |
c) What AI did well
| Case | Effect |
|---|---|
| Structured scattered project information. AI reorganized discussions and feature information into the formats required by the project documents. | Made initial drafting faster and exposed missing information. |
| Reviewed documents against explicit guidelines. Supplying both the existing document and course guideline allowed AI to identify missing sections. | Helped keep the Requirements and Design Documentation aligned with the required structure. |
| Found gaps in user flows. AI followed the navigation between screens and identified missing states or transitions. | Helped make the wireframes represent a complete user flow rather than isolated screens. |
d) Hallucinations and errors
| Problem | How it was caught and corrected |
|---|---|
| Early proposal drafts described StyleMate too generally as an AI fashion recommendation service and did not emphasize recommendations from the user's actual wardrobe. | I noticed that the description could also apply to generic recommenders and revised the prompt to explicitly state the owned-wardrobe constraint. |
| AI sometimes mixed planned functionality with implemented functionality when drafting project documents. | I compared drafts with the current implementation and checked feature-specific information with the responsible team members before publication. |
e) Prompt revisions
Product differentiation
| Prompt | Result | |
|---|---|---|
| Before | "Revise the target customers, motivation, and innovation of StyleMate." | Produced a reasonable but generic description of an AI fashion assistant. |
| After | "Make it explicit that StyleMate generates recommendations only from clothes registered in the user's wardrobe and does not recommend generic or nonexistent items." | The owned-wardrobe constraint became a central part of the product description. |
Why it worked: the revised prompt explicitly stated the product principle that could not be inferred from a general request to improve the proposal.
f) Manual fixes and why
| What I did | Why |
|---|---|
| Defined and refined the overall product scope | Scope depended on team goals and iteration priorities, not document structure alone. |
| Checked documents against the implementation | AI could not independently know which planned features had actually been completed. |
| Coordinated information from feature owners | Technical descriptions needed to reflect each member's actual implementation. |
Takeaways for Iteration 2
- Use AI to review existing artifacts against explicit guidelines rather than repeatedly regenerating documents.
- Clearly separate requirements, implemented features, and future work in prompts.
- Verify cross-feature technical information with the responsible feature owner before publication.