sorobahn

Am working on making this layer currently. It’s a more interesting problem even when you remove AI agents from the picture, I feel a context layer can be equally as useful for humans and deterministic programs. I view it as a data structure sitting on top of your entire domain and this data structure’s query interface plus some basic tools should be enough to bootstrap non trivial agents imo. I think the data structure that is best suited for this problem is a graph and the different types of data represented as graphs.

Stitching api calls is analogous to representing relationships between entities and that’s ultimately why I think graph databases have a chance in this space. As any domain grows, the relationships usually grow at a higher rate than the nodes so you want a query language that is optimal for traveling relationships between things. This is where a pattern matching approach provided by ISO GQL inspired by Cypher is more token efficient compared to SQL. The problem is that our foundation models have seen way way way more SQL so there is a training gap, but I would bet if the training data was equally abundant we’d see better performance on Cypher vs SQL.

I know there is GraphRAG and hybrid approaches involving vector embeddings and graph embeddings, but maybe we also need to reduce API calls down to semantic graph queries on their respective domains so we just have one giant graph we can scavenge for context.

There is a pdf with a deslop prompt at the end of the article. Prob the skill definition you’re looking for.

I've had this same thought. Given humans were the primary authors of code, the tooling has optimized for writing (IDEs, Text Editors, LSPs, etc). Even though we all know we read more code than write, the tooling space for reading code is rather small, I can only think of stuff like SourceGraph and Github. I'm sure big companies have internal tooling for this, but even then I feel the best experience exploring a single repo today is your EDITor.

I'm also experimenting with building a platform that is optimal for reading code particularly distributed systems since they have many non-local dependencies and are harder to explore locally in code editors/viewers. I def fall in the camp that current AI tools can probably help us understand our systems better than they can contribute code to them. One win of using AI to help us analyze large codebases is that if they can extract useful things for us, they can also extract useful things for their own agentic loops.

Let me know if you wanna chat more about this, would love to bounce some ideas/contribute!

I’m actually interested in solving the documentation problem. Imo we as engineers are thinking too small and keeping docs as this side thing sounds like a recipe for irregular maintenance. Instead, what if docs were more like live blueprints of running systems? We don’t want obvious stuff documented like there is a function called foo, but foo’s relationship to other parts of the code and its runtime characteristics seem important. I think I’m imagining a different form of documentation that is tied with observability but that’s because I feel it’s information that’s far away from code currently and ideally I’d like all information derived from a piece of code to be available at the same place.

Probably slightly off topic but I’d be curious to hear what other people want out of automated systems in this space. I have so many half baked ideas and would love to hear what’s others think/want.

What were some of the pain points mentioned?

Experimenting applying Meta's V-JEPA [0] architecture for representation learning to chess. One of the challenges is that validating if the model is learning useful dynamics of the game, so I'm using it as an excuse to learn some reinforcement learning by using the representations generated by the JEPA model to approximate useful Q-values [1]. This method currently has no search so I'm planning on comparing with this paper [2] which achieves GM level chess without any search. Honestly, Im unsure if the full pipeline is stable enough to even converge, but it's fun experimenting. I'm bad at chess so I really want to make a bot that challenges the best bots on lichess.

[0] https://ai.meta.com/research/publications/revisiting-feature... [1]: https://en.wikipedia.org/wiki/Q-learning [2]: https://arxiv.org/abs/2402.04494

I feel like this is a really hard problem to solve generally and there are smart researchers like Yann LeCun trying to figure out the role of search in creating AGI. Yann's current bet seems to be on Joint Embedding Predictive Architectures (JEPA) for representation learning to eventually build a solid world model where the agent can test theories by trying different actions (aka search). I think this paper [0] does a good job in laying out his potential vision, but it is all ofc harder than just search + transformers.

There is an assumption that language is good enough at representing our world for these agents to effectively search over and come up with novel & useful ideas. Feels like an open question but: What do these LLMs know? Do they know things? Researchers need to find out! If current LLMs' can simulate a rich enough world model, search can actually be useful but if they're faking it, then we're just searching over unreliable beliefs. This is why video is so important since humans are proof we can extract a useful world model from a sequence of images. The thing about language and chess is that the action space is effectively discrete so training generative models that reconstruct the entire input for the loss calculation is tractable. As soon as we move to video, we need transformers to scale over continuous distributions making it much harder to build a useful predictive world model.

[0] https://arxiv.org/abs/2306.02572

A reference from the "Home-Cooked Software and Barefoot Developers" [0] post. I think the view of control on an axis where designers on one end and users on the other is very telling of the current state of software and my personal frustrations of it. When the incentives are misaligned and designers are optimizing for profit, we just get "industrial" grade software where the most reliable component is usually the payment screen.

[0] https://news.ycombinator.com/item?id=40633029

That's a fair point, but personally I feel the role of technology when it comes to distractions is downplayed if we are comparing to old school distractions like paper maps. Given how modern social media apps have basically hijacked out primal desire for social validation with a sprinkle of algorithmic engagement thrown in, it's a new level of addiction that people have to fight through boring commutes and slow traffic.

I can't think of any "traditional" distractions that demand the level of willpower needed to avoid phones while driving. I agree with you that it's not a new problem, but it definitely feels like it is growing at a faster rate due to the rise of phones though. Too many anecdotes of watching people driving full speed through intersections while on their phones these days.

  > His new home would cut into a mountainside just beneath an open space that taxpayers had bought for $64 million to fend off future development.
  > After many discussions of rules and regulations, city officials eventually cleared Prince’s plans. But a group of locals led by residents Eric and Susan Hermann have appealed, maintaining that his house would violate ordinances.

This is so cool! I looked at the transcript for day 5 [1] and realized how I learned the same thing regarding Rust strings not being indexable with integers due to them being a series of grapheme clusters. I didn't use ChatGPT and had to dig through the crate documentation [2] and look at stackoverflow [3], but Simon was able to get an equally great explanation by simply asking "Why is this so hard?" which I could relate to very much coming from C++ land. Now, the ability to trust these explanations is another issue, but I think it's interesting to imagine a future where software documentation is context aware to an individual's situation. The Rust docs are amazing and you can see they bring up indexing in the "UTF-8" section, but it requires me reading a section of the doc which I may not have realized was the reason for my frustration with a compiler error regarding indexing. Even if ChatGPT is not "intelligent" (whatever that means), its ability to take a context and almost act like an expert who's read every page of documentation that can point to you into a productive direction is very helpful.

[1] https://github.com/simonw/advent-of-code-2022-in-rust/issues... [2]: https://doc.rust-lang.org/std/string/struct.String.html#utf-... [3]: https://stackoverflow.com/a/24542502

I think this depends on the scale and type of the project, but it's good to get in the habit of codifying tests and setting up CI ASAP. It's basically scaling you pulling down code and running it. Now with containers, there isn't much of a reason to not have automated build checks and testing. Even when you have changes in a distributed environment, things like docker-compose make it much easy to create mocked CI environments with dbs, caches, etc. Also, CI helps me prioritize PRs when I have many to review. Being able glance at github to see which ones are mergeable immediately vs which ones may have other dependencies causing CI to break is great.

If you're working on some legacy codebase and don't have these luxuries, I totally get running it locally first. I am lucky to work with people who I do trust deeply to not waste others' precious time by testing first so there is probably also a human element for me.