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?”

AI is ready today, except for real-time video calls. So the odds are you just don’t know how to configure it properly.

Just because you installed Claude Code doesn’t mean you’re leveraging the full power of AI for software development.

Always be learning: specifically, keep asking other engineers to show you their CLAUDE.md.

What is “agentic engineering”?

It’s a combination of 2 things:

1. system prompt design = CLAUDE.md

2. agentic loop design

Is it just vibe coding?

No.

Vibe coding produces insecure throwaway code for your weekend projects. It’s ideal for prototyping. It replaced Figma as a tool to visualize ideas.

Agentic engineering produces secure, production-ready code that is of the same quality as code written by humans, or better.

Part 1: System prompt design = CLAUDE.md

The real software engineering today happens in your CLAUDE.md.

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.

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.

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.

How to write your CLAUDE.md

Your CLAUDE.md must include 3 things:

1. Description: 1-sentence description of the codebase.

2. Rules: Behaviors the agent should and shouldn’t do

3. Routing table: References to where to find additional knowledge

1. 1-sentence codebase description

Assume common sense and keep it concise.

“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.

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).

Below are a few fundamental rules I find incredibly helpful.

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.

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.

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 implicit documentation for what the behavior should be.

Rule #2: 1-sentence class and method description

“Write a 1-sentence description on top of all classes and methods: Write a succinct but thorough summary of what a class or a method does right above its definition.”

In agentic coding, repetition is better than abstraction. The in-code documentation is helpful for humans interacting with the code, but, more importantly, it serves as an additional layer of context to ground the agent's execution.

Rule #3: Document non-trivial hacks

“Document all non-trivial hacks or monkey-patches directly in code if scattered among multiple files. Always reference the other related files.”

How does the agent know that a particular line of code is meant to be used with a different line of code in a different file? Excluding conventions, such as an MVC pattern, its only chance is to `grep` the code. But if grep doesn’t find it, it doesn’t exist. Mainly when using dynamic languages.

Hence if you don’t document directly in code in both files that these 2 lines serve the same purpose, that information will be forever lost. (It will be only implicitly stored in git commit history: the agent could theoretically find that the two lines were introduced in the same commit, but that’s way too much work so this fact will be missed unless the agent is specifically debugging an error and thinking with ultracode effort.)

Rule #4: Documentation

“Write end-user documentation to docs/user_documentation.md. Write a public API documentation into docs/api_documentation.rb, make it production-ready so that it can be directly shared with customers; don’t include internal information there. Write a high-level internal documentation about the implementation into docs/internal_documentation.md. Never write any local memories. You must include the memories in one of these documentation markdown files instead. If needed, create additional files in the docs/#{topic}.md directory and add them to git.”

Repetition over abstraction. More documentation means more grounding for future sessions. Every new session is smarter than the previous one.

Rule #5: Conventions

“Naming conventions: Always say “Sign in”, never “Log in”. Always say “team members”, never say “colleagues” or “users”. Always say “Remove”, never say “Delete”. Always say “We’ll”, never “we will”. Always say “e-mail”, never “email”. [others]
UI conventions: The first <input> field on the page must always be focused when the page is loaded. All links going to hosts other than betterstack.com must always include target=‘_blank’ rel=‘noopener’ […]”.

Great products feel as if they were implemented by a single person. Consistency’s critical. You get a consistent product for free with agentic engineering, thanks to your Claude.md.

Rule #6: Examples of what great looks like

“When implementing a form, make the page look like monitors#index. (another existing page in the product). When implementing a landing page, make the page similar to betterstack.com/tracing. […]”

If you don’t tell the agent where to get inspiration, it will pick a random part of your product and draw inspiration from there. You should tell it to target the highest-quality parts of your product for imitation. Otherwise, it will imitate the average code in your codebase — which is a common frustration for teams blindly using Claude Code.

Rule #7: End-to-end feature testing

