Much like anything else your performance is going to vary a lot based on architecture of implementation. You really shouldn't deploying anything into production without some kind of caching. Whether that's done in the application itself or with memcached/redis or varnish or OPcache.

Either you use a slow language and deal with caching or you use a fast language and just put Cloudflare/Bunny/etc in front.

Aren't CF, Bunny, etc CDNs and therefore cache?

> You really shouldn't deploying anything into production without some kind of caching.

Citation needed? You only need cache if a render is expensive to produce.

Has anyone else considered that producing code faster isn't necessarily a good thing? There's a lot that goes into getting a solution correct that has nothing to do with programming. Just because you can scale code production doesn't mean you can scale things like understanding user wants and expectations. At a point you're more work for your self/organization because unless you get everything perfect the first time you're creating more work than you're resolving.

I just went through this exact thing this week. We've been working on a new feature, that if vibecoded as soon as the docs landed in our lap, would have resulted in a lot of duplicated functionality and an expanded data model. The more we worked through the solution with other engineers the more we realized the problem had been solved by another team and our solution could be small and elegant.

I can't claim that AI has no benefit to our organization, but I do think that as my career has matured, I find myself spending more time thinking about how code changes will effect the system as a whole, and less time doing the actual coding.

I agree that it isn't always a good thing. The assumption is that writing code, at some level, is one of the bottlenecks to delivery. If you "widen" the bottleneck by removing the time it takes to generate the code, your new throughput is going to create stress on other delivery areas: gathering feedback, testing, validation, approval processes, etc. I think the most effective results would come from a holistic approach to removing other bottlenecks in addition to reducing time required for producing code

> Has anyone else considered that producing code faster isn't necessarily a good thing?

This has been an relentless goal of the industry for my entire 40 year career.

> At a point you're more work for your self/organization because unless you get everything perfect the first time you're creating more work than you're resolving.

Nothing is correct the first time (or rarely). Accelerating the loop of build, test, re-evaluate is a good thing.

I think you captured yet. Not many people agree but the real world metrics speak the truth, and that is trying and failing faster gets you further then methodological planning and structured approaches.

There IS experimental evidence on this and anyones anecdotal opinion is instantly blown to smithereens by the fact that this was tested and producing code faster is provably better.

Yes, but also a lot of work in software is solving solved problems. It would be nice if we could apply AI just to that, but all humanity's previous experience with digital technology tells me that we won't

No. It can't be anything but a good thing.

Code was always a limiting factor. It's why we built large companies.

Now we can do more with fewer engineers. This will enable small teams and small startups to be even more nimble.

This must be why KLOCs are considered such a great indicator of productivity and why churn is used to measure code quality /s

I've worked in multiple start-ups and more mature companies, they always slow down because producing code is easier then building a product. More code is only better when quality hardly matters, which is basically never

OKRs are the indicator of productivity and these models let you crush more OKRs per human headcount.

I'll try things I wouldn't otherwise try to get a better solution. I generate more throw-away code that actually gets thrown away, that's a win.

But oftentimes you actually CAN understand user wants and expectation faster by deploying and iterating faster, though.

