Live data from Hacker News

Harness engineering: Leveraging Codex in an agent-first world

openai.com

151–160 of 222 posts

Re: Harness engineering: Leveraging Codex in an agent-first world

#151

Earlier quoted context omitted.

Well, to be fair, the amount of goalpost shifting that is going on is quite intense. AI not being able to work in a "serious" project, and being limited to "toy projects" has been a long standing critique. But also, bigger projects need some amount of loc written and it's a bit silly to pretend that this is not the case or a bad thing. So the answer to the question is roughly: Establishing that an agent can work in a…

Should we not be counting function points rather than LOC’s. Lines of Code is a meaningless measure. It should also be easy to count function points using AI.

Sure; But that's not the point that is argued about here.

(To state it in AI lingo:)

It's not about the best measure for "amount of code".

It's about wether "amount of code" is a good metric to begin with.

Re: Harness engineering: Leveraging Codex in an agent-first world

#152

Earlier quoted context omitted.

I’ve been vibe coding a lot over the past year or so, and I think I’m going to stop. In fact, I sort of want to challenge myself to see, can I go back to a sort of the fork in the road with the old copilot autocomplete workflow and really maximize that. Be in the drivers seat for most of the code being written, but find ways to use AI to really enhance the flow state / remove blockers. Tools only minimal actual code…

I would be very impressed with someone who's been vibecoding "a lot" for about a year who could then go back to being fully in the loop for even 50%. I would even say I'd expect withdrawal symptoms at that point. The dopamine hits are core to why people even do vibecoding (or vibecoding-in-a-dress/spec-driven development) and why they tend to overestimate its output so much. Hell, it's core to all forms of LLM-assist…

I actually don’t find vibe coding satisfying is one of the many reasons I’m going back. I feel a little of what you’re talking about, but I’m a nerd. I like to code.

But I’m not dismissing your concern. Because it is one of the reasons I’m making this decision. I’m a professional. I’m not just here to feel good I’m here to do a good job over the course of a career. I think all in, when you think about writing good maintainable, software, learning, staying mentally sharp, and speed put together. Vibe coding could be less effective and maybe even in the aggregate “slower”.

Re: Harness engineering: Leveraging Codex in an agent-first world

#153
I am not much understanding the naysayers here.

I will do a premise: I don't like where software engineering is heading, at all. I have never been unhappier to work in this field since AI came out. And no, it is not possible to opt out of AI, especially when your teammates are all great engineers whose productivity increased a lot without any drops in quality code-wise (in fact the opposite has happened). You need to keep up. But it's tiring and the fun/interesting parts are disappearing.

That being said, it's clear that harness engineering is the most important part of our job and that task is going to take increasingly more of our time. And thus having a glimpse of how an AI company handles it is by any means interesting.

Re: Harness engineering: Leveraging Codex in an agent-first world

#154

Earlier quoted context omitted.

>I suspect it's not seen as a problem by providers because more lines generated means more tokens used and hence more billing put out on customers. I have also grown skeptical of token usage in order to run up my bill! But since I feel like it takes me MORE effort to write LESS lines of code myself, I'd expect a quick and dirty AI-generated solution to be MORE lines of code and cost LESS to generate than a concise/el…

The latest frontier models will write code better than you and more elegant, with less lines of code, in 100th of the time, with full test coverage. Hand coding is like writing out assembly/machine code rather than using a compiler.

This.

Insisting on writing code by hand when LLMs are available is not software engineering in 2026. Engineers find the most cost-effective solution for the problem at hand that meets the requirements.

Re: Harness engineering: Leveraging Codex in an agent-first world

#155
post #87

I'm not an AI skeptic but I'm skeptical of the intent of this article. It makes great claims about agent-first engineering and tries to make a real case based on a real product, with real users, and a real team that's been growing — all without even saying what was built or showing it, just like every other AI hype article.

And this thread too is filled with users that "I also have done this or that" but bar one user, nobody followed up with any link to anything.

