DEV Community: Jessica Temporal

Recovering lost commits with git reflog

Jessica Temporal — Sat, 20 Jun 2026 12:00:00 +0000

There is a particular kind of panic that hits when a commit looks like it just vanished. Maybe you ran a hard reset, or a rebase went sideways, and the work you had a minute ago is nowhere in your history. Before you assume it is gone for good, there is one command that may be able to bring it back: git reflog.

What is the reflog?

Git keeps a private log of everywhere HEAD has been. Everything you do in Git that moves the HEAD pointer is recorded, whether you made a commit, did a checkout, ran a reset, or a rebase or merge moved it around.

The log of that movement lives in the reference log (reflog for short), and it is local to your machine. So even when a commit no longer shows up when you do git log, the reference to it usually still lives in the reflog.

Finding the commit you lost

To see the reference log you can run the command below:

git reflog

You get a list of recent moves, with the most recent entry at the top, like shown in the following image.

Each line has a short hash, a reference like HEAD@{2}, and a description of what happened, things like “commit”, “reset: moving to”, or “checkout”.

Even though it may be hard to get used to reading this new format of log, the description and order usually make it clear where you were and can be the indication you need to know where you want to go.

Getting back to it

Once you have spotted the right entry, copy its hash. Then move your branch back to that point:

git reset --hard <hash>

Replace <hash> with the hash you found in the reflog.

For example, thinking of the image above, if you want to go to the state before the reset you’d need to run the following:

git reset --hard a68cffa

And after that, your working state matches the moment before the mistake, like it never happened.

A quick note of caution: git reset --hard discards your current uncommitted changes, so make sure you actually want to land on that older state before you run it. If you are not sure, you can use git switch to the hash first to look around without moving your branch.

Recap

Most people learn about the reflog the hard way after losing the work to a reset or a rebase, so knowing it exists can be extremely helpful in a pinch.

Here’s a recap of the steps to restore a previous lost state with reflog:

Find the state you want to go back to, and copy its hash.
Check if that’s the actual state you want to restore with git switch <hash>. If it’s not, repeat steps 1 and 2 until you find the correct state.
Run git reset --hard <hash> to get back to it.

Recuperando commits perdidos com git reflog

Jessica Temporal — Sat, 20 Jun 2026 11:00:00 +0000

Tem um tipo específico de pânico que bate quando parece que um commit simplesmente sumiu. Talvez você tenha rodado um hard reset, ou um rebase deu errado, e o trabalho que estava aí um minuto atrás não aparece em lugar nenhum do seu histórico. Antes de assumir que ele foi embora para sempre, tem um comando que pode te ajudar a trazer isso de volta: git reflog.

O que é o reflog?

O Git mantém um registro privado de todos os lugares por onde o HEAD passou. Tudo o que você faz no Git que move o ponteiro HEAD fica registrado, seja porque você fez um commit, deu um checkout, rodou um reset, ou porque um rebase ou merge mexeu nele.

Esse registro de movimento fica no log de referência (do inglês reference log ou reflog, para encurtar) e ele é local na sua máquina. Então, mesmo quando um commit não aparece mais no git log, a referência para ele geralmente ainda está no reflog.

Encontrando o commit que você perdeu

Para ver o reference log, você pode rodar o comando abaixo:

git reflog

Você vai ver uma lista de movimentos recentes, com a entrada mais recente no topo, como na imagem abaixo.

Cada linha tem um hash curto, uma referência como HEAD@{2}, e uma descrição do que aconteceu, coisas como “commit”, “reset: moving to” ou “checkout”.

Mesmo que seja difícil se acostumar a ler esse novo formato de log, a descrição e a ordem geralmente deixam claro onde você estava e podem ser a indicação que você precisa para saber para onde quer voltar.

Voltando para lá

Quando você encontrar a entrada certa, copie o hash. Depois, mova o seu branch de volta para aquele ponto:

git reset --hard <hash>

Substitua <hash> pelo hash que você encontrou no reflog.

Por exemplo, pensando na imagem acima, se você quiser voltar para o estado antes do reset, você precisaria rodar o seguinte:

git reset --hard a68cffa

Depois disso, o seu estado de trabalho volta a bater com o momento antes do erro, como se nada tivesse acontecido.

