--dangerously-skip-reading-code • Hacker News Board

Re: --dangerously-skip-reading-code

#51

Post by piokoch » Sat, May 23, 2026, 6:41 PM UTC

ramoz wrote: post #13

> If I had to roll out such a development process today, I’d make a standardized Markdown specification the new unit of knowledge for the software project. Product owners and engineers could initially collaborate on this spec and on test cases to enforce business rules. Those should be checked into the project repositories along with the implementing code. There would need to be automated pull-request checks verifyin…

We've been through that so many times. When UML arrived (and ALM tools suites, IBM was trying to sell it, Borland was trying to sell it, all those fancy and expensive StarTeam, Caliber and Together soft), then BPML and its friends arrived, Business Rule Management System (BRMS), Drools in Java world, etc.

It all failed. For a simple reason, popularized by Joel Spolsky: if you want to create specification that describes precisely what software is doing and how it is doing its job, then, well, you need to write that damn program using MS Word or Markdown, which is neither practical nor easy.

The new buzzword is "spec driven development", maybe it will work this time, but I would not bet on that right now.

BTW: when we will be at this point, it does not make sense anymore to generate code in programming languages we have today, LLM can simply generate binaries or at least some AST that will be directly translated to binary. In this way LISP would, eventually, take over the world!.

Re: --dangerously-skip-reading-code

#52

Post by wizzwizz4 » Sat, May 23, 2026, 6:50 PM UTC

soraminazuki wrote: post #24

wizzwizz4 wrote: post #21

Earlier quoted context omitted.

You're probably thinking of Rice's theorem (a sort of generalised halting problem), but this task is actually way easier than that, since we're not trying to study arbitrary algorithms: we're trying to study the subset of human-comprehensible algorithms. Most of the things we want computers to do are things that, given enough time, someone can write a program to solve: and generally, those programs are not tricksy or…

We can't create an algorithm determining whether a computer program halts or not, but we can write one that checks whether it conforms to natural language specifications much more easily? That makes no sense. There's no exception to the halting problem regarding "human comprehensible" computer programs.

Rice's theorem says that we can't draw a partition between two sets of programs, based on their semantic properties. It says nothing about drawing a partition slightly to one side of the desirable partition, misclassifying some tricksy cases, but correctly classifying all the programs we care about.

Re: --dangerously-skip-reading-code

#53

Post by uptodatenews » Sat, May 23, 2026, 7:00 PM UTC

ramoz wrote: post #13

> If I had to roll out such a development process today, I’d make a standardized Markdown specification the new unit of knowledge for the software project. Product owners and engineers could initially collaborate on this spec and on test cases to enforce business rules. Those should be checked into the project repositories along with the implementing code. There would need to be automated pull-request checks verifyin…

[dead]

Re: --dangerously-skip-reading-code

#54

Post by KaiShips » Sat, May 23, 2026, 7:01 PM UTC

ramoz wrote: post #13

> If I had to roll out such a development process today, I’d make a standardized Markdown specification the new unit of knowledge for the software project. Product owners and engineers could initially collaborate on this spec and on test cases to enforce business rules. Those should be checked into the project repositories along with the implementing code. There would need to be automated pull-request checks verifyin…

[flagged]

Re: --dangerously-skip-reading-code

#55

Post by farmerbb » Sat, May 23, 2026, 7:03 PM UTC

I legit can't tell if this article is satire, or not.

Re: --dangerously-skip-reading-code

#56

Post by retinaros » Sat, May 23, 2026, 7:20 PM UTC

markdown became the language I hate the most thank to LLMs and specs-driven approach. everything feels so dumb right now in agentic coding. looping blindlessly and aimlessly until it compiles then until the playwright server or whatever devtools shows that it somehow works. push the code, have a llm autoreview/autofix,push to prod, run a mythos (perfect name) to identify the bug that opus 4.7 create. loops on loops on loops of some kind of zombie processes running to a "goal" that everyone seems to mystify in talks to just hide the fact that we do nothing anymore. the bottleneck never was code. it was the gate that was keeping away the Elizabeth Holmes and SBF from software engineering and it just opened.

Re: --dangerously-skip-reading-code

#57

Post by Ozzie-D » Sat, May 23, 2026, 7:25 PM UTC

the irony is that AI is making this exact problem worse. ppl are generating entire codebases now without reading any of it -- the flag might as well be the default. the skill thats actually becoming scarce isnt writing code, its reading code you didnt write and knowing if its correct.

Re: --dangerously-skip-reading-code

#58

Post by dasil003 » Sat, May 23, 2026, 7:29 PM UTC

jmull wrote: post #29

The lesson I've learned from our new AI age is how little a large number of people who've worked in software development their entire careers understand software development. I suppose all the money floating around AI helps dummify everything, as people glom on to narratives, regardless of merit, that might position them to partake. What we actually have now is the ability to bang out decent quality code really fast…

Yeah this article is in a real uncanny valley for me where it has some insight, but it also throws out some wild ideas that don't pass the sniff test for me.

To me what AI is doing is changing the economics of human thought, but the change is happening way faster than individuals, let along organizations can absorb the implications. What I've seen is that AI magnifies the judgment of individuals who know how to use it, and so far it's mostly software engineers who have learned to use it most effectively because they are the ones able to develop an intuition about its limitations.

The idea of removing the human from the loop is nonsense. The question is more what loops matter, and how can AI speed them up. For instance, building more prototypes and one-off hacky tools is a great use of vibe coding, changing the core architecture of your critical business apps is not. AI has simultaneously increased my ability to call bullshit, while amplifying the amount of bullshit I have to sift through.

When the dust settles I don't really see that the value or importance of reading code has changed much. The whole reason agentic coding is successful is because code provides a precise specification that is both human and machine readable. The idea that we'll move from code to some new magical form of specification is just recycling the promise of COBOL, visual programming, Microsoft Access, ColdFusion, no-code tools, etc, to simplify programming. But actually the innovations that have moved the state of the art of professional programming forward, are the same ones that make agentic coding successful.

Re: --dangerously-skip-reading-code

#59

Post by throwaw12 » Sat, May 23, 2026, 7:32 PM UTC

> my first bet would be specifications and tests

You are missing another dimension how easy it would be to migrate if adding new feature hits a ceiling and LLM keeps breaking the system.

Imagine all tests are passing and code is confirming the spec, but everything is denormalized because LLM thought this was a nice idea at the beginning since no one mentioned that requirement in the spec. After a while you want to add a feature which requires normalized table and LLM keeps failing, but you also have no idea how this complex system works.

Don't forget that very very detailed spec is actually the code

Re: --dangerously-skip-reading-code

#60

Post by wizzwizz4 » Sat, May 23, 2026, 7:46 PM UTC

soraminazuki wrote: post #32

mjd wrote: post #28

Earlier quoted context omitted.

This sort of theoretical result is not always as clear-cut as you suggest. Computers are finite machines. There is a theorem that although a machine with finite memory can add, multiplication requires unbounded memory. Somehow we muddle along and use computers for multiplication anyway. More to your point there is a whole field of people who write useful programs using languages in which every program must be accompa…

But it's not like these systems make theory go away, they make compromises. So the question is, what's the compromise required for an algorithm that can check the conformance of computer programs to natural language specifications that doesn't involve hoping for the best?

Natural language specifications often aren't specifications at all: interpreting them requires context that is not available to the computer, and often not even available to the specification's authors without further research / decision-making.

LLMs address this problem by just making things up (and they don't do a great job of comprehending the natural language, either), which I think qualifies as "hoping for the best", but I'm not sure there is another way, unless you reframe the problem to allow the algorithm to request the information it's missing.