DEV Community: Peter Tamas

AI FIELD NOTES #002 – Weekly memos for Engineering Leaders

Peter Tamas — Tue, 07 Apr 2026 13:12:03 +0000

You are a software engineer, so you know that feeling. You are deep in dependency hell, reading library docs, digging through version histories, staring at compatibility matrices. Running tools to detect transitive version conflicts.

I got tired of it, too. So I asked Opus 4.6 to build a version checker hook and let AI deal with this problem instead of me. It turned out to be one of the most quietly impactful things I've added to my workflow.

At Bobcats Coding, we've deliberately built AI into our delivery system: how we specify, how we build, how we test, and how we learn. (Of course, if you are in the middle of a large legacy codebase with years of untouched dependencies, your mileage may vary, but that's a story for another time.:))

The core issue

One of my recurring frustrations with AI-generated code was debugging problems caused by poorly selected dependency versions. When you let AI add a dependency to a project, it usually does not install the latest version of the library. Instead, it often selects an artifact that is a few major versions behind the latest release. This behavior caused two types of issues for me repeatedly:

Usage of already deprecated functions
Version mismatch bugs

If you don’t have proper E2E tests in the project, version mismatch bugs can be very difficult to detect. The feature simply doesn’t behave as expected, usually without any error messages, which makes debugging extremely frustrating.

After running into this situation multiple times across several projects, I asked Opus 4.6 to create a version-checking script and integrated it into a PostToolUse hook, that:

checks whether all project dependencies are up to date (similar to Dependabot)
detects version mismatch issues

Since I started using this hook, I’ve never had to struggle with dependency versions again.

When AI adds a new dependency for a feature, even if I miss an E2E test for a particular scenario, this hook saves me a lot of time by catching hidden issues caused by version mismatches.

After every change in my dependencies, it runs version checks and automatically iterates on dependency versions until they align and all tests pass.

The fix

Ask AI to create a version-checker PostToolUse hook in projects that:

shows a warning when it detects a newer version of a dependency
checks for version mismatch issues and resolves them when found
detects transitive dependency conflicts and resolves them automatically

Best practices:

Update dependencies in a separate commit or PR when warnings appear to keep the project up to date.
Use TDD with BDD-style E2E tests (only partially related, but still helpful for catching subtle runtime issues).

Resulting Workflow

AI adds dependencies during feature implementation
The PostToolUse hook detects version issues
The hook automatically aligns dependency versions
Lint, type checks, and tests verify correctness
Only stable commits enter the repository

Result:

Automated dependency version assurance
Reduced debugging time
Safer AI-generated code

What I learned

In my full-stack TypeScript projects, the hook works surprisingly well. Even when the updated major versions were not yet compatible with each other. The feedback loops in the project recognized this and automatically iterated with minor versions, reading issues and forums, and also automatically came up with a small, effective, temporary patch that solved the incompatibility issue.

The bottom line: connecting a version-checker pre-commit hook to all your projects isn't optional when you're working with AI-generated code. It's a mandatory feedback loop for maintaining developer productivity and saving a lot of my nerves.:)

Want to try it? Here is my implementation example

In my TypeScript projects, I implemented this workflow with a small script:

check-versions.ts

It performs:

dependency outdated checks
peer dependency mismatch detection
transitive conflict detection
optional automatic resolution

Example usage:

bun scripts/check-versions.ts              # All checks (pre-commit)
bun scripts/check-versions.ts --mismatch   # Mismatch only (fast)
bun scripts/check-versions.ts --fix        # Auto-resolve mismatches + transitive conflicts
bun scripts/check-versions.ts --json       # JSON output (for Claude hook)

This allows different checks depending on the stage of the workflow.

For example, the fast mismatch-only check is ideal for pre-commit hooks.

An example output of the script:

bun scripts/check-versions.ts 2>&1)
  ⎿  ⚠ OUTDATED PACKAGES:
       @vitejs/plugin-react           4.7.0 → 5.1.4        ▲ major
       vite                           6.4.1 → 7.3.1        ▲ major
       @colyseus/schema               2.0.37 → 4.0.17      ▲ major
       colyseus.js                    0.15.28 → 0.16.22    ▲ minor
       @colyseus/ws-transport         0.15.3 → 0.17.9      ▲ minor
       colyseus                       0.15.57 → 0.17.8     ▲ minor
       @colyseus/testing              0.15.4 → 0.17.11     ▲ minor
       @biomejs/biome                 2.4.4 → 2.4.6        ▲ patch
       @storybook/react               10.2.13 → 10.2.16    ▲ patch
       @storybook/react-vite          10.2.13 → 10.2.16    ▲ patch
       storybook                      10.2.13 → 10.2.16    ▲ patch

     ✓ No version mismatches or transitive conflicts.

