DEV Community: Christopher Groß

My worst Claude Code sessions – and what they taught me

Christopher Groß — Wed, 29 Apr 2026 14:31:49 +0000

Everyone talks about how much time AI saves. True. But nobody talks much about the hours you lose to AI mistakes.

I've been using Claude Code daily for months. My workflow has fundamentally changed, I'm faster, I ship more consistent code. All of that is true. This article is the counterpart – the moments where I sat at my terminal thinking: "What on earth did that just do?"

Not to bash AI. But a realistic picture is more useful than endless hype.

The aggressive refactor

I had a Vue component spread across three files – historically grown, not pretty, but functional. My request was harmless enough: "Clean this up and consolidate the types."

Claude Code did that. And then some more. And then some more.

At the end I had an elegant, clean component – and four features that had quietly disappeared. Including an edge case for loading empty content that wasn't documented anywhere, but was silently expected by two other parts of the app. No test, no comment, no hint. The AI analysed the code, not the behaviour behind it.

What happened: Claude Code had no context about the overall application behaviour. The refactoring was technically correct – but it broke implicit behaviour that was never written down anywhere.

What I do differently now: For refactors, I explicitly state which behaviours must be preserved – not just which files should be touched. "Clean this up, but these three cases must still work afterwards: ..." That sounds obvious. But I forgot it regularly at the start.

The hallucinated API

This one is uncomfortable to tell, because the mistake was partly mine.

I asked Claude Code to write an integration with an external service. The response was fluent, confident, well structured. Methods that sounded plausible, parameters that made sense – everything there.

Only: two of the methods didn't exist. The API never had them. Claude knew an older version of the documentation, or simply made them up – I don't know exactly. What I do know: the code compiled, threw no type errors, and only crashed on the first real API call.

I could have caught this earlier. I should have checked the official docs before accepting the code. I didn't. I was in flow, the code looked good, and I trusted it.

That's what makes confidently wrong output dangerous. When AI hesitates or writes "I'm not sure", I'm cautious. When it responds clearly and structured, I lower my guard. That's exactly the wrong reflex.

What I do differently now: Everything touching external APIs or libraries gets verified against the original docs. Not because I fundamentally distrust the AI – but because the risk is high and the check usually takes two minutes.

The missing context in CLAUDE.md

This one is entirely my fault – but it involves Claude Code, so it belongs here.

I had a new website section implemented. The builder agent did good work, the section looked clean. Except: the section labels – small, monospace formatted labels above headings – were written in plain text instead of CLI style.

That rule wasn't documented in my CLAUDE.md. I had introduced it at some point – all section labels must use terminal style, with a $ prefix or // comment syntax – but I'd forgotten to write it down.

The AI oriented itself to what it saw: older sections I had built myself before introducing the style. It derived a pattern from those. The pattern was wrong, because I had changed my own system over time without updating the documentation.

The result: I had to correct all the labels manually and finally write the rule into the CLAUDE.md.

What I do differently now: When I dislike an output and think "the AI should have known that" – first question: is it in the CLAUDE.md? Usually the answer is: no, not yet.

The logically wrong, syntactically correct code

This is the most subtle mistake – and the one I took longest to find.

I had a filter function that should filter posts by category and tag – combined, with an AND operator. Claude Code wrote the function, it compiled, it passed the obvious test case.

What I only noticed days later: the function had implemented OR instead of AND. Not because the AI doesn't know the difference – but because my request hadn't defined the logic unambiguously. I had written "filter by category and tag". That can mean AND. But it can also mean OR if you read it as: "give me posts that match the category, and give me posts that match the tag".

The AI chose an interpretation. It didn't ask me. And I checked the output for syntactic correctness, not logical correctness.

What I do differently now: For logic involving boolean operators, I write the expected results explicitly into the request. "Filtered with AND: only posts that satisfy both conditions should appear." Two extra sentences. Prevents hours of debugging.

What these failures have in common

When I look back at my worst Claude Code sessions, I see a pattern:

The AI didn't fail because it's bad. It failed because context was missing – either in my request, in my documentation, or in my review process.

Implicit knowledge about my project doesn't exist for the AI. What I find "obvious" because I've been working with this codebase daily for months is only visible to Claude Code if it's documented or directly derivable from the code.

