 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
With generative AI evolving so quickly, developers are under pressure to build AI technologies into new products and ship them faster than ever. As a result, the technical debt from generative AI can become a major stumbling block that slows innovation. By approaching projects thoughtfully and being conscious of where this debt occurs, developers can minimize risk and accelerate the pace at which new AI products are released.
It’s first helpful to think about how technical debt is incurred. There are three variables that apply to any software project: the time it takes to complete, the amount of developer resources and the scope — or how big of a feature you’re building. The high demands placed on developers today mean that many projects require trade-offs along at least one of these variables, whether that’s extending the delivery time, compromising on quality or sacrificing features. Very often, technical debt occurs when quality is compromised to get the desired features to market quickly.
Generative AI presents particular challenges because the technology is evolving so rapidly, with new tools and language models emerging every week. Many organizations don’t have standard procedures in place for developing and testing generative AI. At the same time, they’re eager to ship AI features to stay ahead of competitors and provide unique differentiation.
All of that makes generative AI projects especially susceptible to technical debt — and sometimes that’s OK. Technical debt isn’t always bad, as long as it’s incurred intentionally with a plan to pay off that debt before it becomes a roadblock to future development. The key is to recognize the difference between debt that is acceptable and debt that is not.
For example, compromising on the quality of models and data in a way that affects accuracy is rarely, if ever, a good idea. AI models can hallucinate, leading to poor business decisions or even offensive responses, which can result in reputational harm or lawsuits. You never want to incur technical debt that exposes your organization to such risk.
On the other hand, enterprises often have extensive release processes to ensure that new applications align with the existing IT architecture and integrate well with other systems. These processes can add months to application delivery times, and it’s an area where you can sometimes compromise, as long as you have a plan to pay down the debt with an upcoming release cycle.
In either case, there are steps you can take to minimize technical debt, which mainly relate to the way that data is delivered and managed. The most valuable generative AI-powered apps combine an AI model with internal company data, so the way developers connect to and deliver this data to applications is an important area of focus.
The data that feeds AI models needs to be high quality to ensure good results, and it needs to be governed, with a focus on security and privacy. Applications also need comprehensive observability to ensure pipelines and models are performing optimally. That means having real-time insights to efficiently identify and address any issues that may arise with the data.
The key to minimizing technical debt here is not creating these capabilities in an ad hoc manner for every app that developers build. If you spin up a custom connection to funnel data from a database to a large language model, that connection is likely to generate technical debt that will have to be addressed later. And if you repeat this enough times across multiple applications, the accumulation of technical debt will eventually bring you to a standstill.
Instead, forgo the piecemeal approach for a platform that has built-in capabilities for data governance and management. A cloud platform should impose certain protocols and methods for deployment, ensuring that apps can more easily be integrated with the larger IT environment and connect to systems for observability, access control and other needs.
It’s also important to select a platform in which your generative AI app can be deployed next to your data, so that roles and permissions are honored without developers needing to configure them on the backend. Choosing a platform with baked-in governance in the form of observability, data quality, security and auditing means these services are provided without you having to build them. By taking advantage of prebuilt services and patterns, you can minimize custom work, which in turn minimizes technical debt.
Contrast this with a piecemeal approach. Exciting new tools and frameworks for generative AI are being released weekly, but adopting an a la carte approach creates a new form of shadow IT. Leaders can protect against this by creating guardrails and best practices for teams to follow. They should identify approved tools and frameworks that integrate with the organization’s data platform and are aligned with enterprise needs — meaning they’re robust, scalable and can meet compliance, security and management requirements.
Building AI applications in this consistent manner minimizes technical debt and in turn accelerates progress in the future. If you build a proof of concept that you later want to scale in production, for example, you can achieve this much more quickly by working in an environment that already has connections to your mission-critical data and where governance and security needs are already met.
Generative AI is evolving fast, and the technology itself may eventually help to eliminate technical debt rather than contribute to it. We already have copilots that can write code, and it’s not hard to imagine a time where AI will be able to look at the code you’re writing, identify areas of technical debt and suggest ways to address it. But that’s in the future. For now, we need to build applications in a way that minimizes debt and doesn’t create roadblocks to innovation down the road. That means building in an environment that imposes best practices for sourcing and delivering data in a secure, governed way.
