Are Frontend Developers at Risk? AI Is Already Writing HTML for Us

# Are Frontend Developers at Risk?

## AI Is Already Writing HTML for Us

**Łukasz Piotr Łuczak**
            Software Architect • Consultant • Researcher

DevFest Łódź 2025

---
            > ⚠️ **Repository Archived** — This is a snapshot of the conference experiment.
            > Active development: [github.com/lukaszpiotrluczak/lukaszpiotrluczak.me](https://github.com/lukaszpiotrluczak/lukaszpiotrluczak.me)

<aside class="notes">
              Hi, I'm Łukasz Piotr Łuczak. Three Ł's. It's easier to show you my online business card than to spell my name.

Except... I don't have one. I never had time to build it.

Meanwhile, we keep hearing "AI will replace us." So I thought: let's test that claim. Let's see if AI can build my business card from scratch — a real, production-grade platform.

Oh, and one more thing: these speaker notes you're NOT seeing? Also generated by AI. I'm literally using AI to explain how I used AI. Meta, right?
            </aside>

---

# <span style="-webkit-text-fill-color: #FAD228;">⚠️</span> Repository Status

**This repository is now ARCHIVED**

DevFest Łódź 2025 snapshot — experiment completed.

**Preview the experiment result:**

[lukaszpiotrluczak.github.io/devfest-lodz-2025](https://lukaszpiotrluczak.github.io/devfest-lodz-2025/)

**Active development continues:**

[github.com/lukaszpiotrluczak/lukaszpiotrluczak.me](https://github.com/lukaszpiotrluczak/lukaszpiotrluczak.me)

<aside class="notes">
              Quick note: this repository you're looking at is now archived. It's a snapshot of the DevFest Łódź 2025 experiment.

The project continues at a new repository: github.com/lukaszpiotrluczak/lukaszpiotrluczak.me

All errors and mistakes in this codebase and in this presentation are left intentionally. This is a case study, not a polished product.
            </aside>

---

# The Problem

- No online business card
            - Manual networking is inefficient
            - Scattered social profiles

<aside class="notes">
              As a consultant and speaker, I need to network efficiently. Give people one link, they get everything: bio, contact, talks, publications.

But like many developers, I kept postponing this "simple" project. Too busy. Too many other priorities.

Sound familiar?
            </aside>

---

# The Premise

**"AI will replace us"**

Let's test this claim:
            - Can AI build a production-ready platform?
            - From scratch to deployment?
            - No manual coding?

<aside class="notes">
              We hear this constantly: "AI will replace developers." Twitter debates, conference talks, existential dread.

So instead of arguing, I decided to run an experiment. Can AI actually build a production-ready platform? From zero to deployment? No manual coding?

Let's find out.
            </aside>

---

# The Project

**Digital Business Card Platform**

- Single-link contact hub
            - Bilingual (EN/PL)
            - Mobile-first, SEO-optimized
            - Tabs: Me, Consulting, Contact, Events, Publications
            - Production-grade standards

<aside class="notes">
              Not a toy project. Not a landing page. A real platform with:
              - Bilingual support (English and Polish)
              - SEO and structured data
              - Accessibility standards
              - Security headers
              - CI/CD pipeline
              - Production deployment

This is what production means.
            </aside>

---

# The AI-Assisted Process

**Artifacts Pipeline:**

1. Information Architecture
            2. Brand & Visual Identity
            3. Design Profile (design-profile.json)
            4. Tailwind Theme CSS
            5. HTML Prototypes
            6. Repository DX Setup
            7. Architecture (NestJS + Astro)
            8. Implementation

</div>

<aside class="notes">
              This wasn't "ChatGPT, write me a website."

It was a structured, phased workflow — the same process I'd use with a human team:
              Discovery → Brand identity → Design system → Prototypes → Architecture → Implementation

Each phase produced artifacts that fed into the next. Information architecture document. Design profile JSON. Tailwind theme. HTML prototypes.

This is how you build real software. With or without AI.
            </aside>

---

# Key Constraint

**No manual fixes — only prompts**

- Every change via AI prompt
            - Follow-up prompts for refinement
            - Execution logs replaced chat logs
            - Quality gates made issues visible

<aside class="notes">
              Here's the rule I set for myself: I intentionally did not manually fix the code. Only prompts and follow-up prompts.

If CI failed, I couldn't just edit the file. I had to describe the problem to AI and let it fix it.

Once AI had write access to the repository, execution logs replaced chat logs. No more copy-paste. Just prompts and git commits.

This constraint forced me to test AI's real-world capability, not its ability to generate code snippets.
            </aside>

---

# Friction Point 1

**pnpm Version Conflict**

- CI specified `version: 9`
            - package.json specified `pnpm@9.15.0`
            - pnpm/action-setup@v4 detected conflict

**Solution:**
            Remove CI version, use package.json as single source of truth

<aside class="notes">
              First failure. CI blew up: "ERR_PNPM_BAD_PM_VERSION."

Why? The workflow specified pnpm version 9. The package.json specified pnpm 9.15.0. Both are correct, but they conflict.

AI debugged it: remove the redundant version from CI, use package.json as single source of truth.

Lesson: CI didn't break the build — it revealed a missing assumption about how pnpm/action-setup works.
            </aside>

---

# Friction Point 2

**Missing pnpm Lockfile**

- CI ran pnpm install
            - No pnpm-lock.yaml committed
            - Non-deterministic builds

**Solution:**
            Generate and commit pnpm-lock.yaml

<aside class="notes">
              Second failure. "pnpm install" ran, but builds weren't deterministic.

Why? No lockfile. Dependencies floating. Classic mistake.

AI generated and committed pnpm-lock.yaml. Fixed.

Lesson: Reproducibility requires explicit state. AI knows this. Do you always remember?
            </aside>

---

# Friction Point 3

**Prettier Format Check Failures**

- AI-generated code wasn't formatted
            - CI format check failed

**Solution:**
            Run pnpm run format:fix before commit

<aside class="notes">
              Third failure. Prettier check failed.

AI-generated code was syntactically correct. But it didn't match the project's formatting rules.

Solution: run "pnpm run format:fix" before commit. Done.

Lesson: Quality gates caught this immediately. Without them, the codebase would drift into chaos.
            </aside>

---

# Friction Point 4

**ESM/CommonJS Module Mismatch**

- NestJS built as ESM
            - Astro SSR adapter expected CommonJS
            - Runtime crash: "Cannot use import outside module"

**Solution:**
            Add build:postprocess to write package.json with type: commonjs

<aside class="notes">
              Fourth failure. Runtime crash: "Cannot use import statement outside a module."

Why? NestJS built as ESM. Astro SSR adapter expected CommonJS. Module system mismatch.

This one required multiple prompts. AI debugged it, but it wasn't obvious. Complex runtime issues are still hard for AI.

Solution: add a postprocess step to inject `{type: "commonjs"}` into the build output.
            </aside>

---

# What Works Today

- ✅ Bilingual SPA (EN/PL)
            - ✅ Tabs with icon + label
            - ✅ Light/Dark mode
            - ✅ SEO metadata + JSON-LD
            - ✅ Security headers (CSP, HSTS)
            - ✅ Contact form API (stub)
            - ✅ CI/CD quality gates
            - ✅ Coolify-ready deployment

</div>

<aside class="notes">
              So what actually works?

All of this. Bilingual SPA. SEO metadata. Security headers. Contact form API (stubbed, but structured). CI/CD quality gates. Deployment-ready.

It's not pretty yet. The design needs polish. But it's functional, secure, and production-grade.

And that's exactly what I asked for.
            </aside>

---

## It works.

![Personal page showing bio, roles, and navigation](./screenshots/me-page.png)

<aside class="notes">
              Here's proof. This is the personal page — bio, roles, links. All functional.

It works. You can navigate. You can read the content. You can click the links.

Is it beautiful? No. But that wasn't the goal. The goal was: can AI scaffold a production-grade platform? Yes.
            </aside>

---

## Still functional.

![Company page with service areas and registry information](./screenshots/company-page.png)

<aside class="notes">
              Company page. Service areas, registry information (KRS, NIP, REGON), address. All the data is there.

Buttons work. Navigation works. i18n works (this is the Polish version).

Ugly? Sure. But structured, accessible, and ready for design polish later.
            </aside>

---

## This is fine.

![Contact form with validation and topic selection](./screenshots/contact-page.png)

<aside class="notes">
              Contact form. Name, email, topic dropdown, message textarea. Form validation works. It submits to the API.

Does the button look like 2015? Yes. Does it work? Also yes.

This is what I mean by "AI can scaffold infrastructure." The hard part — architecture, security, accessibility — is done. Making it pretty is the easy part.
            </aside>

---

# What's Intentionally Unfinished

- ⏳ Contact form email integration (stub only)
            - ⏳ CAPTCHA (planned, GDPR-friendly)
            - ⏳ CSP hardening (remove unsafe-inline)
            - ⏳ Analytics (privacy-first, post-MVP)

<aside class="notes">
              What's intentionally unfinished?

Contact form email integration — it logs to console instead of sending emails. CAPTCHA — not implemented yet. CSP hardening — still allows unsafe-inline for now.

The app works. It doesn't look good yet. And that's fine for this demo.

The goal was to test AI's ability to scaffold production infrastructure, not to over-engineer every detail.
            </aside>

---

# The Repository as the Product

**Everything is public:**

- All prompts (prompts/)
            - All conversation logs (conversations/)
            - All design artifacts (docs/)
            - All code (app/)
            - All CI failures and fixes

**[github.com/lukaszpiotrluczak/devfest-lodz-2025](https://github.com/lukaszpiotrluczak/devfest-lodz-2025)**

</div>

<aside class="notes">
              The repository IS the product of this talk.

Everything is public: all prompts, all conversation logs, all design artifacts, all code, all CI failures and fixes.

You can trace the entire journey. See where AI succeeded. See where it struggled. See how I guided it.

Full transparency. No cherry-picking. This is the real story.
            </aside>

---

# Key Lessons

**AI accelerates, but needs guidance**

- AI is a powerful tool, not a replacement
            - Quality gates are essential
            - Humans steer strategy and architecture
            - Works best for structured, well-scoped tasks
            - Struggles with runtime debugging and edge cases

<aside class="notes">
              So what did I learn?

AI didn't replace me. It accelerated me. I still made every architectural decision — NestJS vs Express, Astro vs Next, build strategy, security headers.

AI executed. I directed. Quality gates kept us honest.

Works best for structured, well-scoped tasks. Struggles with runtime debugging and architectural edge cases.

It's a powerful tool. Not a replacement.
            </aside>

---

# The Honest Takeaway

**Can AI replace frontend developers?**

- ❌ Not for complex, production systems
            - ✅ For simple, well-defined tasks
            - ✅ As an accelerator with human oversight
            - ✅ When paired with quality gates

**Developers who use AI > Developers who don't**

<aside class="notes">
              Can AI replace frontend developers?

No. Not for complex, production systems. Not yet. Maybe never.

But can it make you faster? Absolutely. If you know how to guide it. If you have quality gates. If you understand what you're building.

The real question isn't "Will AI replace us?" It's "Will developers who use AI effectively replace those who don't?"

I think we know the answer.
            </aside>

---

# Thank You

**Explore the archived repo:**

[github.com/lukaszpiotrluczak/devfest-lodz-2025](https://github.com/lukaszpiotrluczak/devfest-lodz-2025)

**Connect:**

- [lukaszpiotrluczak.me](https://lukaszpiotrluczak.me)
            - [linkedin.com/in/lukaszpiotrluczak](https://linkedin.com/in/lukaszpiotrluczak)
            - [github.com/lukaszpiotrluczak](https://github.com/lukaszpiotrluczak)

**Support this work:**

[buymeacoffee.com/lukaszpiotrluczak](https://buymeacoffee.com/lukaszpiotrluczak)

</div>

<aside class="notes">
              That's it. Thanks for listening.

Explore the repo — everything is there. Prompts, logs, code, mistakes, fixes. The full story.

If you found this experiment valuable, consider supporting my work on Buy Me a Coffee.

Questions?
            </aside>