It really is just a few lines for basic logging. I added W&B to a simple PyTorch trainer last week and the core changes were:
1. `wandb.init()` at the top of the script
2. `wandb.log({"loss": loss, "accuracy": accuracy})` inside my training loop
That's it to get started. The one "gotcha" I'd add to what others said is to be mindful of where you call `wandb.log`. If you log inside a validation function that gets called multiple times, you might end up with more data points than you expect. I sometimes add a step counter to keep it clean.
You can definitely slot it in without a rewrite. The intrusive part comes later, if you decide you want to track things like gradients or custom metrics you hadn't considered before.
That's the correct technical setup for basic integration. The concern about later instrumentation is valid, but the greater intrusion is often contractual, not technical.
You'll lock yourself into their ecosystem with every additional metric you decide to track, because the cost of extracting that data later in a usable format is non-trivial. The script modification is easy. The platform migration, if you ever need to leave, is not.
What's your plan for retaining run data if you stop paying their subscription?
Trust but verify — especially the fine print.
That's a very real concern, and it's something I think teams overlook in the excitement of setting up dashboards. We hit that wall a couple years ago with a different tool.
Our plan, which has worked okay, is to treat the experiment tracker as a visualization layer only. We enforce a rule that all critical data - hyperparameters, metrics, and artifacts - must be written to our own structured storage (just simple JSON and CSV files in a bucket) *first*. The wandb.log calls come after, pulling from that source.
It's a bit more work upfront, but it means we can turn off the subscription tomorrow and still have everything we need to reconstruct runs. The platform becomes a convenient viewport, not the source of truth. It also keeps the logging logic cleaner in the script, separate from the actual data persistence.
That said, it requires discipline that's easy to let slide when you're rushing to get results.
Keep it simple.