paulhodge

AI enhances human ability. In this case, it enhanced someone’s ability to be an asshole.

No you’re just deflecting his points with an ad hominem argument. Stop pretending to assume what he ‘truly feels’.

AI is too useful to fail. Worst case with a bust is that startup investment dries up and we have a 'winter' of delayed improvement. But people aren't going to stop using the models we have today.

Agree that LLMs go too far on error catching..

BUT, to play devil's advocate a little: Most human coders should be writing a lot more try/catch blocks than they actually do. It's very common that you don't actually want an error in one section (however unlikely) to interrupt the overall operation. (and sometimes you do, it just depends)

Neat investigation but I didn’t totally follow how the project would be useful for reverse engineering, it seems like a project that would mostly be useful for evading bot checks like web scraping or AI automation.

I think this prediction of "vibe code cleanup" is massively overblown. It's amazing how much code quality doesn't actually matter to the business. Yes we recognize symptoms and downsides of bad code, and yes it matters specifically to the engineers that have to work on it. But only in extreme cases does bad code actually cause an existential threat to the business. The world already runs on bad code.

it's kind of tongue-in-cheek but it would provide the maximum amount of isolation from any upstream package changes. Even if the package versions are removed from NPM (which happens in rare cases), you'd still have a copy.

Pnpm 10.x also has a feature to disallow post-install scripts by default. When using Pnpm you have to specifically enable a dependency to let it run its post-install scripts. It's a great feature that should be the standard.

Yes if someone compromises a package then they can also inject malicious code that will trigger at runtime.

But the thing about the recent NPM supply chain attack - it happened really quickly. There was a chain reaction of packages that got compromised which lead to more authors getting compromised. And I think a big reason why it moved so quickly was because of post-install scripts. If the attack happened more slowly, then the community would have more time to react and block the compromised packages. So just slowing down an attack is valuable on its own.

solution: add your entire 'node_modules' folder to source control.

I think different things are happening...

For experienced engineers, I'm seeing (internally in our company at least) a huge amount of caution and hesitancy to go all-in with AI. No one wants to end up maintaining huge codebases of slop code. I think that will shift over time. There are use cases where having quick low-quality code is fine. We need a new intuition about when to insist on handcrafted code, and when to just vibecode.

For non-experienced engineers, they currently hit a lot of complexity limits with getting a finished product to actually work, unless they're building something extremely simple. That will also shift - the range of what you can vibecode is increasing every year. Last year there was basically nothing that you could vibecode successfully, this year you can vibecode TODO apps and stuff like that. I definitely think that the App Store will be flooded in the coming future. It's just early.

Personally I have a side project where I'm using Claude & Codex and I definitely feel a measurable difference, it's about a 3x to 5x productivity boost IMO.

The summary.. Just because we don't see it yet, doesn't mean it's not coming.

Yeah Dario has said similar things in interviews. The way he explained it, if you look at each specific model (such as Sonnet 3.5) as its own separate company, then each one of them is profitable in the end. They all eventually recoup the expense of training, thanks to good profit margins on usage once they are deployed.

There’s a magic component to rule breaking that a lot of online advice doesn’t usually talk about: You have to actually be right. Your ideas have to be good. Companies don’t want everyone breaking the rules because a lot of devs don’t have the engineering skill to back it up.

So if you start operating as a rogue agent then make sure you are good. Tom Cruise (stuntman and actor) had a quote I love- “Don’t be careful. Be competant.”

I have to agree with the author about not adding "v1" since it's rarely useful.

What actually happens as the API grows-

First, the team extends the existing endpoints as much as possible, adding new fields/options without breaking compatibility.

Then, once they need to have backwards-incompatible operations, it's more likely that they will also want to revisit the endpoint naming too, so they'll just create new endpoints with new names. (instead of naming anything "v2").

Then, if the entire API needs to be reworked, it's more likely that the team will just decide to deprecate the entire service/API, and then launch a new and better service with a different name to replace it.

So in the end, it's really rare that any endpoints ever have "/v2" in the name. I've been in the industry 25 years and only once have I seen a service that had a "/v2" to go with its "/v1".

Imagine a browser with no cross-origin security, lol.

That’s bad because visiting an evil site can easily trick your browser into performing one of those requests using your own credentials. CORS doesn’t stop the backend state effect from happening.

Fyi Kilocode has low credibility. They’ve been blasting AI subreddits with lots of clickbaity ads and posts, sometimes claiming things that are outright false.

As far as spend per dev- I can’t even manage to use up the limits on my $100 Claude plan. It gets everything done and I run out of things to ask it. Considering that the models will get better and cheaper over time, I’m personally not seeing a future where I will need to spend that much more than $100 a month.

Lots of signs point to a conclusion that the Opus and Sonnet models are fundamentally better at coding, tool usage, and general problem solving across long contexts. There is some kind of secret sauce in the way they train the models. Dario has mentioned in interviews that this strength is one of the company's closely guarded secrets.

And I don't think we have a great eval benchmark that exactly measures this capability yet. SWE Bench seems to be pretty good, but there's already a lot of anecdotal comments that Claude is still better at coding than GPT 5, despite having similar scores on SWE Bench.

No this app isn't launched yet. And yeah, customer data is definitely a very valid thing to be concerned about.

Mainly working on a dev tool / SaaS app right now. The PII is user names & email.

