I vibe coded my own SQL query tui client mostly for myself, when I wanted vim editing mode, I just asked for it, and it just worked for a huge amount of common vim editing motions/actions. I did have to prompt it to add a few more when things when I noticed they were missing. Sort of makes this kind of stuff trivial. However, coding it yourself is a great mental exercise
Whether code is the bottleneck likely depends on the organization. In mine, code is the bottleneck. AI has pushed it so validation is now the bottleneck. If it is such that the devs are "middlemen" such they can't spec things, then I think whoever can spec things is likely the bottleneck.
I've worked in agtech for the last 20 years supplying CA with various equipment and there's a vast amount of food industry there. So, the unfortunate thing is, kind of need to let capitalism do its job here. Ultimately, there is a lot of opportunity and infrastructure for all kinds of crops. Either people adapt or someone will buy them out. The only time you should really worry is if anyone trys to rezone agricultural land for other purposes.
Same, I've been coding for 40+ years, and other people I know of similar length of time also seem real quick to adopt AI. I'm constantly having to show the young devs how to get the most out of their AI agents and also adapting my workflows regularly as things changes. Weirdly its some of the youngest who are most resistant, I think because they are learning coding skills, and just have got the hang of coding such that they are productive, and AI is coming in and taking that away from them largely, they are still keen to code. While I've enjoyed coding, realistically it's always been the bottleneck in creating software. A lot of the process is about how to effectively manage that bottle neck, now a lot more options are available. Iterating quick, trying different things, experimenting. Much easier to throw something away when you have better ideas.
I've been coding for 25 years now, and it's not that I see AI as evil, but more that it doesn't solve any of my problems or looking back, any problems I had at previous roles.
It's always been someone higher up the ranking wants meetings, training or something dumb because his golf buddy sold him on Kafka support contracts in inappropriate situations, or an architect needs to shoehorn some tech in so they can have it in their designs ready for their next job role. I spend probably more time in meetings than doing coding.
Why can't I have an AI that takes my meetings for me?
I started with x86 assembler and Turbo Pascal (I still remember when I got documentation for Turbo Vision - this was groundbreaking!).
The simple truth is that I had to constantly learn something new and this is how it is in this profession. We’ve been in the trenches and we did it over and over again.
Now I’m using AI full time, doing same thing I always did - shipping products.
Newcomers with first set of skills don’t understand what is meta responsibility in this field - it’s never coding something, it’s shipping products to solve business needs.
As a "young" coder I am hesitant because I don't have decades of skills to fall back on.
It is even more abstraction, even harder to follow the code I'm "writing" with AI.
Also I have a fear that if/when the AI tide recedes, I'll be the one caught with my pants down since I have been forced to vibe code the majority of my career. As opposed to greybeards who can fall back on their decades of knowledge.
You nailed it. Only option is to build skills, preferably on company time. Just remember there's a lot of mediocre devs, and you probably have more time than you think to do things.
The best complement to AI will be a human who is part architect (they know not to build the new system on lovable, and they understand the company's digital assets) and part business analyst (can communicate effectively and tease out and distill requirements from customer team).
That indicates someone who has top notch communication skills and also quite a bit of experience i.e older.
isn't it at risk of any code pathway that somehow allows you exceed a buffer and read memory unbounded? Then a nefarious web page could capture that? That's a huge exposure surface.
I map it on all my computers, works well, if I end up in an environment where I don't have the mapping I just use Ctrl-[ or stretch.
When I end up helping other devs and use their non vim setups...now that really trips me up. Capitals everywhere, random hjkls ... I have to really slow myself down when using a "normal" editor.
One thing I like about some layer of obscurity is not so much anyone directly attacking you, it's someone generically attacking you because you happened to use a common thing that someone finds a security hole with.
I don't think it really matters in terms of their question though, given MySql on the same specs doesn't have the problem and postgres does. Quite clearly it has something to do with indexes and what is the wall postgres is running into that causes the drop off on quite low amounts of rows. If the answer is just get more RAM, it kind of implies postgres is not really that scalable. Especially if the drop off is proportional to the number of rows.
Last time I almost used a hash index in Postgres, I learned it was an incomplete feature and not crash-safe yet. This was v9.3? At that same time, MySQL had them and they were ok to use.
Later that got fixed, but I haven't tried again since, just been using btree because it seemed like Postgres favored that and it has theoretical advantages too.
They are fully stable and perform very well in Postgres today. There are some caveats, but they don't result in any sort of hiccups or unpredictable behavior.
Yeah that's what I've read too. Just haven't gotten around to trying them.
You've probably already read the Postgres docs on hash indexes, but just in case, it says "hash indexes may not be suitable for tables with rapidly increasing number of rows." I agree with the other commenter that it's worth at least trying without them if you haven't already, even though you're already VACUUMing.
On some data, for certain ways of using and querying that data, it makes a lot more sense than a b-tree. When we use hash indices for some of the columns in our test just to see how Postgres will perform, and run our test towards a quarter of a billion rows where Postgres' 32-bit hash indices have a relatively high chance of colliding, querying these hash indices and returning the single requested row is still instantaneous.
I find the people who go "its just statistical" "its just picking the next word" have probably not really understood what the actual tool can do. Ultimately its arguable whether humans are just statistical also, our brains are pattern matching machines. It's just not sensible to boil it down complex behavior to a fundamental building block. It's not hype (though there is hype), vast amounts of people are getting real value out of it. I've been coding 40+ years, it's super obvious to me the utility of AI tools.
I don't think anywhere I said they weren't useful tools; I said that a lot of people fail to recognize the limitations, and that even aside from limitations/utility there is a discussion to be had about broader impact.
LLMs are not hype, but "AI" is. AI is a marketing term, and always has been.
what makes you think that people are failing to recognize the limitations? Seems to me that's the most obvious thing when you try to build things with it.
Have you... talked to people? Like, people generally, not domain experts using these tools to augment their existing process.
Tons of people think AI is significantly more capable than it is. We've known for the better part of a century that generating text that merely pretends competence is enough to convince a significant portion of the population that it is competence.
reply