Confident output is not a quality signal. That's perhaps the most important insight. The AI sounds roughly equally certain at all times. Whether it's doing a trivial formatting task or inventing an API – the tone stays similar. My skepticism must not depend on the tone.

My requests were imprecise. At least half of the described failures could have been prevented with a more precise prompt. "Clean this up" is not a specification. "Implement the filter" is not a specification. That's a wish. A specification defines what must be true at the end.

The developer stays responsible

I review Claude Code output differently than before. Not more superficially – more thoroughly, but in different dimensions.

Syntax? Usually correct. Types? Usually correct. Logic in non-trivial cases? I read slower. External dependencies? Cross-check. Implicit behaviour expectations? Formulate explicitly before the AI starts.

The speed Claude Code gives me is real. The mistakes that can happen along the way are too. Knowing that and working with it saves time. Ignoring it and blindly accepting output will eventually cost you a night with a bug that a two-minute review would have prevented.

AI is not an autopilot. It's a very capable copilot that believes everything you tell it – including the things you forgot to say.

Originally published on grossbyte.io

Vibe coding vs. spec-driven – I got the bill

Christopher Groß — Wed, 22 Apr 2026 10:23:33 +0000

There is that moment at the beginning of a new feature where everything is still open. No legacy code, no constraints, no unexpected dependencies. Just you, an empty directory and an AI tool that promises to deliver results in minutes.

In moments like that, vibe coding is incredibly tempting. Just start. Prompt in, code out, next prompt. No planning, no specifying, no thinking about architecture. Just do it.

I did that. I paid for it.

What vibe coding really means

The term "vibe coding" – coined by Andrej Karpathy – describes an approach where you use AI tools without having clearly defined what you are actually building. No schema, no design system, no explicit rules. You "vibe" your way through the feature.

That is not fundamentally wrong. For a quick prototype, a throwaway demo, a first feasibility check it works well. Within an hour you have something running on screen. The feeling is great.

The problem comes later.

The bill

Over the past months I have seen projects – my own and others' – that started with vibe coding. The pattern is always similar: the first sprint runs surprisingly smoothly. Then sprints two and three arrive. And suddenly you are fighting code that technically works but is architecturally a mess.

Specifically: components that know too much. State management spread across three different approaches because the AI chose a different path with each prompt. Inconsistent naming. Duplicated code, because the AI on the second prompt did not know it had already built something similar on the first.

And the worst part: when you try to fix it afterwards, you are not fighting the AI – you are fighting the accumulated decisions of twenty previous prompts, each locally sensible but globally inconsistent.

Those of us working as senior developers or freelancers with real architectural influence notice this particularly fast. You have the experience to see where it is heading. And that experience tells you: this is going to be expensive.

The difference that specification makes

The principle is simple: before I let the AI write even a single line of code, I have defined what I am building, how it should be structured, and by which rules the code gets written. Not as a hundred-page requirements document, but as a living document – a CLAUDE.md, a component library, an explicit design system.

What changes because of this: the AI no longer makes architectural decisions. I made those beforehand. It just implements them.

That is the decisive shift. Vibe coding lets the AI decide which path to take. Spec-driven development tells it which path to take.

What this looks like in practice

A concrete example from my own website. When I built the blog section, I had two options:

Option A – vibe: Tell Claude Code "build me a blog" and see what comes out.

Option B – spec: First define which frontmatter fields a blog post needs, which components get used, how routing works, how i18n integrates – and then let Claude Code handle the implementation.

I chose option B. The result was consistent code, fewer revisions, and I never had to explain "no, not like that" – because "like that" was clear from the start.

The specification as single source of truth

# CLAUDE.md

## Frontmatter schema
title, slug, translationSlug, date, category, description, readingTime, tags, featured, draft

## Components
- GbCard: default / project / highlight variants
- GbButton: primary / ghost / cta-inverted variants
- No new markup before checking existing components

## Coding rules
- Composition API only
- Tailwind only
- No hardcoded text

That sounds like bureaucracy. But it is the opposite: it is the foundation on which I can work quickly without constantly looking back.

What this means for senior developers and freelancers

