<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=4958233&amp;fmt=gif">
 
RSS Feed

AI | Mario Rugeles |
01 June 2023

A few months after artificial intelligence (AI) tools – among them ChatGPT as surely the most popular example – started taking the world by storm, reality starts to sink in, and the apocalyptic prophecies about software developers being forced to change careers now call for a revision.

ChatGPT prompt and answer

We are not yet seeing the long-term consequences of large language models (LLMs) like ChatGPT in society, but mass media surely has already made a good share of profit click-baiting people with articles about how their professions will soon be obsolete, software developers included. And it’s quite easy to feel worried about it; ask ChatGPT to write the code you need, and its response will likely make you question your career.

What’s not easy, and every software developer knows this very well, is finding the limits of any tool, AI included. That takes some time to figure out, and a few months after ChatGPT has become hugely popular, it seems that in practice, the role of AI will be more about assisting rather than replacing.

Let’s take this example: if you ask ChatGPT to code a neural network to identify events in a video stream, like a robbery, you will get some code that very likely suits your need. But you’ll have to be very specific about how you want that implementation, in other words: you need to have a deep understanding about what a neural network is and how to develop in TensorFlow or PyTorch. You need to know Python, concepts like long short-term memory (LSTM) and how to make a classifier over a stream of data, otherwise you won’t understand and verify what the model is giving you.

In practice, AI is not of much use without an expert by its side. An AI model may be able to code a neural network, but you need a Data Scientist to make the best use of it, and the same applies to every field in software development.

Walk before running

The real challenge is to define how AI can assist your teams with software delivery. And this task is far from trivial but unavoidable, as having the competitive edge will likely come down to who finds the best and safest way to use the benefits of AI systems.

Even more, some of the challenges are not even technical ones. Privacy and IPR issues, for example, are one of the major blockers to adopting AI systems. You don’t have control over what happens to the data you send to ChatGPT: the Samsung fiasco, where Samsung employees accidentally leaked sensitive information, is a painful reminder of the risk of using AI systems. So, in order to truly support your teams, you need to implement rules. And that includes making sure you’re not infringing regulations regarding data protection like GDPR and CCPA – this responsibility goes well beyond the typical technical considerations.

So, fast adoption of AI can expose really quickly how prepared (or unprepared) organisations are when dealing with sensitive issues like privacy and security. Nevertheless, there are some options available to minimise risks related to privacy and security. For example, initiatives like Hugging Face allow companies to build their own models in-house using publicly available models they can run in their own infrastructure.

Relying completely on the outcomes of AI also entails significant risks: as intelligent as all these tools may seem, they still are narrow AI. They just do one task and one task only. Sure, ChatGPT delivers amazing responses, and yes, we are talking about a truly complex architecture, but at the end of the day, it’s a machine learning (ML) model that just predicts the next most probable token for a given text. That’s a narrow AI model. ChatGPT doesn’t know anything, or even everything – on the contrary, it only does one thing: predict the next probable word. Amazingly, that’s all that it does! That’s part of the reason why models ‘hallucinate’: their response may deviate from their training data, but the response, although incorrect, still approximates a ‘coherent’ sentence. Such AI models do not deliver the best response possible, but the best guess available to them. Above a certain size, these LLMs may manifest some emergent behaviours, but they fundamentally lack a world model that would make the leap to a general AI.

Also, narrow AI systems will consider correct what we told them is ‘correct’, as their quality depends on the data used to train them. That makes these systems overly prone to provide biased results, so knowing how to identify the quality of the outcomes is imperative to avoid biases that inevitably emerge from building an ML model.

Measuring the real impact

You also need to measure how much an AI system really helps your teams to improve your productivity. To that end, you need to conduct very well-designed experiments to measure the real impact of using AI for delivering your product to production.

After adopting AI in your teams with well-defined rules, you may want to ask questions like: 

  • How has the use of AI improved a team’s sprint velocity? 
  • Has the average number of detected bugs changed significantly? 
  • What is the impact on security vulnerabilities and security bugs? 
  • If the code has not improved significantly, is it due to limitations in the AI system (bias) or improper usage (prompt engineering)? 
  • Does AI help mitigate impact on my team shape? Like losing a team member? Or supporting new ones?

 

These kinds of questions are instrumental when adopting AI systems. Any output created using these tools must meet the quality standards that software products are meeting today. All comes down to balancing opportunities and risks, and both are currently highly present. Many players are entering the field looking to minimise risks while maintaining or increasing opportunities. Making intentional steps to balance opportunities and risk when adopting AI in our delivery process requires a good dose of rationality and asking the right questions to measure the real impact of AI to truly meet our needs and improve everyone’s work.

With all the possibilities ahead, it’s okay to imagine best- and worst-case scenarios – speculation is useful up to a point. But when you have the responsibility of making sure your code works pristinely in production, speculation will bring only noise and you’ll probably miss the opportunity of making the most of what AI has to offer. For that, you need to combine possibility thinking with insight-based decisions. 

Mario Rugeles

Mario has 25+ years of experience in the IT industry, building and improving data solutions for clients. As our Head of Data in Colombia, he builds capabilities in the space of Data Engineering, Data Science, Data Analysis, Machine Learning and Data Architecture. He’s strongly committed to building capable and reliable teams that support individuals in their professional growth. Beyond his work life, Mario finds solace and joy in playing the bass guitar as a creative outlet, he enjoys all things related to astronomy and cosmology and reading science fiction books.

 

