DEV Community: Kristieene Knowles

Entering My Automation Era (Without Letting AI Build My Code)

Kristieene Knowles — Thu, 04 Jun 2026 05:59:04 +0000

On 30th June 2025, I started my web development journey. At the time, my focus was simple: learn the fundamentals, build websites, solve problems, and improve with every project. Like most developers starting out, I spent my days learning HTML, CSS, JavaScript, accessibility, responsive design, deployment, debugging, and occasionally breaking things in ways I didn't think were possible.

Fast forward to today, and I've realised I've entered a new phase of development.

Not an "AI builds everything for me" phase.

An automation phase.

When people hear the word automation, they often assume it means handing over your codebase and hoping for the best. For me, it's been the opposite. I still design my websites, write the functionality, make the architectural decisions, and review everything that matters. The websites are still mine. What has changed is that I've started automating the repetitive tasks around development rather than development itself.

Over the past few months, I've been building up a collection of GitHub Actions, repository audits, validation checks, reporting tools, and AI-assisted review workflows. My repositories now contain security scanning, dependency auditing, workflow validation, issue prioritisation reports, documentation updates, repository health checks, and automated quality reports. None of these tools are writing client projects for me. Instead, they're acting as a second set of eyes, constantly reviewing things that would otherwise require manual effort.

AI As A Team Member, Not A Replacement

One of the biggest mindset shifts I've had is moving away from asking:

Can AI build this for me?

and instead asking:

Can automation help me verify this?

As a solo developer, I don't have a dedicated QA engineer, security reviewer, documentation writer, or DevOps team. That's usually just... me.

Automation helps bridge that gap.

A GitHub Action can run checks while I'm asleep. An automated report can highlight issues before they become problems. An AI review can spot patterns I might miss after staring at the same code for hours. None of that removes my responsibility as the developer; it simply gives me more visibility into what's happening across the codebase.

The Review Era

The interesting thing is that most of my automation isn't focused on creating code.

It's focused on reviewing code.

That's where I've found the biggest value.

The more automation I add, the more involved I become in the actual development process. Instead of spending time on repetitive checks, I spend more time making decisions, reviewing results, improving architecture, and focusing on the user experience. Automation hasn't reduced my responsibility as a developer; it's given me better tools to manage it.

That small change in thinking—moving from code generation to code verification—has probably saved me more time than any code-generation tool ever could.

Looking Back

If you had told me on 30th June 2025 that I'd eventually have automated audits, repository health reports, workflow validation, issue prioritisation, monitoring, and AI-assisted review processes running across my projects, I probably wouldn't have believed you.

At the time, I was just trying to make websites work.

Today, I'm building systems that help keep those websites healthy.

And honestly, that's been one of the most rewarding parts of my development journey so far.

The code is still mine.

The decisions are still mine.

The responsibility is still mine.

I've just built myself a really efficient team.

That Moment You See ‘Deleting…’ in Git Bash

Kristieene Knowles — Wed, 04 Mar 2026 20:51:34 +0000

The Fear of Using Git Bash Too Early in Your Dev Journey

When I first started learning development about six months ago, Git Bash felt like stepping into a control room full of buttons I didn’t understand.

I had connected Git to my local VS Code environment and thought:

“Okay, this must be what developers use… I’ll just follow along.”

The problem was that I didn’t actually understand the commands I was running.

One day I ran a command in Git Bash and suddenly my terminal started printing lines that included words like “deleting”.

My brain instantly went into panic mode.

Not deleting in the repo.

Deleting in my actual Windows file system.

Inside my /htdocs/ folder.

At that moment I realised something important about Git:

Git is powerful — but if you don’t understand what a command does, it can be terrifying.

I aborted the command as quickly as I could, but by then the damage had already started.

For a few seconds I genuinely thought I had just lost my entire working project.

Thankfully, I had a backup, so I restored everything and carried on.

But that moment taught me two lessons that stuck with me.

Lesson 1 — Git Isn’t Dangerous, Ignorance Is

Git commands can look intimidating because they operate at a very powerful level of your file system.

When you see words like:

reset
clean
rm
delete

…it feels like you're about to destroy your project.

