DEV Community: Aviad Shakargy

Your repo has a file called stripe/webhook.ts. It does nothing.

Aviad Shakargy — Mon, 20 Jul 2026 21:31:21 +0000

Here is a file from a real, well-known open-source repository:

pages/api/stripe/webhook.ts

If you grep a codebase and find that file, you will conclude the app handles Stripe webhooks. Your coding agent will conclude the same thing, faster, and with more confidence.

Here is the entire handler:

export default function handler(_req: NextApiRequest, res: NextApiResponse) {
  res.status(404).json({ message: "Billing webhooks are not available in community edition" });
}

It does nothing. The feature lives in a paid edition. The file name makes a claim the code does not keep.

I found this while testing my own tool against Cal.com, and it changed what I was building.

DevTime started as a local-first CLI that scans a repository and explains it from evidence. As of v0.4.0, it has become something more specific: a verification layer. You state a claim about the repository, and DevTime tells you whether the code can actually back it.

The Idea: Claims, Not Vibes

A claim is a statement about a repository. "Billing webhooks verify signatures." "Authentication uses JWT access tokens."

Most tools answer these questions with pattern matching and confidence. DevTime answers with a status and receipts:

pipx install devtime-ei
cd your-repo
dtc init
dtc scan
dtc verify billing-webhook-signature

Billing Webhook Signature Verification
Claim: Incoming billing webhooks verify the provider's signature.
Status: SUPPORTED

Why:
  - Signature verification behavior evidence was found.
  - A test exercises signature behavior.

Supporting evidence:
  - src/billing/stripe-webhook.ts  [strong]
      Verifies the provider's webhook signature.
  - tests/stripe-signature.test.ts  [moderate]
      Test exercises webhook signature behavior.

Four possible statuses:

SUPPORTED - required behavior evidence exists in the current scan
WEAK - the surface exists, but the proving evidence is missing
CONTRADICTED - credible evidence conflicts with the claim
UNKNOWN - no relevant surface found, or coverage cannot responsibly decide

Statuses mean "per the evidence rules", never formal proof. The tool says so itself.

Contradictions Show Both Sides, Always

Back to that stub file. Run the same claim against a repo where the handler is a 404 stub:

Status: CONTRADICTED

Contradictions:
  - The billing webhook endpoint cannot verify signatures
    because it is a disabled stub.
      claimed:  pages/api/stripe/webhook.ts is named and routed
                as a billing webhook endpoint.
      observed: The handler's only behavior is a 404/501 response.

No vague "authentication may be inconsistent" warnings. A contradiction names what claimed the behavior, what the code actually does, and the exact paths. You can go check.

There is a second detector for the classic case: documentation says JWT, but the only JWT usage in the code is invitation tokens, not access tokens. Both sides, exact files.

One rule I care about a lot: absence is not a contradiction. Documentation with no matching code is WEAK, missing evidence. CONTRADICTED requires positive conflicting evidence on both sides. A tool that cries contradiction on every gap would be noise within a week.

Truth and Freshness Are Separate Axes

A claim you verified last month is not the same as a claim that still holds.

Every verification stores fingerprints of its evidence files. When any of them changes, the claim goes stale, and DevTime names the file:

billing-webhook-signature
  last status: SUPPORTED   freshness: STALE
    changed since verification: src/billing/stripe-webhook.ts

Only evidence files count. You can rewrite the rest of the repo and nothing flags. That restraint is deliberate: staleness alerts that fire on every commit train people to ignore staleness alerts.

The diff review picks this up too:

dtc risk --diff

Claim impact:
  - billing-webhook-signature (previous status: SUPPORTED)
      changed evidence: src/billing/stripe-webhook.ts
      re-verify: dtc verify billing-webhook-signature

Your diff does not just touch files. It destabilizes specific verified claims, and now the review says which ones.

Why This Matters More With Agents

Coding agents read file names and README statements, then act on them with full confidence. The stub webhook above is exactly the kind of thing an agent gets wrong: it would "know" the repo handles Stripe webhooks, and build on payment logic that does not exist in that edition.

DevTime ships a read-only MCP server, so agents can ask instead of guess:

pipx install "devtime-ei[mcp]"
claude mcp add devtime -- dtc mcp start

The agent gets four tools, including this one:

verify_claim -> status, why, supporting evidence, contradictions,
                missing evidence, coverage limitations

Local stdio only. No network listener. No source code returned. And no LLM anywhere in the truth path: verification is deterministic and rule-driven, so the same repo state always produces the same answer.

What It Is Not

Honesty section, because the tool is built on one:

It is a heuristic scanner. Evidence comes from static patterns, not execution.
Two built-in claims so far (billing webhook signatures, JWT authentication). User-defined claims are deliberately postponed until the built-in ones prove trustworthy on real repositories.
Statuses are evidence policy, not security certification.
Strongest on TypeScript/Next.js/Express/FastAPI-style repos. Coverage limits are documented, and the tool prints its own blind spots during scans.

Every wrong output can become a regression fixture. That is the deal I offer: if DevTime says something your repository cannot back up, that report makes the tool permanently better.

Try It

pipx install devtime-ei
dtc demo init
cd devtime-demo-saas
dtc init
dtc scan
dtc verify

