AI Developer Intern

I'm currently working on a GenAI appeal-processing system, the client's first public-facing AI-powered service, built to government-grade reliability and audit standards. It runs on an ECS/Lambda architecture and handles more than 80,000 invocations a year, so every stage needs to trace back to a decision someone can defend later.

Early on, most of my time went into wiring up Lambda invocation logic across that pipeline, then proving it held up. I wrote unit and system integration tests that hit PostgreSQL tables directly on the RDS instance, checking data integrity end to end and cross-referencing CloudWatch logs to confirm the full trace matched what actually happened. That last part mattered more than I expected: during User Acceptance Testing, being able to actually read the logs was the difference between finding a bug in minutes and losing an afternoon to it. I learned to write verbose logging on both the ECS and Lambda side, and to format it so it stayed human-readable in CloudWatch instead of a wall of JSON someone had to parse by hand.

The part I found most interesting was the LLM side. The system chains several Bedrock calls to Claude Sonnet 4.6 across multiple stages, and getting that chain to behave predictably took prompt engineering paired with Python scripts that validated both the prompt outputs and the ECS logic around them. Most of this work happened inside a Windows EC2 instance accessed through AWS Fleet Manager, which took some adjusting to.

I also helped co-design the production PostgreSQL schemas spanning the business logic and GenAI components, translating the logical data model into SQL structures with traceability, audit logging, and versioning built in from the start rather than added later.

Working on a system that receives external files and documents from the public also meant taking security seriously on more than one layer. Our CI/CD pipeline ran SonarQube vulnerability scanning on every change, and on the cloud side, AWS GuardDuty watched the S3 bucket where those external uploads landed, which fed into splitting storage into a quarantine bucket and a separate clean bucket so nothing unverified sat next to trusted data. We also ran Amazon Inspector to catch CVEs across the source code, third-party dependencies, and the infrastructure-as-code itself. Seeing all of that layered together, rather than just reading about it, was probably the biggest thing I took from getting to work on something at this level of production readiness.

After that, I supported a keyword-driven, command-pattern Lambda router and set up unit testing through Lambda test events, so we could validate logic changes without a full redeploy each time. That cut our test-cycle turnaround by roughly 80%.

I've also had to present architectural decisions, test outcomes, and LLM logic flows directly to non-technical clients, which meant learning to explain what a Lambda router or a Bedrock chain actually does in terms that support a real integration decision between our AWS-hosted system and their on-premise one.