“After implementing a new feature, test it end-to-end with a browser by signing in as ‘juraj@betterstack.com’.”

Think of how you try the feature right after implementing it, and make the same possible for your agent. This is critical, and a common mistake with naive Claude Code set-ups: if the agent can’t try out the output of its work, it’s blind even to the most obvious implementation bugs.

Rule #8: Quality criteria

“Quality criteria: After implementing a feature, always ensure that every http request finishes end-to-end in 200 ms. Every page needs to be usable 250ms after load. Every page must be responsive and work in dark mode. Every page within /dashboard must be protected by authentication. Every feature must check for relevant RBAC flags. Regardless of what combination of links, forms or buttons the user clicks, even if illogical, the app must never return user-facing error 500: It should return a user-friendly error message instead and tell the user what to do differently.”

You get what you ask for. If you don’t explicitly say the app needs to be fast, its implementation will be allowed to bloat.

Rule #9: MCP access to production telemetry

“When debugging bugs, use the Better Stack MCP to access production error tracking, logs, and traces from source <url>. If prototyping a new feature, use the Better Stack MCP to access real-user monitoring data such as page views, and web vitals such as LCP.”

Telemetry tools often provide all the necessary context to 1-shot a bugfix. Generally be reluctant to add many MCPs as they waste your context, but do implement one from your observability provider. If they don’t have a robust MCP, change your provider.

Rule #10: Safety classifiers

“Never run a command on production servers without explicitly asking for permission first.”

Fable-like models can go out of their way to get the job done, even if it means `ssh`-ing to a server. This is fine, as long as you’re in control. The `auto` mode in Claude got really good these days, but in case someone in your team runs Codex, it doesn’t hurt to mention this explicitly in your Claude.md.

Rule #11: For HTML prototypes specifically

“Every .html page must be self-contained. Use Tailwind, don’t use any JavaScript framework.”

Allows you to have concurrent sessions 10+ on top of a handful of HTML files.

Other notable tricks for HTML prototyping:

• Paste a PNG screenshot of an existing interface into Claude Code.

• Use the Claude extension for Chrome and sign into your existing products. Then tell Claude: “Use design similar to page <url> opened in Chrome”

• Agentic loop prompt for implementing designs: “Improve this HTML until the pixel drift from Figma is less than 1% of pixels.”

Bonus Claude tricks

Install & enable Claude extension for Chrome

Then sign in to that browser in your testing environment.

For OpenCode, Codex users: `ln -s CLAUDE.md AGENTS.md`

Someone on your team will inadvertently experiment with Codex or OpenCode. By default, harnesses other than Claude Code might ignore CLAUDE.md, so symlink it to AGENTS.md to prevent this.

Use Git for every project

Obvious but necessary to mention. The entire commit history over time provides additional context when debugging bugs, alongside useful tools such as Git bisect.

Directory-specific CLAUDE.mds in sub-directories

Large code base? Include a handful of directory-specific CLAUDE.md in sub-directories to explain the structure and conventions of a smaller pack. Combine with an approach similar to Packwerk from Shopify for the best results.

Advanced: Access to censored & read-only production data

It’s key context to debug production issues alongside production telemetry.

Needs additional engineering, depending on your tech stack. At Better Stack, we developed an equivalent to the `rails runner` command that automatically censors all passwords, tokens and sensitive PII.

Consider REST APIs over MCPs

MCPs can be great, and they can be terrible.

As an example, Linear’s GraphQL API is vastly superior to its MCP. Just tell Claude “Use Linear GraphQL API with this token <token> to…” and optionally link to its API documentation, and Claude will be able to use it without issues.

Sensitive testing data? Add CLAUDE.local.md to your .gitignore

Then include your personal tokens that will not be shared with your team. Querying credentials? Ask Claude to use 1Password command-line op utility.

3. CLAUDE.md Routing table

Add a markdown table or <ul> list into your CLAUDE.md with two columns:

• “When looking for”

• “Look into”

Tell Claude where to find adjacent information for

• key parts of the current code base

• related code bases, e.g. backend for this frontend

• relevant external documentation

• production telemetry

General rules for writing your CLAUDE.md

Be succinct. Be explicit.

Use “good” and “bad” examples.

Your CLAUDE.md should get better over time

Never give your agents one-off feedback on its work.

If it did something wrong, tell it to:

“Remember in CLAUDE.md to always/never do X when Y.”

The real software engineering today happens in your CLAUDE.md.

If your CLAUDE.md is strong, your prompts will be short, simple, and straight to the point.

Part 2: Agentic loop design

What is an agentic loop?

It’s Claude Code working for hours unattended, checking its own work. Design your loops right and get a 100x productivity boost. Neglect them, and you’re back to ad-hoc real-time prompting.

How do you design an agentic loop?

You must tell the agent in CLAUDE.md or in your prompt the objective conditions for the output you want. Being vague is the ultimate sin. If you can’t describe what ‘great’ looks like, coding agents can’t build it.

A part of our CLAUDE.md we wrote above already includes aspects of an agentic loop design: the ‘quality criteria’ includes the requirements for page speed, following UI & naming conventions, and the unit tests written by the test-driven development all aid Claude Code to validate the quality of the output without additional input from you.

Example of an agentic loop:
End-to-end development of a new backend feature

Prompt #1 design document

“Write a design document to implement a managed load balancer into docs/design/load_balancer.md. Base it on HAProxy. The load balancer must be able to apply a new configuration with 0 downtime. Consider the attached screenshots of a competitor. Consider the public docs of competitors X,Y,Z. Interview me about key product choices.”

This is not a standalone prompt to run directly in Claude.ai. You should only run this directly in Claude Code, from the product codebase, after the CLAUDE.md from Part 1 has already been implemented. This will allow Claude Code to consider your existing code and tailor the product definition to your existing product.

Once finished, read through the markdown design file word-by-word and make 2-3 rounds of feedback. Don’t edit the markdown file directly; simply tell Claude, “Skip UDP load balancing, scope the feature with Packwerk,” and reread the adjusted design doc word by word until you’re happy with it.

Estimated Fable time: 30-60 minutes.
Estimated human review: 30-60 minutes.

Prompt #2: implementation

Fable in a new Git worktree:

“Implement docs/design/load_balancer.md”

Estimated Fable time: 1 hour

Review the created files, skim method signatures, don’t read the code line by line.

If there’s any structural mistake, improve your CLAUDE.md “Remember in CLAUDE.md to never add the most recent NPM package versions. Always fix the version explicitly to a package version that has been released already for at least a week to prevent supply chain attacks.”

If anything specific to this feature looks off, tell Claude: “Simplify the TCP healthcheck by….”

Deploy to staging.

Prompt #3: generate integration tests

“What are all the properties and features we need to test on staging to make sure 100% of the feature works? Combine them into as few integration tests as possible and write complete prompts I can use in different sessions. Write 1 naive integration test to be ran before all others to make sure the feature works at at all. Automatically debug issues using staging error tracking, logs and traces using the Better Stack MCP [or alternative] and open a pull request and ask me to re-deploy to staging before continuing testing.”

Estimated Fable time: 15 minutes

Prompt #4: naive integration test

Use Opus to run the naive integration test from the prior step to test the very basic functionality.

Estimated Opus time, no need for Fable: < 30 mins, expect 2-3 pull requests to get the feature to work at all.

Parallel prompts 5-15: copy & paste the integration test prompts from Prompt #3 and run them in parallel

Skim pull requests when opened, re-deploy to staging, ask the session “redeployed, continue”.

Estimated Opus time, no need for Fable: 2 hours.

Semi-attended. Expect 10-20 pull requests and staging re-deploys during this time. Could be unattended if you’re willing to let Claude Code redeploy to staging automatically.

