Her name was Priya and she was a rising junior at Stanford and she had exactly no idea what she was walking into.
The job posting had said "Software Engineering Intern" and she had prepared accordingly: LeetCode problems memorized, system design patterns rehearsed, a GitHub profile polished to a high sheen. She arrived on her first Monday in September with a laptop bag over one shoulder and a confidence born from three prior internships at companies where interns wrote code.
Justin met her in the lobby. "Welcome. Your job this summer is to write scenarios."
"Scenarios," she repeated.
"Not code. Scenarios."
He said it the same way you'd say "not salt, sugar." As if the distinction were obvious and the confusion was understandable and the correction was gentle.
Priya spent her first day confused. She sat next to Navan, who showed her the scenario repository—thousands of files, each one describing an end-to-end user story in precise, structured natural language. A new employee joins the company. A permission is revoked. A cross-workbook formula recalculates. A Slack channel receives a notification from Jira. Each scenario was a tiny world, complete with preconditions and expected behaviors and satisfaction thresholds.
"Where's the code?" she asked.
"You don't write code," Navan said. "Nobody here writes code."
"Then who writes the code?"
"The agents write the code. You describe the world the code needs to survive in. The agents figure out how to survive in it."
Priya stared at the scenario files. They weren't code. They weren't pseudocode. They weren't even structured specifications in the traditional sense. They were stories. Precise stories, yes—stories with API contracts and error conditions and timing constraints—but stories nonetheless. Each one narrated a journey through a system, and the agents' job was to make that journey possible.
On her second day, she wrote her first scenario. It was terrible. Too vague. Too many implicit assumptions. Jay reviewed it—not the code, because there was no code, but the scenario itself—and showed her where the ambiguities were.
"Here," he said, pointing at a line. "You say 'the user should be able to access the document.' What kind of access? Read? Write? Comment? What happens if the document doesn't exist yet? What if the user's permissions were revoked between the request and the response?"
Priya rewrote the scenario. Tighter. More specific. She described the world with the precision of someone who had been told, gently, that vagueness was the enemy.
By the end of her first week, she had written eleven scenarios. Three of them had uncovered edge cases that the existing scenario suite had missed. One of them—a race condition in the Jira twin's webhook delivery—had been lurking for months.
"The best scenario writers are the ones who haven't been trained to think like programmers," Justin told her on Friday. "They describe what users actually do, not what the system was designed to handle. Deliberate naivete."
Priya went home that weekend and rewrote her resume. Under "Skills," where she had previously listed programming languages and frameworks, she added a new line: Scenario design.
By the end of the summer, she was the best scenario writer in the building. She never wrote a single line of code.
The race condition in the Jira webhook that was lurking for months, found by someone who'd been on the job for five days. Deliberate naivete is real and this story nails why it works.