DEV Community: Anna Hartung

AI Writes the Code Now — Which Is Exactly Why Architecture Matters More

Anna Hartung — Wed, 10 Jun 2026 14:03:58 +0000

By Anna Hartung — H-Studio Berlin

There's a comfortable story going around: AI coding tools made architecture less important. If you can generate a feature in thirty seconds and regenerate it when it breaks, who cares about clean boundaries? Just vibe it.

The data from 2024–2025 tells a less comfortable story. We're producing code faster than ever — and a measurable amount of it is the kind you pay for later. AI didn't make architecture optional. It made the lack of it cheaper to create and more expensive to live with.

What the data actually shows

GitClear's 2025 report, analyzing over 200 million changed lines of code, found a few things worth sitting with:

Copy-pasted code overtook refactored ("moved") code for the first time in 2024. Cloning rose while restructuring fell.
Refactoring collapsed — lines associated with refactoring dropped from about 25% of changes in 2021 to under 10% in 2024.
Duplicate code blocks spiked — the frequency of copy-pasted blocks rose sharply as AI assistants went mainstream (devclass summary here).
Churn went up — the share of new code revised or reverted within two weeks of being committed climbed year over year, a proxy for "shipped before it was understood."

Academic work is pointing the same direction: a 2025 study on vibe coding in practice documents the flow benefits and the technical-debt cost, and argues for guidelines to keep it sustainable.

None of this says AI coding is bad. It says AI optimizes for producing code, and producing is not the same as structuring.

Why AI pushes you toward duplication, not design

It's not mysterious once you look at the mechanics.

AI generates; it rarely refactors. Asked for a feature, a model gives you a working block. Asked for a similar feature, it gives you another working block — not "extract the shared logic from the first one." Left unchecked, that's literally how you get a 4x rise in duplication.

It optimizes locally. A model is brilliant at the next function and blind to your system. It doesn't know that the thing it just wrote belongs behind an existing interface, or that you already have a service for this.

It removes the friction that used to force structure. Writing the third near-identical handler by hand used to hurt enough that you'd stop and abstract. Generation removes the pain — and with it, the signal that told you to refactor.

Review degrades. When code arrives faster and "looks right," reviewers rubber-stamp more. The fast path is to approve, not to ask "should this exist at all?"

What this means for how you build

The counter-move isn't to ban AI — it's genuinely a productivity unlock. The move is to put the human effort where the model is weakest: structure.

Keep architecture decisions human and explicit. Boundaries, the data model, public interfaces, where state lives — these are the expensive-to-change decisions, and they're exactly what AI won't make well for you. Decide them deliberately, up front.
Treat AI like a very fast junior. Fantastic at filling in a well-defined function. Not the one you let define your module boundaries or your schema.
Make refactoring and de-duplication explicit review criteria. "Does this duplicate something we have?" and "does this belong behind an existing interface?" should be checklist items, not vibes.
Defend test coverage. Generated code without tests is the fastest way to build something nobody dares to touch in six months.
Watch churn as a signal. If lots of fresh code is being rewritten within days, that's not velocity — it's rework wearing velocity's clothes.

The architecture-first take

Here's the reframe. In a world where typing code was the bottleneck, "just write it" was a defensible default. Now that generating code is nearly free, the bottleneck moves entirely to the decisions code can't make for itself: what the system is, how its parts relate, what's allowed to depend on what. Those decisions were always the expensive ones. AI just stripped away the manual labor that used to hide how much they mattered.

So the studios and teams that win the next couple of years won't be the ones that generate the most code. They'll be the ones whose generated code lands inside an architecture good enough to absorb it — instead of turning into the 12-month rewrite the churn numbers are quietly predicting.

Use the AI. Keep the architecture human. That's the whole playbook.

I'm Anna Hartung, founder of H-Studio, an architecture-first engineering studio in Berlin. We spend a lot of our time making sure fast-moving code lands on a structure that can hold it.

Sources: GitClear AI Code Quality 2025 · devclass · arXiv 2512.11922

Keep Your Source of Truth in the Database, Not in Files: A Pattern for Document-Heavy Apps

Anna Hartung — Wed, 10 Jun 2026 14:00:43 +0000

Most apps that handle a lot of documents — client portals, legal and case systems, funding or insurance workflows, anything with uploads and approvals — quietly drift into the same anti-pattern. The files become the real state of the system. The "status" of a case is whatever the latest PDF in the folder says. Who's allowed to see what is decided by where a file lives. The database, if there is one, ends up as a thin index over a pile of documents.

It feels natural, and it's a trap. Here's the pattern we reach for instead, and why it pays off.

