neprotivo

Improving code understanding is the main focus of my work and thinking right now. If we want to make advances I believe that we should rely more heavily on one key quality of the program code: It is meant to be executed.

Here are some ideas:

1. Time travel debugging. Reading a PR just like a wall of text is difficult, but what if you could step through the PR and see the state at a given line for some test executions? Time travel debugging can make this possible. You would collect a debug trace and use it to overlay the PR diff with additional controls and information to resemble a debugger's UI. I was part of the team behind Codetracer (https://github.com/metacraft-labs/codetracer) who is trying to work in this direction.

2. Test suites and coverage. We don't use them enough for understanding right now. The test suite encodes what features the code is supposed to have, and the coverage tells us where in the code those features are implemented. I'm playing with an idea about this here: http://atlas.vihren.dev When we intersect coverages for the different test cases we can arrive at code segments which represent "atomic behaviors" present in the code. They form a mathematical structure which can be represented as a graph. I am currently exploring what value we can extract from it for the benefit of both humans and agents.

I am using Go right now for personal projects. One such project is to collect per-test-case coverage data and use it to study the structure of the underlying codebase. I'm hoping to develop a new knowledge base for agents to do feature location. Here's a demo https://atlas.vihren.dev

Anyway, it turned out that Go ironically makes it difficult to collect per-test-case coverage data. In spite of the standardized tooling it looks impossible to write a standardized collector that would run on most codebases. In hindsight using another language would have been a better choice

If you are using Jujutsu you can achieve a basic way to maintain a public repo from a private monorepo with very little code and without Copybara. I wrote up how to do it here: https://vihren.dev/blog/20260625-jj-public-private-workflow/

Hi HN,

I wrote up a Jujutsu workflow that I came up with recently. I wanted to work on a public open-source repository while also versioning the private context files that influenced each public commit: specs, product notes, experiments, and agent instructions.

I use coding agents heavily, which means the specs are often as important as the final code. I wanted a proper way to manage them without making them reachable from public history.

Jujutsu’s features give us a compact solution based on filesets, revsets, and `git.private commits`. With a small amount of code, this achieves a public/private split without much heavier tools like Copybara.

This is advanced material. It assumes intermediate jj knowledge, especially around revsets. Let me know what you think.

This approach of solving a problem by building a low-perplexity path towards the solution reminds me of Grothendieck's approach towards solving complex mathematical problems - you gradually build a theory which eventually makes the problem obvious.

https://ncatlab.org/nlab/show/The+Rising+Sea

TLDR:

* Debugging takes 35%-50% of a developer's time

* In the study 79% of the time was spent on the top 26% of the bugs

* Fresh bugs appearing during ongoing work take 3 minutes to fix on average. Committed bugs appearing in the issue tracker take 29 minutes on average

* When running/testing during debugging sessions devs run the code manually (84%) rather than relying on automated tests

* When inspecting program state devs rely on looking at logs and print statements 70% of the cases and in only 30% use a debugger

It looks like the new Blockchain is quite centralized. 45% of blocks are mined by just two addresses: https://twitter.com/santimentfeed/status/1570339602346684416...