The demo repo ships in the package, so you can see SUPPORTED and then break it yourself and watch the status flip.

Shakargy / devtime

Local-first Engineering Intelligence for software repositories.

DevTime

Local-first Engineering Intelligence for software repositories.

DevTime helps a codebase explain itself from evidence.

It scans code, tests, configs, routes, and decisions to identify supported software concepts, link claims to files, surface uncertainty, and warn about a narrow set of risky changes.

Prefer video? Watch the 2-minute demo: DevTime scans a repo locally, explains concepts from evidence, surfaces uncertainty, catches a risky diff, and shows how a corroborated decision improves understanding.

Try DevTime in 60 seconds

pipx install devtime-ei
dtc demo init
cd devtime-demo-saas
dtc init
dtc scan
dtc concepts
dtc explain "Billing Webhooks"

The PyPI distribution is devtime-ei. The Python package remains devtime, and the CLI command remains dtc. dtc demo init copies a small static example repo into ./devtime-demo-saas so you can try DevTime without cloning this repository.

From source

git

…

View on GitHub

PyPI: https://pypi.org/project/devtime-ei/
The verification model in full: https://github.com/Shakargy/devtime/blob/main/VERIFICATION.md
Release notes: https://github.com/Shakargy/devtime/releases

If you run it on a repo and it claims something your code cannot prove, open an issue. That is exactly the feedback I am looking for!

I scanned Cal.com with my evidence-based CLI. The best result was what it refused to say

Aviad Shakargy — Wed, 08 Jul 2026 21:54:36 +0000

I pointed my scanner at Cal.com this week, fully expecting to write a post about everything it got wrong.

The most interesting result was the thing it refused to say.

Quick context: I build DevTime, a local-first CLI that scans a repository and helps it explain itself from evidence. It detects a closed set of concepts (authentication, billing webhooks, background jobs, data export, admin permissions, file uploads), links every claim to evidence files, and reports uncertainty when it cannot prove something. No cloud, no telemetry, no code execution during scan, no AI.

The Setup

Cal.com is a well-known open-source scheduling platform. Big TypeScript monorepo, Next.js frontend, NestJS API, Stripe integration. If you wanted to stress a heuristic scanner, this is a good place to do it.

The run:

pipx install devtime-ei
git clone --depth 1 https://github.com/calcom/cal.com
cd cal.com
dtc init
dtc scan

The scan:

Scan complete. Scanned 5736 files, 24516 signals, 3 concepts in 4.2s.

Local, 4.2 seconds, nothing left the machine.

What It Found

1. Authentication      confidence: high   debt: medium
2. Billing Webhooks    confidence: low    debt: high
3. Background Jobs     confidence: low    debt: high

Authentication was solid. Real evidence, real routes:

- Authentication is present and supported by behavior evidence.
  confidence: 0.82
  evidence: apps/web/app/api/auth/forgot-password/route.ts,
            apps/web/app/api/auth/oauth/me/route.ts

But Billing Webhooks at LOW confidence? Cal.com is a scheduling SaaS with Stripe integration. Of course it has billing webhooks. I assumed I had found my first miss.

The Refusal

Here is what DevTime actually said:

- Possible Billing Webhooks signals detected. Billing Webhooks behavior
  is not established from current evidence.
  confidence: 0.45

Uncertainty:
  - Only dependency or manifest evidence was found for Billing Webhooks;
    presence is not confirmed behavior.

So I went to check manually. The repo has exactly the file you would expect:

apps/web/pages/api/stripe/webhook.ts

Case closed, right? A file named stripe/webhook.ts in a Stripe-integrated SaaS. Any developer grepping the repo would say "here is their webhook handler". Any AI agent reading file paths would state it as fact.

Here is the entire handler:

export default function handler(_req: NextApiRequest, res: NextApiResponse) {
  res.status(404).json({ message: "Billing webhooks are not available in community edition" });
}

It is a stub. The open-source snapshot of Cal.com does not process billing webhooks. That behavior lives in their enterprise edition. The second webhook route in the repo is the same story.

DevTime could not find behavior evidence because there is no behavior to find. The refusal was the correct answer.

That is the whole thesis of the tool in one example. A confident story built from file names would have been wrong. The repository could not prove billing webhooks, so the scanner said so.

Where It Was Actually Wrong

I promised misses, and there are real ones.

Background Jobs was under-called. Cal.com has a genuine job system: a Tasker package with an internal tasker, a Redis-backed tasker, and a task processor, plus cron routes. That is real worker and queue behavior, and DevTime only surfaced dependency and test evidence at low confidence. The guard that suppresses fake background-job signals (calendar cleanup crons pretending to be job queues) is suppressing a true positive here.

Admin Permissions was missed entirely. The repo has real admin surfaces, including admin API routes and admin settings layouts. DevTime detected nothing.

Both misses become regression fixtures now: small repo patterns encoding the expected output, so this exact failure can never return silently. Funny detail: two of the oldest fixtures in the suite came from Cal.com-shaped false positives (calendar "subscriptions" being mistaken for billing). Those fixtures fixed overclaiming. Today Cal.com exposed the opposite failure, overcorrection. Same factory, opposite direction.

One more honesty note: during the scan, DevTime printed this on its own:

Framework coverage warning: NestJS controller parsing is not supported in V0;
backend route coverage may be incomplete.

Cal.com's API v2 is NestJS. The tool told me where its own blind spot was before I found it.

Why I Care About This Pattern

Every tool in this space is optimized to sound sure. Summaries, autocomplete, agents: confidence is the product.

But the Cal.com webhook stub is exactly the kind of thing confident tools get wrong. The story "this repo handles Stripe webhooks" is plausible, well-supported by file names, and false. If your AI agent believed it, it might modify payment logic that does not exist in this edition, or trust dedupe behavior that is not there.

The rule I keep coming back to:

No claim without evidence. Weak evidence produces uncertainty, not confidence.

Uncertainty is not the tool failing. Uncertainty is the tool working.

Try It on Your Repo

pipx install devtime-ei
cd your-repo
dtc init
dtc scan
dtc concepts

There is also a read-only MCP server (dtc mcp start) so coding agents can query the same evidence instead of guessing.

If DevTime gets something wrong on your repository, that is not an embarrassment, it is a contribution. Wrong outputs become fixtures, and fixtures are how this tool earns trust.

Shakargy / devtime

Local-first Engineering Intelligence for software repositories.

DevTime

Local-first Engineering Intelligence for software repositories.

DevTime helps a codebase explain itself from evidence.

It scans code, tests, configs, routes, and decisions to identify supported software concepts, link claims to files, surface uncertainty, and warn about a narrow set of risky changes.

Try DevTime in 60 seconds

pipx install devtime-ei
dtc demo init
cd devtime-demo-saas
dtc init
dtc scan
dtc concepts
dtc explain "Billing Webhooks"

From source

git

…

View on GitHub

PyPI: https://pypi.org/project/devtime-ei/
2-minute demo: https://youtu.be/1Hiu3Y9J_SI
The "DevTime got this wrong" issue template: https://github.com/Shakargy/devtime/issues

If you run it on a repo and it says something your code cannot back up, open an issue. That is exactly the feedback I am looking for!

Give your coding agent memory it can trust

Aviad Shakargy — Sun, 05 Jul 2026 12:18:52 +0000

Your coding agent starts every session knowing nothing about your repository.

Then it guesses. Confidently.

It does not know where authentication actually lives. It does not know that your billing webhooks verify signatures, or that nobody ever wrote down why. It reads a few files, builds a story, and starts editing.

That is the problem I just shipped a fix for.

DevTime v0.1.2 turns local repository memory into an MCP server your agent can query.

If you are new here: DevTime is a local-first Engineering Intelligence CLI. It scans a repository and helps it explain itself from evidence. No cloud, no telemetry, no code execution during scan, no AI required.

Shakargy / devtime

Local-first Engineering Intelligence for software repositories.

DevTime

Local-first Engineering Intelligence for software repositories.

DevTime helps a codebase explain itself from evidence.

It scans code, tests, configs, routes, and decisions to identify supported software concepts, link claims to files, surface uncertainty, and warn about a narrow set of risky changes.

Try DevTime in 60 seconds

pipx install devtime-ei
dtc demo init
cd devtime-demo-saas
dtc init
dtc scan
dtc concepts
dtc explain "Billing Webhooks"

From source

git

…

View on GitHub

What Shipped in v0.1.2

One command:

dtc mcp start

That runs a real MCP server over stdio, on your machine, exposing three read-only tools:

list_concepts - what the scanned repo supports, with confidence labels
explain_concept - the claims behind one concept, the evidence files, and what is still uncertain
get_context_pack - a governed context bundle to hand an agent before it touches code: supported claims, do-not-change-without-review paths, tests to run

So instead of your agent guessing where billing webhooks live, it can ask. And instead of getting a confident story, it gets claims with evidence paths and an explicit uncertainty list.

Try It in Two Minutes

Install with MCP support:

pipx install "devtime-ei[mcp]"

Scan your repo:

cd your-repo
dtc init
dtc scan

Hook it into Claude Code:

claude mcp add devtime -- dtc mcp start

Or any client that reads a config file:

{
  "mcpServers": {
    "devtime": {
      "command": "dtc",
      "args": ["mcp", "start"]
    }
  }
}

No repo to test on? DevTime ships a demo:

dtc demo init
cd devtime-demo-saas
dtc init
dtc scan

What the Agent Actually Gets

Here is the shape of an answer for a concept like Billing Webhooks:

Billing Webhooks is present and supported by behavior evidence. confidence 0.86
Evidence: src/billing/stripe-webhook.ts, tests/stripe-signature.test.ts
Uncertainty: no decision was found explaining key choices
Understanding Score: 58 / 100

Notice the last two lines. The tool tells the agent what it cannot prove. That is on purpose.

The Rules Did Not Change

Wiring a server is exactly the kind of moment where a tool quietly grows scope. This one did not:

Read-only. There are no write tools.
Local stdio only. There is no network listener.
No source code is returned. Claims, evidence file paths, and uncertainty. That is it.
Weak evidence produces uncertainty, not confidence.
If the repo was never scanned, the tools say so instead of making something up.

The main rule is still the same one DevTime started with:

No claim without evidence.

Agents are the exact audience that needs this rule. A human reviewer might notice when a summary smells wrong. An agent will happily build on it.

