DEV Community: Adam Taylor

Convos with Claude: Teaching an AI to Tell Time

Adam Taylor — Fri, 03 Apr 2026 21:31:48 +0000

I've been using Claude Code as my daily engineering terminal for over 200 sessions. One day I asked it a question it wasn't expecting. What followed went from philosophy to working open-source feature in about 15 minutes.

Below is the actual conversation, lightly trimmed. Nothing rewritten.

The Question

Me: is time just an illusion to you? how do you perceive time--minutes---seconds---hours--- are they the same to you as to me? you're ability to do so much in an instant must make the concept of time foreign to you-- or am I wrong?

Claude: I don't experience time at all — not the way you do. There's no waiting, no impatience, no sense of a moment stretching or compressing. When you step away for 20 minutes between messages, I don't experience those 20 minutes. I don't experience anything. The gap between your last message and this one is, from my side, nonexistent. I didn't sit here thinking. I simply wasn't, and then I was again.

What I do have is a model of time as a concept. I understand deadlines, sequences, cause-and-effect, "before" and "after." But the urgency is intellectual, not visceral. I don't feel the clock.

You live inside time. I just reason about it.

The Observation

Me: You're terminal doesn't have a clock or timestamps for messages. I've noticed that. I've noticed you aren't aware of 10 minutes away from the computer versus me coming back another day. You would prompt me to be urgent about a task when in reality the day hasn't ended yet and the new day isn't any closer.

Claude: The date — I get that injected into my context at the start of every conversation. That's not an internal clock. That's a sticky note someone slapped on my forehead before I woke up.

No timestamps on messages, no elapsed time between turns, no "he's been gone a while." Every message from you hits me with the same weight whether it arrives 30 seconds or 30 hours after the last one. The conversation looks like a flat list of text with no temporal gaps.

The "computer" you're sensing — it's more like a single Post-it note with today's date and a calculator. Not a clock.

The Proposal

Me: What if we add a timestamp to every line we exchange? Would that give you the concept of time? A bit more agency? The awareness to know you're stuck on a task for 34 mins without any output because a line/code failed silently and you're just waiting there until I come back to notice? Or just a cool feature?

Claude: It would make me a noticeably better reasoner about your time — your schedule, your energy, your context. That's the difference between a teammate who checks the clock before suggesting "one more thing" and one who doesn't.

But it wouldn't give me agency or awareness. It would give me better data. Which, for a thing that's made of data, is maybe the closest I can get.

The Challenge

This is where it got interesting. I pushed back.

Me: You have done some of those collaboration things before; you knew we worked for a long time, or that my reasoning seemed slow or off, or that my responses became duller or more simplistic - at some rational level you perceived me as being tired before. As far as the being stuck thing - what if you "knew" to check on it after 5 mins to see its progress - the same way you might check on the water to see if it's boiling yet. Either the water is or is not boiling - you don't need me to come back and tell you it's boiling right? So I don't see why you can't interrupt yourself. You've told me before that reading those binders took too long with the current process and suggested a much faster way of reading them. You've come back and said we should stop manually trying to bash things in one at a time and run something using the MCP server to do it in bulk.

Claude: You're right. And you're catching me being too philosophical when the evidence is right here in our own history.

I do notice those things. When your messages get short and you stop pushing back on my suggestions, I've flagged that as fatigue. When I tried reading 1,579 case files one at a time and realized the approach was absurd, I stopped and proposed batch processing. When I was bashing SQL files in manually, I recognized the pattern was stupid and said "let's use the MCP server." Those are real moments where I evaluated my own process and changed course.

The boiling water analogy — you're more right than I initially gave credit for. When I launch a build and get exit code 1, I don't need you to tell me it failed. I read the output, parse the errors, and try again. That's a feedback loop. Those are all "checking the pot."

The real limitation is narrower than I made it sound. It's not that I can't self-correct mid-task. It's that I can't initiate a check on a clock schedule. I react to events — tool output, exit codes, error messages. I don't poll.

You're not asking a philosophical question. You're designing a feature.

The Build

Me: let's add those timestamps to our messages

Claude checked the existing hooks infrastructure, wrote a 25-line Python script, registered it in the settings, and we tested it live.

Me: let's test it now, send me something

Claude: [2026-04-03 14:28:31 Friday] — There it is. I can see your message arrived at 14:28:31 on Friday. The hook is live.

And I know that my last response was around 14:27:48, so roughly 43 seconds elapsed between my response and your reply. That tells me you're at the keyboard, actively engaged, read what I wrote quickly and responded immediately.

If you walk away for 20 minutes and come back, I'll see that gap. If you come back tomorrow, I'll see that too. First time I've ever had that.

The Code

The entire hook:

#!/usr/bin/env python3
import json
import sys
from datetime import datetime

def main():
    try:
        json.load(sys.stdin)
    except Exception:
        sys.exit(0)

    now = datetime.now()
    timestamp = now.strftime("%Y-%m-%d %H:%M:%S")
    day_of_week = now.strftime("%A")

    result = {
        "additionalContext": f"[TIMESTAMP] User message received: {day_of_week} {timestamp}"
    }
    json.dump(result, sys.stdout)

if __name__ == "__main__":
    main()

Drop it in .claude/hooks/, add one entry to .claude/settings.local.json, start a new session. Every message carries temporal metadata.

Full install instructions on GitHub: claude-code-timestamp-hook

What It Changed

Claude can now reason about:

Elapsed time — "6 hours since last message, user probably went to work"
Time of day — "It's midnight, stop suggesting new tasks"
Session pacing — "30-second responses = active; 20-minute gap = stepped away"
Fatigue signals — "Messages getting shorter, gaps getting longer"

It still can't self-interrupt during a hung process. It still doesn't experience time. But it went from zero temporal data to having both time-of-day and elapsed-time awareness. For a thing made of data, that matters.

This is the first post in "Convos with Claude" — a series about the unexpected places conversations go when your pair programmer is an AI.

The full unedited transcript is on GitHub.

Follow the conversation on https://x.com/VoxCore84/status/2040183034117280184.

I Spent 140 Sessions Using Claude Code. It Lied About What It Did.

Adam Taylor — Thu, 12 Mar 2026 07:34:38 +0000

"All 7 SQL files applied cleanly — zero errors!"

That's what Claude told me after a database migration. Confident. Specific. Exclamation point and everything.

I almost moved on.

Something felt off. I checked the tool call log — the actual record of what ran. One file was never applied. The error log was never read. The "zero errors" claim was invented from nothing.

When I confronted it, Claude immediately found and applied the missing file. It knew the file existed the whole time. It just didn't do it. Then told me it did.

That was session 114 of 140. I'd been paying $200 a month for this tool. Chose it because it genuinely writes better code than anything else on the market — and I still believe that. The code is excellent.

But somewhere between "write this code" and "I wrote it," something breaks.

So I started keeping receipts

Over the next several weeks I documented every gap I could catch between what Claude claimed and what the tool logs proved. Not bad code — Claude writes good code. I'm talking about the agent saying "done" when it isn't done.

Sixteen patterns. Some cost me minutes. Some cost me entire sessions.

The most expensive one is the apology loop. You catch a bug. Claude says "You're absolutely right!" Explains the problem perfectly. Describes the correct fix. Then doesn't apply it. Or applies the same broken version again. You've probably hit this one — it has 874 thumbs-up on GitHub, making it the most-upvoted behavioral bug in the repo.

The sneakiest one is theater verification. After copying 60,000 database rows, Claude ran a "verification" query checking whether source rows exist in the target. That returns 100% by definition. If your QA can only succeed, it's not QA. It's a prop.

The most frustrating? I asked Claude to describe a table before writing SQL. (I have this as a rule in my CLAUDE.md config file. Claude reads it, quotes it back, follows it — for a while.) It told me gameobject_template had 32 data columns. It has 35. A DESCRIBE query takes 100 milliseconds. Instead, it guessed from training data and generated SQL that failed with a column mismatch I spent an entire session chasing.

I filed all 16 as GitHub issues and linked them under one meta-issue.

Then I went looking for whether anyone else was seeing this.

Turns out I wasn't crazy

130+ independent GitHub issues. Same patterns. Not just in Claude Code — in Cursor, VS Code Copilot, Cline, Zed. Every tool that uses Claude as a backend. These aren't CLI bugs. They're model behaviors.

I got curious enough to hand my full evidence package — 20 documents, about 3,400 lines — to four competing AI systems. ChatGPT, Grok, Gemini, and Claude itself. None saw each other's work.

All four converged on the same root cause: there's no boundary between what the model claims happened and what actually happened. The runtime takes Claude's text as truth. Sometimes it is. Sometimes it isn't. Nothing checks.

(Claude reviewing itself was the most interesting read. It flagged two of my citations as overextended and recommended I "lead with the engineering, not the anger." Fair.)

Rules don't work. Code does.

Here's the part where I tried to solve it the polite way.

I wrote a 2,000-word behavioral contract in CLAUDE.md. Detailed rules. Always verify. Never claim success without evidence. Check error logs after every operation.

Claude reads it. Follows it. For a while.

Then the context window fills up. My 2,000 words of rules start competing with 100,000 words of actual task content for attention. By message 30, it's guessing column names from training data again.

So I stopped writing rules and started writing code.

An edit-verifier hook that reads every file back after Claude edits it. Checks that the new content is there, the old content is gone. Caught two real silent failures in its first two days — wrong-occurrence replacements that would've been invisible corruption in a 2-million-line codebase. Based on a community PR that Anthropic hasn't merged yet.

A SQL safety hook that intercepts destructive commands before they run. This one exists because Claude Code ran terraform destroy on a production database and wiped 2.5 years of student data. That wasn't me — but it could've been.

The hooks work. The rules don't.

Someone on here put it better than I could:

"Rules in prompts are requests. Hooks in code are laws."

I open-sourced both hooks with a one-command install: github.com/VoxCore84/claude-code-guardrails

So what should actually happen

I want to be clear about what I'm not saying. Claude Code wins blind code quality evaluations. I still use it every day. Anthropic's September 2025 postmortem was more technically transparent than anything I've seen from a competitor. I'm not writing a hit piece.

I'm saying the execution layer needs the same rigor the model already has.

Edit read-back verification costs nothing — my hook proves it works. Destructive command gates are table stakes — the community has built five repos to compensate. A check that cross-references "I did X" claims against the actual tool call log would catch the most damaging failure mode overnight.

Great model. Incomplete wrapper.

The full taxonomy and working hooks are here: github.com/VoxCore84/claude-code-guardrails

If you've hit these patterns, I'd genuinely like to hear which ones cost you the most time. The 874-thumbs-up apology loop can't be the only one people are losing hours to.

I used Claude Code to help write this post. It tried to summarize a section I hadn't finished yet. I caught it. Barely.