I think vibe coding is a particular problem when you – like me – work as a freelancer and carry full architectural responsibility. As a junior developer in a large team there are guardrails: existing codebases, team conventions, architects who make decisions. The structure is already there – you simply work within it.

As a freelancer, you are the architect. If you do not define the structure, nobody does – and then the AI "defines" it implicitly, prompt by prompt. That sounds more efficient than it is.

The real strength of AI tools is not that they can write code fast. It is that they work consistently and reliably within clear boundaries. Those boundaries have to be set by a human.

The compromise I found

I am not writing this because I think vibe coding is fundamentally wrong. Sometimes a quick prototype is exactly the right thing. A throwaway experiment, a proof of concept for a client, a feature demo – there you can vibe.

But as soon as something goes to production, as soon as other developers need to work on it, as soon as maintainability matters: then I need the specification first.

The difference in my day-to-day: I sometimes vibe prototypes. I always spec projects.

Vibe coding gives you something running fast. Spec-driven development gives you something that runs – and that someone will still understand six months from now.

Originally published on grossbyte.io

The ticket as a thinking tool – before the first line of code

Christopher Groß — Wed, 15 Apr 2026 14:27:36 +0000

It was a Tuesday afternoon. I had a task: a filter component for a product list needed to be faster. I knew roughly where the problem was – so I just started.

Three hours later I had a significantly more complex component, a refactored state management layer and a pile of open questions. Was this solved on the frontend or could it have been addressed on the backend? Which filter options should actually be cached? And what was the difference with the mobile view again?

I had been coding without really understanding the problem. The result showed it.

A ticket is not a bureaucratic act

When I use the word "ticket", I sometimes hear a quiet groan. Fairly enough – in many teams, a ticket means: fill out a Jira form, write "N/A" in three fields, add a deadline, assign a sprint. That has about as much to do with what I mean as a doctor's appointment with a spontaneous walk in the park.

A ticket in my sense is simply: a short, clear description of a problem and the expected result. Two paragraphs. Sometimes three bullet points. Done.

The crucial thing is not the ticket itself – it's the act of writing. Whoever has to write a problem down first has to think it through. And that is the real gain.

What a good ticket contains

I keep it simple. Three things are almost always enough:

Goal: What should be better after this change? Not "optimize the filter component" – but "the filter component should respond without visible lag at 500+ entries."

Acceptance criteria: When is the task done? "Filter interaction under 100 ms, tested on a mid-range Android device." No essay – but concrete enough that I know at the end of the day whether I'm finished.

Out of scope: What is explicitly not part of this task? That's the underrated part. When I write down "backend caching is a separate ticket", I'm not suddenly deep in a different problem three hours later.

Why this matters even more with AI

Anyone who has been following the context engineering discussion already knows the principle: the AI is only as good as the context it receives. A ticket is the application of that principle at the level of the individual task.

Before, I could start coding with a vague plan and at least trust my own judgment. I know the codebase, I understand the context, I notice when I'm going off track.

An AI model can't do that. It has no context beyond what I give it. If I write "optimize the filter component", I get code that optimizes something – maybe exactly the right thing, maybe something that improves performance but breaks accessibility, maybe a generic solution that doesn't fit the project at all.

The ticket forces me to build that context before I hand it off. After that I can give the AI a precise task – and I get a precise result.

Clean commits as a side effect

Working with tickets comes with a gift: a readable git history.

Every commit references a ticket. fix: GBW-42 – filter response time under 100ms. Three months later I know immediately: what was the problem? Why was this changed? What was the scope?

Without tickets it looks different. fix: performance. update filter. changes. These commits have given me many grey hairs in my career – usually my own.

The connection is direct: whoever has described the problem clearly can also name the solution clearly. And a clearly named solution is a good commit.

The side effect that surprised me most

Sometimes, when I sit down to write the ticket, I realize I can't.

Not because the problem is too complex – but because I can't clearly formulate the goal. I sit down and realize: I don't actually know what I want. Or: the feature doesn't actually make sense in the current state of the project. Or: this isn't a frontend problem at all, it's a data model problem.

That's not a failure of the ticket. That is the point. Writing a ticket costs me ten minutes. Coding in the wrong direction for three hours costs me – well – three hours. Plus the time to undo it.

