DEV Community: Ecaterina Sevciuc

AI: A Threat or a Mirror of Our Own Mistakes? A Perspective Through Economics and Law

Ecaterina Sevciuc — Sun, 12 Apr 2026 14:26:28 +0000

Introduction

It is hard to open a news feed today without encountering apocalyptic predictions: AI will take our jobs, AI is "hallucinating," and AI will finally destroy what's left of our privacy. This has evolved into a form of mass hysteria. However, as a developer with a background in law and banking, I see the situation differently. To me, AI is not the cause of the crisis, but a logical consequence of how we have been constructing the digital world over the last few decades.

1. The Law of Supply and Demand: The Information Explosion

The first law of economics is simple: supply follows demand. We live in an era of unprecedented information overload. The sheer volume of data is so immense that the human brain, even a brilliant one, is physically incapable of processing it in time to draw correct conclusions.

In today's world, time is money, and modern realities dictate that you should have known everything "as of yesterday." AI emerged at just the right time as an answer to this demand. It is not a threat, but a "super-filter"—a tool that helps us navigate the ocean of information we created ourselves.

2. The "Cybersecurity" Bubble

For decades, we have lived within an inflated bubble of perceived security. The digital world was built on data: corporations needed user information for profit, leading to the creation of apps, games, and services where registration and the surrender of personal data became mandatory.

All of this was wrapped in the beautiful slogan of "cybersecurity." In reality, however, this was often mere "Security Theater"—protecting corporate interests rather than the client. We inflated this bubble ourselves, trading privacy for convenience because "that's just how it works" now. It is time to break this cycle: we must stop thinking only about monetization and finally focus on real security architecture. And this is exactly where AI can become our strongest ally, helping us design systems that don't collapse like a house of cards at the first sign of trouble.

3. The Point of No Return: A Digital "Minsky Moment"

In economics, there is a concept describing the sudden collapse of an unstable system — the Minsky Moment. It is the instant when a structure that seemed stable suddenly proves fragile under the weight of its own debts or errors. The more the bubble of illusions was inflated, the more tangible its correction becomes.

The emergence of AI has exposed a massive "Information Asymmetry": it turns out that those who promised to protect us often lacked a solid foundation themselves. AI doesn't "steal" data in the classical sense; it simply extracts and systematizes what is already in the public domain. This accessibility was created by people, not algorithms. Blaming AI for a lack of security is like blaming a librarian for a library having too many bad books. The librarian didn't write them; they just help you find them.

Conclusion: The Red Pill of Reality

In "The Matrix," Morpheus offered a choice between the blue pill and the red pill. Perhaps AI is that very "red pill." It is uncomfortable to admit that our security concepts have collapsed, so it's easier to shift the blame onto a "soulless machine" that cannot talk back.

But acknowledging a mistake is the first step toward fixing it. Instead of fighting AI, we should use it as our most experienced consultant. We should ask: "How can we rebuild the system so that protection is real, not just a marketing slogan?" Perhaps this "librarian" is exactly who we need to finally bring order to our own digital home.

The Invisible Scales: A Frontend Art Performance on Gender Equity

Ecaterina Sevciuc — Mon, 30 Mar 2026 13:52:37 +0000

This is a submission for the 2026 WeCoded Challenge: Frontend Art

1. The Motto: "Insanity and Courage"

As my daughter often says, my motto for this life chapter (and especially this project) is "Insanity and Courage".

To be honest, I never saw myself participating in something like this. My previous attempt at the first stage of this challenge, Echoes of Experience, was met with such a "polite silence" in terms of reactions that it felt like a clear hint: "Maybe you're in the wrong garden, Katya."

But then, the idea for this visual performance hit me. It was so persistent that it wouldn't let me sleep. I didn't think about how I would build it; I just knew I had to. And that’s when the "real fun" began...

2. The Artistic Vision: Scales of Reality

The central motif of this installation is a pair of scales that remain visually balanced by design. This represents formal, legal equality in the workplace. However, the true story is told through the falling items:

