[jurschreuder]

I'm not sure AI Agents can already beat the average VIM user.

I use VIM and I get some inspiration from LLMs sometimes, but me and other developers always after some time give up and just quickly do it manually.

AI Agents will just full the code with maaaassive swaths of texts it will just make a project unusable.

We even get paid to turn client's AI LLM Claude sketches into real programs.

[keithnz]

This is not my experience at all, the AI agents are many many many times faster than what I can do. What anyone can do. It's crazy how quick I can create stuff these days.

[gdorsi]

It really depends on what kind and of job you do.

If it's not something very common LLMs could end up generating random code.

Also if you work on something performance critical, you can get inspiration from LLMs, but they often don't write fast code.

[keithnz]

not my experience, they write fast code, and if you ask them to optimize, can pull all kinds of tricks out of the bag. Even with some of the niche stuff I work on, they seem really good.

[mchaver]

Without telling us what kind of code you are talking about it is hard to compare. I would say that is true for CRUD web code because there is so much out there that the LLMs can reference.

[keithnz]

I work on all sorts as we have an IoT product offering.... embedded bare metal systems, web, backend IoT servers, Gateways, APIs, Import/Export Systems, Integrations with Manufacturing systems, accounting systems, Automatic Test Equipment. I've been coding for nearly 50 years now, so pretty experienced. What peoples comments seem to imply to me is that they haven't really gone full agentic coding, where you hone your context, your tools, and how you iterate and test with an AI agent. Where any mistakes an AI makes you make sure it can't do it again, you have it setup so your AI code reviews are honed to focus on the things you care about etc.

[gdorsi]

Software development is a quite vast discipline.

In my experience performance of LLMs can be surprisingly good on things that are not mainstream, like database engineering, and surprisingly bad at mainstream categories approached in an unconventional way.

That said, I'm amazed that you have 50 years of experience and still able to have the mental flexibility to adapt to new development paradigms.

As you imply, this stuff isn't simple to pick up, and is completely different on how we have done our job without AI.

[keithnz]

gdorsi , it's not that hard to swap really, because the goal, designing systems, just got easier. I feel AI lets you be a system engineer way better as you can quickly iterate. I have the same kinds of goals in mind, just can do it a heck of a lot quicker.

[keithnz]

hubertdinsk, can't reply directly... but yes lots of niche things, especially in the embedded side, automatic test side. We have a lot of hardware, we control a lot of things, sense a lot of things. There's nothing inherently complicated about it such that AI can't code, in fact you feed AI technical data sheets its insanely useful when writing code against that hardware. It's going to pick up on all the weird nuances. It's great for protocols, especially proprietary ones. Anything with spec sheets are good.

[hubertdinsk]

so not niche at all. You described a bit of everything.

Niche is more like "ISO26262 compliant, response time under 50ms, measured with a oscilloscope with at least 40MHz bandwidth, failure rate less than 10^-7, proven with maths and soak tests". It gets more niche the closer you get to hardware.

Next word prediction will get you laughed out of the room.

[armchairhacker]

AI can generate code much much faster.

But do you never need a specific change (e.g. bugfix), that even describing in English is slower than just doing it? Especially in vim where editor movements are fast.

[jnpnj]

Anybody using cursor or antigravity ?

I tried them a bit and often they can infer immense amount of ideas from the immediate source context and suggest paragraph patches semantically close to what I had in mind from just one word.

Saying this as a vi/emacs user who liked to automate via macros, snippets, dynamic overlay inserts and what not.. I still enjoy being sharp on a keyboard and navigating source / branches swiftly but LLM can match and go beyond it seems. (not promoting them, feel free to stay in good old vi command sequences if that's fun for you)

[armchairhacker]

I’m using Sweep autocomplete, which is like Cursor’s but in JetBrains, and it’s very good. Most of the time, I start the change and Sweep finishes it. Sometimes for larger changes, it initially has the wrong idea, but as I continue it eventually figures out what I’m doing.

Unfortunately they’re sunsetting it, ironically apparently because people aren’t using it. I think it’s strange this hasn’t been posted to HN. They say they will release an open-source local version; otherwise I’ll have to figure out an alternative, because it really saves time and effort…

[keithnz]

possibly there's cases where maybe you want to change some text or something, but I don't think its faster in vim given you likely don't have that file open, and by the time you get to the file, and location, you could have fixed it with your agent, not only that, you could have generated the test case and then fixed in your agent

[1718627440]

I think you missed the point. It takes more time to write English prose than to open a file and just fix it, so unless the time the LLM needs is somehow negative, it's not going to be faster.

[keithnz]

I didn't miss the point, it just feels like the people saying that really aren't using these tools as it just is not my experience at all. I've been a Vim user for multi decades now. There's just no way, it's far easier to type a prompt except maybe if you know exactly what file and exactly where in the file, you might be able to do it as fast as telling the AI to do it. It's not hard to get a minor fix done with a prompt and doesn't take too much English in my experience.

[skydhash]

Maybe it’s hormones, but time flies when you do edit with Vim or Emacs. It’s like playing on a piano. But using AI is like listening critically to someone playing trying to find mistakes. And that’s boring as hell.

[jakobobobo]

If you ask to do a fix you need to read/verify what is done. If you are confident with your editor you go through long amounts of actions knowing your error rate is low enough to use less visual feedback loops.

I'd be curious how one gets to the error rate where they don't think they need feedback loops. Anyone can learn to touch type because the physics are deterministic and can expand from that to touch edit in something that isn't hopelessly WYSIWYG only.

[zhann_dc]

I'd argue you should be working towards no longer having to do these because agentic systems in place will do it in your stead.

All you need to do now, is sign off the code and adjust the agent so it would do these as you would.

[bandrami]

You're forgetting to count the time you spend deleting the excess stuff

[keithnz]

no... I'm not.

[bandrami]

Then you're forgetting the time your sysadmin spends doing that

[otabdeveloper4]

Note you're replying to a guy who never said anything at all about being "faster".

P.S. Software developers aren't being paid to be "fast". In fact, being "fast" is called "technical debt" and you're usually punished for it as a software developer.

[mvanbaak]

I'm a vim user. for decades. Your post does not align at all with my experience.

If you prompt and hand-hold the LLM it is a big help. Things like boilerplate, basic crud etc etc is something I dont have to worry about anymore. And if I am looking at an unknown codebase or area, the llm can explain things to me, it's the rubber duck that talks back.

I'm not using vim plugins (yet) for LLM, tmux and a couple of panes etc is all I need at the moment.

[cholantesh]

The only thing that I find AI is consistently excellent at is giving me a snippet to do something particularly esoteric in my shell and parsing out errors from a massive logfile that I would probably have taken an order of magnitude longer to find myself.