Mert

I’m a full-stack developer with 10+ years of experience. I use Angular on the frontend. I faced an issue that I experience in my everyday routine, even when I have powerful tools like Codex.

Refactoring old UI to a new frontend was painful for me. I can vibe-code complex business logic, but I can’t pull markup pixel-perfect into a new codebase in seconds. Put screenshots to the Codex and have 80% confidence output + time for editing it – this is the bottleneck for me.

I built a Chrome extension that converts any interface into plain Tailwind HTML. It began as my personal tool, which I use to pull plain Tailwind into a new codebase. Then it turned out that it’s not that simple: the web has a lot of markup cases, pseudo-elements, complex gradients, SVGs, authored styling priorities, etc.

It turned out that I built something big, and I wanted to share my pain and solution with you. Also, the inspiration that today it’s possible to build tool in one month. Eventually, people will solve their pain as you solve yours.

Few insights about my extension:

• 95% code wrote AI
• 700+ commits created
• 40~ commits daily
• 400+ regression tests
• Developed in 1 month
• Automated self-learning
• Automated regression testing
• Automated parallelism for scheduled testing/learning
• Keeps improving every day
• First buy from guy I don’t know, but feel thankful for him very much!

What the purpose:

• Refactor legacy UI without changing it appearance
• Pull any good UI element from any website, or even whole website
• Use this as the entry point for your AI – agents are understanding Tailwind better than screenshots
• Convert any AI output with inline styles, dirty code to plain Tailwind
• Customer wants like in that WOW website – got it, pull and paste to your project

Now I can pull whole Github page and convert it to Tailwind html in seconds, which is not Tailwind based and obfuscated.

Also, I made a few simple tools that help convert existing code to Tailwind. They’re support preview, fullscreen, really complex sources. Also they have responsive support, so you can shrink your side window and use them in parallel. They’re completely free, enjoy!

HTML/CSS to Tailwind:
https://tailfind.org/html-css-to-tailwind

CSS to Tailwind:
https://tailfind.org/css-to-tailwind

Bootstrap to Tailwind:
https://tailfind.org/bootstrap-to-tailwind

Now I want to add output configuration, like apply prefixes, units (px/rem), etc..

Would love to hear your feedback or suggestions for improvement.

For years, the status quo of interacting with Ethereum protocols has been a security nightmare masquerading as a routine task. You open a frontend, click “Swap” or “Stake,” and your hardware wallet prompts you to sign a blob of unreadable hexadecimal data.

You are blind signing. You are trusting that the frontend hasn’t been compromised, that the RPC URL hasn’t been poisoned, and that a malicious actor hasn’t swapped out the destination address or function arguments. When the Lazarus Group drained $1.4 billion from Bybit, they didn’t break cryptography; they exploited this exact UI gap. They tricked users into blind signing data that did something entirely different from what was shown on the screen.

The Ethereum Foundation, alongside an industry working group (including Ledger, Cyfrin, MetaMask, and Trezor), launched Clear Signing—a unified security standard designed to enforce the principle of “What You See Is What You Sign” (WYSIWYS).

This deep dive breaks down the technical layer of this release: ERC-7730, ERC-8213, and how they work together to eliminate blind signing without forcing on-chain breaking changes.

1. ERC-7730: The Clear Signing Metadata Standard

Originally proposed by Ledger and now under the stewardship of the Ethereum Foundation’s Trillion Dollar Security Initiative, ERC-7730 establishes a standardized, machine-readable JSON format that describes exactly what a smart contract’s function calls and EIP-712 typed messages mean in plain text.

Because this metadata lives entirely off-chain, it requires zero changes to existing smart contracts.

How It Works Under the Hood

Wallets and hardware devices cannot natively store the ABIs and translation logic for millions of deployed contracts. ERC-7730 solves this by creating a highly structured schema that maps raw calldata bytes to human-readable display formats.

An ERC-7730 file is broken down into three core blocks:

1. Context: Binds the descriptor to specific contract deployments across multiple EVM chain IDs.
2. Metadata: Contains high-level project data (e.g., protocol name, official legal entity, canonical URLs).
3. Display: The execution mapping logic. It dictates how function selectors and specific parameters are parsed and rendered on a wallet UI.

Here is a simplified architectural look at how a descriptor file (calldata-SwapRouter.json) maps execution data:

{
  "$schema": "[https://eips.ethereum.org/assets/eip-7730/erc7730-v2.schema.json](https://eips.ethereum.org/assets/eip-7730/erc7730-v2.schema.json)",
  "context": {
    "$id": "uniswap-v3-router",
    "contract": {
      "deployments": [
        { "chainId": 1, "address": "0xE592427A0AEce92De3Edee1F18E0157C05861564" }
      ]
    }
  },
  "metadata": {
    "owner": "Uniswap Labs",
    "info": { "url": "[https://uniswap.org](https://uniswap.org)" },
    "contractName": "SwapRouter"
  },
  "display": {
    "formats": {
      "0x415565b0": {
        "title": "Swap Exact Tokens for Tokens",
        "description": "Swaps {amountIn} of {tokenIn} for at least {amountOutMin} of {tokenOut} via route {path}."
      }
    }
  }
}

The Neutral Registry and Attestation (ERC-8176)

Metadata files are a security asset in their own right. If a malicious actor submits a fraudulent ERC-7730 file that translates a transferFrom(all_your_tokens) call into a display message that says “Claim Free Airdrop”, the system breaks.

To prevent this:

• The Ethereum Foundation hosts a central, open-source registry at Clearsigning.org.
• ERC-8176 introduces an attestation framework built on top of the Ethereum Attestation Service (EAS). Independent security firms and auditors review these JSON files against verified on-chain code and cryptographically attest to their validity. Wallets can then choose which independent auditors they trust before displaying the translation to the user.

2. ERC-8213: The Bytes-Level Fallback

ERC-7730 works perfectly when a contract is known, indexed, and audited. But what happens when you are interacting with an immutable, freshly deployed contract, a highly custom gas-optimized protocol using packed encodings, or an air-gapped system where the wallet cannot fetch the latest JSON descriptor?

If ERC-7730 cannot resolve the metadata, the wallet falls back to ERC-8213.

Authored by Cyfrin, ERC-8213 addresses a physical human vulnerability: eyeballing raw hex data fails. Humans cannot effectively verify 500 bytes of calldata on a small hardware wallet screen without missing an altered character.

Instead of displaying the entire unreadable byte string, ERC-8213 enforces that wallets calculate and display short, reproducible cryptographic fingerprints called Digests.

The Calldata Digest Formula

For standard transactions containing calldata, ERC-8213 specifies a strict, length-prefixed hash calculation:

$$text{calldataDigest} = text{keccak256}(text{uint256}(text{len}(text{calldata})) mathbin{Vert} text{calldata})$$

By prefixing the raw calldata bytes with their explicit 32-byte length representation before hashing, it eliminates length-extension vulnerabilities and provides a deterministic snapshot of the execution vector.

The EIP-712 Digest

For off-chain signatures (like those used in snapshot voting, Permit2 allowances, or Safe multi-sig tracking), ERC-8213 mandates the standard exposure of the EIP-712 structured digest:

$$text{EIP712Digest} = text{0x1901} mathbin{Vert} text{domainSeparator} mathbin{Vert} text{hashStruct}(text{message})$$

Why This Matters for Hardware Verification

If a frontend gets compromised via an XSS injection, the attacker will swap out the underlying transaction parameters (e.g., modifying the recipient address in the transaction payload).

Because the frontend is compromised, the user’s browser extension might lie about what is happening. However, the hardware wallet calculates the ERC-8213 Calldata Digest directly from the raw bytes sent over the USB/Bluetooth line.

By comparing the digest shown on the physical screen with an independent source (like a block explorer, a separate terminal tool, or local execution), the user has deterministic proof that the data was not modified in transit.

3. The Clear Signing Workflow