But Git isn't the enemy.

Running commands without understanding them is.

Once I slowed down and actually learned what commands like checkout, pull, and reset do, Git stopped feeling scary and started feeling like a safety net.

Lesson 2 — Always Backup Your Work

The real hero of that moment was my backup.

If I hadn’t had one, I genuinely could have lost hours (or days) of work.

After that experience, I decided to automate the process.

I created a small PowerShell script that automatically backs up my /htdocs/ folder, so I always have a copy of my working files.

Now backups happen without me even thinking about them.

That one small script removed an enormous amount of stress from my workflow.

Lesson 3 — Fear Is Part of the Learning Curve

Looking back, the fear I felt in that moment was actually part of the learning process.

Every developer eventually reaches a point where they realise:

Tools like Git aren’t just version control — they’re power tools.

And power tools require respect.

Once you understand them, they stop being scary and start being incredibly useful.

Final Advice for New Developers

If you're just starting with Git:

Don’t blindly copy commands from tutorials

Take time to understand what each command does

Always keep backups of your important work

Because one day you will see the word “deleting” fly past in a terminal…

…and your heart will skip a beat.

Trust me on that.

I Built My Own dev.to Feed Page Instead of Embedding a Widget

Kristieene Knowles — Sat, 28 Feb 2026 20:21:11 +0000

There’s an easy way to show your dev.to posts on your website.

You paste in a widget.
You let it render.
You move on.

I almost did that.

But the more I looked at it, the more it felt slightly disconnected from how I build everything else.

So I didn’t embed it.

I built my own feed page instead.

Why I Didn’t Use the Widget

This wasn’t about avoiding convenience.

It was about consistency.

My site is fully hand-built — HTML, CSS, JavaScript, structured layouts, injection layers, theme handling. Everything is intentional.

Dropping in a third-party widget would have worked, but it wouldn’t have felt like part of the system.

It would’ve been something sitting inside it.

And that difference matters more than it sounds.

The Approach

dev.to provides a public RSS feed. That’s data.

So instead of embedding a UI component, I fetched the feed, parsed the XML, and rendered the posts as native components on my site.

No iframe.
No external styling.
No layout overrides.

Just data → structured objects → my own card components.

That means:

The posts match my design system
The spacing, typography, and hover states are consistent
The performance impact is minimal
The page works whether someone is logged into dev.to or not

It feels integrated rather than attached.

What I Like About This Pattern

RSS is simple.

It’s stable.
It’s predictable.
It doesn’t try to control your layout.

That separation — content from presentation — is powerful.

dev.to handles publishing and discovery.
My site handles display and brand.

Both do what they’re good at.

A Small Architectural Win

This isn’t a huge feature.

It’s not complex.

But it reinforces something I’ve been learning while building everything from scratch:

Control over the surface area of your site makes everything cleaner long term.

When you own the presentation layer, you’re not negotiating with someone else’s styles, scripts, or structure.

You’re just working with data.

And I prefer building that way.

If you’re building a personal site and want your blog content there too, consider pulling the feed instead of embedding the widget.

It’s a small change — but it keeps your architecture intentional.

I Built My Own Wordle Engine to Support How I Actually Think

Kristieene Knowles — Sat, 28 Feb 2026 10:30:56 +0000

Why I Built My Own Wordle

Like a lot of developers, I enjoy Wordle.
But after playing for a while, I realised I didn’t just want to play it — I wanted to understand it.

So instead of cloning a template, I built my own Wordle engine from scratch.

Not because the world needed another clone.

But because I wanted:

Full control over the word pool
Seeded daily logic I understood completely
A stats system I could extend cleanly
And a version that reflected how I actually think when solving puzzles

That’s how Web Weavers Wordle started.

Custom Word Pool (Under 1k → Nearly 6k Words)

Originally, my word list was tiny — under 1,000 entries.

It worked, but it felt constrained.

So I rebuilt the dictionary layer entirely.

Instead of a single static list, I moved to:

Separate .txt files per word length
Dynamic loading
A combined VALID_SET for fast validation
Per-length counts for UI stats

