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.
We should be more tired than the model
71–80 of 168 posts
Re: We should be more tired than the model
#72The 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
#73Earlier 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…
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
#74I 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.
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.
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
#76I 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.
Re: We should be more tired than the model
#77We 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
#78I 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…
> 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
#79Earlier 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…
Re: We should be more tired than the model
#80https://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.