sorobahn

As a w2 earner, taxes make me feel shame and rage. Shame knowing how ineffectively my taxes will translate into helping my fellow Americans/my communities/my grandchildren. The rage is for the realization that the most valuable people in our society (our doctors, engineers, small-med business owners) are the ones mainly footing the bill for select greedy and power hungry politicians. I’ll admit I haven’t validated if this is empirically true based on the numbers. It’s just feelings that come up looking at my daughter and knowing some of my taxes probably blew up an entire school of little girls who aren’t much different than her.

Spent a bad amount of time on this! Thanks for making it!

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?

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.

Think this is the source of the concern for some of the locals initially. The rest I feel is the bad response to the criticism the project was getting.

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.