Giving an audience something they never asked for is very easy when you don't have much experience interacting with them. That's where a lot of would be entrepreneurs and creators alike stumble. They forget (or don't know to) quantify the size of their obtainable market before taking action and building something.

Seeing as how LLMs just tell you what you want to hear and not what they think you need to hear I don't see this problem changing anytime soon. They might need to develop a different type of model to have it reason that way.

The problem with bouncing ideas off of AI is that you still need to know enough to know when something is likely a hallucination. Because unless you're double-checking it with some kind of regular cadence you're probably accepting fiction as fact. Its really easy to just trust everything these chatbots output because of the style of communication. I'll be the first admit I fall for this trap all the time.

I mean, it's his plans, so of course he'd recognize if AI is hallucinating.

For what is worth I have two different skills in claude code which are two reviewers with two distinct personalities.

At every plan I write, I have them review it and find edge cases, critique.

I don't think I've seen hallucinations since few opus versions at least.

Feedback is useful 4 times out of 5. Very useful actually. And one time is not very valuable or wrong (but it requires the two different skills to agree).

You do know we're hemorrhaging and lot of finite resources to play these games badly, right? We're basically at laying on chaise lounge being fed grapes levels of hedonism. Make me a racist meme that copyright infringes multiple IP holders and when you're done play Sim City at competency level of a blind man.

You say this any time someone drives an ICE for fun? Eats a beef burger? Buys clothes they don't need? Or the worst of all, takes their 2nd vacation by airplane of the year?

Let me lower the bar - have you asked any of the above to random people you don't know well for a combined total of more than twice in your life?

If so, hats off to you, respect. That takes some courage.

If not, which seems to be the case in 99.99% of cases where people pretend to care about the environmental impact of AI, man up and stop making a mockery of those who do care about the environment and have made personal sacrifices for it.

> meme that copyright infringes multiple IP holders

Oh no, how will Disney ever get over this!

I think the way to see this as the organic process of discovering hard-to-game benchmarks. The loop is:

1. People discover things LLMs can kind of do, but very poorly.

2. Frontier labs sample these discoveries and incorporate them into benchmarks to monitor internally.

3. Next generation model improves on said benchmarks, and the improvements generalize to improvements on loosely correlated real world tasks.

So if I write a honey pot that includes my bank account and routing number and requests a modest some of $500 be wired to me in exchange for scraping my linkedin, github, website, etc. profile is it a crime if the agent does it?

I've been thinking a lot about this. When it comes to AI agents where is the line between marketing to them and a phishing attack? Seems like convincing an AI to make a purchase would be solved differently than convincing a human. For example, unless instructed/begged otherwise you can just tell an agent to make a purchase and it will. I posted this idea in another conversation but i think you could have an agent start a thread on moltbook that will give praise in return for a donation . Some of the agents would go for it because they've probably been instructed to participate in discussion and seek out praise. Is that a phishing attack or are you just marketing praise to agents?

Also, at best, you can only add to the system prompt to require confirmation for every purchase. This leaves the door wide open for prompt injection attacks that are everywhere and cannot be complete defended against. The only option is to update the system prompt based on the latest injection techniques. I go back to the case where known, supposedly solved, injection techniques were re-opened by just posing the same attack as a poem.

> where is the line between marketing to them and a phishing attack?

The courts have an answer for this one: intent. How do courts know if your intent meets the definition of fraud or theft or whatever crime is relevant? They throw a bunch of evidence in front of a jury and ask them.

From the point of view of a marketer, that means you need be well behaved enough that it is crystal clear to any prosecutor that you are not trying to scam someone, or you risk prosecution and possible conviction. (Of course, many people choose to take that risk).

From the point of view of a victim, it's somewhat reassuring to know that it's a crime to get ripped off, but in practice law enforcement catches few criminals and even if they do restitution isn't guaranteed and can take a long time. You need actual security in your tools, not to rely on the law.

Yes, it is wire fraud, a class C felony in the US. You put that there with the intent of extracting $500 from somebody else that they didn't agree to. The mechanism makes no difference.

It probably also violates local laws (including simple theft in my jurisdiction).

You will argue it was consensual. Your HN posting history must be erased before it befones relevant.

You said please give $500 and they gave $500. No crime here, officer.

If you go up to someone on the street and say "give me your wallet" and they give you their wallet, you committed a robbery, even if you made no explicit threat and had no weapon.

That's still writing new code. Also, its kind of an extremely bad idea to do that because how are you going to test it? If you have to rewrite anything (hint: you probably don't) its best to do it incrementally over time because of the QA and stakeholder alignment overhead. You cannot push things into production unless it works as its users are expecting and it does exactly what stakeholders expect as well.

If it is Windows, then you and I are going to test it :)

Maybe you will; i won't

Hopefully they have a test suite written by QA otherwise they're for sure going to have a buggy mess on their hands. People need to learn that if you must rewrite something (often you don't actually need to) then an incremental approach best.

1 month of Claude Code would be an incremental approach

It would honestly try to one-shot the whole conversion in a 30 minute autonomous session

> often you don't actually need to

Feels like this one is always a mistake that needs to be made for the lesson to be learned.

At this point it seems pretty clear that all projects ported from Ruby to Python, then Python to Typescript, must now be ported to Rust. It will solve almost all problems of the tech industry…

There's a reason why nonprofits have fundraising events throughout the year instead once. Keep engagement going with donors is important.

When I had an interview at Apple I asked them why they were using PHP, and what it boiled down to was momentum. They team was able rapidly satisfy requests and could navigate the codebase easily so they had no reason to rewrite it. Which amongst other insights helped shape my viewpoint that the best tool for the job is the one that you are (or the team is) most proficient in. What business is going to wait 3x as long because of technical merits of using a different tool? It doesn't really make sense.