Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- Where is that quote from, dis you just make it up?
> You can outsource your thinking, but not your understanding. — Sun Tzu
by Crowberry - What's with Claude preferring cursive and italic font in landing page hero sections?
Looks absolutely awful.
by bluerooibos - The gimmicks we come around to justify existing practices being pushed into the industry never stops surprising me.
One would expect the actual answer would be to write the code ourselves.
by pjmlp - Nice idea. I like that it tests whether the person understands the change instead of adding another AI reviewer. We added the tests before we switch to fully agentic AI development using automo - ie we tested every member of staff and now trust them to be the eyes.
Disclosure: I’m building automo.build fully to fix this.
by alexwrich - Have you ever heard the idiom "ambulance at the bottom of the cliff"?by freshnode
- I certainly feel like certain AI coding practices I have leave me with nothing learned in a frustrating way. Sometimes the most effective way to getting what I want is just describing a goal really clearly, and then bashing the AI until it gets there. That bashing process can take a lot of energy and yet I don’t gain useful skills or a “better way” that I would if I was still coding. I generate more training data for BigAI corp, but that’s a slow return cycle.
Not sure if this is the right solution, but I would like to learn/understand/grow more as I pursue reckless efficiency.
by theParadox42 - It’s a neat idea, i think it’ll really take off if you change “before pushing to prod” to “before requesting another human’s time or attention”. If something like this was gatekeeping the “submit PR” and “update PR” buttons it would prevent a lot of waste.by fwlr
- my shortcut to get a similar benefit io to write a quality PR description.
the description should be compact and helpful. describing something complex in a compact and approachable way requires understanding.
the process of writing the description often leads me to understand hidden decisions the LLM made and occasionally uncovers bugs.
my PR descriptions separately answer the following questions:
Why is this change being made? a sentence or two about the problem, objective, etc, and a link to more detail (tickets, docs, etc) if available
What does this change accomplish? typically describes observable changes, requirements, etc. crucially this section avoids describing how the change is implemented.
How does this change accomplish its goal? the answer to this question is "read the code", but the job of a PR description is to provide a quick hand drawn map before dumping the reviewer into the jungle. a good "how" map requires understanding of the jungle, and the new path through it.
by rDr4g0n