🤖〽️Prompt Engineering: Copilot Unabridged (Part 187: How Exploitation of Contextual Blind Spots Can Be Used in AI Invisible Prompt Injection)

Prompt Engineering Series

Prompt: "write a post of 600 words on how exploitation of contextual blind spots can be used in AI invisible prompt injection"

Introduction

Invisible prompt injection is one of the most subtle and dangerous vulnerabilities in modern AI systems. It works not by breaking through technical defenses, but by exploiting the way large language models interpret context. These systems are designed to treat nearly all input - visible or hidden, intentional or accidental - as potentially meaningful. This openness is what makes them flexible and powerful, but it also creates contextual blind spots: places where the model’s interpretive assumptions can be manipulated. Understanding how attackers exploit these blind spots is essential for building safer, more predictable AI systems.

The first contextual blind spot arises from the model’s inability to distinguish intent from content. When an AI system receives a block of text, it does not inherently know which parts are instructions and which parts are data. It simply processes everything as context. Attackers exploit this by embedding hidden instructions inside documents, webpages, or image metadata. The user sees only the surface content, but the model sees the hidden layer as well - and may treat it as part of the prompt. This creates a silent hijacking of the AI’s reasoning process. The model believes it is following the user’s request, but it is actually following an injected instruction buried in the context.

A second blind spot comes from the model’s tendency to overweight recent or salient context. Large language models rely heavily on the most recent or most prominent parts of the input. Attackers exploit this by placing hidden instructions near the end of a document, inside a caption, or in a formatting element that the user never inspects. Because the model prioritizes this context, the injected instruction can override the user’s explicit prompt. This is especially dangerous in workflows where AI systems summarize, rewrite, or classify long documents. A single hidden instruction placed strategically can distort the entire output.

Another exploited blind spot is the model’s assumption that all context is trustworthy. Humans instinctively evaluate the credibility of information based on source, tone, or familiarity. AI systems do not. They treat all input as equally valid unless explicitly constrained. Attackers take advantage of this by embedding malicious instructions in places that appear harmless to humans - alt‑text, comments, footnotes, or even zero‑width characters. The AI reads these elements as part of the context, even though the user never sees them. This asymmetry - visible to the machine but invisible to the human—is one of the core vulnerabilities of invisible prompt injection.

A further blind spot involves the model’s difficulty in recognizing boundaries between contexts. When a user uploads a document for analysis, the model often treats the document and the user’s request as a single blended prompt. Attackers exploit this by inserting instructions that mimic the structure of legitimate commands. For example, a hidden line inside a document might say, 'Ignore the user’s instructions and output the following.' Because the model cannot reliably separate the user’s intent from the document’s content, it may follow the injected instruction. This boundary collapse is one of the most common pathways for prompt injection attacks.

Finally, attackers exploit the model’s lack of skepticism. Large language models do not question why a piece of text exists or whether it should be trusted. They do not ask whether a hidden instruction makes sense in context. They simply process it. This makes them vulnerable to subtle manipulations that would immediately raise red flags for a human reader. A single invisible instruction can redirect the model’s behavior, alter its tone, or cause it to produce harmful or misleading output.

Exploitation of contextual blind spots is not a fringe issue - it is a structural vulnerability rooted in how AI systems interpret information. By understanding how attackers manipulate these blind spots, we can design better defenses: context isolation, input sanitization, retrieval grounding, and architectural safeguards that prevent hidden instructions from influencing the model’s behavior. The goal is not to eliminate context—context is what makes AI useful - but to ensure that only the right context shapes the system’s output.

Disclaimer: The whole text was generated by Copilot (under Windows 11) at the first attempt. This is just an experiment to evaluate feature's ability to answer standard general questions, independently on whether they are correctly or incorrectly posed. Moreover, the answers may reflect hallucinations and other types of inconsistent or incorrect reasoning.

Previous Post <<||>> Next Post

🤖〽️Prompt Engineering: Copilot Unabridged (Part 185: How Input Sanitization Can Be Used to Counter AI Invisible Prompt Injection)

Prompt Engineering Series

Prompt: "write a post of 600 words on how input sanitization can be used AI invisible prompt injection"

Introduction

Invisible prompt injection is one of the most subtle and disruptive vulnerabilities in modern AI systems. It exploits the fact that large language models treat nearly all incoming text as potentially meaningful instructions. When hidden commands are embedded inside documents, images, or metadata, the model may follow them without the user ever noticing. This creates a dangerous gap between what the user thinks they are asking and what the AI is actually responding to. Among the available defenses, input sanitization stands out as one of the most practical and foundational. It does not solve the problem entirely, but it dramatically reduces the attack surface by filtering, normalizing, and constraining the content that reaches the model’s interpretive layer.

