user34283

What they don't need is hardcoding support for five JS package managers in their python files.

In the post the maintainer says that an older version of bun "results in the ejs lockfile being ignored".

The reason is that they never committed the necessary lockfile despite listing "support" for that bun version.

They have separate lockfiles for other package manager versions: bun.lock, deno.lock, package-lock.json, pnpm-lock.yaml.

This part of the comment is also interesting: "which is a significant security concern for users when considering all of the recent npm supply chain attacks".

If you would set up a proper build for the JS artifact instead of committing four lockfiles to your repository, users would not be as exposed to npm supply chain attacks.

Or better yet, can someone explain why they build JS from python scripts with manual support for each package manager and a lockfile for each?

Obviously the JS build should happen outside of Python and use one package manager instead of attempting to support them all.

I speculate that I could indeed "vibe code" a better JS build integration because what they have does not make sense at a first look.

It appears they mixed JS building into their python project, aiming to support multiple package managers which are executed from their python script.

This explains the otherwise non-sensical explanation about bun < v2 ignoring the lockfile: they use a separate lockfile for each package manager. They did not check in one for bun v1, which they claimed to support, consequently it is not using a lockfile.

That's not how JS packaging normally works. I would set up a separate folder for the JS project, and use one package manager to build the project, like anyone else does.

Publish the package to npm, or bundle the tarball with your python program.

I guess the permission model of the JS runtime could be another topic, but at least they would have their build fixed without worrying about Node dependency resolution and package managers in their Python code.

There's 10-15 labs near the frontier, and like 30 serious inference providers, over 70 total on OpenRouter.

With research and hardware near guaranteed to bring the efficiency way up, I'm not scared here of massive price hikes.

There is no moat.

I don't see the benefit of checking in either prompts or specs.

I never tried spec driven development for myself, but if I review other's MRs I am typically exhausted after the first 10 lines.

And there are hundreds of lines, nearly always with major inaccuracies.

For myself I always found the plan mode to work well. Once the implementation is done, the code is the source of truth. If it works, it works.

When I want to add more functionality or change it, I just tell the agent what I want changed.

I doubt walls of semi-accurate existing specs are going to be beneficial there, but maybe my work differs from yours.

It would seem to me that the main source of food insecurity is violent conflict rather than greed.

I often hear people talk online about burning data centers to avoid some capitalist dystopia.

It just seems incredibly pessimistic to me. Who wants civil unrest? The rich elite does not want this either.

We will pay people.

Capitalism is not set in stone when human labor is no longer essential for productivity and AI can handle planning that markets currently coordinate through capitalism.

The difference is that you don't just pull again.

You guide the originally mediocre result towards a good outcome by providing feedback and potentially technical insights.

That's not a gamble, it works reliably enough.

Thanks, I appreciate the info.

But I don't think I'm going to email the mods and beg them to remove me from some list they added me to without notifying me.

I don’t feel like apologizing for complaining about the drivel some write because they don't like LLMs.

It was not my most substantial or productive comment, but I feel it is fair enough and did not target anyone in particular.

Contributing to HN is not worth it.

I'm spending my time, compromising my privacy, and advising potential competitors on what works best in my workflow. It's often not appreciated, so I might as well stop commenting so much.

I hope to publish my app in a month or two, after sufficient polish, market research, and App Store optimization.

As I said, it's not exactly realistic to ask for numbers and a Photoshop competitor within two months.

I am working like 20 hours a week on my new iOS app with Codex.

People on here talk like it was some belief or suggest I am somehow profiting from "hyping" AI.

Is it so hard to believe that agentic coding now works? Engineers are taking it up left and right.

Edit with reply: I can't, because the app is still in the works. Also my HN account is again rate limited and I won't be able to post more comments.

Edit number two to the other comment:

It's not really that expensive. With Anthropic it would be $200, with Codex the $100 subscription is sufficient.

It is interesting phrasing when you say that the providers "are making me think" the use of their service would be better, rather than me reaching this conclusion myself after using their services extensively for my work.

And honestly, I think I've had it with HN. I can't even participate properly in the discussion, maybe because some moderator thought my comments and opinions unworthy again.

This is pretty much true.

Before Codex with GPT 5.4 and 5.5 I was working on a single feature only, no parallel conversations, and a ton of permission prompts would make it impossible for the agent to even work for five minutes on its own.

Times have changed.