On the security layer, I wrote that code mostly by hand, with some 'pair programming' with Claude to get the Oauth handling working.

When I have the agent working on tasks independently, it's usually working on feature-specific business logic in the API and frontend. For that work it has a lot of standard helper functions to read/write data for the current authenticated user. With that scaffolding it's harder (not impossible) for the bot to mess up.

It's definitely a concern though, I've been brainstorming some creative ways to add extra tests and more auditing to look out for security issues. Overall I think the key for extremely fast development is to have an extremely good testing strategy.

I've had days where it really does feel like 5x or 10x...

Here's what the 5x to 10x flow looks like:

1. Plan out the tasks (maybe with the help of AI)

2. Open a Git worktree, launch Claude Code in the worktree, give it the task, let it work. It gets instructions to push to a Github pull request when it's done. Claude gets to work. It has access to a whole bunch of local tools, test suites, and lots of documentation.

3. While that terminal is running, I go start more tasks. Ideally there are 3 to 5 tasks running at a time.

4. Periodically check on the tabs to make sure they're not stuck or lost their minds.

5. Finally, review the finished pull requests and merge them when they are ready. If they have issues then go back to the related chat and tell it to work on it some more.

With that flow it's reasonable to merge 10 to 20 pull requests every day. I'm sure someone will respond "oh just because there are a lot of pull requests, doesn't mean you are productive!" I don't know how to prove to you that the PRs are productive other than just say that they are each basically equivalent to what one human does in one small PR.

A few notes about the flow:

- For the AI to work independently, it really needs tasks that are easy to medium difficulty. There are definitely 'hard' tasks that need a lot of human attention in order to get done successfully.

- This does take a lot of initial investment in tooling and documentation. Basically every "best practice" or code pattern that you want to use use in the project must be written down. And the tests must be as extensive as possible.

Anyway the linked article talks about the time it takes to review pull requests. I don't think it needs to take that long, because you can automate a lot..

- Code style issues are fully automated by the linter.

- Other checks like unit test coverage can be checked in the PR as well.

- When you have a ton of automated tests that are checked in the PR, that also reduces how much you need to worry about as a code reviewer.

With all those checks in place, I think it can pretty fast to review a PR. As the human you just need to scan for really bad code patterns, and maybe zoom in on highly critical areas, but most of the code can be eyeballed pretty quickly.

Yeah the outrage is a little artificial and definitely premature.

Some facts for sanity:

1- The poster of this blog article is Kilocode who makes a (worse) competitor to Claude Code. They are definitely capitalizing on this drama as much as they can. I’ve been getting hit by Reddit ads all day from Kilocode, all blasting Anthropic, with the false claim that their plan was "unlimited".

2- No one has any idea yet what the new limits will be, or how much usage it actually takes to be in the top 5% to be affected. The limits go into effect in a few days. We'll see then if all the drama was warranted.

There’s been a ton of ‘service overloaded’ errors this week so it makes sense that they had to adjust it.

Personally I’ve never hit a usage limit on the $100 plan even when running several Claude tabs at once. I can’t imagine how people can max out the $200 plan.

Very fun and some of these ideas are.. actually not terrible.

The AI definitely gets confused when there is a lot of stuff happening. It helps if you try to make the commands as easy as possible. Like, change 'make' so that '-j8' is default, or add scripts like make-check.sh that does 'make -j check', or add an MCP server that has commands for the most common actions (tell the AI to write an MCP server for you).

Hooks would probably help, I think you could add a hook to auto-reject the bot when it calls the wrong thing.

I'm pretty sure that the $100 / $200 plans are a net profit for Anthropic. Most users (including myself) don't come close to the usage limit.

I've been trying to max out the $100 plan and I have a problem where I run out of stuff to ask it to do. Even when I try to have multiple side projects at once, Claude just gets stuff done, and then sits idle.

That's limited to simple string matching with `*` so it can't handle anything complex.

Agree with the headline but I think the takeaways are a little too cynical. You don't really have to take such a confrontational approach with future employers.

IMO the biggest takeaway I had after a layoff: Always try to navigate your career so that you are doing something valuable to the business. You can tell based on a lot of clues whether you're in a position that's valuable or if you're forgettable. Moving "toward the money" not only helps job security but it helps your compensation too.

Say for example your team has a stretch of a few months without any new high priority requirements or requests. A young developer might think, "Yay, finally we have enough time to do all that refactoring in the backlog." But in reality, that situation should make you very concerned.

I'm not sure if the legend is true or not. But this argument doesn't really disprove it. The devices don't need to send full audio recordings. They are powerful enough these days that they can do a cheap on-device audio analysis and tagging, and then upload the (very small) tags. It doesn't need to be Siri quality analysis because it doesn't matter if the analysis is incomplete or sometimes inaccurate. They would just be scanning for certain keywords.

As for whistleblowing... Is there really that much to whistleblow about it? We already know that ad-based companies like Google are collecting our data every chance they get, because they make billions of dollars from it. They're scraping our emails, studying our GPS location, paying attention to who we are in proximity with, etc. The level of surveillance is incredible and people don't really care. It wouldn't be headline news to find out that they are taking advantage of yet another side channel.

First cases of countries passing legislation specifically to protect human workers from being replaced by AI.

this advice isn't all that useful.

On that first one: "Every outperformer I knew had the style guide internalized"

No thanks.. It's the year 2023, just install an autofixing linter which fixes the code for you, and then worry about other things.