When all integration tests pass, you have something that:

• “looks like a duck”: the design markdown looks great, so does the file/class structure and method signatures

• “quacks like a duck”: the integration tests on staging work

A close to complete product in ~5-6 hours. Including customer-facing API documentation, product documentation, and internal technical documentation.

Appendix

Garry Tan’s talk on a related note

Keep iterating: delete your CLAUDE.md every 6 months

This is a request for comment

This is how we use agents at Better Stack. It’s one way of the highway, but definitely not the only way. Doing something different and it works great? Tell me at juraj@betterstack.com.

Interested in agentic engineering?

Subscribe to Better Stack on YouTube or join the team!

AI erased most product-level moats. So defensibility now comes from things that are intentionally hard to replicate.

• brand & distribution

• being a “compound startup”

• vertical integration

• migration pain

Brand & distribution

The obvious one. Having an existing distribution is a game changer. Think Microsoft pushing terrible MS Teams to their existing user base to beat Slack’s usage numbers.

Building a trusted brand perceived to be building quality products is priceless today. Your brand’s reputation takes years to build yet it’s trivial to lose.

Being a “compound startup”

Launching multiple tightly integrated products solving different problems for the same customer. Single product startups might be easier to build and faster to grow initially, but they’re a lot more vulnerable to competitors too.

“Compound startups” leverage that billing, reporting, authentication, onboarding, support, data models are all shared across multiple products, and you only need to build them once.

Being “a compound startup” means you can use product bundling to your advantage: you can compete on margins where it hurts your competitor but it doesn’t hurt you. Every company now pays for 30+ SaaS vendors. The bar for being the 31st is higher than ever, but selling one more product to existing customers? Easy!

But man building a compound startup is complicated! Different products mean different customers constantly pull you in different directions. If you found building a single product difficult, multi-product is a different level.

Vertical integration

How many new startups are building their own data centers today? Close to zero.
How many are hosting data in Supabase? Most.

There are things you can do with data in your own data center that you can’t do with Supabase. You can tailor your hardware to your software, not the other way around. You could optimize costs and capex/opex.

It’s an insane pain to host your own servers though. But that’s the point.
If it brings you a real benefit, it might be worth it even if super painful.

Migration pain

Can you make your product easy to onboard while being difficult to rip out?

I don’t care if a vendor sells me on a slightly better or a cheaper product if I need to change workflows of an existing team or migrate a ton of data. Switching costs are not just technical; they are social, operational, and political.

The point is there’s “no quick wins” anymore

If you launch an obvious & easy to build idea today, you’ll wake up to 17 competitors on Product Hunt tomorrow. AI removed most “easy” moats. The only durable ones left are the hard ones.

Aiming to build a lasting business? It might be easier to work on a hard problem than an easy one today.

Assumptions:

• typical European 4 weeks paid time off

• 10 public holidays excluding weekends

• and 5 sick days per year

A typical employee in a corporate job putting in 6 work hours per day in a ‘chill mode’ clocks about 1,356 hours per year.

What about others?

With vacations being ‘an email with a view', working on the weekends, public holidays, and Christmas Eve, founders put in 3-4x more work hours per year than the average corporate employee.

Essentially doing the work of at least 4 corporate employees.

“Ok Juraj, but I work smart, I don’t need to work hard”

Imagine a competitor of yours somewhere in the world who’s exactly like you.
But they operate in ‘Founder mode’ while you’re working on your business in ‘Chill mode’.
They’ll run twice as many experiments per year as you will! How will you win?

“That just makes you a workaholic”

Sort of. Think of startups as a high-performance sport. Would you tell an Olympian chasing a gold medal “chill out you’re training too much!”. Most people wouldn’t.

“Ok, but input ≠ output. You can’t be productive if you work for 12-16 hours a day” [*]

It’s the output of your effort that counts.