The ticket is the cheapest mistake I can make. Because when it happens, it happens on paper.

How I handle it today

I use YouTrack for my own projects – but the tool doesn't matter. What matters is the moment before the first commit: is there a ticket for this?

For my own projects I write the ticket myself – often in five minutes. For client projects it's usually already there, or I help shape it. And when someone says "this is just a small thing, does it really need a ticket?"

My answer: precisely because it's a small thing, the ticket takes two minutes. And if it turns out not to be a small thing, you just figured that out – without having written a single line of code.

Whoever cannot write a ticket has not yet understood their problem. And whoever has not understood their problem should not be writing code yet – neither themselves nor via AI.

Originally published on grossbyte.io

Context Engineering: Why Your Prompt Is the Smallest Problem

Christopher Groß — Wed, 08 Apr 2026 09:33:27 +0000

I was at a client project recently, facing a situation I know well by now. New codebase, no AI tooling set up, and a developer on the team asks me: "How do you get the AI to produce such good results?"

I looked at his screen. He had Claude open - in the browser, no project context, a fresh chat for every single task.

That's the problem. Not the tool, not the model, not the prompt. The missing structure.

After a year of using AI daily in real projects, I'm convinced: the difference between "AI is pretty decent" and "AI has fundamentally changed how I work" isn't the perfect prompt. It's the context you give the AI - before it answers the first question.

CLAUDE.md Is Where Everything Starts

When I start working on a new project with Claude Code, the first thing I create is the CLAUDE.md. Not the first component, not the first feature - the context file.

What goes in it? Everything a new developer would need to know on day one:

Tech stack and versions
Project structure and why it's set up that way
Design system - colors, typography, spacing - concrete, with actual values
Coding rules: what always applies, what never does
External links, API endpoints, important accounts

That sounds like work. It is - once. But after that I save myself from rebuilding that context in every single AI session. I don't explain "we use Tailwind, not Styled Components" or "all texts must go through i18n" anymore. It's in the file. Claude reads it, follows it.

The practical difference: when I say "create a new section for the services page", I get code that uses my design system, my components, is TypeScript strict and contains no hardcoded strings. Not because Claude is magic - because it knows the rules.

PRODUCT_SPEC.md - The Product Vision Written Down

CLAUDE.md describes how things are built. PRODUCT_SPEC.md describes what and why.

I created it the first time when I realized: if I haven't touched a project for three weeks and then pick it back up, I need a moment to get back into the right frame of mind myself. The AI needs that even more.

My PRODUCT_SPEC.md covers things like:

What is the core promise of the product?
Who are the users and what do they want?
What features exist, and what design decisions are behind them?
What was deliberately not built - and why?

That last point is underrated. "What we don't build" is just as important as "what we build". If I don't tell the AI that we've deliberately decided against a certain feature, it will suggest or even implement it the next time it seems relevant.

Externalizing Coding Rules - Not Explaining Them in the Prompt

I've noticed that a lot of people include their rules in the prompt every time. "Don't write inline CSS. Don't use any types in TypeScript. Always create a German and English version."

And then they write that again for the next task.

That's exhausting - and error-prone. At some point you forget it, or you phrase it slightly differently, and the AI interprets it slightly differently.

My solution: a thorough section in the CLAUDE.md. Everything that always applies goes there.

A few examples from real projects:

- ESLint must pass without errors before every commit
- No eslint-disable comments without explicit approval
- Every new text must appear in i18n/de.json and i18n/en.json
- Typography: en dash with non-breaking spaces, never the English em dash

That last rule is one anyone recognizes who has forgotten to specify it. I learned it by spending an hour fixing wrong dashes across an entire project.

Recurring Tasks as Skills

This is the part that gets talked about the least - and the one that has helped me the most.

Every project has tasks that always run the same way. After a new feature: run the linter, take a browser screenshot, comment on the ticket with the result. For a new blog post: validate frontmatter, run the typography check, create the German and English versions.

I used to describe this in the prompt every time. "Don't forget to run the linter afterwards" - every single time.

Now I put these workflows into skill files. A Markdown file that describes step by step what to do in a given context. I mention it briefly in the prompt: "Use the publish-blog-post skill."

