Steve Southwell (Progress) asked a question.

May 29, 2026 at 1:19 PM
Using Claude Code extension in VS Code with OpenEdge AI Assistant

I found a minor issue yesterday when trying out Claude Code extension in VS Code using OpenEdge AI Assistant. Basically, if Claude Code does happen to get some syntax wrong, it lacks the integration with VS Code to retrieve the errors and warnings from the "PROBLEMS" tab that VS Code uses to show errors.

When I'm using AI to help write code, I like it to check that there are no errors before it thinks it's done.

 

As a workaround, I created this "diagnostics_mirror" VS Code extension that basically watches the diagnostics and mirrors them into files that Claude Code is able to read.

 

Once you install the plugin, you can tell Claude to use it:

  1. Please create a memory that diagnostics from the VS Code IDE are available in the .ai/problems/ folder: .ai/problems/current-file.json — diagnostics for the currently open file and .ai/problems/all-problems.json — diagnostics across the entire workspace. Check these files when the user asks "what does diagnostics say?" or asks about errors/warnings in the IDE. Whenever you edit code, you should save the file, wait at least one second to allow it to be built, then check the diagnostics to ensure it compiled correctly with no errors or warnings.

If you're using Claude Code, give it a try and let me know how it works for you.

 

  • 3 answers
  • 415 views
Keerthy Yeddula, Mike Fechner, and 2 others like this.

  • Mike Fechner (Consultingwerk)

    Nice idea. I'm documenting ANT scripts in Claude.md

     

    That way Claude can compile modified or all files (depending on scope) or wipe all r-code for large changes.

     

    I typically use Claude outside of the IDE. That leaves the IDE for me to analyze code for the next tasks while Claude is working. I leat Claude typically work on whole tickets start to finish, reading the ticket, creating the feature branch, implementing, unit testing, PR, documentation.

     

    1. ### Developer Build (build-dev.xml)
    2.  
    3. The `sclant` wrapper lives at `../Scripts/sclant.cmd` (the `Scripts/` folder sits next to this `ABL/` folder). It is **not on `PATH`** - invoke it via the relative path. **Do not search for it, do not call it from PowerShell, do not use a fully qualified `C:\...` path.** The exact commands to run from this `ABL/` folder are:
    4.  
    5. ```bash
    6. # Compile only modified files (try this first)
    7. ../Scripts/sclant.cmd -f build-dev.xml build-modified
    8.  
    9. # Compile all files (slower, use when build-modified is not sufficient)
    10. ../Scripts/sclant.cmd -f build-dev.xml build-all
    11.  
    12. # Wipe all r-code before a full rebuild (required when modifying central base classes or interfaces)
    13. ../Scripts/sclant.cmd -f build-dev.xml clean
    14. ```

    And

    1. ### Running a single SmartUnit test class via Ant
    2.  
    3. To execute a single Unit Test class from this `UnitTests/` folder, use the `UnitTests` target in `build-dev.xml`. Same rule as for the build wrapper above: invoke `../Scripts/sclant.cmd` via the relative path - **do not search for it, do not call it from PowerShell, do not use a fully qualified `C:\...` path.**
    4.  
    5. ```bash
    6. ../Scripts/sclant.cmd UnitTests -f build-dev.xml -Dtestclass=<test class name>
    7. ```
    8.  
    9. For example:
    10.  
    11. ```bash
    12. ../Scripts/sclant.cmd UnitTests -f build-dev.xml -Dtestclass=Consultingwerk.OeraTests4.SCL5229.TestClass
    13. ```
    14.  
    15. After the run completes, the results are written to `results.xml` (JUnit XML format). Parse that file and present the contents as a formatted table (one row per test case, showing class, test method, status - passed / failed / error / skipped - duration, and on failure the failure message). When unit tests are failing, attempt to fix the code under test (or the test itself, if the test is wrong) to resolve the failures, then re-run the same command to confirm.