In June, engineer Sophie Alpert drew up an AI writing policy for her team at sales intelligence software startup Clay. It allowed engineers to use AI to brainstorm, draft, and proofread, but mandated that they do their own writing. The policy swiftly went company-wide, but not because leadership pushed it. Clay employees asked for AI writing guardrails.
Alpert isn’t the Brand Media Review’s usual subject. She runs an engineering team, not a brand publication. She came to our attention when her policy went viral among brand editors and writers grappling with their own teams’ AI use.
Alpert’s argument, laid out in an essay titled “There are no lossless transformations of natural language text,” is that writing is thinking. When a manager asks someone to write up a project plan, what they really want is for the employee to think the work through — not for their preferred LLM to do so. The Brand Media Review spoke to Alpert about the mistakes that prompted the policy, whether there was any pushback, and how she squares an AI writing ban with building the technology for a living.
This interview is part of a Brand Media Review series featuring the editors, CMOs, content directors, and — apparently — engineers at the forefront of brand publishing.
You’re an engineer at a company driven by AI, and your essay is careful to acknowledge AI’s coding ability. But you draw a line at using it to write. Why is writing different?
Code is designed to be run by a computer, and there’s an objective standard of whether it does the correct thing or not. With human language, there’s a lot of subjectivity. You’re trying to convey an idea to another person, rather than to a computer, and because of that, it’s much more important to pay attention to nuance.
A lot of engineers treat documentation as a means to an end — it’s not their main focus. But you argue that it’s proof of thought. When did you start seeing internal writing that way?
It depends on the writing. Sometimes an idea is already fully formed in someone’s head, and they’re just communicating it to someone else. But with a project status update or a retrospective, the goal is often not the writing itself. What I’m really asking is for them to think through the project, consider anything that might go wrong, and take responsibility for the result.
What prompted the policy?
Specific failure modes I kept seeing. People were writing documents with parts that weren’t relevant, included by accident because they weren’t paying attention to what the AI put in. When a colleague takes a shortcut to produce a long document that isn’t based on their own thought, it takes just as long, or longer, for me to parse — even though they didn’t put much work in and it’s not reflective of their thinking. That mismatch is frustrating, and I saw it several times, internally and with external people. I wanted to put a stake in the ground.
Did any engineers push back?
Not really. One question did come up among the engineering leads: if it’s not worth somebody’s time to write it, is it worth somebody’s time to read it? AI is now at the point where I can give it access to a codebase and ask how a part works and get a very good answer, which in many cases sidesteps the need for the documentation at all. If someone’s writing something because they feel it’s required, but they’re not putting the work in, I’d rather they ask whether the artifact needs to exist in the first place.
This started as a rule for the engineering team, and then other departments asked to be included. How did this policy wind up going company-wide?
The people I heard from were frustrated, like me, at being handed AI-written documents that weren’t substantive and were a waste of time to read. They wanted a policy to lean on, because it’s much easier to push back on a coworker and say, “Can you write this out yourself?” when there’s a shared understanding that the team values it. It’s about using each other’s time well.
Clay builds a product that uses AI to generate research and output. How do you square that with a policy that restricts AI writing?
The work any of us does falls on a spectrum. At one end are routine, repeatable tasks that have been done before and will be done many times again; at the other are creative, one-off tasks, novel each time. AI is most useful for the first. The creative end — figuring out what to do and how to do it — is where human judgment still matters, and where I’d rather people spend their time.
This interview has been edited for length and clarity.