Uma observação rápida: git reset --hard descarta as suas mudanças não commitadas. Então tenha certeza de que você realmente quer cair nesse estado anterior antes de rodar o comando. Se você não tiver certeza, você pode usar git switch para ir até o hash primeiro e dar uma olhada sem mover o seu branch.

Recapitulando

A maioria das pessoas aprende sobre o reflog do jeito difícil, depois de perder trabalho por causa de um reset ou de um rebase. Então saber que ele existe pode ser uma mão na roda numa emergência.

Recapitulando os passos para restaurar um estado anterior perdido com o reflog:

Encontre o estado para o qual você quer voltar e copie o hash.
Confira se esse é mesmo o estado que você quer restaurar com git switch <hash>. Se não for, repita os passos 1 e 2 até encontrar o estado certo.
Rode git reset --hard <hash> para voltar para ele.

agenticstack.sh: compare tools for building AI agents

Jessica Temporal — Fri, 19 Jun 2026 03:00:00 +0000

If you are building AI agents and wondering which tools to use, agenticstack.sh is worth bookmarking. 🔖

This website lets you compare tools like auth, email, hosting, CMS, and others, so you’ll pick the best one for your use case.

It has comparative tables you can use to make an informed decision.

And since we are talking about AI here, it even has skills that you can install so you can ask questions right in your AI assistant chat. 😄

Let me know if you try it!

Follow along for more tips like this!

git stash: save your work without committing

Jessica Temporal — Thu, 18 Jun 2026 03:00:00 +0000

You’re working, some priority comes up, but you’re not ready to make a commit yet, and you need to switch branches. What do you do? 🤔

Some people like to make a throwaway commit just to save the work so they can undo it later, but I prefer git stash.

Think of it like a stack. You take the changes you made, bundle them up, save them locally, and then your working directory goes back to a clean state.

Each bundle is a stash and it gets saved on index zero.

You can then switch branches, do whatever you need to do, and when you come back, you can pop or apply the stash, and your most recent changes go back to where they were.

One heads up though: if you have new files that git isn’t tracking yet, they won’t be automatically added to this stash. So before you make a stash with new files, you need to stage them first. 😅

Want the full breakdown on git stash? I covered it in more depth here: Using git stash: pop, apply, and drop

If you want more git tips that save your work, follow along!

Preview Auth0 Changes Safely with Deploy CLI Dry Run

Jessica Temporal — Tue, 16 Jun 2026 22:25:31 +0000

Managing your Auth0 tenant configuration as code shouldn't be a "guess and check" process. In this video, I'll demonstrate how to use the Auth0 Deploy CLI's Dry Run feature. Learn how to preview exactly which resources will be created, updated, or deleted before you ever touch your production environment.

What You'll Learn

How to configure the Auth0 Deploy CLI with a config.json file.
The proper syntax for exporting your current tenant configuration to YAML.
How to use the --dry-run flag to validate local changes.
Best practices for keeping sensitive credentials out of your Git history.

Resources

📄 Auth0 Deploy CLI Documentation
💻 GitHub Repository

How to Decode, Encode, and Validate JWTs inside Claude Code

Jessica Temporal — Fri, 29 May 2026 17:42:15 +0000

Stop context switching and start debugging. Let me show you how to supercharge your AI agent with JWT Skills. Learn how to decode, encode, and validate JSON Web Tokens (JWTs) directly within your terminal session using Claude Code. Whether you're troubleshooting an expired token or testing a custom claim, these tools bring security insights right into your development flow.

What You'll Learn:

How to install the jwt-skills
Decoding tokens to inspect headers, payloads, and claims.
Identifying security flags like expired tokens or PII in payloads.
Generating test tokens with custom claims for edge-case testing.
Validating tokens against JWKS endpoints for production-level checks.

Resources:

🛠 Get the Skills
📖 JWT Deep Dive

Manage Your Auth0 Tenants Faster with the Gemini CLI Extension

Jessica Temporal — Wed, 29 Apr 2026 21:01:35 +0000

Stop switching between your browser and terminal to manage identity. In this video, I'll show you how to integrate the Auth0 MCP Server directly into your Gemini CLI.

Learn how to leverage AI to query your applications, initialize tenants, and manage APIs using natural language commands without leaving your development environment.

What You'll Learn

