The approach I’ve been taking lately with general AI development:
1. Define the work.
2. When working in a legacy code base provide good examples of where we want to go with the migration and the expectation of the outcome.
3. Tell it about what support tools you have, lint, build, tests, etc.
4. Select a very specific scenario to modify first and have it write tests for the scenario.
5. Manually read and tweak the tests, ensure they’re testing what you want, and they cover all you require. The tests help guardrail the actual code changes.
6. Depending upon how full the context is, I may create a new chat and then pull in the test, the defined work, and any related files and ask it to implement based upon the data provided.
This general approach has worked well for most situations so far. I’m positive it could be improved so any suggestions are welcome.
OpenTelemetry (OTel) and the OpenTelemetry Protocol (OTLP) are immensely powerful tools. The ability to emit telemetry data from any source, coupled with a receiver that can sample, filter, pipe, and potentially reshape the data to suit any need, is a game changer. This flexibility revolutionizes how we approach observability and monitoring across diverse systems.
1. Define the work.
2. When working in a legacy code base provide good examples of where we want to go with the migration and the expectation of the outcome.
3. Tell it about what support tools you have, lint, build, tests, etc.
4. Select a very specific scenario to modify first and have it write tests for the scenario.
5. Manually read and tweak the tests, ensure they’re testing what you want, and they cover all you require. The tests help guardrail the actual code changes.
6. Depending upon how full the context is, I may create a new chat and then pull in the test, the defined work, and any related files and ask it to implement based upon the data provided.
This general approach has worked well for most situations so far. I’m positive it could be improved so any suggestions are welcome.