Live data from Hacker News

Codex Security

github.com

231–240 of 257 posts

Re: Codex Security

#231
post #225

Earlier quoted context omitted.

If it's code for a pacemaker, it should be reviewed by multiple humans. If it's code for an unimportant side project, I will never read it. Between those extremes are shades of grey. Part of our job in this new era is to understand the worst-case consequences of a bug given how the code interacts with the world, then allocate our effort based on that understanding. This can only be done on a case by case basis.

If you don't, at a bare minimum, read the code once though, you don't know how it interacts with the world.

[dead]

Re: Codex Security

#232

Earlier quoted context omitted.

If you didn't already know, jobs at highly competitive companies tend to have vague job requirements because they expect to be able to apply your raw intelligence to changing demands quickly. There's no point being hyper-specific about the exact software packages because that's not what they want. What they want is someone who, after talking to an interviewer for 30 minutes, leaves them with the thought "Wow, this pe…

> raw intelligence I'm not sure how this would apply. Are you implying that if the company operates on Python, you can hire someone with great "raw intelligence" who have only developed C++ all their life, and they can start contributing on day 1? You need to clearly list what the position entails, otherwise you're wasting time.

They are listing what the position entails. In this case it's a full-stack web dev role. "only c++ all their life" is more or less not possible if you have experience doing that

Likewise from another job post: "Have a strong background in kernel-level systems". Not possible if your whole resume is building web apps, may be possible for someone that has only used c++ professionally.

Re: Codex Security

#233
post #106

Earlier quoted context omitted.

Is that so? I feel like I’m seeing more Python and TypeScript than ever, especially when it comes to AI tooling, which is disappointing. I can’t fathom why anybody would want to continue working with dynamically typed languages when they can now get types for free.

Almost all my tool/skill scripts are in python purely because the standard library has almost everything under the sun in it.

Are you familiar with the Go standard library? It’s notorious for its comprehensiveness and how often you can write zero dependency applications as a result.

And there’s a reason: the Go designers were huge Python fans, so leaned on its design quite a bit. They essentially wanted to make a modern Python with first class support for static typing and highly scalable parallelism, not just concurrency.

Re: Codex Security

#234

security tools from AI companies feel like fire departments run by arsonists. useful, sure, but you can't help noticing who benefits from all the fires

This comes almost exactly a week after the HF hack. Good strat, to drum up a bunch of press about how security-capable the model is right before releasing the product.

Or, it would be if it was intentional. It's a bit suspicious but it is probably incidental or opportunistic... though I do really struggle to see why this tool wasn't made better use of internally to actually harden their infra against the big scary AI they were testing.

Re: Codex Security

#237

Earlier quoted context omitted.

This sounds like it’s just an app development role, not a security analysis position, so I’m not sure what your complaint is.

Professional app development requires an understanding of security.

Good thing they asked for people with experience of professional app development then.

Re: Codex Security

#238
post #106

Quick tangent if you’re willing to humor me… I've been noticing that many new projects that would have been written in Python or Node a year ago are starting to be written in Go, Rust, etc. Theory: people realized there’s little benefit to Python for agents. As Zep wrote, an “agent is a long-running, concurrent, I/O-bound process that spends most of its time waiting on a model, a tool, or a human[1]” — not a particul…

Is that so? I feel like I’m seeing more Python and TypeScript than ever, especially when it comes to AI tooling, which is disappointing. I can’t fathom why anybody would want to continue working with dynamically typed languages when they can now get types for free.

Fully agree with you, and I didn't make my point well — I should have been more clear.

While Python and Node have undoubtedly seen a huge spike since the advent of mainstream AI, relatively recently I've begun to notice a small but growing trend of people switching away from or back to languages like Go and Rust. In an absolute sense, yes, Python is still dominating and growing.

The trend I have noticed is a very small but growing cohort of folks who are coming back to languages like Go and Rust.

Re: Codex Security

#239

Earlier quoted context omitted.

Almost all my tool/skill scripts are in python purely because the standard library has almost everything under the sun in it.

Are you familiar with the Go standard library? It’s notorious for its comprehensiveness and how often you can write zero dependency applications as a result. And there’s a reason: the Go designers were huge Python fans, so leaned on its design quite a bit. They essentially wanted to make a modern Python with first class support for static typing and highly scalable parallelism, not just concurrency.

It's too late to edit, but in retrospect I realize that the first sentence of that comment sounded awfully snarky, and I didn't mean it to. I apologize, and please trust it was asked in good faith.

Re: Codex Security

#240

Quick tangent if you’re willing to humor me… I've been noticing that many new projects that would have been written in Python or Node a year ago are starting to be written in Go, Rust, etc. Theory: people realized there’s little benefit to Python for agents. As Zep wrote, an “agent is a long-running, concurrent, I/O-bound process that spends most of its time waiting on a model, a tool, or a human[1]” — not a particul…

Go and rust have better guardrails that help agents write better code. Python and JS aren't opinionated enough.

I agree with that — One of Go's biggest strengths is the flip side of an arguable weakness: it's not a very expressive language.

The positive of that is that if you ask three people to write the same function, it'll most likely end up nearly identical. You don't get codebases where different areas are written using different styles and different patterns.

This same effect applies equally to coding agents.

Post reply on HN