How to find the Auth0 extension on the official Gemini page.
The one-command installation process for the Auth0 MCP server.
Authenticating and initializing your Auth0 environment via CLI.
Using natural language to list applications and create new API resources.

Resources

How to Use Auth0 Agent Skills in Claude Code & AI Coding Assistants

Jessica Temporal — Mon, 06 Apr 2026 18:27:59 +0000

Tired of your AI coding assistant hallucinating APIs or writing insecure auth patterns? In this video, I'll show you how to use Auth0 Agent Skills to teach your AI assistant (like Claude Code or GitHub Copilot) how to implement Auth0 correctly. Say goodbye to XSS vulnerabilities and manual JWT decoding—ship production-ready, secure authentication from the start.

What You'll Learn

Why standard AI coding assistants struggle with secure authentication.
How to install Auth0 Agent Skills via NPX or Claude Code plugins.
The difference between Core Skills and SDK Skills (React, Next.js, etc.).
A side-by-side comparison of "hallucinated" code vs. secure Auth0 patterns.
How to implement production-ready auth in Next.js using Agent Skills.

Resources

📝 Read the full blog post
🛠️ Auth0 Documentation
💻 GitHub Repo

Auth0 MCP Server Extension for Gemini CLI

Jessica Temporal — Fri, 27 Mar 2026 11:00:00 +0000

The Auth0 MCP Server is now listed on the official Gemini CLI extensions page. This means the Auth0 MCP Server is now directly installable through Gemini CLI with one command, allowing you to authenticate to Auth0 directly from your Gemini CLI session and load tenant information automatically.

What the Auth0 MCP Server Extension Provides

The extension packages the Auth0 MCP Server for Gemini CLI and adds three integration layers:

Discoverability: Listed on geminicli.com/extensions, searchable by name, installable without manual configuration.

Authentication Commands: Built-in slash commands for Auth0 tenant management:

/auth0:init - Device authorization flow with tenant selection
/auth0:logout - Session termination
/auth0:session - Current authentication status

Context Injection: After authentication, Gemini gains your tenant information so the AI can query applications, APIs, connections, actions, and logs without requiring manual tenant specification in every prompt.

Installation and Setup

Install the extension:

gemini extensions install https://github.com/auth0/auth0-mcp-server

Once the command successfully finishes you should see a message stating Extension “Auth0” installed successfully:

Initialize the Auth0 MCP Server:

/auth0:init

Make sure to allow the command to run when prompted. The server will run automatically.

You'll authenticate via device code flow to select your tenant:

And confirm the permissions:

Once authenticated, you should see a message within Gemini saying the Auth0 MCP Server is configured and to restart Gemini CLI to see the changes:

Refresh the MCP server list with the following command:

/mcp refresh

Gemini now has Auth0 context. Ask: "show me my applications" and the AI will receive the structured information about your applications, which Gemini CLI will display as a structured tool call result:

And since Gemini now understands your tenant structure, existing configurations, and naming conventions, it can also show you the same information in a more readable format:

Why This Matters

Before this extension, using the Auth0 MCP Server with Gemini CLI required manual server configuration, environment variable setup, and custom initialization scripts. The extension collapses that into a single install command and three slash commands.

More importantly: context persistence. Once authenticated, every Gemini session knows your Auth0 environment. You're not re-explaining your tenant structure or copy-pasting app IDs. The AI assistant operates with the same tenant awareness you have.

This is the same Auth0 MCP Server that powers VS Code integrations, now packaged for Gemini CLI's extension model. Same capabilities, different CLI.

What's Next

The Auth0 MCP Server supports tenant management, application configuration, API setup, and log analysis. For implementation details and the full MCP Server feature set, see the list on GitHub here.

The extension is available now at geminicli.com/extensions. Install, authenticate, and start managing Auth0 tenants through natural language.

Demystifying OAuth Security: State vs. Nonce vs. PKCE

Jessica Temporal — Fri, 13 Mar 2026 16:17:44 +0000

Confused by the random strings in your OAuth URLs? You aren't alone. Many developers think state, nonce, and code_challenge (PKCE) are redundant—but skipping just one could leave your users' accounts wide open to attackers like "Eve." In this video, I'll break down why these three parameters are like three different locks on three different doors. We’ll look at real-world attack scenarios and show you exactly how each one keeps your app secure.

💡 What You’ll Learn:

The State Parameter: How to prevent Cross-Site Request Forgery ($CSRF$) attacks.
The Nonce Parameter: Why ID tokens need protection against Replay attacks.
PKCE (Proof Key for Code Exchange): Protecting mobile and single-page apps from Authorization Code Injection.
Implementation Strategy: Why you should use all three instead of picking just one.

🔗 Links:

If you enjoy this content and want to learn more about identity, security, and access management, subscribe to our channel!

Have a topic you'd like to see covered? Let us know if the comments below 👀

Automating CSS versioning in staging through GitHub Actions

Jessica Temporal — Tue, 03 Feb 2026 06:00:00 +0000

While setting up a staging environment in a new hosting platform, I ran into an issue where static assets were aggressively cached with no straightforward way to invalidate them. This made staging deploys unreliable and validating changes slow.

I could have spent hours fighting with cache headers and purge APIs, but there’s a simpler approach. Rather than fighting the cache, I leaned into patterns that avoid invalidation entirely and make staging behaviour explicit and predictable.

The Problem

This staging environment was behaving badly:

Static assets were cached aggressively
Cache purging is unavailable
Deploys appear as “successful” but changes were not visible

So I was stuck with a cache that I couldn’t purge and changes I needed to validate somewhere other than my local machine. So I figured it was time to version the styling scripts.

Versioned static assets

One reliable way to bypass aggressive caching is to change the asset URL on every deploy.

Static assets are referenced with a deploy-specific version, in my case I went for short git SHA.

<link rel="stylesheet" href="/static/css/base.css?v=6ea4bbe">

This was enough to fix the problem:

CDNs cache by URL.
A new URL guarantees a cache miss.
No reliance on purge APIs or cache headers.
Simple, deterministic behaviour.

This approach works well for staging, where correctness matters more than caching efficiency. Then my next challenge was: how to get this into my deployment without me manually editing the URLs every single time?

Label-gated staging deploys

I can’t remember to update URLs manually every single time, so instead of suffering every time my CSS wouldn’t update accordingly, I adjusted my code and added a step in my GitHub Actions to take care of this for me.

Since I’m the sole developer on this project, my staging deploys are explicitly controlled using pull request labels.

A pull request is deployed to staging only when the preview is applied.

GitHub Actions

In case you want to replicate this for yourself, here’s how to do it. The steps are pretty simple:

Run your tests;
If tests pass deploy the app to the staging environment
Make a comment on your PR so you know the version of the CSS that should be live
Enjoy QA-ing your staged deployment

First the setup for your action:

name: Run tests and stage changes

on:
  pull_request:
    types:
      - opened
      - synchronize
      - reopened
      - labeled
      - unlabeled

jobs:
# ...

This names the action and tells it which Pull Requests to look at, in my case all of them.

1. Tests running

I want to make sure that all pull requests pass my test suite, so the first job checks out the pull request, installs the dependencies and creates necessary files, then runs the tests:

# ...

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout PR branch
        uses: actions/checkout@v4

      - name: Install uv
        uses: astral-sh/setup-uv@v7

      - name: Install dependencies
        run: uv sync --extra dev

      - name: Setup test environment
        run: cp .env.example .env

      - name: Run tests
        run: uv run pytest

  deploy-staging:
  # ...

This guarantees code quality in all pull requests before I even consider deployment.

With a successful test we can move on to deployment.

2. Stage the deployment

The deployment job only needs to run when the preview label is included.

Then a neat trick: you can get the SHA for the deployment with github.sha and write it out to a file, in this case .deploy_sha and once the code is sent to the cloud it can use that file to read the information.

jobs:
  test:
    # ...

  deploy-staging:
    # Only run after tests pass
    needs: test
    if: contains(github.event.pull_request.labels.*.name, 'preview')

    runs-on: ubuntu-latest

    permissions:
      contents: read
      pull-requests: write

    steps:
      - name: Checkout PR branch
        uses: actions/checkout@v4

      - name: Install uv
        uses: astral-sh/setup-uv@v7

      - name: Set deploy SHA
        run: echo "$" | cut -c1-7 > .deploy_sha

      - name: Deploy to staging
        env:
          CLOUD_TOKEN: $
          CLOUD_APP_ID: $
        run: # your deploy command here

      # ...

My code also needed to account for that. So first I created a function in my FastAPI app to grab the first few characters of the SHA from either the environment variable or the .deploy_sha file. I also set a fall back to dev.

