akoumjian

This is a great contest.

> never becomes superhuman

Arguably, we are already there. I think the idea of the intelligence not scaling far beyond what we have now is worth considering, though doubtful.

Where are you seeing this write up?

This is exactly what I wanted, love that the phone app has a native UI for agents like Pi instead of relying only on terminal renderers.

I think this is a neat idea. Is there a way to self-host the web app interface?

None yet. Any discoveries made with a possible impact risk would end up on the NEO Confirmation Page for follow up. As soon as an observation arc is long enough and gets a provisional designation, impact risks would be calculated and displayed at both NEOCC and JPL Sentry. We also do impact probability calculations and visualizations at Asteroid Institute.

The models only output text. Tool calls are nothing more than specially formatted text which gets parsed and interpreted by the inference server (or some other driver) into something which can be picked up by your agent loop and executed. Models are trained in a wide variety of different delimiters and escape characters to indicate their tool calls (along with things like separate thinking blocks). MCP is mostly a standard way to share with your agent loop the list of tool names and what their arguments are, which then gets passed to the inference server which then renders it down to text to feed to the model.

Celery is great and awful at the same time. In particular, because it is many Python folks' first introduction to distributed task processing and all the things that can go wrong with it. Not to mention, debugging can be a nightmare. Some examples:

- your function arguments aren't serializable - your side effects (e.g. database writes) aren't idempotent - discovering what backpressure is and that you need it - losing queued tasks during deployment / non-compatible code changes

There's also some stuff particular to celery's runtime model that makes it incredibly prone to memory leaks and other fun stuff.

Honestly, it's a great education.

I also started my career with Django using 0.96 in college and 1.1/1.2 with my first industry jobs. It was a really empowering framework and it is surprising to me that I still pick it up today for new projects when appropriate. I started attending the Seattle Django Users Group and discovered there were a decent number of "ex-pats" from the Lawrence Journal-World who were there as it was being developed.

Before I knew it I was helping organize the user group including our weekly coffee shop meetups in addition to the monthly lecture gatherings. There were a lot of local startups (including some very well known businesses and non-profits today) very actively collaborating on these tools. Django was really evolving the way a lot of companies used software and automation.

It wasn't only the engineering, the community ethos of Django both at the local and international scale (and the Python community as a whole) really made it possible to branch out and accelerate my personal software engineering journey.

I've been liking pdm as opposed to poetry, as poetry uses some non-standard syntax in the pyproject.toml file. I had a lot of trouble getting hatch environments to handle changes to default python versions and the like. I like how pdm played nicely out of the box with pyenv if you're using it, otherwise manages environments directly.

"Type ahead" or "autocomplete" is absolutely a different type of problem, and often simpler. This generally falls into the use case where the searcher already knows the specific item they are looking for. Often the results are objects owned by or known to the user in question, or you are searching through a very limited and relatively static set of documents and topics. Reference documentation for software often falls into this category.

In my experience, you don't have to spend a lot of time thinking about scoring and relevancy for these types of search. Generally you only want to include a small edit distance in the results at all to handle misspellings.

This is so vastly different when you have a corpus of millions of documents about an encyclopedia's worth of topics.

> I do wonder how much deep search really matters when people only really expect to look at the first page.

Getting the first page to have the best quality and relevancy is much more difficult if the user is searching through something like scientific papers, stock video footage. It is a challenge in bridging the distance between ideas and expectations.

Broad full text search is incredibly hard to do well. I've had to build, maintain, and improve multiple search systems. The difficulty is largely dependent on the context of the type of search problem you are solving. A lot of complexity depends on your answer to some of these questions:

  - Does the searcher already know the result they are looking for? (If yes, much easier)
  - Are there subjective and objective qualities of the results which should alter the search score, sometimes separate from the text being indexed? (If yes, much harder)
  - What is the quality of the text being indexed? (If end-user provided, this will vary widely)

Ultimately, building good search is often a struggle against providing the best possible results between searcher intent and incomplete document evaluation criteria. People never really think about when a search is working really well, but they definitely know and complain when it's working poorly.

The only purchase I've made on Wish was a similarly "too good to be true" set of flash drives. When I received them I tested them out on a linux live image and sure enough they were simply programmed to report having much more storage than they did. I did get a refund, but you can bet the products are still there.