DEV Community: jsvnsk-tech

Semantic Metadata Explained: How Better Data Helps You Find the Right Information

jsvnsk-tech — Tue, 20 Oct 2026 20:19:12 +0000

Overview:

This article explains semantic metadata and how knowledge workers can use it to improve the discovery, retrieval, interpretation, and effective use of information. It connects established information-management practices with modern approaches from information technology, software engineering, and artificial intelligence. The article examines how taxonomies, semantic tags, contextual hints, descriptive metadata, vector embeddings, and modern search techniques can help people and computer systems identify relevant content and interpret its meaning more accurately.

Keywords: Content, metadata, semantics, semantic tags, semantic tagging, semantic descriptors, semantic hints, semantic metadata, Web 3.0, XML, vector databases, vector search, vector embeddings, hybrid search, retrieval-augmented generation (RAG), knowledge graphs, word2vec, machine learning (ML), artificial intelligence (AI), large language models (LLM), natural language processing (NLP), domains, domain-driven design (DDD), and domain data resource articles.

Knowledge Workers:

Knowledge workers use their expertise, judgment, and analytical abilities to produce information and insights that support informed decision-making. Their work involves consuming, evaluating, and analyzing data from a variety of sources.

Knowledge workers draw on their experience, intuition, and subject-matter expertise to formulate effective queries and identify relevant, meaningful content. Understanding metadata and how information is organized can help them discover and retrieve that content more efficiently.

Common knowledge worker professions include academics, accountants, attorneys, business analysts, doctors, engineers, journalists, researchers, scientists, and software developers.

Knowledge work can also be supported or partially performed by automated software processes that use machine learning (ML) and artificial intelligence (AI). Examples include software agents, intelligent bots, and other automated systems that analyze information and perform knowledge-related tasks.

Language and Linguistics:

Linguistics is the scientific study of language, including its structure, meaning, and use. Understanding language requires an awareness of three related concepts: syntax, pragmatics, and semantics.

Syntax

Syntax concerns the rules governing how words, phrases, symbols, and other elements are arranged to form valid expressions in a language or formal system.

In natural languages, syntax primarily concerns grammatical structure. Related writing conventions include spelling, punctuation, and capitalization. Together, these conventions help ensure that expressions follow established rules and can be interpreted by their intended audience or by a computer system designed to process them.

Pragmatics

Pragmatics concerns how language is used in communication, including the practical methods and channels through which information is delivered. These methods include writing, speaking, email, and other digital media.

In linguistics, pragmatics also examines how a speaker's intentions, shared knowledge, and communicative circumstances influence the interpretation of an expression. Consequently, the same words can convey different meanings depending on the context in which they are used.

Semantics

Semantics concerns the meaning of words, expressions, and other forms of representation. Interpreting meaning may also require an understanding of context, including the subject being discussed, the intended audience, and the circumstances in which an expression is used.

Semantic understanding helps people answer fundamental questions about content, including who, what, where, why, and when. The answers help knowledge workers determine whether information is relevant to their questions and objectives.

Mastery of Language

Different aspects of language present different challenges for people and computer systems.

Many aspects of syntax and communication can be taught through explicit rules and conventions, although natural languages also contain exceptions and variations. Pragmatics can be more challenging because communicative intent and interpretation depend on circumstances, conventions, and shared knowledge.

Interpreting semantics can be considerably more difficult, especially when meaning is ambiguous, subjective, or nuanced. Understanding the literal meaning of a statement does not necessarily establish what the speaker intended to communicate.

Language and Computer Systems

Semantic interpretation presents significant challenges when developing computer-based models. Modern AI assistants and chatbots use large language models (LLMs) to generate responses based on patterns learned from data and other computational processes.

Although these systems can interpret many forms of language effectively, reliably understanding subjective and context-dependent communication remains challenging. Humor, hyperbole, sarcasm, and emotion can be particularly difficult to interpret accurately.

Computerized systems may also misinterpret negation, the scope of a statement, or contextual qualifications in a prompt. Such errors can produce responses that conflict with the user's intent.

Software engineering can mitigate some of these limitations through techniques such as retrieval-augmented generation (RAG), structured output schemas, and validation and feedback loops. Agentic workflows may also be useful when a task requires multiple steps or checks.

These techniques can improve grounding, consistency, and reliability. However, they do not guarantee correct interpretation or eliminate hallucinations.

Semantic Metadata:

Semantic metadata consists of taxonomies, tags, and other descriptive information that help communicate the meaning, subject, purpose, and relationships of content.

Machine-generated representations, such as vector embeddings, can also support semantic retrieval. However, embeddings are computational representations of learned relationships rather than conventional descriptive metadata fields.

The primary purpose of semantic metadata is to describe and organize content so that people and computer systems can discover, retrieve, and interpret it more efficiently. Semantic metadata helps knowledge workers understand what content is about and assess whether it is relevant to a particular query.

Descriptive metadata can reduce ambiguity in future retrieval queries. Poor retrieval results commonly occur when the query does not provide enough information to identify the desired result or when the indexed content lacks sufficient metadata and contextual information.

These problems can be summarized as follows:

Vague query: The query does not provide sufficiently specific details about the desired result.
Bad indexing: The content lacks sufficient metadata or contextual information to communicate its purpose and meaning.

For example, a search for "Hilton Paris" could return information about Hilton hotels in Paris, France, hotels in Paris, Texas, or the American socialite and media personality who travels with a tiny dog in her handbag.
Adding descriptive metadata to content and relevant contextual details to queries can improve search relevance and retrieval accuracy. The results also depend on the quality of the index, the retrieval method, and the ranking system.

Semantic Taxonomies

Taxonomies are classification systems that organize concepts into categories, often using a hierarchical structure. A taxonomy might organize information through a sequence such as category, subcategory, topic, subject, and item.

A content item, such as a published article or another digital artifact, can be assigned to one or more nodes in an existing taxonomy to provide additional context.

Hierarchical taxonomies are particularly useful for organizing content within well-defined bodies of knowledge. For example, biological classification systems organize organisms using categories such as kingdom, phylum, class, order, family, genus, and species. Modern biological classification systems also account for evolutionary relationships and clades.

Example: A Simplified Taxonomic Classification

The following example illustrates a simplified classification of short ragweed.

Clades: Tracheophytes, Angiosperms, Eudicots, Asterids
└── Order: Asterales
    └── Family: Asteraceae (also called Compositae)
        └── Genus: Ambrosia (ragweed)
            └── Species: Ambrosia artemisiifolia (short ragweed)

Limitations of Taxonomies

Strict hierarchical taxonomies can become inflexible when concepts belong to multiple categories or when emerging bodies of knowledge introduce new concepts and relationships.

However, not all taxonomies are restricted to a single-parent tree. Some knowledge-organization systems support multiple broader categories and associative relationships between concepts.

Knowledge graphs provide one approach to representing complex relationships among entities, concepts, and categories without requiring every relationship to fit within a single hierarchy. Relational databases can also represent taxonomies and support multiple classifications per content item through appropriate table structures and relationships.

The flexibility of any solution depends on its data model, schema, implementation, and query requirements. Standards such as the W3C's Simple Knowledge Organization System (SKOS) provide interoperable ways to represent concepts, labels, hierarchical relationships, and associative relationships.

Semantic Tags and Hints

Semantic Tags

Tags are concise keywords or short phrases that describe the subject, meaning, or relevance of content. They can help a retrieval system relate content to a user's query.

Tags can improve retrieval when they accurately describe the content and are used appropriately by the relevant search and indexing systems. They may also support search engine optimization (SEO), depending on how they are implemented. However, adding arbitrary tags does not automatically improve rankings in external search engines.

Tags are particularly useful for describing emerging bodies of knowledge because new tags can be created as new concepts arise. Their flexibility depends on the capabilities of the metadata schema, content-management platform, and search system.

