GoLand’s Profiler Now Works With AI Agents

GoLand In our practical guide to profiling in Go, we mentioned that some of the Go developers we talked to avoid pprof if they can. For many of them, typical Go services perform well enough without optimizations, so when they do need to profile, it can feel like a “rescue mission” with a tool they are not really experienced with. They have to remember which profile to take and how to collect it, and then make sense of a lot of low-level data.

GoLand 2026.1.2 made the collecting part easier with a built-in profiler. In GoLand 2026.3, we are taking it a step further – your AI agent can now use that profiler too. You describe the symptom, for example, “reindexing through POST /reindex takes much longer than it should, profile it”, and the agent runs your app with the profiler, picks the profiles that fit the problem, reads the results, and points you to the code that is responsible. You do not need to know what a mutex profile is or which pprof flags to pass.

This works with Claude Code, Codex, and Junie through the bundled goland-profiler skill and a set of MCP tools. Below, we take a closer look at what the agent does and how you can split the work with it.

What happens when you ask the agent to profile your app? #

The goland-profiler skill tells the agent when to reach for the profiler, for example, for slow execution, high CPU usage, excessive allocations, memory growth, blocking, lock contention, or goroutine leaks. It also explains how to work with the MCP tools that give the agent access to GoLand’s profiler. A typical run goes like this:

1. Run with the profiler: If you have already started the app with the profiler, the agent reuses that run. Otherwise, it starts the app with the profiler using your run configuration, just as you would with theRun with Profiler button. The skill explicitly tells the agent not to addnet/http/pprof or any temporary profiling code, so your source code stays untouched. If it is unclear whether the app is doing what it should, the agent can also read its output.
2. Pick the profile: The skill instructs the agent to take the narrowest capture that answers the question. For CPU issues, that means recording while it runs a workload, such as a load generator, or taking a timed profile if the load is steady. For other problems, it takes a block profile for synchronization waits, a mutex profile for lock contention, or two heap profiles to compare when memory keeps growing. Allocs, goroutine, and goroutine leak profiles are available too.
3. Read the results: Each capture comes back with a summary of up to five of the hottest functions in your code, showing where their cost goes, which lines are the most expensive, and how they are reached. The agent starts from this summary and only asks for more detail – the top functions under a given root, the call paths to a function, or the most expensive lines in a function – when the summary is not enough.
4. Report the findings: The agent tells you what the main bottleneck is and how much it costs, which call path in your code leads to it, where the hot lines are, and whether it is CPU work, allocations, blocking, contention, or goroutine growth. It also suggests a fix or a further measurement, and it is instructed to separate what the profile shows from its own hypotheses. If you ask, it can make the change too.

Every profile the agent captures ends up in the profiler session and in Recent profiles in the Go Optimization tool window, just like the ones you capture yourself. If you want to double-check the agent’s conclusion, you can open the same profile and look at the flame graph.

MCP tools

What the agent can do with GoLand’s profiler

| Run the app with the profiler Starts and stops your app with the profiler, the same way the Run with Profiler button does. Your source code is not changed. run_with_profiler Launches a run configuration with the profiler enabled. list_profiled_runs Lists active and recently stopped profiled runs, including the ones you started from the IDE. get_profiled_run_output Returns the program output of a profiled run, such as the app’s logs. stop_profiled_run Stops the profiled application. | Capture profiles Saves captured profiles to the session and to Recent profiles , so you can open them in GoLand later. take_profile Captures a profile (a snapshot, or a CPU profile for a set duration) and returns it with a summary. start_cpu_recording Starts a CPU recording. stop_cpu_recording Stops the recording, saves the CPU profile, and returns a summary. | Read profiles Works with any profile – one the agent captured, one you captured, or the one currently open in the editor. list_profiles Lists session, recent, and currently open profiles. profile_summary Returns totals and the top 5 functions with their hot lines and call paths, for any saved profile. profile_top_frames Ranks functions by self or cumulative cost, similar to pprof -top . profile_call_paths Shows the call paths that lead to a given function. profile_source_lines Ranks the source lines of a function by cost, similar to pprof -list . |