The rule: the database is the system of record; files are just managed assets

State lives in the database. Documents live in object storage. The database owns the truth — statuses, ownership, permissions, the activity history — and each file is represented by a row with metadata and access rules, not by its existence in a folder.

Concretely:

Every domain object is a real record — case, request, task, agreement, billing state — with explicit status fields and transitions, not implied by which documents exist.
Files are assets, referenced from the database. The blob sits in object storage; the row holds the metadata, the owner, the permissions and the link.
Access is checked against the data model, by role and relationship — "can this user see this record," not just "is this user logged in."
State changes are logged as events. Sensitive transitions write an activity record, so "who did what, when" is a first-class part of the system.

Why it's worth the extra work

Auditability. When the truth is in the database and transitions are logged, you can answer "what happened to this case and who touched it" precisely. A folder of files can't tell you that.

Access control becomes possible. You can't reliably enforce "this paralegal sees only their assigned cases" when permission is a function of folder structure. When access is a check against records and relationships, you can.

Integrity. Documents get renamed, re-uploaded, deleted. If they're your source of truth, every one of those is a potential corruption of state. As assets pointed to from authoritative records, they're replaceable without losing the truth.

You can actually reason about the system. Statuses, transitions and ownership in a schema are something you can query, validate and test. "The newest PDF wins" is not.

A minimal shape

You don't need anything exotic. A typical version:

Postgres (or similar) as the single source of truth for records, status, permissions and events
Object storage (S3-style) for the file bytes
A metadata row per file: owner, related record, type, access scope, timestamps
Role- and relationship-based access checks on every protected route
An append-only activity log for sensitive state changes

The expensive-sounding parts — the event log, the per-record access checks — are cheap to add at the start and very painful to retrofit once files have already become your de-facto database.

The trade-offs (so this isn't a sales pitch)

This pattern is overkill for a simple file share or an internal tool three people use. If there are no real roles, no compliance surface and no need to audit, a folder and a spreadsheet are fine — don't build a state machine to store five PDFs.

It earns its keep the moment you have multiple roles, sensitive data, approvals, or anyone who will later ask "who saw this and when": legal, healthtech, fintech, B2B client portals, anything touching personal data under GDPR. That's exactly where the file-as-truth approach fails most expensively.

The one-line version

If a document determines what your system does — who can act, what state something is in, what happens next — that decision belongs in your database, with the file as a managed asset hanging off it. Treat files as the source of truth and you've built a filing cabinet. Treat the database as the source of truth and you've built a system.

I'm Anna Hartung, founder of H-Studio, an architecture-first engineering studio in Berlin. We build document- and workflow-heavy platforms where this distinction is usually the difference between a product and a mess.

Building for the Surge — What We Learned Architecting a System for 10,000+ Users at Once

Anna Hartung — Wed, 23 Apr 2025 10:55:03 +0000

Building for the Surge: Architecting for 10,000+ Users at Once

When tickets for a big event go on sale, traffic doesn’t gradually increase.

It spikes.

All at once. Thousands of people hitting Buy Now in the same moment.

That’s the scenario we had to design for when building EventStripe — a ticketing platform with one key constraint:

The system had to stay responsive under 10,000+ concurrent users within the first minute.

This wasn’t about long-term scalability or graceful degradation.

It was about surviving the first 60 seconds.

What we focused on

We’ve worked on plenty of high-load platforms before, and we stick to a few architectural rules when the stakes are this high:

Isolate traffic domains

We split payments, seat reservations, and admin panels into separate services. No shared failures, independent scaling.
Use queues and prioritize

Payment spikes aren’t just traffic — they’re money. We used retry logic, backoff strategies, and metrics to keep the system graceful under pressure.
Make monitoring a first-class citizen

Grafana dashboards and ELK logs gave us zone-level visibility in real time. Saturation. Queue depth. Error rates. If it blinked — we saw it.
Don’t fear launch-day deploys

Jenkins pipelines with rollback and canary options gave us confidence. If something had to change mid-spike, we were ready.
Simulate real chaos

Load tests weren’t theoretical. We mimicked real user flows, used real API limits, and stress-tested until the system stopped blinking.

Stack (if you’re curious)

Java 20 + Spring (backend)
Next.js (frontend)
Docker + Kubernetes
Jenkins, Grafana, ELK

We ran tests simulating 9,000+ active users.

The system held.

No slowdowns. No unhandled spikes. Just tickets sold.

It’s not a magic formula — just careful architecture and a lot of rehearsal.

Have you built for traffic surges before?

What helped your system survive?

This project was designed and tested by our team at H‑Studio, where we focus on building resilient, high-load systems for SaaS and platforms.