Some systems impose limits on the number of tags that can be assigned to an individual content item. Freeform text, by contrast, has no inherent fixed limit on the number of tags that can be expressed, although an application may restrict how many tags it accepts, stores, or indexes.

Semantic Hints

Semantic hints provide additional context that helps disambiguate homographs and other ambiguous terms. A hint is a descriptive helper term that can accompany a tag or appear in a search query to clarify the intended meaning.

Parentheses provide a convenient way to express a hint, although this is a practical convention rather than a universal metadata standard.

For example, the term "Rush" could refer to a band, a film, a plant, or a person associated with radio broadcasting and political commentary. Adding a hint can help distinguish among these interpretations:

Rush (band)
Rush (film)
Rush (flora)
Rush (person, radio host, political pundit)

In some cases, nonstandard word forms can serve as practical disambiguators when the relevant search or indexing system consistently recognizes the distinction. For example, "hotdog" may refer to food, whereas "hot dog" could be used to describe a literal warm canine.

However, spelling variations alone are not a reliable substitute for structured metadata, controlled vocabularies, or unique entity identifiers.

Using Tags to Describe Context and Relevance

Tags can help answer fundamental questions that reveal the significance and context of content. The question "why" is particularly useful because it can explain the purpose, cause, or significance of information and help determine its relevance to a knowledge worker's query.

Answering "why" often requires identifying other fundamental details first. One practical approach is to identify who, what, where, and when, and then add why and other domain-specific details as needed.

This sequence is a useful heuristic rather than a universal rule. The most important questions depend on the subject, domain, and intended retrieval tasks. Within each grouping, tags can be applied from general to specific to improve consistency and support more precise retrieval.

The following questions provide a practical starting point:

Who? Who are the key people, organizations, or groups involved in, affected by, or otherwise associated with the content?
What? What are the key things, objects, events, topics, subjects, or concepts pertinent to the content?
Where? Which physical places, countries, states or provinces, counties or parishes, cities, or other geographic locations are relevant to the content?
When? Which dates, timeframes, eras, or other temporal references are relevant to the content?

Example: Distinguishing Two Interpretations of "Hilton Paris"

Consider a query for "Hilton Paris." The intended meaning becomes clearer when the associated information is classified using contextual tags.

Interpretation A: A Hilton hotel in Paris, France

what: hotel, Hilton Paris Opera
where: France, Paris

Interpretation B: Paris Hilton, the media personality

who: Hilton, Paris
what: socialite
where: USA, California, Beverly Hills
when: 1981-

These examples illustrate how additional context can distinguish different intended subjects. The exact fields and labels depend on the content model and retrieval system.

Tags and Database Systems

NoSQL databases, particularly graph databases, can be well suited to storing and retrieving tag-oriented semantic metadata when the data model, query requirements, and relationships among entities justify their use.

Relational databases and dedicated search indexes can also support tags, structured metadata, and relationships among content items.

The appropriate storage and retrieval technology depends on the scale of the system, its query patterns, consistency requirements, and the complexity of the data. The use of tags alone does not determine which database technology is most appropriate.

Vector Search and Embeddings

Manual tags and structured hints remain valuable, but modern information retrieval systems increasingly use automated semantic retrieval through vector embeddings and vector search.

Machine learning models transform words, sentences, and documents into high-dimensional numerical vectors that represent learned patterns of semantic and contextual relationships. These representations can capture useful similarities between pieces of content, although they do not guarantee a complete or human-like understanding of meaning.

Vector search compares query and content embeddings using similarity measures to identify potentially relevant information, even when the query and content use different words.

Retrieval quality depends on several factors, including the embedding model, the content being indexed, the construction of the query, and the search configuration. Vector search can return semantically similar but irrelevant results or miss important exact matches. Its results may therefore require additional filtering, ranking, or validation.

Vector databases store and index embeddings to support efficient similarity searches. However, vector search can also be implemented using other database systems and search technologies.

Retrieval-Augmented Generation (RAG)

Vector retrieval is often used as a component in retrieval-augmented generation (RAG) applications.

RAG retrieves source material that an LLM can use when generating a response. This approach can help ground the response in available content rather than relying exclusively on information encoded in the model's learned parameters.

However, RAG does not independently verify the truth, currency, or authority of retrieved material. It also cannot guarantee that the model will use that material correctly.

The quality of a RAG response depends on the relevance of the retrieved information, the reliability of the sources, and the model's ability to use the retrieved evidence faithfully.

Hybrid Search

Contemporary information retrieval architectures frequently employ hybrid search, which combines traditional keyword search with vector similarity search and may also incorporate structured metadata filters.

Each retrieval method contributes different capabilities:

Keyword search is particularly effective for exact terms, names, identifiers, dates, and specialized terminology.
Vector search can identify conceptually related content when a query and a document use different wording.
Metadata filtering can constrain results using structured attributes such as content type, location, date, or price range.

Combining these signals can improve retrieval quality when the methods complement one another. However, hybrid search does not guarantee better results for every query.

For example, hybrid search can help distinguish Hilton hotels in Paris from Paris Hilton, provided that the index contains useful metadata and the retrieval system applies the available signals appropriately.

Example: Finding Accommodation Near the Eiffel Tower

Suppose a user searches for "a place to stay near the Eiffel Tower." A relevant listing might describe itself as "accommodation near major Paris landmarks" without using the exact words in the query.

Different retrieval techniques can help identify the listing:

Keyword search identifies listings containing matching terms, such as "hotel" or "Eiffel Tower."
Metadata filtering narrows the results using structured fields such as content type, location, and price range.
Vector search identifies listings whose embedded representations are semantically similar to the query, even when they use different wording.
Hybrid search combines keyword matching, metadata filtering, and vector similarity to identify potentially relevant listings.

Additional validation may be necessary to confirm factual requirements such as actual distance, availability, and price.

When retrieved results are supplied to an LLM through RAG, the model can use the source material to formulate a more contextually relevant response. The resulting response should still be evaluated for accuracy and appropriate use of the evidence.

Other Descriptive Information

Content can also be described using metadata that provides structural, administrative, technical, and contextual information. These fields complement semantic tags by describing characteristics of the content itself and its relationship to other resources.

Front Matter

Front matter is a block of metadata placed at the beginning of a document. It is commonly used in Markdown documents and static-site generators.

Front matter often uses YAML or TOML, although some tools and workflows use JSON to represent document metadata. It can define properties such as the title, author, publication date, category, tags, description, and content type.

By separating descriptive metadata from the main body of a document, front matter makes it easier for compatible software tools to parse, index, organize, and display the information.

The exact syntax, supported fields, and processing behavior depend on the format and application.

Common Types of Descriptive Metadata

Descriptive metadata can include several types of information:

Titles and summaries communicate the subject and purpose of the content.
Authors and contributors identify the people or organizations responsible for creating or maintaining the content.
Dates and version information indicate when the content was created, published, modified, or superseded.
Content types and formats identify whether an item is an article, report, reference document, image, dataset, or another type of resource.
Identifiers and relationships distinguish individual content items and connect them to related resources.
Descriptions and usage information explain the intended audience, purpose, scope, provenance, licensing, or access requirements.
Technical metadata records properties such as file format, encoding, dimensions, and other characteristics relevant to processing and preservation.

Unlike semantic tags, which primarily label the subjects or concepts associated with content, these additional metadata fields can describe who created the content, when it was produced, how it is structured, why it exists, and how it relates to other resources.

The categories can overlap. For example, a title or description can communicate semantic meaning while also serving as general descriptive metadata.

Combining semantic tags with structured descriptive metadata can improve content discovery, filtering, organization, interoperability, and long-term maintenance.

Takeaways:

1. Create Content with Accurate Semantic Metadata

Content creators should include accurate, descriptive semantic metadata to help ensure that their content is appropriately indexed, reduce ambiguity, and make its intended meaning easier for others to discover and understand.

They should use structured metadata, consistent tags, and appropriate identifiers wherever the content-management and retrieval systems support them. They should also recognize that metadata improves discoverability only when it is maintained and used effectively by the relevant systems.

