HN user

tudelo

678 karma

You clicked my name.

distributed something or another engineer at Initech

Posts3
Comments523
View on HN

I find it useful for code reviews (spawn a subagent with minimal/no context to review X commit). Of course, this is more or less a shortcut that could be done with a seperate agent. Another use is multiple reviews at once if tokens are not an issue, with seperate "personas" or focuses. As far as implementation goes I have not seen any major usecase.

A degree is not a bad thing. This forum is pretty biased on startup culture but I bet the vast majority would say its not worth it personally but worth it on a career level. Even then, the space to explore things outside of your immediate interest is invaluable and you WILL make connections beyond what you expect. Good luck in your studies.

I echo the sentiment. Most work is described as basic and unimaginative, yet we still have every large company having outages despite employing "the best". Even worse, they game uptime and outages in a way that mirrors gerrymandering.

For a significantly shorter critque of the book, check out qntm's critique. I mostly agree with qntm assessment. But it's a bit too emotional and personal and doesn't cover the parts i find the most harmful.

This page seems like an actual critique while the blog post doesn't offer much of one, am I missing something?

edit: There is a github linked towards the bottom of the post... full of LLM emoji exclamations.

We deserve better

It is extremely easy to burn tokens if that is required. Explore this codebase. Team x wants y feature, research and generate a full plan. What does feature x in codebase y actually mean? Analyze code coverage in x. Map out code flow and find concurrency bugs in y and on and on...

Oh and my favorite: Use 5 independent subagents to review code change and summarize the findings, and for any finding determine if they are real concerns

Waymo Premier 1 month ago

People will reply to you calling you crazy, but SF/bay is the only place I have ever experienced where many people will literally leave their cars unlocked because a broken window isn't worth the hassle. Yes, locking your parked car is a hazard here... and the reason is obvious.

Mythical Man Month 2 months ago

Most of my work has been in core infra at large companies. Having the code written faster does not change rollout velocity all that much... It does help with signals and idiot proofing on bugs but when things break and cost real (very real) dollars AI is not an explanation. In that instance, its not even close. Development might be 10-20 percent of the actual work to get a change out.

I seriously doubt it. Degradation would be in some part related to the conditions the painting was held in, which would be nearly impossible to backtrack outside of one-off case studies. Imagine a painting that was stuck in a room full of smoke -- or was put on some less than good backing paper/framing.

There has been some research on what causes degradation on paper/pigment but as far as I know much of it ends up as a mystery, a fact of time...

The only counter I have to this is that there are some workflows that have test environments, everything can't or shouldn't just run locally. Sometimes these test take time, and instead of babysitting the model to write code and run the build+deploy+test manually, you can send it off to work until the kinks are worked out.

Add to that I have worked on many projects that take more than 20 minutes to fully build and run tests... unfortunately. And I would consider that part of the job of implementing a feature, and to reduce cycles I have to take.

After the "green" signal I will manually review or send off some secondary reviews in other models. Is it wasteful? Probably. But its pretty damn fun (as long as I ignore the elephant in the room.)

First off, appreciate you sharing your perspective. I just have a few questions.

I've gone back to managing the context window in Emacs because I can't be bothered to learn how to deal with another model family that will be thrown out in six months.

Can you expand more on what you mean by that? I'm a bit of a noob on llm enabled dev work. Do you mean that you will kick off new sessions and provide a context that you manage yourself instead of relying on a longer running session to keep relevant information?

Unironically learning vim or Emacs and the standard Unix code tools is still the best thing you can do to level up your llm usage.

I appreciate your insight but I'm failing to understand how exactly knowing these tools increases performance of llms. Is it because you can more precisely direct them via prompts?

I am rather positive that if you were sat down in a room and couldn't leave unless you did some mildly complicated long division, you would succeed. Just because it isn't a natural thing anymore and you have not done the drills in decades doesn't mean the knowledge is completely lost.

Alerting has to be a constant iterative process. Some things should be nice to know, and some things should be "halt what you are doing and investigate". The latter needs to really be decided based on what your SLI/SLAs have been defined as, and need to be high quality indicators. Whenever one of the halt-and-do things alerts start to be less high signal they should be downgraded or thresholds should be increased. Like I said, an iterative process. When you are talking about a system owned by a team there should be some occasional semi-formal review of current alerting practices and when someone is on-call and notices flaky/bad alerting they should spend time tweaking/fixing so the next person doesn't have the same churn.

There isn't a simple way but having some tooling to go from alert -> relevant dashboards -> remediation steps can help cut down on the process... it takes a lot of time investment to make these things work in a way that allows you to save time and not spend more time solving issues. FWIW I think developers need to be deeply involved in this process and basically own it. Static thresholds usually would just be a warning to look at later, you want more service level indicators. For example if you have a streaming system you probably want to know if one of your consumers are stuck or behind by a certain amount, and also if there is any measurable data loss. If you have automated pushes, you would probably want alerting for a push that is x amount of time stale. For rpc type systems you would want some recurrent health checks that might warn on cpu/etc but put higher severity alerting on whether or not responses are correct and as expected or not happening at all.

As a solo dev it might be easier just to do the troubleshooting process every time, but as a team grows it becomes a huge time sink and troubleshooting production issues is stressful, so the goal is to make it as easy as possible. Especially if downtime == $$.

I don't have good recommendations for tooling because I have used mostly internal tools but generally this is my experience.

Quitting nicotine is absurdly overblown. I'm sure me saying this will annoy somebody, but I think it's much more of a habit than a physical addiction and people hide behind the physical addiction as an excuse. Maybe if you smoke a pack a day it is a different beast but daily smoking is really not hard to kick.

If you live in the USA you should be able to order online and then go in person to like a labcorp or whatever. If you ever got a drug test for a job, thats the sort of place that usually does it. I think some states you may need a referral but most you do not. For a hormone related test covering testosterone and other factors it is going to cost >100 dollars.

And how much money might have been saved not having some of that information available later... because that is totally a good reason to burn history.