Live data from Hacker News

We should be more tired than the model

vickiboykis.com

71–80 of 168 posts

Re: We should be more tired than the model

#71
post #28

Earlier quoted context omitted.

That’s only true if companies give some of the productivity gains back to the employee, but most companies don’t do that. They keep the profits purely for themselves. There are some exceptions.

Choosing speed today is going to cost you tomorrow. Leaning on these tools degrades your actual abilities. You are making yourself less valuable to future employers. So while it might be in the best interest of the company to force you to work faster it is in your own best interest to resist that.

What form can that resist realistically take if lots of companies are monitoring your LLM usage, demanding more usage, and fire bottom "performers"?

Re: We should be more tired than the model

#72
I encourage you to crack open a dependency tree for any project and ask: how many of these do I understand? Then open one and ask: do you really understand whats happening? How much of the code there do you even use?

The experience will feel uncannily similar to AI generated code. So treat slop the same way. Give it a good, well tested API, and file an issue or PR when something breaks.

Re: We should be more tired than the model

#73
post #65

Earlier quoted context omitted.

Here's the loop for a successful small refactor (anything beyond a rename that could be handled entirely by an IDE): 1. Find the code you want to change 2. Run the tests to confirm that test coverage is good for the starting point 3. Track down everywhere else that might call or interact with that code 4. Update the tests (red/green TDD) 5. Alter the code 6. Update the things that call the code 7. Run the tests again…

My point is that all these steps can be done very quickly by even a junior developer who knows emacs or their IDE, in a codebase with existing lint/format/test automation, without even taking their hands off the keyboard. You're already in your IDE, you can probably do it just as fast there. I don't see the cost/benefit of spending tokens and hitting a server for this kind of work. I guess the difference may be in pe…

Those 11 steps would probably take me 15 minutes.

There are a lot of small refactorings that I wouldn't consider to be worth 15 minutes of my time, so I wouldn't do them.

Outsourcing those to an agent means I don't have to make that tradeoff, which means I can get better quality code.

But yes, for a lot of my work I'm now a Claude Code / Codex first developer. I run Zed so I can navigate the code and occasionally make small edits.

Re: We should be more tired than the model

#74

I don't know. I find that I'm moving up a level and improving my product-management skills while delegating most of the code to the agents. I'm still very much hands-on with the design and requirements, and I'm asking questions like, "What's our security story for XYZ?", "Are we accounting for colour-blindness?", etc. Not being down in the code allows me to prairie-dog a bit more and see the landscape better.

One thing I've noticed is that LLMs have allowed middle managers trapped inside the role of a developer to finally self actualise.

chef's kiss

Re: We should be more tired than the model

#75

> We should be more tired than the model I understand the rationale behind this, but can't help feeling that this is a downward spiral. The software industry has always been a hard place to build and sustain a career because of the pace of change. With these tools, the pressure to increase output is going to grow, jobs are going to be axed - so software devs need to work harder to stay relevant. Weren't these tools s…

That’s only true if companies give some of the productivity gains back to the employee, but most companies don’t do that. They keep the profits purely for themselves. There are some exceptions.

Of cause there are some who see boost in productivity and other advantages of AI, but I'm questioning the current AI models ability to produce code (and text). If all the promises were true, we'd see an increase in code quality, but we mostly don't. AI tools do help find interesting bugs code bases like Curl, but commercial vendors doesn't seem to be delivering any fast or better than before. In fact some, like Microsoft, seems to produce worse code now.

If there's this huge productivity boost what is it being spend on? I know, many have been laid off, but that's not universally true. So we have a productivity boost that doesn't really deliver anything and overall quality a lot of products/code/writing/communication is going down, yet we spend an ungodly amount of money on datacenters... for what, just spinning the wheels?

Re: We should be more tired than the model

#76
post #46

I don't know. I find that I'm moving up a level and improving my product-management skills while delegating most of the code to the agents. I'm still very much hands-on with the design and requirements, and I'm asking questions like, "What's our security story for XYZ?", "Are we accounting for colour-blindness?", etc. Not being down in the code allows me to prairie-dog a bit more and see the landscape better.

I'm about 50% that way. However when the AI is done coding I then step back and review to find places the code quality is unacceptable. I also have to stop the AI once in a while because it forgets the point and does something stupid. Junior engineer learn, AI does not.

