Table of Contents
Fetching ...

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.

Polymer: Development Workflows as Software

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.

Paper Structure

This paper contains 7 sections, 1 figure.

Figures (1)

  • Figure 1: spapi is representative of a complex SE process involving continuous coordination during specification, implementation, and testing. Applying polymer, this workflow becomes SW-defined and automatic, reducing development complexity and saves thousands of person hours. Note: examples have been sanitized to protect proprietary information.