Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

-​-dangerously-skip-reading-code

olano.dev

Post reply on HN
Print view View original

131–140 of 219 posts

Re: -​-dangerously-skip-reading-code

#131

Post by jelmersnoeck »

> "I'd make a standardized Markdown specification the new unit of knowledge for the software project. ... There would need to be automated pull-request checks verifying not only that tests pass but that code conforms to the spec."

Agree, this is how you make the development loop more deterministic and ultimately autonomous. It's how I've been using coding agents myself for the past few months (by building my own to support this natively [1]).

If you have a spec you approve/agree on, have an agent code against it, and then have a review phase verify the implementation didn't drift from the spec (either by adding or removing features), you get to a position where you can trust the outcome.

There's still a lot to be said about spec definition and what if during implementation gaps are discovered, and that's where HITL comes into play.

[1] https://github.com/jelmersnoeck/forge

Re: -​-dangerously-skip-reading-code

#132

Post by kenhwang »

jimmaswell wrote: post #123
facundo_olano wrote: post #95

Author here. I'm surprised to see this surfacing now. I just wanted to clarify, since apparently the post doesn't do a good job at it, that what I discussed there is not a methodology I advocate for. The point of the post was: ok, since there are organizations mandating to maximize speed by reducing time spent on typing code (or even mandating to maximize agents usage), is there a way we can meet that requirement whi…

> every time I use AI for coding, to some capacity I'm sacrificing system understanding and stability in favor of programming speed. Sure, but couldn't you say the same for letting other people contribute code too? In either case, you make the choice of how deeply you want to review it. You can ask the AI or the human to explain things that aren't clear. For me it's case by case in either scenario. Sometimes it's not…

I always wondered why people don't also ask the AI to generate code comments/documentation, summaries of those documentation, overview of the system, and re-review them all for correctness for the changes they asked the AI to do.

What I've noticed reviewing all my colleagues' AI generated code PRs is: it really is just code, and the rare comment here and there is still added by the human.

We're already trying to light tokens on fire as fast as possible to stay on acceptable required use leaderboards, why not light some more for system understanding and housekeeping.

Re: -​-dangerously-skip-reading-code

#133

Post by tedd4u »

20k wrote: post #38
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…

What we really we need is some kind of more detailed spec language that doesn't have edge cases, where we describe exactly what we expect the generated code to do, and then formally verify that the now generated code matches the input spec requirement. It'd be super helpful to have something more formal with no ambiguity, especially because the english language tends to be pretty ambiguous in general which can result…

Check out Allium, posted here recently.

https://juxt.github.io/allium/

Re: -​-dangerously-skip-reading-code

#134

Post by weird-eye-issue »

kenhwang wrote: post #132
jimmaswell wrote: post #123

Earlier quoted context omitted.

> every time I use AI for coding, to some capacity I'm sacrificing system understanding and stability in favor of programming speed. Sure, but couldn't you say the same for letting other people contribute code too? In either case, you make the choice of how deeply you want to review it. You can ask the AI or the human to explain things that aren't clear. For me it's case by case in either scenario. Sometimes it's not…

I always wondered why people don't also ask the AI to generate code comments/documentation, summaries of those documentation, overview of the system, and re-review them all for correctness for the changes they asked the AI to do. What I've noticed reviewing all my colleagues' AI generated code PRs is: it really is just code, and the rare comment here and there is still added by the human. We're already trying to ligh…

For major new features, I do ask it to do those things. Why is it that you think people don't do that?

Even for most small changes I will ask it to do a simple "production review" then I use my experience and judgment to decide on which items need to actually be addressed or not

Re: -​-dangerously-skip-reading-code

#135

Post by runarberg »

alabut wrote: post #113
iloveoof wrote: post #99

Software engineering has always worked this way, just not to ICs. “The LLMs produce non-deterministic output and generate code much faster than we can read it, so we can’t seriously expect to effectively review, understand, and approve every diff anymore. But that doesn’t necessarily mean we stop being rigorous, it could mean we should move rigor elsewhere.“ Direct reports, when delegated tasks by managers, product n…

Simon Willison made a similar parallel recently: https://simonwillison.net/2026/May/6/vibe-coding-and-agentic... “The thing that really helps me is thinking back to when I’ve worked at larger organizations where I’ve been an engineering manager. Other teams are building software that my team depends on. If another team hands over something and says, “hey, this is the image resize service, here’s how to use it to resi…

