When Automation Becomes the Bottleneck: Lessons Learned
In How This Website Was Built with Prompts, I described how AI helped turn an old WordPress installation into a static website hosted on AWS.
What I underestimated was how quickly a simple website could become a surprisingly complex software project.
How complexity crept in
Static siteFeaturesNine languagesCI & securitySafe releasesScope and dependencies grew together →Conceptual progression, not a numerical growth chart.
It began with S3, CloudFront, and a few pages. Then came weather forecasts, training data, games, security checks, automated releases, and nine languages.
Each translated article also needs consistent navigation, metadata, feeds, and generated HTML. Eventually, even small content changes could trigger a substantial CI/CD pipeline.
When safety mechanisms become obstacles
Our recent Git history is a useful reality check. We encountered secret-scanner friction, reproducible-build mismatches, stalled font installations, workflow configuration errors, and missing AWS IAM permissions.
One partial deployment recovery involved checking 534 public objects: 501 aligned with expectations, 24 had unexpected differences, and nine new pages could not be read. Getting back to a safe release took multiple tightly controlled PRs.
Each safeguard had a purpose. But together, they made the system difficult to change.
The lesson: more automation does not automatically mean better automation.
From an idea to a live page
Idea / changePull requestSite + security checksAll checks green?Review + mergeRelease safety gatesVerified S3 deployCloudFront TTLChatGPT: diagnose & fixYesNo → fixMerge and release have separate quality and safety gates.The fix loop happens before human review and release.
A PR is not a deployment. Changes first pass site and security checks, then require review and merge. The release independently validates the generated site, AWS permissions, budget, and exact files before uploading anything to S3.
Get Bkuhlen’s stories in your inbox
Join Medium for free to get updates from this writer.
If a check fails, the right response is to investigate the cause-not weaken a safety gate just to make a red badge turn green.
My favorite workflow: the evening debugging loop
One especially useful habit is asking ChatGPT to keep working through a PR’s failing checks: inspect the logs, propose a narrow fix, commit it, and check CI again.
That’s particularly handy in the evening, just before bed. I can leave the repetitive investigation to the connected session instead of personally following every failure.
This isn’t a promise that ChatGPT will run indefinitely or autonomously overnight: it only works while an active session and the necessary tools are available. I still review the result and decide when to merge.
Making CI/CD simpler again
We’re now deliberately removing work that adds little value to routine changes:
- Gitleaks: check new secrets on every PR; run full-history scans separately.
- Semgrep and pip-audit: check relevant changes, with scheduled full scans.
- Documentation fast path: skip heavy site builds for docs-only PRs.
- Dependency caching: reuse Python and Sharp downloads, not deployment artifacts.
- Timing data: measure font setup and quality gates before optimizing further.
We keep the important protections: reproducible builds, SHA-256 manifests, OIDC, least-privilege AWS permissions, budget checks, and no CloudFront invalidations.
Measuring the outcome
Baseline runsNext 5–10 PRsTime to green · failures / retriesMerge-to-deploy durationCompare like-for-like PR typesNo illustrative numbers presented as measured resultsMetrics to compare after additional CI runs; no results claimed yet.
We’ll compare similar changes before and after these improvements: time to green PR, failed or retried checks, and merge-to-deploy time. Documentation-only changes must be compared with documentation-only changes-not with full multilingual site builds.
The first optimizations are in place. The next five to ten PRs will tell us whether they really make the workflow more predictable.
The next improvement to this website may not be another feature. It may simply be making the existing system easier to maintain.
Originally published at https://berndkuhlen.de on November 7, 2026.
