Forem: Christopher Groß

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