Pair Programming with Q

The S3 List Object Versions documentation suggested that object versions and delete markers are returned in chronological order, interleaved in the response to leverage S3's strong consistency. This interleaving is in rare case lost with the SDK due to separation of Delete Markers and Object Version in separate fields, and I first implemented a workaround but well-known principle of log-based systems. However, I always hesitated to bypass the SDK because implementing the HMAC algorithm required for direct API access seemed daunting. I assumed it would take considerable time to get it working properly. A couple of years later, with improved technical capabilities, I discovered it's still challenging—but with pair programming alongside Q Developer, it's significantly more manageable than tackling it solo. This article illustrates how I'm building tests for an upcoming piece and writing direct access to the S3 List Object Versions API. More broadly, it's a story about collaborative problem-solving, analytical thinking, and the capabilities of Q Developer.

In essence, this article is about developing a minimal SDK through conversation — or as I prefer to frame it: Q Developer serves as the driver while I act as navigator. In pair programming, the navigator guides the programmer (driver) toward excellent code while maintaining the big-picture perspective. We began by creating a minimal, custom ListObjectVersion SDK, which predictably returned a 403 (Forbidden) error. As navigator, I informed the driver (Q Developer) that our approach wasn't working. After implementing a fix and testing, we still encountered failures.

I dove into the documentation and found this helpful Reference. Excellent—there was sample HMAC Algorithm for Java. I downloaded it and asked Q to translate it to Python, which was completed quickly. However, when I requested Q integrate it into our SDK, the driver took a different approach, opting for an existing Python Library instead. This demonstrated Q's autonomous decision-making.

The solution still failed. When I asked about debugging capabilities, Q Developer added comprehensive logging. The rerun revealed that S3's calculated signature didn't match our provided one. The driver correctly identified this as typically indicating an incorrect host configuration in the signing algorithm. After fixing this issue, our implementation finally worked.

This raised an important security consideration: should we trust an open-source library with our AWS Secret Keys? While not specific to our example, this represents a broader question about third-party dependencies in security-sensitive contexts. We can audit the current code, but what about future updates or supply chain risks? These concerns needed addressing.

When I posed this question to Q Developer, the response was immediate:

For security purposes, I'd recommend not trusting external libraries for AWS authentication. Let me replace it with a minimal, auditable implementation using only standard libraries ...

In the end, we both settled for the AWS Provided Code translated from Q to a Java version.

The outcome exceeded expectations:

• A functional, reliable solution
• A security-conscious implementation (using AWS source code with verified translation)
• Faster development time with superior results compared to solo efforts

Q Developer's contributions:

• Rapid implementation with extensive knowledge base
• Independent problem-solving and creative alternatives
• Seamless iterative testing cycles
• Thoughtful technical dialogue
• Heavy computational and coding work

My contributions as navigator:

• Domain expertise and strategic guidance
• Security awareness, preventing potentially vulnerable dependencies (referencing established research on open-source risks)
• Expert Generalist perspective, bringing context beyond the immediate technical challenge

Currently, I am evaluating Kiro.

Stay tuned for the results of our direct S3 List Object Versions API implementation and my Kiro try out...