Jiahuei (Justina) Lin

“Vibe coding” represents a paradigm shift where non-technical users, or “software makers”, create applications by describing the desired outcome, focusing entirely on the final output rather than the underlying code. This movement, propelled by hyper-growth platforms like Lovable, Bubble, and Glide, actualizes the vision of “AIware”: software for all, by all. However, this remarkable progress is currently confined to applications of limited complexity and introduces significant risks of unreliability and failure. This 90-minute technical briefing introduces Vibe Engineering, a structured framework for AI-assisted software creation that goes beyond one-shot prompts. The framework operates by defining roles, specifying artifacts, and orchestrating a repeatable process. It is built on two foundational pillars: (1) Intent Engineering, which focuses on deeply understanding user needs through multi-agent dialogues, Theory of Mind (ToM) principles, and test-driven requirement refinement; and (2) Realization Engineering, a specialized Agent Execution Environment (AEE) where multi-agent teams autonomously build, test, and verify the software based on the user’s validated intent. This briefing provides an insider’s view of the technical challenges in this domain and surfaces concrete software engineering research opportunities.

Foundation models (FMs), such as Large Language Models (LLMs), have revolutionized software development by enabling new use cases and business models. We refer to software built using FMs as FMware. The unique properties of FMware (e.g., prompts, agents and the need for orchestration), coupled with the intrinsic limitations of FMs (e.g., hallucination) lead to a completely new set of software engineering challenges. Based on our industrial experience, we identified ten key SE4FMware challenges that have caused enterprise FMware development to be unproductive, costly, and risky. For each of those challenges, we state the path for innovation that we envision. We hope that the disclosure of the challenges will not only raise awareness but also promote deeper and further discussions, knowledge sharing, and innovative solutions.

One can extend the features of a software system by installing a set of additional components called plugins. WordPress, as a typical example of such plugin-based software ecosystems, is used by millions of websites and has a large number (i.e., 54,777) of available plugins. These plugin-based software ecosystems are different from traditional ecosystems (e.g., NPM dependencies) in a sense that there is a high coupling between a platform and its plugins, compared to traditional ecosystems for which components might not necessarily depend on each other (e.g., NPM libraries do not depend on a specific version of NPM or a specific version of a client software system). The high coupling between a plugin and its platform and other plugins causes incompatibility issues that occur during the co-evolution of a plugin and its platform as well as other plugins. In fact, incompatibility issues represent a major challenge when upgrading WordPress or its plugins. According to our study of the top 500 most-released WordPress plugins, we observe that incompatibility issues represent the 3^rd major cause for bad releases, which are rapidly (within the next 24 hours) fixed via urgent releases. 32% of these incompatibilities are between a plugin and WordPress while 19% are between peer plugins. In this paper, we study how plugins co-evolve with the underlying platform as well as other plugins, in an effort to understand the practices that are related support such co-evolution and reduce incompatibility issues. In particular, we investigate how plugins support the latest available versions of WordPress, as well as how plugins are related to each other, and how they co-evolve. We observe that a plugin’s support of new versions of WordPress with a large amount of code change is risky, as the releases which declare such support have a higher chance to be followed by an urgent release compared to ordinary releases. Although plugins support the latest WordPress version, plugin developers omit important changes such as deleting the use of removed WordPress APIs, which are removed a median of 873 days after the APIs have been removed from the source code of WordPress. Plugins introduce new releases that are made according to a median of 5 other plugins, which we refer to as peer-triggered releases. A median of 20% of the peer-triggered releases are urgent releases that fix problems in their previous releases. The most common goal of peer-triggered releases is the fixing of incompatibility issues that a plugin detects as late as after a median of 36 days since the last release of another plugin. Our work sheds light into the co-evolution of WordPress plugins with their platform as well as peer plugins in an effort to uncover the practices of plugin evolution, so WordPress can accordingly design approaches to avoid incompatibility issues.