The `check-versions.sh` hook

In the .claude/hooks folder, I created the check-versions.sh script, where I run the check-versions.ts script only when a package.json file is modified.

#!/usr/bin/env bash
# Version checker hook — runs after PostToolUse on Edit/Write.
# Only fires when the modified file is a package.json.
# Runs mismatch check and injects result into Claude's context.

set -euo pipefail

INPUT=$(cat)
ROOT="/Users/kond/kondfox/isuperhero-claude"

# Extract the file path from the hook payload
TOOL_INPUT=$(echo "$INPUT" | jq -r '.tool_input // empty' 2>/dev/null || true)
FILE_PATH=$(echo "$TOOL_INPUT" | jq -r '.file_path // empty' 2>/dev/null || true)

# Only run when a package.json was modified
if [[ -z "$FILE_PATH" ]] || [[ "$FILE_PATH" != *"package.json"* ]]; then
  exit 0
fi

# Run mismatch check only (fast, no network call)
cd "$ROOT"
RESULT=$(~/.bun/bin/bun scripts/check-versions.ts --mismatch --json 2>&1 || true)

echo "$RESULT"

`PostToolUse` hook integration

In the .claude/settings.json I defined the PostToolsUse hook:

{
  // ...
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "/Users/kond/kondfox/isuperhero-claude/.claude/hooks/check-versions.sh"
          }
        ]
      }
    ],
  // ...
}

Pre-commit Integration (Husky)

The script runs automatically before every commit via Husky.

Example pre-commit hook:

#!/usr/bin/env sh
cd"$(git rev-parse --show-toplevel)"

~/.bun/bin/bun scripts/check-versions.ts--fix
~/.bun/bin/bun run lint:fix
~/.bun/bin/bun run typecheck
~/.bun/bin/bun run test
~/.bun/bin/bun run test:e2e

This ensures that:

dependency versions are aligned
lint errors are fixed
types compile
unit tests pass
E2E tests pass

before any commit enters the repository.

This creates a tight feedback loop for AI-generated code.

You can see a full working example here:

https://github.com/kondfox/isuperhero-claude

The repository contains the full check-versions.ts implementation and the Husky integration used in production.

Legacy project?

I have doubts about how good idea it is to integrate the version checker feedback loop into a legacy project where the dependencies are far behind the actual versions. But I’m gonna give it a try in such a project shortly, and share the result with you.

AI Field Notes #001 | Is AI frontend development finally getting good? Our Opus 4.6 test says yes. (And no.)

Peter Tamas — Tue, 07 Apr 2026 13:00:00 +0000

In December 2025, I wrote about trying to build a full page with AI with a much smaller scope, and it didn’t go well.

At that time, my conclusion was that while implementing a simple, small UI component with AI and Figma MCP worked quite well, it was surprising how badly it handled the implementation of a full page. The small UI component generation wasn't perfect either. I could get a ~90% "close enough" output that I could quickly align to the requirements by hand. But when I asked AI to implement a simple login page that contained only already-existing components, even with Figma MCP, the result was disappointing. The layout was far from the design, and it hallucinated elements that weren't in the design at all. No matter how I prompted, it just produced different hallucinations. Which I really don't understand, because Figma MCP provides a structured description of the design. In the end, I spent much more time experimenting with AI than it would have taken to puzzle the components into their places by myself within a few minutes.

My current experience is still not flawless, but I'm amazed by the improvement in this area over the past 3 months. I managed to implement a whole complex page, with existing and new components, that I had estimated at 48 hours, in just 8 hours. Not in one iteration, not 100% AI-generated, not without refactoring and human code reviews, but the velocity is impressive.

Some Context on the Comparison

After having satisfying experiences with Opus 4.6 UI component implementation, I was eager to retry a full-page AI implementation experiment. When you don't have a strict specification, it's easy to vibe-code a fair-looking result, but it's hard to evaluate how well the output matches the client's needs. That's why I chose a project where we had clear requirements:

Figma designs that we need to implement
An OpenAPI specification of the backend API

These are strict, structural anchors that provide clear and easy verification of the result.

The state of the project when I ran my experiment:

The project was already "Claude-ready". It had a well-set-up, project-specific Claude.md that my colleagues had been using for months.
We already had an API client, but none of the endpoints that this page uses were defined in it yet.
The site layout, design system, and some of the UI components that the page needed were already in place, but the design also contained new, complex UI components.

Unfortunately, this was a client project we built at Bobcats Coding, so screenshots, product details, and the repository stay private. But I'm going to write about everything else.

The first iteration

The better you specify, the better outcome you can expect. This isn't a new directive; it was true before AI coding as well. But with agentic engineering, specification is the new code.