How to split the work with the agent #

How much of the process you hand over is up to you. These are the three setups we have found most useful:

• The agent does everything: You describe the problem, and the agent handles the rest, from launching the app to explaining the results. This is a good option when you do not know where to start.
• You profile, the agent analyzes: You run the profiler yourself, open a profile, and ask the agent what it sees. The agent can read the profile that is currently open, so there is nothing to export or describe.
• You run the app, the agent captures: You start the app with the profiler and get it into the state you care about, for example, after a warm-up or with a production-like dataset loaded, and then ask the agent to take the profiles.

Workflows

Three ways to split the work with the agent

| The agent does everything Useful when you know something is slow but have no idea where to start. 1 You “Reindexing through POST /reindex takes much longer than it should. Profile the app and tell me why.” 2 Agent Loads goland-profiler , picks a run configuration, and callsrun_with_profiler . Your code stays as it is. 3 Agent Sends some load to the app, records CPU with start_cpu_recording andstop_cpu_recording , and takes a heap or allocs profile if the symptom points to memory. Each capture returns a summary with the hottest functions and call paths. 4 Agent If the summary is not enough, digs deeper with profile_top_frames ,profile_call_paths , orprofile_source_lines , then stops the app it launched. 5 Agent Explains what is slow and why, and can fix it if you ask. The profiles stay in GoLand, so you can open them and check. | You profile, the agent analyzes You stay in control of the run, and the agent helps you make sense of the profile you already have open. 1 You Run the app with the profiler, reproduce the slow request, and capture a profile the usual way. 2 You Open the profile. Something in the flame graph looks off, but you are not sure what. 3 You “Look at the open profile. Why are we allocating so much?” 4 Agent Finds the open profile through list_profiles , reads it withprofile_summary , and goes deeper withprofile_top_frames ,profile_call_paths , orprofile_source_lines if the summary is not enough. It reads the same profile you are looking at. 5 Agent Explains the hot path in terms of your code and suggests a fix. | You run the app, the agent captures You start the app with the profiler and get it into the state you care about, and the agent takes it from there. 1 You Start the app with the profiler and get it into the right state, for example, after a warm-up or with a production-like dataset loaded. 2 You “It is running with the profiler now. Capture goroutine and mutex profiles and tell me where the contention is.” 3 Agent Finds your run with list_profiled_runs , then callstake_profile for each profile type. 4 Agent Reads the profiles, checks them against the source code, and reports back. The app keeps running until you stop it. |

Current limitations #

• GoLand-started app: GoLand’s profiler modifies the executable during compilation to expose the profiling API, so it cannot be attached to an already running process. The agent either starts the app through a run configuration with the profiler or works with a session you started yourself.
• Short-lived programs: The profiler samples a running process, so a CLI tool that finishes in a fraction of a second does not leave enough time to capture anything useful. The skill works best for servers, workers, and other long-running services.
• Tested agents: We have tested the workflow with Claude Code, Codex, and Junie. Other agents that can connect to GoLand’s MCP server may work too, but we have not verified them yet.

How to try it #

1. Update to GoLand 2026.3 and open your project.
2. Make sure goland-profiler is enabled inSettings | AI | Skills . You can also restrict it to specific projects or turn it off there.
3. Ask your agent to profile your app, or open a profile you have captured and ask the agent what it sees.

Tell us what you think #

We hope this makes profiling something you can do as part of your everyday work, and not only when a service is already in trouble. If you have been avoiding the profiler, this might be a good time to give it a try.

We would love to hear how it works for you – which setup you end up using, whether the agent’s summaries are enough or you still open the flame graph, and which projects it does not work for. Feel free to tag us on X, drop into the #goland-gophers Slack channel, or create a ticket in our YouTrack issue tracker..

Happy coding,

The GoLand team

Subscribe to GoLang Blog updates