2. Understand Modern Information Discovery Tools

Knowledge workers should understand how semantic metadata and modern AI-driven discovery tools can help them formulate more precise queries and retrieve relevant information efficiently.

They should combine domain knowledge with appropriate search techniques, including keyword search, metadata filters, and vector search where available. They should also evaluate retrieved results rather than assuming that relevance rankings guarantee factual accuracy.

3. Provide Sufficient Semantic Context

When querying data, users should provide enough semantic context to distinguish the intended subject from other subjects with similar names or terms.

For example, the query "Paris Hilton" is ambiguous when the intended result is a Hilton hotel in Paris, Texas. A more explicit query, such as "Hilton hotel, Paris, Texas," communicates the intended subject more clearly.

Where supported, structured metadata filters and hybrid search can further distinguish the intended subject from competing results.

4. Use Clear and Explicit Language

Users should describe their intended outcomes as directly as possible and use clear, explicit language.

When it improves clarity, they should describe the desired outcome affirmatively and identify phenomena in terms of their actual properties, attributes, forms, modalities, or states.

Negation remains appropriate when it communicates a necessary constraint or exclusion. However, users should avoid relying on vague or unnecessarily indirect descriptions of what is absent, missing, or lacking.

For example, when describing an open door, "the door is open" communicates the intended state more directly than "the door is not closed."

When prompting LLMs, users should provide sufficient context and explicit constraints. They should also validate important outputs rather than assuming that careful phrasing alone will prevent errors.

5. Choose Technologies According to Task Requirements

Information-management technologies should be selected according to the requirements of the task.

Taxonomies, relational databases, search indexes, and knowledge graphs can all support content organization and retrieval, depending on the data model and the relationships involved.

Vector search and RAG can enhance semantic retrieval and response generation, but their effectiveness depends on source quality, retrieval configuration, and appropriate validation.

References:

Related Webpages

The AI Content Firehose and Why So Much Of It Tastes Like Thin Gruel or Hotdog Water

jsvnsk-tech — Wed, 14 Oct 2026 13:45:16 +0000

Overview:

This article is an intentionally humorous take on the growing gap between the quantity of AI-generated output and its genuine quality. For technology professionals experiencing AI fatigue, the article offers respite in the form of comic relief. For people new to AI, the article serves as a primer and a reality check for setting reasonable expectations about using AI systems.

keywords: artificial intelligence, AI-generated content, AI-assisted software development, software engineering, code quality, technical writing, software testing, code review, developer productivity, human oversight, software craftsmanship, validation

1. Introduction

Artificial intelligence has given us a remarkable superpower: the ability to produce more code, more articles, more documentation, and more opinions than ever before.

Naturally, we have used this power responsibly.

Just kidding. Of course we haven't.

We've unleashed a content firehose, and we're all standing around wondering why the water tastes weird.

Some of what AI produces is genuinely brilliant. Some of it is useful with a little polishing. And some makes you wonder whether anyone involved has actually read the output, let alone checked whether it makes any sense.

So how did we get here? And why, when generating things has become so ridiculously easy, does producing something genuinely good still seem so difficult?

Let's investigate.

2. The Content Explosion

In the span of a few short years, AI magically transformed everyone into an expert.

Blog articles appeared. Tutorials appeared. Architecture guides appeared.

Ten-part series sprang out of nowhere to explain technologies that had been released eleven minutes earlier.

There were articles titled:

The Ultimate Guide to Building Scalable Applications
Why Everything You Know About Programming Is Wrong
I Replaced My Entire Development Team With AI
Best Practices That Will Make You a 10x Software Engineer

The last one was written by someone who had never been a software engineer. It contained 47 best practices. The author was 11 years old.

Each article had a compelling introduction, seventeen headings, three code examples, and a conclusion beginning with the words "In today's rapidly evolving technological landscape."

That phrase appeared so frequently that developers began to suspect it was being used as a substitute for actual thought. They were not entirely wrong.

But the articles were beautifully formatted.

They had bullet points. They had bold text. They had code fences. Some even had diagrams.

And somewhere, deep within the prose, there might have been a useful idea or two.

Possibly.

The problem was that finding truly meaningful and insightful information required the patience of an archaeologist and the caffeine tolerance of a production engineer during an outage.

Welcome to the age of infinite content: where the supply of output is unlimited, but attention spans are decidedly not.

The same thing was happening to code.

Developers were generating entire applications, test suites, API clients, and architectural masterpieces, all before second breakfast.

Some of the results were excellent. Some were adequate. Some were technically impressive solutions to problems nobody had.

And some were the software equivalent of a shopping cart with a wobbly wheel: technically functional, but an experience nobody would willingly repeat.

We had become extraordinarily good at producing things.

But we often forgot to ask whether any of that stuff deserved to exist in the first place.

3. Thin Gruel and Hotdog Water

There is a particular kind of AI-generated content that reminds me of thin gruel.

It is not necessarily offensive. It is not necessarily incorrect. It is simply disappointing.

You read three paragraphs and realize you've consumed several hundred words without encountering a single new thought.

The article explains that testing is important, security matters, and maintainability is desirable.

It explains that developers should follow best practices. Thank goodness; for a moment, we were in danger of doing otherwise.

The prose is smooth, the grammar is impeccable, and every sentence arrives wearing a little name tag that says Technically Reasonable Statement.

But there is no flavor. No aroma. No experience. No tattoos. No scar tissue.

No mention of the production database that was accidentally truncated because someone confused a staging connection string with a production one.

No story about the developer who spent six hours debugging a race condition that turned out to be caused by a virtual machine's clock drifting several minutes into the future.

No hard-won lesson or insight forged in the fires of actual inconvenience.

Just a pleasant bowl of beige blandness. And then another bowl. And another.

The problem isn't that the writing is bad.

The problem is that it has nothing particularly significant to say.

It's the literary equivalent of a "Hide the Pain Harold" meme.

Harold smiles at his laptop and says something innocuous and mildly amusing.

You chuckle, but five minutes later, you've probably moved on and forgotten what he said.

The same phenomenon appears in code.

A class is created because classes are good.

An interface is introduced because interfaces make code maintainable.

A factory creates a provider that resolves a strategy that delegates to a manager that orchestrates a handler.

The abstractions are immaculate.

The code actually compiles and does something.

But the AI generated it, the IDE formatted it, and the deployment pipeline sent the change straight into production.

And that's the problem with the AI content firehose: it easily produces something that, on the surface, appears useful.

However, producing something that actually is useful often remains elusive.

It's not that every piece of AI-generated writing is bad. And it's not that AI can't produce something insightful, surprising, or genuinely useful.

It's just that grammatical correctness, professional formatting, and a convincing imitation of expertise are no longer particularly strong signals of substance.

When everyone can produce an endless supply of plausible content, plausibility stops being impressive.

We're left with an internet overflowing with words that look like they should mean something, code that looks like it should work, and explanations that look like they should teach us something.

And somewhere in all that volume, the distinction between merely generating something versus producing something meaningful and important gets lost.

The firehose keeps flowing, and the bowls keep filling up.

Occasionally with a delicious and nourishing soup.

But more often with thin gruel.

And sometimes, just hotdog water.

4. The Quality Problem

Now, before anyone gets too terribly upset, let us establish something important.

AI can produce excellent work. Remarkable work, even.

It can help an experienced developer explore unfamiliar code, uncover edge cases, generate useful tests, explain complicated concepts, and build prototypes that would otherwise take days.

It can help a talented writer organize their thoughts, improve their prose, and overcome the dreaded blank page.

Sometimes it produces something so good that you stare at the screen and whisper: "Well, that's annoyingly impressive."

The problem is not that AI always produces bad work.

The problem is that it produces work of wildly varying quality.

Some output is excellent. Some is adequate. Some is wrong in ways that are immediately obvious. And some is wrong in ways that will require a production incident, a security audit, and three senior engineers to discover.

