Live data from Hacker News

Coding assistants are solving the wrong problem

bicameral-ai.com

131–140 of 151 posts

Re: Coding assistants are solving the wrong problem

#131
post #14

For me, AI is an enabler for things you can't do otherwise (or that would take many weeks of learning). But you still need to know how to do things properly in general, otherwise the results are bad. E.g. I'm a software architect and developer for many years. So I know already how to build software but I'm not familiar with every language or framework. AI enabled me to write other kind of software I never learned or…

> But you still need to know how to do things properly in general, otherwise the results are bad. Even that could use some nuance. I'm generating presentations in interactive JS. If they work, they work - that's the result, and I extremely don't care about the details for this use case. Nobody needs to maintain them, nobody cares about the source. There's no need for "properly" in this case.

Agree. Or internal or personal tooling where it doesn't beg to be perfect and you can (1) verify by observing behavior of the software -- if it works it works, and (2) deal with edge cases as they arise because it's not mission critical.

Re: Coding assistants are solving the wrong problem

#132
One of the things I’ve noticed talking to Claude, is that like, one of the reasons Claude seems so genius is because of it’s ability to keep right up with me, to talk about things I want to talk about that other people may not and follow me down rabbit holes.

And having a person that keeps right up with you makes it feel like they’re very intelligent, because of course they are, they seem like scarily as intelligent as you. Because they’re right next to you, maybe even a little ahead! (I think Travis Kalanick was experiencing this when he was talking about Vibe Physics.)

But the thing is, it was ultimately an extension of your ideas, without your prompts, the ideas don’t exist. It’s very library of babel esque.

And so I wonder if coding assistants have this general problem. If you’re a good developer following good practices, prompting informatively, it’s right next to you.

If you’re not so good and tend to not be able to express yourself clearly or develop solutions that are simple, it’s right there with you.

Re: Coding assistants are solving the wrong problem

#133

Earlier quoted context omitted.

I've had quite a bit of the "tell it to do something in a certain way", it does that at first, then a few messages of corrections and pointers, it forgets that constraint.

> it does that at first, then a few messages of corrections and pointers, it forgets that constraint. Yup, most models suffer from this. Everyone is raving about million tokens context, but none of the models can actually get past 20% of that and still give as high quality responses as the very first message. My whole workflow right now is basically composing prompts out of the agent, let them run with it and if some…

LLMs do a cool parlour trick; all they do is predict “what should the next word be?” But they do it so convincingly that in the right circumstances they seem intelligent. But that’s all it is; a trick. It’s a cool trick, and it has utility, but it’s still just a trick.

All these people thinking that if only we add enough billions of parameters when the LLM is learning and add enough tokens of context, then eventually it’ll actually understand the code and make sensible decisions? These same people perhaps also believe if Penn and Teller cut enough ladies in half on stage they’ll eventually be great doctors.

Re: Coding assistants are solving the wrong problem

#134

Earlier quoted context omitted.

I've had quite a bit of the "tell it to do something in a certain way", it does that at first, then a few messages of corrections and pointers, it forgets that constraint.

> it does that at first, then a few messages of corrections and pointers, it forgets that constraint. Yup, most models suffer from this. Everyone is raving about million tokens context, but none of the models can actually get past 20% of that and still give as high quality responses as the very first message. My whole workflow right now is basically composing prompts out of the agent, let them run with it and if some…

been experimenting with the same flow as well, it is sort of the motivation behind this project - to streamline the generate code -> detect gaps -> update spec -> implement flow.

curious to hear if you are still seeing code degradation over time?

Re: Coding assistants are solving the wrong problem

#135
post #50

I think AI will fail in any organisation where the business process problems are sometimes discuvered during engineering. I use AI quite a lot, I recently had Claude upgrade one of our old services from hubspot api v1 to v3 without basically any human interaction beyond the code review. I had to ask it for two changes I think, but over all I barely got out of my regular work to get it done. I did know exactly what to…

> AI can write the code, but it doesn't refuse to write the code without first being told why it wouldn't be a better idea to… LLMs combine two dangerous traits simultaneously: they are non-critical about suboptimal approaches and they assist unquestioningly. In practice that means doing dumb things a lazy human would refuse because they know better, and then following those rabbit holes until they run out of imagina…

do you think having an MCP that surfaces what the model isnt certain of would alleviate a big part of the issue?

Re: Coding assistants are solving the wrong problem

#136
post #46

Earlier quoted context omitted.

I hear your pushback, but that I think that's his point: Even seasoned coders using plan mode are funneled towards "get the code out" when experience shows that the final code is a tiny part of the overall picture. The entire experience should be reorganized that the code is almost the afterthought, and the requirements, specs, edge cases, tests, etc are the primary part.

