The career fair was at a university in the Bay Area. StrongDM had a booth—a table, really, with a banner and some stickers and a QR code linking to the careers page. Justin was there because he believed CTOs should occasionally stand at career fair tables and talk to undergraduates. It kept you honest about what the next generation was thinking.
She was a junior, computer science major, and she waited until the three students ahead of her had each taken a sticker and moved on before she approached. She had the look of someone who'd been rehearsing a question.
"I read about your software factory," she said. "The one where AI writes all the code."
"That's a simplification, but yes," Justin said. "Go on."
"If AI writes all the code..." She paused. Restarted. "I'm about to spend two more years learning to write code. If AI writes all the code, what will I do?"
Justin didn't give her the comfortable answer. He didn't say "AI will just be a tool" or "there will always be jobs for programmers." Those were the answers she'd heard from every other booth, and she'd come to this one specifically because she sensed they weren't true.
"You'll describe the world," Justin said.
She blinked.
"The factory doesn't eliminate the need for human intelligence. It redirects it. Right now, programmers take a requirement, figure out the design, and express it in code. In the factory, humans take a requirement and express it as a specification—a precise description of what the software should do, how it should behave, what scenarios it should handle. Then agents implement the specification. But the specification requires deep understanding of the problem domain. It requires knowing what to build and why. It requires judgment."
He paused to let her process.
"The skills you're learning aren't wasted. Understanding how software works—data structures, algorithms, systems architecture—that knowledge makes you better at describing what software should do. You don't stop needing to understand the machine. You stop needing to type the instructions by hand."
"So I'd be writing specs instead of code?"
"You'd be writing specs. Designing scenarios. Building digital twins. Thinking about what 'correct' means for a given system and figuring out how to measure it. You'd be doing the hardest part of software engineering—the part that was always the hardest part. The implementation was never the hard part. Understanding the problem was the hard part. We just used to do them both at the same time."
She was quiet for a moment. Then she said, "That actually sounds more interesting than writing code."
Justin smiled. It was the right answer, and she'd arrived at it herself, which was better than if he'd handed it to her.
"Keep learning to code," he told her. "But start paying more attention in your requirements engineering class. That's the one that's going to matter."
She took a sticker and left. Justin watched her go and hoped she'd remember the conversation. Some career fair conversations evaporate by dinner. Some change the shape of a career. He couldn't know which kind this one was.
As a CS junior, this is the first time the "what will I do" question got an answer that didn't feel like a dodge. "You'll describe the world." Not "don't worry, there will still be jobs." An actual reframing of the role.