DEV Community: Andrew Eells

Vibe Coding Is Reckless. Defined Architecture Patterns Fix It.

Andrew Eells — Mon, 10 Aug 2026 06:17:34 +0000

Andreas Horn leads AIOps work at BLP - real enterprise IT. A while back he posted something that stuck with me: most people calling vibe coding the future have never sat through a 2 a.m. call after a misconfigured permission policy or firewall rule took production down.

Demos look great. Small projects hold up. None of it survives a real enterprise, where system complexity and constraints are the default.

He's right. He's also spent a decade watching AI initiatives succeed or fail inside real companies.

Here's the sharper point: this isn't a talent problem, and it isn't a caution problem. It's a constraint problem. The architectural "-ilities" - scalability, security, maintainability, observability, and the rest - are exactly the properties teams reinvent under deadline when no convention exists.

The twelve-factor app made this same bet well over a decade ago: a fixed convention for how a SaaS app runs in production, not something every team invents from scratch. That bet gets sharper once the thing touching your system is an agent, not a person.

Why vibe coding breaks

A coding agent doesn't reason about your architecture. It reads what's there and extends it. Give it a codebase where the -ilities are already expressed the same way a dozen times, and it follows those patterns reliably. Give it a blank project - which is what vibe coding usually means - and it has nothing to follow. It invents the patterns instead: how identity is checked, what gets logged, how failures propagate, where rate limits live. The result might be plausible. It is not always production-grade.

That gap shows up in public. WIRED reported research from Red Access finding thousands of publicly accessible vibe-coded apps with effectively no authentication - and close to two thousand appearing to leak sensitive data. Security is only one -ility. The same blank-canvas pressure applies to scalability, observability, deployability, and maintainability. Agents optimise for something that works. The cross-cutting properties are what they have to guess.

Why Backbone fixes it

Two agents, same task: add a feature that touches identity, authorization, and an audit trail - the kind of change that forces several -ilities into play at once.

On a blank project, the agent invents those concerns as it goes: where identity lives, how authorization is checked, what gets audited, how operational boundaries are drawn. Decisions about the architecture happen while the feature is being written.

On Backbone, those decisions already exist. Authentication is wired to Cognito and OAuth2. Authorization runs through an existing identity model. Audit events already have a schema, cross-cutting wiring, and a destination. Deployment, configuration, health checks, observability, and rate limiting are already established. The agent isn't designing the -ilities. It's adhering to them - extending a system with known scalability, reliability, and security characteristics rather than inventing those characteristics feature by feature.

That's the bet behind Backbone: agents are better at extending an established pattern than inventing production architecture from scratch. Service-to-service calls use explicit AWS IAM identities and policies, not credentials embedded in application code - one more decision that's already made, not one your agent has to guess at.

Published ADRs capture the constraints behind those patterns - why Cognito, why IAM for service auth, why the observability stack looks the way it does. Not marketing. The trade-offs.

Where this stops working

Convention only helps if it's right. A flawed pattern gets propagated faster and more confidently by an agent than by a human - it doesn't second-guess precedent, it follows it. That's an argument for getting the pattern right once, by people who've made the mistakes already, not for skipping review. An agent can follow a correct pattern into a situation it was never built for, and catching that is still your job.

One more thing: "vibe coding" might not be the word anyone's using in two years. The shift underneath it - agents doing more of the typing, over bigger diffs, with less supervision - isn't going anywhere.

Architecture engineering, not prompt engineering

The real distinction isn't whether AI wrote the code. It's whether the agent was working inside architecture that already solved the -ilities - identity, authorization, auditing, observability, configuration, deployment - or making those calls up as it went.

If those decisions don't exist, the agent invents them while it builds your feature. If they do exist, it reinforces them.

As coding agents become capable of producing larger and larger changesets, that's the bet that matters: not prompt engineering, but architecture engineering.

Quarkus + GitHub Actions: Reducing CI Time by Half Without Larger Runners

Andrew Eells — Fri, 07 Aug 2026 02:36:51 +0000

Our Quarkus monorepo CI pipeline had plateaued at 9–11 minutes on GitHub Actions free-tier hosted runners.

After a focused optimisation pass, it now completes in about 5 minutes 20 seconds, without self-hosted runners, larger GitHub runners, or paid caching products.

The key discovery was that the remaining time was not in dependency downloads or Maven compilation. It was in duplicate Quarkus work: repeated augmentation, repeated application boots, and infrastructure startup that some test suites did not actually need.

This post walks through the changes that produced the biggest gains, the ones that barely moved the needle, and the final workflow shape.

The baseline was already heavily optimised

Before touching anything, the workflow already had:

Reactor parallelism via .mvn/maven.config (--threads=2C)
Maven Build Cache extension for local incremental builds
Surefire and Failsafe configured for parallel=classes with an explicit thread count
A split build → artifact restore → test shape so test jobs did not rebuild the world
Parallel composite setup where it was safe (JDK + tooling overlapping other preparation)

That matters, because it changes the question from "how do we make Maven faster?" to "what is still dominating wall clock after the obvious tuning is already in place?".

Where we started

Backbone's platform repository is a Maven multi-module Quarkus monorepo: shared libraries, several application services, a BFF API, UI modules, and scaffold code. The module names below (actor, audit, auth-service, etc.) are illustrative; the important point is the shape of the reactor rather than the specific repo layout.

A rough cloc of the parts CI actually cares about (Java, YAML, shell; excluding target, node_modules, etc.) lands around ~24k lines of code, including ~14k Java across roughly 300 source files. Big enough that cold Quarkus boots matter; small enough that a vanity matrix of one job per module mostly pays setup tax.

The critical workflow looked like this:

build: mvn install -DskipTests, upload jars/classes/local io.backbone artifacts
unit-test: Surefire against the restored reactor
integration-test: Failsafe @QuarkusTest classes with local AWS emulation and/or Postgres

A representative run before the major changes looked like this:

Job	Wall clock
build	~2.5 min
int-test	~8.5 min
workflow	~11.4 min

The optimisation target was the end-to-end workflow wall clock (checkout through reporters), not a single Maven invocation in isolation.

One integration-test verify invocation reported:

[INFO] Total time:  02:09 min (Wall Clock)

If Maven itself said 2 minutes while the workflow still took 10–11 minutes, the missing time was clearly job setup, emulator startup, artifact restore, and Quarkus application boots. That observation ended up driving almost every useful optimisation that followed.

The wrong instinct: copy the ECS deploy matrix

We already parallelise ECS deploys with a GitHub Actions matrix, so the obvious idea was "one integration-test job per service".

That would have been a mistake.

Each matrix cell would have re-paid:

JDK and tool setup
Artifact download
AWS emulator startup
Cognito / DynamoDB / S3 seeding where required
Postgres startup where required

