I spend a lot of time inside enterprises right now, and I see the same scene play out: a leadership mandate to “use AI more,” a procurement decision between Claude Code, GitHub Copilot, and Cursor, a flurry of activity, and six months later… not much has changed. Throughput hasn’t doubled. Quality hasn’t improved. A few developers swear by their tool of choice; others quietly turn it off. The mandate gets renewed and the cycle starts again.

The problem isn’t the tool. The problem is that nobody learned how the tool actually works.

This post is for engineers who feel that gap. You’re not skeptical of AI. You’ve used it. You’re skeptical of the hype, and you’re frustrated that your team’s investment isn’t compounding. Good. That skepticism is the right starting point. Let’s talk about what’s actually changed, what to learn, and where to put your energy on Monday morning.

Why “Vibe Coding” Is Failing Enterprises

Vibe coding is the practice of describing what you want, accepting whatever the model produces, and shipping it if the tests pass. It works for prototypes. It catastrophically fails in enterprise codebases, and the reasons are structural, not cultural.

Three failures, every time:

1. Inconsistency. Eight developers each prompt the agent slightly differently, get back eight subtly different solutions to the same shape of problem, and merge them all. Six months later, you have eight idioms for HTTP retry, four error-handling philosophies, and a codebase that pattern-matches against itself badly the next time an agent reads it.
2. No validation. The model said it works. The tests pass. Nobody actually read the diff. The bug ships, and the engineer who “wrote” it can’t debug it because they never engaged with the logic.
3. Drift. Without explicit guardrails, agents make plausible local choices that violate global constraints. They reach for a library you’ve banned. They write to a database directly when your architecture says go through the service layer. Each instance is small. Together they erode the codebase.

None of these are model failures. They’re system-design failures. The agent did what it was asked. Nobody told it what not to do.

How Agentic AI Actually Works

To use these tools well, you have to understand two things: the agentic loop, and the context window. Most of the people I work with have a fuzzy intuition about both, but no operational model. Let’s fix that.

The Agentic Loop

A modern coding agent isn’t a fancy autocomplete. It’s a loop:

  [User intent]
       |
       v
  [Model reasons] <----------+
       |                     |
       v                     |
  [Need a tool?] -- yes --> [Call tool] --> [Result into context]
       |
       no
       v
  [Final response]

The model doesn’t “know” your codebase. At each step, it decides what it needs (reading a file, running a test, searching for a symbol) and the result of that action gets appended to its context. Then it reasons again. The loop continues until the model decides the task is complete or it hits a limit.

This has implications most teams haven’t internalized:

• Every tool call is a chance to give the agent better information, or worse information. A flaky test that returns gibberish poisons the loop. A linter that surfaces real issues sharpens it.
• The agent’s “memory” is whatever is currently in the context window. It does not remember the last conversation. It does not remember yesterday. It remembers what’s loaded right now.
• Time-to-feedback matters. A test suite that takes ten minutes to run is a ten-minute interruption in the agent’s reasoning. Fast, deterministic feedback loops compound.

The Context Window

The context window is the working memory the model has access to during a single task. Everything the agent “knows” in this moment lives there: your prompt, the files it has read, tool outputs, conversation history, and any standing instructions.

The window has a fixed size. When it fills up, things get evicted or compacted, and quality degrades. This is why two superficially similar tasks can produce wildly different results: one of them was given a clean, focused window with the right files; the other was 80% full of irrelevant junk before the work even started.

Different models have different window sizes and different attention profiles. Larger windows aren’t automatically better. A model can get lost in a 200K-token window if half of it is noise. The skill isn’t filling the window. The skill is curating it.

Models Are Not Interchangeable

A fast, cheap model is great for narrow, well-scoped tasks: rename this variable, write this test, format this file. A larger reasoning model earns its cost on tasks that require holding multiple constraints simultaneously: refactor this module, design this API, debug this race condition.

Teams that use one model for everything are either overpaying or underperforming. Teams that match the model to the task, often inside the same workflow, get dramatically better economics.

The New Disciplines

