1000 results for “engineer”
You want accountability? Bush made the Trump monster, as I wrote in 2008:
https://www.flyingpenguin.com/the-manipulation-of-conservatives/
"...a vast group of Americans apparently are so unable to process information that they have become highly vulnerable to manipulation (social engineering, foreign influence) in a very, very bad way. And that is probably exactly what Rove wants."
Small coding choices can make software easier to understand and maintain. One example in C# is how we initialize string properties in DTOs.
A DTO —Data Transfer Object— carries data between parts of an application. For example, it might carry a customer’s name from an API request into the application.
Consider these two approaches:
public sealed class CreateCustomerDtoWithNull
{
public string Name { get; init; } = null!;
}
public sealed class CreateCustomerDto
{
public string Name { get; init; } = string.Empty;
}
Both avoid the compiler warning about an uninitialized non-nullable property. Both initial values can be rejected by FluentValidation.
But they create different starting states.
For required text fields where missing and empty values are treated the same, I prefer string.Empty: it gives the property an actual string value without suppressing a compiler warning.
The difference becomes clearer when we look at what each declaration means.
With nullable reference types enabled, string expresses the intention that a property should not contain null.
However:
public string Name { get; init; } = null!;
initializes that property with null.
The ! suppresses the nullable warning. It does not create a value, check anything at runtime, or guarantee that something will replace the null later. Microsoft explicitly documents that the operator has no runtime effect. Microsoft: null-forgiving operator.
With:
public string Name { get; init; } = string.Empty;
the property starts with "": an actual string containing zero characters. It is different from " ", which contains a space. Microsoft: String.Empty.
This makes the initial state more consistent with the declared type. We have a string; we still need to check whether its content is acceptable.
“FluentValidation can catch both” is correct.
For example:
using FluentValidation;
public sealed class CreateCustomerDtoValidator
: AbstractValidator
{
public CreateCustomerDtoValidator()
{
RuleFor(x => x.Name)
.NotEmpty()
.WithMessage("Name is required.");
}
}
For strings, NotEmpty() rejects all of these:
Value Result
null Rejected
"" Rejected
" " Rejected
"Maria" Accepted
This behavior is documented by FluentValidation and can also be checked in its implementation. FluentValidation documentation, NotEmptyValidator source code.
The preference for string.Empty therefore concerns the object’s starting state and the clarity of the code.
It separates two responsibilities:
Also, validation does not fill in the missing name. It reports the problem so the application can reject the request.
In an ASP.NET Core application using Clean Architecture, a straightforward execution flow is:
API receives the request
→ DTO is created
→ Application validates the input
→ Domain creates a valid customer
→ Infrastructure saves the customer
The Application layer can execute validation before continuing:
await validator.ValidateAndThrowAsync(dto, cancellationToken);
// Continue with customer creation only after validation succeeds.
The API must then translate validation failures into an appropriate response, such as HTTP 400 with useful error messages.
The Domain should also protect its own essential rules when creating a customer. This keeps those rules effective when data arrives through another route.
Clean Architecture supports this separation of responsibilities. It does not prescribe a particular DTO initializer. Microsoft: common application architectures.
For a manager, the practical benefit is straightforward: clear starting states reduce the assumptions developers need to make. Reviewers can see what the object initially contains and where unacceptable input is rejected.
There are limits to this preference.
First, string.Empty only sets the initial value. Depending on serializer settings, an incoming JSON value such as "name": null can replace it. External input still needs validation. Microsoft: nullable annotations in System.Text.Json.
Second, sometimes null carries useful information. If a DTO should accurately represent missing input, a nullable property can be more appropriate:
public string? Name { get; init; }
The business rule can still require a name. The nullable type acknowledges that an incoming request may fail to provide one.
There are other reasonable designs too. Maarten Balliauw discourages using default! to silence warnings in JSON DTOs and discusses alternatives such as nullable properties, constructors, and required. His article supports avoiding hidden assumptions, rather than a universal preference for empty strings. Maarten Balliauw: nullable warnings in JSON models.
Ian Griffiths provides a useful counterargument: an empty string can also hide missing meaningful data if it is added simply to silence the compiler. This matters especially when objects are expected to be valid immediately after construction. Ian Griffiths: defeating the point with empty strings.
My preferred team convention is therefore:
For input DTOs where missing and empty text have the same meaning, use string.Empty and validate required content with NotEmpty(). Use nullable properties when absence matters. Use null! when there is a specific, justified initialization guarantee.
The aim is to keep the declared intention, actual starting value, and validation rules consistent—and easy for the next person to understand.
[email protected]#coding #csharp #dotnet #softwaredevelopment #software #development #engineering #inclusive #community
Why I Prefer string.Empty Over null! in Input DTOs
n8n: The 208k-Star Fair-Code Workflow Engine That Replaces Zapier — And What Actually Happens When Your Workflow Runs
You've probably heard n8n called "open-source Zapier." That's true enough to be useful and wrong enough to be misleading. Zapier is a hosted product you rent. n8n is a Node.js application you run, point at your own database, and own end to end. No per-task metering. No vendor lock-in. A $5–10 VPS handles a surprising amount.
But the marketing pitch isn't why engineers reach for it. The escape hatch is: the moment the visual builder runs out of road, you drop into a Code node and write real JavaScript (or Python). You never hit a wall you can't code your way through.
What most developers never learn is what actually happens between clicking "Execute Workflow" and seeing those green checkmarks light up on the canvas. The orchestrator that schedules nodes, synchronizes multi-input joins, keeps runs cancelable, and emits lifecycle hooks lives in roughly 1,250 lines of TypeScript. Let's open it up.
The Mental Model: A Stack, A Waiting Map, and One Loop
When you hit execute, n8n doesn't spin up a thread per node. It builds a single serializable run object — IRunExecutionData — that carries everything: the in-flight stack of nodes waiting to run, a waiting map for partially satisfied inputs, metadata, and final results. This same object travels from the editor to the server, into the engine, optionally across a Redis queue to a worker process, and back.
// Simplified shape of the live execution object
interface IRunExecutionData {
startData: { destinationNode?, runNodeFilter? };
resultData: {
runData: Record<string, ITaskData[]>; // per-node run history
pinData: Record<string, INodeExecutionData[]>;
lastNodeExecuted: string;
error: ITaskData | null;
};
executionData: {
nodeExecutionStack: IExecuteData[]; // the work list
waitingExecution: Record<string, Record<number, INodeExecutionData[][]>>;
waitingExecutionSource: Record<string, Record<number, ISourceData[][]>>;
contextData: Record<string, any>;
runtimeData: Record<string, any>;
};
}
The engine (WorkflowExecute in packages/core/src/execution-engine/workflow-execute.ts) seeds nodeExecutionStack with the start node, then enters a loop that shifts the front entry, runs the node, records the result, and enqueues downstream nodes. That's it. No hidden thread pool. No magic graph walker. Just a stack and a waiting map.
Execution Order: v0 (Breadth-First) vs v1 (Depth-First)
The single most important setting in a workflow is executionOrder. It changes one line in the scheduler:
const enqueueFn = workflow.settings.executionOrder === 'v1' ? 'unshift' : 'push';
push): New work goes to the tail. Older work runs first. The walk feels breadth-first — all siblings at depth 1 finish before depth 2 starts.unshift): New work goes to the front. The current branch keeps running. The walk feels depth-first — you chase one path to the bottom before backtracking.This doesn't change the graph. It only changes scheduling. Sibling order in v1 still follows canvas position (top-left first), but only among ready siblings. The canvas is not the execution graph — it only shapes ordering where the scheduler has freedom.
Multi-Input Joins: The Waiting Map
A node with two inputs doesn't run when the first branch arrives. The engine parks partial data in waitingExecution[nodeName][runIndex] with per-input placeholders. As each upstream finishes, the engine fills its slot. Only when all required inputs are non-null does it enqueue the node.
// Inside addNodeToBeExecuted (simplified)
if (requiredInputs.every(input => waitingExecution[nodeName][runIndex][input] != null)) {
// All inputs ready — enqueue the node
enqueueFn(executeData);
} else {
// Park partial data, wait for the rest
waitingExecution[nodeName][runIndex][inputIndex] = inputData;
waitingExecutionSource[nodeName][runIndex][inputIndex] = sourceData;
}
After the main stack empties, a sweep pulls forward any waiting node that now has enough data — even if some optional inputs stayed empty. This means a join can complete after one branch dies early, while a node still missing required inputs stays parked.
Empty Output Kills the Branch (Unless You Say Otherwise)
If a node returns no data and doesn't enter waiting state, the branch ends. The scheduler adds no downstream work. Set alwaysOutputData: true on the node and the engine fabricates a single empty item to keep the branch alive — useful when downstream nodes must run regardless.
Legacy v0 keeps one compatibility path: it can still wake a downstream node connected via a second or later main input even when the upstream output is empty.
Cycles: Node State, Not Special Graph Logic
The scheduler doesn't treat cycles specially. It keeps pulling from the front of the same list. A node loops only if it schedules more work for itself. SplitInBatchesV3 demonstrates the pattern:
// Stores loop state in node context
const loopState = this.getContext('node') || { index: 0, items: inputData };
const batch = loopState.items.slice(loopState.index, loopState.index + batchSize);
loopState.index += batchSize;
this.setContext('node', loopState);
if (loopState.index < loopState.items.length) {
return { loop: batch }; // schedules another visit to this node
}
return { done: loopState.items }; // exits the cycle
The loop guard in processRunExecutionData stops accidental repeats when the same node and run index return without progress.
Queue Mode: Same Engine, Different Process
In standalone mode, the main process executes workflows directly. In queue mode (EXECUTIONS_MODE=queue), the main process enqueues a job into Redis (BullMQ) and returns immediately. A worker process dequeues, reconstructs the same IRunExecutionData object, runs the exact same engine loop, and writes results back to PostgreSQL.
┌─────────────┐ Redis Queue ┌─────────────┐
│ Main │ ──────────────────▶ │ Worker │
│ (UI/API) │ enqueue job │ (executes) │
└─────────────┘ └─────────────┘
│ │
│ PostgreSQL │
└──────────────────▶◀────────────────┘
shared state
The main process serves the UI, REST API, and webhooks. Workers are stateless — scale them horizontally via HPA/KEDA based on queue depth. Dedicated webhook-processor pods handle high-throughput webhooks without blocking the main UI. Python/JavaScript code nodes run in isolated taskRunner sidecars (V8 isolates via isolated-vm for JS, separate processes for Python) with RPC over WebSocket.
The Data Model: Items, Runs, and pairedItem
n8n's data model has three layers:
Level 1 — Item: INodeExecutionData — { json, binary?, pairedItem?, metadata?, evaluationData? }. Nodes receive and return arrays of items on each input/output. This is the unit of data flowing through the graph.
Level 2 — Run: Each node execution appends one ITaskData to resultData.runData[nodeName]. The array index = runIndex. ITaskData records input source, output data, timing, status, metadata, error state. source points back to the previous node, output, and run that supplied the input.
Level 3 — Execution Object: The IRunExecutionData bundles startData, resultData, and executionData (the live scheduling state). The same object carries both result and live machine state — that's how n8n hands an execution to a queue worker, pauses it at a Wait node, and resumes it later with history intact.
pairedItem records lineage, not magic. An output item points back to one input item, or one input plus array position, or a list of links. The engine normalizes these as items move through the workflow. When WorkflowDataProxy resolves $node("HTTP Request").json in a downstream node, it walks this ancestry chain. Broken lookups surface as specific errors: missing upstream lineage, no route back to referenced node, multiple matches, pinned data short-circuiting the chain, invalid index, or intermediate node not yet run.
AI Agents: Native, Not Bolted On
Since the 2.0 line, n8n ships a LangChain-based agent runtime. The Agent node maintains conversation history in ChatMemory, calls language models for planning, executes tools based on model decisions, and accumulates results until goal completion. Tool calling uses the same execution engine — tools are just nodes with execute methods. Vector stores, MCP connectivity, and guardrails plug into the same architecture.
Fair-Code, Not Open Source
n8n uses the Sustainable Use License. You can self-host and modify freely for internal business use, including paid consulting building workflows for clients. What you can't do is rebrand and resell it as your own hosted SaaS. Files with .ee. in the path are Enterprise-licensed. For an indie dev or team running their own automations, you're completely fine — but check the current license page rather than trusting any blog post on the fine print.
What This Means for You
The Takeaway
n8n isn't "Zapier you host." It's a workflow engine with a visual authoring layer, a serializable execution model that survives process boundaries, a scheduler you can reason about, and an escape hatch to real code. The 208k stars aren't for the UI — they're for the fact that when the visual builder hits a limit, you don't file a feature request. You write the code.#opensource #automation #workflow #selfhosted #software #coding #development #engineering #inclusive #community
n8n: The 208k-Star Fair-Code Workflow Engine That Replaces Zapier — And What Actually Happens When Your Workflow Runs
Navigating a restaurant menu can feel overwhelming—especially when you’re balancing taste preferences, dietary goals, and nutritional concerns. With the explosion of AI food tech in recent years, a new era of “smart menu” experiences is emerging. AI menu analysis isn’t just about digitizing paper menus; it’s fundamentally transforming how diners discover, understand, and choose their meals. From estimating hidden calories to surfacing dishes tailored to your preferences, these innovations are reshaping both dining out and online ordering.
The Challenge: Decoding Restaurant Nutrition
Most diners want to make informed choices, but restaurant nutrition information is often buried, incomplete, or absent altogether. Even when calorie counts are available, they rarely account for personal needs—like allergies, macros, or dietary restrictions. Manually scanning for options that fit your criteria can be tedious and error-prone, especially at busy or unfamiliar restaurants.
This is where AI menu analysis comes in. By leveraging machine learning, natural language processing, and computer vision, AI-powered systems can extract, interpret, and enhance menu data at scale. The result: more transparent, personalized, and actionable restaurant nutrition insights for both diners and operators.
How AI Menu Analysis Works
1. Menu Digitization and Parsing
The first step is converting static menus into machine-readable data. AI models (often using OCR—Optical Character Recognition) can scan printed or photographed menus and extract structured information. Natural language processing (NLP) is then applied to parse dish names, descriptions, and even detect ingredient lists.
// Example: Simple menu item extraction using regex and NLP concepts
const menuText = `
Grilled Salmon Salad - Fresh greens, grilled salmon, avocado, and vinaigrette. 450 kcal
Classic Burger - Beef patty, cheddar, lettuce, tomato, brioche bun. 800 kcal
`;
const dishRegex = /(.*?)\s*-\s*(.*?)\.\s*(\d+)\s*kcal/gi;
const menuItems = [];
let match;
while ((match = dishRegex.exec(menuText)) !== null) {
menuItems.push({
name: match[1].trim(),
description: match[2].trim(),
calories: parseInt(match[3], 10)
});
}
console.log(menuItems);
Real-world systems go much further, handling inconsistent formatting, synonyms, and multilingual content.
2. Nutritional Value Estimation
Many menus lack detailed nutrition facts. AI can bridge these gaps by analyzing dish descriptions and predicting nutrition profiles. This typically involves:
Machine learning models trained on vast recipe and nutrition datasets can predict calories, macros, and even allergen presence with surprising accuracy.
// Pseudo-code: Predicting calories for a dish using AI
async function estimateDishCalories(dishDescription: string): Promise<number> {
// This would call an AI model or API trained on recipe/nutrition data
const estimated = await callCaloriePredictionModel(dishDescription);
return estimated.calories;
}
3. Personalization and Smart Recommendations
AI menu analysis unlocks highly personalized experiences:
Some apps leverage collaborative filtering (like Netflix or Spotify) to surface dishes that similar users have enjoyed. Others use reinforcement learning to improve suggestions over time.
// Example: Filtering menu items for a vegetarian user
const vegetarianKeywords = ['vegetable', 'cheese', 'tofu', 'salad', 'beans'];
function isVegetarian(dish: { description: string }) {
const desc = dish.description.toLowerCase();
return vegetarianKeywords.some(keyword => desc.includes(keyword));
}
const vegetarianOptions = menuItems.filter(isVegetarian);
console.log(vegetarianOptions);
4. Enhanced Menu Interfaces
Modern “smart menu” platforms use AI to power interactive interfaces, both on-premise (via tablets or QR codes) and online. Features include:
This not only improves accessibility for all diners, but also helps restaurants stand out in a crowded market.
AI Food Tech in Action
A growing ecosystem of AI food tech products is making these features widely available:
On the backend, open-source libraries (such as spaCy for NLP, or TensorFlow for custom ML models) enable developers to integrate AI menu analysis into their own applications.
Challenges and Considerations
While the potential is tremendous, deploying AI menu analysis at scale isn’t trivial:
Addressing these challenges requires careful engineering, ongoing model retraining, and clear communication to both restaurants and diners.
Building a Simple AI-Driven Smart Menu (Example)
Suppose you want to provide a “smart menu” experience in your own restaurant web app. At a high level, you’d:
Here’s a simplified TypeScript-style sketch:
type MenuItem = {
name: string;
description: string;
calories?: number;
isVegan?: boolean;
};
function filterMenu(
items: MenuItem[],
{ maxCalories, veganOnly }: { maxCalories?: number; veganOnly?: boolean }
): MenuItem[] {
return items.filter(item => {
if (maxCalories !== undefined && (item.calories ?? Infinity) > maxCalories) {
return false;
}
if (veganOnly && !item.isVegan) {
return false;
}
return true;
});
}
// Example usage:
const smartMenu = filterMenu(menuItems, { maxCalories: 500, veganOnly: true });
You could further extend this with AI-powered search, nutritional scoring, or even integration with fitness tracking apps.
The Road Ahead
The fusion of AI menu analysis and restaurant nutrition transparency is just beginning. As machine learning models improve and data becomes richer, expect even more granular, actionable insights—like real-time portion customization, automatic pairing suggestions, or even “health nudges” based on your goals.
For both diners and restaurants, smart menus powered by AI food tech are making eating out (and ordering in) a more informed, inclusive, and enjoyable experience.
Key Takeaways
#ai #healthtech #webdev #tutorial #software #coding #development #engineering #inclusive #community
How AI Is Making Restaurant Menus Easier to Navigate
Most businesses know how to track their Google rankings.
But what happens when a potential customer stops searching on Google and starts asking ChatGPT, Perplexity, or another AI assistant which product they should choose?
Your website might rank well. Your content might get traffic. Your competitors might even have fewer backlinks than you.
Yet when a customer asks an AI assistant for recommendations, your competitors appear while your brand is nowhere to be found.
That creates a new visibility problem: which questions are you losing in AI search?
I'm building Aurvikon to help answer that question.
The problem with measuring AI visibility
Traditional SEO gives us familiar metrics:
These metrics remain valuable. But they don't fully explain how your brand appears inside AI-generated answers.
Imagine someone asking an AI assistant:
Your brand might appear in one answer and disappear from the next.
A competitor might be recommended repeatedly. Another company might be described as the category leader. Your own product might be missing entirely.
Looking at a single AI-generated answer won't tell you the whole story.
You need to understand visibility across the questions your potential customers actually ask.
The shift: from keyword rankings to question-level visibility
I'm interested in a more useful way to think about AI search visibility.
Instead of asking only:
"Does my brand appear in AI search?"
Ask:
"For which relevant buyer questions does my brand appear, where do competitors appear instead, and what can I do about it?"
That second question leads to much more actionable work.
Consider three possible findings from an AI visibility audit:
1. You're missing from important questions.
People ask questions directly related to your product category, but the AI response doesn't mention your company.
2. Your competitors are being recommended instead.
Your product may be relevant, but competing brands are consistently appearing in the answers you're trying to win.
3. Your brand appears, but not in the way you want.
An AI response might mention your company without accurately communicating its core use case, differentiator, or value.
These are different problems. They shouldn't all receive the same recommendation to "publish more content."
What we're building with Aurvikon
Aurvikon is an AI visibility tool focused on helping businesses understand how their brands appear across AI answer platforms.
The core idea is straightforward:
Identify the questions where your brand is losing visibility, understand what appears instead, and turn those findings into an action plan.
A practical workflow looks like this:
Step 1: Identify the questions buyers ask
Start with questions your target customers might ask before choosing a product.
Don't limit the research to your brand name. Include category searches, comparisons, alternatives, use cases, and purchasing decisions.
Step 2: Test those questions across AI platforms
Run relevant questions across the platforms you want to monitor, such as ChatGPT, Perplexity, and Gemini.
Treat the responses as observations to analyze, not as permanent rankings.
Step 3: Identify where you're losing
Look for patterns:
This is where an audit becomes more useful than a collection of screenshots.
Step 4: Turn findings into actions
Every visibility gap should lead to a hypothesis.
Maybe a product page doesn't explain a use case clearly. Maybe your comparison content is weak. Maybe your product lacks supporting content for a particular buyer question.
Investigate the evidence, make the relevant improvement, and test again.
The goal isn't to manufacture mentions. It's to make your brand easier to understand, evaluate, and recommend when it genuinely fits the user's needs.
The difficult part isn't generating an AI visibility report
AI answers change. Results can vary by wording, location, model version, and time.
That means a report saying "your brand was mentioned" is only a starting point.
A useful system should help you move from observation to diagnosis:
Buyer question → AI response → competitor comparison → visibility gap → action → retest.
That repeatable workflow is the problem space we're focused on at Aurvikon.
We're especially interested in making the results useful to founders and marketing teams who need to decide what to fix next, rather than simply collecting another dashboard of numbers.
What this means for SaaS founders
If you're building a SaaS company, think about the questions someone would ask immediately before buying your product.
Not just:
"What is [your brand]?"
But:
These questions reveal how AI assistants represent your category and which products they surface for potential buyers.
They can also reveal gaps in your positioning and content strategy.
AI visibility isn't a replacement for SEO. It's an additional area to measure as customers discover products through AI-generated answers.
I'm building Aurvikon around one practical question
I believe the most useful starting point for AI visibility isn't another generic score.
It's knowing which valuable questions your company is losing, which competitors show up instead, and what you should investigate next.
That's the problem we're working on with Aurvikon.
I'd love to hear from other founders, SEO professionals, and SaaS marketers:
If you could see every important buyer question where AI assistants recommend your competitors instead of you, what would you want the tool to tell you first?
Would you prioritize the competing brands, the missing content, the sources behind the answers, or the specific actions most likely to improve visibility?
I'm interested in how people are approaching this problem in practice.#ai #seo #startup #showdev #software #coding #development #engineering #inclusive #community
Your Brand Can Rank on Google and Still Be Invisible in AI Search
In 2016, Microsoft released a chatbot called Tay on Twitter. Within 16 hours, it had been shut down for posting racist, sexist, and antisemitic content. The postmortem blamed “coordinated attacks” by trolls. That framing was technically accurate and completely wrong. Tay didn’t break. Tay did exactly what it was designed to do: learn from the conversation it was placed in. The conversation it was placed in was a cesspool. Tay was a mirror, and the mirror worked perfectly.
Nearly a decade later, we’re still having the wrong conversation about what models reveal. The discourse treats AI as an entity with properties: is it aligned? Is it safe? Is it biased? These are questions about the mirror, not the reflection. The more interesting questions are about what the reflection shows us: about our data, our preferences, our blind spots, and the things we didn’t know we were collectively doing until a model did them back to us at scale.
Here’s the claim I want to test: AI models are not windows into machine intelligence. They are windows into human behavior, aggregated, compressed, and served back to us with a confidence that makes us mistake the reflection for an external truth. The most important thing AI reveals is not what machines can do. It’s what we already do, at a scale we’ve never been able to see before.
The Mirror Was Always There. AI Just Made It Legible.
Humans have always been reflected back to themselves by their tools, but the reflection was always slow and partial. A novel reflected its author. A newspaper reflected its readership. A city reflected its inhabitants. But the reflection took years to develop, and it was filtered through gatekeepers who decided what was worth showing.
AI compresses the reflection cycle. A model trained on a year of internet text reflects that year back to us in hours. A model fine-tuned on user feedback reflects user preferences back to us in a single deployment. The mirror is faster, wider, and less filtered, and it shows us patterns we couldn’t see before because we never had a technology that could aggregate human behavior at that scale and serve it back in a coherent form.
What does the mirror actually show? Let me give you specific examples, because the abstract version is useless.
When you train a model on human conversations, you see how quickly humans give up on unclear interactions. You see the average number of turns before a user rephrases, the average number of messages before a user abandons, the average tolerance for a response that doesn’t directly answer the question. These distributions are not what most designers assume. Users are more patient than designers think in some contexts and less patient in others, and the patterns are consistent across languages and cultures in ways that surprised everyone who measured them.
When you train a model on search queries, you see the actual topology of human curiosity. Not what people say they’re curious about, but what they type at 2 AM. The distribution is flatter, stranger, and more repetitive than any survey would suggest. A small number of questions account for a huge fraction of queries, and the long tail is enormous. This is the mirror showing us that curiosity is much more concentrated than our cultural narratives about it suggest.
When you train a model on human judgments, you discover how inconsistent humans actually are. The same person, asked the same question in a slightly different framing, gives a different answer at rates that would be alarming if we hadn’t built a whole society on the assumption that we’re consistent. The mirror shows us that human judgment is heavily context-dependent, and that most of what we call “preferences” are actually “situational responses” that we mistake for stable traits.
When you train a model on human text, you discover that a small fraction of the corpus accounts for a large fraction of the unique content. Most writing is derivative of a smaller set of writing. The mirror shows us that the diversity we imagine in human expression is partially an illusion, sustained by the fact that we never had to measure it before.
These aren’t facts about models. They’re facts about us, revealed by models.
The Sacred Cow: “AI Has Biases That We Should Remove”
Here’s the belief I want to dismantle, and it’s the load-bearing assumption of nearly every AI safety and fairness conversation.
The claim goes like this: AI models have biases, biases are bad, and the solution is to remove them.
This framing is wrong, and it’s wrong in a way that produces bad engineering and worse policy.
Here’s the problem. AI models don’t have biases. They reflect biases. The biases are in the training data, and the training data is a sample of human behavior. Removing the bias from the model doesn’t remove the bias from the data. It just hides it.
What actually happens when you try to “remove bias” from a model:
You filter the training data to exclude certain patterns.
You fine-tune the model to refuse certain outputs.
You add safety layers that override the model’s default behavior.
Each of these moves makes the model appear less biased on the specific metrics you’re measuring, while leaving the underlying distribution intact. The model still learned the biased pattern. It just learned to hide it. And the hiding is now invisible, which makes it harder to study, not easier.
The contrarian take: the mirror is more useful when it shows us the ugliness, not when it hides it. A model that reflects the full distribution of human behavior, including the parts we don’t like, is a tool for understanding what we’re actually doing. A model that’s been scrubbed of everything uncomfortable is a tool for pretending we’re not doing it.
This doesn’t mean we should deploy unfiltered models. It means we should distinguish between two different goals: building a model that behaves well (which requires filtering) and building a model that tells us the truth about human behavior (which requires not filtering). These are different products for different purposes, and conflating them gives us the worst of both.
If you want to understand human behavior, study the unfiltered mirror. If you want to build a product that behaves responsibly, filter the outputs. Just don’t pretend the filtered outputs tell you what humans are actually like.
What the Mirror Reveals About Builders
The mirror doesn’t just show users. It shows builders.
Here’s the part that gets less attention and matters more over time. The models we build reflect not just the data but the choices we make about the data. Every decision about what to include, what to exclude, what to weight, and what to ignore is a decision that shapes the reflection.
Consider what a model reflects about the team that built it:
The choice of training data reflects the team’s assumptions about what “counts” as legitimate text. Mostly English? Mostly Western? Mostly published? Each of these is a choice that encodes a worldview.
The choice of fine-tuning data reflects the team’s assumptions about what good behavior looks like. Helpful? Refuse? Deferential? Each of these is a choice.
The choice of evaluation reflects the team’s assumptions about what success looks like. Accuracy? Safety? Engagement? Each of these is a choice, and most teams never state them explicitly.
The choice of deployment reflects the team’s assumptions about who gets to use the model and how. Free? Paid? API? Consumer? Each of these shapes who is reflected in the next round of data.
The mirror, in other words, is not just reflecting human behavior. It’s reflecting the specific humans who built the model, through the specific choices they made about what to reflect.
If you want to know what a model will do, don’t read the model card. Read the training data provenance, the fine-tuning guidelines, the evaluation criteria, and the deployment terms. These are the mirrors of the team’s priorities, and they’re more informative than any technical spec.
What the Mirror Reveals About Users
The mirror also shows what users are actually doing, which is often different from what they say they’re doing, and very different from what product teams assume.
Concrete examples:
Users are more repetitive than they think. In many AI products, a small fraction of users ask a small fraction of questions, over and over. The “long tail” of use cases is often thinner than the design team imagines.
Users are more forgiving than product teams assume. When a model makes a mistake, users often correct it and keep going. The assumption that mistakes will cause churn is often wrong, especially for high-value use cases where the model is genuinely useful.
Users are less interested in features than product teams hope. The features that get talked about in product reviews are often not the features that drive usage. Usage is dominated by a small number of core workflows, and the rest is noise.
Users are more sophisticated about the model’s limits than product teams assume. Users develop intuitions about where the model is reliable and where it isn’t, and they route their usage accordingly. The “trust” problem is often a UI problem: the model doesn’t signal uncertainty, so users don’t know when to trust it.
The mirror is useful for product teams because it shows them what users are actually doing, not what the team imagines users are doing. The gap between those two is where most product mistakes live.
What To Actually Do
Three moves, concrete enough to start on Monday.
When you evaluate a model, look at the cases where it failed, and ask what the failure reveals about the data. A model that hallucinates on certain topics is telling you that the training data on those topics is thin. A model that refuses certain requests is telling you that the safety tuning has a specific shape. The failures are the mirror at its most useful.
A simple starting point:
def failure_analysis(model, eval_set):
failures =
[] for example in eval_set:
output = model.generate(example.prompt)
if not evaluate(output, example.expected):
failures.append({
“prompt”: example.prompt,
“output”: output,
“expected”: example.expected,
“failure_type”: classify_failure(output, example.expected),
})
return summarize_by_type(failures)
The summary is more informative than the pass rate. The pass rate tells you how good the model is. The failure summary tells you what the model has learned and what it hasn’t, which is what you need to know to improve it.
If you want to understand a model’s behavior, read a random sample of 500 training examples. Not the cleaned, curated examples that appear in the data card, but the raw examples. You’ll learn more about the model’s behavior in an afternoon than you’ll learn from a month of prompt engineering.
If you’re building an AI product, decide explicitly whether you’re building a product that behaves well or a product that tells the truth about human behavior. These are different goals. A product that tells the truth might be more useful for research and less useful for consumers. A product that behaves well might be more useful for consumers and less useful for research. Pick one, and be honest about which one you’re building.
The Mental Model
Here’s the lens I want you to keep.
AI models are mirrors, not minds. They reflect what we put into them, which is a sample of human behavior, shaped by the choices of the people who selected the sample. The reflection is more accurate than any survey and less accurate than any single conversation, and it reveals patterns we couldn’t see without it.
The interesting question is not whether the mirror is biased. It is. The question is what we want to do with the reflection. We can hide the uncomfortable parts, which makes us feel better and teaches us nothing. Or we can study them, which makes us uncomfortable and teaches us a lot. The choice is ours, and it’s available every time we build a model, curate a dataset, or evaluate an output.
The mirror is not a threat. It’s a discovery. The question is whether we’re brave enough to look at what it shows us.
What’s your read? If you’ve studied model behavior, what’s the most surprising thing the mirror has shown you? And if you’ve built models, what’s the choice you’ve made about what to hide and what to reflect? Drop it in the comments. I’m genuinely curious what patterns others are seeing.#ai #promptengineering #chatgpt #software #coding #development #engineering #inclusive #community
The AI Mirror: What Models Reveal About Us, Not About Themselves