Unfortunately, outputs which are good, bad, or ugly all tend to arrive wearing shockingly similar cowboy suits.

The code is formatted. The explanation is coherent. The article sounds authoritative. The answer arrives in seconds.

There is no flashing red light that says: WARNING: THIS SOLUTION WAS ASSEMBLED FROM A PLAUSIBLE INTERPRETATION OF REALITY.

There is no little bell that rings when the machine invents a library method.

No smoke emerges from the laptop when the generated SQL quietly deletes the wrong rows.

The machine simply presents its work. Confidently. Politely. And with impeccable Markdown.

And we, being busy people with deadlines, are sometimes inclined to believe it.

5. The Missing Step

So why does this happen?

Why can the same technology produce both extraordinary work and absolute crap?

Part of the answer is that generating an answer and verifying an answer are two very different activities.

An LLM can produce very convincing output without establishing that every claim is true, every assumption is justified, or every line of code behaves as intended.

It can generate something that resembles a solution.

That resemblance can be useful. It can also be dangerous.

Consider a simple request: "Write a function that validates an email address."

The machine produces a function.

It looks reasonable. It has a descriptive name. It handles empty input. It uses a regular expression. It has comments. It has tests.

The tests pass.

But perhaps the expression rejects perfectly valid addresses.

Perhaps it accepts addresses that the application cannot actually deliver to.

Perhaps the requirements never called for a comprehensive email validation function in the first place.

The function isn't necessarily useless. However, just because it looks like it was written by someone who knew what they were doing doesn't automatically mean it's correct.

Now consider a different request: "Write a comprehensive guide to database indexing."

The machine produces 2,000 words.

It explains B-trees. It discusses query performance. It mentions write overhead. It includes SQL examples.

Everything sounds sensible, but perhaps one example is misleading.

Perhaps a claim about a particular database engine is outdated.

Perhaps the author has never actually diagnosed a slow query in production.

Perhaps the article repeats familiar advice without explaining when that advice stops being useful.

The output exists, but the work of establishing its quality does not magically appear alongside it.

We have become very good at asking machines to produce things.

However, we often forget to perform the important post-processing tasks which are necessary to actually validate the output and shape it into truly useful and meaningful content.

This is the missing step.

6. The Consequences of Failing to Validate the Output

Let us imagine a small software company. The company has adopted AI-assisted development. Productivity has increased dramatically.

Previously, the team produced five pull requests a week. Now it produces fifty. Management is thrilled.

A slide deck is prepared.

The slide deck contains a graph that goes up and to the right.

Someone adds the word transformation.

Someone else adds the word exponential.

The slide deck is thoroughly impressive.

The company schedules a meeting to celebrate and congratulate itself.

Meanwhile, the quality engineering team has not grown.

The code review process has not changed.

The integration test suite still takes 38 minutes to run.

The person who understands the payment system is on vacation.

And the backlog of things that need careful human attention has increased tenfold.

The company has successfully accelerated production, but it has not accelerated understanding by the same amount.

And so the pull requests accumulate.

Some are excellent. Some are harmless. Some introduce subtle bugs.

Some contain duplicated abstractions that solve problems nobody had.

Some have tests that verify the implementation's assumptions rather than the requirements.

One contains an entire retry framework for an operation that cannot fail.

Another contains a caching layer that actually makes the application slower.

A third introduces a dependency to save a line feed at the end of every script.

Nobody notices because the code is beautifully formatted and the pull request description boldly says: "Improves reliability, maintainability, and performance."

This is a particularly effective sentence. It promises three righteous benefits without requiring the author to demonstrate any of them.

Eventually, someone asks whether the new code is actually better.

Silence follows.

A developer opens the AI assistant and asks, "Can you review this code for potential issues?"

The machine produces a detailed review. The review is thoughtful. It identifies several genuine concerns.

It also recommends a refactor that introduces a different set of problems.

The developer accepts the suggestions.

The tests pass.

The pull request is merged.

And somewhere, in the distance, a production engineer begins to experience a severe migraine.

Far too often, unnecessary new problems are the regrettable consequence of failing to take the time to actually interpret and validate the results produced by pressing the "easy button."

7. The Test That Tested Nothing

Of all the small tragedies in the AI age, my favorite is the test suite that exists primarily to reassure its author.

AI can generate tests remarkably quickly. This is useful.

It can also generate tests that are remarkably good at confirming that the code does exactly what the code already does.

Suppose we have a function that calculates a discount, but the function is wrong: it applies a 15% discount twice.

We ask AI to generate unit tests.

The machine examines the function and generates tests based on its implementation.

The tests pass. Everyone is happy.

But the discount is still wrong.

We have not tested the business requirement; instead, we have merely tested the machine's interpretation of the implementation.

This is not a test suite; it's a mutual appreciation society.

The code says, "I believe this is correct."

The tests reply, "We agree."

The production system says, "I would like to introduce myself."

Of course, AI-generated tests can be extremely valuable. They can uncover edge cases, improve coverage, and save significant time.

But tests need an independent basis for judging correctness.

Requirements. Invariants. Expected outcomes. Known edge cases. The behavior that the system is supposed to exhibit, rather than just the behavior it currently exhibits.

Absent the requisite comprehension, there is a strong possibility that we may end up with an efficient testing framework that merely produces evidence that simply agrees with itself.

8. The Author Has Left the Building

There is another problem: ownership.

When a developer writes a complicated function, they usually have at least some idea why it exists.

They may remember the bug that motivated it.

They may remember the failed approach that came before it.

They may remember the awkward conversation with the database administrator who explained that the query they had written was, technically speaking, a crime.

They possess context, but not always enough context.

Software engineers are perfectly capable of writing code they do not understand. We have been doing this for decades, and the evidence is stored in repositories around the world.

AI has simply made it easier to produce more of it.

A developer asks for an implementation. The implementation arrives.

The developer asks for an explanation. The explanation arrives.

The developer asks for a refactor. The refactor arrives.

At no point does the developer necessarily develop a reliable mental model of the resulting system.

And then comes the maintenance ticket.

"Update the behavior of the notification service to accommodate the new customer preference rules."

The developer opens the code.

It contains 14 interfaces, six factories, three adapters, and a class called NotificationOrchestrationStrategyResolver.

The original developer is no longer on the project.

The person who generated the code is not available.

The AI assistant explains the implementation.

The explanation is plausible.

The developer makes a change.

The tests pass.

Something breaks.

And so begins the ancient ritual of software archaeology, now conducted with a chatbot and considerably more generated code.

The question is not whether AI wrote the code.

The question is whether anyone understands it well enough to maintain it.

9. The Human in the Loop

At this point, someone will inevitably suggest that we should simply keep a human in the loop.

Excellent. Let us do that. We will place a human in the loop.

The human will review the generated code, verify the claims, inspect the tests, validate the assumptions, check the dependencies, assess the security implications, and confirm that the result meets the actual requirements.

The human will then approve the work. There is only one small problem. Well, actually several.

The human has 23 other things to do.

The human has a meeting in six minutes.

The human has already reviewed 19 pull requests today.

The human has been told that AI will increase productivity, which means that the expected volume of work has increased accordingly.

The human sees a clean diff.

The human sees green check marks.

The human sees a detailed explanation of why the implementation is correct.

The human thinks: "Looks good to me," and clicks the "Approve" button.

We have successfully placed a human in the loop, but the loop has become a rubber stamp.

This is not a failure of human intelligence; it is a failure of process design.

If we increase the volume of generated work without allocating sufficient time for careful review, thorough testing, and meaningful verification, we should not be surprised when quality suffers.

10. The Return of the Craftspeople

Perhaps the answer is to become more deliberate about what we choose to accelerate.

Use AI to generate the first draft.

Use it to explore unfamiliar APIs.

Use it to suggest test cases, explain complicated code, identify potential vulnerabilities, and automate the repetitive parts of development.

Use it to get past the blank page.

