AI-Augmented Development

The Process

My AI-assisted development process evolved through practical use rather than through an attempt to automate software development wholesale.

For independent work, I commonly use two distinct AI roles. A conversational LLM handles the analytical work; GitHub Copilot handles the implementation work inside the development environment.

How I Work

My implementation prompts usually begin in deliberately ordinary language: “Let's add this feature…” or “Let's resolve an issue where…” I provide as much relevant background as possible while keeping the requested change narrow and finite.

The AI may propose an implementation, but I determine whether the approach fits the existing application, whether it introduces unintended complexity, whether tests are sufficient, and whether the resulting workflow actually works in practice.

When an implementation technically succeeds but creates a bad user experience, I revise the requirement rather than treating generated code as the final authority.

I use AI tools aggressively, but not unquestioningly. AI has allowed me to attempt projects and technical problems I would not previously have known how to approach. It has not removed the need to understand what the software is doing, recognize when an approach is wrong, test the result, or decide whether a feature should exist in the first place.

The goal is not autonomous development. The goal is increased engineering leverage.

Case Study: AI-Assisted Debugging

I use AI as a structured debugging and code-review partner, not as an autopilot. In one recent case, a stored procedure change worked in SQL*Plus and a legacy PowerBuilder application but failed in a Java/PrimeFaces application with an “invalid field name” error. By comparing the production and modified SQL with an AI coding assistant, I identified that several UPPER(...) expressions needed explicit aliases to preserve the result-set field names expected by the DAO layer. I verified the fix locally, shared the corrected SQL and transcript with the team, and helped resolve an issue that had been blocking a colleague’s progress for several days — in about two minutes.

The Situation

A colleague had modified a stored procedure to uppercase several returned fields. The change worked correctly in SQL*Plus and in the legacy PowerBuilder application, but caused a blank screen in a PrimeFaces application, with JBoss logging an “invalid field name” error. We agreed the problem likely lived somewhere between the stored procedure output and the Java DAO layer.

The Approach

When my teammate asked me to take a look, I immediately created two comparison artifacts: the current production SQL and the modified SQL. I then used my AI coding assistant as a focused code-review partner, asking it to compare the two files and identify anything that could explain why the Java layer saw an invalid field name.

The Fix

The assistant identified that wrapping selected fields in UPPER(...) changes the result-set column labels unless explicit aliases are supplied. The Java DAO expected the original field names, so the fix was to alias the transformed fields back to those names:

UPPER(customer_name) AS customer_name

I tested the corrected SQL locally in our PrimeFaces application, confirmed it resolved the issue, and shared both the corrected SQL file and the AI Q&A transcript with the team so they could inspect the reasoning trail.

Result

A bug that had consumed several days of manual investigation was resolved in two minutes through a human-led, AI-assisted workflow using actual project artifacts, targeted prompting, and local verification.