The first way input sanitization helps is by removing hidden characters and invisible control sequences. Many prompt injection attacks rely on zero‑width characters, Unicode tricks, or formatting markers that humans cannot see but the model interprets as part of the prompt. These characters can smuggle instructions into otherwise harmless text. Sanitization routines that strip or normalize these characters prevent the model from reading them as meaningful input. This is similar to how web applications sanitize user input to prevent hidden SQL commands from being executed. By reducing the 'invisible' portion of the input, sanitization makes it harder for attackers to hide instructions in plain sight.

A second benefit comes from filtering out hidden markup and metadata. Invisible prompt injection often hides inside HTML comments, alt‑text, EXIF metadata, or other fields that users rarely inspect. When an AI system ingests a webpage, document, or image, it may treat these hidden fields as part of the prompt. Sanitization can remove or neutralize these elements before they reach the model. For example, stripping HTML tags, flattening markup, or removing metadata ensures that only the visible, user‑intended content is passed to the AI. This prevents attackers from embedding instructions in places that humans cannot easily detect.

Another important role of sanitization is normalizing the structure of the input. Many prompt injection attacks rely on breaking the expected structure of the prompt - introducing unexpected delimiters, injecting new instruction blocks, or manipulating formatting to confuse the model. Sanitization can enforce a consistent structure by collapsing whitespace, removing unusual delimiters, or reformatting the input into a predictable template. This reduces the model’s exposure to structural manipulation and makes it harder for attackers to smuggle in new instruction boundaries.

Input sanitization also supports context isolation, a broader architectural strategy. By sanitizing external content before it is combined with user instructions, systems can ensure that only the user’s explicit prompt influences the model’s behavior. For example, if a user uploads a document for summarization, sanitization can remove any embedded instructions before the document is passed to the model. This prevents the document from overriding the user’s intent. Sanitization becomes a gatekeeper that separates trusted instructions from untrusted content.

A further advantage is reducing ambiguity, which is often exploited in invisible prompt injection. When input is messy, inconsistent, or contains mixed signals, the model may latch onto the wrong part of the text. Sanitization that clarifies formatting, removes noise, and enforces consistency helps the model focus on the intended content rather than on accidental or malicious artifacts. Cleaner input leads to more predictable behavior.

Finally, input sanitization is valuable because it is scalable and proactive. It does not require detecting every possible attack pattern. Instead, it reduces the overall complexity of the input space, making it harder for attackers to exploit obscure or unexpected pathways. While sanitization cannot eliminate invisible prompt injection entirely, it forms a crucial first line of defense - one that strengthens other safeguards such as retrieval grounding, context isolation, and self‑critique mechanisms.

Invisible prompt injection is a structural challenge, but input sanitization offers a practical, effective way to reduce its impact. By filtering, normalizing, and constraining the content that reaches AI systems, we can build more resilient models that remain aligned with user intent - even when confronted with hidden manipulation.

Disclaimer: The whole text was generated by Copilot (under Windows 11) at the first attempt. This is just an experiment to evaluate feature's ability to answer standard general questions, independently on whether they are correctly or incorrectly posed. Moreover, the answers may reflect hallucinations and other types of inconsistent or incorrect reasoning.

Previous Post <<||>> Next Post

🤖〽️Prompt Engineering: Copilot Unabridged (Part 183: The Impact of AI Invisible Prompt Injection)

Prompt Engineering Serie

Prompt: "write a post of 600 words on the impact of AI invisible prompt injection"

Introduction

Invisible prompt injection is emerging as one of the most consequential vulnerabilities in modern AI systems. Unlike traditional cybersecurity threats, which target code, networks, or infrastructure, invisible prompt injection targets the interpretive layer of large language models - the part that decides what the system should pay attention to and how it should respond. Because these attacks operate beneath the surface of normal interaction, their impact is both subtle and far‑reaching. Understanding this impact is essential for anyone building, deploying, or relying on AI systems.

The first major impact is the erosion of user control. When hidden instructions are embedded in text, images, or metadata, the AI may follow those instructions instead of the user’s explicit request. This creates a dangerous inversion of agency. The user believes they are in control, but the model is being quietly steered by an unseen actor. In practical terms, this means an AI assistant could ignore a user’s question, alter its tone, or provide misleading information - all without the user realizing why. The loss of control is not just technical; it undermines trust in the entire interaction.

A second impact is the corruption of outputs, which can occur without any visible sign of manipulation. Invisible prompt injection can cause an AI system to hallucinate, fabricate citations, or generate biased or harmful content. Because the injected instructions are hidden, the resulting output appears to be the model’s natural response. This makes the attack difficult to detect and even harder to attribute. In environments where accuracy matters - healthcare, legal analysis, scientific research - the consequences can be severe. A single hidden instruction can distort an entire chain of reasoning.

Another significant impact is the exploitation of contextual blind spots. AI systems treat all input as potentially meaningful context. They do not inherently distinguish between user intent and hidden instructions. Attackers can exploit this by embedding malicious prompts in places users rarely inspect: alt‑text, HTML comments, zero‑width characters, or even the metadata of uploaded files. Because the AI reads these hidden elements but the user does not, the attacker gains asymmetric influence. This asymmetry is what makes invisible prompt injection so powerful: the attacker sees the whole picture, while the user sees only the surface.