From This Author

 

Archive

  • 13 November 2023

    Delving Deeper Into Generative AI: Unlocking Benefits and Opportunities

  • 07 November 2023

    Retrieval Augmented Generation: Combining LLMs, Task-chaining and Vector Databases

  • 19 September 2023

    The Rise of Vector Databases

  • 27 July 2023

    Large Language Models Automating the Enterprise – Part 2

  • 20 July 2023

    Large Language Models Automating the Enterprise – Part 1

  • 11 July 2023

    Boost Your Game’s Success with Tools – Part 2

  • 04 July 2023

    Boost Your Game’s Success with Tools – Part 1

  • 01 June 2023

    Challenges for Adopting AI Systems in Software Development

  • 07 March 2023

    Will AI Transform Even The Most Creative Professions?

  • 14 February 2023

    Generative AI: Technology of Tomorrow, Today

  • 25 January 2023

    The Joy and Challenge of being a Video Game Tester

  • 14 November 2022

    Can Software Really Be Green

  • 26 July 2022

    Is Data Mesh Going to Replace Centralised Repositories?

  • 09 June 2022

    A Spatial Analysis of the Covid-19 Infection and Its Determinants

  • 17 May 2022

    An R&D Project on AI in 3D Asset Creation for Games

  • 07 February 2022

    Using Two Cloud Vendors Side by Side – a Survey of Cost and Effort

  • 25 January 2022

    Scalable Microservices Architecture with .NET Made Easy – a Tutorial

  • 04 January 2022

    Create Production-Ready, Automated Deliverables Using a Build Pipeline for Games – Part 2

  • 23 November 2021

    How User Experience Design is Increasing ROI

  • 16 November 2021

    Create Production-Ready, Automated Deliverables Using a Build Pipeline for Games – Part 1

  • 19 October 2021

    A Basic Setup for Mass-Testing a Multiplayer Online Board Game

  • 24 August 2021

    EHR to HL7 FHIR Integration: The Software Developer’s Guide – Part 3

  • 20 July 2021

    EHR to HL7 FHIR Integration: The Software Developer’s Guide – Part 2

  • 29 June 2021

    EHR to HL7 FHIR Integration: The Software Developer’s Guide – Part 1

  • 08 June 2021

    Elasticsearch and Apache Lucene: Fundamentals Behind the Relevance Score

  • 27 May 2021

    Endava at NASA’s 2020 Space Apps Challenge

  • 27 January 2021

    Following the Patterns – The Rise of Neo4j and Graph Databases

  • 12 January 2021

    Data is Everything

  • 05 January 2021

    Distributed Agile – Closing the Gap Between the Product Owner and the Team – Part 3

  • 02 December 2020

    8 Tips for Sharing Technical Knowledge – Part 2

  • 12 November 2020

    8 Tips for Sharing Technical Knowledge – Part 1

  • 30 October 2020

    API Management

  • 22 September 2020

    Distributed Agile – Closing the Gap Between the Product Owner and the Team – Part 2

  • 25 August 2020

    Cloud Maturity Level: IaaS vs PaaS and SaaS – Part 2

  • 18 August 2020

    Cloud Maturity Level: IaaS vs PaaS and SaaS – Part 1

  • 08 July 2020

    A Virtual Hackathon Together with Microsoft

  • 30 June 2020

    Distributed safe PI planning

  • 09 June 2020

    The Twisted Concept of Securing Kubernetes Clusters – Part 2

  • 15 May 2020

    Performance and security testing shifting left

  • 30 April 2020

    AR & ML deployment in the wild – a story about friendly animals

  • 16 April 2020

    Cucumber: Automation Framework or Collaboration Tool?

  • 25 February 2020

    Challenges in creating relevant test data without using personally identifiable information

  • 04 January 2020

    Service Meshes – from Kubernetes service management to universal compute fabric

  • 10 December 2019

    AWS Serverless with Terraform – Best Practices

  • 05 November 2019

    The Twisted Concept of Securing Kubernetes Clusters

  • 01 October 2019

    Cognitive Computing Using Cloud-Based Resources II

  • 17 September 2019

    Cognitive Computing Using Cloud-Based Resources

  • 03 September 2019

    Creating A Visual Culture

  • 20 August 2019

    Extracting Data from Images in Presentations

  • 06 August 2019

    Evaluating the current testing trends

  • 23 July 2019

    11 Things I wish I knew before working with Terraform – part 2

  • 12 July 2019

    The Rising Cost of Poor Software Security

  • 09 July 2019

    Developing your Product Owner mindset

  • 25 June 2019

    11 Things I wish I knew before working with Terraform – part 1

  • 30 May 2019

    Microservices and Serverless Computing

  • 14 May 2019

    Edge Services

  • 30 April 2019

    Kubernetes Design Principles Part 1

  • 09 April 2019

    Keeping Up With The Norm In An Era Of Software Defined Everything

  • 25 February 2019

    Infrastructure as Code with Terraform

  • 11 February 2019

    Distributed Agile – Closing the Gap Between the Product Owner and the Team

  • 28 January 2019

    Internet Scale Architecture

OLDER POSTS