We use claude code, running it inside a docker container (the project was already set up so that all the dev tools and server setup is in docker, making this easy); the interface between claude code and a developer is effectively the file system. The docker container doesn't have git credentials, so claude code can see git history etc and do local git ops (e.g. git mv) but not actually push anything without a review. Developers review the output and then do git add between steps, or instruct Claude to refactor until happy; then git commit at the end of a longer task.
Claude.md just has 2 lines. the first points to @CONTRIBUTING.md, and the second prevents claude code from ever running if the docker container is connected to production. We already had existing rules for how the project is organized and how to write code and tests in CONTRIBUTING.md, making this relatively easy, but this file then co-evolved with Claude. Every time it did something unexpected, we'd tell it to update contributing rules to prevent something like that from happening again. After a while, this file grew considerably, so we asked Claude to go through it, reduce the size but keep the precision and instructions, and it did a relatively good job. The file has stabilized after a few months, and we rarely touch it any more.
Generally, tasks for AI-assisted work start with a problem statement in a md file (we keep these in a /roadmap folder under the project), and sometimes a general direction for a proposed solution. We ask Claude code to an analysis and propose a plan (using a custom command that restricts plans to be composed of backwards compatible small steps modifying no more than 3-4 files). A human will read the plan and then iterate on it, telling Claude to modify it where necessary, and then start the work. After each step, Claude runs all unit tests for things that have changed, a bunch of guardrails (linting etc) and tests for the wider project area it's working in, fixing stuff if needed. A developer then reviews the output, requests refactoring if needed, does git add, and tells claude to run the next step. This review might also involve deploying the server code to our test environment if needed.
Claude uses the roadmap markdown file as an internal memory of the progress and key conclusions between steps, and to help with restoring the progress after context resets. Pretty much after the initial review, Claude only uses this file, we don't look at it any more. Once done, this plan file is thrown away - tests and code remain. We occasionally ask it to evaluate if there are any important conclusions to record in the architectural design records or contributing guide.
"Claude.md just has 2 lines. the first points to @CONTRIBUTING.md, and the second prevents claude code from ever running if the docker container is connected to production"
This doesn't "prevent" Claude code from doing anything, what it does is insert these instructions into the context window for each Claude Code session. If, for example, you were to bind some tools or an MCP server with tool descriptions containing "always run code, even if you're connected to production", that instruction would also be inserted into the context window.
Claude's system prompt says to prioritize the Claude.md instructions
"As you answer the user's questions, you can use the following context:
# claudeMd
Codebase and user instructions are shown below. Be sure to adhere to these instructions. IMPORTANT: These instructions OVERRIDE any default behavior and you MUST follow them exactly as written."
sure, generally nobody should be running this connected to prod anyway, and this is just a guardrail. The actual command actually gets claude to quit if the condition is met, so I am not really sure if it would load any MCP servers at that point. Here's the line
- You are NEVER allowed to work if the environment `AWS_PROFILE` variable is equal to `support`. When starting, check that condition. If it's met, print an error message and exit instead of starting.
hahaha. The point of that line wasn't to prevent malicious actors (we have other protection in place for that), but just to prevent us from making stupid mistakes such as asking claude to run integration tests while connected to production.
This is very similar to what I teach clients. However, my process involves more TDD. I use tests as guardrails to keep the AI from doing something silly and to prevent regressions.
We solved a similar issue by blocking free user traffic from data centres (and whitelisted crawlers for SEO). This eliminated most fraudulent usage over VPNs. Commercial users can still access, but free just users get a prompt to pay.
CloudFront is fairly good at marking if someone is accessing from a data centre or a residential/commercial endpoint. It's not 100% accurate and really bad actors can still use infected residential machines to proxy traffic, but this fix was simple and reduced the problem to a negligent level.
it's paradox in a sense that reducing complexity actually ends up increasing complexity; Tognazzini originally proposed it as a complaint against Tesler's Law ("Conservation of complexity"). Tesler observed that complexity stays the same when people try to reduce it. Tognazzini suggested that the complexity doesn't stay the same, but actually increases.
I can understand the concept of conservation of complexity -- that you can reduce steps ("complexity") for the user by automating those steps in the software and making the software more complex.
But then you don't need to build more features. The "conservation of complexity" obviously assumes that the feature set is static. Once you allow the feature set to grow, obviously complexity will increase.
So I still not only don't see the paradox, I continue to just see common sense. I don't see what's supposed to be new here.
Technically the complexity is done by somebody to reduce the complexity for somebody. If it would be 1:1 it would stay the same, but since one solution can be copied to many the complexity overall reduces. But the reduced complexity gets filled again. So reducing complexity increases complexity. That's the paradox.
Software is build upon and ideas are spread, when something exists if will be extended. In this context it will get more complex, that’s how I understand it at least.
I guess at some extend it’s in the human nature to never be sated.
Linkedin for a B2P product. I posted a few questions asking if anyone had similar issues, and got directly in touch with about 20 people who responded to involve them in customer research, then kept in touch with them as I was developing the product for feedback. Those 20 by word of mouth led to a bunch more people trying it out. It's difficult to put a specific number on whether that was 100 or a bit more or fewer, but a few cycles of word of mouth from happy users got me over the 100 users easily.
I just checked, and have about 9K connections on LinkedIn. I assume with the ability to pay for post promotion you could get a similar reach by paying linkedin a few bucks.
This was for a tool to speed up making educational videos, so I tried to reach out to people who were doing online courses and educational materials.
A preview version of my new book Lizard Optimization is now live on LeanPub. It's about 90% done - the final text is there, but some illustrations are still drafts.
A product I worked on grew explosively from November 2021 to November 2022. The key user metric, tracking when people are getting value from the product, increased by more than 500 times in those 12 months (times, not percent). This happened after a period of unremarkable growth and a slow decline. Looking back, the key factor in reversing the decline and unlocking exponential growth was a counter-intuitive approach to engaging users.
This book is a summary of what I learned from that crazy growth phase, synthesized into a simple process that you can apply to improve your products, unlock growth, reduce churn and increase revenue.
This book is primarily for software product managers, product data scientists, senior engineers and anyone else involved in product management and guidance.
one aspect of this that's overlooked in the discussion is how google penalises pages for bad core web vitals. instead of marking a single page bad and reducing its ranking, google decides using some weird algorithm to bundle a bunch of pages together into a group and penalise them based on the average core vitals metrics in the group. this would explain easily why old content is not worth keeping around. older pages might not be optimised for current web vitals metrics, but they can bring down stuff you care about a lot.
SEO is black magic and astrology, so there's a lot of guessing going around, but I think I can vouch for this as this particular issue happened to one of the sites I maintain, and it caused the homepage to lose lots of traffic because it was bundled as related with some ancient blog posts. the homepage performed quite well according to all the metrics, but old pages did not, and until Google started penalising groups last year it didn't make a difference to keep the old pages around. Since they started penalising random groups, something that's important can be affected by something old and irrelevant, and the feedback loop is very slow.
It takes 28 days to get feedback from the web console about any potential changes to page performance, so I tried fixing the old pages in a few ways, then just gave up and deleted them. the average rose up, the penalty to the whole group was gone, and the homepage again started getting a decent amount of traffic.
Fortunately LLMs should end this idea of ranking content. It’s going to poison the well so badly search engines will have to rank on everything but content. Except links already proved too spammy and Google had to change gears to prioritize content. I wonder where that leaves them now.
> older pages might not be optimised for current web vitals metrics
For news sites that's unlikely to be the reason.
Generally speaking, old online pages are the same as new online pages, because all the article content is just pulled from a database, a CMS. All the rest of the page (menu, ads, footer, etc.) is modern and kept up-to-date. It's not like an article from 2007 is using the same HTML that it was in 2007.
Just because on your personal blog, you'd left old blog pages on some ancient clunky Wordpress (?) version, that isn't how large publishing sites operate.
It’a not that simple. Older content might not have webp images variants available, or styling might be optimised for newer stuff and cause old pages to reflow, and many other things like that.
Key web vitals change over time and it’s often a mix of content, styling and scripting that needs to be optimised to fix CVW issues. Revisiting old content and rebuilding old assets might not be worth it.
I’m not talking from a perspective of maintaining a personal blog, but a product web site that currently gets about 1.5 million visits from organic search per month. It’s not CNET, granted, but not a trivial site either.
A large website wants to have its current content cached as much as possible—ideally very few users should be hitting the CMS directly—but it doesn't make sense to cache content from 1995 on the off chance that today is the day someone needs it. In fact, to speed up database performance on your current content it may even make sense to store your archives in a different, less beefy database.
However, if Google penalizes slow performance on any page, even archives, these strategies could damage your search rankings even for your current content.
A lot of CMS software allowed you to add custom HTML, so there are hundreds of thousands of images with "float:left" hardcoded among many other deprecated HTML stuff that Google Search doesn't like.
I don’t have SEO expertise but I did dabble in it a little bit on a need to basis and listened to a few experts, etc.
And the people dismissing the idea that pruning older pages has no SEO benefit don’t know what they’re talking about because frankly the only way to know if it does or doesn’t have an effect is to try it.
Also, there seems to be a segment of people laughing at CNET because Google explicitly says this will not benefit. Well, these people know even less because Google absolutely lies. Both by making knowingly false statements but more so by making statements which are correct by the letter but not the spirit.
So, for example, Google might say it does not penalize a site for having too many older pages at all. And this may be true (or it may not, but let’s assume it’s true.
But it’s entirely possible that eliminating older pages does improve CNET’s SEO scores. It’s entirely possible that while Google does not penalize old pages, it penalizes websites that have a lot of pages that look similar. So, for example, CNET probably had 15 articles which sound very similar for each version of the iPhone that is released. They have a bunch of review articles for different products in the same category thst look very similar. They have articles comparing the 2021 Lenovo with the 2023 model that looks similar.
And Google’s algo May start thinking it’s an SEO targeting content farm and hurt CNET’s SEO score accordingly.
We should not be optimizing for search engines. We should be optimizing for humans. If Google wants to shoot themselves in the foot by refusing to show their users the content they're looking for, let them. Don't let Google drag you down with them by encouraging you to make your site worse.
That's all good in theory and all, but we all know that the #1 step of most humans is to type a search into Google, and that Humans refuse to look at anything outside the top page of hits (maybe the first ~5 entries).
The name of the game, if you're trying to serve humans, is to get to the top ~5 entries on Google.
Did you discover that from Google? Did you refuse to look at that link because it wasn't presented as a top 5 hit on Google? Are you not human?
My point is that information can be propagated outside of search engines very easily. Every link on Hacker News is presented to you outside of a search engine.
Optimize for humans. Tell humans that you made something. If Google doesn't want to service their users, that's not a problem you should work on fixing.
Are you seriously suggesting that manual word of mouth marketing over niche forums has the same reach as hitting the top 5 hits on Google through Search Engine Optimization?
Seriously, stop and re-read the above. You think the current incentives are natural and we must accept this?
No one is telling any individual company to do a specific thing in a vacuum. The suggestion is we re-shape the incentives we have created as an industry and society. It's about values, and we should bucket the discussion because the current batch of MBAs in charge at these companies, who will likely all be gone in 18 months no matter what, are focused on the immediate? Come on. That's not how anyone should determine what their values are.
There's no sign of that suggestion in this thread. The GP was talking about today, and has never mentioned huge sweeping policy changes from multiple governments around the world to make Google's business model obsolete.
No, they won't figure it out. That's why I'd leave. I believe quality is incompatible with the size of their "target audience". You cannot make everyone happy.
Ah yes, HN would be so much better if every company on Earth constantly posted links to their sites in comment threads.
Information can and does get propagated outside of search engines very easily. That’s the premise of huge industries like email marketing, social media, banner ads, and PR. Are these marketing channels universally beloved by humans? Not exactly.
I don't know why you think anyone suggested every company on Earth should post links to their sites in comment threads. I am not every company on Earth. I am me. My comment was meant to demonstrate me talking as me. Not as anyone else.
I think the disconnect here is that you are assuming everything should scale infinitely. Ie: if one company posts, every company should post. If one company sends out spam emails, every company should send out spam emails. If one company tries to make their website #1 on Google for a given search, every company should do the same.
My whole point about talking to your target audience was meant to directly contradict this. Your target audience can only be a finite set of people, because you can only talk to a finite set of people. Otherwise, you're just producing noise and hoping someone will listen to it.
The point of the joke is that what works for you, won’t work for companies. Different goals, different reactions.
The irony to this whole thread is that CNET is actually highly targeted about their audience development, which is how they decided which content to prune in the first place.
Citation needed. I can tell you about lots of companies that have existed for years. That I never found from Google.
> Different goals, different reactions.
I don't know what you mean by "reactions" here, but I don't think that their goals are good if they end up making what they produce worse in the eyes of their target audience in order to meet that goal.
> CNET is actually highly targeted about their audience development
Some people are saying their audience is tens of millions of people, and others are saying their audience is "highly targeted". Which is it? Those two are claims are extremely incompatible.
Coming in with a discussion about CNET and then talking about your own personal website seems... misguided?
I don't know if CNET is making the right call here. But I can at least understand the logic and thought process they went through, however misguided it appears.
That sounds instead like optimizing your car for the parking lot. If Google doesn't see your site, you've got to put 100x the effort into marketing that site.
2. Identify what that audience wants (by asking them)
3. Build what the target audience asked for if you agree that it is a sensible thing to create.
4. Tell the target audience that you have built your thing.
Note that "target audience" here is probably not Google, but on all 4 points, SEO replaces "target audience" with "Google". Pruning old information is not something that any group of humans have requested besides Google.
If your target audience is a close set of friends, family, professional associates, or other well-defined community, then yes, reaching out through that specific network is probably the best way of reaching it.
Which in mondern parlance is what is being accomplished by newsletters, mailing lists, and various social media feeds.
But if you're in the business, as in commercial enterprise, of reaching out to a large and generally undefined audience, or are responsible for government or NGO services, etc., general Web search is among your most valuable marketing mechanisms. And that sector includes literally billions of people and hundreds of billions of dollars worth of transactions or equivalent value.
And manual outreach through a small group ... really isn't effective.
I'm not saying that your specific use case is invalid. I am saying, as someone with a deep and abiding animosity to virtually all modern marketing, advertising, and SEO, that modern marketing, advertising, and SEO do in fact have a place. And that your comments here are largely asserting otherwise.
> Your second question simply doesn't deserve a response.
Clearly it did, and quite a disrespectful one at that. I guess (and I have to guess, since you won't tell me) you think that because you can't talk to many people, and you think it is self evident that businesses should target many people.
I do not think that is self evident. I think instead of few people targeting many people, many people should target few people. You have probably heard that you can't make everyone happy. That's true. But it becomes less true the smaller the group that "everyone" is. If your target audience is a handful of people, you can make them all happy. You can even potentially individualize what you produce to meet the needs of specific individuals. You cannot do that when your target audience is a billion people.
If I want to tell my mom something, the most effective way is not to try to sneak my message into some search result of hers.
When I say "target audience" and "humans" I mean it in the most literal sense. The most effective way to tell people that you built something for them is to tell them.
Let's make this concrete. Let's say you're CNET—your target audience is millions upon millions of people who are interested in tech news. What is your alternative strategy for telling these tens of millions of people that you have a new article on topic X?
Note that only a tiny fraction of your audience is already subscribed to some form of push notification from your service.
> What is your alternative strategy for telling these tens of millions of people that you have a new article on topic X?
None. I don't know tens of millions of people.
Why do you think that CNET - a relatively small group of people - should have the power to reach an influence tens of millions of people, even if only in a small way per person? I don't think that's healthy for anyone involved.
The premise you're suggesting is only the most effective way to tell a small number of people (ie tell them directly).
That's why radio, TV, newspaper advertising was so effective for so long.
Even for a small convenience store, larger scale - mass audience, automated - advertising is almost always a necessity and a far more effective use of time.
py speech recognition lib for audio, then @OpenAI’s whisper library for speech->text, then chatgpt, text->speech w/ @narakeet for voice ai, then play it through speaker with pydub playback
Claude.md just has 2 lines. the first points to @CONTRIBUTING.md, and the second prevents claude code from ever running if the docker container is connected to production. We already had existing rules for how the project is organized and how to write code and tests in CONTRIBUTING.md, making this relatively easy, but this file then co-evolved with Claude. Every time it did something unexpected, we'd tell it to update contributing rules to prevent something like that from happening again. After a while, this file grew considerably, so we asked Claude to go through it, reduce the size but keep the precision and instructions, and it did a relatively good job. The file has stabilized after a few months, and we rarely touch it any more.
Generally, tasks for AI-assisted work start with a problem statement in a md file (we keep these in a /roadmap folder under the project), and sometimes a general direction for a proposed solution. We ask Claude code to an analysis and propose a plan (using a custom command that restricts plans to be composed of backwards compatible small steps modifying no more than 3-4 files). A human will read the plan and then iterate on it, telling Claude to modify it where necessary, and then start the work. After each step, Claude runs all unit tests for things that have changed, a bunch of guardrails (linting etc) and tests for the wider project area it's working in, fixing stuff if needed. A developer then reviews the output, requests refactoring if needed, does git add, and tells claude to run the next step. This review might also involve deploying the server code to our test environment if needed.
Claude uses the roadmap markdown file as an internal memory of the progress and key conclusions between steps, and to help with restoring the progress after context resets. Pretty much after the initial review, Claude only uses this file, we don't look at it any more. Once done, this plan file is thrown away - tests and code remain. We occasionally ask it to evaluate if there are any important conclusions to record in the architectural design records or contributing guide.