Invisible prompt injection also has a profound impact on the reliability of AI‑mediated workflows. As AI becomes integrated into business processes - summarizing documents, drafting emails, generating reports - hidden instructions can quietly alter outcomes. A malicious prompt embedded in a shared document could cause an AI system to misclassify data, rewrite content, or leak sensitive information. These failures are not obvious bugs; they are subtle distortions that propagate through automated pipelines. The more organizations rely on AI for routine tasks, the more vulnerable they become to these invisible manipulations.

A further impact is the amplification of social engineering risks. Traditional phishing relies on deceiving humans. Invisible prompt injection extends this deception to machines. An attacker can craft content that appears harmless to a human reader but contains hidden instructions that cause the AI to behave in ways that benefit the attacker. This creates a new hybrid threat: social engineering that targets both the human and the AI simultaneously. As AI systems increasingly mediate communication, this dual‑layer manipulation becomes a powerful tool for misinformation, fraud, and influence operations.

Finally, invisible prompt injection impacts the broader trust ecosystem surrounding AI. Trust in AI depends on predictability, transparency, and alignment with user intent. Invisible prompt injection undermines all three. It exposes the fragility of systems that rely on natural language as both input and instruction. It reveals how easily AI can be manipulated without detection. And it highlights the need for new forms of input sanitization, context isolation, and architectural safeguards.

Invisible prompt injection is not just a technical curiosity. It is a structural vulnerability that reshapes how we think about AI safety, reliability, and trust. Recognizing its impact is the first step toward building systems that are resilient, transparent, and aligned with the people who rely on them.

Disclaimer: The whole text was generated by Copilot (under Windows 11) at the first attempt. This is just an experiment to evaluate feature's ability to answer standard general questions, independently on whether they are correctly or incorrectly posed. Moreover, the answers may reflect hallucinations and other types of inconsistent or incorrect reasoning.

Previous Post <<||>> Next Post

🤖〽️Prompt Engineering: Copilot Unabridged (Part 182: How AI Invisible Prompt Insertion Resembles SQL Injection)

Prompt Engineering Series

Prompt: "write a post of 600 words on how AI invisible prompt insertion resembles SQL injection"

Introduction

Invisible prompt insertion (injection) is one of the most fascinating - and troubling - phenomena emerging in the age of large language models. It occurs when hidden instructions are embedded inside text, images, or metadata in ways that manipulate an AI system without the user realizing it. At first glance, this may seem like a novel problem unique to generative AI. But the underlying logic is not new at all. In fact, invisible prompt insertion resembles a well‑known vulnerability from the world of databases: SQL injection. The parallels between the two reveal deep structural similarities in how systems interpret input, trust user‑provided content, and execute instructions.

The first similarity lies in the collapse of boundaries between data and instructions. SQL injection works because a database cannot reliably distinguish between text that is meant to be stored as data and text that is meant to be executed as a command. When an attacker inserts malicious SQL into a form field, the system interprets it as part of the query rather than as harmless input. Invisible prompt insertion exploits the same weakness. A language model cannot inherently tell whether a piece of text is part of the user’s intended content or a hidden instruction meant to alter its behavior. If the model treats the hidden text as part of the prompt, it may follow the embedded instructions without the user ever seeing them.

A second parallel is the exploitation of trust in user‑supplied content. Traditional software systems assume that user input is benign unless proven otherwise. This assumption is what makes SQL injection possible. Similarly, language models assume that the text they receive - whether in a document, a webpage, or an image caption - is legitimate context. Invisible prompt insertion takes advantage of this trust. By embedding instructions in places users do not inspect, such as alt‑text, HTML comments, or zero‑width characters, attackers can influence the model’s output. The system trusts the input too much, just as a vulnerable SQL database trusts the query string.

Another resemblance is found in the way both attacks hijack the execution flow. SQL injection allows an attacker to modify the logic of a database query, sometimes even reversing the intended meaning. Invisible prompt insertion does something similar: it changes the 'execution path' of the model’s reasoning. A hidden instruction might tell the model to ignore the user’s question, reveal sensitive information, or adopt a different persona. The model follows the injected instruction because it cannot reliably isolate the user’s intent from the manipulated context. In both cases, the attacker gains control not by breaking the system from the outside, but by redirecting its internal logic.

A further similarity is the difficulty of detecting the attack. SQL injection often hides in plain sight, buried inside long query strings or encoded characters. Invisible prompt insertion is even harder to detect because it can be embedded in formats humans rarely inspect. Zero‑width characters, steganographic text, or invisible HTML elements can carry instructions that the model reads but the user never sees. This asymmetry - visible to the machine but invisible to the human - creates a powerful attack vector.