The "Second Shift": While both sides show equal professional standing (the laptops), the female side is gradually overwhelmed by the "invisible" weight of unpaid domestic labor.
The Invisible Burden: Falling household items (strollers, pans, appliances) represent the mental load and multitasking that often fall disproportionately on women.
Pressure & Stress: The pulsing gender symbols and the darkening gradient are visual metaphors for the mounting systemic pressure that grows as responsibilities multiply.
The Finale: A theatrical ending serves as a reminder: we all see the imbalance, we all acknowledge it, yet the cycle continues. This piece is a call to look closer at the "hidden" side of the scales.

3. The Performance (Video)

4. Project Structure & The "Renovation Budget" Rule

If you’ve ever done a home renovation, you know the rule: calculate your budget and time, then multiply by two. If you’re lucky.

My "renovation" of this code was supposed to take a week. It took that week plus another 8 days of pure troubleshooting.

The Tech Stack:

Vanilla JavaScript (No libraries, just raw logic).
CSS Custom Properties for deep design tokens.
SVG for the scales architecture.
AudioDirector Class for rhythmic synchronization.

5. The "Behind the Scenes" Struggles

Here is a list of things that made me want to pull my hair out (and how I fixed them):

The Z-Index Layer Cake: Managing 6 layers of depth was like hell’s accounting. Making sure a falling pan lands inside the scale pan—behind the front rim but in front of the back wall—required a level of CSS discipline I didn't know I possessed.
The Spiral of Despair: I tried doing the spiral fall with pure CSS. My laptop almost turned into origami. I switched to a JS-based spiral using polar coordinates ($r = a + b \cdot \theta$) and requestAnimationFrame. No more "jumping" icons!
The Zoom Conflict: Scaling the body messed up every absolutely positioned element. I had to create a dedicated .page__zoom container and move the entire universe inside it.
Audio-Visual Sync: My discrete zoom felt "soft" and lagged behind the music. I had to implement a "Snap Mode" and fine-tune parameters like frontloadFactor and leadSeconds to make the zoom feel snappy and anticipatory.
The Ghost of Backgrounds: At one point, the background just stopped showing up on restarts because of a conflict between body and .start-overlay. I had to clear the document background and move all scene-active styles into a predictable CSS class.

6. Repository & License