This is where vocabulary matters. The industry has settled, more or less, on three terms that describe three different jobs. They overlap, but they’re distinct, and engineers who confuse them under-invest in two of the three.

Prompt Engineering

The immediate instruction. “Refactor this function to use async/await.” “Write a test for the edge case where the user is null.”

Prompt engineering used to be most of the conversation. It’s now the smallest part of the job. Models are good enough that a clear, specific prompt usually suffices. If you find yourself spending a lot of time crafting the perfect prompt, your effort is probably misallocated. The leverage is upstream.

Context Engineering

Deciding what the model sees when it works. Which files are loaded. Which documentation is in scope. Which conventions are stated explicitly. Which past decisions are surfaced.

Context engineering is where most of the quality gap lives. Two teams using the same tool with the same prompts will produce wildly different output if one of them has invested in:

• A CLAUDE.md (or equivalent for your tool) at the root of the repo that states architectural conventions, banned libraries, testing expectations, and domain terminology.
• Curated reference docs the agent can pull in on demand.
• Clean, idiomatic code that the agent can pattern-match against.
• Explicit examples of “we do it this way, not that way.”

This is the work most enterprises skip, and it’s the work with the highest ROI.

Harness Engineering

Designing the system the agent operates inside. The hooks, the validation gates, the subagents, the tool integrations, the CI checks, the rollback mechanisms.

If context engineering is “what does the agent know,” harness engineering is “what is the agent allowed to do, and what happens when it tries.” This is the discipline that turns a useful coding assistant into a reliable team member. It’s also the most underdeveloped at every enterprise I’ve worked with.

A team without a harness is trusting vibes. A team with a harness is running a system.

The Primitives: Hooks, Skills, and Agents

These are the building blocks you use to do the work above. Each maps onto one of the three disciplines.

Hooks (Harness Engineering)

Hooks are deterministic checkpoints that fire at specific points in the agent’s loop: before a tool runs, after a file is edited, when a session starts. They are not polite suggestions to the model. They are code that runs, and the agent has to live with the result.

A trivial example: every time the agent edits a TypeScript file, run the type checker and the linter. Reject the edit if they fail.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "npx tsc --noEmit && npx eslint $CLAUDE_FILE_PATHS"
          }
        ]
      }
    ]
  }
}

This single hook eliminates an entire category of garbage commits. The agent cannot ship code that doesn’t compile, because the hook makes it impossible. You haven’t asked the model to be careful. You’ve made carelessness fail loudly.

Good hooks to consider:

• Format-on-write
• Lint-on-write
• Block edits to sensitive paths (/infra, /secrets, generated files)
• Run affected tests after a change
• Log every shell command for audit

Hooks are pure harness engineering: they are the rails the agent runs on.

Skills (Context Engineering)

Skills are packaged expertise. A folder containing instructions, examples, and sometimes scripts, which the agent loads when relevant. Think of a skill as “the team’s knowledge about how to do X, written down once, available everywhere.”

A SKILL.md for your team’s database migration workflow might describe the conventions, the commands, the gotchas, and the review checklist. When a developer asks the agent to write a migration, the skill loads, and the agent inherits your team’s institutional knowledge instead of inventing its own.

---
name: db-migrations
description: Use when creating, modifying, or reviewing database migrations.
  Triggers on phrases like 'migration', 'schema change', 'alter table',
  or file references under /migrations.
---

# Database Migrations

## Conventions
- All migrations are reversible. Every `up` has a tested `down`.
- Never drop a column in a single migration. Two-phase: deprecate, then drop.
- Index changes go in their own migration, never mixed with schema changes.

## Workflow
1. Generate migration: `npm run db:new <name>`
2. Write `up` and `down`. Both must be idempotent.
3. Test the round-trip locally before pushing.
4. Tag the PR with `migration` so the on-call DBA reviews it.

Skills are context engineering: they shape what the agent knows, on demand, scoped to the task.

Agents and Subagents (Both)

A subagent is a specialized agent invoked from within another agent’s loop. It has its own context window, its own focused instructions, and it returns only its conclusion to the parent. The parent’s context stays clean.