When an application triggers a signing event, the execution pipeline functions as follows:

[ Frontend Action ] 
        │
        ▼
[ Raw Calldata / EIP-712 Struct Generated ]
        │
        ▼
[ Wallet Interception ]
        │
        ├───► Has ERC-7730 Metadata & Valid ERC-8176 Attestation?
        │           │
        │           ├───► YES: Display Human-Readable UI ("Swap 1 ETH for 3,000 USDC")
        │
        └───► NO (Fallback to ERC-8213)
                    │
                    └───► Compute deterministic Keccak256 Calldata/EIP-712 Digest
                    └───► Render concise cryptographic fingerprint on screen

Intent to Build

Clear signing closes one of the oldest attack surfaces in the EVM ecosystem. Moving forward, security is no longer just about writing secure Solidity or Rust circuits; it includes ensuring that the execution intent matches the user’s perception at the exact millisecond they hit “Sign.”

As I focus on building protocol-level infrastructure, implementing ERC-7730 descriptors and ensuring ERC-8213 compatibility will be core to the development lifecycle of my applications. I will be documenting my project implementations, gas considerations, and architectural patterns here in public. Stay tuned for the engineering updates.

I wanted to practice Go regularly by building real projects, so I decided to solve a problem I personally face: expense tracking.

For the last few months, my money management has been messy. I tried different finance apps, but most of them required too much manual input.

So I built a personal finance tracker with AI chat and Telegram bot support.

Now I can simply write:

had lunch 500 taka

The LLM extracts the amount, category, description, and other details, then logs the expense for me.

I can also upload a receipt, and the app can read it and extract purchase details automatically.

This is still an early-stage project. I will keep working on it in my free time to add more features, improve stability, and reduce bugs.

GitHub repo:
https://github.com/aididalam/LLM-Finance-Tracker

A retrospective on building PDLC — 31 slash commands that force my Claude Code workflow to actually finish features.

Six months of pair-programming with Claude Code taught me one uncomfortable truth: the AI is great at writing code, and terrible at the rest of the software lifecycle.

It happily says “done” when only the chat transcript proves the PRD existed.

It writes tests, but after the implementation — making “TDD” a polite lie.

It loses track of which feature is at which stage the moment you start a new session.

It enters lint-fix loops that converge on nothing.

None of this is the model’s fault. The model does what you ask, in the moment you ask it. The problem is that soft conventions — “please write a PRD first”, “please write the failing test first” — are how we talk to humans, who keep their own working memory.

LLMs don’t. They need hard contracts: rules that the workflow itself enforces, not rules the model is supposed to remember.

This is the story of how I encoded that conviction into a Claude Code plugin called PDLC — Product Development Life Cycle — and what surprised me along the way.

The shape of the contract

PDLC ships 31 slash commands organized in three layers:

• Entry points (3): /pdlc-feature, /pdlc-fix, /pdlc-status — one sentence drives a whole chain
• Stages (11): /pdlc-prd, /pdlc-design, /pdlc-tdd, /pdlc-implement, /pdlc-review, /pdlc-e2e, /pdlc-ship, … — when you want fine-grained control
• Tools (17): /pdlc-ui-design, /pdlc-db-migrate, /pdlc-security, /pdlc-perf, … — specialized concerns

Every Layer 1/2 stage that produces artifacts is bound to five invariants I call the Iron Law:

1. Persist to disk. Every artifact (PRD, API design, DB schema, test plan, review notes) lands as a real file under docs/. You can git diff what the AI did.
2. Update the state machine. Each stage writes docs/.pdlc-state/<feature-id>.json. New session? /pdlc-status tells you exactly where every feature stands.
3. Tests first. /pdlc-implement literally refuses to proceed if /pdlc-tdd hasn’t already produced a failing-test artifact on disk for this feature. Real TDD red-light gate.
4. Self-check. Every stage runs a self-audit before handing off. Catch drift at the stage boundary, not three stages downstream during review.
5. One-shot repair. Auto-fix loops run at most once. If a stage’s output fails its own audit, the model gets one chance to repair it, then flags the issue for a human. No more “fix → check → fix → check → fix” until the heat death of your token budget.

