12 hours ago July 19, 2026mrksbrg

FaREwell and Stay Relevant in the AI Era

This is a personal copy of a column published in IEEE Software (Jul/Aug 2026). Republished with permission.

For the past four years, I’ve had the honor of shepherding the Requirements department and sharing a wide range of Requirements Engineering (RE) topics. Through bimonthly columns, often presented by excellent guest columnists and sharp co-authors, we’ve explored the evolving role of RE. It’s hard to grasp that this is the 24th column I’ve contributed to. As I end my term, I reflect on the content we’ve published and place it in the context of the most rapidly evolving period of software engineering ever. – Markus Borg

Markus Borg

When I got the chance to take over the column in late 2021, I realized that a Requirements department under my helm would broaden its scope. I made this explicit in the joint handover column with my predecessor, Sarah Gregory, in 2022 [1]. Over the past four years, the department has moved beyond product requirements to also cover process and organizational requirements.

The department’s focus has shifted from RE as specification work to RE as strategic guidance under technological disruption. We have explored topics such as responsible development, open-source governance, and developer wellbeing. Looking back,  I also see a stronger focus on quality requirements than on functional ones.

Sarah handed over to me by introducing me as “working at the intersection of research and practice in a critical part of our discipline that was barely in its infancy five years ago.” The critical part was, of course, AI and machine learning (ML). What followed during my term as editor has been remarkable. I’m writing this piece from NVIDIA GTC 2026, arguably the most happening AI conference right now, and it’s hard to grasp the rapid, fundamental shift this general-purpose technology is driving.

When I started as editor for this department, 24 columns ago, using ML to extract insights from historical data was a major thing. Deep learning was well established and had beaten various benchmarks across fields such as vision, natural language processing, and signal processing. Back then, I still preferred calling it ML rather than AI.

Half a year after writing my first column, ChatGPT burst onto the scene and brought generative AI to the masses. I gave in, like many others, and started referring to it as AI. By 2025, agentic AI had taken off, and the level of automation had risen toward autonomy. In software engineering, the biggest disruptor is now coding agents – an alluring productivity solution that organizations increasingly adopt.

An Overview Against the AI Backdrop

In this column, we review the main clusters the Requirements department has covered over the past 24 issues. These must be understood in relation to major AI milestones in the software industry. We do so primarily from two complementary perspectives: a) adapting RE to develop AI systems and (RE4AI) and b) using AI to improve our RE practice (AI4RE).

The figure below shows a timeline with selected product releases representing recent AI milestones in software engineering. The vertical position of each icon reflects the citation count of each column.

  • A) GitHub Copilot: AI pair programming becomes mainstream.
  • B) ChatGPT: Conversational software work becomes normal.
  • C) Cursor: The rise of AI-native development environments.
  • D) Devin: The idea of the AI software engineer enters the mainstream.
  • E) Lovable: Vibe coding broadens who can participate in software creation.
  • F) Claude Code: Terminal-native coding agents enter developer workflows.

Above the timeline in Figure 1, the paper icons represent the Requirements columns (C1 to C24, see Table 1). As indicated by color, 15 out of 24 columns address one of these two perspectives. AI has shifted from being one topic among others to dominating the discussion toward the end of my term.

Note that all columns have been written at least three months before their publication dates. Logos above the paper icons indicate whether the corresponding product releases shown below the timeline are mentioned in each column. In some cases, we mentioned these products early. Next, we organize the department’s evolution into three phases: 1) RE4AI, 2) AI4RE, 3) Agents.

IDAuthor(s)Column TitleIssue Theme
C1Gregory, BorgLooking Back, Moving Forward: A HandoverBots in Software Engineering
C2Scharinger, Borg, Vogelsang, and OlssonCan RE Help Better Prepare Industrial AI for Commercial Scale?Software Engineering for AI
C3BorgPipeline Infrastructure Required to Meet the Requirements on AIInfrastructure as Code
C4BorgRequirements on Technical Debt: Dare to Specify Them!Hybrid Work
C5Borg, Aasa, Etemadi, and MonperrusHuman, What Must I Tell You?Explainable AI
C6FreyHow We Lead Successful Open-Source Collaborations in the Danish Public SectorOSS in the Public Sector
C7HotomskiMy REvelation: Unveiling an Unseen Career in RequirementsSoftware Careers
C8Zowghi and BanoWhat’s Missing in Requirements Engineering for Responsible AIEducation and Training
C9Wagner, Borg, and RunesonNavigating the Upcoming European Union AI ActObservability and Explainability
C10BorgRequirements Engineering and Large Language Models: Insights from a PanelAI in Education and Training
C11Dalpiaz and SteghöferWhere Requirements and Agility Meet: No Man’s Land or a Land of Opportunity?Industry-Academia Collaboration
C12Borg and GraziotinRequirements for Organizational Resilience: Engineering Developer HappinessWellbeing for Resilience
C13VogelsangFrom Specifications to Prompts: On the Future of Generative Large Language Models in Requirements EngineeringN/A
C14Sandahl, Regnell, and BorgThe Magazine at 40: Viewing Requirements Engineering Through a Ruby LensGenerative AI
C15Borg and RichterSentiment Analysis for the Masses: How LLMs Changed the GameMLOps
C16KochFrom Modeling to Simulation: A Head Start for Digital Ecosystem DesignDigitalization of Smart Ecosystems
C17MaidenGenerative Rules for More Creative Thinking About RequirementsCreativity
C18Tahvili and BorgExcel Isn’t a Process, and Not All ‘Intelligence’ Is SmartNext-Generation Software Testing
C19Borg, Beck, Beck, Jiménez, Kanellopoulos, and PenzenstadlerResponsible Requirements Engineering in a VUCA WorldQuantum Software
C20Borg, Bjarnason, and HedinVibe Coding and the New Prototyping PlaybookN/A
C21Steghöfer and BorgAn Abstraction is Worth a Thousand VibesAIWare and Foundation Models
C22Hawkings, Colin, Habli, and BorgSafe Machine Learning: Why Performance is Not EnoughSoftware Sustainability
C23Dobslaw, Gren, Borg, and SternerAI Transformation: Ready or Already?N/A
C24BorgFaREwell – and see you in the FutuRE!Impact of AI on Productivity