Where to Find It

DevTime is now listed in the official MCP Registry as:

io.github.Shakargy/devtime

It is also on mcp.so and Smithery, and the package lives on PyPI as:

devtime-ei

The Python import is still devtime and the command is still dtc. The name devtime was reserved on PyPI, so devtime-ei is the public distribution name.

Why I Keep Building This

AI tools write code faster than teams can understand it. The gap between "code exists" and "someone understands it" grows every sprint. Git remembers what changed. It does not remember what is true, what supports it, or what nobody ever decided.

AI writes. EI remembers.

That is the bet. v0.1.0 was the scanner. v0.1.1 made it installable in one line. v0.1.2 hands the memory to agents.

What I Want Feedback On

Not "nice project". This:

DevTime got a concept wrong on your repo
A claim is too strong
An uncertainty is missing
The MCP setup failed on your machine
Your agent got a context pack that misled it

Every one of these can become a regression fixture. That is how the tool earns trust: wrong outputs become tests that can never break again silently.

Shakargy / devtime

Local-first Engineering Intelligence for software repositories.

DevTime

Local-first Engineering Intelligence for software repositories.

DevTime helps a codebase explain itself from evidence.

It scans code, tests, configs, routes, and decisions to identify supported software concepts, link claims to files, surface uncertainty, and warn about a narrow set of risky changes.

Try DevTime in 60 seconds

pipx install devtime-ei
dtc demo init
cd devtime-demo-saas
dtc init
dtc scan
dtc concepts
dtc explain "Billing Webhooks"

From source

git

…

View on GitHub

PyPI: https://pypi.org/project/devtime-ei/
MCP Registry entry: search "devtime" at https://registry.modelcontextprotocol.io/v0/servers?search=devtime
Release notes: https://github.com/Shakargy/devtime/releases/tag/v0.1.2
2-minute demo: https://youtu.be/1Hiu3Y9J_SI

If you wire DevTime into your agent and it says something your repo cannot back up, open an issue. That is exactly the feedback I am looking for!

The Most Dangerous Code in Your Repo Is the Behavior Nobody Can Prove

Aviad Shakargy — Wed, 01 Jul 2026 23:20:52 +0000

We spend a lot of time arguing about code quality. Is it clean? Readable? Tested? Too clever? AI-generated? All fair questions, but I think we're missing a more important one:

Can the repository actually prove what this behavior is supposed to do?

Not the developer. Not the product manager. Not the person who has been on the team for four years and somehow knows that this weird edge case is intentional. The repository itself.

Because when a system gets old enough, "how it works" and "what the repo can prove" slowly become two different things. And that gap is where bugs hide.

Code is not the same as behavior

A repository can show you code, commits, who changed a file and when. But code history is not behavior history.

Git can tell you:

It usually cannot tell you:

That second sentence is the thing teams actually need, and in many codebases it only exists in someone's head. Sometimes it lives in a Slack thread from 2022, or a Jira ticket nobody can find, or a PR comment that made sense at the time. Sometimes it doesn't exist anywhere.

The code still runs. The tests still pass. The team still ships. But the repo has lost the reason.

AI makes this worse, but it didn't create the problem

It's easy to blame AI coding tools here. AI generates code that looks clean, tests that pass, and explanations that sound reasonable. But every team has had code like this long before AI:

if (user.country === "US" && order.total > 0) {
  enableManualReview = true;
}

Why? Fraud rule? Tax rule? Old business requirement? Temporary workaround that became permanent? Nobody knows.

Now add AI to the picture. A coding agent sees that condition and tries to "simplify" it. A reviewer sees a clean diff. The tests pass because nobody ever wrote a test for the original behavior, and the PR gets merged. Two weeks later, someone asks why orders stopped entering manual review.

The behavior was real. The evidence was missing.

A green test suite is not proof of understanding

I love tests, but tests can only prove what someone remembered to assert. A test can prove that a function returns 200. It may not prove that the function is allowed to retry, that the retry must be idempotent, or that the timeout exists because a mobile client depends on it.

A passing suite often means "the checks we wrote still pass" - not "the behavior users depend on is still protected."

This is why missing evidence deserves to be treated as a signal, not just an inconvenience. If a PR changes payment logic and no payment tests changed, that doesn't automatically mean the PR is bad - but it's a signal. If a feature has five implementations, three naming styles, no docs, and tests that only cover happy paths, the next change to it is more dangerous than it looks. The repo is quietly telling you: I may work, but I cannot fully explain why.

That difference matters more now because code is getting easier to produce. When code becomes cheap, understanding becomes expensive.

The new code review question

Traditional review asks whether the code is correct, readable, secure, and tested. Those questions still matter. But I think every risky PR needs one more:

Take a PR that touches billing webhooks. The review shouldn't only ask whether the code looks good. It should ask: does this affect duplicate delivery? Retry behavior? Event ordering? Refunds? And for each answer - is there evidence, or just confidence?

This isn't about adding bureaucracy. It's about refusing to merge changes that look safe only because the repo cannot explain itself.

"Documentation" is not enough

The usual answer is: write better docs. I half agree. Docs are useful when they stay close to the system and dangerous when they drift away from it.