What surprised me

1. The state machine matters more than I expected.

I started with the persistence rule alone — write everything to disk. That helped, but a week into using it I caught myself asking the AI “wait, did we write a PRD for the phone-verification thing?” again. The artifacts existed; they were just hard to find.

Adding the per-feature state file (F20260502-01.json with current_stage, artifacts, next_step) was the moment the plugin started feeling like an actual process tool, not a fancier prompt template. /pdlc-status became my new dashboard.

2. Tests-first was the hardest contract to make stick.

The natural tendency of an LLM is to “show its work” by writing the implementation first, then writing tests that conveniently pass. To make /pdlc-tdd truly red-light, I had to make /pdlc-implement read the test artifact and verify it currently fails — not just exists. Without that verification, the model would happily generate stubs that already pass.

3. One-shot repair was a token-budget revelation.

Before this rule, lint-fix loops would burn 30k tokens converging on a misunderstanding. The model would “fix” something that wasn’t the real issue, the checker would complain again with a slightly different message, the model would “fix” the new message, and so on. Capping the repair at one attempt forces it to either understand the real problem or escalate to a human — both vastly better than infinite drift.

Where this falls apart

Three things I should be honest about:

• Claude Code only. I rely on slash commands and skills as first-class primitives. Cline and Cursor don’t have direct equivalents. Porting is possible (the contracts are in bash + markdown) but not free.
• The Iron Law is not law. A determined user can edit the state file by hand, or invoke /pdlc-implement directly without going through /pdlc-tdd. The contracts are guardrails, not jail. That’s deliberate — guardrails that you can step over with one extra command are usually right.
• Overhead for tiny changes. Running the full chain for a 3-line CSS fix is overkill. That’s what /pdlc-fix (lighter chain) is for, but the line between “feature” and “fix” is judgmental.

When to reach for it

If your workflow with an AI agent involves:

• Multiple sessions per feature → the state machine pays for itself
• Anything you’d want to git diff later → persistence pays for itself
• Code where you regret not having tests → TDD red light pays for itself

If you’re using AI for one-off scripts, refactor sweeps, or single-session prototypes, PDLC is more ceremony than the work justifies. Use it where the discipline is worth its weight.

Try it

Install (no clone needed):

curl -fsSL https://raw.githubusercontent.com/kanfu-panda/pdlc-skills/main/install.sh | bash -s -- --global

Then in Claude Code:

/pdlc-feature add phone-number verification to user login

It will allocate a feature ID, walk through the chain, and refuse to skip the steps that matter.

Repo (MIT): https://github.com/kanfu-panda/pdlc-skills

If you build something on top, file a Discussion — I’d love to see what shapes hold up that I haven’t tested.

— kanfu-panda

Siempre he sabido que puedes conectarte a servicios de email mediante APIs y OAuth.

Pero sinceramente: nunca me ha gustado.

Entre registrar aplicaciones, configurar permisos, pelearte con el login de Microsoft y gestionar tokens… al final, para automatizar una tarea simple, acabas montando una infraestructura enorme.
Y yo solo quería automatizar tareas repetitivas de mi correo.

Pues hoy he descubierto otra opción.

Cómo funciona

Si tienes Outlook instalado en tu equipo, puedes acceder a sus funcionalidades desde C# usando las librerías Interop de Office.
Eso te permite interactuar directamente con:

• Emails
• Carpetas
• Calendario
• Contactos
• Eventos
• Respuestas automáticas

Todo usando la sesión de Outlook que ya tienes abierta en tu ordenador.
Sin montar OAuth. Sin APIs externas. Sin rate limits.

Qué he hecho de momento

Por ahora solo he creado un pequeño script que:

• limpia mi bandeja de entrada
• mueve emails automáticamente a carpetas
• organiza correos según reglas

Pero las posibilidades son enormes.
Por ejemplo:

• exportar correos a JSON para analizarlos
• generar respuestas automáticas
• crear eventos en el calendario
• clasificar emails con IA
• construir tu propio asistente de correo

Básicamente, cualquier cosa que puedas imaginar usando los datos de Outlook.

Lo interesante

Muchas veces evitamos automatizar cosas porque pensamos inmediatamente en APIs complejas y autenticación.
Y resulta que, en algunos casos, ya tienes todo lo necesario instalado en tu máquina.

Creo que voy a explorar bastante más esta idea

Business Insider ran a piece last month: “Good Vibes Won’t Help Your Vibe-Coded Side Hustle Win.” The headline is brutal. The data is real.

I want to dig into why — because the takeaway isn’t “vibe coding doesn’t work.” It’s “vibe coding works, but only if you start with the customer, not the code.”

What the Data Actually Shows

There’s a real pattern underneath the failed-vibe-coding narrative. The winners have one thing in common that the failures don’t: they started with a specific problem a specific audience had, and they used vibe coding to solve it.

A product manager Business Insider profiled built a gift-picking app using Claude. She had a clear problem — people struggle to pick good gifts — and a clear audience: people who buy gifts for people they’re close to but don’t know well. She vibe coded the solution. It works. She monetizes through Amazon affiliate links.

For every one of her, there are hundreds of developers building “an AI tool” because they watched a YouTube video about vibe coding. No specific problem. No specific audience. Just a conviction that if you build it, customers will come.

They don’t.

The Build-It-And-They-Will-Come Fallacy

The median successful micro-SaaS built with vibe coding hits $1,200 MRR within 90 days. That’s real. That’s also the median for successful products — not the median for all products.

The distribution is brutal. Most vibe-coded side hustles fail. The successful ones cluster around a specific pattern:

1. Specific problem — not “AI automation” but “appointment reminder fatigue for service businesses”
2. Specific audience — not “small businesses” but “solo dental practices with no receptionist”
3. Validated demand — before writing a line of code, they talked to 20 people in the target audience and found that yes, this is a real problem and yes, they’d pay to solve it
4. Iterated before shipping — built a landing page first, measured interest, adjusted the offering before writing the actual product

The code is the last step. Not the first.

Why Developers Get This Backwards

Developers — and I say this as one — default to the part they know. Code is the comfortable part. Customer discovery is uncomfortable. Market validation is ambiguous. Talking to potential customers and hearing “no” or “maybe” is not what we trained for.

So we do what we’re good at: we build. And then we hope the building was the hard part. It usually wasn’t.

The uncomfortable truth: building the product is maybe 20% of the work of a successful side hustle. The other 80% is problem validation, audience definition, pricing strategy, distribution, and conversion optimization.

Vibe coding compressed the 20%. It didn’t change the 80%.

How to Actually Use Vibe Coding for a Side Hustle

Here’s the sequence that works:

Week 1: Find one problem, from one audience, that you can describe in one sentence. Not “appointment scheduling” — “a solo massage therapist who loses 3 appointments per week because they forget to confirm.” That’s a problem worth solving.

Week 2: Talk to 20 people who match that description. Ask: “Is this a problem for you? How do you handle it today? What would the ideal solution look like? Would you pay $X for it?” If 15 of 20 say yes to the last question, you have validated demand.

Week 3: Build the landing page. Describe the solution. Put a price on it. See if people click. See if people sign up. Even if you can’t process payments yet, email capture tells you something.

Week 4: Build the product. Not before. Not during. After. When you know what you’re building, for whom, and why they’ll pay.

Week 5+: Iterate based on actual feedback. Your first customers will tell you what’s wrong. Listen more than you build.

The Meta-Skill

The real skill in vibe coding isn’t writing code. It’s the ability to stay in problem-validation mode long enough to be confident you’re building something people want — before you write a line of product code.

That ability is rare. That’s why the people who have it win. Not because they coded faster. Because they coded the right thing.

P.S. If you want one automation, one workflow, and one real example every week — I send out a newsletter for people building with AI agents. Free to subscribe. No fluff.