Hacker News Reader

Comment by indymike | Hacker News Reader

A long time ago a mentor of mine said,

"In tech, often an expert is someone that know one or two things more than everyone else. When things are new, sometimes that's all it takes."

It's no surprise it's just prompt engineering. Every new tech goes that way - mainly because innovation is often adding one or two things more the the existing stack.

View on HN

I remember being told that the secret of good consultancy is knowing what to read on your way to the meeting

100% based. Some of the best meetings and demos I've ever ran in my consulting era were done on prep I did maybe 30 minutes before! Ironically, in many cases, the more prep I did, the worse the outcome was!

very true. and these days take a lot less effort than before getting llms to summarize shit which is one task they inarguably shine on

They make too many mistakes for me to rely on their summaries for consulting. Repeating one of those is a great way to embarrass yourself in front of a client and damage your reputation

I don't trust LLMs or "deep research" for any serious analysis. I use them for guidance (when I do use them) but not for the final product. Too many words with too many landmines (mistakes) hidden within. Also, distillation and inference via human brain is much more environmentally-friendly than sacrificing fleets of GPUs while only being just a tad bit more work.

It’s easy to underestimate the amount of testing “just” prompt/context engineering takes to get above average results.

And then you need to see what variations work best with different models.

My POCs for personal AI projects take time to get this right. It’s not like the API calls are the hard portion of the software.

I'm always more interested in the 'less is more' strategy, taking things away from the already hyper-complicated stack, reviewing first principles and simplifying for the same effectiveness. This is ever more rare.

I think this sense of “less is more” roughly means refactoring? I think the reason these go south so often is because we’re likely moving complexity around rather than removing it. Removing a layer from the stack means making a different layer more complex to take over for it.

Generally that seems to be true u less we're talking about removing cruft that wasn't needed.

Yearly front-end rewrites are quite the joke, but they also reveal that the team didn't really get the underlying assumptions correctly.

Or maybe they just really wanted to try Redux/Zustand/Jotai/the cool new router and ended up making a mess that will need cleaning next year.

Reply on news.ycombinator.com