skydhash

The thing you’re forgot to mention is that the trust in the layers below your code is not blind. Sure you treat it as axiomatic foundation. But when something breaks and you’re sure it’s not about your code, then you can investigate the actual part that is wrong in that foundation.

Once that’s done, there’s a matter of accountability where you can report the issue to the people responsible for that. Then because they know their own code they can repeat what you did and try to find where things went wrong.

That chain of accountability is the main issue there. We still have tower of abstraction, but no one knows about their layers. Accountability is lost and with it the trust is gone.

I never care about code, whether you wrote the majority of it or it’s just a glue that hold several library. What I care about is that the semantics of that module that I interact or build upon can be trusted, and when something wrong is an accident and not a daily event.

Even when you’re writing an application and not a library or a platform, you’re not free to write whatever. Your users depends on you, and themselves may have clients that depends on them. Being cavalier about what you write is just recklessness and in any other (real in some countries) type of engineering, it would be labelled as malpractice.

As you're being very vague, I write more about my opinion, which is based on a guess of what your approach. Basically the Q of P imply Q where P is the guess (and P is the thing you're being vague). I'd like if you can prove that either P is not valid or that there's a different Q that exists.

  Axiom: A software is the recipe for some process. The code is the formal version where everything is exhaustively specified.
  P: Not thinking about the code
  Q:  means you’ve stopped thinking about the software somewhere and no longer can say if it’s ok or not.

To further go with my point, it's like explaining how to make a cake and you said that instead of a recipe, it's fine to provide just the name of the ingredients and a general instruction like: mix everything together and put it in the oven.

> I ultimately think learning how other people structure programs is an enriching task

Learning from others is great. But there should be actually something to learn. When someone says

  so long as you're not writing the code or specifying exactly how it should work.

It means they’re not creating software. They’re just playing with randomly generating something.

A software is the recipe for some process. The code is the formal version where everything is exhaustively specified. Not thinking about the code means you’ve stopped thinking about the software somewhere and no longer can say if it’s ok or not.

> For me typing out code was always the annoying part. The fun comes from fixing problems, optimizing for speed, making the UX flow better and visuals look nice, all things that are on the level of software not code.

This always read like

  Writing sentences was the annoying part. The fun come from sharing ideas, optimizing for brevity, making the rhythm flow better and words more impactful, all things that are on the level of communication, and not grammar.

Then you start wondering about the actual level of education of the person and their claims about writing a nice novel.

Code is formal writing. Expressing an idea in such formal forms means you have thought exhaustively about the evolution of the algorithm/process. If you’ve not done that, you can’t guarantee the correctness of that algorithm/process. Is it just toying around with an idea of software?

> you could even design a program down to the level of what each function does, and still only be doing 'architecture', not coding, so long as you're not writing the code or specifying exactly how it should work.

So it all wishes and prayers? no wonder software quality is down.

> The clear specifications, reasonable timelines, and enough technical freedom, let you focus on clean, secure, resilient architectures.

The nicest thing was when you nailed down the architecture and then you are mostly twiddling your thumbs while waiting for the PM guys to have the next feature idea. Maintenance and bug fixing is a breeze.

> It's funny how AI has suddenly caused this great awakening in developers/mathematicians: that building stuff or working on purely technical stuff wasn't their actual value, but rather "taste", "understanding", "deciding what to or not to build" etc

Anyone that has worked in an enterprise context knows this. You spend more time saying no and finding justifications than in the editor.

> the value is not in the code (AI can code better than me at this point), nor even in the software architecture (AI is just getting to the point where it will get better than me). It's in deciding what to build and what not to build, defining the overall character and vision of the product,

Defining what to build in enough details is how you get the business logic nailed down (aka essential complexity, aka the domain in DDD). Code is just formal writing and architecture is there for maintenance (a program can be in a single file).

Sure there are accidental complexity like the intricacies of the tech, but those are actually explained very well in the docs.

> They are typically the inputs that matter, and if chosen carefully then they cover all interesting/relevant inputs from the vast space.

The thing is you can have code that passes the tests, but are wrong for the general cases. With manual coding, you will have the knowledge that the code is about right, then add test cases to precisely check that intuition.

Like being aware that you used a linear function so as soon as 2 points in the test are ok, the code is right. But if you don’t read the code and have not noticed the quadratic function, your test cases will pass while the code is incorrect.

