dkn

Assuming the author had to input good points for the LLM to expand it into a full length post, just give me the points. Give both formats if one must. Translate, spellcheck, fix mistakes with an LLM. Don’t inflate 3 bullet points to a 10 minute read.

I can’t distinguish between well meaning slop and blogspam slop. I might be able to if I’m well informed on the topic and can point out inaccuracies. Otherwise I just don’t know what is accurate and what is filler or outright wrong. LLM-isms are very distracting and exhausting to sort through. It just doesn’t make for a good reading experience.

I have had a ton of success in exposing AST-based tools to agents when working in large, old codebases.

Without them, not only do agents get simple things like function call counts wrong, they tend to return different results. I use this as an example when showing people how the tooling works.

Grep is fine for simple use cases. A step up from that is ast-grep and I need to explore this tool more. But I had the most success building a small pipeline that reads the old code base, parses it file by file using tree sitter, and then loads it into a SQLite database for querying. For example, I have it capture construct definitions and usages and represent those as directed edges and nodes in a single table depending on the node type. The agent is instructed on how to query it and perform interesting queries like build call graphs, or determine dependencies between domains (modularity is not great in this codebase) which is helpful for us to extract around capability lines.

I also calculate fitness statistics, and have some code to capture specific details and knowledge about this very old framework that short circuits agent work in the future. We have some “interesting” magical libraries and functions that block static analyzers from going beyond the call site. This is mitigated, and means agents don’t have to “guess”.

Making all of this available to the different team members at my work has been pretty helpful. It’s faster (fewer tool calls), cheaper (fewer tokens), and accurate.

Yep, and wasted token spend on an ongoing basis.

I instruct the LLM to follow TDD practices in certain areas, but otherwise prioritize integration style tests at the edges.

I am curious in your experience how often the LLM must also update the tests. I find that if LLMs write tests after the implementation exists, they are either extremely brittle because they are coupled to the implementation, or they cover little of value because they mock everything to the point of testing nothing.

I question your assertion that more commits and releases per week is more productivity. There could be unexpected effects from your commits that create more work for you or for others and that could be hard to quantify.

Doing bad things faster might feel more productive to you, but it doesn’t mean that you are delivering more value. You might be, but the metrics you have shared to not prove that.

When deployed to Deno Deploy, KV is a wrapper around FoundationDB, selected for its use in the distributed/edge environments that Deno operates in. When used locally, it's a wrapper around SQLite.

The API is standardized for both.

Deno is not a programming language though. It's a JavaScript (TypeScript) runtime.

Deno is basically trying to be an infrastructure framework for JavaScript.

I think the parent poster is pointing out that there are more ways of discriminating traffic than just a domain name. Such as geographic location, device IDs, etc. All of which are commonly used.

It's not proof of what is being claimed, but they are variables that would need to be controlled before being confident that Douyin is or is not adjusting content to foreign or domestic users.

In Canadian provinces, bait fishing in streams is often illegal.

From the perspective of users of solar energy on Earth, wouldn't an increase over billions of years appear constant? My intuition tells me that evolution is much faster than that, and any fluctuations due to solar cycle dynamics would already be mitigated as expected by the same process, if it is indeed so regular.

Is this the same thing as... not pumping it?

I think this is a great summary, and also highlights much of what Joe Armstrong talked about when comparing Erlang to other OO languages, and his earlier decisions to design Erlang to work in the same way whether in a single-node or multi-node environment.

How else do you suppose all those AI efforts are fulfilled?

Sure but the real-life equivalent of that would be God telling Nike what kind of shoes you and your friend were talking about in secret.

They aren't forced to, they are trained to. The usage of a social network is innocuous at first.

Similarly, a person is not necessarily forced to start using narcotics to develop a dependency.