The no-bullshit guide to Agentic Engineering

Early-stage startup engineering

SubscribeSign in

The no-bullshit guide to Agentic Engineering<br>Practical guide to shipping production-ready software in hours instead of months.

Juraj Masar<br>Jul 29, 2026

Share

Originally written for the engineering team at Better Stack.

A practical mental model

If you ever find yourself saying: “AI is not good enough yet to do [action]”, please automatically assume you’re wrong. It’s just practical to do so. It forces you to think “*how*  do I make AI do this?”<br>AI is ready today, except for real-time video calls. So the odds are you just don’t know how to configure it properly.<br>Just because you installed Claude Code doesn’t mean you’re leveraging the full power of AI for software development.<br>Always be learning : specifically, keep asking other engineers to show you their CLAUDE.md.<br>What is “agentic engineering”?

It’s a combination of 2 things:<br>system prompt design = CLAUDE.md

agentic loop design

Is it just vibe coding?

No.<br>Vibe coding produces insecure throwaway code for your weekend projects. It’s ideal for prototyping. It replaced Figma as a tool to visualize ideas.<br>Agentic engineering  produces secure, production-ready code that is of the same quality as code written by humans, or better.<br>Part 1: System prompt design = CLAUDE.md

The real software engineering today happens in your CLAUDE.md.<br>CLAUDE.md is the highest return-on-investment file in your entire codebase . If this is the first CLAUDE.md you’re writing, spend hours designing it: sentence by sentence.<br>Never have a personal, locally stored CLAUDE.md. Always share your CLAUDE.md with your entire team directly in Git in the codebase. CLAUDE.md is the new meta programming.<br>Dear engineering managers : for the first time in the history of software engineering, you can now directly influence what kind of code your human colleagues contribute! Historically, your only option would be to write a GitHub pull request review comment “Bob, please prefer to do X over Y next time”. Today, you just re-configure everyone’s CLAUDE.md instead. Your team will continue using Claude Code the same way and magically produce better code!

Signs that your CLAUDE.md is incorrectly designed

Claude will say “Exploring your code base to understand X…”

Your CLAUDE.md doesn’t have a ‘routing table’ section that would reference other markdown files for documentation, describe codebase components, and link to adjacent codebases.

Claude will say “Writing a memory about X…”

You haven’t configured Claude to write shared documentation in your codebase. This is problematic because your colleagues won’t be able to leverage the same agent memories when their agents run, so they’ll be running into the same mistakes you already did.<br>How to write your CLAUDE.md

Your CLAUDE.md must include 3 things:<br>Description : 1-sentence description of the codebase.

Rules: Behaviors the agent should and shouldn’t do

Routing table: References to where to find additional knowledge

Common mistake: Do not include specific knowledge in your CLAUDE.md. CLAUDE.md is for behavioral rules = meta programming in English; it’s not a place for product documentation.

Why? CLAUDE.md is your system prompt: it gets included at the start of every session of every sub-agent, always. Unless a particular fact is required for every single session, it doesn’t belong to CLAUDE.md. Irrelevant words in your CLAUDE.md can easily make your agents worse.

1. 1-sentence codebase description

Assume common sense and keep it concise.<br>“This is a Ruby on Rails + PostgreSQL + Redis backend for an iOS application that .”

Don’t waste your tokens on general knowledge: No need to explain the Model-View-Controller pattern. Claude knows what a typical Rails codebase looks like.<br>2. Agent rules = meta-programming in English

Now the fun part. Personally, I find a properly designed CLAUDE.md to be way more impactful than an underlying model upgrade (e.g., Opus → Fable).<br>Below are a few fundamental rules I find incredibly helpful.<br>Do you use other tricks I haven’t mentioned here?<br>Please tweet at me at x.com/jurajmasar.

Rule #1: test-driven development

“Always use TDD: test-driven development”.

Thanks to TDD, your agents will keep getting better on their own as the codebase grows, feature by feature. The more tests, the more implicit rules for what the end result should look like.<br>Your agents are really good at writing very fast unit tests. They’re also amazing at selecting just the right subset of tests to run to validate a particular code change. You will thus see your agent launching tests on their own when implementing a new feature, detecting a failure and improving the code on their own, without any impact from you. That’s your first taste of an agentic loop! More on that later.<br>Even if a test is not executed, its definition alone describes how the software should work. When the agent loads the test file into the LLM context, it becomes...