That sounds like a small thing. In practice, it's what makes the difference between an AI I have to correct and an AI that simply does the right thing.

Define Data Models Before Writing Code

This is a lesson I learned the hard way.

I had given an AI the task of implementing a new feature with several database tables. The result was technically working - but the data model was wrong. Not wrong in the sense of "syntax error", but wrong in the sense of "this will be a problem in three months". Missing constraints, an N:M relation that should have been 1:N, and a field that semantically belonged in a different table.

Since then I do it differently: before I let the AI loose on database work, I write a short model spec. In prose, no special syntax:

Table: orders
- id: UUID, Primary Key
- user_id: FK → users.id, NOT NULL
- status: ENUM (pending, processing, shipped, cancelled), NOT NULL
- total_cents: INTEGER, NOT NULL (no DECIMAL - we calculate in cents)
- created_at: TIMESTAMP WITH TIME ZONE, NOT NULL, DEFAULT now()

Relations:
- One order has many OrderItems (1:N)
- One order belongs to exactly one user

That takes 15 minutes. It saves an hour of refactoring.

Context Engineering Instead of Prompt Engineering

I notice the term "prompt engineering" showing up everywhere right now. Workshops, courses, LinkedIn posts about the perfect phrasing.

I think that's the wrong focus.

The prompt is the last step. The system around it - CLAUDE.md, PRODUCT_SPEC.md, coding rules, skills, data models - is what actually determines quality. The AI is only as good as the context it receives. And that context can be built systematically, versioned and improved over time.

A good prompt in a poorly prepared project delivers mediocre results.
A mediocre prompt in a well-prepared project delivers good results.

I call it context engineering. Whoever understands this has a real advantage - not just with Claude, but with any AI tool.

TL;DR

What	Why
`CLAUDE.md`	Tech stack, project structure, design tokens, coding rules
`PRODUCT_SPEC.md`	What we build, why, and what we deliberately don't build
Skill files	Recurring workflows defined once, referenced forever
Data model specs	Written before code, not discovered through refactoring

The better the structure around the AI, the better the results. That's not theory - that's the experience from a year of daily use in real projects.

I'm Christopher, a freelance fullstack developer from Hamburg. I write about Vue/Nuxt, TypeScript and working with AI in real projects - at grossbyte.io.

My Agent Workflow – From Idea to Deployment in Minutes

Christopher Groß — Sun, 29 Mar 2026 23:21:50 +0000

A Bug, a Prompt, Done

The other day I noticed: blog posts weren't showing up in my sitemap. Annoying, especially for SEO.

In the past I'd have opened the sitemap module, read through the config, found the fix, tested, committed, deployed. Maybe 30 minutes, maybe an hour.

Instead I typed one sentence into my terminal:

"Blog posts are not included in the sitemap."

Five minutes later, the fix was live.

The Setup: Three Agents, Clear Roles

I use a multi-agent setup in Claude Code. Three agents, clear responsibilities:

Lead Agent – Plans, creates tickets, coordinates
Builder Agent – Implements the code
Tester Agent – Runs real browser tests with screenshots

The workflow is always the same: I give the lead agent a task – sometimes a sentence, sometimes a paragraph. It analyzes the problem, searches the codebase, creates a YouTrack ticket with a detailed description and proposed solution. I glance at it, say "go" – and the rest happens.

The lead delegates to the builder, which writes the code following my coding rules from CLAUDE.md. Then the tester spins up a real browser, loads the page, checks if the problem is solved. Only when everything is green does the lead come back to me: ready for review.

A More Impressive Example

The sitemap fix was trivial. But the workflow really shines on bigger tasks.

When I wanted full WCAG accessibility for my website, I essentially told the lead agent:

"The website needs WCAG-compliant accessibility."

What happened:

The lead analyzed the scope – every page, every component, every form
It created a ticket with a prioritized list of all necessary changes
The builder systematically worked through every component – ARIA labels, focus management, contrast, skip links, focus traps
The tester took screenshots after each iteration and verified accessibility

Result: WCAG 2.1 Level AA in under 2 hours. Estimated manual effort: 2–3 days.

