This is Episode 3 of The Vibe Coder’s Guide to the Machine: computer science for a new generation.
Say you have asked an assistant for a small program that pulls data from a service once a second. The service wants to know who is asking, so the program logs in when it starts and receives a token. It saves the token in a file so it will not have to log in again, and sends it with every request. The assistant runs the program, the first answers come back fine, and it tells you the program works, which is true. Then, while the program is still running and the terminal is still printing, the answers change from yes to no.
I built the smallest version of that on a Mac: a local server that hands out tokens and a client program that uses one. A token here is a short piece of text the server issues, meaning roughly “whoever presents this may ask for data”. This one also carries its own deadline, four seconds after it was issued. The server signs it, attaching a mark computed with a secret only the server holds, so the server can tell if anyone has altered the contents, deadline included. The client starts, gets a token, saves it to a file, and calls the server’s /data address once a second for seven seconds with the same token. At zero, one, two and three seconds, the server answered 200, “ok”. At four, five and six seconds it answered 401, the status a web server uses to refuse a request whose credentials it will not accept, with the message “token expired”.
Look at what did not change. The client’s process ID was 91342 at the first call and 91342 at the last. It never crashed. It added no warning of its own. It went on asking, punctually, and printing the refusals. By any measure a process list can show, it was the same healthy process it had been three seconds earlier. The token had not changed either: the same bytes, sent the same way. Only the time had moved.
Running is not the same as still valid. A process can hold a token, a connection or a turn at writing to a shared file while another party’s clock counts down on it. When the count reaches zero, the process is not told and does not stop. It carries on exactly as written, holding a credential that the party that issued it no longer honours. Some endings are caused by an event: a process exits, a file is closed, a name is deleted. This one is caused by a clock, and the clock belongs to someone else. No one calls the ending, no event marks it, and the process that holds the expired token finds out last, one refusal at a time.
AI makes this easy to miss, because of when the checking happens. An assistant tests its work in the minute after writing it, and in that minute every token is fresh and every connection has just been opened. The deadlines that matter are usually further away than the test. So the practical question is: what can expire while your code is still running, and what keeps it valid?