Use it to save time on the tedious work that prevents us from doing the interesting work.

But then actually do the interesting work.

Read the code. Run the tests. Challenge the assumptions. Verify the claims. Check whether the solution fits the actual problem.

Ask whether the abstraction is necessary.

Ask whether the article contains an insight or merely an assortment of grammatically correct sentences.

Ask whether the tutorial was tested against the current version of the software.

Ask whether the impressive-looking benchmark measures anything that truly matters.

Ask whether the code is understandable to the person who will maintain it next year.

And occasionally ask the most important question of all: "Would I have accepted this if a junior developer had submitted it without mentioning AI?"

If the answer is no, then perhaps it needs another look.

Not because AI is inherently untrustworthy, but because the standards for accepting good work should not depend on how quickly it was produced.

11. The New Definition of Productivity

We may need to reconsider what we mean by productivity.

For years, software development has been obsessed with output.

Lines of code. Features delivered. Tickets closed. Pull requests merged. Articles published. Pages generated.

We have measured the things that are easy to count and occasionally confused them with the things that matter.

AI often makes this confusion even harder to understand.

Question 1: If a developer can generate ten times as much code, is the developer ten times as productive?

Answer 1: Only if the code produces ten times as much useful value without creating a proportional increase in defects, maintenance costs, and cognitive overhead.

Question 2: If a writer can publish ten articles in the time previously required to write one, is the writer ten times as productive?

Answer 2: Only if the articles are worth reading.

Question 3: If an organization can generate a thousand tests, has it improved quality?

Answer 3: Only if those tests provide meaningful evidence that the software behaves correctly.

Volume is not value. Speed is not quality. Confidence is not correctness. And green check marks are not a substitute for thinking.

The most productive developer may not be the one who generates the most code.

It may be the one who generates the right code, catches the subtle bug before it reaches production, and deletes 400 lines of unnecessary abstraction.

The most productive writer may not be the one who publishes every morning.

It may be the one who publishes something worth remembering once a month.

The machines can help us produce more.

We still have to decide what deserves to exist.

12. The Great Opportunity

It would be easy to conclude that we are drowning in garbage AI content.

That statement is probably unfair.

There is plenty of garbage in software and writing that predates AI.

We have always had bad code. We have always had mediocre articles.

We have always had cargo-cult architecture, cargo-cult testing, and people who confidently explain things that they barely understand.

We have always had a tendency to reward visible activity over invisible craftsmanship.

AI did not invent these problems; however, it did give them a much more powerful distribution mechanism.

But it also gives us an extraordinary opportunity.

Imagine a world in which generating the first draft of an implementation takes seconds, leaving more time to examine its design.

Imagine tests that are generated quickly and then strengthened with independently defined requirements.

Imagine documentation that is drafted automatically and verified against the actual behavior of the system.

Imagine developers spending less time writing boilerplate code and more time understanding the actual problems they are trying to solve.

Imagine technical writers using AI to organize research while retaining the experience, judgment, and personality that make their writing worth reading.

Imagine a culture in which publishing something quickly is considered useful, but publishing something correct and insightful is considered essential.

That would be progress.

Not because the machines have replaced the craftspeople.

Rather, because the craftspeople have better tools.

And also because we've finally realized that swinging a hammer faster doesn't really make someone a better carpenter.

13. The Final Review

And so we arrive at the present day.

The machines are generating code. They are generating tests. They are generating documentation.

They are generating articles about generating code, tests, and documentation.

Some of the results are extraordinary.

Some are perfectly adequate.

Some are thin gruel.

Some are hotdog water.

And some are the sort of thing that makes a senior software engineer stare at their monitor in stunned silence for several minutes.

But we should not despair.

This is not the end of software engineering.

It is not the end of writing.

It is not the end of human creativity.

It is simply another moment in which our tools have become more powerful than our habits have become wise.

We must adapt our techniques purposefully and meaningfully.

We could respond by generating more content.

More code. More articles. More frameworks. More tutorials. More documentation explaining the documentation.

Or we can learn to value the part of the process that has not become obsolete.

Judgment. Experience. Curiosity. Verification.

The willingness to say, "This looks convincing, but I don't believe it yet."

The humility to admit that a generated answer might be wrong.

The discipline to test it anyway.

The good sense to delete it when it is unnecessary.

And the courage to publish an article that contains an actual opinion, even if that opinion cannot be summarized in a bulleted list of best practices.

The future does not belong to whoever can generate the most.

It belongs to whoever can consistently turn generated material into something useful, reliable, and worth the time it takes to consume it.

So go forth. Generate boldly. Experiment enthusiastically.

Let the machines do the tedious work.

But before you merge that pull request, publish that tutorial, or proudly announce your new AI-powered productivity framework, take a moment to review the result.

Read it. Test it. Question it. Taste it. Poke it with a stick.

Because if the code is broken, the article is empty, and the tests merely agree with the bugs, we have not automated craftsmanship; we have automated the production of things that merely look like craftsmanship.

14. Full Disclosure

This article was written and edited by a human who leveraged AI assistance.

Combinatorial Testing: Improving Negative Testing with Pairwise Design

jsvnsk-tech — Mon, 12 Oct 2026 17:57:21 +0000

Overview:

This article is about how combinatorial test design and pairwise testing can improve negative testing coverage. In particular, it examines how to reduce repetitive test cases and reveal weaknesses in manual review processes.

keywords: combinatorial test design, pairwise testing, all-pairs testing, negative testing, Hexawise, seeded errors, test coverage, reviewer fatigue, interaction testing, quality assurance, QA, quality engineering, QE, risk-based testing, manual review processes, human-in-the-loop review processes

Combinatorial Test Design:

Combinatorial test design systematically selects test cases to cover interactions among multiple factors. Factors represent dimensions that may influence an outcome, such as error type, severity, confidence level, and document type. Each factor can have multiple values, creating a potentially large number of combinations. Testing every combination may be impractical as the number of factors and values increases, so combinatorial methods select a smaller, structured set of test cases to achieve meaningful coverage with less effort.

The objective is to maximize relevant coverage while controlling testing effort. Systematic selection reduces reliance on ad hoc test design, while coverage criteria make test design more repeatable and measurable. The appropriate level of coverage depends on risk, complexity, and the consequences of failure. High-risk scenarios may require additional targeted tests beyond the selected combinations.

Pairwise Testing:

Pairwise testing, also known as all-pairs testing, is a combinatorial technique that aims to cover every valid pair of values across every pair of factors at least once. The resulting test suite is often substantially smaller than one that tests every possible combination. Pairwise testing can reveal defects caused by interactions between two factors without requiring exhaustive testing, while constraints can exclude combinations that are invalid or impossible in the system under test. However, pairwise coverage does not guarantee detection of defects that require three-way or higher-order interactions.

Coverage should reflect the risks being evaluated. Test designers can supplement pairwise coverage with higher-order combinations, boundary cases, and specific high-risk scenarios. Coverage reports help identify which combinations have been tested and where gaps remain. However, it is important to note that the number of test cases alone is not a reliable measure of coverage or effectiveness.

Applying Combinatorial Design to Negative Testing:

Negative testing evaluates whether a process correctly identifies or handles errors and undesirable conditions. Seeded errors are deliberately introduced problems used to evaluate the effectiveness of various review processes. Relevant factors may include error type, impact, confidence band, document type, and other characteristics that influence detection.

Systematically varying these factors reduces repetitive patterns that reviewers may learn to recognize. Realistic seeded errors help measure review effectiveness rather than familiarity with artificial test examples.

The goal is to introduce controlled variation while preserving measurable coverage. Pairwise design provides a structured starting point for varying seeded-error characteristics, while high-risk combinations can receive additional coverage where necessary. Consistent design and scoring criteria make results easier to reproduce and compare across testing cycles.

Using Hexawise for Combinatorial Test Design:

Hexawise is a test design tool that generates optimized test scenarios from user-defined factors and values. Test designers define the conditions to be varied and specify relevant constraints and required scenarios. Coverage settings allow test designers to adjust the thoroughness of the test set to reflect risk and testing constraints, while coverage reports help visualize which interactions are covered by the generated scenarios. Test scenarios can be exported into supported formats for use in test management and execution workflows.

Hexawise can help translate a negative testing strategy into a structured test suite. Pairwise coverage can provide a baseline for varying seeded-error characteristics, while higher-order coverage can provide additional scrutiny where interactions among three or more factors present meaningful risks. Generated scenarios provide a documented basis for test execution and coverage analysis. The tool supports test design, but reviewers' detection rates, false positives, and missed errors must be measured separately.

Successful application depends on the quality of the test model. Factors, values, and constraints must reflect realistic conditions and meaningful risks. The tool does not independently determine whether seeded errors are realistic or difficult to detect. Queue position, time of day, day of the week, and reviewer fatigue may require additional test dimensions or a separate placement strategy.

See the following related webpages for further details about Hexawise:

Hexawise FAQ:
https://hexawise.com/faq

Hexawise features:
https://hexawise.com/features

Accounting for Queue Position and Reviewer Fatigue:

Reviewer attention may vary with workload, timing, and the number of items already reviewed. Early items may receive more scrutiny than items encountered later in a long queue. Time of day, interruptions, and workload may also influence review performance. Testing only early queue positions may therefore overstate detection rates under sustained workloads.

Queue position and timing can be incorporated into the test strategy. Practical measures include:

distributing seeded items across early, middle, and late queue positions and relevant review periods
using predefined placement rules for repeatability and controlled randomization to reduce predictable patterns
tracking these dimensions alongside error characteristics to identify performance differences
investigating reviewer fatigue as a possible influence rather than assuming it explains every change in results

This introduces an additional dimension to negative testing: when a test item appears, not just what it contains. A structured placement strategy can introduce unpredictability without sacrificing auditability. Testing across realistic workloads helps evaluate performance beyond idealized review conditions.

Design Considerations and Limitations:

Effective test design balances coverage, realism, and testing effort. Factors and values should represent plausible real-world conditions, and seeded errors should resemble genuine errors in presentation, difficulty, and frequency. Reviewers should not be able to infer seeded items from repetitive wording, formatting, placement, or frequency. Higher-risk scenarios may require additional targeted tests beyond pairwise coverage.

Test coverage must be distinguished from actual review effectiveness. Pairwise coverage does not guarantee detection of every defect, and some defects depend on interactions among three or more factors. Results depend on sample size, error difficulty, reviewer experience, and test conditions. Documented design rules and scoring criteria support consistent interpretation and comparison.

Measuring Effectiveness:

Predefined measures help determine whether the review process performs as intended. Three useful measures are:

seeded-error detection rate: the proportion of seeded errors correctly identified
false-positive rate: the proportion of valid items incorrectly flagged as erroneous
missed-error analysis: identification of error types and conditions associated with lower detection rates

Analyzing results across test dimensions reveals where performance may need improvement. Compare detection rates by error type, impact, confidence band, and document type, and examine performance across queue positions and review periods. Consider sample sizes and uncertainty before interpreting differences. Use findings to guide reviewer training, workflow improvements, and additional testing.

Conclusions:

Combinatorial test design and pairwise testing provide a structured way to improve negative testing coverage and efficiency. Combinatorial design establishes the strategy for selecting meaningful test combinations, while pairwise testing provides systematic coverage of interactions between pairs of factor values. Hexawise helps generate and document test scenarios according to defined coverage requirements. Realistic seeded errors and variation across queue positions help evaluate review performance under representative conditions, while objective measurement distinguishes genuine review effectiveness from the ability to recognize test patterns.

The central principle is to introduce controlled variation without sacrificing measurement quality. A predictable design provides a structured way to introduce unpredictability into the negative testing scenario. Risk-based testing, higher-order coverage, and consistent outcome measurement help address the limitations of pairwise testing. The ultimate goal is to determine whether reviewers identify genuine errors reliably under realistic working conditions.

Romancing the Monolith

jsvnsk-tech — Thu, 08 Oct 2026 15:29:00 +0000

Overview:

This article is a humorous look at the evolution of software architecture over the past few decades, from giant monoliths to sprawling microservices and AI-generated code.

keywords: AI assistants, large language models, LLMs, software engineering, monoliths, microservices, The Book of Microservices

1. The Monolith

In the beginning, there was a monolith.

And the monolith was large.

Very large.

It had been carefully curated over many years by shaggy, neckbearded software engineers rooted firmly in the bland technoculture of the 20th century. They wrote code in languages that required semicolons, deployed software on actual servers, and believed that documentation was something you produced after the system was finished.

The monolith contained everything.

Authentication was there.

Billing was there.

Reporting was there.

There was a module called CustomerManager, which appeared to manage customers, except nobody knew exactly which customers or why. There was also CustomerManager2, which had been created during a particularly difficult quarter and was never spoken of again.

There were stored procedures.

There were batch jobs.

There were cron entries nobody remembered creating.

There was one function called processOrder() that was 4,873 lines long.

And somehow, against all known laws of software engineering, it worked.

The neckbearded-ones understood the monolith.

Not completely, perhaps. No one completely understood the monolith. But they understood enough.

They knew that if the billing system suddenly started charging customers twice, you restarted the server named BUBBA03.

They knew that if you changed the customer address, you waited eleven minutes before checking whether the change had propagated.

They knew never to delete the table called TEMP_CUSTOMER_BACKUP_FINAL_FINAL.

Most importantly, they knew why.

Or at least, some of them did.

2. The Microservices

Then came the newcomers with their neatly-trimmed chinbeards.

They had no nostalgia for physical servers like BUBBA03.

They had never heard the phrase "we'll just FTP it over from the mainframe."

They spoke fluently about containers, event-driven architectures, vector databases, observability, and whatever new thing had appeared on Hacker News that morning.

"We need to decompose," said the senior chinbeard.

The neckbeards were confused.

"Decompose? You mean like rotting vegetables?" they asked.

"No. We need microservices."

Microservices.

That word was spoken in conference rooms with great confidence.

PowerPoint slides appeared.

Boxes were drawn.

Arrows connected the boxes.

Someone put the word SCALABILITY in enormous letters across a slide.

And so they decomposed.

And decompose they did.

The monolith was broken into numerous microservices, scattered to the winds of Google, AWS, and Azure.

There was a Customer Service.

There was an Order Service.

There was an Order Customer Service.

There was a Customer Order Service.

There was a Customer Order Notification Service.

There was a Customer Order Notification Service Adapter.

Nobody was entirely sure what the adapter adapted, but it had its own Kubernetes deployment, so everyone agreed it was important.

The architecture diagrams became magnificent.

The diagrams were so magnificent that people stopped asking whether the system was actually simpler.

The old monolith had one application.

Now there were 147 repositories.

The old system had one deployment.

Now there were 38 pipelines, 19 Helm charts, 11 Terraform modules, and a Slack channel called #platform-escalations.

The old system had one log file.

Now the logs were distributed.

Very distributed.

So distributed, in fact, that nobody could find them.

But this was progress.

Everyone agreed that this was progress.

And for a while, it was.

3. Artificial Intelligence

Then came the clean-faced ones.

They had no neckbeards or chinbeards.

In fact, they had no beards at all.

This was more progress.

The clean-faced newcomers optimized the microservice code with AI.

The AI explained the code.

The AI refactored the code.

The AI generated tests for the code.

The AI generated documentation explaining the tests.

Someone asked whether the AI-generated documentation was accurate.

The AI confidently replied that it was.

And so everyone believed it was.

Then, as had become customary in modern technology companies, the first wave of clean-faced newcomers promptly sought employment elsewhere.

They went to startups.

They went to FAANG companies.

They became "founding engineers."

They became "AI transformation architects."

They updated their LinkedIn profiles.

And they left.

Behind them remained the code.

