DEV Community: Christopher Groß

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