Takeaway: Next time I'd flag the Windows-specific gotchas (WeasyPrint's native deps, SQLite file locks, libGL missing on Modal's slim image) up front in the first prompt since they cost real cycles to debug reactively.
Takeaway: Next time I'd paste the full Unsloth/Modal error and ask for the actual root cause up front instead of letting quick patches loop on the same symptom.
Takeaway: Next time I'd ask it to actually dry-run or at least trace the Modal image build and dataset serialization steps against Unsloth's current examples, not just review the code — the static review missed both the apt-get ordering bug and the PIL/Arrow serialization issue, which only showed up once I actually ran it on Modal.
Takeaway: Next time I'd start by checking the model's actual transformers/peft requirements against unsloth's supported range before writing any training code — that single incompatibility cost the whole first hour.
Takeaway: Next time I'd ask upfront for the full dataset provenance and org/token permissions before starting a training run, since I ended up chasing HF org migration details mid-run.
Takeaway: Next time I'd paste the actual HF dataset_info metadata into the first prompt so the card is right the first time instead of needing a follow-up fix.
Takeaway: Next time I'd start by checking the app's actual inference stack (llama-cpp-python, not vLLM) before pushing any model format, since that assumption cost a lot of back-and-forth on GGUF conversion that turned out to be a dead end for MiniCPM-V-4.6.
Takeaway: Next time I'd tell the agent upfront to check the model card on Hugging Face for the exact transformers version needed, since half the debugging loop was chasing version mismatches (MiniCPM-V-4.6 model_type not registered, then peft/transformers pin conflicts) that a single doc check would have caught.
Takeaway: Next time I'd paste the file path and both exact values upfront so the agent doesn't need to read the file first to find them.