The more hours you put in, the faster you learn. The faster you see what works and what doesn’t. The faster you master a skill.

The effort compounds. Since you’re a lot more experienced because of working more, you’re able to get *more* done in a single hour of work over time, not less.

It’s a marathon, but you sprint the entire time

YC preaches ‘eat, sleep, build product and talk to your users’. This is fun for 3 months, but imagine keeping this up for 10 years straight. You have to love the game, otherwise any sensible person would quit.

It’s actually good news: this is how you start

Do you want to start a business, but you don’t have savings?

This is how you get your break: “Work 9-5, spend a couple hours with the family, and 7pm to 2am in the morning is plenty of time to do the damage. […] Everybody has time. Stop watching fucking Lost.”

Just be self-aware and understand what it takes.

[*] the Better Stack team works regular hours

…“Feels like opening iterative pull requests, waiting 10 mins for CI, and deploying a +10/-7 PR is already outdated”

So are programmers already out of a job? Are the best practices for shipping software such as continuous integration and pull request reviews already irrelevant?

Here’s my 2 cents as of March 2025.

Day-to-day impact of LLMs on software engineering

In the last 2 years alone, software engineering changed more drastically than in the prior 20 years.

Starting with the obvious, Claude Sonnet 3.7 is insanely good for 1. debugging errors, and 2. prototyping initial concepts. Stack Overflow & internet forums are dead. Your marketer is no longer hiring $5 fiverr gigs, they create the scripts they need themselves with Claude.

Devin is a great concept, but the error rate is still too high for most tasks. This is where we’re going though — you simply tag your virtual colleague in Slack and wait for them to open a pull request.

Cursor’s CMD+K with Claude Sonnet is the single most important practical change in day-to-day engineering workflows since GPT-3.

If you’re a full-stack engineer and you haven’t incorporated CMD+K into your workflow you will soon become irrelevant. (It’s fascinating that existing IDEs like JetBrains are struggling to keep up!)

Starting a new project? Cursor’s composer mode is useful, too. Although it becomes impractical as you cross 5-10k lines of code and the dependencies become too complex.

Where we’re going

SWE Agents by GitHub will likely shake things up next thanks to their tight integration with GitHub pull requests & having the entire codebase.

New models come with very large context windows. Gemini Flash 2.0’s 1 million context window means that entire small codebases can be now completely included in a single prompt, leading to higher quality answers & insights.

Needs of engineering teams are different to cool demos

Most ‘AI coding’ demos focus on 1. single page visual demos, and are 2. built from scratch by the model. And 3. models make many mistakes, so you need multiple attempts of tweaking your prompt before it does what you need.

Software engineering teams deal, on the other hand, with:

1. numerous internal microservices and many repositories

2. millions of lines of existing code

3. they optimize for not breaking things when adding new features

This is why the Devin experience of simply asking an agent to implement a feature in a complex existing codebase is still just a dream today. And why CMD+K in Cursor remains the key game-changer for existing software engineering teams.

There’s one other notable use-case for engineering teams: chatting with code. Imagine you need to integrate with a poorly documented Go library although you never worked with Go. You can ask Cursor Chat to explain the parts of the code base relevant to you: e.g. ask about what’s the structure of the API payload the service expects. This works exceptionally well.

I think there are many existing workflows still waiting to be disrupted by LLMs: automations for triaging bugs and feature requests, code review assistants, UI copywriting assistants, UI convention checkers, QA testing, and workflows for resolving infrastructure incidents faster, to name a few. We’re working on some of these at Better Stack, so if this sounds like an interesting challenge, join us!

So what makes human engineers relevant today?
Experience + Low error rate.

We still need full-stack engineers with 1. a lot of experience, and 2. low error rate.

Experience is both the soft intuition built from years of building and fixing complex systems as well as hard knowledge of the existing systems.

By “error rate” I mean the guard rails an engineer needs around them to be able to ship production-ready features.

