It's very important to understand what's happening, sure. Blindly shipping AI-produced code without understanding is just irresponsible. But how does writing code helps with that? Reading helps a lot, but writing just slows things down in my experience so far.
Hard agree on this. I feel like it's pretty normal, but I struggle with retaining information by just reading. I really need the manual typing step to cement the knowledge.
I'll push back against this slightly: learning what good code is requires debugging bad code, whether by way of a symbolic debugger or judicious use of printf() or breaking an algorithm down into its steps so that you can figure out its asymptotic behaviors.
I harped on checking someone's ability to debug code back when I interviewed candidates, in part because I found that people who could debug effectively could also sniff out bad code. It was something of a bonus that I also happened to select for candidates who could explain their debugging strategies and what that meant for the software they were working on.
It's kind of the same distinction between backups and restores, wherein the restores are what's important, but they're impossible without the backups to restore from.
One of the first things I do in any new-to-me project is set breakpoints in the integration tests and start stepping through the code so that I can establish some mental context. However, if there aren't integration tests, I begin writing them so that I can walk around with my debugger.
LLMs will make tradeoffs without consulting you. This is sometimes a feature and often a bug. Many times a decision made up front can have non obvious implications down the line. This is one of the biggest values I bring to be table as a more experienced swe.
I think if I fully understand everything the agent is going to do and trivially verify the output quality, LLMs are a win. For one off prototypes, the same is true. For software which is unique, complex, and performing a task which has not been fully specified I find myself needing to drop into my editor more and more.
Recently I've been moved to a research focused team and I really need to have proof that something is happening. I've had Claude Opus 5 gaslight me by telling me it did something and when I read the code it obviously did not. This happens more and more with my tasks that are kind of complex.
I've found a lot of the claims by AI people have been 6mo - 2 years "ahead" of my experience. I think we are now in an era where harness engineering is highly valuable (making a test, looping an agent, manually annealing with new ideas) but the claims that no one writes code manually seems like it may not be fully there for all code.
I'd love to see open source win, for the reasons the article talks about and others, but so far I'm not convinced this is actually happening, unfortunately.
To me, literally writing code by hand instead of letting AI do it feels like digging a foundation pit with a shovel instead of letting an excavator do it. Sure it can be done but much slower and the benefits are questionable. But curious if you have reasons to believe otherwise?
Every excavator crew I've seen has a shovel on the truck. They sometimes pull it out of the truck and use it. Most of the time though you can get the excavator there and get the job done faster than any hand work.
The most common use for a shovel seems to be "this is as close as I dare get to the wire we know is around here - scrape the dirt away until you find it and then I'll dig the rest out."
It's not the same example, the excavator is driven by a human being, it's a tool (in coding world the same as using an high level programming language instead of writing bits into the computer memory).
The LLM *may* be used as a mere tool, that is something you ask question time to time, but shouldn't be the thing that makes the work that you should do. Because if we arrive at this point (hopefully never) at that point the CEO of the tech companies may as well say, why we still need developers? Let's fire all of them.
Fortunately they did not, because there is STILL VALUE in writing code by hand, understanding what it happens, what the code will do, etc. I hope this will not be a lost skill, or well, if it does good for me, because the same as nowadays things being able to repair electronic devices makes a ton of money (I've considered opening a repair shop) because there is no one still doing it, will do programmers that well, know how to program.
Yes, LLM is a tool. And CEOs of the tech companies are retaining developers not because there is value in writing code by hand, it's because developers can use that tool effectively and responsibly: they can tell bad code from good code, they design the solution, let AI do the hard boring work of coding it out, then these developers check its output, test it, also they can be creative and e.g. ask LLM to review LLM's output, etc etc.
But the need to manually type stuff out arises very infrequently in my experience. It happens but it's an exception, not the rule.
If your work is analogous to digging a foundation pit or something like framing up homes in a development, that makes a lot of sense. But that's not the only kind of work many of us do, and analogies to things like finish carpentry, functional sculpture, or fine furniture are more applicable. Hand craft doesn't always make a difference, but there's plenty of places where it does.
Plus, for a lot of people with fluency and experience, it's simply more fun/natural and not meaningfully less productive.
Genuine question: do you feel this disparity despite being diligent and checking the LLM's output, or is that not factored in?
It's also been my experience that generating an entire app/portion of code can be much easier by typing out a relatively concise prompt, but this only applies if it's the kind of code I'm
1) free from having to verify afterwards,
2) not having to fight with the LLM to get right, or
3) is coming from someone else in the form of a PR that may/may not have been checked by them first.
Having to deal with these cases has sometimes been the equivalent of using a spoon to dig a foundation, at least in my experience.
Of course checking the LLM's output and testing it and iterating on it is factored in. And yeah that verification and testing and iteration where most of the time goes, and still it ends up being significantly faster than typing everything manually, and the end result quality is often higher I believe.
To avoid fighting with the LLM to get right, it's useful to first come up with the architecture manually, run it by the LLM first (without writing any code - just talking to it, asking it to find flaws in your architecture), and once both you and LLM are happy with the plan, fire it to execute. This step removes a lot of friction (but not all of it - later iterations are still almost always necessary)
Re: the date/time format, I was thinking about implementing support for an option like timefmt, so you'd be able to do :set timefmt=2006-01-02T15:04:05Z07:00 , but postponed for now.
That's not hard to implement, however to make it persistent requires implementing some config / scriptability, which is a whole other thing and requires more thought.
Re: runit, I never tested it, but after looking around briefly, it sounds like there is no unified log file, and not even unified log format? I mean it's possible to make it work, treating every log file as a separate logstream, but I've no idea what these logs look like and whether supporting the formats would be easy.
I think everything is in /var/log/socklog/everything/current, so this could be considered united.
Before you add the timefmt, it may be better to add a configuration file if one does not already exist, but it seems like it does? You already have ~/.config/nerdlog/logstreams.yaml, so might as well have config.yaml?
If so, then yeah it's totally doable to make this format supported.
Re: config.yaml, yeah I thought of that, but in the long term I rather wanted it to be nerdlogrc.lua, so a Lua script which nerdlog executes on startup. Similar to vim (or rather, more like neovim in this case since it's Lua). Certainly having config.yaml is easier to implement, but in the longer term it may make things more confusing if we also introduce the Lua scripting.
I don't think there's anything wrong with this format, it looks good. The most important thing for nerdlog is that all components of the timestamp must be at the fixed offsets from the beginning of each line. So I believe it can be implemented, I can look at it on the weekend. Feel free to create an issue on Github (I won't be able to test it for real, so would need your help with that)
Thank you! :(. It is also referred to as wristdrop.
> If you sleep in a position that causes radial nerve compression, you may wake up experiencing numbness and tingling along the back of your arm, forearm, and hand. With more severe compression, you may also experience “wrist drop”. With wrist drop, your wrist becomes limp, and is unable to extend up.
This is what happened. It happened to me before 2 times, but this time it was only about 30 mins long compression so it is not THAT severe as it was the previous 2 times.
The reason I expanded on it is that just mere 30 minutes of sleeping on your arm may damage the nerves which results in radial nerve palsy. I would have never imagined it would happen to me, heck, I had no idea it was a thing. I had limp arms before from compression but that was related to only blood circulation, not nerve damage.
Radial nerve palsy is a nightmare for programmers. The first one was so severe that I lost my muscle memory, meaning I could not access some of my accounts.
Treatment is rest, selective electrical stimulation, and B1-B6-B12 combination, ideally injected IM. The faster the better. The first incident took months to recover, this one may only last 3 weeks.
I only had the blood circulation issues from compression during sleeping, and also had no idea until today that the nerve damage like that is possible. I wonder how could it be prevented, if it can.
I seriously hope I won't have to deal with it, but thanks for expanding on it and the treatment.
Thanks. And no, as of today, there's no way to define a group like that. Might be a viable idea though.
However, before we go there, I want to double check that we're on the same page: this `log_files` field specifies only files _in the same logstream_; meaning, these files need to have consecutive logs. So for example, it can be ["/var/log/syslog", "/var/log/syslog.1"], or it can be ["/var/log/auth.log", "/var/log/auth.log.1"], but it can NOT be something like ["/var/log/syslog", "/var/log/auth.log"].
At the very grave risk of scope creep, I'll point out that the GP's yaml is very close to an Ansible inventory file so rather than just making up a new structure one could leverage any existing muscle memory (and create helpful defaults for folks who have not yet seen Ansible but have seen your tool)
That first "children" key is because in ansible's world one can have "vars" and "hosts" that exist at the very top, too; the top-level "vars" would propagate down to all hosts which one can view as "not necessary" in the GP's example, or "useful" if those files are always the same for every single host in the whole collection. Same-same for the "user:" but I wasn't trying to get bogged down in the DRY for this exercise
Yeah it would be great, and I do want to support it, especially if the demand is popular. In fact, even if you ungzip them manually, as of today nerdlog doesn't support more than 2 files in a logstream, which needs to be fixed first.
Specifically about supporting gzipped logs though, the UX I'm thinking about is like this: if the requested time range goes beyond the earliest available ungzipped file, then warn the user that we'll have to ungzip the next file (that warning can be turned off in options though, but by default I don't want to just ungzip it silently, because it can consume a signficant amount of disk space). So if the user agrees, nerdlog ungzips it and places somewhere under tmp. It'll never delete it manually though, relying on the regular OS means of cleaning up /tmp, and will keep using it as long as it's available.
reply