DEV Community: Sebastian Aburto

I'm Not Coding Anymore, and That Is Ok

Sebastian Aburto — Tue, 14 Jul 2026 19:51:02 +0000

I am a hands-on software engineer with more than 17 years of experience, and I no longer write code. Yet, I still deliver software on a daily basis. I fix bugs, do analysis, design systems, implement new features, and test my changes.

For the actual coding, I have become the guide for my agentic coding tools. My responsibility is to give them the necessary context to make the changes. I define the acceptance criteria using deterministic verification, and I review the evidence to check the completeness and accuracy of the results.

Guiding like a junior programmer, but forever

Some people say that LLMs are like junior programmers because you have to give them proper guidance about everything. This analogy is true up to a certain point. The main difference is that a human junior developer becomes an expert over time. They make better decisions after making several mistakes, they generate trust within the team, they develop pride in their work, and eventually, they mentor and coach other developers.

But LLMs are in a perpetual juniorhood. You need to make sure their agents always have access to the necessary context, and that this context is real and updated. The agent needs access to the right tools in a secure environment, and it might need your assistance at any minute during the task.

Managing the context

As a human, I need to retrieve the necessary information to start working on a task. Because this task is part of a system, I need to understand how the system works and what its functionality is. If I am already familiar with the system, I don't need to do much analysis. I just confirm the outcome I need to accomplish, understand the acceptance criteria, and make sure I have enough information to start the implementation.

Sadly, agent tools do not yet have the skill to read minds, so I must facilitate the discovery of the context. This context could be in a spec.md or agent.md file, a ticket that the agent can access using an MCP server, a README.md, or just directly in your prompt.

The environment where the agent runs is also important. It could be your laptop, a server, a Docker container, or a sandbox. Wherever it runs, the environment must mitigate security risks. You need to provide deterministic restrictions, like blocking internet access, restricting it from reading other folders, and managing repository access (for example, denying pushes to main).

Finally, it needs access to the right tools, MCPs, and skills. If you are working on a backend task, you probably don’t need a Playwright MCP. Try to avoid bloating the context with too many skills; make sure you only enable the right ones for the specific task.

Avoid MCP servers as much as possible and prefer CLI tools. For example, use playwright-cli, jira-cli, gh, glab, etc.

From human trust to hard evidence

Verify everything from LLMs

You can’t trust LLM results. They are non-deterministic. Even if you give them the perfect context, you can’t assume everything was done following the rules. Mistakes happen, and they will keep happening.

The way you verify the results depends on the context. It can vary from running automated tests and Playwright tests, to looking at screenshots and test results. Maybe you need ad-hoc reports showing the impact of the change in a development environment, or you need to run some manual steps. It changes depending on the nature of the task.

I only review the code after the agent does its own code review. If there is something I can really improve in the implementation, I leave a comment to guide the agent to make it better.

Later, you need to validate the results live in production, exactly the same way you would if you changed the code manually. You can also use the agent to help monitor that.

The last step is doing a retro. Save the important learnings. Maybe there was a common error that should become a new rule or a new deterministic tool to verify next time. This makes your next session faster and more token-cost effective.

Overview of a common workflow for a development task

You can't blame the LLMs

Good software design, low coupling, high cohesion, high-quality code, and simplicity are still vital. Everything you already know about software engineering is still important. You are the human in charge. You make the decisions. Maybe you don’t craft the code line by line, and maybe you don’t review every single line, but you still need to ensure your output has high quality.

[!WARNING]
LLMs are not stable yet. Some days you get good results, but some days, especially right before a new model release, you can't believe how dumb they become. I hope model providers improve transparency about the real status of their services. The key is to have multiple providers ready as backups.

Conclusion

Since the start of 2026, I have not produced a single line of code by hand. I rely completely on agentic coding tools powered by LLMs. I focus my effort on making sure these tools have enough context, and I take care to never trust the results they give me. Producing code now is cheaper, but producing high-quality software faster is not yet cheap. I still spend significant time verifying and validating the results. There is no silver bullet yet. I am still learning, and I am still trying to find better ways to develop software.

