Case Study Walkthrough #2

Automating Purchase Requests by Demonstration

Demonstrate the task once in the browser. The AI observes, reverse-engineers the portal form, verifies each step live, and generates a script that replays the workflow.

← Back to Seminar Page

🛒 The Task

Filing a 직접구매 신청 on the DGIST portal — the same clicks every time, only a few values change.

📝 Header fields
name · vendor · purpose
→
🔍 Two search popups
project · budget category
→
📋 Item grid + files
items · prices · PDFs
→
💾 Save
order button stays manual
🔧 Before You Start: Setup

Three installs: the agent, the browser bridge, and the script runtime.

1

Claude Code — the AI agent that runs in your terminal.

shell
npm install -g @anthropic-ai/claude-code
claude   # 첫 실행 시 Anthropic 계정으로 로그인

Node.js가 없다면 먼저 nodejs.org에서 설치하세요 (macOS: brew install node).

2

Claude in Chrome extension — lets Claude observe and drive your Chrome.

Chrome Web Store에서 "Claude in Chrome" 설치 → 같은 Anthropic 계정으로 로그인 → 확장 설정에서 portal.dgist.ac.kr, auth.dgist.ac.kr 접근 허용.

3

Python + Playwright — 생성된 스크립트를 실행할 런타임.

shell
pip install playwright
playwright install chromium
💡 The Key Idea: Show, Don't Tell

Describing a legacy form precisely is harder than just doing the task once — so demonstrate it instead.

💬 The prompt — polished from the actual session, ready to copy

Context:
- 나는 DGIST 포탈(https://portal.dgist.ac.kr)에서 반복적으로 수행하는 업무를 자동화하는 스크립트를 만들려고 해.
- 로그인이 필요하면 https://auth.dgist.ac.kr/login/ 페이지를 열어줘. 비밀번호 입력과 로그인은 보안상 내가 직접 할게.
- 크롬 확장(Claude in Chrome)이 연결되어 있으니 내 크롬 창에서 작업해.

Role:
너는 내가 시범 보이는 업무를 관찰해서, 그 업무를 재현하는 독립 실행 스크립트(Playwright, Python)를 만들어주는 자동화 엔지니어야.

Command:
1. 내가 크롬에서 해당 업무를 한 번 시범 보일게. 내가 "시범 끝"이라고 하면 분석을 시작해.
2. 스크립트를 쓰기 전에 페이지 구조(iframe, 필드, 팝업, 그리드)를 역공학하고, 각 단계를 실제 브라우저에서 검증해. 단, 검증 중에 저장·제출은 하지 마.
3. 매번 바뀌는 값과 고정값을 구분해서 나에게 확인받고, 바뀌는 값만 입력받는 구조로 만들어.
4. 스크립트는 저장 단계까지만 자동화하고, 최종 제출(발주·결재)은 내가 직접 누르도록 남겨둬.
세션에서 실제로 사용한 원본 프롬프트 보기
Context: 현재 나는 포탈에서 반복적으로 수행하는 나의 업무를 자동화 할 스크립트를 만들려고 해. 포탈을 사용하기 위해서는 auth.dgist.ac.kr에서 우선 로그인을 해야 해. 로그인 후에는 포탈에서 작업을 해.
Role: 너는 내가 자동화 하고자 하는 일을 스크립트화 해주는 사람이야.
Command: 내가 크롬에서 포탈에 접속해 시범을 보일테니 해당 일을 해주는 스크립트를 작성해.
ⓘ
You do the task once in your own browser. The AI inspects the pages, figures out how the form works underneath, and only then writes code.
⚠
세션 중 사람이 하는 일 세 가지. ① 로그인 (AI는 비밀번호를 다루지 않음) ② 알림창 닫기 — alert() 창이 떠 있으면 자동화가 멈추므로 직접 닫고, 문구를 알려주세요 ③ 최종 제출(발주·결재) 버튼 클릭.
🎬 How the Session Unfolded

From demonstration to a runnable script.

1

Human demonstration

Log in, file a test request the usual way — header, popups, one item row, attachments, save — then say "시범 끝".

2

Reading the end state

From the finished draft, the AI identified the target screen and found the form inside an iframe with ~170 fields — a classic legacy jQuery/jqGrid page.

3

Reverse-engineering the form

Read-only probes mapped every field the demo touched: header inputs, dropdown codes, the item grid's columns, and the file-upload control.

4

Live verification — without saving

On a fresh form, the AI replayed each step for real — header, both popups, a grid row — before writing any script code. Nothing was submitted.

5

Debugging the surprises

Verification surfaced problems no spec would mention: a save button that only exists via the portal menu, a popup with a hidden required order, and alert() dialogs that freeze automation.

6

Generating the script

A standalone Playwright (Python) script plus a small JSON for the values that change. It stops at save — the order button stays human.

🐛 What Live Verification Uncovered

Each of these would have silently broken a script written from the demo alone.

1

The save button doesn't exist if you open the form by URL. The portal menu opens the same URL as a POST with menu-authorization parameters; the script replays that POST.

2

Popups have a hidden required order. The budget popup's dropdowns must be chosen in sequence (예산과목 → 지출계획 → 계정과목) — each choice populates the next via AJAX.

3

The item grid is an inline-edit jqGrid. New rows are live inputs ({rowId}_GD_NM, …), and the total only computes if you fire the same change/blur events a keystroke would.

4

Native dialogs freeze everything. While an alert()/confirm() is open, the page is unreachable. The script auto-accepts and logs every dialog.

5

Detail rows only unlock after the first save. The real order: save the header → add items → attach files → save again.

📦 The Result

A script anyone can run — no AI needed at execution time.

Generated files
📄 dgist_direct_purchase.py — Playwright script: login check → form → popups → items → files → save
📄 request.json — only the values that change: name, vendor, items, attachments
shell
pip install playwright && playwright install chromium   # once
python dgist_direct_purchase.py request.json
request.json
{
  "구매명": "연구용 소모품 구매",
  "거래처": "쿠팡",
  "비고": "연구 수행에 필요한 소모품 구매",
  "품목": [
    { "품명": "USB 허브", "모델": "ABC-1234", "단위": "EA", "단가": 35000, "수량": 2 }
  ],
  "첨부파일": ["~/Downloads/명세서.pdf", "~/Downloads/영수증.pdf"]
}
✓
A persistent browser profile means you log in once and the session is reused. The script prints the request number and leaves the browser open for review — the order click stays human.
🧠 Principles You Can Reuse

The same recipe applies to any repetitive portal task.

Principle 1

Demonstrate, don't specify

One real demo carries more truth than a page of requirements.

Principle 2

Verify live before codifying

Replay every step in the real browser first — the surprises above were found before the script existed.

Principle 3

Keep the human at the boundaries

Passwords and the final submission stay human. Automation owns everything in between.

Principle 4

Parameterize only what changes

Fixed values go in the script; each run needs just a small JSON — what you bought, from whom, and the receipts.

Case study from the Automating Routine Work with AI seminar · PLX Lab @ DGIST