Example: your main agent is implementing a feature and needs to understand how a legacy module works. Instead of dumping 4,000 lines of code into the main context (and degrading every subsequent decision), it dispatches a “code explorer” subagent that reads the legacy module and returns a 200-word summary. The main agent stays focused. The work gets done.

Subagents straddle both disciplines: defining what they do is context engineering; defining when and how they’re invoked is harness engineering.

Brownfield Cleanup Is the Highest-Leverage AI Investment

Here’s the thing nobody wants to hear: the best thing you can do to make your AI tooling work better is clean up your codebase.

Agents pattern-match. They read your code, infer the conventions, and produce more of the same. If your codebase is consistent, well-organized, and idiomatic, the agent extends it correctly. If your codebase is a graveyard of half-finished refactors, three competing styles, and dead code, the agent confidently produces more of the mess.

This is the opposite of the order most teams attempt. They want to point the agent at the legacy mess and have it clean things up. That works at the margins. It does not work at scale, because the agent has no anchor for what “good” looks like in your context.

A more productive sequence:

1. Pick one module or domain. Don’t boil the ocean.
2. Establish the patterns by hand or in tight collaboration with the agent. Two or three reference implementations done well.
3. Document them. In a CLAUDE.md, in skills, in architecture decision records.
4. Now point the agent at the rest. With pattern anchors and explicit guidance, it can extend the cleanup at scale.

Your codebase is the single largest piece of context any agent will ever load. Investing in its quality is investing directly in the quality of every future AI-assisted change.

We Are Still Professional Developers

Here is where I want to push back on the discourse, gently. The narrative that “AI writes the code now” is half-true and badly framed. Yes, the typing has shifted to the model. But typing was never the job. The job was, and is:

• Understanding the problem precisely enough to specify it
• Choosing constraints that make the system robust
• Validating that the work actually solves the problem
• Owning the result

What changed is the medium. We used to express our judgment in code. We now express it in guardrails and descriptiveness: in the conventions we write down, the hooks we wire up, the skills we package, the contexts we curate, the validation we insist on. The agent does the keystrokes. We design the system that makes those keystrokes correct.

This is not less engineering. In some ways it is more. The discipline of being explicit is real work that most teams have avoided for decades. Writing down what was previously tribal knowledge. Codifying what was previously taste. That work is now the work.

The people I see succeeding with these tools are not the ones who type the cleverest prompts. They are the ones who treat the agent as a powerful, fast, senior teammate who needs context, needs guardrails, and needs to be checked. They test as they go. They validate every diff. They keep their codebase clean so the agent stays sharp. They are, in every sense that matters, still professional developers.

The floor moved. The craft didn’t.

Where to Start

If you take one thing from this post: pick a single repo this week and add three things.

1. A CLAUDE.md (or your tool’s equivalent) at the root that states your conventions, your stack, your banned patterns, and your testing expectations. Two pages, no more.
2. One hook that enforces a thing you actually care about: lint, type check, test coverage, whatever. Make it impossible to ship code that violates it.
3. A short audit of one area of the codebase where the patterns are inconsistent. Pick the canonical pattern, document it, and start the cleanup.

That is a week of work. Slow down to speed up. It will compound for the rest of the year. And it is an order of magnitude more valuable than another debate about which tool is best.

Just a few weeks ago, I wrapped up the KCNA, and today I officially passed the GitHub Actions (GH-200) exam.

As an architect, I actually enjoy taking exams. Not because I love tests, but because they force accountability. When you work at the architecture level long enough, it’s easy to drift away from the implementation details. Certifications give me a concrete way to validate that I’m still absorbing the material and paying attention to the finer points. The stuff you don’t always hit when you’re doing POCs or designing high-level architectures.

Accountability looks different for everyone, but for me, certs are a reliable forcing function to stay sharp.

Why I’m Sharing This (While It’s Still Fresh)

Since I’m only a few hours removed from hitting that “pass” screen, I figured now was the perfect time to share a few study tips and the cheat sheet I built while prepping.

This is very much a “here’s what worked for me” post.

How I Studied