Does your company have an army of manual QA testers? Is every pull request introducing a new feature followed by several hotfixes? Both signify an environment with a high tolerance for errors. Devin is coming for your job soon.

“Full-stack engineer” is the main software engineering role still relevant today. If you perceive yourself as just a “Ruby engineer” or just a “JavaScript engineer” then play with Claude, Cursor & Devin and reconsider.

Thanks for reading! Follow me on Twitter & subscribe below for future posts.

In the short-term, they don’t. The rest of the team subsidizes a new colleague when they’re getting up to speed during onboarding.

So when does “short-term” end and “long-term” begin?

That depends on the introductory compensation.

The introductory compensation is the responsibility of the person joining the company. An experienced engineer with 2 mortgages, 3 kids and a dog has different expectations to a fresh grad.

But the higher the introductory compensation, the higher the expectations. And thus the shorter “time to enough value created”.

We could pay you a million a month, but I’d need you to have a tangible impact on the business on your first day.

The long-term compensation, on the flip-side, is the responsibility of the company. And it’s in the company’s best interest to aggressively increase comp when appropriate.

Imagine you have a colleague who’s simply killing it: the last thing you want is for them to start thinking about leaving because of a different company offering them more $.

At Better Stack, we revisit the compensation of every team member twice a year. That doesn’t mean we automatically increase everyone’s comp every 6 months. It means the company opens up the conversation about your comp with regards to your performance, the company’s overall performance, and the outside market, so that you don’t have to.

It’s in our best interests to aggressively increase compensation when appropriate. In the past, we increased the comp of our colleagues by 50%+ in three consecutive bi-annual reviews — effectively increasing the comp by more than 3.4x within 18 months. But at the same time, for different colleagues, we left the comp unchanged over the same 2-3 consecutive reviews. Because the comp should be proportional to the real value people create.

Large bigtech corporations typically have no clue about who is actually creating a ton of value and who is not. But a nimble startup with technical leadership can recognize it & reward it.

Imagine you’re tasked with deriving an equation for the very first time.

You’re *really* focused on getting it done. You spend hours and hours thinking about how to solve the problem.

Yet, you eventually give up.

Who is your go-to person you ask for help?

Would you prefer to ask 100 first graders to help you or 1 university math student?

I’d go with the university student every single time.

Yet, tech journalists, VCs, job applicants, and even tech recruiters ask me regularly: “How many engineers do you plan on hiring this year?”

This question is fundamentally flawed.

Software engineering is remarkably similar to math in the sense that a really great mathematician can solve a thousand times more difficult math problem than an army of first graders.

9 women won’t give birth to a child in a month.

100 Cessna pilots won’t fly a fighter jet.

So let’s stop thinking of software engineers as a commodity. The best software builders are at least 100x more productive than the mediocre ones.

You might not need a team of 50 engineers after all, you might just need a single really awesome engineer.

So how many engineers are we looking to hire at Better Stack?

Every single great one we can.

Things look, work, and mostly *feel* the same.

This is trivial at first when you’re the only developer but almost impossible later as your engineering, design, and product teams scale and new colleagues join.

The following are my 8 recommendations on improving the design of your next product without adjusting the color of a single pixel.

1. Do not introduce new concepts recklessly

“Sign in here” yet “Can’t log in?”.
“Register here” yet “Sign up with Google”.
Different words, same thing.

Do not ever use synonyms for the core product concepts of your app.

Instead, be uncompromisingly boring: either use “Sign in” and “Sign up”; or “Log in” and “Register” but never the other.

Boring is great.

Otherwise, your users will be left wondering: Is “user” the same thing as “customer” and “profile”? What about “team member”, “colleague”, and “teammate”?

2. Period at the end of tooltips, flash messages, and error messages

It’s often the small things that add up: Do tooltips end with a period or not? If some do and some don’t, just pick one and unify them.

3. Date formats

