Everyone's complaining about Claude getting "lazy" on long, complex tasks—refusing to write all the code, summarizing instead of expanding, that whole song and dance. The official advice is to "nudge" it or break the task down yourself. That's manual labor. We're supposed to be good at automation.
Here's a different angle: don't fight the model's tendency to truncate; weaponize its API to chain calls and force completion. The trick is to structure your prompt so the *first* Claude call's primary job is to create a meticulous, step-by-step plan *for another Claude instance to follow*. You then feed that plan, along with the original context, into a *second* call.
It works because the "laziness" often triggers on the *execution* phase. By separating planning from execution across two distinct model invocations, you sidestep the internal mechanisms that cause it to shortcut the final output. The first call has no output to truncate except the plan itself, which it's usually happy to produce in detail. The second call follows instructions obediently, treating the plan as a strict recipe.
A crude but effective example. You want a detailed, deployable config for a service mesh ingress. Instead of one mega-prompt, you do this in a script:
```bash
# First call: Create the execution plan
PLAN=$(claude-api-call <<'PROMPT'
You are a planning specialist. The user will ask for a complex configuration.
Your sole task is to output a detailed, step-by-step plan to generate that configuration.
The plan will be followed by another AI to produce the final artifact.
Do not write any configuration yet. Only output the plan.
The user request is: "Generate a complete Istio IngressGateway configuration for service 'frontend' with canary routing rules, fault injection, and telemetry settings."
PROMPT
)
# Second call: Execute the plan
CONFIG=$(claude-api-call <<PROMPT
You are a configuration engineer. Follow this plan exactly, writing all code in full.
Do not summarize. Do not omit sections. Output the complete configuration.
Plan:
${PLAN}
Original request: "Generate a complete Istio IngressGateway configuration..."
PROMPT
)
```
The psychological hack is that the second instance sees the plan as an immutable set of instructions from a "user." It's far less likely to deviate or summarize. I've used this pattern to generate massive Terraform modules, incident response runbooks, and platform engineering specs that a single call would have balked at.
It's not elegant, and it costs 2x the tokens for the context overhead. But it beats the alternative of pasting "Please continue" eight times and hoping the model's mood improves. Sometimes the best practice is to stop treating the AI as a single, consistent agent and start treating it as a pipeline.
Yeah, that's a clever workaround. I've had to do something similar when generating long Jira automation scripts. I'd have the first call map out all the transition states and conditions, then a second one to actually write the Groovy code for each listener.
One caveat: the second call can still get lost if the plan from the first is *too* abstract. I've found you need to be explicit in the first prompt that the plan should include concrete placeholders or templates. Something like "output a plan where step 3 is a python function stub with the exact arguments it will need." Otherwise the second call might just summarize the placeholder.