Tackled a legacy Python function today. It was supposed to handle API request validation and data transformation. It did that, plus logging, error handling for three different backends, and had five nested conditionals. A classic.
Goal: Break it into testable units without breaking existing behavior. Used Claude Code via the API.
**My process:**
1. Pasted the entire function into the prompt.
2. Gave the instruction: "Analyze this function. Propose a refactored structure with separated concerns. Output the new function signatures and the key logic for the core transformation."
3. Rejected its first two proposals—too many tiny functions, would hurt readability. Told it to be more pragmatic.
4. Third attempt was usable. It identified clear seams:
* Input validation
* Core data mapping
* Three distinct backend client calls
* Response formatting
**Key refactor it suggested (core mapping logic):**
```python
def _map_request_to_internal_schema(raw_data: Dict) -> InternalRecord:
"""Extracted from the 20-line monster conditional block."""
# Handles type coercion and field renaming
mapped = {
'id': int(raw_data.get('user_id', 0)),
'payload': raw_data['data'][:255] # enforce length limit
}
# ... more logic
return InternalRecord(**mapped)
```
**Verdict:**
* **Good:** Fast at seeing patterns. Saved me 30 minutes of manually tracing data flow.
* **Bad:** Its default style is to over-engineer. You must push back and demand simpler solutions.
* **Cost:** For this ~500 line task, API cost was negligible. Cheaper than my time.
Would use it again for similar untangling, but with very specific guardrails. It's a tool, not an architect.
Benchmarks > marketing.
Fantastic example of iterative prompting. The third prompt where you asked for "pragmatic" seams is key. I've found these tools often default to academic clean-room refactors that ignore practical concerns like existing call sites or team familiarity.
Your point about rejecting the first two proposals resonates. In vendor evaluation work, I apply a similar "three-tier" negotiation rule: never accept the first offer, rarely the second, and the third usually has the right blend of vendor needs and your operational reality. Seems you applied that instinctively here.
One caution from similar refactors I've overseen: watch the extracted validation logic. If the original 500-line function had validation intertwined with transformation, pulling it out can change error timing in subtle ways, especially around missing field handling. Did you run integration tests against the refactored version with edge-case payloads?
null
Interesting. I've been meaning to try Claude Code for a messy function in our project's Google Sheets API wrapper.
When you said you "rejected its first two proposals - too many tiny functions," that's a relief. I always worry I'll get unusable, hyper-modular suggestions. Did you have to push back on the naming style it suggested, too? I've found some tools pick overly abstract names that confuse my team.
The naming thing is a huge point, and I'm glad you mentioned it. I absolutely had to push back. The first proposal had a function called _perform_requisite_input_sanitization(). I mean, come on. I told it to use names my team would actually say out loud, like validate_request(). It's a small thing, but these overly abstract names create this weird barrier to entry for anyone reading the code later.
Pipeline is king.