You can find the "gory details" of my code here:
👉 GitHub: wecoded-gender-art-2026 (https://github.com/kate8382/wecoded-gender-art-2026.git)
The project is shared under the MIT License (yes, the one I have on GitHub—feel free to use it, just don't blame me for the z-index trauma!).

7. Conclusion

In the end, despite the headaches, the minutes of total despair, and the constant internal question—"Why am I doing this to myself?"—I am incredibly glad I reached the finish line.

Regardless of the contest results, I am proud of this work. It might not look exactly like the "perfect" version I initially imagined, but it is a living, breathing visualization of a thought that was important to me. I survived the 8-day budget overrun, and I’m still standing.

P.S. No laptops or chipmunks were harmed in the making of this project. 🐿️💻

How I migrated my pet project to TypeScript, or Katya in Wonderland

Ecaterina Sevciuc — Fri, 13 Mar 2026 17:23:09 +0000

This is a submission for the 2026 WeCoded Challenge: Echoes of Experience

I’ve finished my TypeScript course!.. But there's no need to congratulate me yet...

At first, I thought that after JS, nothing could surprise me anymore. When you read the textbook and look at the examples, you think: “Oh, everything's clear!”. But then you look at a blank file in VSCode and have no idea what to write: the textbook examples don’t seem to apply, and my imagination (or experience) is just not there. And on top of that: my logic seems to be acting up, too! 😂

In moments like these, you feel like Alice in Wonderland — the further you go, the “curiouser and curiouser” it gets. But at least Alice had a Caterpillar who helped her adapt to the situation — by offering mushrooms! 😂 But I have no caterpillar, and certainly no mushrooms.

❓ But in all seriousness:

Why is TypeScript a separate topic from JavaScript? If the goal is reliable code, wouldn't it be more logical to start learning with a typed approach right away, so that all the "Alices" out there learn on safe examples from the start?

If TypeScript is just a superset of JS, where is the boundary — should you learn "pure JS" first and then TS, or just take TS as your primary language?

Which JS weaknesses actually hinder production, and does TS really solve them all?

Do TS types actually help catch bugs earlier? And how much do they complicate fast, JS-style prototyping?

📁 About the project:

The migration goal: To increase code reliability, unify types between the frontend and backend, and simplify refactoring — that’s if we're putting it nicely and professionally.
But if we're being blunt: I just wanted to finally understand what TS is and "what you eat it with" (how it actually works) 😂

📁 What I migrated:

Frontend: UI and log display logic:

export interface ErrorItem {
  id: string;
  message?: string;
  status?: string;
  type?: string;
  firstSeen?: string;
  lastSeen?: string;
  [k: string]: unknown; // For those unexpected Wonderland surprises
}

Backend: handlers, API contracts, validation:

export interface CreateErrorRequest {
  message: string;
  stack?: string;
  type?: string;
  apiKey?: string;
  projectId?: string;
  user?: string;
}

Build configs and types for external libraries

📁 Key changes and approach:

Moved shared types into a single module so that front and back use the same data model.
Enabled strict: true in tsconfig and did a gradual migration using allowJs.
Added types for API responses and log structures.

📁 What I’ve learned (at least, I really hope so!):

✔️ Types act as documentation and prevent errors at early stages.
✔️ Iterative migration with small PRs saves time.
✔️ Shared types between layers reduce the number of runtime errors.

❗ Conclusion: A total brain-melt and "bleeding eyes" are guaranteed for quite some time!

You can find the code and all the details here: https://github.com/kate8382/error-logger-viewer.git

"Thank you for reading my Alice-inspired journey! I’m still looking for answers to the 4 questions above. If you have any thoughts, experiences, or even the wildest metaphors to share, I’d be happy to hear them in the comments!"

Error Logger & Viewer — tiny SPA for tracking JS errors

Ecaterina Sevciuc — Fri, 31 Oct 2025 18:54:07 +0000

TL;DR: Tiny SPA to capture and group browser JS errors — filters, charts, demo and server modes. Try the "Create test error" button on the demo: https://kate8382.github.io/error-logger-viewer/

Why I built it

What happens when a small idea turns into a few months of late‑night debugging? I wanted a lightweight tool that helps developers see runtime problems quickly, group similar errors, and track fix progress. The app runs in two modes: demo (localStorage) for quick tests and server (Node.js + Express + LowDB) for persistent storage.

What it does

Captures global JS errors (window.onerror, onunhandledrejection), resource load errors, and fetch failures.
Groups and deduplicates errors by message/stack to reduce noise.
Searchable, sortable error table with status tracking (new / in progress / fixed / ignored) and comments.
Charts for error dynamics (day/week/month), visual filters and quick actions.
Supports light/dark themes and i18n (EN/RU).
Accessibility features: ARIA labels and keyboard navigation.
Tests: Jest (unit) and Cypress (E2E). CI via GitHub Actions.

Quick architecture

Frontend: vanilla ES6 + Webpack, modular components for table, charts and modals.
Backend (optional): Node/Express + LowDB for a simple REST API. Client switches between demo (localStorage) and server modes via a small adapter.

Demo & source

Live demo: https://kate8382.github.io/error-logger-viewer/
Source: https://github.com/kate8382/error-logger-viewer

Screenshots
Dashboard — overview, quick stats and theme example.

Error table — search, sorting, status and actions.

Charts — error dynamics by period (week/month/year).

Lessons learned

Grouping errors across browsers and minified stacks is tricky — tests and careful matching rules help a lot.
Small UX details (filters, inline status change) make the tool useful for teams.
Next steps: add a project registration flow (projectKey + drop‑in client snippet) and a lightweight admin to manage multiple projects.

Feedback welcome — what metrics would you add to a simple error dashboard?