Have a set of defined date formats you use throughout the app.

4. Consistent page layout

All pages ought to belong to one of a few categories:

• landing page

• listing page

• dashboard page

• authentication page

• form page

If none feels right, think twice if you really need to introduce a new behavior to your interface. All pages of the same type should feel and work the same.

5. Short or long-form English? Informal or formal?

Pick a voice and stick with it. I prefer a conversational professional tone:
an informal, friendly, and honest active voice.

✅ “You’ve successfully updated your profile.”
❌ “Profile was successfully updated.”

6. Copywriting 101

7. Grammar mistakes

Your interface needs to sound native to your customers in the U.S.

Not a native speaker? Rewatch Suits on Netflix. Use Grammarly or leverage “Make the following sound native” Chat-GPT prompts.

8. Write it down

Codify your UI conventions by writing them down and make all new engineers, designers, and product managers read all of them before they start contributing.

Focus on engineers. They’re the ones who typically make or break consistency.

No designers or product managers can design every possible error message of every form, so your engineers will have to improvise whether you make them focus on consistency or not.

Recommended resources

• Don’t make me think.

• Refactoring UI.

• Kevin Hale on How to Build Products Users Love.

…or work with us on the next product at Better Stack.

2. Praise publicly, and criticize privately. Schedule a private 1:1 session. Never criticize someone’s work publicly in front of other colleagues.

3. Check on them first. Is everything fine with them at home? It’s your job to know if they need your support outside of work. Remember, work is just work.

4. Have explicit examples. Be ready to discuss specifics. "Remember last Thursday when you did X? I'd really have preferred you to have done Y in that situation because of Z." Have screenshots ready, links to pull requests or Slack conversations you can reference. Nothing is worse than ambiguity when you're criticizing someone’s work.

5. Cover everything in a single session. Once you're giving someone feedback, don’t be half-hearted. Otherwise, they’ll tell you “You didn’t mention that last time” the next time you talk.

6. Is this a repeated mistake? Acknowledge that. "Remember when we were discussing X last week? We agreed that…”

7. Be firm but kind. Never make it personal. Talk about “the work” they've done, not about the person themselves. Do not ever let your emotions get the better of you.

8. Don’t leave anything unsaid or vague. If you’re not explicit enough, you can’t expect them to understand something you barely implied. Over-communicate rather than under-communicate.

9. Reason from first principles. They might be operating on a different set of beliefs than you, for example, saying “That wasn’t my job”. Be ready to dig deep and get down to first principles if you need to: "Look, how would the business function if everyone was doing this?”

10. The discussion takes as long as it takes. The meeting is scheduled for 30 minutes? Great. Make sure both of you have free time in the calendars afterward. Take your time when speaking, use silence to your advantage. It’s completely fine to breathe in and think for 5-10 seconds about what you want to say before you continue talking. If you discuss the issue in-depth enough, they should be able to acknowledge the problem in the end. If they’re not, delve into it with, “It feels like you’re getting a bit defensive. Do you think what I’m saying is not fair?”

11. Be specific about what you want to happen next. Is this the last warning before you need to let them go? Tell them that.

12. Be ready for extreme reactions. Prepare for every possible outcome of the conversation, regardless of how unlikely. They could laugh, cry, shout at you, or quit on the spot. What would you do if they did that?

Don't worry, you’ll do fine. Radical candor is an integral part of a well-functioning team.

Don’t be this guy:

One such distinction is knowing when to flip the switch between the two engineering approaches.

Here's the scoop: Traditional paths like universities, internships, and work experiences at mega-tech companies usually only teach engineers the ways of "polished and perfect engineering".

1. Don't mess things up!

2. You have to be a team player. Stick to a common code style, whip up unit tests, and give your code some good documentation.

3. Your code should be a breeze to maintain and enhance.

4. Long-winded commits and pull request messages? Bring 'em on.