I like to use multiple sources when learning a new technology. I’ve found that reviewing the same material from two to three different angles really helps reinforce concepts.

My usual pattern looks like this:

• 1 primary reading resource
• 1–2 video resources

For this exam, I reviewed the following:

Reading

• Microsoft’s Offical GH-200 Course Material

Video

• Microsoft’s Offical GH-200 Video Training Course
• Andrew Brown’s GH-200 Course

Practice Exams

For practice exams, I stuck with:

• Microsoft Learning Practice Questions - I actually think these are too easy compare to the exam. This is a good starting place though.
• Exam Pro

The ExamPro videos are free on YouTube, and if you want more structured practice, you can buy their flashcards and 3–4 full practice exams for around $30. For me, that was well worth it.

What to Expect on the Exam

One thing you really need to know about this exam: questions compound knowledge.

You’ll often see an answer that looks like the obvious, quick win. But it’s not the right one.

Slow down. Read carefully. There’s usually an additional constraint, feature, or enterprise-level detail baked into the question that changes the answer.

I also heard from multiple coworkers that the enterprise features caught them off guard. Because I had that heads-up going in, that section didn’t trip me up. If you’re studying, don’t skip enterprise topics. They matter.

Results & Timeline

• Score: 890 / 1000

• Study time: ~2–3 weeks

  • 1–2 hours after work on weekdays
  • A few hands-on labs on the weekends

I already had a background in Azure DevOps, which made the GitHub Actions content easier to digest, but this exam is still very doable if you’re consistent.

The Cheat Sheet

Below is the cheat sheet I put together to review right before the exam.

Domain 1: Author and Maintain Workflows (40%)

Workflow Triggers (Events)

Multiple Events

on: [push, pull_request]

Scheduled (Cron)

on:
  schedule:
    - cron: "0 2 * * 1" # Mondays at 2am UTC

Manual Trigger

on:
  workflow_dispatch:
    inputs:
      environment:
        required: true

Webhook Events

• check_run
• check_suite
• deployment
• deployment_status
• Used for CI/CD integrations and chained workflows

Workflow Components

Workflow Syntax Basics

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm install

Key Rules

• YAML indentation matters
• steps must be under jobs.<job_id>
• Each job runs on a single runner

Conditional Logic

Step Condition

if: github.ref == 'refs/heads/main'

Job Condition

if: success()

Dependent Jobs

jobs:
  build:
    runs-on: ubuntu-latest

  deploy:
    needs: build
    runs-on: ubuntu-latest

Runners

GitHub-hosted

• Short-lived
• No custom software
• Best for standard CI

Self-hosted

• Custom tools
• Network access
• Long-running jobs

Runner Labels

runs-on: [self-hosted, linux, custom-software]

Secrets & Environment Variables

Encrypted Secrets

env:
  API_KEY: $

Default Environment Variables

• GITHUB_REPOSITORY
• GITHUB_REF
• GITHUB_SHA
• GITHUB_RUN_ID

Custom Env Vars

• Workflow-level: env:
• Job-level: jobs.<job>.env
• Step-level: steps[].env

GITHUB_TOKEN

Use when:

• Creating issues
• Publishing packages
• Pushing to repos
• Authenticating to GitHub APIs

env:
  GITHUB_TOKEN: $

Workflow Commands

Set Environment Variable

echo "MY_VAR=value" >> $GITHUB_ENV

Set Output

echo "result=success" >> $GITHUB_OUTPUT

Publishing & Deployment

GitHub Packages / GHCR

• Authenticate
• Build artifact/image
• Push to registry

Service Containers

services:
  postgres:
    image: postgres:15

CodeQL

- uses: github/codeql-action/analyze@v3

Releases

• Create GitHub release
• Upload artifacts
• Deploy to cloud provider

Domain 2: Consume Workflows (20%)

Interpreting Workflow Effects

• Check commits, PRs, releases, issues
• Inspect triggered event via run metadata
• Read workflow YAML to infer behavior

Diagnosing Failures

UI

• Actions tab → Workflow → Job → Step logs

REST API