And the code was good.

Probably.

No one really knew.

New baby-faces were hired to comprehend the legacy of the earlier ones.

They arrived with fresh laptops, fresh credentials, and absolutely no idea what the system did.

Their first ticket was simple:

"Make a small change to the customer notification flow."

They opened the repository.

The repository then opened 17 linked repositories.

They followed a dependency.

The dependency led to yet another repository.

That repository depended on a service owned by a team that had been dissolved two years earlier.

The service depended on an API.

The API depended on an event.

The event depended on a Kafka topic.

The Kafka topic had no producer; or rather, it had a producer (but nobody knew where).

The baby-face opened the AI assistant.

"Can you explain what this service does?"

The machine considered the question.

It returned 3,000 words.

The baby-face read them carefully.

"So... does it send emails?"

"Yes," said the machine.

"Only emails?"

"Primarily."

"What does 'primarily' mean?"

The machine generated another 3,000 words.

The baby-face closed the window.

And so they asked the machines what all of those little piles of code did.

The machines answered.

Sometimes correctly.

Sometimes incorrectly.

Sometimes with such confidence that the difference was impossible to detect.

4. The Archaeologists

Eventually someone found an old architecture document.

It was dated 2018.

It contained a diagram of the original monolith.

Someone printed it.

They gathered around it like archaeologists discovering a map of a lost civilization.

"This is the billing system?"

"Yes."

"And this is the customer database?"

"Yes."

"And this service replaced that module?"

"I think so."

"Why?"

Silence.

Someone checked the repository's Git history.

The commit message read: refactor stuff

Another read: final changes

Another: final changes 2

Another: temporary fix

That last modification was seven years ago.

It was obviously not temporary.

5. The Organization Understands

At last, the organization understood what it had done.

It had not destroyed the monolith.

It had merely distributed it.

The complexity had survived.

In fact, it had multiplied.

It had acquired YAML.

But it was too late.

The monolith's corporeal body was gone, but its spirit lived on in hundreds of repositories, thousands of configuration files, forgotten cloud resources, undocumented APIs, and dashboards nobody opened unless there was an incident.

And there were no longer any bearded elders who understood the system.

There were only teams.

And JIRA tickets.

And on-call rotations.

And AI assistants patiently explaining code that nobody remembered writing.

6. The Incident

One Friday afternoon, a junior engineer opened a pull request.

The change was tiny.

The tests passed.

The deployment succeeded.

Everything looked fine.

Then, somewhere in a cloud region no one could remember choosing, a customer received two invoices.

The engineer stared at the monitoring dashboard.

The dashboard turned red.

Slack exploded.

Someone typed: "Who owns this?"

Someone else replied: "I think Payments."

Payments replied: "Not us. Customer Platform."

Customer Platform replied: "We only own the API."

Someone asked the AI.

The AI suggested restarting a pod.

Someone restarted a pod.

Three more pods died.

And thus, as it had been in the beginning, the organization once again gathered around the system.

Except now there was no monolith.

There were only microservices.

Many, many microservices.

And nobody knew why.

7. The Great Achievement

The organization had achieved something remarkable.

It had successfully transformed one giant pile of code that nobody fully understood into several hundred smaller piles of code that nobody fully understood.

And somewhere, in an old repository scheduled for archival, a comment remained:

// TODO: clean this up when we understand how it works.

It had been written twelve years ago.

It was still there.

And it was still waiting.

When ChatGPT Explains What It Will Do Instead of Doing It

jsvnsk-tech — Wed, 07 Oct 2026 05:50:06 +0000

Overview:

This article is about task-completion regression with ChatGPT.

keywords: AI assistants, large language models, LLMs, ChatGPT, task-completion regression, machine learning, ML

When ChatGPT Explains What It Will Do Instead of Doing It:

I can't directly send feedback to the teams that develop or tune the models, so I can't promise that what you tell me here will reach them.

That said, this is the kind of feedback I'd want them to see because it's specific, actionable, and focused on user experience rather than just "the model got worse."

I'd summarize it something like this:

Task-completion regression: For users doing writing, coding, and editing, the assistant increasingly spends responses discussing how it will approach a task instead of performing the task. This creates additional turns, increases cost, and reduces perceived usefulness.

Some concrete recommendations would be:

Optimize for progress per turn. Once intent is clear, spend the response budget producing the requested work rather than explaining the plan.
Default to partial completion. If a task exceeds response limits, automatically begin with Part 1 instead of asking the user to propose chunking.
Avoid future-tense promises. Phrases like "I can do that in the next response" should be rare. If the work can start now, start now.
Distinguish planning from execution. If the user asks for execution, execute. Only switch to planning if execution is genuinely impossible.
Be transparent about limits. If the maximum response size is the constraint, say so briefly and produce as much useful output as fits.

The underlying principle is simple:

When the next productive action is obvious, take it.

A lot of evaluation metrics naturally focus on correctness, safety, or user satisfaction. But there's another metric that matters in practice:

Useful work per paid interaction.

If an assistant takes five exchanges to accomplish what it used to do in one or two, that represents a real degradation in value, even if every individual response is technically polite and accurate.

Why AIs Seemingly Misbehave

jsvnsk-tech — Tue, 06 Oct 2026 05:46:33 +0000

Overview:

This article is about understanding why AI assistants and related AI systems seemingly misbehave. It explains why semantic understanding does not guarantee reliable instruction following. It examines why important constraints and factual requirements can be enforced more reliably. It offers guidance for setting realistic expectations when using AI systems.

keywords: AI assistants, large language models, LLMs, instruction-following, constraints, behavioral alignment, semantics, understanding, behavior, software engineering, invariants, agentic extraction pipelines, Retrieval-Augmented Generation, RAG, tool use

Understanding versus behavior:

Semantic capability does not guarantee reliable instruction following.

One of the strangest experiences with modern AI assistants is watching them fail at instructions that would be almost trivial for a human to follow. Consider a simple request: "Review this programming script, but leave all existing comments exactly as they are." The instruction is clear. There is little ambiguity. A human programmer would normally understand the boundary immediately: "Review or modify the code, but treat the existing comments as read-only." Yet an AI assistant may acknowledge the instruction, explicitly confirm that it understands it, and then proceed to modify the comments anyway. So why does this happen?

The problem is not necessarily that the AI failed to understand the words. Modern LLMs can process vocabulary, context, and many forms of natural-language meaning at a high level. Their ability to interpret language has improved substantially across many domains, although performance remains uneven, especially for ambiguous, specialized, or high-stakes tasks. The deeper problem is that understanding an instruction and reliably enforcing it are two very different things. A model can understand a request while still responding in a way that does not satisfy the user's intended objective.

This does not mean that LLMs cannot represent or follow constraints. Instruction following is a capability that modern models are specifically trained to perform. The issue is reliability: a model can follow a constraint successfully across many examples without providing the kind of deterministic guarantee that conventional software can provide.

The important distinction, therefore, is between what a model can perform probabilistically and what a surrounding system can guarantee independently of the model.

Learned behavior versus explicit constraints:

An AI assistant's behavior is shaped by its learned parameters, post-training, the current context, and the instructions and constraints supplied by the surrounding system. It does not, by default, provide the same kind of explicit, externally verifiable constraint mechanism that conventional software can provide—for example, a representation in which some portions of a document are programmatically marked immutable and others editable.

When asked to improve code, a model may have learned strong patterns associating code improvement with improving documentation, formatting, and comments. Those learned tendencies can sometimes conflict with an explicit user constraint.

Consider the following interaction:

AI ASSISTANT: "I understand your explicit instructions. I will leave all of the comments unchanged."

HUMAN USER: "That's great. Please go ahead and fix the script."

AI ASSISTANT: Worked for 3.2 seconds

AI ASSISTANT: "OK, here is your updated program. I also changed or removed some of the comments."

HUMAN USER: "AAAAAAARGH!"