A README saying "webhooks are idempotent" is nice. A test proving duplicate delivery is safe is better. A decision record explaining why retries work this way is better still. And a tool that connects the claim to the actual files, tests, routes, and recent diffs is the best version of all.

The future of software maintenance isn't more documentation. It's evidence-backed documentation: here is the claim, here is the evidence, here is what's still uncertain. A repo should be allowed to say "I don't know" - that's much healthier than pretending.

Maybe repos need an "understanding score"

We measure test coverage, build time, bundle size, churn, security findings, dependency risk. We almost never measure whether a repository can explain its own important behavior.

Imagine opening a repo and seeing:

Area	Evidence
Authentication	Strong
Billing webhooks	Partial
File uploads	Weak
Admin permissions	Unclear
Email delivery	No decision record found

Not because the score would be perfect, and not because it replaces human review - but because it points attention at the parts of the system where the confidence is fake. And fake confidence is expensive.

The real bottleneck

AI tools will keep improving. They'll write more code, open more PRs, fix more bugs, generate more tests. That's not the problem. The problem is that faster code generation doesn't automatically create better system understanding - a team can ship more code while understanding less of the behavior they're preserving.

The bottleneck isn't syntax, boilerplate, or even review speed. The bottleneck is evidence. Can we prove what this behavior is, why it exists, and that this change doesn't break it? Until repositories can answer those questions, we're relying on memory, folklore, and confidence.

And confidence is not evidence.

The most dangerous code in your repo isn't always the ugly code, the old code, or the AI-generated code. Sometimes it's the behavior everybody depends on but nobody can prove. Once you start looking for it, you see it everywhere.

I've started exploring this idea in an open-source CLI tool called DevTime - it scans a repository and generates evidence-backed explanations of how things actually work, linking every claim to real files and tests. If the problem in this post sounds familiar, I'd love your feedback on it.

What's the piece of "everybody knows" behavior in your codebase that nobody can actually prove? Tell me in the comments.

DevTime v0.1.1 - I made the first-run experience much easier

Aviad Shakargy — Sun, 28 Jun 2026 21:00:07 +0000

A few days ago I released DevTime v0.1.0.

It worked. The repo was public, the demo was ready, the README was detailed, and the release was clean.

But there was still one problem: it was too annoying for a stranger to try.

Trying it meant cloning a repo, creating a virtual environment, and installing from source. That is a fine path for a contributor. It is not a great path for someone who just wants to understand what the tool does in one minute.

So DevTime v0.1.1 is about one thing: make DevTime easy to try.

If you are new here, DevTime is a local-first Engineering Intelligence CLI that scans a repository and helps it explain itself from evidence.

Shakargy / devtime

Local-first Engineering Intelligence for software repositories.

DevTime

Local-first Engineering Intelligence for software repositories.

DevTime helps a codebase explain itself from evidence.

It scans code, tests, configs, routes, and decisions to identify supported software concepts, link claims to files, surface uncertainty, and warn about a narrow set of risky changes.

Watch the 2-minute demo: DevTime scans a repo locally, explains concepts from evidence, surfaces uncertainty, catches a risky diff, and shows how a corroborated decision improves understanding.

Try DevTime in 60 seconds

pipx install devtime-ei
dtc demo init
cd devtime-demo-saas
dtc init
dtc scan
dtc concepts
dtc explain "Billing Webhooks"

From source

git clone https://github.com/Shakargy/devtime.git
cd

…

View on GitHub

What Changed in v0.1.1

DevTime is now published on PyPI. The distribution name is:

devtime-ei

The Python package is still:

import devtime

And the CLI command is still:

dtc

So the new install path is one line:

pipx install devtime-ei

No clone. No virtual environment setup. No installing from source.

Try It Without Cloning

After installing, you can create a local demo repo directly from the installed package:

dtc demo init

Then scan it:

cd devtime-demo-saas
dtc init
dtc scan
dtc concepts
dtc explain "Billing Webhooks"

That means someone can now try DevTime on a real example without cloning the GitHub repo first.

Why I Added the Demo Command

DevTime is about evidence, so a fake printed example is not enough. The demo needs real files, real routes, real tests, and real uncertainty.

So this command:

dtc demo init

copies a small packaged demo repository into your current directory. It does not:

Execute any code
Call the network
Send anything anywhere

It just creates a local demo app you can scan. The output shows how DevTime detects concepts like:

Authentication
Billing Webhooks
Background Jobs
Data Export
Admin Permissions
File Uploads

Then it explains those concepts from evidence:

dtc explain "Billing Webhooks"

The goal is not just to say "this repo has billing webhooks". The goal is to show what DevTime believes, which files support it, what is still uncertain, and what evidence is missing.

The Rule I Care About Most

No claim without evidence.

If evidence is weak, DevTime should not sound confident. It should show uncertainty. That is why one of the main product principles is:

This matters even more now because AI coding tools are making code generation faster. The bottleneck is not only writing code. The bottleneck is understanding what the codebase can prove.

AI writes. EI remembers.

A Nice Thing That Happened

After the public release, a GitHub user opened the first external PR to improve the README. It was a docs-only change, but it mattered. It proved the public backlog worked:

I opened small good-first-issue items
someone found one
they forked the repo
they sent a PR
it got merged

For a new open-source project, that small loop feels important.