Not because the AI is magic, but because the workflow eliminates context switching and parallelizes the repetitive parts.

What I Actually Love About It

No context loss. I describe the problem once – the context is preserved from ticket through implementation to testing.

Documentation happens automatically. Every change is documented as a YouTrack ticket with description, proposed solution, and screenshots. No writing tickets after the fact.

Small fixes actually get done. You know how you spot a typo or a small visual bug and think "I'll fix it later"? With this workflow, the barrier is so low I just do it immediately.

The Part Nobody Wants to Hear

This is not "AI does everything, I sit back."

In roughly every third or fourth task, I intervene. Sometimes the AI interprets a requirement differently. Sometimes the code is technically correct but stylistically off. Sometimes it's faster to change three lines myself than explain what I want.

That's fine. The workflow doesn't save 100% of my work – it saves 70–80%. The remaining 20–30% is where human judgment actually matters.

I review every single change. Every one. Not because I don't trust the AI, but because it's my code running in production. Read the diff, check the logic, manually test critical paths. That usually takes 2–5 minutes per change – and those minutes are non-negotiable.

Concrete Time Savings (Real Numbers)

Task	With agents	Manual estimate
Sitemap bug	5 minutes	30–60 minutes
Full WCAG accessibility	~2 hours	2–3 days
i18n text adjustments (DE + EN)	3 minutes	~20 minutes
New blog section	1 day	~1 week

The leverage is greatest for tasks that touch many files, follow clear rules, and are repetitive. It's smallest for creative work, complex business logic, and architecture – that's still on me.

What You Need to Get Started

Three things:

A good CLAUDE.md – Your project spec. Design system, coding rules, project structure. The better this file, the better the results.
Clear agent definitions – Each agent has a role, tools, and boundaries. This prevents chaos.
A place for tasks – Doesn't have to be a ticket system. Markdown files in your repo work fine. But personally, I prefer YouTrack – better history, easy referencing, agents comment directly in tickets.

The setup takes a few hours. The time savings afterward are multiples of that.

The Reality Behind the Hype

AI agents aren't autopilot. They're more like a very fast, very patient junior developer who never gets tired and follows your specs exactly – as long as you state them clearly.

The workflow works because I stay in control. I decide what gets built. I review what was built. I intervene when necessary. The agents accelerate execution – but the responsibility stays with me.

AI agents don't replace developers. They replace the parts of the work that keep developers from focusing on what actually matters.

Originally published on grossbyte.io

Curious how the agent setup looks in detail? Happy to write a follow-up on the CLAUDE.md structure and agent definitions if there's interest.

Accessibility in 2 hours – with AI instead of days of manual work

Christopher Groß — Mon, 23 Mar 2026 12:18:27 +0000

This article was originally published on grossbyte.io.

Accessibility was on my list for months. I knew what needed to be done. I kept putting it off anyway — because it always felt like days of tedious work.

Last week I just did it. With Claude Code CLI in under 2 hours.

What was built

Not just the basics – the result exceeds WCAG 2.1 Level AA in the areas covered, including support for system preferences that go beyond the standard:

Semantic HTML & ARIA on every interactive element
Skip-to-content link, visible focus styles, focus trap in the mobile menu
prefers-contrast: more/less, prefers-reduced-motion, prefers-reduced-transparency, forced-colors: active
Manual .a11y-mode toggle in the header
Fully accessible contact form with aria-live, aria-busy, aria-describedby
iOS zoom fix for inputs below 16px font size

What surprised me

The quality. I expected to do a lot of manual follow-up. Instead, Claude Code implemented the ARIA patterns correctly – disclosure widgets, live regions, focus traps. These aren't trivial patterns.

Also: prefers-contrast: less and prefers-reduced-transparency are CSS features I had never actively implemented before. Claude Code not only included them but chose sensible color values too.

The honest take

AI doesn't replace understanding accessibility. You need to know what aria-live does, why a focus trap is necessary, and whether the contrast values make sense. But the implementation – writing the labels, adjusting CSS variables, adding role attributes across dozens of files – that's exactly what AI does well.

When it takes 2 hours instead of 2 days, there are no more excuses.

Full writeup with all implementation details: grossbyte.io