Java Command-Line Debugging with AI Agent

Sebastian Aburto — Sun, 07 Jun 2026 10:36:46 +0000

When you need to track down a complex bug, your first instinct is to reach for a visual debugger. You set a breakpoint, step through the logic, and inspect the stack trace. But in an era of agentic coding, IDEs and visual debuggers are a bottleneck.

IDEs and their visual debuggers in the agentic coding era are not an option anymore 🙅

The best next option is adding some logs as breadcrumbs to try to understand what is happening

void processPayment() {
    System.out.println("Entering processPayment()");
    // ...
    if (isValid) {
        System.out.println("Processing valid payment: " + paymentId);
    }
}

It is a natural approach, but the feedback loop is slow in Java. Each change means compiling, packaging, and running again, or at best, a hot-reload. You make many code modifications just to understand what happens, but those print statements only work in your own code.

I need something my agent can use, the same way I use a visual debugger.

JDB: The built-in command-line debugger for Java

I gave jdb a try, the command-line debugger that was always there (since jdk 1).

You can connect to a jvm that is running with the debugger options:

java -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005 MyClass

Then you can connect using that port:

jdb -attach 5005

This is an interactive tool where you send commands like:

add breakpoints: stop at com.saburto.Bar:46 or by method stop at com.saburto.Bar.getAllLedgers
steps: step, step up, stepi, next, cont
get variables info: print, dump, eval, locals, set
threads: where, threadgroups, up, down, kill, interrupt
show source code: use to add the source code path, list to show the code