> If you are looking to think critically, it can be an absolutely fantastic partner in that endeavor.

Joining “thinking critically” and a tool that has no truth basis is concerning. You may as well put numbers inside a raffle box and just take one out instead of using a calculator.

There’s no definition of correct that LLM tooling enforces, so how can it be a partner in thinking?

That’s the main issue with slop coding. It would be way more useful to send pseudocode out if you can. Logical semantic is always independent of programming syntax. No need to generate code.

> we have companies like VW, Microsoft and other craps who are constantly going downhill because there's no person behind the products.

I wouldn't mind if they accepted they are building utilities so that there's no need to reinvent the wheels every quarter. Windows 7 was pretty much done. Just add small amount of features (like wsl) over time, but they had to butcher it to add metro. It's like reinventing pry bars and concrete blocks.

> You'll want to test the hell out of the resulting code, not only to catch flaws in the prompt but also those introduced by the LLM.

Imagine worrying about gcc or the python interpreter that much. No wonder they use the label "reverse centaur" for LLM usage. You must think carefully before coming up with a prompt, then review the code carefully for correctness. Double the stress for no reason. Or is it just going with the vibes and slinging slop?

> tech that approaches new change with curiosity rather than pseudo-religious turning away will win out because of the type of people who are building the former

Why not

  tech that approaches new change with religious recklessness rather than critical thinking will lose out because of users that are tired of regressions and breakages.

Two of the things I like about the scientific community is the lectures/conference and the sharing of ideas through papers. I’m nowhere near that level and have to wait for those ideas to trickle down into textbooks. So maybe I’m learning stuff that have been discovered decades ago, but it’s still useful on a daily basis.

> The result may be impressive, but if the only beings that can move math forward in future are machines grinding away on billions of scenarios that no human would have the patience to undertake

Seems like the same thing as neural networks. You have something like a few thousand parameters for computer that works well, but no underlying algorithms and formulas, like the shaders.

> perhaps code becomes just another disposable artifact just like compiler-generated machine code, so understanding or maintaining it will be unnecessary.

The compiler development teams make sure that the output of the compiler is correct according to the source code input, preserving semantics and issuing errors for incorrect statements.

Who is doing that for LLM prompts?

> You can pin down existing expected behavior pretty well with automated test

Test cases are sample based, they do not take care of the whole range of input and output. Type checking in the other hand are set based and sometimes the types are too coarse. In both instances, you need to carefully choose your axiomatic foundation, and if you can do that, that means you’re already aware of both programs and solution. As defining the problem is a major step in problem solving.

> Indeed. Though I don't see the connection to my point.

A lot of AI proponents are touting the tools as better hammers while purposely not saying anything about the house. You need to show how it can help with building a new house and not gush that it’s a new shape, different from all the other hammers in history.

So the focus on line of codes, number of PRs, all the harness talks,… is worth nothing if better software can’t be built.

> The key question is: Do we want (desire or require) humans to understand the implementation?

Understanding the implementation is not the root cause here. The actual issue is that all software are built for a particular needs which is human related. In most software, the cost mostly decays to a constant value unless that need has changed or an external event has occurred.

Embracing AI fully is keeping the software in constant flux as it can’t guarantee it will actually follow the requirements and the platform specs. Any prompt has a non zero chance to introduce regressions and breaking changes, disrupting the workflow of the users.

The tools to write the code does not matter to the user just like the hammer does not matter to the person that needs a home. But if your tools results in a badly constructed house that always needs repair and what not, expect complaints.

> The idea that C is a smol language that can be completely understood by one person is one of those myths that need to be put to bed

You don’t need to understand the language completely. You only need to understand the general semantics and refer to the standard and docs to get the semantics down. That’s what they’re here for.

> AI may not be deterministic, but on small to medium-sized tasks it produces more correct code, more reliably, faster than a human developer does. By any objective measure, not adopting it is professional irresponsibility.

How do you define correctness for any given task? If you know the correct logical process for any given process, writing it in code is just a matter of typing. The issue is that the human author, even when assisted by AI tools, does not know what is the correct algorithm for the task. In most cases, the output is probable code, not correct code.

Very much this. Experimentation and careful usage is ok, but we’ve all seen that is pretty much dwarfed by blind slop generation.

> I would very much challenge this.[…]. You can't refine a concept you don't see. It's just that simple. We all like to think we can "know in advance" but we cannot. Time and time again we are shown to be shortsighted, ignorant and too lazy to have figured it out beforehand