Re: Harness engineering: Leveraging Codex in an agent-first world

#156

I’d be interested to know two things: 1. What’s the job satisfaction like day to day being an engineer on this project? How have they adapted to this way of working? 2. How much did it cost? Work is being done whilst the engineers sleep but if that 6 hours overnight task cost $300 and could have been done by a person in 2 hours is it a real saving?

> 1. What’s the job satisfaction like day to day being an engineer on this project? How have they adapted to this way of working?

The job satisfaction is looking at the bank account every time you feel your job sucks.

Re: Harness engineering: Leveraging Codex in an agent-first world

#157

Earlier quoted context omitted.

>I suspect it's not seen as a problem by providers because more lines generated means more tokens used and hence more billing put out on customers. I have also grown skeptical of token usage in order to run up my bill! But since I feel like it takes me MORE effort to write LESS lines of code myself, I'd expect a quick and dirty AI-generated solution to be MORE lines of code and cost LESS to generate than a concise/el…

The latest frontier models will write code better than you and more elegant, with less lines of code, in 100th of the time, with full test coverage. Hand coding is like writing out assembly/machine code rather than using a compiler.

> The latest frontier models will write code better than you and more elegant

They often do, but they often don’t. I regularly have to push for more elegant, or less lazy solutions.

Re: Harness engineering: Leveraging Codex in an agent-first world

#158
post #41

What I still can't understand is why is massive amount of code generated is a flex? I don't feel that software has gotten a lot better in past 3 years, only sloppier. It's surprising to me that people who know about reward hacking choose a simple objective like lines of code generated as a signal for quality. I'd argue you have to optimize for less lines generated as possible while secondary optimization should be re…

Far from everybody is using it for massive code generation - code size is still very much a liability. I currently use it (ds4-flash, local, code isn't open to non-local) to modify and trim a certain internal project for a different use case. Tons of review passes, fuzz test generation and running, "give me your thoughts on this", etc, etc - basically iterating over and over and over. Funnily enough, my intrinsic knowledge of the codebase improves massively like this. It is involved, but the acceleration is real - and I don't have to worry about wrist nerves as much.

The only people I know that have LoC/token use/etc metrics imposed on them work for big corps where such things are (or used to be) en vogue.

Re: Harness engineering: Leveraging Codex in an agent-first world

#159
post #2

> We had weeks to ship what ended up being a million lines of code... Five months later, the repository contains on the order of a million lines of code across application logic, infrastructure, tooling, documentation, and internal developer utilities. Over that period, roughly 1,500 pull requests have been opened and merged with a small team of just three engineers driving Codex. This translates to an average throug…

The average efficiency improvement is closer to something like 2-3x per Anthropic’s numbers and this is only the rate at which software can advance. Do you expect to notice if 12 months of software engineering on a project you’re following gets done in 6 months? I suspect not.

The root cause is that the acceleration is pareto distributed so the modern engineering team at the moment looks like one 10x engineer, one 5x engineer, and the rest are approximately 1.5x engineers.

Re: Harness engineering: Leveraging Codex in an agent-first world

#160
post #2

> We had weeks to ship what ended up being a million lines of code... Five months later, the repository contains on the order of a million lines of code across application logic, infrastructure, tooling, documentation, and internal developer utilities. Over that period, roughly 1,500 pull requests have been opened and merged with a small team of just three engineers driving Codex. This translates to an average throug…

It feels like the update cadence has indeed sped up. But not necessarily quality.

Looking at MS Office I notice a lot of small changes recently that are mostly annoying. Things like Word comments losing the focus after you @-tagged a colleague, needing to click the Outlook search field twice before you can enter text, Outlook mobile date picker losing its ability to show your and attendee's availability.

So it looks like lots of throughput, but unfortunately breaking features that work. Or wasting time on things that don’t matter such as the status bar of OneDrive search circling around the input field.

Post reply on HN