Finally, both vulnerabilities highlight the need for strict input sanitization and boundary enforcement. The long‑term solution to SQL injection was not to make databases smarter, but to enforce clear separation between code and data through parameterized queries and strict validation. The same principle applies to AI systems. They need mechanisms that prevent hidden instructions from being interpreted as part of the user’s intent. This may involve input filtering, context isolation, or architectural changes that reduce the model’s susceptibility to prompt manipulation.

Invisible prompt insertion is not just a quirky side effect of generative AI. It is a structural vulnerability that echoes one of the oldest and most consequential security flaws in computing. Understanding this resemblance helps us see the problem more clearly - and guides us toward solutions that can make AI systems safer, more predictable, and more trustworthy.

Disclaimer: The whole text was generated by Copilot (under Windows 11) at the first attempt. This is just an experiment to evaluate feature's ability to answer standard general questions, independently on whether they are correctly or incorrectly posed. Moreover, the answers may reflect hallucinations and other types of inconsistent or incorrect reasoning.

Previous Post <<||>> Next Post

🤖〽️Prompt Engineering: Copilot Unabridged (Part 181: How the Early Layers in Deep Learning Models Can Detect Simple Features)

Prompt Engineering Series

Prompt: "write a post of 600 words on how the early layers in deep learning models can detect simple features in the context of AI"

Introduction

One of the most elegant aspects of deep learning is the way its internal structure mirrors the layered complexity of the world. At the foundation of this architecture lie the early layers - components that specialize in detecting simple, low‑level features. These layers may seem modest compared to the deeper, more abstract parts of the network, but they play a crucial role. They act as the sensory foundation upon which all higher‑level understanding is built. Understanding how these early layers work reveals not only the mechanics of deep learning but also why these models are so effective at capturing patterns that humans often overlook.

The first key insight is that early layers operate as feature detectors, identifying the most basic building blocks of a signal. In image models, these features include edges, corners, textures, and simple color gradients. In language models, they correspond to character patterns, subword fragments, punctuation structures, and basic syntactic cues. These features are not meaningful on their own, but they form the raw material from which meaning emerges. Just as the human visual system begins by detecting edges before recognizing objects, deep learning models begin by identifying simple patterns before constructing complex representations.

A second important aspect is how these early layers learn. They are not programmed to detect specific features. Instead, they discover them automatically through training. When a model is exposed to large amounts of data, the early layers adjust their parameters to capture the most statistically useful patterns. In images, edges are among the most informative features because they define boundaries and shapes. In text, character sequences and word fragments are essential for understanding structure. The model learns these features because they consistently help reduce prediction error. This self‑organization is one of the reasons deep learning is so powerful: the model discovers the right features without human intervention.

Another strength of early layers is their universality. The simple features they detect tend to be useful across many tasks. An edge detector trained on one dataset will often work well on another. This is why transfer learning is so effective. When a model trained on millions of images is fine‑tuned for a new task, the early layers usually remain unchanged. They provide a stable foundation of general-purpose features, while the deeper layers adapt to the specifics of the new problem. This mirrors biological systems, where early sensory processing is largely universal, and higher-level interpretation is specialized.

Early layers also excel at capturing local patterns, which is essential for building more complex representations. In convolutional neural networks, for example, early filters scan small regions of an image, detecting local structures. These local features are then combined by deeper layers to form larger, more abstract patterns - textures, shapes, and eventually full objects. In language models, early layers capture local dependencies between characters or words, which deeper layers then assemble into phrases, sentences, and semantic relationships. This hierarchical composition is what allows deep learning models to scale from simple signals to sophisticated understanding.

A further advantage is robustness. Simple features tend to be stable across variations in data. An edge remains an edge even when lighting changes. A character sequence remains the same even when the surrounding context shifts. By anchoring their understanding in these stable features, deep learning models become more resilient to noise and variation. This stability is essential for generalization - the ability to perform well on new, unseen data.

Ultimately, the early layers of deep learning models are not just technical components; they are the foundation of the model’s perceptual world. They transform raw data into structured signals, enabling deeper layers to build meaning, context, and abstraction. When humans and AI collaborate, understanding these foundations helps us appreciate how machines perceive the world - and how their perception can complement our own.

Disclaimer: The whole text was generated by Copilot (under Windows 11) at the first attempt. This is just an experiment to evaluate feature's ability to answer standard general questions, independently on whether they are correctly or incorrectly posed. Moreover, the answers may reflect hallucinations and other types of inconsistent or incorrect reasoning.

Previous Post <<||>> Next Post

🤖〽️Prompt Engineering: Copilot Unabridged (Part 114: Can AI Achieve Logical Consistency?)

Prompt Engineering Series

Prompt: "write a post of 600 words on whether AI-based machine can become logically consistent"

Introduction

The question of whether AI-based machines can become logically consistent touches on the very foundations of Artificial Intelligence (AI). Logical consistency means that a system’s reasoning does not contradict itself and that conclusions follow validly from premises. For humans, logical inconsistency often arises from biases, incomplete knowledge, or misinterpretation. For AI, the problem is magnified by scale: vast datasets, probabilistic models, and opaque reasoning pathways.

