AI-Augmentation of Software Development: Use Cases

Posted by 0Comments 0Likes

AI-Augmentation of Software Development: Use Cases

This blog posting shares what I see as the common use cases for AI-augmentation of software development. Figure 1 overviews these use cases and Table 1 describes them. There are several key features of Figure 1:

  1. It’s a mapping, not a lifecycle. The diagram indicates the main categories of work in software development and maps AI-augmentation use cases to them.
  2. It focuses on software development. I haven’t included all of the typical white-collar worker use cases around writing reports or presentations, only the use cases specific to software development.
  3. The wording is key. It’s important to note how I’ve worded the use cases, using terms like potential and suggest. This is because you need to “keep humans in the loop”, working in such a way that a person validates the output of an AI, updates it as appropriate, then commits it to your overall asset base. An implication of this is that the human in the loop needs to be sufficiently competent to judge the AI’s output. When the output of the AI is large the human in the loop may need to use another AI-based tool to help them analyze the output of the first AI-based tool.

Figure 1. Potential opportunities for AI-augmentation in software development (click to enlarge).

AI-augmentation of software development - Use cases

Table 1. Software development AI-augmentation use cases in context.

 

Use Case Advantages Disadvantages
Analyze existing implementation. Software developers often need to work with existing, legacy code that they are unfamiliar with or in some cases have forgotten about even though they wrote it. Tooling such as SonarQube and CAST SBOM Manager help developers to navigate the complexities of existing implementations.
  • Enables developers to navigate complexities of legacy code.
  • Pinpoints potential problems in your code.
  • Thoroughness: The AI is likely to perform a more thorough job than people would.
  • Trustworthiness: The AI is less likely to be biased than individuals in what it produces.
  • Accuracy risk: Although AIs can often be built with greater accuracy than people, they still aren’t perfect and any results shouldn’t be taken verbatim.
  • Intellectual property (IP) risk: Is the AI retaining your IP after use?
  • Privacy risk: Are you providing personal identifying information (PII) to the AI?
Brainstorm potential requirements. I often want to brainstorm requirements with my stakeholders. We’ll do this for both potential high-level ideas during scoping as well as later during construction to identify potential details. Asking an AI to suggest ideas is like having another experienced voice in the room.  Although large language model (LLM) such as ChatGPT or Gemini will do, an LLM aggregator such as Poe provides a flexible option.
  • Provides input into discussions with stakeholders about their requirements.
  • Greater range: The AI is likely trained on a greater range of examples and contexts than that experienced by the people on your team, potentially giving a more robust result.
  • Trustworthiness (see above).
  • Doesn’t remove the need to work closely with stakeholders to understand their actual needs.
  • The AI isn’t producing unique ideas, merely repeating what it has seen before.
  • IP risk (see above).
Explain status and trends. For over a decade software teams have been using dashboard technologies to monitor and report their progress. While this is a great idea in theory, in practice it assumes that people understand the information that is being presented to them.  Good luck with that. Luckily AI-based tooling such as Qlik Sense exist to explain the results of your analytics.
  • Increases the chance that the users of data products such as dashboards or reports understand the implications of the information being presented.
  • Greater range (see above).
  • Thoroughness (see above).
  • Trustworthiness (see above).
  • Unless the tooling is specifically trained for software development metrics, you will need to invest time training it.
  • Accuracy risk (see above).
  • IP risk (see above).
Generate potential code. I will often use an LLM such as Bing to suggest code examples or improvements to a snippet of code that I’ve written. Many developers will use editors such as Github Copilot, or plug-ins to their preferred IDE, that effectively pair program with you. Note that it isn’t just about application code.  For example, products like Harness.io create delivery scripts and Flow.bi for creating DataVault2-compliant raw data vaults to enable continuous data warehousing. And I need to give a shout out to Brave CodeLLM which does so privately and provides explanations of the code that it produces.
  • Increases the rate at which code is written.
  • Potential for developers to become proficient with a language quicker.
  • Greater range (see above).
  • Doesn’t turn bad programmers into good ones.
  • Code quality decreases the more code that is generated at any one time, so my recommendation is to incrementally generate and validate a few lines at a time.
  • Accuracy risk (see above).
  • IP risk (see above).
Generate potential documentation. First and foremost, do your best to write clean, literate code that requires minimal documentation. Second, you’re always going to need some code documentation, particularly why you wrote what you did. Where any LLM will do for this, there are products such as Mintlify that are specifically built to generate documentation from your code.
  • Increased documentation accuracy when you generate it just in time (JIT), ideally when you consider evolving your implementation.
  • Can generate documentation for regulatory compliance purposes.
  • Thoroughness (see above).
  • Existing, “legacy” documentation tends to be out of sync with the implementation. You are generally better off writing clean, literate code that doesn’t require documentation.
  • The most important thing to document is why you did what you did, something the AI can’t generate.
  • Accuracy risk (see above).
  • IP risk (see above).
  • Privacy risk (see above).