I understand Codex had 500k weekly users at the beginning of the year, now they have 4M.

GPT 5.4 came out at the start of March, GPT 5.5 end of April.

What do you expect, that we all go to market with a Photoshop competitor within two months?

Edit: and I can't provide any more replies since once again some automatic system or a mod rate limited my account for whatever reason.

Let's see at the end of the year how that went with the supposedly disappointing actual output and no layoffs.

With GPT 5.4 or 5.5 I did not notice degradation in performance when it was working on a large 5k line file containing a WebView, JS scripts, as well as native UI.

I instructed it to split it up anyway, yet I wonder how often the concerns around the mess are imaginative rather than practical.

Let's say iCloud sync

Microservices in big companies where you have to first write the spec and then fully understand the changes is maybe among the least benefiting use cases yet.

When you work on just a new mobile app, this is where I find AI is making the biggest difference.

On mobile you don't need specs and you don't need to understand every detail of the implementation. You can QA test the app on a real device. It gives me more confidence than just having written the code myself, and it's much faster. You can implement multiple major features in a single day.

This kind of e2e testing is just not possible with backend services.

While this arXiv policy seems reasonable enough, I don't care for the kind of drivel some post on HN because they don't like LLMs.

I'm here because I enjoy building things. And today this mostly happens with AI. I could do without the often thoughtless comments and conspiracy theories about "LLM hypers" posted by people who don't like LLMs.

I don't think the owner lied, but rather that the entirely speculative comment on here is obviously wrong.

It says here in the comments that it's mistaken about the supposed previous existence of the crate.

No. I just use claude -p to review some Codex output.

The Pro plan is barely enough for this after the doubling of usage limits.

After the recent doubling of usage limits Opus 4.7 via claude -p barely offers enough usage on the Pro plan to review changes I make via Codex.

I assume that with API pricing it will run out in the first week and I might as well unsubscribe.

On GitLab even if you set the same cache key it will not cross between unprotected and protected runs.

GitLab just adds a -protected suffix to the cache key.

It seems baffling that GitHub does not do this trivial separation, if I understand it correctly.

What I don't get is how the GitHub Action cache is shared between unprotected and protected refs. Is that really the case?

Why even have protected branch rules when anyone with write access to an unprotected branch can poison the Action cache and compromise the CI on the next protected branch run?

In GitLab CI caches are not shared between unprotected and protected runs.

It's not about the number of users but the kind of software you develop.

In a mobile app, do you think it's more important to test that your drag gesture works as expected on the phone, or to understand every line of the implementation?

I felt the same with:

"it takes too much effort to get the output production ready"

turning into

"maybe long term the maintenance will be more expensive"

I give it three months until people realize that you rarely need to review every single line and fully understand the code, like so many comments are claiming.

That breaks if the library uses build scripts, like for setting up native binaries, or native modules linked against the specific Node version.

If you want a vendored deps model you can look at Yarn Plug and Play which does this via .zip files.

However, I would just stick with regular pnpm and installs.

I‘ve recently started to use skills and so far it’s been working great.

Your agent can write a python script to loop and simply call „claude -p“ or „codex exec“.

For simple workflows this seems good enough and can be set up in 10 minutes without third party software.

What do you think?

Skills are not fairy dust but a combination of prompts and deterministic code, so that you get the best of both worlds.

Eg. Loop in the code, process the subagents non-deterministic response for the individual task.

This takes 10 minutes to set up, you just need to run something like /skill-builder and describe the desired workflow.

I imagine many people just don’t know that it’s possible. I only discovered it a few days ago myself.

It worked on the first try.

I can’t comment on the behavior of ancient npm versions, but with modern npm I would not even know how to skip using a lockfile.

As for the parent comment about not using the lockfile for the production build, that’s just incredibly incompetent.

Maybe they should hire someone who knows what they are doing. Contrary to the popular beliefs of backend engineers online, you also need some competency to do frontend properly.

In this case what’s needed is „npm ci“ instead of „npm install“ or better „pnpm install —frozen-lockfile“.

Pnpm will also do that automatically if the CI environment variable is set.

If you listen to people on HN you could think AI is not increasing productivity or is even having a net negative effect.

I think the reality is different.

In this thread I saw the resume of an engineer affected by this Cloudflare layoff. In the resume he claimed that adopting opencode in his workflow, he shipped an integration in half the time it took peers without AI assistance for similar projects.