Are we now really this far knees down in the gutter already? Are we?

agentultra 5 hours ago | parent | next [-]

Maybe. I’m not certain the pages and pages of informal markdown specifications for the agents really add anything for me.

▲

whattheheckheck 5 hours ago | parent [-]

Yes the bar will be raised to formal verification and actually strong mathematical proof skills to be a real software engineer

	▲	fn-mote 4 hours ago \| parent [-]
		… and isn’t the AI is already ahead of 99+% of programmers on that front? I don’t know anything about formal verification myself! But proof? I am sure we have seen that AI capabilities exceed humans on that front.

▲

biztos 4 hours ago | parent | prev | next [-]

Alas, I think we (collectively) either are, or will be soon. There will be people who keep 100% knowledge of the code in their projects, but I don't think there will be any monetary reward for that, nor reputational outside of their own niche. And I say that from a position of really wanting to be wrong about it.

I recently started using Claude to write an app. I was going to write it by hand but was having trouble getting motivated, and I knew I had to "up my game" in the vibecodery anyway. So far it's been a lot of back and forth, I keep the leash pretty short because I don't want The Claude AI you see everywhere now.

But even with good intentions and the short leash, I find myself saying "yeah, whatever, it looks like it did what I told it to do" and not actually reading all the code. Some yes, all no. And this is for my own project, nobody is my boss here, and it's nothing I couldn't have done by myself.

Now imagine the incentives for someone who's doing it for money, whose boss is pushing them to do more AI and not less, who probably doesn't actually know how to do all the things the AI is doing for them, who looks around and sees who's getting promoted and who's getting laid off...

And remember that most of us, most of the time, no matter how much we might love computers and software, are that person.

But hey, it could be worse! Have you heard about the Literacy Crisis?

▲

jghn 3 hours ago | parent | next [-]

> but I don't think there will be any monetary reward for that, nor reputational outside of their own niche

I used to think this but have come around to the opposite. I'm already seeing client projects where they went off and LLMd their way forward. A few hundred KLOC and many rounds of bug fix whack-a-mole later, they have something that's a giant house of cards.

Sure, once in this state the LLMs can repair issues at a faster rate than the humans can, but the damage is already done at that point. And it requires a lot of combined human/agentic effort to unfuck it.

▲

yxhuvud 3 hours ago | parent | prev [-]

> 100% knowledge of the code in their projects

That stops working once the code reach a certain size/complexity limit. It is a different limit for different people, but there is a point where there is just too many parts to be possible to fit in a head. There is also a middle stage where everything fits, but can't be accessed all at once but require some time to retrieve specifics when looking at areas not in recent memory. The middle step is more achievable the easier the code is to reason about by black boxing parts.

▲

biztos 2 hours ago | parent [-]

I hear this a lot as a reason to accept that only the robots have read the code: "but it's too much code for one person to understand."

Yes, but it's not ever too much code for a team to understand, or a community. The question is whether you can build a team or community with enough trust and integrity that two things are always true:

1. Alice understands the fluxtron renoberator module she wrote.

2. Bob can also shift his attention there and understand it if necessary, because Alice writes clean code that was reviewed by John and Sally.

You can have Alice, Bob, John and Sally all be robots, and you can decide to trust the robots, but (so far anyway) it's a choice, not an inevitability.

▲

TeMPOraL 2 hours ago | parent [-]

But 1 and 2 were rarely true pre-LLMs, not in any code that has substantial active development. Because 3 months later, the fluxtron renoberator module has been modified, fixed and refactored by 5 other people and looks little like Alice remembers it, and Bob, well, he could never shift attention and actually understand it, nor could anyone else, because that's just a nice story we told ourselves that never worked in practice.

	▲	jghn an hour ago \| parent \| next [-]
		> But 1 and 2 were rarely true pre-LLMs, not in any code that has substantial active development. Every large project I ever worked on worked exactly this way. What do you mean it was rare?
	▲	skydhash an hour ago \| parent \| prev [-]
		> But 1 and 2 were rarely true pre-LLMs, not in any code that has substantial active development. I'm ready to bet that is untrue. Sure, no one can recite the code, but people can quickly scan the module and refresh their memory as well as understanding the new changes, even after a while. If not, collaboration would have been impossible. > Because 3 months later, the fluxtron renoberator module has been modified, fixed and refactored by 5 other people and looks little like Alice remembers it I don't know for which type of projects those things happen, but good design can have a long staying power. Drastic refactoring in a short period is a clear sign of bad engineering. > and Bob, well, he could never shift attention and actually understand it, nor could anyone else, because that's just a nice story we told ourselves that never worked in practice. A lot of OpenSource projects are decades old, and while some core maintainers can stay for the lifetime of the project, new contributors came, understood the code, made changes, then left. Same for hires in companies.

▲

TeMPOraL 2 hours ago | parent | prev [-]

We already were, even before LLMs, we just deluded ourselves we're not.