Building a Route Optimization Engine in 4.5 Hours: An LLM-Assisted Hackathon Post-Mortem

This is a technical post-mortem analyzing constraint-driven development with AI coding assistants.

Building a Route Optimization Engine in 4.5 Hours: An LLM-Assisted Hackathon Post-Mortem

What This Document Covers

This is a detailed analysis of building production-grade code under time constraints:

  • Constraint design for AI coding assistants
  • Decision-making process during rapid development
  • AWS Location Service API integration
  • Performance optimization and UX decisions
  • Honest assessment of what worked and what didn’t

Estimated reading time: 15-20 minutes

Who This Is For

  • Engineers evaluating AI coding assistants for production work
  • Technical leads designing development workflows with LLMs
  • Anyone building route optimization or mapping systems
  • Developers interested in constraint-driven development approaches
  • Teams looking to understand when AI assistance helps vs. hinders

The document includes the actual constraint prompt we used, architectural decisions with reasoning, and specific examples of where the LLM excelled (API integration) and where it failed (domain knowledge, architectural vision).

Questions or improvements? Open an issue on the repo or e-mail me.

Complete Guide: Deploying Services to AWS EKS with Terraform and Helm

This is a comprehensive, step-by-step guide for deploying containerized services to Amazon EKS. You’ll learn how to:

A Complete Guide to Deploying a Service to AWS EKS

What This Guide Covers

This is a comprehensive, production-ready deployment guide covering:

– Infrastructure provisioning with Terraform

– Container builds and ECR push with GitHub Actions

– Kubernetes deployments with Helm

– IAM Roles for Service Accounts (IRSA) configuration

– Complete troubleshooting section

Estimated time: 2-3 hours first time, ~30 minutes after that.

Who This Is For

  • Platform engineers building self-service deployment pipelines.
  • DevOps engineers standardizing EKS deployments.
  • Anyone who’s fought with Kubernetes RBAC, IAM permissions, and Helm templating and wants a reference that just works.

The guide includes complete working examples – not snippets, but full Terraform modules, Helm charts, and GitHub Actions workflows you can adapt.

*Questions or improvements? Open an issue on the repo or message me on LinkedIn.*

Office Hours: Ask a Senior Engineer on Fridays from 9am to 3pm CEST

I’m starting something simple to help fellow engineers.

Over the last few months, people reached out with questions about direction, strategy, and “what actually matters” when trying to get hired in Europe/Sweden. It was in response to an off-the-cuff post during the summer (the Hug-a-Platform-Engineer one).

I’m grateful actually for some of the humor getting lost in translation! It’s opened up an opportunity to do something new.

So, I’m starting a weekly series: Office Hours: Ask a Senior Engineer on Fridays from 9am to 3pm CEST.

If you’re a junior engineer, a career-switcher, mid-and-stuck, senior-and-stuck, or just trying to break into engineering in the EU, drop one question below.

Anything about:
* skill focus
* job search strategy
* what EU/Sweden roles really require
* technical direction
* getting unstuck

To make it easier, here’s an example:

Question
“I’m a platform engineer outside of Europe. How do I get noticed by EU teams?”

Mini-answer
Make one small public project that demonstrates reliability work — something like a simple service with a playbook + basic telemetry. Show deployment with CI and basic secrets management. Hiring managers trust what they can see, and you can build credibility in 2–4 weeks this way.

So, that’s it!

What’s one question you want clarity on?

I’ll pick one each week, and I’ll answer it honestly and practically — no grift, no sales pitch.

Verifying Android Bundles Before Publishing

I posted last week about writing some scripts to sanity-check and validate Android bundles before uploading to Google Play Store (and having them rejected!).

I’ve made the scripts – one for AABs and APKs – open source as public gists.

curl -s https://gist.githubusercontent.com/minademian/71a5a3d0243496ce6a2a49956c01e4cd/raw/05189c8da3c8833595546a68325a3617cbd1944f/verify_aab_release.sh | bash
curl -s https://gist.githubusercontent.com/minademian/6e841c8e1a84308c6b3dc937a2d4a4cd/raw/4768df88d3d3111c134700c0637ed030a97af3a9/verify_apk_release.sh | bash