Generate potential tests. It is possible, and mostly desirable, to generate tests (or more accurately automate checks) from various artifacts. For example, you can generate acceptance tests and quality of service (QoS) tests from requirement descriptions. Unit and integration tests can be generated from existing code and scripts. Furthermore, tooling such as TestRigor enables you to create acceptance and UI-level integration tests from English prose.
  • Can generate tests to use as executable specifications.
  • Greater range (see above).
  • Thoroughness (see above).
  • Trustworthiness (see above).
  • Accuracy risk (see above).
  • IP risk (see above).
  • Privacy risk (see above).
Guesstimate schedule and budget. Like it or not, software developers are often asked to provide schedule and cost estimates for the current release that they are working on. Products like CostGPT step you through a series of relevant questions and then produce the basis for a guesstimate.
  • Likely to consider a more comprehensive range of issues than people do.
  • Automates bureaucracy that developers typically don’t like nor are very good at.
  • Trustworthiness (see above).
  • Very difficult to be accurate because of the bespoke nature of requirements, significant variation in developer skills, and evolution in tooling and technology.
  • Accuracy risk (see above).
  • IP risk (see above).
Identify technical debt. Technical debt refers to quality issues within your system infrastructure, potentially pertaining to architecture, design, or implementation. Technical debt is mistakenly thought of as just a source code problem, but the concept is also applicable to source data (this is referred to as data debt) as well as your validation assets.
  • Pinpoints aspects of your implementation that potentially should be improved.
  • Greater range (see above).
  • Thoroughness (see above).
  • Trustworthiness (see above).
  • Accuracy risk (see above).
  • IP risk (see above).
  • Privacy risk (see above).
Suggest potential strategies. Software developers can work with LLMs to suggest potential architecture, technical design, and UI design strategies for what they’re building. Modeling tool vendors are building copilot/advisor functionality into their offerings as well.
  • Greater range (see above).
  • Trustworthiness (see above).
  • Accuracy risk (see above).
  • IP risk (see above).
  • Privacy risk (see above).
Suggest potential WoW improvements. Effective software developers choose to improve their way of working (WoW) based on their learnings over time. Techniques such as retrospectives can be used to identify and explore challenges that you’re facing and even identify potential improvements. AI-based tooling such as Effilix will process transcripts from such discussions, transcripts which themselves can be generated via AI-based tooling, to generate potential WoW improvements that your team might choose to adopt. This enables your team to adopt a guided continuous improvement (GCI) strategy and your organization’s coaches and project managers to extend their range
  • Greater range (see above).
  • Thoroughness (see above).
  • Trustworthiness (see above).
  • Accuracy risk (see above).
  • IP risk (see above).
  • Privacy risk (see above).
Suggest potential quality improvements. AI has been used for years to analyze existing systems to identify potential opportunities to improve the quality. SonarQube, CAST SQG and BlackDuck’s Coverity Static Analysis statically analyze existing code. Applitools Visual AI dynamically finds user interface (UI) bugs and Veracode’s DAST to find runtime vulnerabilities in web apps.
  • Greater range (see above).
  • Thoroughness (see above).
  • Trustworthiness (see above).
  • Accuracy risk (see above).
  • IP risk (see above).
  • Privacy risk (see above).
Validate implementation. Many of us work in organizations that have common guidelines and standards that we are expected to follow, and increasingly in environments where regulatory compliance is required. Many of the products for suggesting potential quality improvements are applicable for this. Furthermore, products such as Compliance.ai can identify and help you to understand your obligations under applicable regulations.
  • Greater range (see above).
  • Thoroughness (see above).
  • Trustworthiness (see above).
  • Accuracy risk (see above).
  • IP risk (see above).
  • Privacy risk (see above).
Visualize existing implementation.Software developers regularly work with legacy implementations that they need to leverage and often evolve. This software is often complex, using a myriad of technologies for reasons that have been forgotten over time. Tools such as CAST Imaging visualizes existing code and ChartDB visualizes legacy data schemas to provide a “birds-eye view” of the actual situation that you face.
  • Thoroughness (see above).
  • Trustworthiness (see above).
  • Accuracy risk (see above).
  • IP risk (see above).
  • Privacy risk (see above).
Visualize potential workflows.When software developers extend existing systems they need to ensure that what they are doing fits into the existing workflow appropriately. Visualization tools such as Decisions Process Mining analyze existing systems and visualize the supported workflow. Existing workflow modeling tools are also adding AI-based functionality to do the similar things.
  • Thoroughness (see above).
  • Trustworthiness (see above).
  • Accuracy risk (see above).
  • IP risk (see above).
  • Privacy risk (see above).

Those use cases all make a lot of sense, but that doesn’t mean that all of them are applicable to you, at least not right now, given whatever situation that you face. You want to adopt the right strategies, and select the right tooling that supports those strategies, for you and your team. Table 1 puts each use case into context by indicating their advantages and disadvantages. We took this sort of approach in Disciplined Agile (DA) years ago, and I am in the process of doing so with both Agile Data and Agile Modeling techniques. All techniques are contextual in nature, working well in some situations and not so well in others. By understanding the trade-offs associated with a technique you can better judge whether it may work for you in your environment.

Tags: ,

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.