The ELIZA Effect in 2026

Your guide on this website is Eliza. I gave it the same name as the 1966 original, inspired by all the anonymous women who helped build tech. The 1966 original needed to know nothing of the real world to be believed; mine has to know everything it says. It answers questions about my work, and it cannot invent one, because nothing is generated while you talk to it. It can still be wrong, if I wrote something wrong, and there is a check in the build for exactly that. This is what it is, where it comes from, and what it cannot do.

A woman in the office of an MIT professor asked him to leave the room so she could tell a chatbot in private that she was sad.

The first Eliza, from 1966

The year was 1966, the program was called ELIZA, and Joseph Weizenbaum had written it to demonstrate that a machine could hold a conversation without understanding a word of it. She worked in the building and knew exactly what the program was, and she still wanted the room to herself.

If I had worked in IT back then, I too would have been a secretary and not a conversation designer, not a technical writer. I would probably also have been a person typing that she is depressed much of the time, which is a line from the published transcript of the original ELIZA. It is something I understand and even relate to.

Secretary in one account, a young lady in another. She was never named, and she may be several women compressed into one. The first person on record to feel understood by a machine is the least documented person in the story. He never gave her a name.

That is the whole of the ELIZA effect, and it has not aged a day. Humans give machines the aura of humanity. The program found a keyword in your sentence and handed it back as a question, and when it found nothing to work with it reached for something warm and empty. Tell me more. People felt understood, and what they were hearing was a piece of themselves, returned.

That is why naming it was a decision that carries a lot of weight. For me, ELIZA is for all the women who tested technology, improved it, and remained anonymous to history. The 1966 ELIZA matched patterns against a written script; so does mine. That program was named after Eliza Doolittle, a fictional woman taught to speak by the man studying her. And I am called Eliza, which is the only part I did not arrange.

So it shares its architecture with the original and its name with the person it talks about. It speaks about me in the third person, and when a question turns personal it hands you my address instead of answering. I could have built the version that speaks as me. That one performs intimacy on my behalf, with my name on it, in the register Weizenbaum spent forty years warning about. A bot speaking as me would invite you to feel you had met me.

His machinery was a keyword ranking, a set of rules for taking a sentence apart, and a set for putting one back together. Three of the things it did survived into mine, each with a limit his never needed. It hands your own word back when it misses, once, capped at six words, and never an insult or a protected subject. It remembers one thing, which part of my work you were reading, and offers the way back if it misses twice. And it never uses the same wording twice in a row, so two misses do not read like a machine stuck in a groove.

He also wrote down why it played a therapist. The psychiatric interview, he explained in the same paper, is one of the few conversations in which one side is "free to assume the pose of knowing almost nothing of the real world" and still be believed. The patient supplies the world, and the pose does the rest. That is the one part I reversed. Mine gets no pose. It is given one small world, my work, and it speaks only from inside it.

Luckily, it is 2026. Thanks to the women in Women in Technical Communication: From typewriters to touchscreens, a history by the women who did the work, collected by Sharon Burton, I get to stand on their shoulders and write the voice of my own chatbot.

It knows nothing it was not told

That is the job I gave the thing in the corner of this site. People arrive here with one question about whether I can do a job. I want them to get an accurate answer before they run out of patience. Quickly is the easy half. Accurately is the half that decided how it had to be built.

Every answer is written before anyone asks it. Each one is attached to the questions that should reach it, and the engine does one job: it picks the right answer and says it back.

I wrote the answers as a voice script first. SSML is the markup that tells a voice assistant where to pause and which word to stress, and I drafted the conversations in it before any of this existed as a web page. That draft is the copy that shipped as text, and every reply still has a read aloud button.

There is a reason that order produces better writing, and it is not discipline. Clark and Brennan catalogued what each medium makes cheap and what it makes expensive. Speech has no reviewability and no revisability: the listener cannot go back over a clause, and the speaker cannot edit before sending. Writing for the ear therefore forces sentences that survive one pass. Text inherits that and loses nothing.

One decision follows from all of it: the bot cannot drift from the facts. No model runs at the moment you ask, so nothing is present that could improvise them.

What I give up is coverage. It answers what I have written and nothing else. So the work is not prompting a model. The work is reading the log, seeing what people actually asked, and writing the answers that were missing. When it does miss, it says so and hands over my email address. That is a safety net, and a safety net is not the same as having the answer.

Act, confirm, hand off

Type anything into it and your sentence goes through the same three steps. I designed them first for an AI documentation agent that works asynchronously: it posts its plan on the pull request and waits for the developer's approval. That is the only way it works. I was curious whether the same steps would hold at this much smaller scale. They do.

Act. The match is clear, so it answers, with a link to the page the answer came from. Confirm. Two answers are close, so it asks which one you meant and offers both. Hand off. Nothing matches, so it says so and gives you my email address.