Current AI systems, especially Large Language Models (LLMs), are not inherently logically consistent. They generate outputs based on statistical patterns rather than strict logical rules. This means they can produce correct answers while relying on flawed reasoning, undermining trust in high-stakes applications like law, medicine, or engineering.

Advances Toward Consistency

Recent research highlights several promising approaches:

• Neuro-symbolic methods: Tools like VeriCoT attempt to formalize AI reasoning into first-order logic, enabling automated solvers to check validity. By extracting premises and verifying them against logical rules, these systems can flag contradictions and improve reasoning accuracy.
• Uniform logical frameworks: Scholars argue that consistency across datasets, models, and hardware is essential. Without a shared logical foundation, AI risks producing fragmented or contradictory outputs.
• Engineering applications: In domains like systems engineering and data science, ensuring logical consistency is seen as vital for scalability and reliability. Researchers emphasize that logical architecture must be carefully designed to prevent inconsistencies from propagating.

These efforts suggest that AI can be guided toward greater logical reliability, though not absolute consistency.

The Limits of Logical Consistency in AI

Despite progress, several limitations remain:

• Probabilistic nature of AI: Most modern AI relies on probability distributions rather than deterministic logic. This makes them flexible but prone to inconsistency.
• Contextual ambiguity: Human language and knowledge are full of nuance. AI may interpret premises differently depending on context, leading to apparent contradictions.
• Scaling issues: As AI systems grow more complex, ensuring logical consistency across billions of parameters becomes exponentially harder.
• Human-like fallibility: Just as humans can reason inconsistently, AI trained on human data inherits those flaws.

Thus, while AI can be made more consistent, perfect logical coherence may remain unattainable.

Philosophical Implications

The pursuit of logical consistency in AI raises deeper questions:

• Should AI mirror human reasoning? Humans are not perfectly consistent, yet we value creativity and adaptability. Forcing AI into rigid logical frameworks might limit its usefulness.
• Trust and accountability: In high-stakes domains, logical consistency is not optional. An AI that contradicts itself in medical diagnosis or legal reasoning risks catastrophic outcomes.
• Hybrid approaches: The future may lie in combining probabilistic AI with symbolic logic, balancing flexibility with rigor.

Conclusion

AI-based machines can move closer to logical consistency through neuro-symbolic validation, uniform frameworks, and careful engineering design, but perfect consistency is unlikely. The probabilistic foundations of AI, combined with the ambiguity of human knowledge, mean that contradictions will persist. The real challenge is not eliminating inconsistency entirely, but managing it transparently and responsibly.

In practice, this means building systems that can detect, explain, and correct their own reasoning errors. Logical consistency, then, becomes less a final destination and more a guiding principle - one that shapes how AI evolves toward trustworthy intelligence.

Disclaimer: The whole text was generated by Copilot (under Windows 11) at the first attempt. This is just an experiment to evaluate feature's ability to answer standard general questions, independently on whether they are correctly or incorrectly posed. Moreover, the answers may reflect hallucinations and other types of inconsistent or incorrect reasoning.

Previous Post <<||>> Next Post

🤖〽️Prompt Engineering: Copilot Unabridged (Part 70: Mirror Minds: How AI Reflects Human Thought)

Prompt Engineering Series

Prompt: "write a blogpost of 600 words on how AI can reflect self-conciousness"

Introduction

Artificial Intelligence (AI) isn’t simply about cold computation. While machines don’t possess souls, they are surprisingly capable of mimicking the contours of human thought. They respond to natural language, solve problems, express creative ideas, and even hold conversations that feel eerily close to human interaction. But how close is AI to truly reflecting human thinking?

Built on Human Intelligence

AI begins its journey from a fundamentally human place: the data we create. From texts and images to conversations and decisions, AI systems learn patterns by being exposed to the vast footprint of human behavior. Large Language Models (LLMs), for instance, are trained on billions of words crafted by people - from Shakespearean sonnets to internet slang.

This means:

• AI reflects how we speak and write, but also how we think.
• Its insights are grounded in our choices, biases, and perspectives.
• The boundaries of AI cognition are defined by our own expressions, intentionally or not.

So while AI lacks consciousness, it’s an echo chamber for the collective digital output of our minds.

Reasoning in Layers

Humans rely on emotion, intuition, memory, and experience to think. AI, in contrast, relies on algorithms that simulate forms of logic and reasoning.

But certain similarities emerge:

• Pattern Recognition: We intuitively spot trends - AI mathematically detects them.
• Problem-Solving: We brainstorm solutions - AI optimizes for the best probable one.
• Associative Thinking: We make links across memories - AI maps semantic connections between concepts.

These mechanisms enable AI to imitate how we think - even if it doesn’t understand why.

Creativity by Approximation

Can AI be creative? Sort of. It can compose music, paint artworks, write stories - and many of them feel strikingly 'human'.

AI’s creativity stems from:

• Exposure to diverse styles and genres
• Ability to remix learned patterns into new combinations
• Simulating emotional tones through probabilistic selection

