AI Feature: Semantic Object inspection + Explanation of complex objects #8

tichmangono commented 2025年12月14日 15:22:51 +01:00

Semantic Object inspection + Explanation of complex objects - a lot of the docstrings etc. during inspection are gibberish to most people and they dont know what it means. So use Ai to bridge this gap. A lot of folks are vibe coding and get turned off by terminals and docs. Need to make the docs more accessible and semantic, less annotations more normal words and what they mean for the project. This could be a layer on top of the existing computer science oriented docs

Semantic Object inspection + Explanation of complex objects - a lot of the docstrings etc. during inspection are gibberish to most people and they dont know what it means. So use Ai to bridge this gap. A lot of folks are vibe coding and get turned off by terminals and docs. Need to make the docs more accessible and semantic, less annotations more normal words and what they mean for the project. This could be a layer on top of the existing computer science oriented docs

sczi commented 2025年12月15日 04:23:28 +01:00

I don't fully understand what you mean. Do you have some examples of complex objects and the explanation that an AI would provide?

On a related idea, I think all the information I gather through runtime introspection for the slime-help pages, could be provided to an LLM. Then instead of browsing through pages of documentation looking for how to do something, a user could just prompt "I have this object, how can I do some task with it?" and the llm can inspect the object, inspect its methods, documentation, the libraries' source and examples and documentation etc as needed, and just generate a snippet to do what the user wants.

I don't fully understand what you mean. Do you have some examples of complex objects and the explanation that an AI would provide? On a related idea, I think all the information I gather through runtime introspection for the slime-help pages, could be provided to an LLM. Then instead of browsing through pages of documentation looking for how to do something, a user could just prompt "I have this object, how can I do some task with it?" and the llm can inspect the object, inspect its methods, documentation, the libraries' source and examples and documentation etc as needed, and just generate a snippet to do what the user wants.

tichmangono commented 2025年12月16日 01:23:40 +01:00

Here's are a few examples, but can be even more informative if the AI is tacking your work, functions and goals:

EXAMPLE 1.

Computer gibberish (to some)

<sqlalchemy.engine.base.Connection object at 0x7f3b2c1a5d90>
Attributes:
_dbapi_connection: <sqlite3.Connection object at 0x7f3b2c1a5e10>
_execution_options: immutabledict({})
_transaction: <sqlalchemy.engine.base.RootTransaction object>
closed: False
invalidated: False
info: {}

Semantic explanation:

AI semantic layer:

"This is an active database connection to SQLite. The connection is open and healthy (not closed or invalidated). There's currently a transaction in progress that hasn't been committed yet — if your code exits without calling commit(), changes will be lost. The empty info dict means no custom metadata has been attached to this connection."

EXAMPLE 2.

Computer gibberish (to some)

ndarray: shape=(1000, 4), dtype=float64
[[0.234, nan, 0.891, 0.445],
[0.112, 0.334, nan, 0.221],
...]

Semantic explanation:

AI semantic layer:"This is a dataset with 1000 rows and 4 features. Warning: 23 cells contain NaN values, concentrated in columns 1 and 2. If you pass this to most ML models, it will fail. Consider using np.nan_to_num() or sklearn.impute.SimpleImputer before proceeding."

Here's are a few examples, but can be even more informative if the AI is tacking your work, functions and goals: EXAMPLE 1. Computer gibberish (to some) ---- <sqlalchemy.engine.base.Connection object at 0x7f3b2c1a5d90> Attributes: _dbapi_connection: <sqlite3.Connection object at 0x7f3b2c1a5e10> _execution_options: immutabledict({}) _transaction: <sqlalchemy.engine.base.RootTransaction object> closed: False invalidated: False info: {} Semantic explanation: ---- AI semantic layer: "This is an active database connection to SQLite. The connection is open and healthy (not closed or invalidated). There's currently a transaction in progress that hasn't been committed yet — if your code exits without calling commit(), changes will be lost. The empty info dict means no custom metadata has been attached to this connection." EXAMPLE 2. Computer gibberish (to some) ---- ndarray: shape=(1000, 4), dtype=float64 [[0.234, nan, 0.891, 0.445], [0.112, 0.334, nan, 0.221], ...] Semantic explanation: ---- AI semantic layer:"This is a dataset with 1000 rows and 4 features. Warning: 23 cells contain NaN values, concentrated in columns 1 and 2. If you pass this to most ML models, it will fail. Consider using np.nan_to_num() or sklearn.impute.SimpleImputer before proceeding."

tichmangono commented 2025年12月16日 01:25:01 +01:00

Yes, and the ida of asking "what can i do with this?" is great as well. that's what I meant by further layers once the LLM has your context and objects for that session.

Yes, and the ida of asking "what can i do with this?" is great as well. that's what I meant by further layers once the LLM has your context and objects for that session.

sczi commented 2025年12月20日 16:22:40 +01:00

Interesting, I agree the raw attributes of a class is often not a clear way of presenting the information we want. Longer term the direction I want to take the object inspector in is how the smalltalk folks do it. In their inspector they have different "views" of any object, which can be things like lists, tables, even graphical views with animations and so on. And they've built up a huge library of view functions, so you can create custom views for your objects with very little code. So the raw attributes would be just one view you can select, the AI semantic explanation could be another, and the AI could probably even write custom views and get it right a lot of the time, with the developer being able to edit the code for the custom view if needed.

Interesting, I agree the raw attributes of a class is often not a clear way of presenting the information we want. Longer term the direction I want to take the object inspector in is how the [smalltalk folks do it.](https://www.youtube.com/watch?v=N0XSImxyszM) In their inspector they have different "views" of any object, which can be things like lists, tables, even graphical views with animations and so on. And they've built up a huge library of view functions, so you can create custom views for your objects with very little code. So the raw attributes would be just one view you can select, the AI semantic explanation could be another, and the AI could probably even write custom views and get it right a lot of the time, with the developer being able to edit the code for the custom view if needed.