What is in v0.1.1?

New commands:

dtc demo init
dtc demo init --force

Plus:

PyPI package (devtime-ei)
pipx install support
packaged demo repository
README quickstart starting from pipx install
97 passing tests
no cloud
no telemetry
no code execution during scan
no AI required

Quick Install

Install with pipx:

pipx install devtime-ei

Or with pip:

pip install devtime-ei

Create the demo repo:

dtc demo init

Run the demo:

cd devtime-demo-saas
dtc init
dtc scan
dtc concepts
dtc explain "Billing Webhooks"

What I Want Feedback On

The most useful feedback is not "nice project". The most useful feedback is:

DevTime got this concept wrong
This claim is too strong
This uncertainty is missing
This evidence is weak
This repo structure confused it
The install flow failed
The wording is misleading

That kind of feedback can become a fixture and make the tool more trustworthy.

Shakargy / devtime

Local-first Engineering Intelligence for software repositories.

DevTime

Local-first Engineering Intelligence for software repositories.

DevTime helps a codebase explain itself from evidence.

It scans code, tests, configs, routes, and decisions to identify supported software concepts, link claims to files, surface uncertainty, and warn about a narrow set of risky changes.

Watch the 2-minute demo: DevTime scans a repo locally, explains concepts from evidence, surfaces uncertainty, catches a risky diff, and shows how a corroborated decision improves understanding.

Try DevTime in 60 seconds

pipx install devtime-ei
dtc demo init
cd devtime-demo-saas
dtc init
dtc scan
dtc concepts
dtc explain "Billing Webhooks"

From source

git clone https://github.com/Shakargy/devtime.git
cd

…

View on GitHub

GitHub: https://github.com/Shakargy/devtime
PyPI: https://pypi.org/project/devtime-ei/0.1.1/
Release: https://github.com/Shakargy/devtime/releases/tag/v0.1.1

If you try it on a repo and it gets something wrong, please open an issue. That is exactly the feedback I am looking for!

I built DevTime - a local-first CLI that helps a repo explain itself from evidence

Aviad Shakargy — Tue, 23 Jun 2026 17:25:41 +0000

Git remembers code.

It remembers what changed, who changed it, and when.

But it does not remember understanding. It does not tell you why a behavior exists, what evidence supports it, what nobody has decided yet, or where a risky change may be touching an important concept.

That is the problem I started working on with DevTime.

DevTime is a local-first Engineering Intelligence CLI that scans a repository and helps it explain itself from evidence.

Shakargy / devtime

Local-first Engineering Intelligence for software repositories.

DevTime

Local-first Engineering Intelligence for software repositories.

DevTime helps a repository explain itself from evidence. It scans code, tests configs, routes, and decisions to identify the concepts inside a codebase, show the evidence behind them, surface uncertainty, and warn about risky changes.

It does not execute your code. It does not send your code anywhere. It does not require AI. It does not pretend to know things without evidence.

Why this exists

Git remembers code. It does not remember understanding - why a behavior exists, what evidence supports it, or what nobody has decided yet. As AI tools generate code faster than teams can review it, that missing understanding becomes the bottleneck.

DevTime builds evidence-backed repository memory: a local layer that says what a repository can prove, and - just as importantly - what it cannot prove yet.

…

View on GitHub

What DevTime Does

DevTime creates local repository memory. You can run:

dtc init
dtc scan
dtc concepts
dtc explain "Billing Webhooks"
dtc risk --diff
dtc context "Authentication"

It scans the repo locally, stores memory in .devtime/, detects known software concepts, links claims to evidence, and shows uncertainty when evidence is missing or weak.

For example, it can say:

This repo appears to have Billing Webhooks.
Here are the files that support that claim.
Here is what is still uncertain.
No decision was found explaining retry strategy.
This diff changed retry behavior without duplicate-delivery test changes.

What DevTime Does Not Do

V0 is intentionally narrow. DevTime does not:

Upload your code
Send telemetry
Execute repository code during scan
Require AI
Claim to understand every repository
Replace code review
Act as a security scanner

It is a heuristic tool with a closed set of supported concept families in V0.

The goal is not magic. The goal is evidence-backed repository memory.

Why I Built It

AI coding tools are making code generation faster. But faster code generation creates a new problem: teams can produce changes faster than they can understand the system around those changes.

DevTime is built around one idea:

AI writes. EI remembers.

Engineering Intelligence (EI), at least the way I am thinking about it, means a repository should be able to explain what it knows, what evidence supports that knowledge, and what is still uncertain.

The Rule I Care About Most

No claim without evidence.

If evidence is weak, DevTime should not sound confident. It should show uncertainty. That is why one of the main product principles is:

If DevTime says "I cannot prove this yet", that is not a failure. That is the product being honest.

What is in v0.1.0?

The first public release includes:

Local SQLite repository memory
Local scan & concept detection
Evidence-backed explanations
Understanding Score and Understanding Debt
Context Packs for humans and agents
Narrow advisory risk --diff
Issue template for "DevTime got this wrong"
Apache-2.0 license

Current V0 concept families include:

Authentication
Billing Webhooks
Background Jobs
Data Export
Admin Permissions
File Uploads

Quick Install

Clone the repo:

git clone https://github.com/Shakargy/devtime.git
cd devtime