This is always been the businessman's dream to write requirements and then coding becomes a mindless work but requirements and specs can never cover every small detail. Code itself is the spec but Business people just dont wanna write it. if you handle all edge cases and limitation in the spec, and then do the same in the code, you are just writing code twice. This also completely ignores the fact that PMs and Busine…

would the ideal scenario be to get business and engineering writing specs together?

Re: Coding assistants are solving the wrong problem

#137
post #23
post #14

For me, AI is an enabler for things you can't do otherwise (or that would take many weeks of learning). But you still need to know how to do things properly in general, otherwise the results are bad. E.g. I'm a software architect and developer for many years. So I know already how to build software but I'm not familiar with every language or framework. AI enabled me to write other kind of software I never learned or…

I'm in the same boat. I've been taking on much more ambitious projects both at work and personally by collaborating with LLMs. There are many tasks that I know I could do myself but would require a ton of trial and error. I've found giving the LLMs the input and output interfaces really help keep them on rails, while still being involved in the overall process without just blindly "vibe coding." Having the AI also he…

How granular do you go with the interfaces? Full function signatures + types, or more like module-level contracts.

wondering what sort of artifacts beyond ADR/natural language prompts help steer LLMs to do the right thing

Re: Coding assistants are solving the wrong problem

#138

Earlier quoted context omitted.

You not only stumble upon a weird bug in your hacky solution that takes engineering weeks to debug, but your interfaces are fragile so feature velocity drops (bugs reproduce and unless you address reproduction rate you end up fixing bugs only) and things are so tightly coupled that every two line change is now multi-week rewrite. Look at e.g. facebook. That site has not shipped a feature in years and every time they…

> You not only stumble upon a weird bug in your hacky solution that takes engineering weeks to debug, but your interfaces are fragile so feature velocity drops (bugs reproduce and unless you address reproduction rate you end up fixing bugs only) and things are so tightly coupled that every two line change is now multi-week rewrite. I don't think you fully grasp the issue you're discussing. Things don't happen in a va…

> Competent engineers understand tradeoffs and the importance of creating and managing technical debt.

I would disagree on the engineering point, as this ultimately falls on project management. Yes, engineers should provide professional expertise, but if management decides to yolo then engineers do not have the capacity to remove tech debt, regardless of their competence. Management of technical debt is, at the end of the day, managing short term versus long term velocity.

> Things don't happen in a vacuum, and your hypothetical "fragile interfaces" that you frame as being a problem are more often than not a lauded solution to quickly deliver a major feature.

Nothing I said disagrees with this, however that quick delivery of a major feature has downstream effect: anything that touches said feature is harder / slower / error-prone to implement. The more the team embraces "move fast and break things" the harder the wall it hits. Slower teams tend to be consistently average. Neither is better and this competence in managing technical debt is more often than not coupling/decoupling over fragile/robust interfaces.

This shows in LLM coding assistant use. Drop them in a well structured codebase and they implement features relatively well. Drop them in a bowl of spaghetti and they hurt themselves over confusion. With LLM coding assistants becoming more prevalent this managing of tech debt becomes even more important topic. You just cannot tell the LLM "pls implement well, no tech debt bro" or "yolo this, move fast, make it work 80% of the time".

If my career has taught me anything is that it takes competent engineering to push back against management pushing for every possible shortcut. A worry here is that detachment from the final output will reduce buy-in and produce "bad" code that will eventually grind feature velocity to a halt.

Re: Coding assistants are solving the wrong problem

#139

The requirements gap point is underrated. AI guesses where a human would ask By the time you catch it in review, you've already wasted the time you saved -_-

Silent naive compliance. AI will try to follow the prompt almost to a fault and because AI doesnt talk back, its upto the operator / engineer to ensure that requirements are well scoped. Product meetings often have a form of hand-waviness to details. The little assumptions which are out of place are what slow down a project the most. The issue is that with AI it is easy to quickly go far down the wrong road. I think thats the reason for the slow down that people experience.

Ironically, the very agents designed to replace engineers are now making engineers more important. These requirement collection skills can and should be folded into the existing craft of software engineering.

Re: Coding assistants are solving the wrong problem

#140
post #26
post #14

For me, AI is an enabler for things you can't do otherwise (or that would take many weeks of learning). But you still need to know how to do things properly in general, otherwise the results are bad. E.g. I'm a software architect and developer for many years. So I know already how to build software but I'm not familiar with every language or framework. AI enabled me to write other kind of software I never learned or…

I use Claude Code a lot but one thing that really made me concerned was when I asked it about some ideas I have had which I am very familiar with. It's response was to constantly steer me away from what I wanted to do towards something else which was fine but a mediocre way to do things. It made me question how many times I've let it go off and do stuff without checking it thoroughly.

People pay a lot of money to have people make mediocre solutions for them.

Now you don't have to pay a lot of money to get a mediocre solution that works.

All those things that are broken, but you don't have time or money for them, you can have them fixed now.

Post reply on HN