People do it all the time by breaking doing the problem. No one wakes up one day and say let’s build Excel or Figma and start coding or writing specs. There are sketches, libraries research, algorithms exploration,… Then all this knowledge will be assembled incrementally. If you got the foundation right, you can coast for a long time as reality is not that volatile.

In the process of building a car, you start with a skateboard (or a cart), because the foundational problem is transport between A and B. You don’t start with building a steering wheel.

> It's not just us, everyone has trouble seeing ahead. We need to see the pieces moving and I assure you the clankers get pieces moving.

Emacs, TCP, Unix are around 50 years old. Vim and Windows NT, 30 years old. You can find several example of software and technologies that get the foundation right in their design and then start doing incremental improvement. That is what happens when you solve problems and not just throwing things at walls to see what sticks.

I have a single home server (debian on an old mac mini) and this thing is like my router. Power on and just wait. Jellyfin and other stuff are taken care off by apt upgrade. I don’t usually bother upgrading the others unless they fail due to dependency updates (which only happened once).

> What happens then is engineers scramble, gather their thoughts, present their ideas to the pointy-haired-boss and inquire about the context, the Why, the desired end state, the planning, etc. Given that "programming" is slow, extraordinarily costly and error-prone we have to carefully manage this. We create processes, systems of accountability and governance

That is when you go and create a whole politically motivated circus. Instead such ideas could have been coded and deployed in a single day. The actual discussion are not really about the tech, they are mostly about business needs and constraints.

The technologies are technically equivalent, but there are different tradeoffs between them. Most of engineering is finding the best set to help the business.

But it seems that a lot of people can’t bother refining their ideas conceptually. Or trying to solve the essential needs of their users. It’s like some kind of ADHD where they want “something” now, whatever the thing is.

> I was telling them that the same way managers give them vague instructions and they turn out with code, managers could give LLMs vague instructions and they output code.

I look at those kind of statements and wonder if there’s any kind of programming experience behind them. Managers give vague instructions because they have vague ideas and evaluate implementations vaguely. The people closest to the implementation are the users and the developers. The former needing the help of computers and the latter making the computer able to help the users. The manager is an accidental complexity to the situation.

How does one create a product like SolidWorks, Blender, or Excel? They didn’t came from vague instructions from managers. The users have very specific needs and the developers provide solutions for those needs. Nothing there is vague.

> I'd argue that being slow and using a ton of memory has more to do with (very) poorly optimized websites rather than blaming browsers as a whole.

A web browser is a huge platform. Audio, 2D and 3D graphics, file handling, network requests,... A lot of code while your application needs are tiny. That is wasteful and a security risk.

Aesthetics, usability, and technical flavor are different axes and feel right is a subjective point. And based on anecdata, usability is what actual users want. Web wrapping is mostly an exclusive focus on aesthetics. With native frameworks, you often get very close to "feel right" without much effort.

> Yeah the problem is having to write 5 apps, not the inconsistency.

Isn’t that what abstraction and interface is about? You can write the common business logic and presentation concerns, and then share it across each native implementation.

That is what web wrapping is in truth, but it’s just inneficient because of the huge surface area of web technologies.

I agree with "nothing has changed" in practical terms. If you take a look around most things rely on an undergraduate level of math than whatever is at the frontier. The proofs may be important, but they are really remote to people's lives.

Math and programming languages are formal. Meaning they don't have any ambiguity in them. Every statement is what it is. That means they are very rigid and there's not a lot of variance. Natural languages are more diffuse and a written piece is more the reflection of the author than anything else.

That is why it's so disturbing. After several paragraphs, you realize there's nothing human there even when the actual information is present. People that do create AI piece are OK with it because they already have the context, but for the reader, it's always the uncanny valley.

> Apparently, part of his philosophical thought was that the ultimate goal of mathematics is to reduce (maybe even eliminate) how much thinking we do.

And it has done so. Imagine how much resources we would be spending on trials for any new object if not for the mathematical models of various systems and events that let us simulate timeline with pure logic. And with the invention of the computer, we’ve ridden ourselves of the human effort of manually computing them.

Pure maths and other theoretical sciences are useful because they brought us tools. Like discovering striking two rocks can produce a spark and thus allowing us to control fire. AI discoveries are more like seeing random thunder strikes and hoping some dry tree is now burning somewhere.