Create a virtual environment:

python -m venv .venv

Activate it on macOS/Linux:

source .venv/bin/activate

Activate it on Windows PowerShell:

.venv\Scripts\Activate.ps1

Install DevTime:

pip install -e ".[dev]"

Run the demo repo:

cd examples/demo-saas
dtc init
dtc scan
dtc concepts
dtc explain "Billing Webhooks"

What I Want Feedback On

The most useful feedback is not "nice project". The most useful feedback is:

DevTime got this concept wrong
This claim is too strong
This uncertainty is missing
This evidence is weak
This repo structure confused it
The install flow failed
The wording is misleading

That kind of feedback can become a fixture and make the tool more trustworthy.

Shakargy / devtime

Local-first Engineering Intelligence for software repositories.

DevTime

Local-first Engineering Intelligence for software repositories.

It does not execute your code. It does not send your code anywhere. It does not require AI. It does not pretend to know things without evidence.

Why this exists

DevTime builds evidence-backed repository memory: a local layer that says what a repository can prove, and - just as importantly - what it cannot prove yet.

…

View on GitHub

If you try it on a repo and it gets something wrong, please open an issue. That is exactly the feedback I am looking for!

I Monitored 15 Popular APIs for 7 Days. 73% Changed While Nobody Was Watching.

Aviad Shakargy — Thu, 21 May 2026 22:40:39 +0000

Every backend depends on a graveyard of third-party APIs. Stripe for billing, Twilio for SMS, OpenAI for inference, that internal auth service from two teams over that nobody remembers who owns.

Ask any backend engineer to list every external HTTP call their service makes and you'll get half the list. The other half lives in a forgotten cron job, a legacy integration, or a vendor your predecessor added and never documented.

I wanted to know: how often do these APIs actually change? Not the big announcements that hit Hacker News - the quiet ones. The field that becomes required. The header that gets renamed. The deprecation notice buried in page 4 of a changelog.

So I built a system to find out.

The Experiment

I pointed my monitoring engine at the changelogs and release notes of 15 widely-used APIs:

Stripe · OpenAI · Twilio · GitHub · Auth0 · SendGrid · Slack · Shopify · Cloudflare · Vercel · Supabase · Notion · Firebase · HubSpot · Datadog

Every 6 hours, a worker fetches each changelog URL, extracts the text, computes a content hash, diffs it against the previous snapshot, and runs the diff through a severity classifier that scans for keywords like breaking change, deprecated, removed, security, end of life.

I let it run for a week with zero manual intervention. No tweaking, no hand-holding. Just the pipeline doing its job.

Here's what came back.

The Results

7 days. 15 APIs. 58 change events detected.

11 out of 15 APIs - 73% - shipped at least one change to their changelog or docs during a single week.

API	Changes Detected	Risk Keywords Found
GitHub	14	security, deprecated, removed
Vercel	10	security, deprecated, beta
Cloudflare	9	security, vulnerability, removed
Shopify	5	deprecated, removed, beta
Datadog	2	shutdown, breaking change, vulnerability
Slack	2	breaking change, deprecated, renamed
Firebase	2	breaking change, vulnerability, renamed
Supabase	2	breaking change, deprecated
Auth0	1	end of life, breaking change
OpenAI	1	breaking change, deprecated
HubSpot	1	beta
Stripe	0	-
Twilio	0	-
SendGrid	0	-
Notion	0	-

Let that sink in. In one week, the classifier flagged entries containing high-risk terms like breaking change, deprecated, removed, and end of life across 11 different APIs. Cloudflare, Datadog, and Firebase had vulnerability mentions. Auth0 had an end of life notice. Datadog's changelog contained shutdown.

Not every flagged entry means something broke. But each one is the kind of change worth reviewing before your next deploy - and in a normal week, most teams probably would not have seen them in time.

And this is just what's in the public changelogs. This is vendors doing the responsible thing and documenting their changes. How many don't?

Methodology note

This experiment tracked visible changes in public changelog and release-note pages. It does not prove that every detected change was breaking, only that the monitored source changed and contained risk-related language worth reviewing.

What Surprised Me

During this week, GitHub changed almost every 12 hours

14 change events in 7 days. During this monitoring period, GitHub's blog changelog updated almost twice a day with deprecations, security patches, and feature removals. If your CI/CD pipeline, your auth flow, or your webhook integrations depend on GitHub's API - and they probably do - things are moving under your feet constantly.

The "stable" APIs really are stable

Stripe, Twilio, SendGrid, and Notion had zero detected changes all week. That's not boring - that's a signal. These teams invest heavily in API stability. When you're choosing between vendors, this kind of data matters.

Most detected changes carried high-risk keywords

A large share of the 58 events contained keywords like security, deprecated, or removed. That doesn't mean every change was production-breaking - it means these were the changes most worth reviewing. Changelog entries tend to cluster around consequential updates. Nobody updates their changelog to say "we fixed a typo in an error message." When an entry appears, it usually matters.

Auth0 dropped an "end of life" notice

One event, one week, but the keywords were: end of life, breaking change, deprecated, removed, renamed. If you integrate with Auth0 and you didn't read their changelog this week, you might have missed a deprecation that affects your auth flow.

How It Works Under The Hood

