Table of contents
Introduction
GenAI code has the potential to unlock extraordinary benefits in the Software Development Lifecycle (SDLC) for both coders and organizations.
Developers can stay in their flow state, experiment, and fix code, with lower cognitive load. At the organizational level, McKinsey estimates that there could be a $1T economic impact thanks to greater productivity.
Beginning in 2021 and ramping up through 2023, companies have begun experimenting with GenAI for code through developer-specific tools like GitHub CoPilot and general tools like ChatGPT that work on human language as well as computer languages. Well over 10,000 organizations have become paying users of CoPilot's enterprise version.
A closer look reveals that despite this usage growth, we are solidly still in the experimentation phase. Most engineers have access to one or more GenAI coding tools but varying guidance on how much to use them. Engineering leaders have little insight into usage levels with an even more vague understanding that regulatory and compliance requirements could have a huge, negative, impact on their businesses. As one CTO told us:
“I don’t want to wake up one day and realize our code isn’t ‘ours’ thanks to GenAI.”
As a result of this lack of visibility into activity and compliance standards, engineering organizations understandably treaded lightly in 2023.
To address this challenge, our team at Sema has analyzed hundreds of potential compliance guidelines that organizations will face, or are already facing, with respect to GenAI code. Based on this foundation, we have built a cutting-edge method to detect GenAI usage in codebases, using GenAI along the way to create it. This solution is an extension of our 7 years of experience working with >800 organizations, valued in excess of $1T, to assess the health of their codebases.
We cannot guarantee the future, and what follows most certainly is not legal advice. From our research to date, we are, with a degree of confidence, able to recommend best practices for organizations seeking to implement GenAI code across the SDLC in 2024 and beyond.
The remaining sections of this guide establish, exactly, how.
Part 1 is about laying the foundation. If an organization is contemplating adopting or expanding GenAI code, there are four recommended steps to take immediately, to increase the likelihood of success. Establishing or working with a Developer Council, for example, is the most important step.
Part 2 shares six recommendations to align the team to begin to realize the productivity gains and manage the compliance risks. These six steps are applicable to every software team when thinking about GenAI code. The most important principle deciding if and where GenAI is right for your organization’s SDLC.
As we share these recommendations, we provide a Quick Start guide. Specifically, we include a sample set of GenAI code usage metrics your teams can use, based on a hypothetical “Company Z” example -- a midsized company building software for manufacturers (i.e. not in a heavily regulated industry)
Part 1—Laying the Foundation. Four steps to get the organization on track for GenAI in the SDLC.
If an organization is contemplating adopting or expanding GenAI for code, there are four steps it should take now to make those efforts more successful.
Step 1. Create or contribute to a Developer Council.
In Sema’s developers’ hundreds of years of experience, and from our years of working professionally with thousands of developers, the most important guiding principle about helping developers be their best is this:
Code is a craft, not a competition.
Coders know that designing, implementing, and troubleshooting software is painstaking, precise work that can take all of their energy and focus. Comp and perks from being a software developer certainly can be very nice, but the core satisfaction comes from building the right thing well, not defeating others working on the same product.
At the organizational level, the focus on developer productivity and velocity are understandably necessary. However, there is a potential cost to the work and quality of (work) life for developers. The key to striking the right balance is to respect the craft of code by involving engineers early and deeply in any efforts to change tools, workflows, and goals. In order to maximize the likelihood of success for a change that is, albeit, necessary, developers need a say in what it takes to do their best.
In the GenAI for code context, we are strong proponents of establishing a Developer Council. Given that code is a craft, it makes sense that craftspeople have a keen interest in shaping their guild. It’s the rationale behind the World Wide Web Consortium (W3C), all the way to smaller, in-house panels.
Diverse voices are key on any council to make sure that any plans for GenAI reflect an organization’s perspectives. This means diversity of background but also sentiment and experience. We recommend at least one developer from each of these four groups. Readers of management literature will recognize this as the Skill-Will Matrix, originally from Landsberg’s 2015 book, The Tao of Coaching.
Lodestars have deep subject matter expertise in software development and therefore are better equipped to put this new tool to work.
Too, Lodestars, for whatever set of reasons, believe that GenAI can deliver real benefits to themselves and their peers.
Adventurers do not have the same level of skill and expertise as Lodestars, but they are similarly excited. This means they are at risk of making well-intentioned but incorrect uses of GenAI relative to their personal development as coders and also to the organization’s goals.
It is an easy trap to fill a GenAI Developer Council with advocates, Lodestars and Adventurers. But it is still a trap—excluding them will mean solutions that don’t work for everyone.
Some developers have skepticism about GenAI, even if they aren’t upfront about it.
Within this low or lower enthusiasm group, Questioners are experienced Engineers. They’ve been around long enough to see so-called “good ideas” come and go.
Novices are just getting their sea legs as coders and may not know where to start.
With respect to a GenAI Developer Council, these perspectives are important and valuable to include, particularly when testing the strength and integrity of a new suggestion for the organization.
Step 2. Expose the Developer Council to what’s on the Executive Leadership’s GenAI agenda and concerns
C-suites, General Counsel, and Compliance Leaders are giving careful consideration to GenAI.
It’s likely very unusual for Legal Counsel, CEOs, or department leaders, to sit down with developers to discuss developer tooling. See Step 1 above—as craftspeople, developers can and should decide their own tools the vast majority of the time.
But GenAI is not just another management fad. In the view of our team at Sema, GenAI is, quite possibly, the most important contribution to developer effectiveness since, or even more than Open Source.
And the implications for the organization’s legal risk, security and strategy are significant.
To help the Developer Council make the right choices on informing the use of GenAI, the 10,000 foot view must be clear.
Step 3. Create a safe space for provocative questions
It’s likely that developers may be keeping their thoughts and concerns to themselves. This silence creates risk—risk that serious issues won’t be addressed and risk that developers won’t be heard and therefore won’t buy in. As psychological safety is known to be linked with performance at work, it’s critical to open a channel for developers to share doubts, criticisms, and concerns. Organizations can consider anonymous Slack / Teams channels or appointing trusted peers or managers who will receive questions and pass them along without attribution.
For us, the most compelling example of this phenomenon comes from… Sema.
At our own organization, we are wrestling with, researching, and building topics related to GenAI for code. We regularly discuss the benefits of GenAI code in our engineering workflows.
And yet, many months into our work, one of our most vocal and most trusted engineers came to our head of engineering and asked if it was ok for him to use one of the recommended GenAI tools.
When we dug in deeper with him, we realized he had been questioning his professional identity— “if I use GenAI, does that make me a real developer?” No developer would say that about Open Source code, decades into its widespread use. But GenAI is just at the beginning of the adoption curve.
Thankfully, that developer is now an advocate for GenAI usage – and for encouraging others to speak their mind, too.
Step 4. Put a mechanism in place to understand changing compliance standards
Finally, organizations would be wise to begin tracking changing regulations, legislation, and other stakeholder requirements about GenAI code.
The reason is that certain potential or actual compliance standards could have big implications for appropriate use of GenAI for code and could potentially lead to significant code rewrites or other forms of company risk.
Information pertaining to changing regulations and legislation can come from IP-focused law firms and trade associations. Sema regularly publishes an AI Code Compliance Newsletter that tracks important regulatory updates to follow.
We’ve highlighted some general trends below. Again, please note that this is information not legal advice, and you should always connect with your counsel to evaluate best practices and risks for your own organization
- As a Stanford University study determined, GenAI code is less secure than code written by individual developers. The implication for organizations is that GenAI code must get the same or greater scrutiny from SAST/ DAST tools as the rest of their code.
- The more that developers copy-paste GenAI code, the more likely it is that the code will not get legal protections like copyright. Copyright offices have already declared that 100% “pure” GenAI works will not get legal protection, they have not clearly set the threshold for how much human involved is required.. To be safe, high priority code should be modified, or “blended” by developers.
- The more regulated your industry, the more specific and potentially restrictive the rules will be about GenAI code. Compliance changes are already in flight from the FDA, for example. Organizations in life sciences, financial services, and defense, among others, should proceed cautiously.
- Companies should prepare to demonstrate their GenAI usage—the GenAI provenance of the code—to any external stakeholder that asks for Open Source composition or a Software Bill of Materials. Why? GenAI code is code used in your codebase that’s not created by your developers—just like Open Source. And like Open Source, it adds risks along with benefits.
Who are these external stakeholders? Some acquirers and investors will have GenAI assessment in the first half of 2024 as part of technical due diligence. Insurance products such as Reps and Warranties insurance, and complex procurement offices will likely be following suit.
Part 2—How should developers use GenAI while coding?
With a few foundational blocks in place, we can now turn to how much, exactly, developers should use GenAI while coding.
A Developer Council (Step 1) can help determine the right levels of GenAI usage while encouraging and supporting implementation. And creating standards without developer input dramatically limits the likelihood of success of any such standards effort.
Exposing the Developer Council to what’s on the Executive Leadership’s GenAI agenda and concerns (Step 2) makes it more likely that all of the decision makers about GenAI are doing so with the full picture in mind.
Creating a safe space for provocative questions (Step 3) helps address implementation concerns and pushback before such unanswered concerns quash the initiative.
Putting a mechanism in place to understand changing compliance standards (Step 4) helps everyone understand whether and why these standards might need to change.
Too, an organization will need to determine what GenAI tools are acceptable, the methods to prevent unauthorized tools, and other ways to prevent company IP from “leaking” into non-private GenAI tools.
With these foundations in place, the organization can turn to how and how much developers should use GenAI for code. These six recommendations are applicable to engineering teams of all sizes, stages, and industries.
To demonstrate each recommendation, we reference the specific example of a mid-sized, Private Equity backed software development company (“Company Z”) with 100 developers making software for generalist manufacturers.
Recommendation 1. Determine the areas of the codebase that should have 0% GenAI usage
The famous management theorist Peter Drucker once observed:
There is nothing so useless as doing efficiently that which should not be done at all.
This is certainly true for GenAI usage. If there’s a compelling organizational reason not to use GenAI at all, then developers have “maximum productivity from GenAI” when their usage is zero. Worse, they could be unproductive if they are using GenAI if their work needs to be undone, or heavily rewritten.
As of January 2024, Sema has not identified any specific bans on GenAI from external regulation, legislation, or law. However, given potential external rules, and risks determined internally, organizations may choose a zero use policy in the short term.
The two most compelling examples are:
- Sections of the codebase with the highest organizational value, to eliminate the potential intellectual property risk (i.e. lack of code ownership).
- Code for high risk situations and or highly regulated industries, such as supporting the warfighter, or health and safety technology – to avoid the risk that future compliance will require rewrites of that code.
For a practical example, let’s consider the use case of Company Z.
With respect to external risks, generalist manufacturers are not likely to face an industry-specific higher level of scrutiny. On internal risks, the protection of intellectual property is extremely important but can be addressed through more direct methods including Blended GenAI code (see #3), choice of LLMs, and data leakage prevention tools and training.
It’s reasonable that Company Z may decide that GenAI is applicable across its entire codebase.
Recommendation 2. Determine minimum levels of developers’ GenAI usage as a percentage of their total coding
Excluding the code covered in Recommendation 1, we believe that the benefits from integrating GenAI into the SDLC is that organizations should set a baseline level of regular usage.
This level might be extremely low, because organizations are still understanding how best to capture the benefits of GenAI code. Or too, an organization with many junior developers may set a lower standard than one with more seniors, since, as discussed above, junior developers will need more scaffolding to use GenAI correctly and still need to focus on the fundamentals.
But having a universal minimize standard communicates to the organization that the belief in collectively experimenting with GenAI to help coders and the organization.
As an example, Company Z could decide that 5% of all code should include GenAI code.
Why 5%? It’s a number low enough to nudge Questioners (high skill, low enthusiasm for GenAI) and Novices (low skill, low enthusiasm) towards experimentation while recognizing legitimate reasons for hesitancy. And it prevents Novices and Adventures (low skill, high enthusiasm) from overusing GenAI to their, and the company’s, detriment too soon.
Recommendation 3. Determine maximum levels of Pure GenAI usage.
As noted above, one of the clear lines of compliance emerging is that Pure GenAI—which was copied in without modification from an LLM Chatbot—will be viewed less favorably than Blended GenAI in the eyes of copyright law.
For today, we know one plain fact: as of writing, code which is 100% pure GenAI cannot achieve copyright protection. Other aspects of GenAI code regulatory issues are in flux. The higher priority the code, the more important it is that the code be Blended and not Pure GenAI.
Put into practice, engineering leaders at Company Z could decide that:
No code should be above 50% pure GenAI
No production customer code, including frontend and backend parts of their platform, should be above 25% pure GenAI
The most important thing a team can do when implementing GenAI in the SDLC is help developers understand that GenAI code is not to be treated like Open Source, and left untouched, but that modification is appropriate and necessary. If an organization only achieves teaching developers this in 2024, it would be a major milestone for future success.
Some points to reinforce, educationally speaking:
- Pure GenAI code is more likely to have security vulnerabilities
- Pure GenAI code may not get copyright and other legal protections
- Pure GenAI code may not be understood by the team
Recommendation 4. Set developer-specific support systems for interacting with GenAI
Recall the skill/will matrix from above, with Novices, Questioners, Adventurers and Lodestars.
Whether you use this framework or another, developers will have different wants and needs regarding GenAI, and the development and support plans should vary. Here’s an application of this skill/will matrix for Company Z:
For this company, Lodestars will be asked to coach and guide others.
Questioners will be given time and budget to research GenAI SDLC techniques and share their results with others. In that research they will no doubt uncover nuances that are useful to the rest of the team, and their own perspective may change while exploring.
Adventurers and Novices should both have plenty of scaffolding for their GenAI usage, including paired programming and thorough code reviews. Novices just need a little more help getting started.
Recommendation 5. Set domain-specific goals for interacting with GenAI.
Goals for working with GenAI could vary across software development lifecycle tasks and or functions. For example, a team might decide to emphasize GenAI tools when bug fixing but not on core database work. Curious and thoughtful developers can co-create the right answer for their organization.
Our fictional Company Z decided to pause on this recommendation and regroup after six months—getting everything on this list right was success enough.
Recommendation 6. Agree on a cadence to review usage and results – recalibrate as necessary
In the spirit of iteration and experimentation, with GenAI code metrics and elsewhere, the most important thing to do first is put (electronic) pen to (virtual) paper. Propose the organization’s standards and explain the rationale clearly to participants. Then, try the protocols out.
Very quickly, you will get feedback directly and indirectly on how the standards are working. Use that feedback to regroup and tune, at least quarterly, but we recommend monthly in the near time.
At Company Z, for instance, the Developer Council agreed to meet twice a month for 3 months: 60 minutes on their own and 30 minutes with the CEO and General Counsel, who committed to bringing regulatory updates to the group.
Expect to continue with this some version of this meeting for years to come, as developers adapt to the tools, the tools themselves change, and compliance standards settle.
Conclusion
The key to unleashing developer productivity with GenAI is to empower engineers to participate in the development and refinement of goals, standards, and methods.
Developers know their work best, as craftspeople, and when given the right context, authority and goals will help deliver the right code at the right time. By setting up the foundational components, and then answering the six recommendations, developers and organizations will accelerate the value from GenAI in the SDLC.