So I spent ~1 hour specifying the task as my initial prompt. I gave a general context about the page we were building, linked the design of the whole page in Figma and the components one by one. I gave a clear specification for each element of the page: which API endpoint it gets its data from, what it represents, how it should work. I specified all the page actions as well. What should happen when a button is clicked, when a dropdown element is selected, and so on. I also instructed Claude to generate every new UI component in a reusable way within our UI library, test them, and provide Storybook stories and documentation.

I asked AI to create an implementation plan that multiple agents could work on in parallel (because I was curious how this would work). I required a contract-first approach so that the results of the asynchronously working agents could be integrated at the end.

Opus 4.6 worked for 9 minutes to create the plan. It correctly found all the files in the project that it needed to modify and the workspaces and folders where it should create the new files.

It separated the work into 4 agents with clear responsibilities, tasks, and restrictions:

Agent 1: API Layer

Update the API schema
Generate API types from the schema
Create and export DTO types
Add mapping functions
Implement new API client methods based on the given interface
Add unit tests

Agent 2: UI Components

Implement the discovered new UI components (the plan listed their names, dependencies, and functional descriptions)
Add unit tests
Create Storybook stories
Export the components from the UI library

Agent 3: Page Composition

Replace the current placeholder component on the page (server component)
Call the proper API client methods for data
Feed the data to the created client component
Implement the layout and state management of the client component
Place the required UI components on the page
Implement the page actions

Agent 4: E2E Tests

Write the necessary BDD-style E2E tests for the page (the BDD features were also included in the plan for quick human verification)

It created an execution order as well:

Phase 1 (parallel): Agent 1 (API) + Agent 2 (UI Components)
Phase 2 (after Phase 1): Agent 3 (Page Composition)
Phase 3 (after Phase 2): Agent 4 (E2E Tests)

Agents 1 and 2 have zero dependencies and run fully in parallel.
Agent 3 depends on both but can start skeleton code immediately.
Agent 4 runs last as it needs rendered DOM.

The execution of the plan took 29 minutes and 25 seconds.

The result at first glance was a bit odd. It clearly contained all the required elements and showed the data correctly from the API, but the layout was broken, and the component designs were only ~80–90% faithful to the Figma designs. No hallucinations, though!

All in all, it was not great, not terrible for a first iteration.

Refining the design

I asked Claude to use Playwright MCP to verify its result: find the differences from the Figma design and fix them.

Using Playwright MCP as a feedback loop in frontend development works surprisingly well. Claude opens the page in a browser, takes screenshots, analyzes them, finds the problems, fixes them, verifies the fix with Playwright again, and iterates until it's solved.

However, my prompt was too vague, and the use of Figma MCP is still far from perfect, so the result was also disappointing. What worked much better was creating screenshots of both the UI implementation and the expected design, then describing the problems. Most of the design issues could be solved this way.

Creating a 100%, pixel-perfect design is still not something an LLM is capable of.

You need to recognize the point when the agent gets stuck in a loop, when every iteration just makes the problem different, but you don't get any closer to the solution. That's the point when you need to take the keyboard and finish the job yourself.

In the case of pixel-perfect design implementation, in my experience with current models and tools, you can usually reach a ~90–95% state with AI.

Refining the code

Opus 4.6 generates relatively decent code, but most of the time it needs some refactoring. In the case of this experiment, here's what I found during code review:

It didn't create components for all the UI elements it should have. This led to unnecessary duplication that would have been difficult to maintain.
It didn't always use the tokens from the design system or our SASS mixins (e.g., for typography).
I found some overcomplicated, mutating logic that could have been written more simply.
It didn't create some of the components as reusable as I expected.
It hardcoded some constants that shouldn't have been hardcoded.
It wasn't forward-thinking enough to extract functionality we could reuse later into a hook or utility function.
It used far more useMemo than necessary. But when I pointed these out to Claude, it could fix them much faster than I would have. With proper permissions, it can even read PR comments from GitHub, so you don't necessarily need to prompt these manually. You can just review on GitHub, then give a short fix my reviews on the PR instruction.

What didn’t work

Figma MCP still surprisingly underperforms compared to a simple screenshot.

The multi-agent implementation was fun to try, but resulted in a 3,000+ line PR, which is far from optimal. Next time, after I have the multi-agent implementation plan and the contracts (types, interfaces) in the code, I'd try to solve the task on separate branches using worktrees.

What worked

With all the refinements, I could ship the module in ~8 hours instead of the estimated 48 hours. Fully tested and documented. Two things stood out from the start:

1. Playwright MCP is a MUST in frontend development.
2. Creating the API schema mapping, types, and API client based on the given OpenAPI specification worked perfectly, even on the first iteration.

I don't think AI frontend development is solved, but for the first time, the velocity feels real. One thing's for sure: I'll keep testing, and I'll keep writing when something interesting happens.