You can take it one step further and add it to your precommit hook, using the hook management tooling of your choice.

It will look like this:

yarn test || exit 1 # script in package.json: "bash./scripts/verify_aab_release.sh", yarn validate-packages || exit 1 npx lint-staged || exit 1

Meet My Second-Born: yarn-shell-completion!

Continuing my foray into OSS, I’ve been spending more time with my first (tech) love of the command-line and am teaching myself how to write shell completion scripts.

Second-born: yarn-shell-completion! https://github.com/ursine-code/yarn-shell-completion

Big h/t to @Felipe Contreras on YouTube for inspiring me to delve into this area of engineering and making it easy(-ish) to get into!



Upcoming Project: JIRA Worklogs Microsoft Teams Bot

I’ve been working on a concept over the last month, to explore a different way of inputting time reports on Fridays with Atlassian’s JIRA Worklogs module.

To exercise my system design thinking and writing muscles, I put together a design for my solution. The solution is running locally, but still not working with an actual live Teams instance. Debugging Microsoft Teams Apps Marketplace is… painful.

Code is here, demo coming soon!

Tl;DR – It’s Not As Bad As They Say!

“Contrary to conventional wisdom, the 2023 ABS (which produced 2022 data) found that adoption of technology, including AI, did not change overall worker numbers.

Businesses most often reported their “number of workers did not change overall” between 2020 and 2022 after adopting any of the five technologies the ABS tracked: AI, specialized software, robotics, cloud-based tech or specialized equipment.”

Cutting through all the hype on AI, a take from the recent US census report.

A Team of One Plus Two

I thought LLMs were just Copilot.
This week I discovered agents — and it changed how I code.

Instead of autocomplete, I had Claude Sonnet 4 troubleshooting bugs with me in real time. I redirected it when it drifted, or followed when it made sense. At one point, I asked it to output all its decisions into Markdown — suddenly I had a log of learnings I could share with the team.

A coworker spun up an Model Context Protocol (MCP server), so we all could mine knowledge about our project through hundreds of Confluence pages. Suddenly I wasn’t a solo engineer anymore — I was a team of 1 human + 2 agents.

The result? Faster debugging, better knowledge capture, and new side project ideas. I’m thinking, how could I implement a MCP server to mine Google Drive folders? Or, OneDrive? And hook them into apps or blogging platforms like this one WordPress?

So many possibilities! I’m excited! Hoohaa.

Test Runners in Multi-Stage Docker Builds

While working with Docker builds, you may already be familiar with building images and creating containers:

$ docker build --build-arg FOO=BAR FOUX=BARS -t my-docker-image:latest .
$ docker run -d -p 8088:8080 my-docker-image

This would build and create a container for the following Dockerfile:

FROM node:20-slim AS builder
WORKDIR /app
COPY . .
RUN yarn install --immutable --immutable-cache --check-cache
RUN yarn build:prod

FROM builder AS test
RUN yarn test:integration

FROM node:20-slim AS final
WORKDIR /app
ENV NODE_ENV=production
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/package.json ./package.json
COPY --from=builder /app/yarn.lock ./yarn.lock
RUN yarn install --production --frozen-lockfile
ENTRYPOINT ["node", "./dist/src/server.js"]

Need to run just the test layer in CI?

Enter the --target flag:

$ docker build --target=test -t my-api:test .

The --target flag will build the Dockerfile from the top to the specified stage, and then stop — skipping any further layers like the final production image. This is ideal when you only want to run tests in a CI/CD pipeline without building the full image.

CI/CD Example

- name: Build Docker image for testing
  run: docker build --target=test -t my-api:test .

- name: Run integration tests in container
  run: docker run --rm my-api:test

Benefits of this approach

  1. You maintain clean image separation and avoid adding test-only dependencies in the production image.
  2. Caching becomes smoother since your pipeline will cache the build layers and skip test runs in the production builds.
  3. It becomes clearer during debugging if the integration (or whatever test suite you want to run), since the test logs are isolated from the app runtime.
Verified by ExactMetrics