The source code looks clean in the output of the coding agent

  42    @GetMapping
  43    public PageResponse<LedgerResponse> getAllLedgers(
  44            @RequestParam(defaultValue = "0") int page, @RequestParam(defaultValue = "20") int size) {
  45
  46 =>     var ledgers = ledgerService.getAllLedgers(page, size);
  47
  48        var content =
  49                ledgers.getContent().stream().map(mapper::toLedgerResponse).toList();
  50
  51        return new PageResponse<>(content, page, size, ledgers.getTotalElements(), ledgers.getTotalPages());

Let your agent know the tools

Frontier models are intelligent enough to figure out how to call jdb, but if you want to lend a hand, create a skill using man jdb to document the key commands.

Scenarios

Dump a request payload

Attach jdb to my app at port 5005, set a breakpoint at LedgerController.getAllLedgers, trigger curl localhost:8080/api/ledgers, and dump every field of the ledgers Page object. I want to see the actual database records returned.

Trace a variable's mutations

Set a breakpoint in PaymentService.process, step through line by line with next, and dump the payment variable after each line. I want to see how the status field changes as it moves through validation, enrichment, and persistence.

Inspect concurrency at a checkpoint

Break at the top of my scheduled job in ReconciliationScheduler.run, trigger a full thread dump with where all, and show me what every other thread is doing at that moment. Any thread blocked on a lock?

Evaluate an expression in place

Set a breakpoint at line 89 of InvoiceCalculator, and when it hits, run eval invoice.getLineItems().stream().mapToDouble(LineItem::getTotal).sum(). I want to verify the line-item math without adding a log line, rebuilding, and waiting for Maven.

Debug exception state without re-deploying

Break inside the catch block of PaymentGateway.submit (line 203), send a payment request with a bad card number, and when the breakpoint fires, dump the exception's message, cause chain, and the local variables. I want to see exactly what the gateway rejected and what state the request was in.

These prompts share a common shape: pick a breakpoint, trigger the code path, and let the agent extract the data. The agent handles the timing, the jdb commands, and the output parsing, and you get the answer in your terminal.

Simple examples

Checking variables in a request

For a Java application, you need to start the system with the proper arguments: java -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005 -jar app.jar

For spring-boot application using mvn:

mvn spring-boot:run -Dspring-boot.run.jvmArguments="-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=*:5005"

Then connect by attaching to the port: jdb -attach 5005, and that is it.

jdb is interactive by design, but in an agentic workflow the session must run hands-off, with the HTTP request firing while the debugger is attached and waiting.

[!WARNING]
This is only an example of how my agent generated the script to use the debugger. Depending on your case it may be different; let your agent create the right script.

Because the agent cannot type commands interactively into a debugger prompt, we pipeline the commands through standard input instead:

cd ~/projects/my-app && rm -f /tmp/jdb-output.txt && (
  echo "stop in com.saburto.ledger.controller.LedgerController.getAllLedgers"
  echo "cont"
  sleep 5
  echo "next"
  sleep 1
  echo "dump ledgers.content.elementData"
  echo "dump ledgers.content.elementData[0]"
  sleep 2
) | timeout 30 jdb -attach 5005 > /tmp/jdb-output.txt 2>&1 &
JDB_PID=$!
sleep 2
curl -s localhost:8080/api/v1/ledgers \
  -H "Authorization: Bearer $(./scripts/get-token.sh)" > /dev/null
wait $JDB_PID 2>/dev/null
echo "JDB_EXIT=$?"

Let's break this down:

The ( echo ... echo ... ) subshell pipes a sequence of jdb commands into the debugger. Each command goes in at the right time: set the breakpoint, continue, wait 5 seconds for the HTTP request to arrive and hit the breakpoint, then step over the assignment and dump the ledger data.
The whole thing runs in the background (&), with its PID captured.
After a 2-second head start, curl triggers the REST endpoint that runs getAllLedgers().
The script then waits for jdb to finish and reports the exit code.

The agent reads /tmp/jdb-output.txt afterward.

The next command steps past the var ledgers = ... assignment before the dumps run. The sleep calls pace the commands so they arrive after the breakpoint fires. The agent reads the output file and reconstructs the data.

Now we see each LedgerEntity instance:

ledgers.content.elementData[0] = {
    id: instance of java.util.UUID(id=15654)
    name: "Basic Transactions Ledger"
    createdAt: instance of java.time.Instant(id=15670)
    isNew: false
}

[!TIP]
Use tmux as the bridge between agent and debugger. Tell the agent to open a new panel or window in tmux and send all debugging commands there while keeping your coding agent open in the original pane. This is the pattern we use throughout this post, including the SQL extraction later, to keep the agent and jdb running in parallel.

Printing the Header of the Http Request

Here is an example. Without touching a single line of code, I asked the agent to show me the HTTP request headers hitting a controller method. After a few tries, it delivered exactly what I needed:

Request Headers at LedgerController.getAllLedgers() (line 46, bci=0)

 ┌───┬───────────────┬─────────────────────────────────────────────────────────────┐
 │ # │ Header        │ Value                                                       │
 ├───┼───────────────┼─────────────────────────────────────────────────────────────┤
 │ 0 │ Host          │ localhost:8080                                              │
 ├───┼───────────────┼─────────────────────────────────────────────────────────────┤
 │ 1 │ User-Agent    │ curl/8.5.0                                                  │
 ├───┼───────────────┼─────────────────────────────────────────────────────────────┤
 │ 2 │ Accept        │ */*                                                         │
 ├───┼───────────────┼─────────────────────────────────────────────────────────────┤
 │ 3 │ Authorization │ Bearer                                                      │
 │   │               │ eyJraWQiOiJkZWZhdWx0IiwidHlwIjoiSldUIiwiYWxnIjoiUlMyNTYifQ. │
 │   │               │ ..                                                          │
 └───┴───────────────┴─────────────────────────────────────────────────────────────┘

How I got there (wrapper chain)

The request object at DispatcherServlet.doDispatch frame 15 goes through 5 nested .request fields:

SecurityContextHolderAwareRequestWrapper
  → HeaderWriterFilter$HeaderWriterRequest
    → (firewall wrapper)
      → RequestFacade
        → Request
          → coyoteRequest.headers  (MimeHeaders, count=4)
            → headers[0..3]        (MimeHeaderField with nameB/valueB MessageBytes)

No code changes, no rebuilds, no restart. Just the debugger, the agent, and a tmux

Advanced debugging: chasing the SQL

Sometimes you need to dig deeper. I wanted to see the exact SQL that Spring Data JDBC sends, straight from the PostgreSQL wire. I started at the high level (LedgerController.getAllLedgers) and worked down through the stack, trying breakpoints until the right one stuck:

┌──────────────────────────────────────────────────────┬────────────────────────────────────────────────────────────────────────────────────┬────────┐
│ Layer                                                │ Breakpoint tried                                                                   │ Result │
├──────────────────────────────────────────────────────┼────────────────────────────────────────────────────────────────────────────────────┼────────┤
│ java.sql.Connection.prepareStatement(String)         │ Failed — Connection is an interface, jdb can't break on interfaces                 │        │
├──────────────────────────────────────────────────────┼────────────────────────────────────────────────────────────────────────────────────┼────────┤
│ org.postgresql.jdbc.PgConnection.prepareStatement    │ Never hit — HikariCP proxies the connection                                        │        │
├──────────────────────────────────────────────────────┼────────────────────────────────────────────────────────────────────────────────────┼────────┤
│ com.zaxxer.hikari.pool.ProxyPreparedStatement.<init> │ ✅ Hit — the Hikari wrapper constructor receives the real statement as an argument │        │
└──────────────────────────────────────────────────────┴────────────────────────────────────────────────────────────────────────────────────┴────────┘

The key breakpoint

stop in com.zaxxer.hikari.pool.ProxyPreparedStatement.<init>

This fires every time HikariCP creates a prepared statement. The constructor signature accepts a statement parameter, the real PgPreparedStatement from the PostgreSQL driver.

Extract the SQL from the driver internals

At the breakpoint, the statement variable is a PgPreparedStatement which has a preparedQuery field of type CachedQuery:

print statement.preparedQuery
→ CachedQuery{executeCount=10, query=SELECT "ledger_ledgers"."id" AS "id", ... LIMIT 20, isFunction=false}

The CachedQuery.toString() conveniently includes the full SQL string.

Sending commands to a tmux pane

Since jdb ran interactively in a tmux pane, I used:

tmux send-keys -t 3 'print statement.preparedQuery' Enter

Summary of the chain

curl → Tomcat → Spring MVC → LedgerController.getAllLedgers()
  → LedgerService → PagingAndSortingRepository.findAll(Pageable)
    → Spring Data JDBC → JdbcTemplate
      → HikariCP → ProxyPreparedStatement.<init>(conn, PgPreparedStatement)
                                                   ↑
                                         statement.preparedQuery = the SQL

Final Response

This is what it looks like the final response:

SQL Queries Executed for GET /api/v1/ledgers

From the ProxyPreparedStatement.<init> breakpoint on PgPreparedStatement:

Query 1: COUNT (for pagination metadata)
SELECT COUNT(*) FROM "ledger_ledgers"
(Earlier runs captured this: Spring Data JDBC executes the count first to populate PageImpl.totalElements)

Query 2: SELECT data (with LIMIT)
SELECT "ledger_ledgers"."id" AS "id",
       "ledger_ledgers"."name" AS "name",
       "ledger_ledgers"."created_at" AS "created_at"
FROM "ledger_ledgers"
LIMIT 20

Conclusion

Agentic debugging is powerful. You get deep insights into your Java system's state in seconds, entirely hands-off. The days of manually hitting F10 to step through line by line are behind us.

jdb is just for Java, the same pattern applies to gdb for C/C++, pdb for Python, dlv for Go, or any debugger that exposes a command interface. If you can use in a terminal, the agent can use it.

So, do you still prefer hitting F9, F10, F11 to step through your code?