Hacker News Reader

Comment by __MatrixMan__ | Hacker News Reader

Once you figure out how to get your model to go find the context it needs (for me this usually comes down to really good error messages that feel a bit like a prompt injection attack) and you figure out how to keep the tasks small and uniform-ish such that a passing test for a previous (supervised) task becomes a reason that that output can now be used as context for how to complete the next (unsupervised) task, agents can be pretty darn reliable.

Maybe 50% of the problems we solve are repetitive enough for this to make sense, and 50% of those are unpredictable enough that a model in a loop isn't overkill compared to traditional automation, and 50% of those are too small to be worth investing in the necessary scaffolding. But if you're looking at a problem that's in that magical 12.5%, a properly constrained agent is absolutely the way to go.

View on HN

You should do a video on that, like a live coding session. Not a tutorial, an organic recording of you being a badass context engineer. That would make it easier to get the message across.

Good suggestion, thanks.

I'll likely have to make a "what even is this" video for my coworkers, so maybe the video you're proposing would make a good Part II to that.

Might be tricky to convince my company to bless its release but perhaps with some careful editing...

You could do it on spare time, not using your company's hardware, and work on a public open source repository. This way there's no conflict with potential contracts.

Also, LLMs have been around for a while. Maybe you can just search for someone that did it and share one video that you would endorse as representative of what you believe to be good context engineering. It seems that there should be a lot of those around, lots of people are using this tech, aren't they?

I designed the project around what I can lean on LLMs for, so its not like I can just drop into an existing codebase and make it look like a good idea to let your agent crank while you get coffee. Perhaps not so badass a context engineer after all.

Still the pattern is generalizable enough, so yeah I'll think on ways to bring it to a wider audience.

> its not like I can just drop into an existing codebase

The devil is always in the details. For example, in enterprise teams the time to onboard a new project or a new programmer is often dismissed but actually very important. Serious companies take this matter very seriously. More inexperienced teams often come up with an excuse for a slow onboarding time without realizing it's a proxy metric for quality. If you can't jump in quickly or jump someone else quickly into the productive train, something is wrong.

I think recording yourself doing it might be a worthwhile endeavour, even if you don't release it to a wider audience.

The act of recording yourself and watching it might reveal blind spots that you were not aware while doing it. Perhaps things you think are fast but actually took more time than you imagined.

Also, by giving this advice I can take my personal judgement out of the equation. Now it's you recording and only you watching yourself and judging yourself (which can be very soul crushing, I can tell from experience).

Reply on news.ycombinator.com