The pool is now just under 6,000 words, all curated to match the theme (every answer starts with W).

It’s modular, scalable, and easy to extend — without bloating the main script.

That refactor alone made the project feel like a proper engine instead of a weekend experiment.

Daily Logic (Seeded, Predictable, Controlled)

For the daily mode, I didn’t want randomness.

I implemented seeded selection based on the local date:

function seedFromDate() {
  const d = new Date();
  return d.getFullYear() * 10000 + (d.getMonth() + 1) * 100 + d.getDate();
}

This means:

Everyone gets the same word on the same day
The day flips at local midnight
No server needed
No external API calls

It’s deterministic and self-contained.

Which is exactly how I like my systems.

The UX Gap I Noticed

This is where it got interesting.

When solving Wordle, I don’t like filling unknown spaces with random letters.

Before, if I was thinking through a word like:

W _ S T _

I would temporarily type something like:

W W S T W

Just to fill the row visually.

But that felt wrong.

Those letters weren’t information — they were noise.

So I added a new state.

A manual ? placeholder.

Now I can type:

W ? S T ?

It:

Visually preserves structure
Doesn’t affect validation
Cannot be submitted
Acts as a deliberate “unknown” marker

It sounds tiny.

But it fundamentally changed how the puzzle feels to solve.

It added an intentional “thinking state” between blank and evaluated.

And I haven’t seen other clones do that.

What I Didn’t Build (Yet)

I considered expanding daily mode to every word length.

Technically, it would be easy.

Architecturally? It touches:

Stats storage
Streak logic
UI distribution trees
LocalStorage keys
Share formatting

So I didn’t.

The current version is:

Stable.
Clean.
Focused.

I’d rather refine than expand.

Final Thoughts

This project started as curiosity.

It’s now a modular, seeded, PWA-enabled Wordle engine with:

Nearly 6,000 words
Custom daily logic
Clean stats tracking
Share image generation
And a small UX improvement I genuinely love

Sometimes the best way to understand a system is to rebuild it.

And sometimes rebuilding it lets you improve it in small, meaningful ways.

The live version is here, if you'd like to try it; https://webweaversworld.co.uk/html/main/wordle/index.html

When Regex Meets the DOM (And Suddenly It’s Not Simple Anymore)

Kristieene Knowles — Thu, 26 Feb 2026 10:03:46 +0000

I recently built a custom in-page “Ctrl + F”-style search and highlight feature.

The goal sounded simple:

Support multi-word queries
Prefer full phrase matches
Fall back to individual token matches
Highlight results in the DOM
Skip <code> and <pre> blocks

In my head?

“Easy. Just build a regex.”

Step 1: Build the Regex

If a user searches:

power shell

I generate a pattern like:

power[\s\u00A0]+shell|power|shell

The logic:

Try to match the full phrase first
If that fails, match individual tokens

On paper? Clean.

In isolation? Works.

Step 2: Enter the DOM

This is where things escalated.

Instead of just running string.match(), I had to:

Walk the DOM
Avoid header UI
Avoid <pre>, <code>, <script>, <style>
Avoid breaking syntax highlighting
Replace only text nodes
Preserve structure

That meant using a TreeWalker.

const walker = document.createTreeWalker(root, NodeFilter.SHOW_TEXT, {
  acceptNode(node) {
    const p = node.parentElement;
    if (!p) return NodeFilter.FILTER_REJECT;

    if (p.closest("code, pre, script, style")) {
      return NodeFilter.FILTER_REJECT;
    }

    return NodeFilter.FILTER_ACCEPT;
  },
});

Now we’re not just doing regex.
We’re doing controlled DOM mutation.

Step 3: The Alternation Problem

This is where it got interesting.

Even though the phrase appears first in the alternation:

phrase|token1|token2

The engine still happily matches:

power
shell
PowerShell

Depending on context.

So now the problem isn’t “regex syntax”.

It’s:

Overlapping matches
Execution order
Resetting lastIndex
Avoiding double mutation
Preventing nested <mark> elements

Step 4: Two Passes?

At one point I thought:

Maybe this shouldn’t be one regex.

Maybe the logic should be:

Try phrase match
If none found, then try token match