• List workflow runs
• Download logs and artifacts

Debugging

Enable Step Debug

env:
  ACTIONS_STEP_DEBUG: true

Data Between Jobs

Artifacts

- uses: actions/upload-artifact@v4

Outputs

outputs:
  version: $

Caching

- uses: actions/cache@v4
  with:
    path: ~/.npm
    key: npm-${{ hashFiles('package-lock.json') }}

Workflow Management

• Add status badge from Actions UI

• Delete vs Disable:

  • Disable: keeps history
  • Delete: removes file + history

• Environment protections:

  • Required reviewers
  • Deployment gates
• Matrix builds:

strategy:
  matrix:
    node: [18, 20]

Domain 3: Author and Maintain Actions (25%)

Action Types

Action Structure

action.yml
index.js
Dockerfile

Metadata

• name
• inputs
• runs
• outputs

Troubleshooting Actions

JavaScript

• Check Node version
• Review logs
• Validate action.yml

Docker

• Dockerfile errors
• ENTRYPOINT issues
• Permissions

Workflow Commands in Actions

• Exit codes control success/failure
• core.setFailed()
• process.exit(1)

Domain 4: Manage GitHub Actions in the Enterprise (15%)

Reuse & Distribution

• Reusable workflows (workflow_call)
• Centralized action repos
• Naming conventions
• Version pinning

Access Control

• Organization policies
• Allow/deny action sources
• Control who can use which actions

Runners at Scale

GitHub-hosted

• Subject to IP allow lists

Self-hosted

• Custom networking
• Proxies
• Labels
• Groups for access control

Runner Management

• Group runners by purpose
• Move runners between groups
• Monitor _diag logs
• Update runner binaries regularly

Secrets in the Enterprise

Access via:

${{ secrets.MY_SECRET }}

Today, I’m putting this into practice using GitHub Spec Kit to build the foundation of my latest personal project.

What is Spec-Driven Development?

Spec-Driven Development is a workflow where the requirements (the “Spec”) are the source of truth. Instead of asking an AI to “build an app,” you use it to help you define a Constitution, a Specification, and a Plan as guardrails. Only then do you move to execution.

GitHub Spec Kit is a relatively new framework (released in late 2024/early 2025) designed to streamline this within GitHub Copilot. For this session, I used GitHub Copilot with GPT-5 for the “Architect” phase (drafting the specs) and switched to Claude Opus 4.5 for the “Developer” phase (the execution).

Phase 1: The Constitution

In Spec Kit, the Constitution is the soul of your project. It defines your “laws”—tech stack, coding standards, and architectural constraints. It ensures the AI doesn’t hallucinate a random library or a different language halfway through the build.

I’m building a .NET 10 backend with a React/Tailwind frontend, targeting a Raspberry Pi 5 Kubernetes cluster. Here is the prompt I used to establish my rules:

Prompt: /speckit.constitution I want to build consitution for my application using the following technologies. Frontend: React, Tailwind CSS, Playwright (E2E). Backend: .NET 10, xUnit + FluentAssertions, WebApplicationFactory (integration tests). Platform: Kubernetes, Docker (ARM64-compatible images), Raspberry Pi 5 (initial target). Portable to major cloud providers. CI/CD & Ops: GitHub Actions (self-hosted runner), Dependabot, OpenTelemetry, Prometheus + Grafana. Before ever pulling in new technology consult me first.

The Result: constitution.md

Phase 2: The Specification

With the laws set, I needed to Specify. I wanted a “Hello World” API—something small to validate my K8s infrastructure so I can hit the ground running when my Raspberry Pi’s arrive later this wek.

Prompt: /speckit.specify I want to build a simple hello world application that I can I use for deploying and validating my kubernents cluster, which will be built later on.

The Result: hello-world.spec.md

Phase 3: The Plan & Tasks

If the Spec defines what must exist, the Plan defines how it will be built. Since I wanted to see how well the LLM handled the Spec Kit workflow, I let it take the lead on the roadmap.

Prompt: /speckit.plan create a plan based of the constitution and spec.