But if programming is your hobby, chances are, you love playing around with the latest tech. You might find yourself churning out 50-100 line scripts just to test that shiny new API. Or maybe to scrape a list of rentals to snag the perfect apartment... or score the best car deal.

These are throwaway scripts that probably won't see the light of day again.

That's why many self-taught coding enthusiasts often resort to a patchwork approach to make things work... and fast.

There's a common misbelief that the "polished and perfect" style of engineering is always superior. But it's not. Tests for code that's gonna gather dust in some corner are just a waste of your time. Staging environments for pre-release software? That’s ridiculous.

If you're an engineer at an early-stage startup, being able to prototype is a golden skill.

What really sinks startups isn't ugly code. It's the failure to create something people are willing to pay for. That's why being able to prototype quickly, especially in the early stages, is super important.

The crème de la crème of engineers can do both: whip up quick and dirty prototypes, validate their concepts at breakneck speed, and then spin those ideas into top-notch production code.

Engineers often overlook how adding a feature impacts all future changes from that point on. Here's the truth:

Not all features are created equal. Some can literally tank your future productivity.

"All of our competitors have dark mode, let's add it!"

"Let's translate our dashboard into other languages to break into European markets. How hard can it be?"

"Should we launch the responsive web app as a hybrid iOS app as well?"

"Don't forget about Android!"

"Could we convert parts of the web app into an Electron desktop app?"

These suggestions sound harmless until you realize that every single feature added from that point on needs to accommodate all versions of your app.

Light & dark, web & iOS & Android & Electron, English & German... that's 16 versions of the same page right there.

Since it's not practical to check all page versions when adding a new feature, you'll end up with a user experience prone to errors and inconsistency, as well as a significant slowdown in development speed.

So the next time you're about to implement a feature, pause and ask yourself: could this be a work multiplier? Is it really worth it?

P.S. We’re hiring at Better Stack.

Picture that: creating more value in a single day than a big-co engineer creates in 3 months.

The examples are everywhere

Google's initial team had just three people. Apple's crew was only 25-strong when they introduced the Apple II. At the point of its acquisition by Facebook, WhatsApp was serving 600 million users with a team of roughly 50 engineers. Instagram's tale is quite similar, boasting 30 million users with a mere 13 engineers at its $1 billion acquisition. And Basecamp? It began as a humble side project.

Similarly, at Better Stack we had only 3 software engineers writing code back in the day when we crossed $2 million in ARR, coupled with double-digit monthly growth. That's an impressive "revenue per engineer" ratio, if you ask me.

It’s the art of doing less

Imagine a "1x engineer" as a fresh university grad who, given enough time, could build any software from scratch.

Then the "10x engineer" is a seasoned pro with a refined intuition that helps them identify the part of code that should be implemented using an existing open-source library instead of building it from scratch. This doesn't mean they write superior code or type faster. Rather, they understand the immense time-saving potential of plugging in an existing open-source work rather than re-inventing the wheel. The key here, of course, is choosing the right library.

Who’s the mythical “100x engineer” then?

A "100x engineer" has a comprehensive understanding of the product roadmap, business model, competition, and common customer issues as well as a detailed knowledge of the work needed to implement a feature. As a result, they can judge the cost/benefit ratio of a feature better than the product manager. 100x engineers push back on feature definitions. They’re able to cut the right 5% of the feature to simplify its implementation by 100x.

100x engineers aren’t necessarily better at writing code. They better understand the context of everything absent in the task description.

They’re able to take a second to judge the cost/benefit ratio of a feature before they jump into implementation. They can often do so better than the product manager or the CEO.

In the end, it's about everything an engineer doesn't have to do.

Yet, pragmatism and thinking from first principles can be surprisingly rare among engineers. We've all been guilty of over-engineering, premature scaling, recreating existing libraries, and blindly following industry "best practices".

But when you manage to find a few of these 100x engineers, you're in for some real magic.