Mine doesn't. It mostly adds and keeps referencing previous decisions. Correctly, referring to them as being overridden. Even tweaking the original text or occasionally deleting a part. But text would look differently had it been written from scratch.
Unless a LLM works truly as a compiler, there will be a drift between the code and the spec.
The app's memory usage is an aggregation of the alloc/free events. I think the original point was that all of the metrics, traces and logs are conceptually the same but for efficiency, we store less data in each place, not the full history. Personally, for the systems I work on, having an easy way to turn logs into metrics and vice versa, without deciding up front, would be a slight benefit.
Because there are diminishing returns somewhere for sure. Will the developer be more effective when he gets $2,000 more in tokens? I can't max the $100 subscription. The same for any other employee-related expense. It's a no-brainer to give the developer a solid laptop. But if you'd pay extra $2,000/month in computer and office supplies costs, will it save the employee a few hours? I don't think so. Their salary doesn't matter that much.
> Can you tell me what is the budget necessary to supply AI tools capable of substantial research assistance to all academic staff at a university?
I think the GP meant that *if the tools provide substantial benefit* to staff, their costs can be compared to salaries and other large expenses of the university. The $100/month subscription costs less than your office space.
Why is vendoring frowned upon, really? I mean, the tooling could still know how to fetch newer version and prepare a changeset to review and commit automatically, so updating doesn't have to be any harder. In the end, your code and the libraries get combined together and executed by a computer. So why have two separate version control systems?
Vendoring doesn't entirely solve the problem with hidden malicious code as described in the article, but it gives your static analyzers (and agents) full context out of the box. Also better audit trail when diagnosing the issue.
The repository suddenly contains thousands of files that I need to worry about. With regular locked-dependencies (but non-vendored) like Cargo.lock does, I have them contained in archives with well-known hashes that other people have also looked at.
If I have to manually match the content of the vendor/ folder with the contents of the Cargo.lock referenced source code anyway, I could just use Cargo.lock directly without having to concern myself with the thousands of files in your vendor/ folder.