This generated the execution roadmap under hello-world-k8s-validation folder. To make it actionable, I immediately followed up with:

Prompt: /speckit.tasks create tasks

This produced a tasks.md file—a checklist of manageable units of work that the AI (or a human) can follow to complete the feature.

Phase 4: Execution with Claude Opus 4.5

This is where I switched gears. While GPT-5 handled the architectural “thinking” beautifully, I wanted to see Claude Opus 4.5 handle the “doing.”

Prompt: implement the tasks for this project

The magic of Spec Kit is that because the tasks.md and constitution.md were so well-defined, Claude didn’t have to guess. It implemented the hello-world endpoints, set up the OpenTelemetry logging, and generated the Dockerfiles for ARM64 (Raspberry Pi) compatibility without a hitch.

Before finishing, I realized I needed a .gitignore to keep things clean:

Prompt: create a .gitignore based on this project and git best practices

Final Thoughts

The entire session—from reading the Spec Kit docs to having a deployable, containerized .NET 10 app with full observability—took only 30 minutes.

I can’t test the infrastructure on the actual Raspberry Pi 5s yet (they are still in transit), but the code is reviewed, test pass and the telemetry is validated. Later this week, I’ll be automating the Pi setup with Ansible and a self-hosted GitHub runner. I will be able to test the rest out then.

Full Session Commit: https://github.com/rswitzer/etsy-optimizer/commit/bef4e399cfb166961ce99259f14709ec2505b7b0

And that’s how I ended up spending Day 1 of my upskilling project using GitHub Copilot Pro, VS Code, and GPT-5.1-codex to scaffold an actual application.

As a crafter who makes jewelry (Instagram and Etsy), I’ve got a backlog of pieces waiting to be listed. So why not build something useful? One of my upcoming side projects is an app that takes in a photo and generates an SEO-optimized Etsy listing. Perfect playground. Perfect excuse to explore where software engineering is going with agentic AI.

Why I’m Doing This Now

I’ve spent the last few years operating at the architecture level, so I’m intentionally pulling myself closer to implementation again. I fully intended to start with Kubernetes work, but the timing of the client request plus the personal project opportunity made GPT-5.1 the right place to begin.

To properly evaluate the tooling, I upgraded to GitHub Copilot Pro for Individuals. The free tier doesn’t include GPT-5.1-codex, and Pro comes with 300 premium requests per month.

A premium request is essentially a unit of consumption for advanced Copilot features. The quick summary:

How Premium Requests Are Calculated

• Base request unit: 1 premium request
• Applies to things like:
  • Copilot Chat prompts
  • Copilot Code Reviews
  • Copilot Coding Agent tasks such as creating PRs
• A model multiplier is applied depending on which Copilot model is used, but GPT-5.1 Codex is the primary one I’m testing here.

Starting the Experiment: Let’s Build Something

My first instinct was to dive right into my Etsy listing generator idea. Codex generated a lot of code very quickly, but I couldn’t get the project running. That’s on me – this is a new laptop I haven’t fully configured for development yet.

I realized that before evaluating Copilot as an engineering partner, I needed a known baseline. So I reset and started smaller.

Prompt 1:

“Create a .NET Core app with a health check page.”

Great starting point. A predictable output. Easy to validate. And a chance to assess whether the code felt trustworthy.

Copilot scaffolded a full application with multiple pages, including a weather endpoint I didn’t ask for. I prompted it to remove that. It did.

I hit debug and boom: healthy environment, healthy endpoint.

Refactoring Toward Best Practices

Once I knew my dev environment was working, I asked Codex to take the next step.

Prompt 2:

“Refactor this into a production-ready .NET Core application.
Keep only the health check endpoint.
Add a placeholder API for Listing Builder.
Add unit tests.
Use best practices.”

This is where the agentic behavior kicked in.

It created new projects, reorganized folders, scaffolded tests, deleted unnecessary files, attempted builds, and prompted me to allow command-line execution to update the solution structure. I could see the AI thinking and iterating.

When it finished, it produced a clean, professional-looking solution layout.

I briefly reviewed the code. Everything made sense. It read like something a senior engineer would produce. The unit tests passed. The app built. The health endpoint ran.