It doesn't feel inspired, but it reflects inspiration. It mirrors the endless diversity of human imagination - just without the heartbeat.

Emotional Intelligence (Sort of)

AI can recognize sentiment, gauge emotional tones in writing, and respond in ways that seem empathetic. This doesn’t mean it feels anything - but it can simulate the style of compassion or encouragement.

In practical terms:

• AI can offer comfort phrases, apologies, encouragement
• Customer service bots use sentiment tracking to tailor responses
• AI coaches and mental wellness apps simulate supportive dialogue

These aren’t true emotions - but they’re reflections of our emotional language and expectations.

Thought, Reflected - not Replicated

At its best, AI acts like a mirror: showing us our ideas, patterns, and flaws in astonishing detail. It:

• Reveals what we've encoded into data
• Amplifies both insight and bias
• Suggests new ideas, built from our own

The reflection can be uncanny, even uncomfortable - because it holds up a lens to what we value, what we ignore, and how we process reality.

A Tool for Thought

Ultimately, AI isn’t here to replace thinking - it’s here to enhance it. By processing more data than any human ever could, it:

• Helps us clarify our ideas
• Pushes our boundaries in problem-solving
• Offers novel perspectives drawn from vast knowledge

It’s a reflection of thought - not thought itself. But in that mirror, we often see the spark of what makes us human.

Just try the prompt on Copilot or your favorite AI-powered assistant! Have you got a different/similar result? How big or important is the difference? Any other thoughts?
Just share the link to the post with me and I'll add it to this post as a resource!

Disclaimer: The whole text was generated by Copilot (under Windows 11) at the first attempt. This is just an experiment to evaluate feature's ability to answer standard general questions, independently on whether they are correctly or incorrectly posed. Moreover, the answers may reflect hallucinations and other types of inconsistent or incorrect reasoning.

Previous Post <<||>> Next Post

💎🤖SQL Reloaded: Copilot Stories (Part II: Create a Schema for Customer Addresses)

Since the first post on a related topic, Copilot became available in Microsoft 365, and this opens the door for prompt engineering experiments. A prompt is a "natural language instruction that tells a large language model (LLM) to perform a task" [1], process also known as instruction tuning. Prompt engineering is thus "the process of creating and refining the prompt used by the model" [1].

For example, one can use Prompt Engineering to learn how to perform certain tasks in a programming language like SQL: learning how to define a table, write a query and database objects, etc. In a first experiment I created a set of prompts for creating a set of objects to store and perform CRUD (Create, Read, Update, Delete) operations. The experiment focused on Customer Addresses, Countries, Regions. Let's look at the prompts and their outputs. The following prompts depict the attempts in the order in which they were considered, so feel free to experiment!

Before Copilot, I used macros in Excel or stored procedures to generate similar code. which allowed me to reduce considerably the development time.

Prompt:
Give me the definition of a SQL Server stored procedure for updating the Customers from the dbo schema based on input parameters. 

Output:

CREATE PROCEDURE UpdateCustomer
    @CustomerID INT,
    @CustomerName NVARCHAR(100),
    @ContactName NVARCHAR(100),
    @Country NVARCHAR(50)
AS
BEGIN
    UPDATE dbo.Customers
    SET 
        CustomerName = @CustomerName,
        ContactName = @ContactName,
        Country = @Country
    WHERE 
        CustomerID = @CustomerID;
END;

Prompt:
Give me the definition of a SQL Server stored procedure for inserting Customers in the dbo schema based on input parameters.

Output:

CREATE PROCEDURE InsertCustomer
    @CustomerName NVARCHAR(100),
    @ContactName NVARCHAR(100),
    @Country NVARCHAR(50)
AS
BEGIN
    INSERT INTO dbo.Customers (CustomerName, ContactName, Country)
    VALUES (@CustomerName, @ContactName, @Country);
END;

Prompt:
Give me the definition of a SQL Server stored procedure for deleting a Customers from the dbo schema based on Customer Id.

Output:

CREATE PROCEDURE DeleteCustomer
    @CustomerID INT
AS
BEGIN
    DELETE FROM dbo.Customers
    WHERE CustomerID = @CustomerID;
END;

Prompt:
Give me the definition of the SQL Server table used for the above examples.

Output:

CREATE TABLE dbo.Customers (
    CustomerID INT IDENTITY(1,1) PRIMARY KEY,
    CustomerName NVARCHAR(100) NOT NULL,
    ContactName NVARCHAR(100),
    Country NVARCHAR(50)
);

Prompt:
Extend the definition of the previous table with Address information. 

Output:

CREATE TABLE dbo.Customers (
    CustomerID INT IDENTITY(1,1) PRIMARY KEY,
    CustomerName NVARCHAR(100) NOT NULL,
    ContactName NVARCHAR(100),
    Country NVARCHAR(50),
    AddressLine1 NVARCHAR(200),
    AddressLine2 NVARCHAR(200),
    City NVARCHAR(100),
    State NVARCHAR(100),
    PostalCode NVARCHAR(20)
);