Which sounds simple…

Until you realise your DOM has already been mutated once.

Now you’re managing state across passes.

The Realisation

I understand JavaScript logic.

I understand regex.

But applying that logic safely across a live DOM tree?

That’s a different tier of problem.

Regex is deterministic.
The DOM is structural and stateful.

And once you start replacing text nodes, everything becomes delicate.

What I Learned

Regex problems are easy in isolation.
DOM mutation problems are easy in isolation.
Combining them multiplies complexity.

Also:

The line between “simple feature” and “mini search engine” is very thin.

Where I Am Now

The search works.

Mostly.

It highlights.
It skips protected blocks.
It respects structure.

But it’s not a browser-level Ctrl + F.
Not yet.

And that’s the interesting part.

I now respect the DOM far more than I did before.

And I never thought I’d say this sentence naturally:

I get the logic of JavaScript.
Making that logic behave predictably inside a living DOM tree is the real challenge.

There’s still refinement to do.
Edge cases to tame.
State to simplify.

But that’s the line between “feature complete” and “actually robust.”

And I’m somewhere in the middle of that line.

I Learned More Building One Testimonial System Than From Months of Tutorials

Kristieene Knowles — Wed, 25 Feb 2026 06:10:40 +0000

When I first got into web development, it was very much the “web” side of things that pulled me in.

HTML. CSS. Making something appear on a screen from nothing.

There’s something powerful about writing a few lines of code and seeing it come alive in a browser. That never really gets old.

But over time, something shifted.

I started caring less about just how things looked… and more about how they worked.

The logic.

The structure.

The “why is this doing that?” moments.

Recently, I built my own testimonial system for my site. On the surface, that sounds simple. Just a form and some displayed text, right?

It wasn’t.

I had to think about:

How the data gets stored
How to structure it properly
Validation
Preventing abuse
Connecting front-end to database
Triggering actions after submission
And making sure it all behaves in production, not just locally

There were moments where I broke it.
Moments where I misunderstood how APIs worked.
Moments where I thought I’d finished… only to realise I hadn’t accounted for edge cases.

But that’s where the learning really happened.

I realised something important:

You don’t become “full-stack” by calling yourself full-stack.

You become it by building things that force you to learn the layers underneath.

What started as “I want a testimonials page” turned into:

Working with databases
Understanding data flow
Thinking about security
Writing logic I didn’t think I could write a few years ago

And honestly? That’s been the most satisfying part.

Not the polished UI.
Not the final version.

The messy middle.

The debugging.
The rewrites.
The moments where something finally clicks.

I’m still learning. A lot.

But every time I build something that stretches me a bit further than last time, I feel like I’m actually becoming the developer I wanted to be when I was younger.

And that’s a good feeling.

Why I Still Build Websites From Scratch in 2026

Kristieene Knowles — Tue, 24 Feb 2026 05:15:08 +0000

In a world of drag-and-drop builders, AI site generators, and one-click themes, choosing to build websites from scratch can feel unnecessary.

But I still do.

I run an independent studio, Web Weavers World, where every site is hand-coded. No templates. No visual builders. No plugin stacks layered on top of each other.

That’s not because modern tools are “bad.” They’re incredibly useful. They solve real problems.

I just value control.

When I build from scratch, I know exactly:

What loads and when
Why a layout behaves the way it does
How performance is impacted
What the accessibility trade-offs are
Which scripts are truly necessary

There’s no mystery layer.

Performance matters to me. Not just Lighthouse scores, but real-world responsiveness. Clean architecture matters. Maintainability matters. Accessibility matters.

And honestly ~ I enjoy it.

There’s something satisfying about understanding every moving part of a system you built. From the CSS structure to the backend logic to the analytics tracking.

It also forces better decisions.

When you don’t have a plugin to solve everything, you think more carefully about whether something needs to exist at all.

That constraint is valuable.

I’m not anti-tool. I use modern workflows, automation, and analytics daily. But I choose intentional complexity over hidden complexity.

That’s why I still build websites from scratch in 2026.

Curious how others approach this ~ are you all-in on frameworks and builders, or do you still enjoy the raw build process too?