21–30 of 125 posts
This would be fine if LLMs had a dedicated language or a well-tuned abstraction that suited their abilities well. Right now we are trying to fit our square languages into the LLM's round hole.
I think the main issue with this approach is that your solution space eventually narrows. You go from formulating unique solutions to flagging things that look wrong and then just picking an alternative LLM generated one. I’ve noticed this recently as all my side project work is being done by hand. If I do ask an LLM another question about something small it will offer solutions but doesn’t offer the solution I think…
I think the main issue with this approach is that your solution space eventually narrows. You go from formulating unique solutions to flagging things that look wrong and then just picking an alternative LLM generated one. I’ve noticed this recently as all my side project work is being done by hand. If I do ask an LLM another question about something small it will offer solutions but doesn’t offer the solution I think…
This is my experience as well, and I've been using Claude Code a lot.
Extremely impressive tools, but they're like fast food. They will solve your immediate problems quickly and cheaply, but you're going to have issues on the long term if that's all you use.
I think the main issue with this approach is that your solution space eventually narrows. You go from formulating unique solutions to flagging things that look wrong and then just picking an alternative LLM generated one. I’ve noticed this recently as all my side project work is being done by hand. If I do ask an LLM another question about something small it will offer solutions but doesn’t offer the solution I think…
> Slowly your brain just gets trained to mid thinking like an LLM Regression to the mean. I am doing a lot of the code reviews on my team and I can see that LLMs have a hard time with OOP (or are perhaps specifically guided to avoid) and writes a lot of `private static` utility functions. A lot of duplicated small utilities that can end up becoming a maintenance nightmare should the behavior need to be normalized/fix…
Feels AI-written as well and a recycling of 1000 versions of this point.
It’s unfortunate because many of us are going “full AI” when it comes to coding. And there are some true gives and takes that are interesting to explore.
Sadly, this piece reads like pure hype.
But the question is, will this atrophy our ability to write and understand code? Is reviewing enough? Won't we inevitably get lazy and stop reading enough code? Reading always was a worse way to learn than doing. When we stop doing, we will have to triple our reading (if that's even enough), but will we do that or just trust the agents more and more?
I wonder if people thought something similar when moving from writing low level machine code by hand to high-level languages. No one looks at the actual machine instructions anymore! Will our ability to understand low level instructions atrophy?
I think the main issue with this approach is that your solution space eventually narrows. You go from formulating unique solutions to flagging things that look wrong and then just picking an alternative LLM generated one. I’ve noticed this recently as all my side project work is being done by hand. If I do ask an LLM another question about something small it will offer solutions but doesn’t offer the solution I think…
I agree this is a problem too, but I suspect mostly for novel(ish) software problems. For me, LLMs have expanded the solution space, because, while I used to be decent with SQL in Postgres, now I'm operating on a whole new level—the LLM's ability to make sense of Postgres' full suite of options, and the performance implications of the queries, is far beyond what I could have accomplished.
I've been working with Apache AGE (openCypher in Postgres) recently and found that left to its own device, the agent wrote terribly inefficient queries, even when given a test harness and instructions to examine the result of the query plan.
It just didn't seem to understand the graph traversal, even when given the graph schema and small snippets.
I ended up hand-writing the structural "skeleton" of the main query that I performance tuned to a certain extent and then handed it over to Codex to finish off. Once it had this skeleton to start from, it was able to do a much, much better job of writing this query.