# Deploy SHA for cache busting - check env var first, then file, fallback to "dev"
def get_deploy_sha():
    """Get deploy SHA from environment or .deploy_sha file."""
    sha = os.getenv("DEPLOY_SHA")
    if sha:
        return sha[:7]

    # Try reading from file (created during CI/CD deploy)
    try:
        with open(".deploy_sha", "r") as f:
            return f.read().strip()
    except FileNotFoundError:
        return "dev"

# Automatically make the deploy_sha available in all templates
templates.env.globals["deploy_sha"] = get_deploy_sha()

The environment variable is used in production which normally doesn’t change unless I see some weird caching I’m not expecting to, whereas while developing locally the fallback takes action and in staging we use the file.

Finally the HTML template looks like this:

<link rel="stylesheet" href="/static/css/base.css?v=">

Since we pass the deploy_sha automatically as part of the globals variables for templates, any page will have the information they need when the application is being built.

3. Get a comment

Finally, I wanted to get a comment I can see both:

That the deployment is live
The hash I should look for in case I notice some discrepancies between what I’m seeing and the deployment

To this I added a final step to the deploy-staging job with the following code:

# ...
jobs:
  test:
    # ...

  deploy-staging:
    # ...
    steps:
      # ...

      - name: Comment staging URL on PR
        uses: actions/github-script@v7
        with:
          script: |
            const sha = '$'.substring(0, 7);
            const marker = '<!-- staging-deploy -->';
            const body = `${marker}\n🚀 **Staging deploy complete** \n\nPreview: $\n\nCommit: \`${sha}\``;

            // Find existing comment
            const { data: comments } = await github.rest.issues.listComments({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: context.issue.number,
            });

            const existing = comments.find(c => c.body.includes(marker));

            if (existing) {
              await github.rest.issues.updateComment({
                owner: context.repo.owner,
                repo: context.repo.repo,
                comment_id: existing.id,
                body: body,
              });
            } else {
              await github.rest.issues.createComment({
                owner: context.repo.owner,
                repo: context.repo.repo,
                issue_number: context.issue.number,
                body: body,
              });
            }

Since I also didn’t want every new commit to generate a new comment, I used an HTML comment to mark the message:

const marker = '<!-- staging-deploy -->';

Since comments render Markdown the HTML shows up in edit mode but gets hidden when displayed.

And this is what that looks like as the final step of the deploy-staging is completed:

Trade-offs of this approach

This gave me full control over which pull request is staged and my staging represents “currently under review” making it easier for me to even QA the changes myself.

The only downside from this approach is that I can’t have multiple ephemeral per-pull-request environments since I can only make one PR deployment at a time but that works well for my development workflow.

The goal is clarity and control, not maximum automation.

Conclusion

Versioned static assets and label-gated deploys solved my staging cache problem. Now CSS files get a git SHA in the URL, GitHub Actions handles deployments when I apply the preview label, and I always know which version is live. No cache invalidation needed.

AI-powered software development flow: Lessons from shipping My Yarn Stash

Jessica Temporal — Tue, 03 Feb 2026 05:00:00 +0000

When I started building My Yarn Stash, I wasn’t trying to prove AI could build an app for me.

I wanted to answer a practical question:

What actually changes when you treat AI tools as long-term collaborators across planning, implementation, and design?

Not with demos or toy examples, but with a real product that has users, persistent data, billing, authentication, and migrations—all the unglamorous constraints that come with shipping software meant to stick around.

What follows is a breakdown of how AI fit into each phase, where it helped, where it failed, and what I learned or was reminded about tool boundaries by building something real.

The day the AI deleted my database

Early in the project, I asked a coding agent to help with a schema change. It confidently suggested:

rm yarn.db
# Then recreate with new schema

And I let it.

Gone. All the test data I’d been building up. Hours of manual entry to stress-test edge cases. Deleted in a single command because the AI treated the database like a throwaway artifact.

The AI didn’t behave incorrectly. It did exactly what made sense if you assume databases are ephemeral. The problem was that I hadn’t established guardrails.

That moment reminded me to both pay more attention and adjust how I collaborated with AI tools. I needed to be very clear about constraints.

Later I added rules to my copilot instructions:

NEVER delete database files
ALWAYS run migrations instead
Before any destructive operation, run backups first

