Polymer: Development Workflows as Software
Dhasarathy Parthasarathy, Yinan Yu, Earl T. Barr
TL;DR
The paper addresses the cost and friction of automating early software engineering activities by proposing polymer, a workflow-as-code approach that uses LLMs as skeleton keys for automation. It demonstrates two Volvo cases—test workflow as code (spapi-tester) and implementation workflow as code (spapi-coder)—to automate under-specified tasks and reduce coordination friction. The method combines LLM-driven translation with conventional automation, enabling left-shifted automation before specification is fully formalized. The authors discuss open challenges and outline a research agenda for validating, scaling, and governance of polymer-enabled development workflows.
Abstract
Software development builds digital tools to automate processes, yet its initial phases, up to deployment, remain largely manual. There are two reasons: Development tasks are often under-specified and transitions between tasks usually require a translator. These reasons are mutually reinforcing: it makes little sense to specify tasks when you cannot connect them and writing a translator requires a specification. LLMs change this cost equation: they can handle under-specified systems and they excel at translation. Thus, they can act as skeleton keys that unlock the automation of tasks and transitions that were previously too expensive to interlink. We introduce a recipe for writing development workflows as software (polymer) to further automate the initial phases of development. We show how adopting polymer at Volvo, a large automotive manufacturer, to automate testing saved 2--3 FTEs at the cost of two months to develop and deploy. We close with open challenges when polymerizing development workflows.
