GenAI for Software Engineering: "If you can specify it, I can synthesise it"


Will AI agents become integral members of software engineering teams?

I recently attended the ESEC/FSE conference in San Francisco, where one of the keynote talks was titled "Towards AI-driven software development: challenges and lessons from the field" and delivered by Professor Eran Yahav from Technion. This post summarises my notes on the key messages of the talk.

Part of the context for the talk was a recognition that generative artificial intelligence (GenAI) technologies are seeing increasing usage across all stages of the software development lifecycle. Of course, the extent to which they are used is not uniform across all stages, with the most significant usage being for code and test generation. However, as demonstrated by some of the papers presented in other sessions of the conference, the step change in capability realised by the public release of LLMs over the past year has led to researchers exploring the use of GenAI in deployment and maintenance scenarios, for example generating outage reports based on runtime log information (Jin et al., 2023), and automating program repair (Wei et al., 2023).

A key point is that automation will be partial, with tasks like generating code based on converting requirements into specifications fully automated, and an emphasis on human-machine teaming for key tasks like requirements elaboration and acceptance testing. Such teaming requires the ability to precisely specify the task for the machine, suggesting a future where GenAI agents can say "If you can specify it, I can synthesise it". However, this is only worth doing if the agent can also satisfy the 'rule of delegation':

Cost of specification (input) + Cost of consumption (output) << Cost of manual work

 To satisfy this, the mechanism for communication between the human software engineer and the AI agent is a key aspect. The agent should be: 

  • concise: both input and output should be precise and short, working across different abstraction levels (i.e. input can be a specification at a different abstraction level from output). Similarly, modalities of input and output can be different (e.g., object model diagram in, code out). 
  • reliable: giving human software engineers confidence that the output is correct without needing to expend lots of effort to verify it. Structuring the output appropriately, providing explanations, etc., can all help reduce this aspect of the cost of consumption.
  • inquisitive: the agent should be able to explore the input/output space and get help from the human software engineer to verify the relevance of outputs to the task. Analogous to programming by example.
  • reflective (self-aware): requires long-term memory to learn from past interactions and user feedback on performance, as well as self-evaluation of performance (links to inquisitiveness). Currently, this is not a property of GenAI-driven agents.
  • personalised: the interaction of the agent should be tailored to the needs of the human software engineer.
The integration of GenAI agents into the software engineering process also has implications for the architecture of software engineering tools (and any software that uses LLMs as its base processing layer). The architecture of these systems would be composed of agent programs that interact with a long-term memory layer, a context layer, and a LLM layer. 

Architecture for GenAI Agent Systems

It was suggested that these layers are analogous to the main memory, registers, and CPU of a classical computing architecture. Taking this analogy further, the CPU itself would likely be replaced by several application-specific integrated circuits (ASICs), which maps to the idea that instead of a monolithic general LLM, the architecture would integrate several specialised LLMs that are used depending on the context of the task being performed. The rationale for this is that the smaller models offer better performance, flexibility, etc. It also allows the GenAI agents to be customised to the problem and solution domains of the software engineering team. This architecture also suggests the need for an adaptive management layer to help monitor and change the structure and behaviour of the specialised LLMs depending on the context and quality requirements that need to be satisfied.

One key observation following the talk was that it focussed on the software development lifecycle stages from development onwards, with little to no consideration of requirements elicitation, analysis and system design. However, it wasn't because these were not considered relevant or important, but rather because they were not the speaker's main area of work.  The talk also didn't address the challenges of 'supervisory control' if the GenAI agent is allowed to independently evolve the code (e.g., automatically patching code following failures) where automation can make it harder for the human software engineer to make sense of the codebase when the agent is no longer able to cope.

A broader summary of the use of GenAI in software engineering was presented by Miroslaw Staron from the University of Gothenburg at a recent reporting workshop: 

Additionally, several papers present surveys of the various applications of AI/ML to software engineering, including:

  • Hou, Xinyi, et al. "Large language models for software engineering: A systematic literature review." arXiv preprint arXiv:2308.10620 (2023).
  • Fan, Angela, et al. "Large language models for software engineering: Survey and open problems." arXiv preprint arXiv:2310.03533 (2023).
  • Ozkaya, Ipek. "Application of Large Language Models to Software Engineering Tasks: Opportunities, Risks, and Implications." IEEE Software 40.3 (2023): 4-8.


Acknowledgements: 
Title image created by OpenAI's DALL-E, generated on 15 Dec 2023.


Comments

Post a Comment

Popular posts from this blog

Cloud Wedge - geek of the week

Image
CloudWedge: 'Geek of the Week' My colleague Yijun Yu recently wrote a opinion piece for The Conversation about how cloud computing could have made a difference to the search for Malayian Airlines MH370.  Essentially the question he poses is: why, in the age of global internet connectivity (including now onboard planes!), do we depend on the onboard flight data recorder for information about what happens on a plane? Of course there are numerous challenges with this - not least the cost of bandwidth for all the flight data (including cockpit audio) to be uploaded in real time and the security of the data.  Yijun's article addresses some aspects of the latter, and the former is not an insurmountable problem.  For example it should be possible to upload basic flight telemetry (e.g., GPS location, air speed, engine statistics and fuel data) without requiring significant bandwidth.  Indeed aero engine manufacturers such as Rolls-Royce deployed engine monitoring ...
Read more

Priming Code Club

Code Club Assembly Presentation from akbandara As part of my work with STEMnet, I recently signed up as a CodeClub volunteer at St. Bernadette's Catholic Primary School in Milton Keynes.  Working with Kate Clarke, the ICT leader at the school, I am going to be leading an after-school club that will introduce kids in Year 5 and Year 6 to the exciting world of programming.  CodeClub is a nationwide, volunteer driven, grass-roots movement to get kids learning about the fun that can be had programming computers, rather than simply using them. In order to give the kids some idea about what they might be letting themselves in for, last week I delivered the short presentation (embedded above) at the school.  I started out by getting the kids to identify different computers, and think about what a computer really does, i.e. follows a set of instructions to complete a task.  We then played with a neat little iPad game called 'Kodable' which allows the player t...
Read more

Cyber security by the rest of us ...

Image
Breakdown of cyber crime types reported by learners in Week 1 As part of the Introduction to Cyber Security MOOC , we asked learners to review their computer security practices at the start of their learning by completing a simple online survey / self-audit.  Over 9100 learners completed the survey in Week 1 of the course, highlighting some interesting findings. For example, although 84% of respondents had configured their computers to require a password on startup, 30% did not 'lock' their computer so that it required the password to be re-entered if they left it unattended. With regard to password management, 55% of respondents depended on their memory for storing passwords, whereas 26% used software (password manager / web browser) to manage their passwords.  It is noteworthy that 18% reported that they write their passwords down and 59% reuse the same username / password across multiple websites. It was reassuring to note that 90% of learners who completed the...
Read more