Towards Enabling An Artificial Self-Construction Software Life-cycle via Autopoietic Architectures
Extracted source text · arXiv 2604.13934
%%
%% This is file `sample-sigconf-authordraft.tex',
%% generated with the docstrip utility.
%%
%% The original source files were:
%%
%% samples.dtx (with options: `all,proceedings,bibtex,authordraft')
%%
%% IMPORTANT NOTICE:
%%
%% For the copyright see the source file.
%%
%% Any modified versions of this file must be renamed
%% with new filenames distinct from sample-sigconf-authordraft.tex.
%%
%% For distribution of the original source see the terms
%% for copying and modification in the file samples.dtx.
%%
%% This generated file may be distributed as long as the
%% original source files, as listed above, are part of the
%% same distribution. (The sources need not necessarily be
%% in the same archive or directory.)
%%
%%
%% Commands for TeXCount
%TC:macro \cite [option:text,text]
%TC:macro \citep [option:text,text]
%TC:macro \citet [option:text,text]
%TC:envir table 0 1
%TC:envir table* 0 1
%TC:envir tabular [ignore] word
%TC:envir displaymath 0 word
%TC:envir math 0 word
%TC:envir comment 0 0
%%
%% The first command in your LaTeX source must be the \documentclass
%% command.
%%
%% For submission and review of your manuscript please change the
%% command to \documentclass[manuscript, screen, review]{acmart}.
%%
%% When submitting camera ready or to TAPS, please change the command
%% to \documentclass[sigconf]{acmart} or whichever template is required
%% for your publication.
%%
%%
\documentclass[sigconf]{acmart}
%%
%% \BibTeX command to typeset BibTeX logo in the docs
\AtBeginDocument{%
\providecommand\BibTeX{{%
Bib\TeX}}}
%% Rights management information. This information is sent to you
%% when you complete the rights form. These commands have SAMPLE
%% values in them; it is your responsibility as an author to replace
%% the commands and values with those provided to you when you
%% complete the rights form.
\setcopyright{acmlicensed}
\copyrightyear{2018}
\acmYear{2018}
\acmDOI{XXXXXXX.XXXXXXX}
%% These commands are for a PROCEEDINGS abstract or paper.
\acmConference[Conference acronym 'XX]{Make sure to enter the correct
conference title from your rights confirmation email}{June 03--05,
2018}{Woodstock, NY}
%%
%% Uncomment \acmBooktitle if the title of the proceedings is different
%% from ``Proceedings of ...''!
%%
%%\acmBooktitle{Woodstock '18: ACM Symposium on Neural Gaze Detection,
%% June 03--05, 2018, Woodstock, NY}
\acmISBN{978-1-4503-XXXX-X/2018/06}
\input{utils/macros}
%%
%% Submission ID.
%% Use this when submitting an article to a sponsored event. You'll
%% receive a unique submission ID from the organizers
%% of the event, and this ID should be used as the parameter to this command.
%%\acmSubmissionID{123-A56-BU3}
%%
%% For managing citations, it is recommended to use bibliography
%% files in BibTeX format.
%%
%% You can then either use BibTeX with the ACM-Reference-Format style,
%% or BibLaTeX with the acmnumeric or acmauthoryear sytles, that include
%% support for advanced citation of software artefact from the
%% biblatex-software package, also separately available on CTAN.
%%
%% Look at the sample-*-biblatex.tex files for templates showcasing
%% the biblatex styles.
%%
%%
%% The majority of ACM publications use numbered citations and
%% references. The command \citestyle{authoryear} switches to the
%% "author year" style.
%%
%% If you are preparing content for an event
%% sponsored by ACM SIGGRAPH, you must use the "author year" style of
%% citations and references.
%% Uncommenting
%% the next command will enable that style.
%%\citestyle{acmauthoryear}
%%
%% end of the preamble, start of the body of the document source.
\begin{document}
%%
%% The "title" command has an optional parameter,
%% allowing the author to define a "short title" to be used in page headers.
\title{
%Evaluating AI-Based Approaches for Clinical Protocol Assessment: An Experience Report
Towards Enabling An Artificial Self-Construction Software Life-cycle via Autopoietic Architectures
}
%%
%% The "author" command and its associated commands are used to define
%% the authors and their affiliations.
%% Of note is the shared affiliation of the first two authors, and the
%% "authornote" and "authornotemark" commands
%% used to denote shared contribution to the research.
\author{Daniel Rodriguez-Cardenas}
\email{dhrodriguezcar@wm.edu}
\orcid{1234-5678-9012}
\affiliation{%
\institution{William \& Mary}
\city{Williamsburg}
\state{VA}
\country{USA}
}
\author{David N. Palacio}
\email{davidnad@microsoft.com}
\affiliation{%
\institution{Microsoft}
\city{Redmont}
\state{WA}
\country{USA}
}
\author{Denys Poshyvanyk}
\email{dposhyvanyk@wm.edu}
\affiliation{%
\institution{William \& Mary}
\city{Williamsburg}
\state{VA}
\country{USA}
}
%%
%% By default, the full list of authors will be used in the page
%% headers. Often, this list is too long, and will overlap
%% other information printed in the page headers. This command allows
%% the author to define a more concise list
%% of authors' names for this purpose.
\renewcommand{\shortauthors}{Rodriguez-Cardenas et al.}
%%
%% The abstract is a short summary of the work to be presented in the
%% article.
\begin{abstract}
Software engineering research has focused on automating maintenance and evolution processes to reduce costs and improve reliability. The emergence of \textbf{foundation models (FMs)} with strong code understanding and reasoning abilities offers new opportunities for autonomous software behavior. Inspired by Artificial Life (\textit{ALife}), we propose a fundamental shift in the Software Development Life-Cycle (\textit{SDLC}) by introducing \textit{self-construction} mechanisms that enable software to evolve and maintain autonomously. This position paper explores the potential of \textit{Autopoietic Architectures}, specifically $\Psi$-\textit{Arch}, as a foundational framework for self-constructing software. We first analyze the limitations of traditional maintenance approaches and identify gaps in current SDLC automation. Subsequently, we outline the core challenges in achieving self-construction, including integrating foundation-model-based reasoning units and establishing novel architectural paradigms. Although this paper does not present a definitive solution, it seeks to catalyze discourse and inspire research toward a new paradigm in software engineering—one in which self-constructing software represents the next frontier in SDLC automation.
\end{abstract}
%%
%% The code below is generated by the tool at http://dl.acm.org/ccs.cfm.
%% Please copy and paste the code instead of the example below.
%%
\begin{CCSXML}
<ccs2012>
<concept>
<concept_id>10011007.10011074.10011111.10011113</concept_id>
<concept_desc>Software and its engineering~Software development techniques~Automatic programming</concept_desc>
<concept_significance>500</concept_significance>
</concept>
<concept_id>10011007.10011074.10011134</concept_id>
<concept_desc>Software and its engineering~Software creation and management~Program comprehension</concept_desc>
<concept_significance>300</concept_significance>
</concept>
<concept>
<concept_id>10010147.10010178</concept_id>
<concept_desc>Computing methodologies~Artificial intelligence</concept_desc>
<concept_significance>100</concept_significance>
</concept>
</ccs2012>
\end{CCSXML}
\ccsdesc[500]{Software and its engineering~Software development techniques~Automatic programming}
\ccsdesc[300]{Software and its engineering~Software development techniques~Program synthesis}
\ccsdesc[100]{Computing methodologies~Artificial intelligence}
\keywords{AI, LLMs for Code, Maintenance, Software Life-cycle}
%% A "teaser" image appears between the author and affiliation
%% information and the body of the document, and typically spans the
%% page.
%\received{20 February 2007}
%\received[revised]{12 March 2009}
%\received[accepted]{5 June 2009}
%%
%% This command processes the aauthor and affiliation and title
%% information and builds the first part of the formatted document.
\maketitle
\input{text/01.Introduction}
\input{text/03.why_important}
\input{text/02.background}
\input{text/03.position}
\input{text/04.discussion}
%\input{text/06.Future_Work}
\input{text/05.conclussion}
%\section*{Acknowledgment}
%We would like to thank all the participants in our user study. Also, the authors have been supported by the \# grants. Any opinions, findings, and conclusions herein are the authors’ and do not necessarily reflect those of the sponsors.
%%
%% The next two lines define the bibliography style to be used, and
%% the bibliography file.
\bibliographystyle{ACM-Reference-Format-num}
\bibliography{utils/references}
%%
%% If your work has an appendix, this is the place to put it.
\end{document}
\endinput
%%
%% End of file `sample-sigconf-authordraft.tex'.
%%%%%%%%%%%%%% USERPACKAGE
\usepackage{tikz}
\usepackage{caption}
\usepackage{blindtext}
\usepackage{tcolorbox}
\usepackage[final]{pdfpages}
\usepackage{lipsum,multicol}
\usepackage{xcolor}
\usepackage{tikz}
\usepackage{listings}
\usepackage{enumitem}
\usepackage{hyperref}
\usepackage{amsfonts}
\usepackage{wrapfig}
\usepackage{subcaption}
\usepackage{adjustbox}
\usepackage{colortbl}
\usepackage{fancybox}
\usepackage{multirow}
\usepackage[normalem]{ulem}
\useunder{\uline}{\ul}{}
\usepackage{enumitem}
\usepackage{booktabs}
%%%%%%%%%%%%%% NEW COMMANDS
\newcommand{\codeRational}{\textbf{Code}\ensuremath{\mathbb{Q}}\xspace}
\newcommand{\shapleyCode}{{\textbf{\textit{shapCode}}}\xspace}
\newcommand{\codeXplainer}{{\textbf{\textit{codeXplainer}}}\xspace}
\newcommand{\REF}{{\color{red} \textbf{[REFS]}}\xspace}
\newcommand{\ie}{\textit{i.e.,}\xspace}
\newcommand{\eg}{\textit{e.g.,}\xspace}
\newcommand{\etc}{\textit{etc.}\xspace}
\newcommand{\etal}{et al.\xspace}
\newcommand{\etals}{et al.'s\xspace}
\newcommand{\aka}{\textit{a.k.a.}\xspace}
%Comments
\newcommand{\nb}[2]{
\fbox{\bfseries\sffamily\scriptsize#1}
{\sf\small$\blacktriangleright$\textit{#2}$\blacktriangleleft$}
}
\newcommand\TODO[1]{\textcolor{red}{\nb{\#TODO:}{#1}}}
\newcommand\DAVID[1]{\textcolor{blue}{\nb{DAVID:}{#1}}}
\newcommand\ALEJO[1]{\textcolor{teal}{\nb{ALEJO: }{#1}}}
\newcommand\MICHELE[1]{\textcolor{blue}{\nb{MICHELE}{#1}}}
\newcommand\DANIEL[1]{\textcolor{orange}{\nb{DANIEL}{#1}}}
\newcommand\DIPIN[1]{\textcolor{violet}{\nb{DIPIN}{#1}}}
%\newcommand\alexey[1]{\textcolor{cyan}{\nb{Alexey: }{#1}}}
\newcommand\revision[1]{{\color{blue}{#1}}}
\newtcolorbox{boxK}{
fontupper = \small,
sharpish corners, % better drop shadow
boxrule = 0pt,
toprule = 0pt, % top rule weight
%enhanced,
%fuzzy shadow = {0pt}{-2pt}{-0.5pt}{0.5pt}{black!35} % {xshift}{yshift}{offset}{step}{options}
}
%%%%%
\newcommand{\secref}[1]{Sec.~\ref{#1}\xspace}
\newcommand{\figref}[1]{Fig.~\ref{#1}\xspace}
\newcommand{\tabref}[1]{Table~\ref{#1}\xspace}
\newcommand{\Phase}{{\sc Phase}\xspace}
\newcommand{\Phases}{{\sc Phase's~}\xspace}
\newcommand*\circled[1]{\tikz[baseline=(char.base)]{
\node[shape=circle,draw,inner sep=0.5pt] (char) {#1};}}
%%%%%%%%%%%%%% MODELS
\newcommand{\ncm}{NCM\xspace}
\newcommand{\ncms}{NCMs\xspace}
\newcommand{\codeparrot}{\textit{codeparrot-small}\xspace}
\newcommand{\bart}{\textit{BART-large}\xspace}
%%%%%%%%%%%%%%% DATASETS
%%%%%%%%%%%%%% Terms
\newcommand{\lmc}{LM4Code\xspace}
\newcommand{\lmsc}{LM4Code\xspace}
%\newcommand{\nlm}{NLM\xspace}
\newcommand{\lms}{LMs\xspace}
\newcommand{\ntp}{NTP\xspace}
\newcommand{\ntps}{NTPs\xspace}
\newcommand{\ewash}{\textit{eWASH}\xspace}
\newcommand{\aise}{AI4SE\xspace}
\newcommand{\statements}{\texttt{\small{[statements]}}\xspace}
\newcommand{\structural}{\texttt{\small{[structural]}}\xspace}
\newcommand{\types}{\texttt{\small{[types]}}\xspace}
\newcommand{\oop}{\texttt{\small{[oop]}}\xspace}
\newcommand{\conditionals}{\texttt{\small{[conditionals]}}\xspace}
\newcommand{\loops}{\texttt{\small{[loops]}}\xspace}
\newcommand{\asserts}{\texttt{\small{[asserts]}}\xspace}
\newcommand{\punctuation}{\texttt{\small{[punctuation]}}\xspace}
\newcommand{\class}{\texttt{\small{[class]}}\xspace}
\newcommand{\focalmethod}{\texttt{\small{[focal method]}}\xspace}
\newcommand{\signature}{\texttt{\small{[signature]}}\xspace}
\newcommand{\bool}{\texttt{\small{[bool]}}\xspace}
\newcommand{\expression}{\texttt{\small{[expression]}}\xspace}
\newcommand{\nlnoun}{\texttt{\small{[nl\_noun]}}\xspace}
\newcommand{\exceptions}{\texttt{\small{[exceptions]}}\xspace}
%\newcommand{\customitem}[2]{\item[#1] \textbf{\arabic*}}
\newcommand{\functional}{\texttt{\small{[functional]}}\xspace}
\newcommand{\return}{\texttt{\small{[return]}}\xspace}
%%%%%% tables
\newcommand{\mean}{\textbf{\textit{mean}}\xspace}
\newcommand{\std}{\textit{std$[\sigma]$}\xspace}
%%%%%%%%%%%%%% NEW COMMANDS
\newcommand{\sm}{\textit{SM}\xspace}
\newcommand{\alife}{A\textit{Life}\xspace}
\newcommand{\sdlc}{\textit{SDLC}\xspace}
\newcommand{\nvd}{NVD\xspace}
\newcommand{\cve}{CVE\xspace}
\newcommand{\cnas}{CNAs\xspace}
\newcommand{\cna}{CNA\xspace}
\newcommand{\cvss}{CVSS\xspace}
\newcommand{\llm}{LLM\xspace}
\newcommand{\llms}{LLMs\xspace}
\newcommand{\bigvul}{\textit{Big-Vul}\xspace}
\newcommand{\noncloud}{\textit{open-source}\xspace}
\newcommand{\cisco}{\textit{Propietary}\xspace}
\newcommand{\nlm}{NLM\xspace}
\newcommand{\nlms}{NLMs\xspace}
\newcommand{\approach}{$\Psi$\textit{-Arch}\xspace}
\newcommand{\psiarc}{$\Psi$-Architecture\xspace}
\newtheorem{thm}{Theorem}[section]
\newtheorem{lem}[thm]{Lemma}
\newtheorem{prop}[thm]{Proposition}
\newtheorem{cor}{Corollary}
\newtheorem{conj}{Conjecture}[section]
\newtheorem{defn}{Definition}[section]
\newtheorem{exmp}{Example}[section]
\newtheorem{rem}{Remark}
\section{Introduction}
\label{sec:introduction}
%%% The introduction should address the following key aspects:
%1. The Establishing Significance of Software Life-Cycle Why SLC is important to automate?
%2. Previous or current research and contributions "Automation of Software Life-Cycle"
%3. Gap, question, or prediction "Automation of SLC has not been yet addressed from the perspective of ALIFE" What is ALIFE.
%4. The position "We propose a paradigm shift from conventional SLC to self-contructed SLC"
%The answer to the question \textit{"why engineer software artificially?"} tends to be naturally related to the answer to \textit{"why study artificial life for software engineering automation?"}
%%______________________________
%% Key1: Introduce the topic and its relevance.%%
%-----
%% Software Development Life-Cycle ---> Software Maintenance ---> Examples of Automation is Source Code Generation.
Software Development Life-Cycle (\sdlc) outlines five phases to produce a software artifact \ie that is designed, developed, tested, deployed and maintained \cite{10.1145/2543581.2543595,Lehman1980ProgramsEvolution}. Specifically, the software maintenance phase is the most critical and costly in the \sdlc\cite{10.1007/978-981-16-0739-4_28,895984}. Software maintenance entails \textit{any modifications made to a system after deployment}. In fact, these modifications involve the knowledge of the practitioners \cite{10.1145/3597503.3623330} to design, construct, and improve the source code. Recent software maintenance (\sm) research has focused on automating repetitive tasks using Machine Learning~ (ML) and, more recently, foundational models (FMs) - large-scale pre-trained models trained on vast datasets of code and natural language with broad capabilities across diverse tasks.
Automating software maintenance ensures that software systems remain efficient, reliable, adaptable, and relevant over time \cite{9568959,10548798}. Several studies have investigated software maintenance automation on downstream tasks such as testing \cite{gruber2023automatictestgenerationtools,10765036}, and program repair \cite{10172693,10.1145/3597503.3623310,SequenceR,SANER2019}. Additionally, foundation model-based code generation has been extensively studied in the field of software maintenance~\cite{Ciniselli2021AnES, ICSE2021Transformers,Tufano2018AnTranslation,Wang2017Semantics-awareCode,BinghamBrown2017TheMutants,White2016DeepDetection} to assist practitioners with large language models (\llms) demonstrating remarkable abilities to understand code semantics~\cite{merrill_can_2024}, generate patches~\cite{jin_inferfix_2023, ramanan_aspire_2024}, and think about software behavior~\cite{wei2025swerladvancingllmreasoning}. However, as software products grow in size and complexity, \textit{canonical} ML-assisted maintenance becomes increasingly challenging and error-prone \cite{10.1145/3597503.3639095}, powered by the reasoning and generative capabilities of foundation models~\cite{wu_reasoning_2024}.
%% Background of a more specific area than the maintenance field. That area is "automating software maintence".
\begin{figure}[h]
\centering
\includegraphics[width=\linewidth]{figures/Paradigms.pdf}
\caption{\small{Maintenance Paradigm Shift: a) Software Maintenance (\sm) is independent from the main software, and b) \sm is wrapping the main software.}}
\label{fig:newD}
\end{figure}
%------ Problem introduction or paper gap
%%???
This canonical vision of software maintenance has permeated research methods in the software community, leaving no room for alternative approaches due to the remarkably successful use of statistical learning technologies such as transformers \cite{vaswani2023attentionneed} or reinforcement learning \cite{wei2025swerladvancingllmreasoning}. Irrespective of the exponentially growing canonical research on maintenance, a significant gap remains as this \sm automation has not yet been addressed from the perspective of autonomous construction. This autonomous mechanism is achieved by incorporating artificial life (\alife) elements to enable \textbf{autopoietic} features (\eg self-organization, self-assembly, or self-replication) for \textit{self-construction}~\cite{Sayama_2024,Dorin2024Alife,arcas2024computationallifewellformedselfreplicating}, powered by the reasoning and generative capabilities of fundation models.
%%______________________________
%%Key2: Provide background information.
\alife is an interdisciplinary field that examines life-like properties—such as self-organization, adaptation, and evolution—in natural and artificial systems \cite{Dorin2024Alife}. Integrating \alife principles with foundation model capabilities enables maintenance frameworks that not only perform predefined tasks, but also autonomously adapt and evolve under changing conditions. We propose self-construction maintenance as a replacement for the canonical maintenance paradigm within the \sdlc. This paper challenges the traditional understanding of \sm and introduces an autonomous mechanism that supports the software construction life-cycle.
%%______________________________
%%Key3: Clearly state our position (thesis statement).
This paper introduces an \textbf{autopoietic architecture} called \approach for the artificial self-construction software life-cycle. \approach is an extended and adapted version of von Neumann's self-replicating model \cite{VonNeumann1966}. We present a first draft for the formal notation of \approach and a complete description of an additional self-construction reasoning unit $\Gamma$. \approach establishes the foundation for next-generation \sdlc through \textit{artificial software engineering}.
In this paper, we explain our \approach and how to integrate an autopoietic architecture in a software system using \llms. We highlight the necessity of using causal reasoning to help the system make decisions on self-refactoring, where FMs provide the generative and reasoning capabilities required for autonomous decision-making.
%\TODO{Introduce a case study using \approach with a tiny implemented example}
%At the intersection of Artificial Life (ALIFE) and Software Engineering (SE) we identify an opportunity to automate the maintenance and evolution process.
%%Stating Problems
%However, the authors omit the \textit{how} and \textit{why} of bounding such systems. Instead, their focus is on integrating control units into systems through feedback control and AI techniques. Although this research is relevant for evolvable software systems, we argue that software design must go further by incorporating mechanisms for \textit{self-construction} at runtime. Self-construction not only ensures adaptability to environmental changes but also enables the natural evolution -or enhancement- of the system.
%We are in favor \textbf{to enable self-constructed software through Autopoietic Architectures}. What would the reasoning unit do? It would extract the identified dead code from the main software and automatically generate a new replica of the architecture. This new replica would be the natural evolution of the system. This generated version would replace the actual system after guaranteeing that the replica is running stably. Indeed, one can say that the replicated software system $S$ exhibits \textit{complex behavior} \cite{MaturanaHumberto1980AutopoesisCognition}. \DENYS{I like the example in this paragraph, it is pretty effective. However, the two paragraphs before need to flow coherently}
\section{What are the Autopietic Architectures for?}\label{sec:impact}
We assert that the software maintenance research conducted on automatic techniques to date will be easily integrated into the autopoietic architecture (\approach). Consider the following scenario; a software engineer wants to eliminate a useless functionality in a software system $S$. The useless functionality can be mapped to sections of the source code that are executed, but its results are never required. This is a typical example of \textit{dead functionality} elimination. This engineer wants the system $S$ to self-identify the impact of the elimination of functionality and remove additional dead code. At this point, we can notice that the system $S$ includes the FM-powered solution, in other words, $S$ is an FM by itself. Using an autopoietic architecture (\approach), the system $S$ is controlled by a reasoning unit $\Gamma$ that decides how to react in the presence of dead code and create a refactoring. The autopoietic architecture automatically generates a new, refactored replica of itself to replace the actual system, ensuring that the replica runs stably.
We envision a formal and nature-inspired approach that artificially enables the \textit{self-construction} of the Software Engineering Life-Cycle using \approach. \autoref{fig:newD} illustrates the paradigm shift from a canonical ML-driven to a self-construction maintenance technique. This self-construction paradigm allows software systems to create better replicas of themselves at run-time, leaveraging the code understanding, generation, and reasoning capabilities.
\section{Background \& Context}
\label{sec:background}
%%
%1. Introduce Software maintenance (canonical view)
%2. Mention LLM capabilities on software code generation
%3. Mention LLM reasoning process
%4. Mention Evolvability is being solved in Alife --> autopoetic concepts
%5. What exactly is the technique that can help us to solve the evolvability issue (self-replication)
%6. To make a transition from self-replication to self-constrcution.
%% Key Aspects this section should contain:
%1. Define key concepts and provide a brief history of the issue.
%2. Explain why the issue is important and who is affected.
%3. Summarize different perspectives on the issue.
%----------------------------------
Foundation models are large-scale pre-trained models trained on broad datasets that can be adapted to a wide range of tasks~\cite{marl-book}. Unlike traditional Machine Learning models that require task-specific training, FMs leverage transfer learning and self-supervised learning to develop general-purpose capabilities that can be fine-tuned for specific applications. In the context of software maintenance, FMs such as GPT-4, CodeLlama, and StarCoder have demonstrated remarkable capabilities in code generation~\cite{dou_stepcoder_2024}, program repair~\cite{jin_inferfix_2023,10.1145/3597503.3623310}, vulnerability detection~\cite{shimmi_ai-based_2025,rahman_towards_2024}, and code comprehension~\cite{velasco_toward_2025}.
The term \textit{autopoiesis} refers to a process by which systems continuously regenerate and sustain their components and connections autonomously \cite{MaturanaHumberto1980AutopoesisCognition,Bedau2007ArtificialLife}. Under this autopoietic automation vision, software systems are perceived as dynamic entities with inherent self-regulation, adaptability, and, in particular, \textit{self-construction} behaviors.
The autopoiesis concept becomes feasible as the recent research on FMs, particularly \llms for SE and agentAI4SE~\cite{yang2024sweagentagentcomputerinterfacesenable,arora2024masaimodulararchitecturesoftwareengineering,zhang2024surveylargelanguagemodels,shen_shortcutsbench_2025} has demonstrated the potential to cover the required components for an autopoietic architecture. This perspective transcends conventional ML techniques by enabling a paradigm where software architectures incorporate self-maintenance, self-repair, and autonomous evolution. As a result, autopoietic principles provide a foundation for \textbf{next-generation artificial software engineering}, fostering resilient, adaptive, and self-sustaining computational ecosystems and redefining the SDLC.
The Software Development Life-Cycle (\sdlc) enables a software product by involving technological resources and stakeholders in a well-designed pipeline. This pipeline consists of several phases, including planning, analysis, design, development, testing, deployment, and \textit{maintenance}. Each phase has its own set of activities and deliverables that feed into the next phase. Software Maintenance (\sm), the last phase, is the longest and, therefore, the most costly because it stays active as long as the software remains in production\cite{10.1007/978-981-16-0739-4_28,895984}. Considerable research attention has been devoted to \sm on the automation of specific \textit{tasks}. These tasks assist maintenance activities such as clone detection \cite{White2016DeepDetection}, bug-fixing \cite{Tufano:ASE18, Tufano:MSR18}, impact analysis, traceability \cite{9284034}, refactoring\cite{Nader-palacio2018AssessingDetection,Mkaouer2016AOpportunities}, bad smell detection \cite{Romano2018ACode,Tufano2017WhenAway}, and vulnerability detection\cite{10.1145/3597503.3623345, 10.1145/3597503.3639173, 10764854}.
It is generally accepted that \sm automation operates using machine learning (ML) approaches or evolutionary computation (EC) solutions (\ie Search-Based Software Engineering \cite{10.1145/2379776.2379787}). Consequently, several maintenance tasks, within the Software Development Life-Cycle \sdlc, still require the active intervention of practitioners. For example, automating \textit{bug-fixing} with a statistical learning approach depends upon collecting, filtering, deduplicating, and transforming code-based datasets, tasks generally performed by practitioners. Despite the breadth and depth of existing research for automating maintenance tasks, none of those ML and EC approaches have been addressed from the point of view of a \textit{self-adaptive technology}.
Self-adaptivity comprises the ability of a software system to assess and regulate its behavior\cite{Macias-Escriva2013Self-adaptiveApplications}. Recent progress in self-adaptivity investigates and develops sophisticated systems such as multi-agent software \cite{marl-book}, component-based software engineering \cite{10481576}, configurable systems \cite{ye2025distilledlifelongselfadaptationconfigurable}, and model-driven architectures \cite{10608368}. These systems can adapt their behavior in response to environmental changes (\eg new requirements, limited resources, or code changes). Remarkably, this adaptive capability has also been further studied in the context of Artificial Life (\alife) -particularly- with the introduction, definition, and formalization of \textbf{autopoietic systems}~\cite{Dorin2024Alife}.
%
%Natural Computing (NC) treats research problems from two perspectives \cite{Cossio2012HandbookComputing}: 1) human-design computing inspired by nature (e.g., Neural Networks, Genetic Algorithms, or Quantum Computation) \footnote{The code generation agents are designed with this perspective. They are implemented with Deep Learning techniques. This proposal does not have details of the code generation agents} and 2) computations taking place in nature (e.g., the computational nature of self-assembly, bacterial communication, or the nature of brain processes). The \textit{Program Genesis} problem can be addressed from the second approach since software modifications are potentially caused by both self-replication and self-organization behaviors. The self-replication process refers to the evolution of a program where a new and enhanced version of itself is produced. The self-organization process relates to the rules or strategies to keep the program under control and stable \footnote{This topic can be extended by Alan Turing theories about Morphogenesis.}. Nonetheless, this proposal is mainly concerned about the self-replication problem by engineering software architectures to embed dedicated units for self-construction. The described software architectures will incorporate computational characteristics based on living organisms. This architecture will allow common maintenance tasks (e.g., patching, refactoring, clone detection) to emerge from less complex agents.
%The kinetic beast, introduced by John von Neumman, represents a foundational computational theory aimed at simulating self-replication -a key property of living systems- through a universal constructor capable of replicating cellular automata. However, this model lacks the capacity for evolution, a limitation that Christopher Langton addressed by proposing a simpler self-replicating automation\cite{Langton1989ALife}. Subsequent research by Sayama \etal and Ikegami \etal explored the emergence of more realistic and complex self-replicating structures, advancing the field of Artificial Life (ALife)\cite{Bedau2007ArtificialLife}. Despite these theoretical advancements, ALife research has largely focused on conceptual experimental studies. At the intersection of ALife and software engineering, there is still a gap in the engineering of practical, evolvable software systems. This evolvable system is currently in the maintenance phase of the software development cycle (SDCL).
%The kinetic beast introduced by von Neumann is a computational theory attempt to simulate self-replication as a property of living systems. The von Neumann machine is a universal constructor for replicating a cellular automaton. The kinetic beast is unable to evolve. Langton realized such limitation and introduced a simpler self-replicating automaton version. Sayama \etal and Ikegami \etal studied the emergence of realistic and more complex self-replicating structures \cite{Bedau2007ArtificialLife}. Nevertheless, none of the Alife publications were oriented to engineer software systems.
\section{From Canonical to Self-Construction Life-Cycle}
\label{sec:position}
\begin{figure*}[ht]
\centering
\caption{Autopoietic Architecture \approach to enable artificial self-construction software life-cycle}
\includegraphics[width=0.95\textwidth]{figures/Architecture.pdf}
\label{fig:arch}
\vspace{-1.2em}
\end{figure*}
\input{tables/reasoning_unit}
%1. Present well-structured arguments supporting our position.
%In his tale \textit{-the last question-}, Isaac Asimov presented a self-replicating machine with the ability to answer any question of the universe.
Following Asimov's vision about a self-replicating machine~\cite{Asimov1956LastQuestion}, this paper examines the relationship between the premise \textit{software systems can self-replicate into a ``better, decentralized, and intelligent'' version of themselves} and the Software Development Life-Cycle (\sdlc). This self-replication process embodies the \textit{self-construction} of adapted internal mechanisms, which compose the original software, to attend an \textit{environment} of functional (\ie what the system should do) and non-functional (\ie how the system should perform) requirements.
Assuming the autopoietic automation vision, we must recognize and acknowledge the feasibility of a new type of autonomous architecture that leverages an artificial self-construction life-cycle and the FM's ability to understand code semantics and generate syntactically correct, functionally appropriate patches~\cite{wei2025swerladvancingllmreasoning}. We refer to this autonomous mechanism as \textit{Autopoietic Architectures} (\approach). To attain an artificial self-construction life-cycle paradigm, beyond the canonical perspective (see \autoref{fig:newD}-a), we argue that \approach can be used as a self-construction standard to implement systems whose \textit{self-replicating components} are calibrated and well communicated. This self-construction paradigm draws inspiration from the Von Neumann kinetic beast \cite{VonNeumann1951,VonNeumann1966} \footnote{Langton later enhanced this foundational model by introducing a simpler self-replicating automaton to address the problem of evolutionary capabilities \cite{Langton1989ALife}}.
The \approach embodies six self-replicating components: the main (or original) software, an instruction tape, three machines (\eg constructor, copy and control machines) and a reasoning unit. The self-replicating process starts when the control machine $\Lambda$ causes the copy machine $B$ to replicate the instruction tape $\Phi$.
%2. Use logical reasoning, facts, statistics, and examples.
The \textit{first} component encapsulates the original software to replicate $P$ (\autoref{fig:arch}-\circled{1}). $P_{type}$ refers to Lehman's categorization of software systems~\cite{Lehman1980ProgramsEvolution} that encompasses specified systems ($S$-Systems), problem-solving systems ($P$-Systems), and evolving systems ($E$-systems). The \textit{second} component (\autoref{fig:arch}-\circled{2}) consists of an \textit{instruction tape}, $\Phi$, which stores the meta-data of \approach. This meta-data contains detailed instructions on constructing the entire architecture from its source code. The instruction tape $\Phi$ could incorporate advanced, goal-oriented techniques for system maintenance (\ie automated refactoring, patching, repairing, and re-engineering processes). The \textit{third} component (\autoref{fig:arch}-\circled{3}) reflects a \textit{constructor machine}, denoted as $A$, which is responsible for reading any instruction $\phi$ from the instruction tape $\Phi$ to construct components. The \textit{fourth} component is a \textit{copy machine} $B$ (\autoref{fig:arch}-\circled{4}). $B$ can replicate $\Phi$ instruction, \ie $B$ can copy $\Phi$ meta-data -including $\Phi(B)$. The \textit{fifth} component is the control machine $\Lambda$ (\autoref{fig:arch}-\circled{5}). $\Lambda$ produces an isolated copy of $\Psi$ and communicates with the \textit{reasoning unit} $\Gamma$ (\autoref{fig:arch}-\circled{6}). $\Gamma$ is the \textit{sixth} and last component oracle that formulates causal questions to make decisions~\cite{Tucci2013IntroductionDo-Calculus}.
\begin{defn}
The copy process generates a $\Phi$ final instruction tape
\begin{equation}
B + \Phi(\Psi) \rightarrow \Phi(\Psi)
\end{equation}
where the operand `$+$' is the use of two components ($B$ and $\Phi$) and the operand `$\rightarrow$' is a realization or copy. In other words, $B$ takes the meta-data instructions and generates a copy of $\Phi(\Psi)$. Define $\Delta = A+B$. Thus, $\Psi$ would be the $\Delta + P$ composition. Replacing in the previous formula:
\begin{equation}
B + \Phi(\Delta + P) \rightarrow \Phi(\Delta + P)
\end{equation}
\end{defn}
\begin{defn}
Now, $\Lambda$ causes A to construct the components described by the instruction in $\Phi(\Psi)$.
The construction process generates a copy of $\Psi$
\begin{equation}
A + \Phi(\Psi) \rightarrow \Psi
\end{equation}
\end{defn}
%The fifth design (see \autoref{fig:arch}-e) includes the reason unit $\Gamma$. This component synchronizes the $A$ and $B$ machines to replicate the entire architecture. $\Gamma$ will take decisions about what is observed from $\Phi$. Such decision might activate self-replication to correct errors. I envision using Pearl's causal model to enable the decision making in three levels. These levels are associations, interventions and counterfactual conditionals. The reasoning unit might evolve itself since $\Gamma$ is embedded in $\Psi$ and will respond to specific software maintenance tasks. For instance, a reasoning unit $\Gamma_r$ that enhances refactoring modifications or a reasoning unit $\Gamma_u$ that applies rejuvenation (e.g., re-engineering or automatic patching) to the main software.
\begin{defn}
The control machine $\Lambda$ synchronizes the machines correctly to produce the tape $\Phi$ and the $\Psi$-Architecture by adding the copy of $\Phi(\Psi)$ to the new $\Psi$
\begin{equation}
A + B + \Gamma + \Phi(\Psi) \rightarrow \Psi + \Phi(\Psi)
\end{equation}
Now, let's include in the tape machine the information of the main software or $P$, the reasoning unit $\Gamma$, and rename the entire architecture as $\Psi_P$, therefore $\Delta= A + B + \Gamma$:
\begin{equation}
\Psi_P = \Delta + \Phi(\Delta+P) = A + B + \Gamma + \Phi(A + B + \Gamma + P)
\end{equation}
so we can observe that $\Psi_P \rightarrow A + B + \Gamma + P + \Phi(A + B + \Gamma + P)$
which means:
\begin{equation}
\Psi_P \rightarrow \Psi_P + P
\end{equation}
\end{defn}
Finally, after following previous definitions, we obtain the original software $P$, with the respective optimizations $P'$, and its instruction tape. $P$ is embedded in the autopoietic architecture \approach. Note that $P'$ optimizations originate from the reasoning unit $\Gamma$. $\Gamma$ introduces small instructions to the instruction tape so $\Phi(P)$ evolves to $P'$. $\Gamma$ can include other complementary maintainability tasks \eg performing control tasks, such as software traceability.
%3. Address counterarguments and refute them with evidence.
%Although autopoietic architectures \approach pose a promising self-construction framework, the vast majority of work in the \sdlc research field has focused on traditional (\ie canonical) maintenance tasks. Studies indicate that over 70\% of software lifecycle costs are attributed to maintenance and evolution efforts~\cite{895984,Lehman1980ProgramsEvolution}. Conversely, our autopoietic architectures \approach can leverage an artificial self-construction life-cycle that continuously monitors, modifies, and optimizes targeted software. These architectures encapsulate the original software system within an intelligent maintenance layer, operating as an autonomous entity.
%Maintenance is also seen as Software Evolution; the variable time $t$ plays an important role in \approach. We can keep track of the natural evolution of the original system across $t$. Ideally, the \approach should follow the laws of software evolution proposed by Lehman \cite{Lehman1980ProgramsEvolution}:
%\begin{itemize}[leftmargin=*, labelwidth=2pt, labelindent=1pt]
% \item \textit{Continuing change}: any software has two possible reactions across time: decay or change. The posed architecture can handle changes to automate the replacement of the targeted system -similar to Issac Asimov Multivac system.
% \item \textit{Increasing complexity}: an evolving software will increase its complexity too; however, the complexity term is very ambiguous in software engineering. This is why the second proposal will be oriented to self-organization \cite{Self-OrganizationReview.}.
% \item \textit{Fundamental law of program evolution}: the self-regulation of the program will be handled by a control unit embedded in the \approach too.
% \item \textit{Conservation of organizational stability}: the invariant work rate measured during the SDLC will be kept on track in the \approach.
% \item \textit{Conservation of familiarity}: the release content of the software is contained in a tape machine that serves as a repository.
%\end{itemize}
%An Autopoietic AI Architecture (\textit{AIArch}) is the abstraction of having a system taking care of another one (see \autoref{fig:newD}-b). This architectonic paradigm is motivated by the von Neumann machine design \cite{Bedau2007ArtificialLife}. The Autopoietic Architecture or $\Psi$-Architecture (or an organism according to von Neumann) will consist of six designs. The $\Psi$-Architecture wraps the main software $P$, which is the system with the core or direct functionality (see \autoref{fig:arch}-a). From the software engineering perspective, the D-Functionality can be conceived as any software that behaves under the Lehman categorization of systems: S-Systems, P-Systems, or E-Systems \cite{Lehman1980ProgramsEvolution}.
%however, can this architecture survive in an environment and extract useful source code (in the form of genetic code) from other systems or agent architecture?
This reasoning component $\Gamma$ is the most challenging to design as it comprises unique and necessary knowledge to address self-construction tasks. However, recent research has demonstrated the reasoning capabilities of FMs via prompt engineering and agent orchestration~\cite{toran_autogpt_2023}. To properly define this reasoning unit, we decompose it, as detailed in \autoref{table:reasoning}, into five key dimensions (\eg component representation, purpose, source of information, algorithm employed, and agent question).
In addition to those dimensions, we can classify reasoning tasks into three levels according to Pearl's causality approach: observation, intervention, and retrospection \cite{Pearl2009CausalOverview}. Firstly, the goal of the \textit{observation} level is to predict a maintenance task $M$ based on given evidence $\epsilon$. The prediction is a conditional distribution $p(M|\epsilon)$ where $M$ can be corrective $M_c$, adaptive $M_a$, perfective $M_p$, or preventive $M_v$ activity. Secondly, the \textit{intervention} level aims to measure the causal effect when the reasoning unit $\Gamma$ modifies a sub-component in $P$ to accomplish a maintenance task $M$. Finally, the \textit{retrospection} level aims to estimate the expected value of hypothetical conditions. For example, consider the reasoning unit $\Gamma$ performed an adaptive maintenance task $M_a$ with an observed result $Y=y$, but now the reasoning unit wants to assess what would have happened ($Y=?$) if, instead of $M_a$, the unit had performed $M_v$. The previous situation formally defines a counterfactual prediction. The reasoning unit can measure this hypothetical condition using the expected value $E(Y_{M=M_v} | M=M_a, Y=y)$.
\begin{table*}[!h]
\caption{The Reasoning Unit $\Gamma$ Depends Upon The Maintenance Task}
\vspace{-1.2em}
\label{table:reasoning}
\centering
\scalebox{0.75}{
%\setlength{\tabcolsep}{5pt}
%\begin{tabular}{l|lp{3.5in}}
%\begin{tabular}{lllp{3.6in}}
\def\arraystretch{1}\tabcolsep=10pt
\begin{tabular}{p{0.13\linewidth}p{0.32\linewidth}p{0.32\linewidth}p{0.32\linewidth}}
%\toprule
%\multicolumn{1}{c}{\textbf{Feature}} & \multicolumn{3}{c}{\textbf{Causal Reasoning Unit $\Gamma$}} \\ \hline
\multicolumn{1}{c}{\textbf{Dimension}} & \multicolumn{1}{c}{\textit{Observation}} & \multicolumn{1}{c}{\textit{Intervention}} & \multicolumn{1}{c}{\textit{Retrospection}} \\ \hline
\textbf{Representation} & Probability $p(M|\epsilon)$ & Causal Effect $do\{p(M|\epsilon)\}$ & Counterfactuals $E{[}Y_M|M,Y{]}$ \\
\textbf{Purpose} & Take decisions about maintenance tasks based on observations & To intervene in the architecture to assess the causal effect of a new replica & To imagine possible scenarios where a modification on the architecture takes place \\
\textbf{Source of Inf.} & Quality SE Metrics $\Pi$ & Traceability Links $L$, SE Metrics $\Pi$ & Depends upon the maintenance task $M$ \\
\textbf{Algorithm} & Variational Inference & Front/Back door adjustment & Front/Back door adjustment \\
\textbf{Agent Question} & What if the unit sees a metric $M$ under desired thresholds? & If the unit modifies a sub-component $P$ in the main system to fulfill a maintenance task $M$, will enhance a $\Pi$ metric? & What if the unit had assessed one possible maintenance solution $M$ that was not being considered before? \\ \hline
\end{tabular}%
}
\vspace{-1.2em}
\end{table*}
\section{Discussion \& Implications}
\label{sec:discussion}
%This section should focus on the following key aspects:
%1. Analyze the consequences of adopting or rejecting our position.
%2. Discuss policy implications, social impact, or ethical considerations.
The emergence of self-evolving and autonomous FM agents represents a natural evolution beyond the autopoietic architecture (\approach) framework presented in this work. Recent research demonstrates that FM-powered agents can transcend static, human-designed configurations to become adaptive systems capable of continuous self-improvement through interaction data and environmental feedback. These developments align closely with the self-construction paradigm proposed in \approach and suggest promising directions for extending the autopoietic software life-cycle.
Because the reasoning unit automates some maintenance tasks, a replica of the autopoietic architecture \approach serves as an enhanced copy of the original (\ie main) software. This enhancement formally represents what software researchers refer to as \textit{software evolution}\cite{10.1145/2593882.2593893}. In light of our autopoietic architecture \approach, the proposed work seeks to explore the following research questions (RQs):
\begin{itemize}[leftmargin=*, labelwidth=0pt, labelindent=0pt]
\item $RQ_1$ \textit{How effective is using \alife elements combined with foundation models to create software systems that exhibit self-construction behavior?} The effectiveness of \alife to create software systems that exhibit living features (\ie self-replication) has been widely studied \cite{Bedau2007ArtificialLife}. However, we require researching methodologies compatible with the software development life-cycle similar to the software transplantaton \cite{10.1145/3695987}.
\item $RQ_2$ \textit{To what extent is software maintenance automated under the autopoietic \approach scheme powered by foundation models?} We can measure maintenance levels in a software system by considering corrective, adaptive, perfective, and preventive tasks executed by FMs agents.
\item $RQ_3$ \textit{Should software designs have a dedicated component to self-construction?} This question explores if and when incorporating \alife elements in software design.
\item $RQ_4$ \textit{How can we migrate from canonical maintenance to self-construction maintenance paradigm?} We can leverage software engineering research to migrate any potential system to an autopoietic architecture \approach.
\end{itemize}
To address the RQs, developing and deploying \approach will require extensive expertise in training and programming \textit{AI-agents}. An increased interest in AI-agents has emerged in recent years; this technology has enhanced the performance of challenging tasks\cite{yang2024sweagentagentcomputerinterfacesenable,wang2024executablecodeactionselicit,jimenez2024swebenchlanguagemodelsresolve, qiu2025alitagselfevolvinggenerativeagent}. We believe AI-agents theory and practice can contribute to the implementation of the proposed self-replicating components. For example, the control mechanism could be an AI agent trained on architectural patterns data. This control agent can also formulate questions to or communicate with the reasoning unit, another independent agent.
While the exact nature of inputs and outputs within autopoietic architectures \approach remains uncertain, the overarching goal is clear: to enable self-construction and maintenance through replication and adaptability processes inspired by \alife. It may be observed that the proposed architecture does not account for possible security issues or any other type of non-functional constraints. %Moreover, the environmental variables are not studied in-depth.
%The EC opens a new field for artificial software engineering supported by the adoption of generative AI-based tools~\cite{lin_when_2024,mehrotra_integrity-based_2024}.
%To answer these questions, the development and deployment of the proposed architecture \approach will require extensive knowledge in agent programming since the \approach components can be addressed by specialized agents. This \approach starts with LLM agents' specialization on each \approach component's role. For instance, the control machine could be an LLM agent trained on architecture patterns. We are unsure what constitutes an input and output in \approach. However, the goal of the \approach is clear: to enable self-construction maintenance by using replication and adaptability processes from Natural Computation science.
%To start on this formulated paradigm of \approach, it is necessary to have better data quality for both, validate and specify the LLM agents' roles. For example, the instruction tape will require examples of good and bad architecture patterns. The software as an organism requires to self-adapt to its environment; therefore, it is necessary to collect and prune software architecture examples, software standards, patterns, and anti-patterns.
\section{Conclusion}
\label{sec:conclusion}
%This section should focus on:
%1. Summarize key points and reinforce our stance.
%2. Provide recommendations or a call to action!
Software maintenance and evolution are challenging activities in \sdlc that require the application of Artificial Life (\alife) techniques combined with FM capabilities to advance next-generation artificial software engineering. This positional paper highlights the benefits of closing the gap between \alife and Software Engineering research by formulating \textit{autopoietic architectures} to enable an artificial self-construction software life-cycle. The autopoietic architecture, namely \approach, aims to follow Lehman laws for software evolution on a \sdlc (\ie continuing change, self-regulation, stability). \approach elicits the next generation of artificial software engineers for new \sdlc activities (\ie prompt-engineering, agentAI monitoring, and LLMs for SE debugging). Furthermore, \approach requires architectural data and benchmarking to assess the extent of self-construction of the original software system. %, and deep research on components and reasoning unit formalization and validation.
%Artificially engineering software systems is a challenging research activity that requires the usage of natural computation techniques in the solution of the maintenance problems. Software engineering maintenance is conceived as an evolutionary process since the systems experience several modifications during the life cycle. These modification can be interpreted as natural occurrences of the system, in the same way evolutionary features appear in biological organisms. Natural computation is a sub-field in computer science that analyze biological organisms to enrich computational techniques. This document proposes to use such computational techniques to formulate automatic maintenance task embedded in main software systems.