Now I have a solid foundation for the rest of the project.

The Final Touch: GitIgnore and Initial Commit

Before wrapping Day 1, I asked it to configure a proper .gitignore, then pushed the working scaffold to GitHub so I can pick this back up later in the week and begin building the UI, cleaning the code uo further and wiring up the backend.

Commit here

Early Takeaways After Day 1

1. Prompt-first development is real.
The more intentional and incremental your prompts, the clearer and more predictable the output.

2. Reading code matters more than writing it.
Copilot can generate astonishing amounts of code. Your value is increasingly in reviewing, shaping, and validating it.

3. Agentic workflows feel like pairing with a senior engineer.
It scaffolds, refactors, reorganizes, builds, and tests – not just a text generator, but an active engineering partner.

4. The productivity boost is no joke.
What normally takes 1–2 hours took about 10 minutes.

I haven’t even touched the actual Etsy listing logic yet, but the foundation is there. And I can already see how this will reshape how engineers and architects build software.

This was just Day 1 with GPT-5.1 Codex in agent mode. I’m excited to see how far I can push it next.

Where AI Does the Job: Abstracting the Friction

I use GenAI to eliminate necessary but non-enjoyable tasks that cause friction:

• Aesthetics for “Good Enough”: I use ChatGPT to generate header images simply by describing what I want. I have no desire to spend time in Photoshop. The goal is a “good enough” aesthetic so that my focus remains entirely on the technical message.
• Content Structuring (The Ramble-to-Organize Method): This is the biggest win. I’ll be frank: I hate writing and organizing my thoughts. Now, I bypass that friction entirely:
  • I open a prompt in ChatGPT, Copilot, or Gemini and just start “talking” out every stream-of-consciousness thought I have.
  • I treat it like expressing my thoughts to a friend.
  • The AI then converts that messy, rambling stream into an organized, coherent, and grammatically sound blog post structure.

GenAI allows me to “get my words out” quickly, ensuring my energy is spent on the core message, not the mechanics of writing.

Where I Draw the Line: Preserving the Creative Process

While I embrace GenAI for functional efficiency, I maintain a firm, non-negotiable boundary: I do not use GenAI in my personal arts or crafts.

I believe there is still a special, beautiful quality in something created from the human mind and hands. I love the creative process itself—the friction, the experimentation, and the hands-on effort. There is value and beauty in that. For me, the value of this blog is in the technical experience, so I use GenAI to protect my time for that, but I deliberately choose to avoid it in my personal creative pursuits where the process itself is the reward.

GitHub Pages is a free static site hosting service that publishes a site directly from your GitHub repository. Jekyll is the static site generator used by GitHub Pages. It converts Markdown, Liquid templates, and theme files into a complete static HTML website.

Because I’m using GitHub Pages’ built-in Jekyll build, it runs in safe mode, which means:

• only approved plugins are allowed
• gem-based themes work normally
• remote themes are supported
• no custom build pipeline is needed

This is perfect for a lightweight, low-maintenance technical blog.

Tip: Customizing Your Theme

I followed the official GitHub Pages Quickstart, but I hit a few common friction points once I started customizing.

1. Theme Compatibility Issues

Each Jekyll theme expects a specific file structure. Switching themes often produces errors about missing layout files or front matter, because themes define different required pages and partials.

2. Hidden Theme Source

Most Jekyll themes are shipped as Ruby gems. Their internal files — layouts, includes, Sass — are not visible in your repository, which means you cannot directly edit things like:

• header layout
• navigation partials
• page templates

The Customization Fix

To customize deeper than configuration alone allows, you simply override the theme files locally.

The process is straightforward:

1. Visit the theme’s GitHub source repository
2. Download the parts you want to customize

3. Copy them into your own repo under:

   • _layouts/
   • _includes/
   • _sass/

Any file placed in your repository automatically overrides the version inside the theme gem. No forking or custom builds needed.

Choosing Stability: Locking Down the Remote Theme