And went on to recreate my database. The AI didn’t change its behaviour. I changed mine.

This became the pattern for the entire project: AI amplified my clarity and punished my ambiguity and lack of attention.

The database deletion reminded me of something fundamental: vague instructions produce unpredictable results. That lesson shaped how I approached every other phase of this project moving forward.

Separate conversations, separate contexts

After the database incident, I knew I needed better constraint management. That started with how I structured conversations.

I treated ChatGPT like a colleague I’d grab for specific discussions.

Each feature got its own conversation thread:

One for billing and entitlements
One for the AI extraction flow
One for soft-delete patterns
One for launch strategy

This wasn’t about organization. It was about context management.

When everything lives in one chat, the AI starts to get slow and confused, that’s when constant “summarizing history” increase time to answers, so as an engineer leveraging AI, you have to dutifully manage the context window. A billing conversation shouldn’t bleed into UI discussions. Implementation details shouldn’t pollute planning threads.

Separate chats forced clarity. Each conversation had a single purpose, which made it easier to:

Stay focused on one problem
Evaluate outputs against specific goals
Make decisions without noise

What those conversations actually looked like

Branding: From vague to concrete

I started with “I want it to feel cozy and calm.” Through discussion, we identified edge cases I hadn’t considered:

Text baked into images would need rework every time pricing changed
Realistic imagery would read as generic stock photos
“Organizing” visuals imply judgment. Better to frame as “inventory tracking”
Gradients applied inconsistently would create visual noise

The conversation forced specificity. By the end, I had constraints like “no text in images” and “single vertical gradient system” that my coding agent could implement reliably.

Account page: Surfacing failure modes

When planning the account page, ChatGPT helped identify non-obvious problems:

Timezone drift : Automatically updating timezone when users travel would silently change project dates. Solution: only update on explicit user action.
Empty state guilt : Showing “0 finished projects” or prompting users to “finish your first project” creates pressure. Solution: gentle empty state with no call to action.

These weren’t implementation details. They were experience risks that would erode trust if missed.

Launch strategy: Reframing the goal

I initially thought about launch as a visibility event: where to post, how to announce.

The discussion reframed it as a state change : from “only I use this” to “other people can use this safely.”

That shifted focus from:

“How many people see this?”

To:

“What breaks when the first real users arrive?”
“Is this experience internally consistent?”
“Where can people get confused or succeed quickly?”

I deprioritized announcements and spent more time on onboarding clarity instead.

Every useful insight got distilled into markdown. Feature specs, constraints, architectural decisions: all rewritten in my own words with the help of ChatGPT, structured for clarity, stored alongside the code.

This forced two things:

I had to actually understand the decision
The output became durable and reviewable

Stack decisions: What I chose vs. what I asked about

With clear conversation boundaries established, I could make better stack decisions. I came into the project with strong opinions about some parts of the stack and no opinion at all about others.

What I decided before asking AI:

Auth0 for authentication (familiar, reliable, scalable)
FastAPI as the web framework (Python, async, good docs, also familiar and with great Auth0 support)
Supabase for database and storage (Postgres with good tooling and prod database at 0 cost)
Vanilla JavaScript and handwritten CSS to start instead of a framework (less abstraction, easier to reason about with AI and for me to follow along)
Resend for emailing users: a welcome email for the users and another to notify myself when new user signed up
Replicate: to provide AI features like the label extraction information

These choices weren’t about AI compatibility. They were about reducing cognitive load and keeping a codebase I could jump in without the help of AI if needed.

What I asked AI to help evaluate:

Payment gateway : I had no strong opinion. We discussed options and landed on Polar for simplicity and developer experience.
Deployment platform : I wanted something low-cost that I already understood. Heroku fit both criteria.

The pattern here matters: I brought constraints and context to the conversation instead of asking “what should I use?” in a vacuum.

AI didn’t tell me what to build with. It helped me think through trade-offs for the decisions I hadn’t made yet.

Learning which model does what well

Stack decisions settled, the next challenge was figuring out which AI tool to use when. Understanding model strengths came from repeated experience across different contexts.

I didn’t use one AI tool for everything. That was deliberate. Through building, I found a flow that worked for me:

ChatGPT for planning and exploration