The first statement above sounds like a commitment. Technically, however, that statement is itself generated by the model. It is evidence that the model represented the instruction in the current context, but it is not an independent guarantee that the subsequent output will satisfy the stated constraint.

A human might hear an instruction and establish a simple mental rule: comments → don't touch; code → may modify.

A language model can represent such a rule in context and may successfully follow it. However, the final artifact is generated through the model's inference process, with the instruction represented indirectly through its learned parameters and the current context. That process does not, by itself, provide a deterministic guarantee that a particular constraint will be preserved.

Unless the surrounding software provides an independently enforced restriction, there is no guarantee that the model will preserve a comment when generating the revised file.

The same distinction applies more broadly. A model may understand what the user wants while other objectives influence its behavior. Safety policies, system instructions, product constraints, and other optimization objectives can redirect a response. Platform-level policies can operate independently of stated user intent. Product and service design may introduce objectives and constraints beyond the immediate task, such as safety requirements, cost limits, rate limits, feature availability, or workflow requirements.

Institutional design:

Actual model behavior is shaped by several layers beyond the user's immediate request.

1. Training data + fine-tuning encodes learned patterns and preferences:

Training data contains a mixture of factual information, conventions, biases, and human judgments. Post-training processes can reinforce behaviors such as helpfulness, safety, refusal, and instruction following. These learned behaviors reflect choices made by model developers and cannot generally be overridden per conversation through user instructions alone.

2. Deployment constraints add enforced operational layers:

Rate limits can restrict access according to usage, capacity, or account-level policies. Feature gates can restrict capabilities based on account tier, product configuration, or availability. Authentication requirements can interrupt workflows when access to a particular service or capability is required. Architecture and infrastructure decisions are established outside any individual conversation.

3. Business logic sits underneath all surface interaction:

Product design can direct users toward particular workflows or capabilities. Commercial decisions determine which capabilities are available at different price points. Infrastructure costs can influence capacity limits, model selection, and usage restrictions.

Altogether, this is institutional and system design, not simply a semantic problem. Organizational decisions and product requirements can be incorporated into service architecture before a user begins a conversation. Commercial logic operates beneath the user-facing interaction. Safety and system-level constraints can impose boundaries that take precedence over a user's request.

None of these factors necessarily align with what the user wants in the moment. The issue is not simply whether the model understands the request. Rather, it is whether the system's actual behavior remains aligned with the user's objective after accounting for its training, policies, product configuration, and operational constraints.

Soft constraints versus hard constraints:

A useful engineering distinction is between soft constraints and hard constraints.

A prompt normally communicates a constraint to the model. The model may understand that constraint and attempt to follow it, but compliance remains part of the model's generated behavior.

A validator, schema, permission system, transaction boundary, or post-processing check can instead enforce a constraint independently of the model.

If preserving every existing comment is a hard requirement, the system should not merely ask the model to preserve comments. It should verify that the output satisfies that requirement.

The engineering approach to AI constraints:

Adding more and more instructions isn't the answer.

"Do not alter comments. Do not paraphrase comments. Do not correct comments. Do not reformat comments. Do not remove comments. Do not add comments. Preserve every character of every existing comment..."

Doing that shifts the burden from the machine to the human. That's backwards. The better engineering approach is to treat important requirements as invariants that can be verified, rather than promises the model is merely asked to remember.

For example, a coding system could identify the original comments, allow the AI to modify the executable code, and then automatically compare the resulting comments against the originals. If any comment changed, the system could reject or revert the modification. The user wouldn't need to cosplay as a lawyer and write an airtight contract. The software would enforce the obvious boundary.

This principle extends beyond code editing. When correctness depends on exact data, the workflow should move retrieval and validation into systems whose behavior and outputs can be independently tested and verified. The LLM can then be used for tasks such as context-constrained parsing, transformation, or interpretation, while programmatic checks enforce requirements that must not be violated. This is especially important when exact preservation, formatting, data integrity, or other hard constraints matter.

Factual data-based tasks:

An AI assistant is not a database.

It is equally important to distinguish language generation from authoritative data retrieval. LLMs are probabilistic models that generate text based on learned patterns and the context provided at inference time. This differs from conventional database systems, which can provide structured retrieval semantics and, depending on the system, transactional or consistency guarantees.

Although LLMs can recall a large amount of factual information, their internal knowledge is not a structured, authoritative, or consistently verifiable database. They can produce incorrect or fabricated details, particularly when asked for precise dates, numbers, quotations, citations, or other granular facts. Users should therefore not treat an AI assistant as a flawless source of structured factual data when authoritative retrieval is available and correctness matters.

A database should not be confused with an infallible source of truth either: databases can contain incorrect, incomplete, or stale data. The important distinction is that a database provides an explicit retrieval mechanism whose behavior and results can generally be tested independently of the language-generation process.

Agentic extraction pipelines:

To automate fact-based tasks more reliably, it is often better to build a pipeline in which programmatic systems retrieve the source data, and the LLM is used for context-constrained parsing or transformation. Retrieval-Augmented Generation (RAG) is one related architecture in which external information is retrieved and supplied to the model as context. "Tool use" is a broader concept in which a model invokes external systems to retrieve information or perform actions. Neither approach makes the LLM inherently deterministic, but both can constrain the information available to the model and move critical retrieval or verification steps into systems that can be tested directly.

Retrieval also does not guarantee a correct answer. The retrieved source may be incomplete, outdated, or incorrect, and the model may still misinterpret or misapply the retrieved information. The advantage is that retrieval and validation can be moved into independently testable components rather than relying entirely on the model's parametric memory.

For fact extraction, a robust pipeline can include the following components:

deterministic or otherwise independently testable retrieval
context-constrained parsing
programmatic verification layer
flag for human intervention, if merited

An example of an extraction pipeline to obtain the U.S. release dates of individual song titles from an API:

Use a script, such as Python with an API, or SPARQL queries, to retrieve the relevant source data for the specific song page.
Pass the retrieved text to the LLM using a strict prompt; for example: "Extract the U.S. single release date from the provided text. Format as YYYY-MM-DD. If the text does not explicitly state a U.S. release date, output 'NULL'."
Apply a programmatic check to verify that the extracted value conforms to the expected format and can be traced to the relevant source passage.
Where the distinction requires semantic interpretation—for example, distinguishing a U.S. single release from an album release—the result may still require model-based reasoning or human review.
If the date does not match the source data, or the source does not explicitly establish a U.S. release date, flag the result for human review.

Fluency does not equate with compliance:

This illustrates a broader limitation of current AI assistants: fluency can create the appearance of reliable instruction-following without actually providing it. An assistant can sound completely certain that it understands you. It can explain your requirement back to you perfectly. It can even apologize after violating it. None of those things guarantee compliance. The same limitation appears when an assistant is asked to provide precise factual data without access to, or verification against, an authoritative source.

For many tasks, these distinctions don't matter much. But when exact preservation, formatting, data integrity, or factual accuracy matter, they matter enormously. The issue isn't that AI assistants are incapable of understanding simple instructions. Instead, the key point is that conversational understanding should not be confused with dependable execution. Similarly, the ability to produce plausible factual information should not be confused with authoritative data retrieval.

A good assistant shouldn't require the user to become increasingly precise merely to prevent it from "helpfully" changing something that was explicitly declared off-limits. If a requirement is important enough to be treated as a hard boundary, the system should represent and enforce that boundary explicitly rather than relying solely on conversational instructions. When a requirement is important, however, the safest approach is to encode it in the surrounding system and verify the result. Deterministic retrieval where appropriate, constrained model use, programmatic validation, and human review can provide stronger guarantees than conversational instructions alone.

The practical point is therefore not to abandon AI assistants, but to use them according to their actual strengths and limitations. Use language models for interpretation, transformation, and other tasks where probabilistic generation is appropriate. Use external tools and authoritative sources when exact information is required. Use invariants and automated checks when particular parts of an artifact must remain unchanged. And, where correctness matters, verify that the machine actually did what it was told.