cagz

Exactly. As a software developer, AI has given me more time to tackle higher-order problems. The actual architecture, optimisation, and user experience.

Mathematicians could:

- Continue working on philosophical aspects of the solution and not bothered by whether the solution is known or not. It is not a movie that gets spoiled when the ending is known.

- Or better, demand from AI labs, how they would like to see AI helping them on philosophical aspects.

The article starts interestingly; I like the analogy between cold reading and LLM responses (well, the ones we were getting three years ago). Then it goes on to generalise to the tune of "This new era of tech seems to be built on superstition and pseudoscience" which I think was a conclusion better left to the reader.

We are used to articles, blogs that stayed relevant for years. It is hardly the case with AI, the speed of change is so high that an observation can become stale in a year. This makes it very important for articles to state that the ideas are based on the technology in year X, rather than generalising them as universal truths.

The title feels clickbaity. Direct API, CLI and MCP all have their uses.

Direct access (Curl/own small function): This requires agent to have full understanding of the API spec. Yes, context can be protected using progressive disclosure, but this essentially means agent needing to understand the API again and again, before every use. Also, a typical API spec may or may not be agent-friendly. If there are nuances when calling an endpoint, where do we put these? Into OAS description? Works, but clunky.

CLI: It works beautifully, especially when a 3rd party CLI already exists for a complex backend. Assumes a well documented, agent friendly CLI, most CLIs are designed for human or CI/CD consumption. Talking about MCP taking up too much context, think about agent starting with my_cli --help, and going down through the switches and parameters one at a time to figure out how the CLI should be called. Less of a problem when calling a well know CLI (e.g. aws), but anything more niche (or custom) requires multiple turns to compose the final CLI command.

MCP: Has its issues, but offers an agent-native solution. Everything agent needs to know about a tool becomes available at once. In an enterprise environment MCPs can be served through an MCP Gateway, providing governance and permission management, this is quite contrast against running a CLI that requires agent to have execute permissions in its shell.

A very poor, word-by-word copy of https://mathandai.org

I wish this were a document that clearly described how mathematicians expect AI to behave, rather than how it is misaligned. I can kind of decipher the expectation from the declaration, but it still sounds a bit like "it would be better if AI didn't meddle with mathematics", instead of "we want AI to approach problems like this and that way".

Yes, quite a few uses in prod, main use case being abstracting API access for agents. In our case these are mostly in-house MCP servers, purpose built for the given agent.

Why MCP instead of CLI or agent accessing API directly?

Direct access (Curl/own small function): This requires agent to have full understanding of the API spec. Yes, context can be protected using progressive disclosure, but this essentially means agent needing to understand the API again and again, before every use in that context. Also, a typical API spec may or may not be agent-friendly. If there are nuances when calling an endpoint, where do we put these? Into OAS description? Works, but clunky.

CLI: It works beautifully, especially when a 3rd party CLI already exists for a complex backend. Assumes a well documented, agent friendly CLI, most CLIs are designed for human or CI/CD consumption. Talking about MCP taking up too much context, think about agent starting with my_cli --help, and going down through the switches and parameters one at a time to figure out how the CLI should be called. Less of a problem when calling a well know CLI (e.g. aws), but anything more niche (or custom) requires multiple turns to compose the final CLI command.

MCP: Has its issues, but offers an agent-native solution. Everything agent needs to know about a tool becomes available at once. In an enterprise environment MCPs can be served through an MCP Gateway, providing governance and permission management, this is quite contrast against running a CLI that requires agent to have execute permissions in its shell.

I must mention that we also utilise lazy-loading of MCPs. In use cases where 10s of tools needs to be loaded, only the most common ones are pre-loaded, then agent kernel connects the others as an when needed, and release them after a timeout (in case of long running sessions). This keeps the context lean.

It is BTP, not London Underground, they are not the same thing.

Outages happen. What concerned me most was the time taken for the full resolution (almost 12 hours). I am hoping that root cause analysis promised will look into this as well and how it can be improved.

Is the 1/10+ reduction in memory usage applicable to larger models, i.e. would be possible to run a 200Gb model, by using 20Gb of memory?

I couldn't help noticing on the screenshot that user having direct access to a production database from their laptop :)

My workflow is: - Write the test first, confirm it fails - Write the minimum code to make that test pass - Confirm it is green

Would be nice to see the actual % token/time saving across end-to-end coding sessions over these time periods https://github.com/MinishLab/semble#savings

My observation is that greps and the processing of grep outputs account for only a small portion of overall consumption; I haven't measured this scientifically though.