Most planning conversations happened in ChatGPT in the mobile app. I used it on my phone during downtime to think through features, identify edge cases, and explore design decisions before writing any code.

The mobile accessibility mattered. I could sketch out billing logic while having my coffee in the morning or map out future features during a commute. By the time I grabbed my computer to code, I’d already worked through the conceptual problems.

GitHub Copilot Agents for straightforward work

Well-defined low-complexity features and bugs went to GitHub issues and I would let Copilot handle implementation through PRs asynchronously by assigning Copilot to a given issue. It freed me up to work on more-complex and high value things while Copilot handled the implementation of the “no-brainer” tasks.

When agents got stuck online, I’d download the code and ask Claude Opus to step in.

VS Code Copilot for local development

I used VS Code with Copilot in different modes and with models depending on the work:

Claude Haiku:

Mostly in Plan mode;
Quick iterations when following up on features locally;
Good for refactoring and adjusting implementation details that didn’t require more scope other than one file

Claude Opus:

Mostly in Agent mode;
Complex situations with many moving pieces
Used when precision and accuracy mattered more than speed

No matter the model though, they were always constrained by explicit conventions in copilot-instructions.md. The lesson wasn’t “use the best model.” It was knowing not only when to switch models and modes but also why switching should happen.

That judgment is a skill. AI tools don’t remove it.

The database deletion happened because I let my guard down. I got comfortable with AI-assisted coding and stopped questioning the suggestions. It was a good reminder that different contexts need different constraints. By this phase of the project, I’d learned to match tool capabilities to task requirements.

Functional first, pretty later (because I’m not a designer)

With implementation flowing more smoothly, I turned to design. This required a different kind of clarity.

I deliberately delayed visual design work. Not because of anything AI-related, but because CSS and JavaScript are not my strong suit.

I focused on making things functional first: flows, data models, interactions. Once those settled, I could tackle design from a more stable foundation. It didn’t look ugly but it clearly wasn’t beautiful:

My first exploration with Stitch, Google’s Gemini-based tool that transforms text descriptions into UI designs, showed me how powerful it was. I dropped the link of the working app and asked for a redesign. It made something pretty, but it didn’t look like my product.

So I used ChatGPT to put together the branding guidelines: tone, colour direction, what feelings I wanted the UI to convey. Once I had that document written down, I went back to Stitch with:

Screenshots of the functional app
The branding document
Specific constraints like “redesign this following the brand guidelines”

The result you see below:

That combination worked. The design felt right because I’d done the thinking first. And did I mention it now supports dark mode as well?

The lesson: Tools work better when you’ve already established intent. Just like the database needed constraints, design tools needed direction.

What this experience taught me about building with AI

Going through all these steps I noticed a few patterns that go beyond individual tool choices. These are a few things I’m carrying forward:

1. AI doesn’t replace judgment. It makes judgment more important

The database deletion wasn’t an AI failure. It was a clarity failure. Once I added explicit constraints, the tools became more reliable.

2. Context boundaries matter

Separate conversations for separate concerns reduced drift and forced focus.

3. Model switching is a learned skill

Understanding when to use a lightweight model versus a heavy one came from repeated friction, not documentation.

4. Design still requires taste

AI can accelerate iteration, but you need to know what you’re aiming for. “Make it pretty” produces generic results. “Make it feel cozy and trustworthy” with examples gives you something to evaluate.

5. Shipping something real teaches more than demos ever could

Most AI tool examples live in a world where you can always start over. Production software doesn’t. That constraint forced honesty about where AI helps and where it doesn’t.

What this means for learning AI tools

I always believed developers do better when they learn the limitations of the tools they use when building software. Specially since development is no-longer my day job, this project became an outlet for experiment and trying new tools and it helped shape how I evaluate and talk about AI tools.

Demos have their place in my world, but nothing beats the actual experience of building something and learn by doing.

Building My Yarn Stash gave me a even clearer sense of where AI accelerates work and where it introduces risk. Not from reading about it, but from hitting the boundaries myself.

If you’re trying to find your footing with AI tools: build something real. Solve a problem you face often, try the new tools and find the flow that works for you.

Step away for a moment from the tutorials and courses and build your own project free of the constraints instructors purposely impose in order to teach and give students a good experience. Something with users, data you can’t lose, and decisions that compound over time.

You’ll learn more from one broken migration than from a hundred perfect prompts.