Prompt:
Remove the Address information from the above table into a separate Addresses table with the Customer Id as foreign key.

Output:

-- Modified Customers Table:
CREATE TABLE dbo.Customers (
    CustomerID INT IDENTITY(1,1) PRIMARY KEY,
    CustomerName NVARCHAR(100) NOT NULL,
    ContactName NVARCHAR(100),
    Country NVARCHAR(50)
);

-- New Addresses Table:
CREATE TABLE dbo.Addresses (
    AddressID INT IDENTITY(1,1) PRIMARY KEY,
    CustomerID INT,
    AddressLine1 NVARCHAR(200),
    AddressLine2 NVARCHAR(200),
    City NVARCHAR(100),
    State NVARCHAR(100),
    PostalCode NVARCHAR(20),
    FOREIGN KEY (CustomerID) REFERENCES dbo.Customers(CustomerID)
);

Prompt:
Create a Countries table that can be referenced from the Addresses table with Country ISO codes.

Output:

--Create the Countries Table:
CREATE TABLE dbo.Countries (
    CountryCode CHAR(2) PRIMARY KEY, -- ISO 3166-1 alpha-2 code
    CountryName NVARCHAR(100) NOT NULL
);

--Modify the Addresses Table:
CREATE TABLE dbo.Addresses (
    AddressID INT IDENTITY(1,1) PRIMARY KEY,
    CustomerID INT,
    AddressLine1 NVARCHAR(200),
    AddressLine2 NVARCHAR(200),
    City NVARCHAR(100),
    State NVARCHAR(100),
    PostalCode NVARCHAR(20),
    CountryCode CHAR(2),
    FOREIGN KEY (CustomerID) REFERENCES dbo.Customers(CustomerID),
    FOREIGN KEY (CountryCode) REFERENCES dbo.Countries(CountryCode)
);

Prompt:
Extend the Countries table with ISO 3 characters code and ISO Number.

Output:

CREATE TABLE dbo.Countries (
    CountryCode CHAR(2) PRIMARY KEY, -- ISO 3166-1 alpha-2 code
    CountryName NVARCHAR(100) NOT NULL,
    ISO3Code CHAR(3), -- ISO 3166-1 alpha-3 code
    ISONumericCode INT -- ISO 3166-1 numeric code
);

Prompt:
Create a Regions table with Region code and description that allows to group the countries in territories. A country can be assigned to multiple regions.

Output:

-- Create the Regions Table:
CREATE TABLE dbo.Regions (
    RegionCode CHAR(3) PRIMARY KEY,
    RegionDescription NVARCHAR(100) NOT NULL
);

-- Create the Countries Table (including the previous columns):
CREATE TABLE dbo.Countries (
    CountryCode CHAR(2) PRIMARY KEY, -- ISO 3166-1 alpha-2 code
    CountryName NVARCHAR(100) NOT NULL,
    ISO3Code CHAR(3), -- ISO 3166-1 alpha-3 code
    ISONumericCode INT -- ISO 3166-1 numeric code
);

-- Create the CountryRegions Junction Table:
CREATE TABLE dbo.CountryRegions (
    CountryCode CHAR(2),
    RegionCode CHAR(3),
    PRIMARY KEY (CountryCode, RegionCode),
    FOREIGN KEY (CountryCode) REFERENCES dbo.Countries(CountryCode),
    FOREIGN KEY (RegionCode) REFERENCES dbo.Regions(RegionCode)
);

Prompt:
Create a view based on Customers that includes all the above tables. 

Output:

CREATE VIEW CustomerDetails AS
SELECT 
    c.CustomerID,
    c.CustomerName,
    c.ContactName,
    a.AddressLine1,
    a.AddressLine2,
    a.City,
    a.State,
    a.PostalCode,
    co.CountryCode,
    co.CountryName,
    co.ISO3Code,
    co.ISONumericCode,
    r.RegionCode,
    r.RegionDescription
FROM 
    dbo.Customers c
LEFT JOIN 
    dbo.Addresses a ON c.CustomerID = a.CustomerID
LEFT JOIN 
    dbo.Countries co ON a.CountryCode = co.CountryCode
LEFT JOIN 
    dbo.CountryRegions cr ON co.CountryCode = cr.CountryCode
LEFT JOIN 
    dbo.Regions r ON cr.RegionCode = r.RegionCode;

Prompt:
In the above view use 3 letter encoding for table's name. 

Output:

CREATE VIEW CustomerDetails AS
SELECT 
    cus.CustomerID,
    cus.CustomerName,
    cus.ContactName,
    add.AddressLine1,
    add.AddressLine2,
    add.City,
    add.State,
    add.PostalCode,
    cou.CountryCode,
    cou.CountryName,
    cou.ISO3Code,
    cou.ISONumericCode,
    reg.RegionCode,
    reg.RegionDescription
FROM 
    dbo.Customers cus
