How to Survive AI with Intent Integrity Chain

Go straight to an AI summary of this blog post instead

Everyone getting fired soon because of AI might sound like a joke to some, but it’s an unsettling reality that many developers are fighting. As we head towards the future, AI isn’t writing code anymore; it’s replacing coders.

Microsoft’s Satya Nadella recently stated that nearly 30% of Microsoft’s code is now written by AI tools like Copilot. Just days after that stat was made public came the gut punch – Microsoft laid off 2,000 employees. Could this be a coincidence, or is there a connection between 30% share of code being AI and employees getting fired?

Such coincidences aren’t just linked to Microsoft alone. A similar phenomenon can be seen across CloudStrike, IBM, and others. Even Goldman Sachs predicts that up to 300 million jobs will be replaced by AI in an industry that was short of nearly two million engineers a few years ago.

This isn’t the first time the tech world has panicked about job extinction.

Be it Java bytecodes or migration to the cloud, developers have always faced skepticism, fear, and resistance when new tech emerges. But, this time, it’s different. Why?

Because, this time, we’re dealing with tools that don’t just automate – they generate results that can’t be predicted. These tools hallucinate. They might be fast, but they’re not reliable. Despite this, they’re being trusted to generate production-level code.

In this article, we explore this tension and look at why something called the Intent Integrity Chain might be our best option at surviving AI without losing control. Let’s get started!

Panic and Progress – The Cycle Continues

The panic surrounding AI in software development might seem new, but it’s not. In fact, with every abstraction in tech, whether it’s Java, the use of SaaS tools, or the move to the cloud, doubt always follows.

There was a time when engineers questioned Java bytecode, asking if it could be trusted. There were those who deemed cloud computing too risky for sensitive data. The resistance has always been there, but – despite that – every shift that has prevailed thus far has helped developers build better than before.

Over time, abstractions have the backbone of scalability, leading to the development of faster, more complex, and more resilient systems. But what makes this current moment different is the nature of AI. Traditional abstractions were more about simplifying complexities while maintaining a consistent behaviour that was repeatable. However, advances such as large language models (LLMs) give room to randomness.

LLMs are designed to be probability-based, meaning the output from these models can be different even if they’re fed identical inputs. This unpredictability is a breaking point from past abstraction.

While tools of the past did trigger fear and resistance, they came with a framework that could be determined. With LLMs, developers are now working with systems that behave differently every time, meaning that developers have to face new challenges pertaining to accuracy and reliability in the software these models generate.

Are LLMs Just a Monkey With a GPU?

Despite their popularity, LLMs remain unreliable when it comes to software development. Their code generation capabilities look more like trial-and-error efforts than an engineer at work.

Rather than a precise, intelligent tool, you can think of an LLM as a monkey with a GPU that’s just trying things until they work.

How does such reality play out in real-life development? There are numerous examples of these models simply inventing functions, fabricating package names, and even producing logic that’s dangerously flawed.

For example, LLMs have referenced npm libraries that don’t exist, and malicious actors have used those hallucinated names to register packages, introducing a new vector of supply chain attacks.

Many may see this risk as one prevailing only in theory, but that’s not the case. Studies that compare code quality results from leading tools such as GitHub Copilot, Amazon CodeWhisperer, and ChatGPT generate correct code just 31% to 65% of the time, meaning the code is flawed nearly half the time.

What’s even worse is that 40% of AI code was vulnerable, as it contained exploitable flaws and didn’t follow basic security practices.

Looking at it now, it’s clear that the issue isn’t about inaccuracies alone. It also includes misplaced confidence. These tools present their code with high levels of certainty even in cases where the results are wrong.

There have been instances where developers asked AI to optimize their code for speed. The result? The model removes validation checks or breaks test coverage entirely for the sake of performance.

Given this, we can say that LLMs aren’t a replacement for humans, not for now. They’re tools that can, however, amplify the intent and capabilities of those who use them. That said, these models lack a strong understanding of systems and context; they can’t be trusted blindly, and human judgment is now more crucial than ever before.

The Intent Integrity Chain

Given everything we’ve covered thus far, it’s clear that relying on AI-generated code comes with a set of evolving risks. The Intent Integrity Chain is a framework that’s designed to ensure that such risks do not prevail and that a developer’s original idea is turned into functional and reliable software.

The fundamental concept with this framework is that something gets lost between a developer’s idea and the final output, and that’s what’s referred to as a translation gap. These gaps exist between a prompt and the final output that an LLM model produces. This happens because the model’s behaviour is unpredictable and based on improvisation, meaning there is no guarantee that what comes out will reflect what went in.

The Intent Integrity Chain can help address this via a multi-step process that’s centered on four artifacts:

Prompt – Written by humans, this represents the raw intent or desired functionality.
Spec – A structured, standardized version of the prompt, still in natural language, but formatted for clarity and consistency.
Test – Automatically generated from the spec; these tests define what correct behavior looks like.
Code – Generated by the LLM, intended to pass the tests that were based on the spec.

Prior to moving forward with this, it’s essential to know that each artifact serves as a link in the chain, but can’t be trusted blindly.

While the prompt doesn’t need validation as it’s just a starting point, the spec must be reviewed by humans to ensure that it captures the prompt’s intent. Similarly, the test must be locked and verifiable, and the code generated by LLM should only be validated if it passes the locked test.

This structure basically introduces checkpoints at every stage, which can help reduce the risk of security flaws and hallucinated features, ensuring that the output aligns with the human intent.

Trust, Verify, Prompt

AI-generated code is becoming more common with every passing moment. Given this, building guardrails isn’t about following good practice; it’s about survival.

Without clearly defined constraints like specs and tests, LLMs can generate unsafe or outright broken software. In addition, techniques like Test-Driven Development (TDD) and Behavior-Driven Development (BDD) provide early-stage structure, but they’ve struggled with adoption because developers are biased toward writing code over writing tests.

With development and AI now becoming more than a trend, the most critical skill developers can acquire is intent articulation.

What this means is that developers must now turn into prompt engineers who can express requirements in a precise manner, design testable specs, and audit LLM output for flaws. Given this, technical leadership today has become more about having the ability to guide a model through structured prompting and constraint validation.

A Shared Understanding and a Future-Proof Skill Set

Using structured specifications like Gherkin can help limit misunderstandings between humans and machines. While these specs aren’t code, they’re formal enough to be understood by humans and machines.

While working with spec to test and then to code can help limit AI errors in the final result, being able to do that requires developers to shift their mindset.

They must stop seeing LLMs as experts and think of them as a tool designed to amplify intent. However, if the initial intent is poor, the outcome of the code will be poor too.

With this in mind, three key skills that developers must focus on enhancing their performance to be future-ready include writing better prompts, validating outputs, and designing clear specs. Those who develop these three key skills may have a better chance at being effective in their careers. Those who don’t might end up being replaced by AI.

Final Thoughts

AI has and continues to change software development in a way that we’ve never seen before. While it can code in a faster and more efficient manner, its output is not always as intended or contains logical flaws, exploitable vulnerabilities, misconfigured security policies and more.

Developers, however, can use the Intent Integrity Chain to stay in control and ensure that AI code is generated as intended by aligning human intent with machine output through structure and validation.

Summary