Anne Koziolek is now a professor at the Karlsruhe Institute of Technology (KASTEL) and leads the “Modelling for Continuous Software Engineering” research group. Her day-to-day work involves collaborating with her PhD students, serving as dean of studies, writing proposals, and doing academic community service. Recently, she served as a PC co-chair at ICSA 2026.
Here is what she had to say about their work and the future of performance engineering:
Could you briefly summarize the core contribution of your paper and what you are most proud of regarding its impact?
The paper turned architecture improvement into a search problem. We identified the degrees of freedom that a component-based architecture model already contains, such as allocation, processor speeds, and component selection.
We then let a multi-objective evolutionary algorithm explore that space for performance, reliability, and cost at once, returning a Pareto front rather than one supposedly best answer.
In retrospect, it was an early instance of model-driven optimization: the degrees of freedom cover more than one type of change and are defined over the metamodel rather than over one concrete model, which is why we could generalize them beyond Palladio in our CBSE 2011 paper.
What exciting new challenges are you and your team focusing on today?
My group works on making modelling cost-efficient enough to be part of continuous development. We focus on keeping heterogeneous models consistent with each other and with the code so that each piece of information is specified only once, automatically extracting models from code and from natural language artefacts.
In this way, we combine large language models with (symbolic) models—what we call intersymbolic AI. Design assistants will need both LLMs and models to deal with complexity through abstraction.
In your opinion, what emerging trends will dominate the field over the next few years?
I expect performance engineering to move further from a specialist activity towards something continuous that developers apply themselves. Part of that is already happening; benchmarking and performance regression checks are increasingly run inside CI pipelines. However, performance assessment in agile projects is rather ad hoc.
What is missing are cheap models. Our work on “Continuous Integration of Performance Models” (CIPM) moves in that direction: the architectural performance model is updated automatically from each commit and from operation-time observations.
Only affected parameters are recalibrated, instrumentation is applied adaptively to changed code to keep monitoring overhead low, and the approach validates its own accuracy. If keeping a model alive costs almost nothing, prediction can become a routine part of the pipeline.
What is your top advice for junior researchers submitting to ICPE 2027?
Start from a problem someone actually has, take your time to familiarize yourself with the state of the art, and think your ideas through.
What is one message you would send back to yourself?
Trust the general framing more than the current implementation. The four degrees of freedom we happened to support were the least interesting part of the paper, and the abstraction behind them was the part with a future.
What is one ICPE memory that has stayed with you?
I have attended several ICPEs, but presenting this paper at my first ICPE in 2010 (which was actually the first joint WOSP/SIPEW conference) as a PhD student was probably the most memorable.
Afterwards, I had great discussions that led to a years-long collaboration with Alberto Avritzer and others, from which I learned a lot. Such exchange during coffee breaks is exactly what makes conferences so valuable.