Thesis: Interesting work is less amenable to the use of AI

This can be a perfectly valid argument for many reasons. Their use case isn’t well documented, can’t be publicly disclosed, involves APIs that aren’t public, or are actual research and not summarizing printed research to name a few I’ve run into myself.

This argument that “engineers are boring and afraid for their jobs” is ignoring the fact that these are usually professionals with years of experience in their fields and probably perfectly able to assess the usefulness of a tool for their purposes.

To clarify my process. 1) I have a problem in a new domain that I'm stuck on. 2) I work with the LLM to discuss my problem, think about solutions, get things to try. Not unlike StackOverflow or digging through documentation. However this process is much faster and I learn more without being called stupid by random people on SO (or HN). 3) The problem is fixed and I move on, or back to 1 or try something else.

The value here is that I have a problem to solve and I'm seeing it through to the end. I know what good looks like and have the agency and attention span to get there. The LLM doesn't and likely won't for quite some time.

  #### /ask What would you refactor from main.py?

  #### What would you refactor from main.py?

  Based on the provided `main.py` file, here are some potential areas for refactoring:

  1. \*Separation of Concerns\*: The `run()` function is responsible for initializing the simulation and running it. This could be separated into two functions: one for initialization (`init_simulation()`) and another for running the simulation (`run_simulation()`).

  2. \*Code Duplication\*: There are several places where similar code is repeated, such as in the `Market_v1` and `Market_chaos_v1` classes. These can be refactored into a single class or function.  // LOL no, these two classes exist for a very different reason, and have very different code.

  3. \*Error Handling\*: The error handling for the `TimeElapsed` event is not robust enough. It should handle cases where the time elapsed is less than zero or exceeds a certain threshold.  // Negative time elapsed? Are we time-traveling? Where is my time DeLorean?

  4. \*Logging\*: The logging functionality could be improved by adding more detailed logs and making it configurable.

  5. \*Testing\*: The test functions in `TestBS` and `TestBS2` are repetitive and could be refactored into a single test function that handles different scenarios.  // This is outside main.py

  6. \*Code Readability\*: Some of the code is quite verbose, which can make it harder to read and maintain. Refactoring can help improve readability by simplifying complex logic or breaking down large functions into smaller ones.

  7. \*Configuration\*: The simulation parameters are hardcoded in `main.py`. It would be better to allow these parameters to be configurable through command-line arguments or a configuration file.

  8. \*Error Handling for Market Orders\*: The error handling for market orders is not robust enough, especially when dealing with negative amounts or invalid asset types.  // LOL, you have never shorted the market, haven't you?

  9. \*Logging and Debugging\*: The logging and debugging information could be more detailed and easier to understand.

  10. \*Code Organization\*: The code can be organized into modules or packages to improve maintainability and scalability.

  These are just a few potential areas for refactoring. Depending on the specific requirements and constraints of your project, you may want to focus on different aspects of the code.

  > Tokens: 12k sent, 405 received.

  #### /ask how would you organize the code in modules?

  #### how would you organize the code in modules?

  Organizing code into modules can improve maintainability, scalability, and readability. Here are some steps you could take to refactor `main.py` into modules:

  1. \*Create a Module for Simulation Initialization\*: Create a new module named `simulation.py`. This module will contain the `init_simulation()` function that initializes the simulation.

  2. \*Create a Module for Market Classes\*: Create a new module named `markets.py`. This module will contain the `Market_v1`, `Market_chaos_v1`, and any other market-related classes.

  3. \*Create a Module for Logger\*: Create a new module named `logger.py`. This module will contain the `Logger` class.

  4. \*Refactor Main Function\*: Move the `run()` function into the `simulation.py` module, as it is responsible for initializing and running the simulation.

  5. \*Organize Other Functions\*: Move any other functions that are not directly related to simulation initialization or market classes into their respective modules.

  6. \*Use Import Statements\*: Use import statements in your main file (`main.py`) to import the necessary functions and classes from these modules.

  Here's a basic example of how you might structure the code:

  ### `simulation.py`
  ```python
  from markets import Market_v1, Market_chaos_v1
  from logger import Logger

  def init_simulation():
      # details omitted
  ```

  ### `markets.py`
  ```python
  from dataclasses import dataclass

  @dataclass
  class Stock:
      pass

  @dataclass(unsafe_hash=True)
  class Option:
      strike: int
      type: str  # 'c' or 'p'
      expiration: int

  @dataclass
  class MarketOrder:
      amount: int
      asset: object  # Union[Stock, Option]  # Why did you replace my type?

  @dataclass
  class Quote:
      price: float

  @dataclass
  class TimeElapsed:
      current_time: float

  class Simulator:
      # details omitted
  ```

  ### `logger.py`
  ```python
  from dataclasses import dataclass

  @dataclass
  class Stock:
      pass

  @dataclass(unsafe_hash=True)
  class Option:
      strike: int
      type: str  # 'c' or 'p'
      expiration: int

  @dataclass
  class MarketOrder:
      amount: int
      asset: object  # Union[Stock, Option]  # Why did you replace my type?

  @dataclass
  class Quote:
      price: float

  @dataclass
  class TimeElapsed:
      current_time: float

  class Logger:
      # details omitted
  ```

  ### `main.py`
  ```python
  from simulation import init_simulation

  def run(start_time=0, end_time=6, increment=0.1):
      # details omitted

  def main():
      # details omitted

  if __name__ == '__main__':
      #import cProfile
      #cProfile.run('main()')
      main()
  ```

  By organizing the code into modules, you can make it easier to manage and maintain. Each module will have a clear responsibility, making it easier to understand and work with the codebase.

  > Tokens: 13k sent, 850 received.

  #### /ask why are some dataclasses in the logger.py module in your proposal?

  #### why are some dataclasses in the logger.py module in your proposal?

  In the proposed refactoring of `main.py`, the `Logger` class is defined in its own module named `logger.py`. This is because the `Logger` class is not directly related to the simulation or market classes, and it has no dependencies on any other parts of the codebase.

  By placing the `Logger` class in a separate module, you can keep the main logic of the simulation and market classes focused on their respective responsibilities. This separation also makes it easier to manage and maintain the codebase, as each module is responsible for a specific aspect of the application.

  Additionally, by keeping the `Logger` class in its own module, you can reuse it across different parts of the application if needed, without having to duplicate the code.

  > Tokens: 14k sent, 150 received.

  #### /ask Can you put only the logging classes in logger.py?

  #### Can you put only the logging classes in logger.py?

  Certainly! If you want to keep only the logging-related classes in `logger.py`, you can modify the structure as follows:

  ### `logger.py`
  ```python
  from dataclasses import dataclass

  @dataclass
  class Stock:
      pass

  @dataclass(unsafe_hash=True)
  class Option:
      strike: int
      type: str  # 'c' or 'p'
      expiration: int

  @dataclass
  class MarketOrder:
      amount: int
      asset: object  # Union[Stock, Option]

  @dataclass
  class Quote:
      price: float

  @dataclass
  class TimeElapsed:
      current_time: float

  class Logger:
      # details omitted
  ```

  ### `simulation.py`
  ```python
  from markets import Market_v1, Market_chaos_v1
  from logger import Logger

  def init_simulation():
      # details omitted
  ```

  ### `main.py`
  ```python
  from simulation import init_simulation
  
  def run(start_time=0, end_time=6, increment=0.1):
      # details omitted

  def main():
      # details omitted

  if __name__ == '__main__':
      #import cProfile
      #cProfile.run('main()')
      main()
  ```

  In this refactoring, the `Logger` class is moved to its own module, and only the necessary classes from `markets.py` are imported into `simulation.py`. This keeps the `logger.py` module focused solely on logging-related functionality.

  > Tokens: 14k sent, 429 received.

You might start to get useful results if you bump up to the 20B range - Mistral 3/3.1/3.2 Small or one of the ~20B range Gemma 3 models. Even those are way off the capabilities of the hosted frontier models though.

They can’t generate knowledge that isn’t in their corpus and the act of prompting (yes, even with agents ffs) is more akin to playing pachinko than it is pool?