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.
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.
No cloud. No telemetry. No code execution. No AI required.
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.
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.
That last part matters because DevTime should not pretend to know more than the repository can prove.
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:
Uncertainty is a feature, not a bug.
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.
Links
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.
No cloud. No telemetry. No code execution. No AI required.
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.
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!