We only had a handful of integration-test classes. Fixed setup cost multiplied by N shards usually loses to one job that pays setup once and parallelises the Maven reactor internally.

So we kept the job count small and focused on eliminating duplicated work inside the existing jobs.

Prerequisite: LocalStack → Floci

Before this CI pass, we had already migrated from LocalStack to Floci as the local AWS emulator on :4566.

The original motivation was Cognito support, not CI speed. LocalStack Community did not provide a credible Cognito story for our authentication flows, so auth integration tests previously required a real AWS-backed job alongside a LocalStack-backed job for the other services.

Floci supports enough of Cognito for our password, refresh-token, and JWT flows that we could collapse those two worlds into a single local emulator.

It was also noticeably lighter in CI.

LocalStack startup (older run)

Step	Wall clock
`./.github/actions/localstack`	~49 s

Floci startup (current run)

floci start --detach --image floci/floci:1.5.34
floci wait --timeout 2m
...
Waiting... (119s remaining)   Floci AWS is ready (http://localhost:4566)

The entire start-and-wait sequence completed in about 16 seconds.

Smaller footprint, no auth-token tax for CI, and Cognito in the same process that already emulates DynamoDB, S3, and SES. That consolidation mattered more than the raw startup-time improvement.

The migration was not entirely frictionless. Floci's InitiateAuth + REFRESH_TOKEN_AUTH path initially accepted invalid refresh tokens and minted new JWTs, which broke our negative-path authentication tests. We filed floci-io/floci#2113, and it quickly attracted two fix PRs (#2132 and #2135). That kind of maintainer response is exactly what makes an emulator migration feel safe rather than lonely.

Step 1: actually forward the Maven flags

CI had been invoking:

task test:integration -- -Dtest.thread.count=2

but the Task definition never forwarded {{.CLI_ARGS}}, so Failsafe never saw the thread-count override.

After fixing that, we enabled reactor parallelism for the integration-test invocation:

task test:integration -- -Dtest.thread.count=2 -T 1C

This helped, but only modestly. The dominant cost was still Quarkus application startup, not Maven's ability to schedule modules concurrently.

Step 2: treat Quarkus boots as a budget

Every @QuarkusTest class pays for an application start. Once we started looking at boots as a finite budget, several easy wins appeared.

What changed

Excluded scaffold integration tests from CI: template-service remains in-tree as a scaffold, but CI no longer boots Quarkus for a module that rarely changes.
Merged overlapping integration tests: notification unsubscribe coverage moved into NotificationResourceIT; Cognito user and service cases became nested tests under a single CognitoAuthenticationProviderIT so they share one application boot.
Demoted thin HTTP integration tests to unit tests: DocumentResourceIT became focused unit tests around the Tika, S3, and DynamoDB behaviour we actually cared about.

The suite still provided meaningful coverage, but we were no longer starting Quarkus for every historical convenience test class.

At this point the full workflow was down to roughly 9.5 minutes: an improvement, but nowhere near the eventual 5-minute target.

Step 3: split integration tests by infrastructure

The remaining integration tests naturally separated into two infrastructure groups:

Job	Infrastructure	Modules
`int-auth-test`	Floci + Cognito seed	`auth-service`
`int-rest-test`	Postgres	`actor`, `audit`, `notification`

The important observation was that auth tests did not need Postgres, and the REST-resource tests did not need DynamoDB template seeds or Cognito setup.

So we stopped starting Floci and Postgres in the same job, and we stopped seeding notification templates when nothing in the test suite actually read them.

The critical-path shape changed from:

build + (Floci + Postgres + all ITs serially)

to:

build + max(unit, int-auth, int-rest)

That was the first optimisation that made the workflow feel dramatically shorter, bringing it down to around 6.5 minutes.

A useful side note: avoid parallelising shell-tools (which uses apt) with postgres (which also uses apt). That turned into a classic package-manager lock race. Floci was safe to overlap with Temurin and shell-tool setup because it does not compete for apt locks.

Step 4: stop using Graal where you are not building native images

Native-image builds still require GraalVM. Unit tests and @QuarkusTest do not.

We introduced a Temurin 25 composite action for all non-native workflows and kept GraalVM only on the ECR native-image pipeline.

This was not a massive wall-clock win (roughly 20 seconds), but it reduced runner setup overhead and removed a surprising amount of cognitive noise from the workflow definitions.

Step 5: make CI install skip `quarkus:build`

This was the cleanest Maven optimisation in the entire exercise.

A normal Quarkus mvn install performs package-time augmentation. Our test jobs restore artifacts and then run @QuarkusTest, which boots directly from the test classpath. They do not need the production runner jar produced by the build job.

So the CI install step became:

mvn install -Dmaven.test.skip -Dquarkus.build.skip=true \
  -pl '!libs/reactor,!ui,!ui/web-actor,!services/template-service' -am

The logs changed from multi-minute Quarkus augmentation phases to a stream of:

[INFO] Skipping Quarkus build
[INFO] Skipping Quarkus build
...
[INFO] Total time:  31.650 s (Wall Clock)

The build job dropped from roughly 2 minutes to about 80 seconds, which removed a substantial chunk of the remaining critical path.

Excluding ui, web-actor, and template-service from the CI install reactor also mattered. Those modules were simply not what 02-build-test was trying to validate on every push. One small Maven quirk worth noting: excluding !ui alone is insufficient; Maven will still include the child module unless you also exclude !ui/web-actor.

Step 6: run Failsafe without packaging again

After the install phase stopped producing runner jars, the integration-test jobs were still invoking verify, which re-entered package and quarkus:build for the service modules.

For @QuarkusTest, that was pure wasted heat.

The integration-test invocation became:

mvn -pl services/auth-service \
  test-compile \
  failsafe:integration-test failsafe:verify \
  -DskipUnitTests

A recent auth-job run reported:

[INFO] BUILD SUCCESS
[INFO] Total time:  01:21 min (Wall Clock)

We experimented with dropping -am after artifact restore first. That cleaned up the reactor graph, but it barely moved wall clock because the upstream jars were relatively cheap.

The real lever was skipping package-time augmentation during install; Failsafe-without-package was the complementary optimisation on the test side.

The finish line

A current green run of 02-build-test on main looks roughly like this:

Job	Wall clock
build	~1.3 min
int-rest-test	~2.8 min
int-auth-test	~3.7 min
unit-test	~3.1 min
workflow	~5.5 min

That is roughly half of where we started, and the number developers actually experience day-to-day is "about five minutes twenty".

What barely moved the needle

This is the section I wish more CI optimisation posts included. These ideas sounded promising during planning, but they were not the reason the pipeline got fast:

Maven -T by itself: useful, but not transformative once Quarkus boots dominate.
Dropping -am after artifact restore: cleaner reactor hygiene, only a few seconds of savings.
Failsafe-without-package after install already skipped quarkus:build: a real improvement, but smaller than the install-phase optimisation.
Persisting Maven Build Cache in GitHub Actions: still on the shelf; actions/setup-java caches ~/.m2/repository, not ~/.m2/build-cache, so the extension kept writing cache entries without ever reading them across workflow runs.

We stopped when the next ideas started looking like "fewer services" or "don't boot Quarkus at all", which would have traded away the confidence the pipeline exists to provide.

The patterns worth stealing

If I had to compress the whole exercise into five transferable lessons:

Budget Quarkus boots. Merge overlapping tests, demote HTTP-thin integration tests, and exclude scaffold modules from CI.
Split jobs by infrastructure requirements, not by module count. Auth + Floci versus REST + Postgres beat six tiny jobs that each restarted the world.
Match the JDK to the work. GraalVM for native-image builds; Temurin for everything else.
Do not package what @QuarkusTest will rebuild anyway. -Dquarkus.build.skip=true during CI install is boring, reliable, and surprisingly effective.
Choose an emulator that covers the awkward service. Floci's Cognito support let us delete an entire AWS-shaped CI job category, not merely shave a few seconds off container startup.

The final result was less about discovering a clever Maven flag and more about refusing to pay for the same Quarkus application three times on the way to asserting a single HTTP status code.

We'll happily take five minutes twenty.

We've Spent 25 Years Shifting Left. The Next Shift Is Down.

Andrew Eells — Fri, 24 Jul 2026 07:28:29 +0000

I've been building software professionally for about 25 years.

Looking back, I realised that a surprising amount of that time has been spent doing one thing.

Shifting left.

Moving work earlier. Catching problems sooner. Automating the things we used to do by hand at the end of a project.

It's been one of the defining trends of modern software engineering.

But recently I've started wondering whether we've been optimising along the wrong axis.

Twenty-five years of shifting left

Around the turn of the millennium, continuously building and testing software instead of integrating everything just before release was still a relatively new idea.

Continuous integration emerged. CruiseControl popularised the approach, Hudson followed a few years later, and eventually Jenkins became the tool many teams knew best. "Does it build?" became a question answered automatically on every commit.

That was shift-left number one.

Testing and integration moved earlier.

Then continuous integration became continuous delivery. Martin Fowler and Jez Humble helped turn the idea into mainstream engineering practice. Building software wasn't enough; every commit produced something releasable.

Then the "D" quietly changed meaning.

Delivery became deployment.

Releasing software stopped being a scheduled event and became something that happened continuously as a consequence of merging code.

Then came DevOps.

Operations moved left too. Infrastructure, monitoring, deployments and incident response all became part of the same team's responsibility.

"You build it, you run it."

Then security took its turn. DevSecOps pushed security left as well - threat modelling, dependency scanning and policy checks moving out of a late-stage gate and into the pipeline itself.

Every few years another discipline moved closer to the developer.

Testing.

Delivery.

Deployment.

Operations.

Security.

It genuinely made us better engineers.

AI isn't really shifting left

Today it's fashionable to put AI into the same story.

I'm not convinced that's what's happening.

AI isn't primarily moving work earlier.

It's helping us perform the same work faster.

That's an important distinction.

Where AI has changed things is by lowering the barrier to entry. Someone with relatively little operational experience can now generate a CI pipeline, Terraform configuration or deployment workflow in minutes.

Useful?

Absolutely.

But if AI's biggest contribution is helping us recreate the same infrastructure more quickly, then perhaps recreating it was never the thing we should have been doing in the first place.

The pattern I couldn't ignore

Here's what those 25 years actually looked like.

I built CI pipelines.

Then I built them again somewhere else.

Then again.

I created infrastructure-as-code.

Then recreated it for the next company.

I wired up authentication.

Observability.

Deployment pipelines.

Audit logging.

Secrets management.

Monitoring.

Rollback procedures.

Different organisations.

Different technology stacks.

Different decades.

Almost exactly the same engineering disciplines.

None of that work was the product.

None of it differentiated the business.

It was simply the operational foundation required before the product could exist.

These aren't product problems. They're engineering fundamentals. Yet almost every team rebuilds them from scratch, every single time.

Shift-left made us do this work earlier.

It never asked why we were repeating it at all.

Every startup, every consultancy and every enterprise greenfield project still begins by rebuilding the same engineering capabilities before a single customer problem gets solved.

Forge is about shifting down

That's the shift I'm interested in now.

Not left.

Down.

Imagine rotating the software lifecycle ninety degrees.

Across the top sits your product: the services, APIs and user experience your customers actually pay for.

Underneath sits everything every serious SaaS product inevitably needs.

Authentication.

Identity.

CI/CD.

Observability.

Audit.

Notifications.

Document services.

Infrastructure.

Operational tooling.

These capabilities aren't unique to your business.

They're shared engineering concerns.

So why are they still treated as project work?

Shifting down means moving those undifferentiated engineering disciplines beneath your application into a reusable operational foundation instead of rebuilding them inside every new product.

That's what Forge Platform is.

Not another framework.

Not another starter template.

An opinionated operational backbone for modern SaaS products.

Authentication, users, audit, notifications, documents and a BFF orchestration layer. Infrastructure-as-code. CI/CD. Observability. Security. Everything deployed into your own AWS account, from your own GitHub repositories, remaining entirely under your control.

The disciplines I spent decades shifting left don't disappear.

They simply stop living inside every application.

Left was never the destination

Shift-left was absolutely the right idea.

Finding problems earlier has transformed our industry.

But somewhere along the way we confused the mechanism with the objective.

The objective was never simply to push more responsibility onto developers.

It was to stop repeatedly paying for the same engineering work in every company, on every project, for every new product.

Some engineering problems only need solving once.

The operational backbone beneath your SaaS product is one of them.

After 25 years of shifting left, that feels like the direction we've really been heading all along.

If that resonates, I'd genuinely like to hear from you - you can find out more at forgeplatform.software.

AWS Transform and Superwerker: same vocabulary, different problems

Andrew Eells — Sat, 11 Jul 2026 18:04:14 +0000

Most people will read AWS Transform's landing zone agent as Superwerker's smarter cousin. I don't think that's right.

Same destination. Different problems. Treating them as substitutes is how greenfield teams buy enterprise process they don't need — and how migration teams under-buy governance they do.

I saw the announcement via a LinkedIn post, and it stuck because the vocabulary overlaps heavily with a tool I've actually used and rate highly: Superwerker. I haven't run Transform myself — this is a read from the announcement and docs, not a hands-on review. I'd genuinely like to hear from anyone who has.

Superwerker: opinionated defaults, shipped

Superwerker is a free, MIT-licensed CloudFormation stack. You run it, and it stands up a multi-account baseline — Control Tower, SSO, and sensible guardrails — without a discovery workshop. We used it on a recent greenfield build and had SSO and baseline guardrails live in an afternoon. The entire decision tree is a public repo you can read end to end before you commit to anything.

I'm generally a fan of opinionated tooling. If there is a sensible default, I'd rather spend engineering time building product than debating OU structures.

If I were founding again tomorrow with a blank AWS org, I'd run Superwerker before I spent a day on account design. Greenfield teams don't fail because their landing zone wasn't migration-aware. They fail because they never got a baseline and spent months refactoring after the event.

Transform: a different problem

Transform's agent is a different shape of tool entirely. It's not a standalone landing zone builder — it's embedded in AWS Transform's end-to-end migration workflow. Transform gathers information about your organisation, migration waves, compliance requirements and account structure before proposing a landing zone.

That's a fundamentally different problem from "deploy me a sensible default."

Where Forge sits

Forge deliberately stops at the landing zone boundary. That's infrastructure governance, and every organisation has different requirements. Once that foundation exists — whether it came from Superwerker, AWS Transform or something else — that's where Forge starts.

A working rule of thumb

Greenfield startup? Use Superwerker.
Enterprise migration? Look seriously at AWS Transform.
Brownfield AWS estate? Use judgement. Every organisation carries different history and constraints.

I haven't used Transform yet, so I'd genuinely like to hear from teams that have. I'm much more interested in where this rule breaks down than where it holds.

How AI finally solved AWS architecture diagrams

Andrew Eells — Fri, 10 Jul 2026 05:47:49 +0000

After years of fighting draw.io, CloudFormation graphs and auto-generated spaghetti, architecture diagrams felt like the final boss of platform engineering - one I'd never quite beaten.

I've been building software professionally for over 25 years.

I have yet to be genuinely excited by AI's impact on large-scale software engineering. It's exceptionally good at bounded problems - a Bash script, a utility class, an isolated feature - and it's undeniably accelerating delivery. But building an entire production platform is a different challenge. That's still about architecture, trade-offs, operational thinking and years of accumulated engineering judgement.

I don't believe "vibe coding" is replacing experienced engineers any time soon. AI is an extraordinary force multiplier, but it doesn't replace engineering judgement. If you're only capable of building poor software today, AI mostly helps you build poor software faster.

But this...

This genuinely felt like the first time AI solved this category of problem I'd been wrestling with for years.

In under two hours I went from...

"A salesperson asked if I had an architecture diagram. I said, 'Yes... but it's rubbish.'"

...to publishing this.

You can see the live diagram on the Forge docs site, with more detail in the AWS platform infrastructure guide.

After literally years of trying different approaches, this is the first workflow that has produced an architecture diagram I'd happily put in front of customers.

The problem with architecture diagrams

Anyone building on AWS has probably been here.

The architecture changes.

The diagram doesn't.

Eventually someone opens draw.io and spends half a day dragging icons around.

Six months later it's wrong again.

I've spent years trying to solve this problem.

Manual diagrams

I've built diagrams using tools including:

draw.io AWS diagram shapes
Lucidchart
Microsoft Visio
Cloudcraft (live AWS/Azure scanning and visual designer)
Eraser AI AWS Diagram Generator (prompt-to-diagram)

The results can look fantastic - whether you drew them by hand, scanned live infrastructure, or generated them from a written description.

Until the infrastructure changes.

Then they immediately start drifting from reality.

CDK diagram generators

I also explored tools including:

cdk-dia
cdk2d2
AWS PDK CDK Graph (with its diagram plugin)

These are clever projects.

They faithfully represent your infrastructure.

Unfortunately, for customer-facing architecture communication, that's exactly the problem.

A single ECS service explodes into something like:

Task Definition
Execution Role
Task Role
Security Groups
Target Groups
Listener Rules
Auto Scaling
CloudWatch Alarms
Log Groups
IAM Policies
ENIs

Everything is technically correct.

Nothing is architecturally useful.

CloudFormation graphs answer:

"What AWS resources exist?"

Architects are usually trying to answer:

"How does this system work?"

Those are completely different questions.

The CDK diagram generators were right.

They just weren't publishable.

AWS Workload Discovery

I even evaluated AWS' own solution:

AWS Workload Discovery on AWS

It discovers infrastructure.

It inventories resources.

It builds dependency graphs.

For me?

It simply wasn't worth the cost - over $400/month just to deploy the CloudFormation stack and keep the discovery pipeline running, so you can draw a diagram of what you already deployed with CloudFormation. That is a genuinely terrible proposal for a documentation problem.

Again, it documents what AWS has deployed.

It doesn't communicate your architecture.

The breakthrough

The breakthrough came from this AWS blog:

Build AWS architecture diagrams using Kiro CLI and MCP

At first I thought:

"Interesting... but they're just feeding text into an LLM."

Then I realised something.

That isn't a weakness. It's the entire point.

An experienced solutions architect doesn't think in CloudFormation resources.

They mentally ignore:

IAM Roles
Security Groups
Parameters
Log Groups
Listener Rules
Auto Scaling Targets

and instead think:

Application Load Balancer
ECS Services
PostgreSQL
Redis
S3
Cognito

That's architecture.

Not implementation.

The LLM wasn't trying to replace an architect.

It was acting as an architectural abstraction layer - the same idea as a C4 container diagram: document intent at the level stakeholders actually care about.

That was the lightbulb moment.

Cursor did almost all of the work

Armed with that idea, I pointed Cursor at my AWS CDK repository.

I also gave it some context from a conversation I'd had with ChatGPT about why CloudFormation graphs are the wrong level of abstraction - useful for framing, but Cursor did the actual work.

Then I basically let it loose.

It analysed the repository.

It walked the stacks.

It understood the constructs.

It traced the networking.

It identified which AWS resources represented meaningful architectural components and which were simply implementation plumbing.

Then it produced:

a curated architecture model
rendering instructions
a repeatable workflow
automation scripts
documentation updates
and finally, the diagram itself.

I didn't manually reverse-engineer thousands of CloudFormation resources into a diagram. I reviewed and refined what the tooling produced.

That's a huge distinction.

The AI wasn't making architectural decisions.

It was reverse engineering architectural decisions I'd already made in code.

My role was limited - mostly review, a few rounds of feedback, and sanity-checking that the subnet story matched what we'd actually built.

That's a far harder problem than it sounds

The YAML wasn't the clever part.

The clever part was that Cursor understood:

an ECS Task Role isn't an architectural component
an Application Load Balancer definitely is
six Fargate services belong together
subnet boundaries matter
CloudFront belongs at the edge
PostgreSQL, Redis and Cognito deserve first-class representation

None of that existed in a single file.

It emerged from analysing thousands of lines of CDK spread across stacks, constructs and configuration - including constructs like ForgeStaticEdgeDeliveryConstruct, which encodes the CloudFront → S3 static UI + API path proxying story as a single architectural unit rather than a pile of distribution behaviours and origin policies.

That's genuinely impressive.

Was it perfect first time?

No.

I iterated a couple of times.

I told Cursor to:

collapse repeated Cognito connections and repeated metrics connections to AMP
show public/private subnet boundaries in the VPC

The second render was immediately publishable.

There was also a small tooling wrinkle: the AWS Diagram MCP server package has been yanked upstream, so we pinned the last published version (1.0.23) in a source-controlled mcp.json. That kind of friction is worth mentioning - this wasn't magic; we wrestled with it slightly to get it working.

The hybrid workflow

The workflow ended up looking like this.

CDK repository
        │
        ▼
Cursor analyses architectural intent
        │
        ▼
Curated intermediate model (YAML)
        │
        ▼
Kiro CLI
        │
        ▼
AWS Diagram MCP ([Model Context Protocol](https://modelcontextprotocol.io/))
        │
        ▼
Published AWS architecture diagram
        ([Python diagrams](https://diagrams.mingrammer.com/) + [Graphviz](https://graphviz.org/) + AWS icons)

The architecture model is version controlled.

The prompt is version controlled.

The rendering script is version controlled.

The generated diagram can be regenerated whenever the platform evolves.

For the first time ever, my architecture documentation actually feels maintainable.

Why this works

The key insight is surprisingly simple.

Architecture diagrams should document intent, not implementation.

My CDK constructs already encode that intent.

They have names like:

ForgeStaticEdgeDeliveryConstruct
ForgeEcsWorkloadConstruct
ForgeCognitoIdpStack

Those are architectural concepts.

CloudFormation is an implementation detail.

Trying to diagram CloudFormation is a bit like trying to explain a car by drawing every nut and bolt.

Sometimes abstraction is exactly what you want.

AI finally solved the right problem

This experience genuinely changed my opinion of where AI delivers value.

Not by replacing engineers.

Not by generating production systems from prompts.

Not by writing thousands of lines of code you'll spend next week debugging.

Instead, it behaved like a very competent technical collaborator.

It absorbed an entire repository.

It reconstructed the architecture.

It understood what mattered.

It ignored what didn't.

It accepted feedback.

It refined the output.

The AI wasn't designing my platform.

But it did an excellent job of documenting a platform that already exists - the same platform I write about when debugging AMP remote write failures or explaining what production-ready actually means.

Would I trust it blindly?

Absolutely not.

The architecture still belongs to the engineers who built the system.

The AI isn't deciding what the platform looks like.

It's modelling something that already exists.

The human remains accountable.

The AI removes an enormous amount of tedious work.

That's augmentation.

Not replacement.

What's next?

This has me thinking the future isn't another CDK diagram generator.

It's architecture-aware tooling.

Imagine a workflow that can:

analyse your CDK constructs
infer architectural components
maintain a version-controlled intermediate model
regenerate diagrams automatically
produce different views for developers, operations, security reviews and customer documentation

That feels considerably more exciting than another CloudFormation graph.

And I essentially have that version-controlled now - tied to a real ECS on Fargate platform, not a toy example.

Here's how Cursor did it

The interesting part isn't the PNG. It's the intermediate model - a curated, solutions-architect view derived from CDK constructs, not from the synthesized CloudFormation dependency graph.

The model header explains the intent:

---
# Forge Platform - curated architecture model
#
# Derived from CDK constructs under infra/src/lib (NOT from the synthesized
# CloudFormation dependency graph). Low-level noise (IAM roles/policies,
# security groups, log groups, alarms, KMS keys, SSM params, ENIs, target
# groups, listener rules) is deliberately omitted.
#
# Source of truth mapping:
#   - Edge / CloudFront .......... forge-static-edge-delivery-construct.ts
#   - Ingress (ALBs) ............. forge-ecs-ingress-construct.ts
#   - Compute (Fargate) .......... forge-ecs-workload-construct.ts
#   ...

Nested groups encode the VPC security boundary:

groups:
  - id: vpc
    label: VPC (ForgePlatformVpc)
  - id: public_subnets
    label: Public Subnets
    parent: vpc
  - id: private_subnets
    label: Private Subnets
    parent: vpc
  - id: compute
    label: ECS Fargate Cluster
    parent: private_subnets
  # ...

Aggregate connections collapse repeated edges - six identical "service auth" lines become one:

  - from: compute
    to: cognito_service
    label: service auth
    aggregate: true

The MCP server registration is trivial - no secrets, just a pinned package launch:

{
  "mcpServers": {
    "awslabsawsdiagrammcpserver": {
      "command": "uvx",
      "args": [
        "--from",
        "awslabs.aws-diagram-mcp-server==1.0.23",
        "awslabs.aws-diagram-mcp-server"
      ],
      "env": {}
    }
  }
}

And regeneration is a one-liner:

./infra/architecture/render-diagram.sh

Which syncs the MCP config, then drives Kiro non-interactively:

kiro-cli mcp import --file "${mcp_config}" --force global
kiro-cli chat --no-interactive --trust-all-tools "$(cat diagram-prompt.md)"

The prompt tells the MCP server how to map component types to diagrams nodes, nest subnet clusters, and honour aggregate edges - treating the YAML as the single source of truth.

That's the whole trick: deterministic extraction from code you already wrote, LLM-assisted rendering for polish.

Final thoughts

This is probably the first AI workflow I've adopted where I immediately thought:

"I'm never going back."

Not because the AI was smarter than me.

Because it could absorb an entire repository, retain all of that context, and perform a task that would have taken me several evenings of tedious work.

I've spent years looking for a workflow that made architecture diagrams feel like source code instead of PowerPoint.

This approach is by far the best I've seen.

Not because AI magically solved architecture.

Because it finally solved the tedious part.

AMP Remote Write HTTP 400: The CloudWatch Metric That Solved It

Andrew Eells — Sat, 04 Jul 2026 00:32:05 +0000

AMP said 400. CloudWatch said why.

We turned on Amazon Managed Prometheus (AMP) remote write from our Quarkus services on ECS — Micrometer snapshots, Snappy-compressed Prometheus remote write, SigV4 signing — and everything mostly worked.

Mostly.

Every service logged AMP remote write failed with status 400 on a ~60 second cadence. Not constantly. Not only at startup. Intermittently, across the fleet, continually.

HTTP 400 with an empty body is a frustrating place to start.

This post is how we narrowed it down, why the obvious suspects weren't the culprit, and the CloudWatch metric that finally made the failure mode obvious.

The setup

Forge pushes application metrics in-process:

Micrometer with the Prometheus v1 registry (/q/metrics for local scrape, MetricSnapshots for export)
Remote write to AMP over HTTPS with Content-Encoding: snappy and AWS SigV4 (aps signing name)
One AMP workspace shared by every ECS service in the environment (auth, actor, document, notification, audit, BFF, …)
GraalVM native images on Fargate, private subnets, no collector sidecar

The architecture is deliberate: fewer moving parts, right-sized tasks, metrics, and traces exported directly from the app.

When remote write misbehaves, the failure is somewhere in a short chain: scrape → encode → compress → sign → POST.

What we ruled out first

Wrong URL

A previous deploy had pointed at the wrong path suffix. AMP's real endpoint is:

https://aps-workspaces.<region>.amazonaws.com/workspaces/<ws-id>/api/v1/remote_write

Not .../remote_write alone (that returned 404).

We verified the CloudFormation export, the ECS task environment variable, and a SigV4-signed POST with an empty Snappy payload to the correct URL. That returned 200. So URL and IAM were fine.

SigV4 and transport

The same signing code path used in production (AwsSignedHttpTransport) worked from a JVM probe on a developer machine against the live workspace. Empty payload and full payload both succeeded when credentials and URL were correct.

"A bad metric family"

We scraped live exposition text from a running native task (more on that pattern below), loaded it into a JVM integration test, encoded it with the same remote-write encoder, and POSTed to AMP.

200. Full payload accepted.

So the metric content at scrape time was not inherently toxic. The encoder and Snappy path on JVM were fine.

That left something about the native periodic push path or fleet-wide ingestion behaviour — not a single broken histogram hiding in auth-service.

The pivot: CloudWatch `DiscardedSamples`

AMP exposes vended CloudWatch metrics under the AWS/Prometheus namespace. One of them is DiscardedSamples, with a Reason dimension explaining why samples were dropped.

We listed metrics for our workspace:

aws cloudwatch list-metrics \
  --namespace "AWS/Prometheus" \
  --metric-name "DiscardedSamples" \
  --region us-west-2

The only reason showing material volume:

Reason = new-value-for-timestamp

Querying that dimension:

aws cloudwatch get-metric-statistics \
  --namespace "AWS/Prometheus" \
  --metric-name "DiscardedSamples" \
  --dimensions \
    Name=Workspace,Value=ws-xxxxxxxx \
    Name=Reason,Value=new-value-for-timestamp \
  --start-time "$START" --end-time "$END" \
  --period 300 \
  --statistics Sum \
  --region us-west-2

We saw hundreds of discards per five-minute bucket, sustained, fleet-wide.

That is not a signing bug. It is not Snappy corruption.

In Prometheus remote write semantics, new-value-for-timestamp means: AMP already has a sample for this exact time series (same metric name and label set) at this exact timestamp, but the new sample has a different value.

In Prometheus, a series is defined by the metric name and its complete label set. If two writers produce identical labels, the backend treats them as one time series regardless of which process produced them.

Same series. Same millisecond. Different number. Rejected.

Once we saw that, the intermittent 400s and the ~95% push success rate (success counter climbing, failure counter occasionally ticking) both made sense: most pushes partially or fully conflicted with other writers or stale timestamps; some requests failed hard at the HTTP layer.

The actual bug: six services, one series

Each ECS service exports the same Micrometer binders: jvm_*, process_*, system_*, HTTP server metrics, and our own forge_observability_amp_push_* counters.

We had no common tags — no service, no instance, no pod.

So from AMP's perspective:

auth-service   → jvm_threads_live_threads = 21  @ T
actor-service  → jvm_threads_live_threads = 14  @ T
document-service → jvm_threads_live_threads = 19 @ T

That is one series (jvm_threads_live_threads with identical labels) receiving different values at the same timestamp from different tasks, every push interval, forever.

Classic multi-writer collision.

It is the same class of problem as running multiple Prometheus replicas remote-writing the same targets without external labels — except we did it with six application services and one workspace.

Why the JVM probe didn't catch it

The probe used a single scraped exposition file from one task. One writer. AMP happily ingested it.

The failure mode only appears when multiple tasks push overlapping label sets to one workspace on the same schedule.

Why `hasScrapeTimestamp()` wasn't the story

We also suspected stale per-datapoint scrape timestamps from the registry. On JVM Micrometer scrape, hasScrapeTimestamp() was false for every data point in our tests. The old encoder fell back to System.currentTimeMillis() per sample anyway.

Fleet collision fit the CloudWatch evidence better than stale scrape timestamps.

We still normalized to one batch push timestamp per remote-write request — correct semantics for periodic push export — but the fix that cleared discards was disambiguating series.

The fix

1. Common tags (the real fix)

In forge-kit forge-metrics, a CDI MeterFilter:

MeterFilter.commonTags(
    Tag.of("service", applicationName),   // quarkus.application.name
    Tag.of("instance", hostName)        // ECS task hostname; override via config
);

After deploy, AMP queries looked like:

forge_observability_amp_push_success_total
jvm_threads_live_threads{service="auth-service"}
count by (service) (jvm_memory_used_bytes)

Six services, six distinct label sets. Immediately after deploying the common tags, new DiscardedSamples{Reason="new-value-for-timestamp"} buckets dropped to zero across the workspace while historical buckets retained the earlier collisions. No other code changes were required.

2. Richer failure logging

AmpMetricsExporter had only logged status 400. We added Snappy body size, snapshot count, and AMP response body on failure so the next incident doesn't require guesswork.

3. Batch push timestamp

Remote-write encoding now stamps every sample in a WriteRequest with one wall-clock time at export. That is standard push-agent behaviour and avoids mixed timestamps within a single push. It did not replace the need for service / instance tags.

How we verified ingestion (not just "no errors")

Empty HTTP failures are necessary but not sufficient. We confirmed data was stored and queryable:

QUERY_ENDPOINT="https://aps-workspaces.us-west-2.amazonaws.com/workspaces/${WORKSPACE_ID}/api/v1/query"

awscurl --service aps --region us-west-2 \
  -X POST "${QUERY_ENDPOINT}" \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -d 'query=forge_observability_amp_push_success_total'

Success counters for all six workloads, each with service and instance labels. Failure metric absent (never incremented since deploy). CloudWatch discards at zero post-rollout.

That is the bar: PromQL returns your series with the labels you expect, and DiscardedSamples stays quiet.

Appendix: debugging when you can't reach `/q/metrics`

Our laptops can't hit task private IPs in a NAT-less VPC. To compare native exposition with the JVM encoder, we used a one-off Fargate task pattern:

Publish a tiny private ECR image (busybox + wget) — Docker Hub and public ECR aren't reachable from the VPC without NAT.
Run a task in the cluster that wgets http://<task-private-ip>:8080/q/metrics (same path the target group uses for health checks).
Pull logs into a local file and feed it to a JVM probe (FORGE_AMP_METRICS_FILE=...).

We also briefly added a same-SG ingress on 8080 so the scrape task could reach the service ENI — then revoked it after debugging. That rule is not part of normal infra; ALB → task rules stay as designed.

This tooling was valuable for one INT session. We don't plan to keep the scrape image or scripts in the application repo long term — the durable lessons are the CloudWatch reason dimension, the multi-writer tag discipline, and the PromQL verification queries.

Takeaways

AMP HTTP 400 with an empty body sends you down a long hallway. DiscardedSamples by Reason is often the door.
new-value-for-timestamp on a shared workspace screams label collision — multiple writers, identical series, aligned push intervals.
Micrometer MeterFilter.commonTags with low-cardinality service (and instance when you scale replicas) is not optional when many processes remote-write to one Prometheus-compatible backend.
Single-service probes prove encoding, not fleet behaviour. Reproduce collisions with multi-writer thinking.
Confirm consumption with PromQL and CloudWatch ingestion metrics — not only "the error log stopped."

If you're wiring Micrometer → AMP on ECS, check your tags before you tune Snappy JNI or second-guess your SigV4 implementation.

The platform was fine. We were just telling six services to sign the same name on the same line.

The software nobody plans to build - but every successful team eventually does...

Andrew Eells — Fri, 26 Jun 2026 19:59:56 +0000

Every software company starts with one product.

The product customers buy.

The product investors care about.

The product the roadmap revolves around.

But given enough time, almost every successful engineering team finds itself building something else.

Not because they planned to.

Because they have to.

The second product

It doesn't have a marketing website.

Customers never ask for it by name.

Nobody demos it to investors.

Yet it quietly grows alongside the business.

It's your engineering foundations.

The authentication services.

The deployment pipelines.

The infrastructure.

The observability stack.

The audit logging.

The notification system.

The release processes.

The operational tooling.

The architectural conventions.

Individually, none of these things are your product.

Collectively, they're what allow your product to scale.

It happens one decision at a time

Nobody sets out to spend months building engineering foundations.

Instead, they make perfectly reasonable decisions.

"We'll automate deployments later."

"This service just needs its own authentication for now."

"We'll improve the monitoring once we've got more customers."

"We'll standardise this after the next release."

Every one of those decisions is commercially rational.

Product delivery has to come first.

But each compromise adds another piece to a second codebase that the business never intended to own.

The hidden backlog

Earlier in my career, while CTO at a UK insurance startup, I estimated that around 60% of our engineering backlog wasn't product work at all.

It was engineering foundations.

Improving CI/CD.

Standardising infrastructure.

Strengthening security.

Adding observability.

Operational tooling.

Developer experience.

Performance and security testing.

None of those stories generated revenue directly.

But every one of them made future product delivery faster, safer and more predictable.

Eventually we realised something important:

We weren't just building an insurance platform anymore.

We were also building the engineering foundations that made the insurance platform possible.

The Groundhog Day problem

Over the last 20+ years I've worked across startups, consultancies and enterprise engineering teams.

Different industries.

Different products.

Different company sizes.

Yet I kept rebuilding remarkably similar engineering foundations.

Authentication.

Audit.

Notifications.

Infrastructure.

Deployment pipelines.

Observability.

Release management.

Security controls.

Developer tooling.

Different implementations.

The same problems.

After a while it started to feel like Groundhog Day.

Every organisation was independently solving problems that thousands of engineering teams had already solved before.

Engineering foundations are inevitable

This isn't an argument against building engineering foundations.

They're essential.

Every successful software company eventually needs them.

The question is simply when and how you build them.

Do you invest months (or years) constructing them incrementally while trying to deliver product?

Or do you begin with mature engineering foundations already in place and let your team focus on the capabilities that actually differentiate your business?

That's a very different starting position.

Final thoughts

I've come to believe that one of the biggest hidden costs in software engineering isn't technical debt.

It's repeatedly rebuilding the same engineering foundations.

Not because they're unique.

But because every organisation assumes it has to start from scratch.

That realisation is ultimately what led me to build Forge Platform.

After spending more than two decades repeatedly building the same operational capabilities across startups and enterprise programmes, I wanted to create something that lets engineering teams begin with mature foundations already in place - so more of their time is spent building the product they're actually in business to create.

If that resonates, you can learn more at https://forgeplatform.software.

What "production-ready" actually means - and why most teams discover it too late.

Andrew Eells — Sat, 06 Jun 2026 03:54:10 +0000

"Production-ready" is one of the most misused phrases in software engineering.

It usually means:

it runs
it deploys
it works in a happy path

But in real systems, production readiness is not about functionality.

It’s about behaviour under failure, change, and scale.

The difference between working and production-ready

A system is not production-ready when:

it can be deployed

It is production-ready when:

it can fail safely
it can be observed
it can be redeployed without service interruption
it behaves consistently under load
it can be operated by people who did not build it

Most early-stage systems do not meet this bar.

Not because teams are careless - but because these properties are usually added after the system exists.

The problem with "we'll add it later"

In practice, "later" becomes:

after customers arrive
after scale pressure begins
after incidents expose gaps
after engineering velocity slows

At that point, the system is no longer neutral.

It has opinions:

about structure
about deployment
about observability
about service boundaries

And those opinions are expensive to change.

Where teams actually spend their time

Across multiple environments I’ve worked in — from startups to large AWS-based enterprise systems — a consistent pattern appears:

Engineering effort splits into two categories:

domain / product requirements and features
engineering foundation and operational work

In many early systems, the work that goes into engineering foundations - such as deployments, versioning, build and test standards and optimisations, pipelines etc. - becomes a dominant and usually hidden cost.

At one startup, my estimate was that "technical" stories accounted for the majority of backlog creation over time, eclipsing feature development.

This is not an edge case.

This is how systems evolve.

Why this is so hard to avoid

Most teams don't consciously choose to neglect operational maturity.

The problem is that product work is always visible, while engineering foundations are largely invisible.

A new feature can be demonstrated to customers, investors, and stakeholders. It can be tied directly to revenue, growth, or market validation. Improvements to deployment pipelines, observability, security controls, or operational tooling rarely have that luxury. Their value is indirect, preventative, and often only becomes obvious when something goes wrong.

As a result, engineering teams are under constant pressure to prioritise business-driven outcomes over engineering excellence. Every sprint presents another feature request, customer commitment, sales opportunity, or roadmap deadline competing for attention.

Over time, small compromises accumulate:

Deployment processes remain partially manual because "we'll automate it later."
Monitoring exists, but not at the depth needed to diagnose production issues quickly.
Security controls are good enough for today's customers, but not tomorrow's.
Operational knowledge lives in people's heads rather than in systems and documentation.

None of these decisions are unreasonable in isolation. In fact, most are rational responses to commercial pressure.

The challenge is that operational maturity compounds in exactly the same way technical debt does. The cost of postponing it is often hidden until growth, scale, compliance requirements, or a production incident suddenly expose the gap.

By that point, fixing the foundations is competing with an even larger backlog, a larger customer base, and a business that has become increasingly dependent on systems that were never designed for the level of demand being placed on them.

The real definition of production-ready

A more accurate definition is:

A system is production-ready when its operational properties are designed, not discovered.

That includes:

observability as a first-class concern
consistent service structure and bounded contexts
predictable deployment behaviour
explicit failure handling patterns
security and access boundaries defined early

The uncomfortable truth

Most teams don’t lack capability.

They lack a reusable starting point.

So they rebuild production-readiness repeatedly, instead of inheriting it once.

The shift that matters

The real architectural question is not:

"How do we make this production-ready?"

It is:

"Why are we rebuilding production readiness every time?"

This is the problem space I’ve been focused on with Forge: creating a reusable foundation so teams don’t rediscover production-readiness under pressure.

The real startup killer isn't product — it's building platform foundations from scratch.

Andrew Eells — Fri, 08 May 2026 22:15:14 +0000

There's a pattern I've seen repeat a few times over 20 years building software systems in both startup and enterprise environments.

Most early-stage teams believe they are building a product.

In reality, they are building two things at once:

Their actual product
An internal platform they didn't intend to build

And the second one quietly consumes man-years of engineering time.

The hidden tax on early-stage teams

At some point, every startup hits the same phase:

The MVP works
The first customers arrive
Engineering velocity starts to slow
"Just one more service" becomes a platform discussion

And suddenly the backlog shifts.

Not because the product changed - but because the foundations underneath it needed to evolve (without the wheels falling off!).

Based on greenfield experience, I'd guesstimate that up to 60% of engineering effort can be focused on platform foundations, delivery lifecycle and operational processes, not domain features or core business differentiators.

That ratio is not unusual.

It is normal.

And it is also destructive.

The repeated mistake

Across organisations, I've seen the same systems rebuilt repeatedly:

CI/CD pipelines
Infrastructure-as-code structures
Observability setups
Security and access control patterns
Service templates and API conventions
Deployment and rollback strategies

Each time:

slightly different
slightly inconsistent
always re-learned under pressure
and generally whilst trying to keep production lights on

The irony is that none of these are domain-specific.

They are global engineering concerns.

Yet every team reinvents them.

Why this keeps happening

It's not incompetence.

It's timing.

Early-stage teams optimise for:

speed
product delivery
survival

So they defer platform thinking until it becomes unavoidable.

At which point:

the system is already live
constraints are already baked in
rewrites are expensive

So they rebuild under pressure instead of designing under intention.

The real cost

The cost isn't just engineering time.

It's:

delayed product delivery
inconsistent system behaviour
increased operational risk
premature senior hiring in platform roles
architectural fragmentation across services (and teams)

Most importantly:

It shifts engineering from building product value to managing internal complexity.

What changes when you design it once

When these concerns are treated as a reusable foundation instead of one-off decisions:

teams ship faster
systems stay consistent
operational overhead drops
architecture stops diverging across services
engineering focus returns to product domain logic

This is the problem I've been formalising into an opinionated bootstrap approach with Forge Platform.

It enables production-grade microservices from day one with enterprise foundations at startup speed.

Not because teams cannot build these things.

But because they keep building them repeatedly, under pressure, in slightly different ways, everywhere.

The question I keep coming back to

If every team ends up rebuilding the same foundations…

Why are we still rebuilding them every time?

If you have any questions or are interested to find out more, it would be great to hear from you in the comments or feel free to say hello.

DEV Community: Andrew Eells

Vibe Coding Is Reckless. Defined Architecture Patterns Fix It.

Why vibe coding breaks

Why Backbone fixes it

Where this stops working

Architecture engineering, not prompt engineering

Quarkus + GitHub Actions: Reducing CI Time by Half Without Larger Runners

The baseline was already heavily optimised

Where we started

The wrong instinct: copy the ECS deploy matrix

Prerequisite: LocalStack → Floci

LocalStack startup (older run)

Floci startup (current run)

Step 1: actually forward the Maven flags

Step 2: treat Quarkus boots as a budget

What changed

Step 3: split integration tests by infrastructure

Step 4: stop using Graal where you are not building native images

Step 5: make CI install skip quarkus:build

Step 6: run Failsafe without packaging again

The finish line

What barely moved the needle

The patterns worth stealing

We've Spent 25 Years Shifting Left. The Next Shift Is Down.

Twenty-five years of shifting left

AI isn't really shifting left

The pattern I couldn't ignore

Forge is about shifting down

Left was never the destination

AWS Transform and Superwerker: same vocabulary, different problems

Superwerker: opinionated defaults, shipped

Transform: a different problem

Where Forge sits

A working rule of thumb

How AI finally solved AWS architecture diagrams

The problem with architecture diagrams

Manual diagrams

CDK diagram generators

AWS Workload Discovery

The breakthrough

Cursor did almost all of the work

That's a far harder problem than it sounds

Was it perfect first time?

The hybrid workflow

Why this works

AI finally solved the right problem

Would I trust it blindly?

What's next?

Here's how Cursor did it

Final thoughts

AMP Remote Write HTTP 400: The CloudWatch Metric That Solved It

The setup

What we ruled out first

Wrong URL

SigV4 and transport

"A bad metric family"

The pivot: CloudWatch DiscardedSamples

The actual bug: six services, one series

Why the JVM probe didn't catch it

Why hasScrapeTimestamp() wasn't the story

The fix

1. Common tags (the real fix)

2. Richer failure logging

3. Batch push timestamp

How we verified ingestion (not just "no errors")

Appendix: debugging when you can't reach /q/metrics

Takeaways

The software nobody plans to build - but every successful team eventually does...

The second product

It happens one decision at a time

The hidden backlog

The Groundhog Day problem

Engineering foundations are inevitable

Final thoughts

What "production-ready" actually means - and why most teams discover it too late.

The difference between working and production-ready

The problem with "we'll add it later"

Where teams actually spend their time

Why this is so hard to avoid

The real definition of production-ready

Step 5: make CI install skip `quarkus:build`

The pivot: CloudWatch `DiscardedSamples`

Why `hasScrapeTimestamp()` wasn't the story

Appendix: debugging when you can't reach `/q/metrics`