Requirements on AI Systems

We can see that the first AI-heavy columns were all about RE4AI. A common theme was responsible practices and engineering of AI systems. C8 is explicit about this already in the title, but the theme recurs in several other columns. C9 is an early contribution on how the EU approached responsible AI through regulation. C3 was published a year earlier, but is closely related, discussing the need for MLOps infrastructure to practically enable such regulation.

Also related to responsibility is C2, which argues that RE is a key driver for making AI solutions business-sustainable. Revenue remains an interesting topic in the AI era, where many actors have prioritized growth while venture capital is being burned. C5 addresses requirements on explainability when generating code with LLMs. Responsible engineering, like RE itself, is a broad concept.

In the first phase of my term, not every column touched upon AI. It was already an important topic, but not the only one in 2022 and 2023. The department also covered code quality requirements (C4), open-source software in the public sector (C6), and the RE profession itself (C7).

Generative AI Enters RE Work

We all remember when ChatGPT was released in November 2022, as it was all over the news. Despite this hype, it wasn’t until C10 that large language models were discussed as an AI4RE solution in the department. It was, however, a notable entry, summarizing a panel discussion from the International RE Conference in 2023. C10 has since become a well-cited account of early RE community reactions to LLMs. It captures debates on evaluation, creativity, and whether prompting might reshape RE practice.

In C13, Vogelsang argued that prompt engineering practically equals requirements engineering [2]. RE is largely about specifying intent clearly to achieve desired outcomes. Two other columns explored the use of LLMs for more specific RE activities. In C15, we examined sentiment analysis in more depth, and in C17, Maiden provided guidelines for using generative models to boost creativity.

As in the first phase, not every column mentioned AI. It was clearly a big topic, but still not pervasive. The department also covered topics such as agile requirements engineering (C11), organizational resilience (C12), and modelling digital ecosystems (C16). Often aligning with the themes of the corresponding IEEE Software issues, as shown in the table above.

Agents, Vibing, and Some Tension

In the latter phase of my term, the milestones on the timeline in Figure 1 relate to letting go of control. Already in 2024, Devin was introduced as an “AI software engineer” (accompanied by some overhyped demos), but the agentic era truly took off a year later with the release of Claude Code. In between, Lovable emerged, showing that the world had been waiting for vibe coding (Lovable is currently at $400M USD in annual recurring revenue). In C20, we were fortunate to co-author a column with one of its founders, presenting how vibe coding can revolutionize prototyping.

If the reader hadn’t yet sensed mixed messages,  it became evident in this phase. Over the years, several columns argued that RE should act as the adult in the room, disciplining AI systems (for example, C18, C19, and C21). In other columns, we presented how RE can leverage disruptive AI technologies. In the first corner: rigor, safety, regulation, process, and responsibility. In the other corner: vibes, prompts, creativity, transformation, and new playbooks.

How can a department sending such mixed signals be taken seriously? As always in software engineering, the viability of a solution depends on context. There is room for both! A discipline built on clarity and explicitness can still make use of probabilistic tools, informal prompting, and rapid experimentation. I know readers have felt the friction, but I believe such debates are valuable for our discipline. Friction is part of the learning process. I hope the department has made it clear that AI doesn’t remove the need to understand the problem, and that RE shouldn’t be reduced to prompting hype when developing production-grade systems.

The Return of Specifications

As I’ve broadened the scope of the Requirements department, some traditional RE topics have inevitably received less attention. Some readers would have preferred more coverage of classical RE topics such as prioritization, negotiation, traceability, modeling, validation, and stakeholder analysis. However, for those of you invested in the craft of specification and “writing good requirements,” there is good news on the horizon. As noted in Vogelsang’s column (C13), “prompt engineering is requirements engineering” [2]. While prompt engineering might be less central these days – first replaced by context engineering and now by specifying agent instructions – the importance of clearly communicating intent to AI, a new and critically important stakeholder, remains a key skill.

“the importance of clearly communicating intent to AI, a new and critically important stakeholder, remains a key skill”

A renewed focus on high-quality specifications has emerged in the AI era. Recently, GitHub released Spec Kit as an open-source toolkit to structure requirements, specifications, plans, and tasks into workflows that guide AI-assisted implementation. Several alternative approaches have also appeared, reinforcing the growing demand for clear, unambiguous specs. This shift is reflected in a recent Thoughtworks retreat summary [3], which argues that as software development becomes AI-assisted, code can no longer be the primary carrier of engineering intent. Instead, that intent moves upstream and must be expressed in requirements-grade artifacts.

Will there be requirements in the future? Of course. As I wrote in my first column [1], requirements don’t care whether you deal with them or not. In contrast to other constituents of software engineering, they are there even if you don’t want to look their way. And if you don’t manage them at all, your users will let you know!

The winds of change are also blowing in this department. The Requirements department has been part of IEEE Software since 2001 – clearly one of the longest-running in the magazine’s history. How the RE perspective will be represented going forward will continue to evolve. Please reach out to the magazine with feedback and ideas for the future.

Finally, I would like to thank all collaborators I’ve worked with. I also thank all readers of this department over the years for your encouraging words and feedback. See you out there in the community. Until then, FaREwell! And hold on to your requirements.

References

Similar Publications