Knowing what your software does is such a hard problem. Most developers have an idea but if you ask, how are you sure?, the answers reveal how little they know.

Most often we’re satisfied with signals and indicators that it works and we build theories and mental models that use to try to avoid the effort of proving anything.

Worse is what happens when you start using LLM models to generate the code for you. I find you start losing the mental model short-cuts; you start to trick yourself into understanding the code. You understand little.

And what few studies there are of code review suggest that we have very little impact on code quality after reading more than a couple hundred lines of code over an hour.

So the current mental leap is, “the AI is a better programmer than I am.”

I think it’s still worth becoming a better programmer regardless. And there’s no royal road. You just have to write code and struggle with writing bad code.

▲

grvdrm 3 hours ago | parent | next [-]

> how are you sure?

This is not just a software problem. I see it everywhere. Folks in business roles just as much as any other role. There is a surface-level operating framework to get a job done but the why/how is sometimes lost.

I always come back to an example in my past. Somehow automated a report. From Excel to Power BI. Then for months Power BI was wrong. Automation (more code involved for sure) made it run faster but then people forgot about the how - how to check/validate/etc. And since it was code - for many non technical people the whole thing was a lot harder to deal with needing to deep investigate issues.

	▲	ptero 3 hours ago \| parent [-]
		But that is how most of the companies work (and did, for centuries). Very few roles affect critical flight safety, nuclear control or other things that need a bunch of nines for reliability, written and fire-drilled fallbacks, etc. For everything else the general mode is "can we make it work well enough". And when it breaks, well, we will curse and pry it open and either fix or rebuild it. There are many stories of a particular thing that was built long time ago by folks who are long gone and no one knows how it works or even where it physically is. And it works fine; usually better than ensuring complete reliability from the get-go, when it is not clear if it is a long-term core feature or a kludge that will be obsolete soon. My 2c.

▲

whstl 3 hours ago | parent | prev | next [-]

I agree.

But I feel like it's a minority that really know how the software they're writing really works. And it's 10x worse for older legacy software.

Mostly because the people doing it don't care. Not judging, just reporting I guess. I know because I used to work in quite a few companies where the "money maker" app was on maintenance for years and nobody was able to answer questions or didn't even know most corners of it still existed.

This desperation mindset also often correlates with people writing code without care for the next maintainer.

And the scary part is that this also correlates with advocacy for going all-AI.

	▲	cindyllm 2 hours ago \| parent [-]
		[dead]

▲

asdf88990 4 hours ago | parent | prev [-]

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

▲

agentultra 4 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 4 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 3 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 2 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 an hour 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 an hour 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 3 minutes 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 11 minutes 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 an hour ago | parent | prev [-]

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