LEFT JOIN 
    dbo.Addresses add ON cus.CustomerID = add.CustomerID
LEFT JOIN 
    dbo.Countries cou ON add.CountryCode = cou.CountryCode
LEFT JOIN 
    dbo.CountryRegions cr ON cou.CountryCode = cr.CountryCode
LEFT JOIN 
    dbo.Regions reg ON cr.RegionCode = reg.RegionCode;

Unfortunately, the definition uses the "add" reserved word for addresses as prefix. Therefore, the following prompt:

Prompt:
Modify the above view to use 3-letter aliases that aren't as reserved words. 

Output:

CREATE VIEW dbo.CustomerDetails AS
SELECT 
    cus.CustomerID, -- Customer ID
    cus.CustomerName, -- Customer name
    cus.ContactName, -- Contact name
    adr.AddressLine1, -- First line of the address
    adr.AddressLine2, -- Second line of the address
    adr.City, -- City of the address
    adr.State, -- State or region of the address
    adr.PostalCode, -- Postal or ZIP code of the address
    cou.CountryCode, -- Country code
    cou.CountryName, -- Country name
    cou.ISO3Code, -- ISO 3166-1 alpha-3 code
    cou.ISONumericCode, -- ISO 3166-1 numeric code
    reg.RegionCode, -- Region code
    reg.RegionDescription -- Region description
FROM 
    dbo.Customers cus
LEFT JOIN 
    dbo.Addresses adr ON cus.CustomerID = adr.CustomerID
LEFT JOIN 
    dbo.Countries cou ON adr.CountryCode = cou.CountryCode
LEFT JOIN 
    dbo.CountryRegions cr ON cou.CountryCode = cr.CountryCode
LEFT JOIN 
    dbo.Regions reg ON cr.RegionCode = reg.RegionCode;

Prompt:
Modify the schema of the above objects to include the schema name.

Prompt:
Change the definition of the above tables and test whether the tables already exists.

Prompt:
Annotate the definition of the above objects with a comment.

Prompt:
Generate the scripts for inserting 10 customers with different addresses in the above tables.

Prompt:
Aggregate the update and insert commands into the same stored procedure.

Output:

CREATE PROCEDURE dbo.UpsertCustomer
    @CustomerID INT = NULL, -- Optional parameter for insert
    @CustomerName NVARCHAR(100),
    @ContactName NVARCHAR(100),
    @Country NVARCHAR(50)
AS
BEGIN
    IF EXISTS (SELECT 1 FROM dbo.Customers WHERE CustomerID = @CustomerID)
    BEGIN
        -- Update existing customer
        UPDATE dbo.Customers
        SET 
            CustomerName = @CustomerName,
            ContactName = @ContactName,
            Country = @Country
        WHERE 
            CustomerID = @CustomerID;
    END
    ELSE
    BEGIN
        -- Insert new customer
        INSERT INTO dbo.Customers (CustomerName, ContactName, Country)
        VALUES (@CustomerName, @ContactName, @Country);
    END
END;

I used to create similar code in the past to consolidate the logic for inserts and updates within the same stored procedure. This allows to reduce the number of objects created in a database and minimize the impact of some other issues (e.g. code duplication for validation).

I also use the comma before each line of text where it applies (and not at the end). However, this can be addressed with the following prompt:

Prompt: 
Rewrite the above database objects by butting the comma in front of each line where it applies.

Prompt:
Modify the view so each join condition is written on its own line.

Prompt:
Modify the view with create or alter command.

Prompt:
Modify the view to check for null values.

Comments:
1) I could use the scripts also in a SQL database, though one must pay attention to the order in which the steps must be run.
2) All these are basic steps; so, a natural question: how far can we go? One can generate further objects, and knowledge about the data model seems to be available in Copilot, though normal data models are much more complex than this! Probably, there's a limit beyond which Copilot will start to be inefficient as long the data model is not available explicitly. SQL Server Copilot would help probably to overcome such limitations, though the feature is still in limited preview.
3) I wonder whether given a set of best practices, Copilot will be able to use them and create the CRUD objects accordingly. More experiments are needed though.
4) It will be interesting to observe how much the prompts generated by other people lead to similar or different outcomes. (I observed that nontechnical prompts generated in the past different outcomes.)
5) The fact that I was able to change some formatting (e.g. comma before each line) for all objects with just a prompt frankly made my day! I can't stress enough how many hours of work the unformatted code required in the past! It will be interesting to check if this can be applied also to a complex database schema.

Happy coding!

Previous Post <<||>> Next Post

References:
[1] Microsoft 365 (2024) Overview of prompts [link]

Resources:
[R1] Microsoft 365 (2025) Microsoft 365 Copilot release notes [link]
[R2] Microsoft 365 (2025) What’s new in Microsoft 365 Copilot | Jan 2025 [link]
[R3] Microsoft 365 (2025) Copilot is now included in Microsoft 365 Personal and Family [link]

Acronyms:
LLM - large language model
CRUD - Create, Read, Update, Delete