Simon Willison’s analogy does not apply unless that other team was immediately fired after they delivered the image resize service, or (more commonly) was done by a one off contractor. The difference is the trust model. We trust that our company has hired a competent team which maintains knowledge of the image resizing service, that they respond to bug reports and feature requests and that they know how to fix and implement those.

Now I have been on HN long enough to know that we used to despise code written by contractors which we now depend on.

Re: -​-dangerously-skip-reading-code

#136

Post by apsurd »

kenhwang wrote: post #132
jimmaswell wrote: post #123

Earlier quoted context omitted.

> every time I use AI for coding, to some capacity I'm sacrificing system understanding and stability in favor of programming speed. Sure, but couldn't you say the same for letting other people contribute code too? In either case, you make the choice of how deeply you want to review it. You can ask the AI or the human to explain things that aren't clear. For me it's case by case in either scenario. Sometimes it's not…

I always wondered why people don't also ask the AI to generate code comments/documentation, summaries of those documentation, overview of the system, and re-review them all for correctness for the changes they asked the AI to do. What I've noticed reviewing all my colleagues' AI generated code PRs is: it really is just code, and the rare comment here and there is still added by the human. We're already trying to ligh…

yes it makes sense that it's AI all the way down, but also the "why not just…" answer is because it's exhausting.

Being reduced to an inconsequential middle manager is more exhausting than being reduced to a code monkey is the hot insight i've been hanging my hat on.

To be clear: This is really horrible in an IC for the paycheck role. I quit my job on principle because of code/token maxing. Very few are in the place to do this. I've been enjoying AI as an independent, but i still mean to fight the good fight for every line engineer.

Re: -​-dangerously-skip-reading-code

#137

Post by theshrike79 »

throwaw12 wrote: post #59

> 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 ad…

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

In the age of AI this is more true than you know. Given a detailed enough spec and test suite you can effectively rewrite any application with any language in a fully automated way.

I've coined that as "Duck coding" :D If it quacks like a duck, walks like a duck and looks like a duck - it's duck enough for as far as the spec is concerned. Does it matter what is inside the duck?

Re: -​-dangerously-skip-reading-code

#138

Post by refactor_master »

throwaw12 wrote: post #59

> 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 ad…

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

The tests, sure. But certainly not the code itself, as that sits far too close to the implementation (i.e. it is the implementation). An almost infinite number of implantations can fulfill “does foo when bar”, so how can we prove that ours is the spec itself?

It’s kind of like a scientist coming up with a hypothesis post-hoc to fit the results of the experiment.

Re: -​-dangerously-skip-reading-code

#139

Post by cpeterso »

kenhwang wrote: post #132
jimmaswell wrote: post #123

Earlier quoted context omitted.

> every time I use AI for coding, to some capacity I'm sacrificing system understanding and stability in favor of programming speed. Sure, but couldn't you say the same for letting other people contribute code too? In either case, you make the choice of how deeply you want to review it. You can ask the AI or the human to explain things that aren't clear. For me it's case by case in either scenario. Sometimes it's not…

I always wondered why people don't also ask the AI to generate code comments/documentation, summaries of those documentation, overview of the system, and re-review them all for correctness for the changes they asked the AI to do. What I've noticed reviewing all my colleagues' AI generated code PRs is: it really is just code, and the rare comment here and there is still added by the human. We're already trying to ligh…

I see people asking LLMs to omit comments, but comments like PDL (Program Design Language) could be helpful for interactive development: ask the LLM to write pseudocode comments, review them, and then ask the LLM to expand them to actual code. People say comments should explain why, not how. That seems useful for both human reviewers and LLMs.

https://en.wikipedia.org/wiki/Program_Design_Language

Re: -​-dangerously-skip-reading-code

#140

Post by Npovview »

teaearlgraycold wrote: post #109
iloveoof wrote: post #99

Software engineering has always worked this way, just not to ICs. “The LLMs produce non-deterministic output and generate code much faster than we can read it, so we can’t seriously expect to effectively review, understand, and approve every diff anymore. But that doesn’t necessarily mean we stop being rigorous, it could mean we should move rigor elsewhere.“ Direct reports, when delegated tasks by managers, product n…

Well yes but if no humans at the company understand the code then no one is truly responsible for it.

what about the artifacts that were supposed to test the correctness of the code? are they passing willy nilly?
Post reply on HN