I like how far mature adulthood goes :) One never gets old.

Getting frustrated by not having RAG solutions able to answer schematic questions such as "how many X are there", I've created DuoRAG: https://github.com/cagriy/duo-rag

It maintains a vector store and a SQL database. While vector store supports usual RAG operations, the ones that require counting, summation, selection are routed to the SQL database.

There is an option to start with an initial schema, or let it discover the schema itself. Then on the day to day use, if a user query cannot be responded, a candidate schema entry is created to be populated on the next backfill run.

So in actual use, user asks the question such as "Give me the list of people who are scientists". If it is not in the schema, LLM suggest checking it later. Backfill runs at night. Next day it can answer the same question without issues.

Nice tech read, but without information about which companies, doing what, just feels way too click-baity.

I found the idea very interesting but put off a little bit by the various details such as face normals etc (have limited knowledge of the topic). Here are few ideas to increase adoption:

- Sample files

- A video of end-to-end process of creating a basic model (perhaps something more complex than a cube) from 3d design to finished artefact.

- Support for STL

- Built-in option to adjust (reduce) face counts

I am a big fan of MAUI, but I'd really wish they fixed existing issues instead of extending it further. 3.9k open issues and counting. I've got 5 open, verified bugs, some from 2023 :(

It is perhaps my eyes, but when I zoom in enough to make it readable, it gets blurry. A higher-res image would be much appreciated. Great idea otherwise.

> No one is formally verifying the result

This might be the case for a hobby project or a start-up MVP being created in a rush, but in reality, there are a few points we may want to take into account:

1. Software teams I work with are maintaining the usual review practices. Even if a feature is completely created by AI. It goes through the usual PR review process. The dev may choose "Accept All", although I am not saying this is a good practice, the change still gets reviewed by a human.

2. From my experience, sub-agents intended for code and security review do a good job. It is even possible to use another model to review the code, which can provide a different perspective.

3. A year ago, code written by AI was failing to run the first time, requiring a painful joint troubleshooting effort. Now it works 95% of the time, but perhaps it is not optimal. Given the speed at which it is improving, it is safe to expect that in 6-9 months' time, it will not only work but will also be written to a good quality.

I understand the argument, and there are some really good points.

My biggest concern would be that adopting the CLI method would require LLM to have permission to execute binaries on the filesystem. This is a non-issue in an openclaw-type scenario where permission is there by design, but it would be more difficult to adopt in an enterprise setting. There are ways to limit LLMs to a directory tree where only allowed CLIs live, but there will still be hacks to break out of it. Not to mention, LLM would use an MCP or another local tool to execute CLI commands, making it a two-step process.

I am a supporter of human tools for humans and AI tools for AI. The best example is something like WebMCP vs the current method of screenshotting webpages and trying to find buttons inputboxes etc.

If we keep them separate, we can allow them to evolve to fully support each use case. Otherwise, the CLIs would soon start to include LLM-specific switches and arguments, e.g., to provide information in JSON.

Tools like awscli are good examples of there LLM can use a CLI. But then we need to remember that these are partly, if not mostly, intended for machine use, so CI/CD pipelines can do things.

I think their intention is not mining your data (easily opt-outable) or hoping that you maintain the subscription after 6 months. It is rather making large open source project maintainers give AI a proper go.

Believe it or not, there are still a large amount of great tech professionals out there who are sceptical about AI. Many tried AI a year ago and has the impression that "It was alright but had limitations". AI came a long way since then, and it is going to improve even faster over the next 6 months. So this is Anthropics invite for you to join that journey.

In turn, of course this fuels the adoption by superstars (maintainers) endorsing the models.

The use of data for model training is a simple toggle, very easy to opt out of during the initial setup.

Also, the end product is open source anyway, so there is no case of IP being leaked into training data. What remains is that they can use, with your permission, the overall coding practices of a great programmer to fine-tune Claude's code and models. As in, how one approaches planning or troubleshooting. Is this a bad thing? Perhaps every maintainer should decide for themselves whether they want to contribute back or not.

Assuming they've got reasonable programming skills. They can simply find an open-source project they are passionate about. Spend time understanding the overall structure. Then pick up an issue raised by the community and prepare a fix as a pull request.

The first PR is unlikely to be merged the next day; however, it sparks lots of productive discussions with the rest of the community, allowing your kid to build a mental model of the project's best practices and sensitivities.

The more he contributes, the more integral he becomes to the community. After gaining enough experience through small issues, they can even consider working on a new feature.

As a byproduct, a great addition to the CV if they are also looking to go commercial.