Trap for whom. It helped me finish a bunch personal projects that made my work flow more efficient, as someone with very basic knowledge in coding.
The AI coding trap
361–370 of 424 posts
Re: The AI coding trap
#362Earlier quoted context omitted.
> You're constantly back at Day 1 of having to "own" someone else's code. If only there were some people in software engineering in this situation before AI… oh wait. In the current times you’re either an agent manager or you’re in for a surprise.
> In the current times you’re either an agent manager or you’re in for a surprise. This opinion seems to be popular, if only in this forum and not in general. What I do not understand is this; In order to use LLM's to generate code, the engineer has to understand the problem sufficient enough to formulate prompt(s) to use in order to get usable output (code). Assuming the engineer has this level of understanding alon…
The point is an engineering manager is using software engineers as typing savers, too. LLMs are, for now, still on an exponential curve of capability on some measures (e.g. task duration with 50% completion chance is doubling every ~7 months) and you absolutely must understand the paradigm shift that will be forced upon you in a few years or you'll have a bad time. Understanding non-critical code paths at all times will simply be pointless; you'll want to make sure test coverage is good and actually test the requirements, etc.
Re: The AI coding trap
#363Earlier quoted context omitted.
> the LLM may not be learning anything, but I am Regardless of that, personally i'd really like it if they could actually learn from interacting with them. From a user's perspective what i'd like to do is to be able to "save" the discussion/session/chat/whatever, with everything the LLM learned so far, to a file. Then later be able to restore it and have the LLM "relearn" whatever is in it. Now, you can already do th…
I routinely ask the LLM to summarise the high level points as guidance and add them to the AGENTS.md / CONVENTIONS.md etc. It is limited due to context bloat but it's quite effective at getting it to persist important things that need to carry over between sessions.
Yeah, as i wrote this is a common workaround, but what i want is for it to remember everything, not just the important bits.
TBH i'm not even sure if that is possible with LLMs, especially in a way that does not rely on using the context.
Re: The AI coding trap
#364I would love to see an anti-AI take that doesn't hinge on the idea that technology forces people to be lazy/careless/thoughtless. The plan-build-test-reflect loop is equally important when using an LLM to generate code, as anyone who's seriously used the tech knows: if you yolo your way through a build without thought, it will collapse in on itself quickly. But if you DO apply that loop, you get to spend much more ti…
> There's a divide between people who enjoy the physical experience of the work and people who enjoy the mental experience of the work
Eh, physical and mental isn't the divide — it's more like people who enjoy code itself as a craft and people who simply see it as a means to an end (the application). Much like a writer might labor over their prose (the code) while telling a story (the application). Writing code is far more than the physical act of typing to those people.
Re: The AI coding trap
#365Earlier quoted context omitted.
Conflict of interest or not, he's not really wrong. Anyone shipping code in a professional setting doesn't just push to prod after 5 people say LGTM to their vibe coded PR, as much as we like to joke around with it. There are stages of tests and people are responsible for what they submit. As someone writing lots of research code, I do get caught being careless on occasion since none of it needs to work beyond a proo…
> Anyone shipping code in a professional setting doesn't just push to prod after 5 people say LGTM to their vibe coded PR, as much as we like to joke around with it. I can guarantee this is happening in a lot of companies right now. Any company where there is pressure to use AI tools + pressure to get faster results it's inevitable.
Sure, there are incompetent people at every company, but if there was ever a solid reason for draconian linter and unit test rules besides middle management power tripping, it's to catch their mistakes. If it still makes it to prod, the CI/CD is not set up properly or operated by some that don't care, in which case the results are the same with AI or without.
Re: The AI coding trap
#366Earlier quoted context omitted.
That is a myth, cpu time is time spent waiting around by your users as the cpu is taking seconds to do something that could be instant, if you have millions of users and that happens every day that quickly adds up to many years worth of time. It might be true if you just look at development cost, but if you look at value as a whole it isn't. And even just development cost its often not true, since time spent waiting…
Yeah, it's time spent by the users. Maybe it's an inneficiency of the market because the software company doesn't feel the negative effect enough, maybe it really is cheaper in aggregate that doing 3 different native apps in C++. But if CPU time is so valuable, why aren't we arguing for hand written C or even assembly code instead of the layers upon layers of abstraction in even native modern software? Also, why
> But if CPU time is so valuable, why aren't we arguing for hand written C or even assembly code instead of the layers upon layers of abstraction
Maybe we should, all it took was Figma taking it seriously and working at a lower level to make every other competitor feel awful and clunky next to it then it went on to dominate the market.
Re: The AI coding trap
#367I would love to see an anti-AI take that doesn't hinge on the idea that technology forces people to be lazy/careless/thoughtless. The plan-build-test-reflect loop is equally important when using an LLM to generate code, as anyone who's seriously used the tech knows: if you yolo your way through a build without thought, it will collapse in on itself quickly. But if you DO apply that loop, you get to spend much more ti…
> I would love to see an anti-AI take that doesn't hinge on the idea that technology forces people to be lazy/careless/thoughtless.
Not forces, encourages.
Re: The AI coding trap
#368[dead]
Re: The AI coding trap
#369Earlier quoted context omitted.
> I would love to see an anti-AI take that doesn't hinge on the idea that technology forces people to be lazy/careless/thoughtless. The article sort of goes sideways with this idea but pointing out that AI coding robs you a deep understanding of the code it produces is a valid and important criticism of AI coding. A software engineer's primary job isn't producing code, but producing a functional software system. Most…
> And you will never know code as well as a reader and you would have as the author for anything larger than a very small project. This feels very true - but also consider how much code exists for which many of the current maintainers were not involved in the original writing. There are many anecdotal rules out there about how much time is spent reading code vs writing. If you consider the industry as a whole, it see…
You don't have much coding experience, do you. Everybody has a unique coding style that is pretty consistent across codebase, within given language lets say. Even juniors unless they all took it from either stackoverflow or llms (so same source).
Regardless how horrible somebody else's code is, there is some underlying method, or logic reflecting how given person forms mental model of the problem and breaks it down to little manageable pieces. You can learn that style, over time even ignoring it and seeing their code in same ways you see yours. llm code has none of that, if yes its by pure chance that won't repeat.
Re: The AI coding trap
#370Earlier quoted context omitted.
> who is going to be held responsible? This is actually a pretty huge question about AI in general When AI is running autonomously, where is the accountability when it goes off the rails? I'm against AI for a number of reasons, but this is one of the biggest. A computer cannot be held accountable therefore a computer must never make executive decisions
The accountability would be in whoever promoted it. This isn't so much about accountability, as it is who is going to be responsible for doing the actual work when AI is just making a bigger mess.
The accountability will be with the engineer that owns that code. The senior or manger that was responsible for allowing it to be created by AI will have made sure they are well removed.
While an engineer is "it" they just have to cross their fingers and hope no job ending skeletons are resurrected until they can tag some other poor sod.