op-ed · introducing

The ELIZA Effect in 2026

Your guide on this website is Eliza. Inspired by the 1966 original, I gave her my name. She answers questions about my work, and she cannot hallucinate, because nothing is generated while you talk to her. This is what she is, where she comes from, and what she cannot do.

the state light · drag to spin · pearl means thinking, lila means answering

Docs of docs

I was talking to Tudor Juravlea the other day about the fact that nobody reads anymore. Best case scenario, we have a skill that summarizes things for us. And why don't I design my own chat?

A site filled with words explaining how I write words involves, inevitably, more words. Sure, there are incredible people out there who still skim, and I am grateful for them. For most, reading is costly.

This site is ten pages and a few thousand words of case files. Somebody assessing me for a role needs their questions answered stat.

The first Eliza, from 1966

When Joseph Weizenbaum built that program to demonstrate that machines cannot understand us, a woman in his office asked him to leave the room so she could tell it in private that she was sad.

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 most 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. Researchers went through the MIT archives looking for her and found nobody; 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. And no, it is not just after myself. That would be narcissistic. 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.

Three of the things Weizenbaum's program did survived into mine. Each one needed a limit his never did.

Reflection. ELIZA repeated pieces of your own sentence back at you, and that alone made people feel heard. This bot does it once, and only when it has missed. Ask it about kubernetes and it answers that kubernetes is not in its files.

Repeating a stranger's words has an obvious way of going wrong, so it has limits. It never repeats an insult back at the person who typed it. It never repeats a protected subject. And it repeats six words at most, so it cannot parrot a whole paragraph back at you.

Memory. ELIZA held on to what you said earlier and returned to it. This bot holds on to one thing: which part of my work you were reading about when you arrived. If it misses twice, it offers to take you back there. Somebody who is lost usually wants the thread they already had.

Cycled reassembly. ELIZA never used the same wording twice in a row. Neither does this one. Every apology, and every request to narrow a question, is worded differently from the last, so two misses in a row do not read like a machine stuck in a groove.

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.

What she is

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. Writing for the ear keeps the sentences short, because a listener cannot re-read a clause. That draft is the copy that shipped as text, and every reply still has a read aloud button.

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. She 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

Every message you type goes through the same three steps. I designed them first for an AI documentation agent, and they hold here too.

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.

Underneath, it scores your words against the 83 topics it knows. Some of those topics are protected, and a protected topic wins any tie, so the answer becomes an offer to write to me directly. That rule exists because a half-formed question should never be dragged into a subject that deserves a real conversation with a person.

message matcherscore + margin actanswer, source link, next cards confirmone question, two candidates hand offrepair ×4, then write@elizamarin.com
fig. 1 · routing. select the figure to enlarge.

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

rubric.yml
# 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          # Miller
  first_reply_ms: 380    # human turn gap is ~200ms; past 1500ms is dead air
  repair_steps: 4

Pacing is a number

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. Past about 1.5 seconds, a reply starts reading as dead air.

So the pacing is specified, and the specification is boring on purpose. The first line lands at 380ms, measured at 423ms in the browser including render. 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.

The orb above is the same idea made visible. It pulses pearl while a reply is being prepared, and about 260ms before the line lands it goes solid lila. The pair is decorative and hidden from screen readers, which get the reply itself through a polite live region.

How she sounds

The style contract is enforced by tests, so 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:

you · does she work with AI?
eliza · Of course. Right now she works on the conversation experience of Askmanu.

Ask for a length and you get that length, because 27 summaries are authored in advance at five, ten, and twenty-five words:

you · summarize the technical writing page in five words
eliza · Senior technical writer at Oracle.

And the plain words have to hold in the awkward turns too, which is where most bots reach for corporate register:

you · this sucks, not what I asked
eliza · That is fair, and I would rather fix it than defend myself. What were you looking for? I will send it to Eliza exactly as you write it.

The next message the visitor types is captured and drafted into an email to me. An insult becomes a product signal, which is the same move I make with failures everywhere else. Two smaller rules run underneath all of it. The verbs work on any device, so the bot says pick and select, and never click or tap. And every link says where it goes, because a screen reader reads links out on their own, away from the sentence around them.

The bot never calls itself scripted. Every answer is designed, not generated, and its boundaries are named as design decisions, in the same vocabulary I use for the agents I work on.

What she got wrong in week one

She logs the questions people type, anonymously: the text, the answer it reached, and whether it reached one. 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.

Her first two misses were her own name. Somebody asked "who are you?", then "cine ești?", and she had nothing for either. Her own identity, in both of the languages her visitors write in, on the first impression.

The miss that taught the most came later. Somebody typed ai, then artificial, then intelligence, then artificial intelligence, and was politely handed my email address four times, for a question she 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 she can answer, so a test can hold every suggestion to a real reply.

Every miss became a permanent test, which is the only reason the list below is short.

ask-qa.cjs · the live log as a test suite
/* 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 model

Every fact she 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. How I test her, and what the tests cannot tell me, is the next piece.

I love what Fabrizio Ferri Benedetti built, and I still want my Eliza. Ask Fabrice is the same idea built the other way round. His bot searches his own pages for the passages that look relevant, hands two or three of them to a language model, and lets the model write the reply. There are sensible limits around it: a free allowance, then a bot check, and a cap per visitor.

The trade is clean, and I would rather state it than win it. His bot answers anything, and can be wrong. Mine answers what it was given, costs nothing to run, has no key to leak, and replies in under half a second. His weak point is trust. Mine is coverage, and coverage is the thing the live log repairs week by week.

I took three of his ideas outright: a coverage check, so any page worth advertising to machines has an answer she can give; a daily cap per visitor on the logging endpoint; and a visible character counter near the input limit. The model is the thing I left alone. Swapping written answers for generated ones would trade away the one property that makes her worth showing to somebody who is hiring.

Every failure is a chance to repair

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 she now does. The four misses on ai bought the shared vocabulary and the suggestions. "Who are you?" bought her her 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.

So, in full: one JavaScript file. Eighty-three topics. Twenty-seven summaries written at exactly five, ten, and twenty-five words. A repair budget of three tries worded differently and one last line that hands over a human. Zero model calls, zero cost per question, zero invented facts.

What is left, once nothing is generated, is the craft: turn transitions measured in milliseconds, coverage as a property somebody maintains, and 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.

If you need to understand my process, my tone of voice, my way of thinking, my impact and how I work, my job is to get that to you as fast as possible. So if my job is to get information to people, whatever the channel or the tool, then I need to use chatbots to send my pigeon into the sea of the internet.

The pigeon is out. She sits in the corner of every page on this site, pearl coloured, and she goes solid lilac a quarter of a second before she speaks. Ask her something.

subscribe by email share on linkedin