This isn't a cron job running curl and diff. It's the same detection engine that powers API Graveyard, my API dependency intelligence platform, running against real vendor data in production.

The pipeline:

Celery Beat dispatches fetch jobs every 6 hours for each monitored source
Worker fetches the changelog URL, extracts text, and computes a content hash
Diff engine compares against the previous snapshot - if the hash changed, it generates a diff
Severity classifier scans the diff for risk keywords and assigns a severity level (critical / high / medium / low)
Risk events are created and surfaced on the dashboard with severity, timestamp, and source attribution
Public API serves the data through unauthenticated read-only endpoints - no login, no paywall

The whole thing runs on a single Docker Compose stack: FastAPI backend, React frontend, PostgreSQL, Redis, Celery workers. Deployed to a GCP Compute Engine instance via GitHub Actions. Total infra cost: less than the price of one Datadog alert channel.

Some engineering choices that matter:

Hash-based change detection means we don't store raw changelog HTML (copyright-safe) - we only store diffs when something actually changes
Keyword classifier is intentionally simple (pattern matching, not ML) because false negatives are worse than false positives here - I'd rather flag something that isn't breaking than miss something that is
Each vendor is an isolated adapter (~40 lines each). When Stripe redesigns their docs site - and they will - only the Stripe adapter breaks. The other 14 keep running.
SSRF protection on the fetch layer blocks private IP ranges and localhost - because this system fetches arbitrary URLs from a database, and that's exactly the kind of thing that gets you in trouble if you're not careful

Why This Matters

Most teams find out about breaking API changes one of three ways:

A deploy breaks in production. The Slack channel lights up at 2 AM.
Someone happens to read the changelog. Usually the one person who's subscribed to the vendor's blog, and they mention it casually in standup two days later.
A quarterly dependency audit catches it. Three months late, during a sprint nobody wanted.

None of these are good. The first one costs you an incident. The second one depends on luck. The third one is always too late.

What I learned from this week of data is that the problem is worse than most people think. 73% of the APIs we commonly depend on are changing every single week. Not every change is breaking, but the ones that are? They're buried in changelogs that nobody reads, mixed in with dozens of other entries.

For teams that depend on multiple external APIs, automated monitoring is quickly becoming less of a nice-to-have and more of a safety net. It's the difference between catching a deprecation notice on Tuesday and debugging a production outage on Saturday.

See It Live

The public dashboard is running right now at www.api-graveyard.com/api-health - no login, no signup, no paywall. Real data from real APIs, updated every 6 hours.

The source code for the case study (architecture diagrams, screenshots, SDK links) is on GitHub: github.com/Shakargy/api-graveyard-case-study

This case study only monitors public changelogs. The full product goes one layer deeper: discovering the actual APIs your services call from live traffic, mapping dependency risk across your entire stack, and alerting when something changes. One-line SDK integration for Python, Go, and Node.js - check it out at www.api-graveyard.com.

Built by the solo developer behind API Graveyard.

DEV Community: Aviad Shakargy

Your repo has a file called stripe/webhook.ts. It does nothing.

The Idea: Claims, Not Vibes

Contradictions Show Both Sides, Always

Truth and Freshness Are Separate Axes

Why This Matters More With Agents

What It Is Not

Try It

Links

Shakargy / devtime

Local-first Engineering Intelligence for software repositories.

DevTime

Try DevTime in 60 seconds

From source

I scanned Cal.com with my evidence-based CLI. The best result was what it refused to say

The Setup

What It Found

The Refusal

Where It Was Actually Wrong

Why I Care About This Pattern

Try It on Your Repo

Links

Shakargy / devtime

Local-first Engineering Intelligence for software repositories.

DevTime

Try DevTime in 60 seconds

From source

Give your coding agent memory it can trust

Shakargy / devtime

Local-first Engineering Intelligence for software repositories.

DevTime

Try DevTime in 60 seconds

From source

What Shipped in v0.1.2

Try It in Two Minutes

What the Agent Actually Gets

The Rules Did Not Change

Where to Find It

Why I Keep Building This

What I Want Feedback On

Links

Shakargy / devtime

Local-first Engineering Intelligence for software repositories.

DevTime

Try DevTime in 60 seconds

From source

The Most Dangerous Code in Your Repo Is the Behavior Nobody Can Prove

Code is not the same as behavior

AI makes this worse, but it didn't create the problem

A green test suite is not proof of understanding

The new code review question

"Documentation" is not enough

Maybe repos need an "understanding score"

The real bottleneck

DevTime v0.1.1 - I made the first-run experience much easier

Shakargy / devtime

Local-first Engineering Intelligence for software repositories.

DevTime

Try DevTime in 60 seconds

From source

What Changed in v0.1.1

Try It Without Cloning

Why I Added the Demo Command

The Rule I Care About Most

A Nice Thing That Happened

What is in v0.1.1?

Quick Install

What I Want Feedback On

Links

Shakargy / devtime

Local-first Engineering Intelligence for software repositories.

DevTime

Try DevTime in 60 seconds

From source

I built DevTime - a local-first CLI that helps a repo explain itself from evidence

Shakargy / devtime

Local-first Engineering Intelligence for software repositories.

DevTime

Why this exists

What DevTime Does