The middle step has a name I did not invent, and it is a lovely one. Conversation analysis calls it a candidate understanding: the system proposes what it thinks you meant and lets you confirm or correct it, so you never have to type the whole thing again. The hand-off is a graded ladder from the same literature. Its three rungs are an open-class signal that something is wrong, then a narrowing that shows where, then a person. Each rung locates the trouble more precisely than the last, and my fourth line is simply the shortest way to say the email address.

Every one of those refusals carries a reason, an alternative, and a way to reach a human. That is not politeness for its own sake. A refusal with no hedge and no account reads as hostile, because it breaks a norm speakers follow without being able to name it, and conversation analysis has the receipts on that going back to the 1970s.

Underneath, it scores your words against the 103 topics it knows. This is keyword and phrase matching with weights and thresholds, not a trained model, and I would rather say so than let the word AI do work it has not earned here. Some topics are protected, and a protected topic wins any tie, so the answer becomes an offer to write to me directly. Your half-formed question should never be dragged into a subject that deserves a conversation with a person.

The thresholds live in the code, and the standard lives next to it, in a rubric anyone can read:

# what "good" means, in one reviewable place
readability:
  median_grade_max: 8     # reading age of twelve
  reply_grade_max: 12
  sentence_words_max: 20
conversation:
  options_max: 5          # a cap I chose, not a finding I am citing
  first_reply_ms: 380    # the human gap between turns is ~200ms
  repair_steps: 4        # open class, localise, candidate, then a person

The two hundred milliseconds you never notice

Here is a number I think about more than is reasonable. Turn transitions in human conversation cluster around 200 milliseconds, across languages and in sign language too, while retrieving a word takes the brain roughly 600. The arithmetic only works because people predict the end of your turn and prepare their own in parallel. Conversation analysis puts the standard maximum silence at about one second, the point where a pause stops being neutral and starts being interpreted. My own ceiling sits a little above it, at 1.4 seconds. That number is a choice I made, and no research is being asked to defend it.

So the pacing is specified, and the specification is boring on purpose. The first line lands at 380 milliseconds, measured at 423 in the browser once rendering is counted. Each following line waits as long as typing it would plausibly take: 22ms per character, floored at 520ms, capped at 1400ms, with typing dots visible throughout. Bubbles arrive one at a time, 850ms apart, because a whole answer landing at once gives nobody a moment to take the first sentence in. Reduced motion removes every delay in that list.

Writing for somebody who will not read it twice

You will not reread a chat reply. Nobody does. So the style contract is enforced by tests, and a reply that breaks it fails the build and never ships. No em dashes, no exclamation marks past the greeting, no chatbot cliches, and visitors are never gendered. Readability is measured on every reply: the median sits at grade 5.2, sentences stay under twenty words, and every turn ends by handing the floor back.

The thresholds come from the Content Design Hub accessible-content guide, and they are written for an international reader whose English is often a second language. Visitors arrive from everywhere, some of them type in Romanian, and the test suite covers Romanian utterances for exactly that reason. Words came down to meet the numbers: "pharmacovigilance" became "drug safety", "complex" became "hard", "implementable spec" became "spec you can build from".

What the thresholds buy is easier to see in the turns themselves than in the rules. A direct question gets a direct answer, opened the way a person opens one:

The plain words have to hold in the awkward turns too. That is where most bots reach for corporate register:

The next message the visitor types is captured and drafted into an email to me, so an insult becomes a product signal. Two smaller rules run underneath everything: the verbs work on any device, and every link says where it goes, because a screen reader reads links out on their own.

What it got wrong in week one

It keeps a log of what people type, anonymously: the text, the answer it reached, and whether it reached one at all. No name, no address, no cookie. Announcing something like this without saying what it got wrong would be the wrong way round, so here is week one.

Its first two misses were the question of who it is, which is the sort of thing you only find out in public. The first line in the log is "cine ești?", the second is "who are you?", and it had nothing for either. Its own identity, in both of the languages its visitors write in, on the first impression.

The confusion underneath that question is legitimate, and it deserves a plain answer. A bot that wears my name, on my site, invites the reading that you are talking to me, or to something built to impersonate me. That reading is what the whole design refuses, and it is half the reason this article exists: to keep the name, the function, and the person separate. The name honours a lineage. The function is answering questions about my work. The person is elsewhere, which is why it only ever speaks about me in the third person.

The miss that taught the most came four minutes after that one. The log reads ai, then artificial, then intelligence, then artificial intelligence, inside the same minute, each one politely handed my email address, for a question it could already answer. The repair worked exactly as designed and still failed the person typing. Coverage is the product; repair is the apology.

Two fixes came out of it. Twenty phrasings now reach one answer, held there by a test. And the input suggests real questions after two characters, drawn only from questions it can answer, so a test can hold every suggestion to a real reply.

Every miss became a permanent test. The list below is also short because it covers the opening days of a log that is still mostly me.