I ended up sticking with the default Minima theme but switched to the dark variant. Because GitHub Pages supports remote themes, you can reference a theme repository directly in your _config.yml.

But here’s the architect’s trick for long-term stability:

Pin the remote theme to a specific commit.

Instead of referencing the theme repo like this:

remote_theme: owner/repo

you pin it like this:

remote_theme: owner/repo@<commit-hash>

This ensures:

• no unexpected theme updates
• no surprise build breaks
• consistent layout and styling over time

This works even without GitHub Actions, because GitHub Pages allows remote themes — and allows pinning them — as long as they are GitHub Pages–compatible.

Note: I will eventually give the GitHub Actions deployment a try.

This is the “Why” that drives me to carve out time for hands-on work and share my experiences:

1. Reconnecting Architects to Implementation

   We are former engineers who love solving problems, but years in the architecture space can lead to abstraction from implementation details. This blog is my way of figuring out and showing other architects how to stay hands-on.

   • The Benefit: Going through the implementation process is the crucial step in evaluating technology. It quickly reveals where marketing hype ends and real-world complexity begins, ensuring our decisions are practical and ultimately making us better architects.

2. Career Accountability and Marketability

   The GenAI revolution is rapidly making the technical market competitive. This blog serves as a mechanism to:

   • Keep Myself Accountable: It is a public commitment to continuous learning and upskilling in my career.
   • Showcase My Knowledge: It allows me to build a portfolio that demonstrates what I can do and how I think, helping me maintain my competitive edge.

3. Making Engineers’ Lives Easier

   As a technical leader, my responsibility is to reduce friction and set my engineers up for success.

   • Empathy Through Experience: Being hands-on during implementation is critical for building empathy for the engineering team.
   • Responsible Leadership: Making good decisions with technology, and using tools like GenAI responsibly, is how we reduce mental load and stress, leading to happier, more successful engineers and teams.

This blog is my commitment to bridging the gap between high-level strategy and low-level code, ensuring that every architectural decision I make is informed by current, real-world development experience.

And here’s the truth: I’m rusty.

When I was an individual contributor, I often questioned architectural decisions. Did this architect ever even touch the technology they’re recommending? I remember the early days of Xamarin—marketed as revolutionary, but in practice it was clunky, unstable, and frustrating. I spent countless hours just trying to get builds to work locally. That experience left me wishing architects had more firsthand knowledge of the tools they were prescribing.

Now, standing on the other side of the table, I understand why. Architects are buried in meetings, juggling deadlines, and rarely have time for proof-of-concepts. Staying current often means sacrificing personal time, and after eight hours of calls and coordination, the thought of diving into new tech can feel exhausting.

But I don’t want to lose touch.

My Plan: Learning by Building

This blog will document my journey back into hands-on engineering. My goal is to find simple, meaningful ways to stay up to date—projects that tie into my passions outside of work, so learning doesn’t feel like yet another obligation.

Here’s what I’m setting out to do:

• Kubernetes Raspberry Pi Cluster
  I want to build a small Raspberry Pi cluster to learn Kubernetes in a tangible, experimental way. It’s a chance to explore container orchestration beyond theory and documentation.

• AI-Powered Etsy Listing Generator
  Jewelry making is one of my hobbies, but my Etsy shop often sits neglected. Supplies are costly, and I’d love to improve my selling process. My idea: an AI tool that takes a photo of a piece, generates an SEO-optimized listing, and posts it directly to Etsy via their API.

  I’ll treat this project like a client engagement—implementing automation with CI/CD pipelines using GitHub Actions, infrastructure as code with Terraform, and leveraging AI coding assistance. In short, I want to walk through the entire software lifecycle, but for a project that’s personal and fun.

Why This Blog Matters

I hope this blog inspires others to rediscover the joy of building. We became software engineers because we love to code, but somewhere along the way, deadlines, meetings, and workplace drama can make us forget that spark.

By sharing my journey—the frustrations, the experiments, the wins—I want to show that upskilling doesn’t have to feel like work. It can be a creative outlet, a way to reconnect with why we started coding in the first place.

So here’s to learning, tinkering, and building projects that matter to us.