I don't abandon the code to the agent entirely. I have my own... I wouldn't call it a harness as such, but rather a shared Kanban board, and it'll be the subject of a "Show HN" soon. It suffices to say that I define Kanban cards for each feature or bug, and I have clearly defined review points for each card, post-spec and post-code, where I step in. On top of that, after my review, there is an agentic review, and agents can and do catch things that I missed. The quality of the software has improved quite a bit since I instituted that flow.

Re: We should be more tired than the model

#77
The point about the UI affordances strikes me as very relevant. I find that the way I want to use LLMs in coding is not available.

We have chatbots in a sidebar that will just generate code for you or, more helpfully, answer your questions. We also have inline LLM code completion, which I've turned off completely because they're incredibly noisy.

What I want is something between those. My ideal use of LLMs while coding would be, i start writing a function and need to act on some data. I don't know what method to use, maybe I'm in an unfamiliar language/framework and don't know what my options are. I want the AI to explain what methods I can call to do X in this specific place, no more, no less. It would need to know what outcome I want, which would be hard to do without jumping out of the code and typing into the chat, but I basically want it to function like Intellisense on steroids. Something that doesn't break my focus.

Current LLMs are anti-flow. For me, that's poison.

Re: We should be more tired than the model

#78

I clearly identify with the problem the author raises, which is: the bottleneck is understanding. I don't go along with their mitigations though. In programming we have one tool for this: abstraction. Decomposition, pattern recognition, even data structures and algorithms are all down stream of abstraction. Collectively, we've never truly mastered abstraction, but it's what we have and we collectively wield it well e…

The "right" abstraction seems like quite an art. Sometimes it's not obvious, or it takes multiple rounds of exploration and testing (I'm thinking here of the mental shift moving from HTML + JS, via jQuery, Backbone, Knockout and up to React/Vue or Angular). At all points, we thought we had reasonable abstractions for a while. Vue and Svelt, or NextJS, now are so far from the mental model of early 00s "DHTML". And I'm…

>> I’m losing control over the code I write when I work with agentic code generation

> Are you saying we collectively need to get better at abstraction so that LLMs get better at abstraction (either by training, or our prompting), so that their code is easier to read?

No - our current abstraction for coding agents is a loop where we express some freeform specification of a goal, then a sub loop kicks off where an llm takes a stab at what good looks like for the next step (make an edit, search for info, run a command to cause some side effect etc etc), it iterates in this loop and when it's finished its sub loop, it declares end of turn and the loop returns to the user for steering input.

That inner agent loop can make it quite hard to stay in control.

What if instead of only these low level free form prompts we additionally had some higher level primitives to work with?

Re: We should be more tired than the model

#79
post #60

Earlier quoted context omitted.

> Junior engineer learn, AI does not. This is technically true, but lets not act like we haven't seen immense improvement of both models are harnesses for these models in the past years. They may not be learning , but they are getting better

They are getting better at historical data, not at the fundamental issue. As a recent example, I recently had to abandon the multiple LLM reviewer/verifier model I was using because zig 0.16 was released with major changes. I actually reverted back to full self hosted because the foundation models we’re trying too hard to revert to the older versions of the language. It is going to be a balancing act and there is fun…

Question for you, since I also use Zig 0.16: how do you get it to use Zig idioms? I use Kimi 2.6, and I feel like whenever I try to get my agent to write modern Zig based on a C reference it decides to start writing everything in a C style (doesn't use defer, doesn't use opaque enums even when I explicitly tell it to, doesn't use Zig's error unions, swallows errors instead of asserting, and some more). It's quite frustrating, and a lot of catchable errors crop up until I've beat modern practices into it.

Re: We should be more tired than the model

#80

https://web.stanford.edu/class/ee384m/Handouts/HowtoReadPape... I think this is how we should be reading code as well. First understand the top level. Then the next level of detail and so on. I treat my understanding as graph of interconnected black boxes. If I don't understand a particular black box or a node in the graph. I click expand on it, grok the details and then collapse the node. Here's the grokking details…

This kind of structure is also important when writing. You guide the reader through stages of awareness and understanding.

[dead]
Post reply on HN