/* Every recorded miss becomes a permanent regression test. */
const LIVE_MISSES = [
  ['who are you?', 'botmeta'],
  ['what else?',   'whatelse'],
  ['artificial intelligence', 'cd'],
  ['expericente',  'cvpage']   // typos score as the word itself
];

Why not a FAQ, and why not a model

The first objection is the cheap one, and it deserves an answer: this is a FAQ with extra steps. It is also the difference I draw between classical documentation and behavioural documentation, so it is worth the paragraph.

A FAQ documents a system and whether what it says about that system is correct. It is organised by what the content is, and it asks you to find your own place in it. Technical writing, by extension, has the same contract. Conversation design starts somewhere else: a person moving through a decision in real time, who needs one step, now, at the point where they are stuck.

That contract needs machinery a list of questions does not have. Intent is the clearest case. A FAQ has no way of knowing that "why is this timeout set to 30 seconds" is somebody who is about to change it, or that "ux" is two crafts and needs asking which one you mean. It cannot notice that it has missed you twice and offer you the way back to what you were reading. A FAQ answers the question that was written down. A conversation has to work out which question you are asking, and what to do when it cannot.

Every fact it states is compared against the ten live pages of this site before a deploy goes out, and a fact that exists nowhere on the site fails the build. That check is only possible because the answers are fixed text.

I love what Fabrizio Ferri Benedetti built, and I wanted to design one end to end myself. Ask Fabrice retrieves passages from his own pages and lets a language model write the reply. I took three of his ideas outright, including the check that compares my machine-readable index against what the guide can actually answer.

Mine answers only from what it was given. The first line lands in under half a second, there is no key to leak, and the cost is coverage, which the live log repairs week by week.

How it was made, in six artifacts

The part I always want from other people's write-ups is the chain from the messy sketch to the shipped thing, and it is the part most of them leave out. So here is mine. Six artifacts, all still in the repository, none of them tidied up for the photograph.

One file. ask.js holds the engine, the answers and the interface: One hundred and three topics, matched by keyword and phrase, with protected subjects that win any tie. No build step, no dependency, no server. You can read the whole thing in an afternoon, which is the point: a system nobody can read is a system nobody can check.

A standard in its own file. rubric.yml, shown earlier, so the thresholds can be argued with by somebody who never opens the tests.

A table of labelled questions. This is the part I would show first to anyone who works on conversational systems. Two hundred and fifty-eight utterances, each one written next to the answer it must reach, and twelve pairs that must land in the same place despite looking nothing alike.

// every utterance, next to the answer it has to reach
['hey there',        'hello'],
['cine e eliza',     'summary'],
['recomandations',   'recs'],      // misspelled on purpose
['youre stupid',     'criticism'],

// pairs that must land together, however differently they are put
['salary?',          'compensation'],
['are you an ai',    'are you chatgpt'],
['how do i reach her', 'get in touch']

A log of what strangers typed. Anonymous, and it is the only artifact here I did not write. It is also the only one that has ever surprised me.

A test suite that runs before every deploy. Built mostly out of the log: each miss becomes a test, so the same failure cannot come back quietly.

The thing itself, in the corner of this page, which you can check against everything above.

None of this required a model, a budget, or permission. It required deciding what counts as correct, writing it down where someone else can disagree with it, and then reading what people actually typed.

What the misses paid for

The documentation framework I work from puts failure handling inline, right under the step that can fail, and ends every page with one named next action. A conversation earns its keep the same way, so every miss in the log came back as something it now does. The four misses on ai bought the shared vocabulary and the suggestions. "Who are you?" bought it its own name, in two languages. A visitor typing oracll bought a boundary case on the typo threshold that I would never have invented at a desk.

What I cannot tell you is whether it is useful. Two weeks and 443 turns, a good share of them mine, do not support that claim, and the instrument that would close the gap is five think-aloud sessions with people who are not me. That is the next thing I owe this, and it is the subject of the next piece.

What is left, once nothing is generated, is the craft. Turn transitions measured in milliseconds. Coverage as a property somebody maintains. The discipline of writing every line you ship, then testing that it still says what your pages say. That is the part of this work that survives whichever model arrives next, and it is the part I would want to be judged on.

Weizenbaum never gave the woman in his office a name. Sixty years on, the person who proved the whole thing worked is still the least documented one in the story. I gave this one my own name, and then wrote down every sentence it is allowed to say, so that anyone talking to it knows exactly whose words are coming back.

If my job is to get what I know to people, whatever the channel or the tool, then I had to send a pigeon out over the sea of the internet. This one sits in the corner of every page on this site, pearl coloured, and it goes solid lilac a quarter of a second before it speaks. Ask it something.

Most of what holds this up is other people's work. Sacks, Schegloff and Jefferson described how turns and repairs are organised. Clark and Brennan explained what each medium makes cheap and what it makes expensive. Grice set out what makes a contribution cooperative. Weizenbaum documented the machinery of the first ELIZA himself, in 1966. Each one is annotated, with what I took from it, in resources.