791–800 of 897 posts
I'm afraid software development will soon be about fixing code hallucinated up by AIs - and standups, retrospectives, reviews, demos, plannings etc.
Not directly related, but an anecdote: well before AI, I was talking to a Portfolio Solutions Manager or something from JP Morgan. He was an MD at the firm and very full of himself. He told me, "You guys, your job is....you just Google search your problem and copy paste a solution, right?". What I found hilarious is that he also told me, "The quants, I hate that they keep their C++ code secret. I opened up the execut…
A burning need to dominate in a misguided attempt to fill the gaping void inside
Broken and hurting people spreading their pain as they flail blindly for relief
Our world creaks, cracks splintering out like spider thread
The foundations tremble
Earlier quoted context omitted.
> Who's filling that role in this brave new world? Us? (Yeah, we’re fucked)
In a world of vibe coders, those who can still debug on their own, will have quite a valuable skill.
Earlier quoted context omitted.
Are least for a few more generations of model. I just finished creating a multiplayer online party game using only Claude Code. I didn't edit a single line. However, there is no way someone who doesn't know how to code could get where I am with it. You have to have an intuition on the sources of a problem. You need to be able to at least glance at the correct and understand when and where the AI is flailing, so you k…
Curious, do you supervise the code itself or at least understand what the code is trying to do? By "I didn't edit a single line", do you still prompt the agent to fix any issues you found? If so, is that consided an edit?
I think only once did I ever give it an instruction that was related to a handful of lines (There certainly were plenty of opportunities, don't get me wrong).
When troubleshooting occasionally I did read the code. There was an issue with player to player matching where it was just kind of stuck and gave it a simpler solution (conceptually, not actual code) that worked for the design constraints.
I did find myself hinting/telling it to do things like centralize the CSS.
It was a really useful exercise in learning. I'm going to write an article about it. My biggest insight is that "good" architecture for an current generation AI is probably different than for humans because of how attention and context works in the models/tools (at least for the current Claude Code). Essentially "out of sight out of mind" creates a dynamic where decomposing code leads to an increase in entropy when a model is working on it.
I need to experiment with other agentic tools to see how their context handling impacts possible scope of work. I extensively use GitHub Copilot, but I control scope, context, and instructions much tighter there.
I hadn't really used hands off automation much in the past because I didn't think the models were at a level that they could handle a significantly sized unit of work. Now they can with large caveats. There also is a clear upper bound with the Claude Code, but that can probably be significantly improved by better context handling.
Earlier quoted context omitted.
Surely there is a scale limit to how big the application can be using this approach.
Why do you say that? I would argue that as long as your tests and interfaces are clearly defined no reason it couldn't scale indefinitely.
Hypothetically, if you codified the architecture as a form of durable meta tests, you might be able to significantly raise the ceiling.
Decomposing to interfaces seems to actually increase architectural entropy instead of decrease it when Claude Code is acting on a code base over a certain size/complexity.
Earlier quoted context omitted.
Are least for a few more generations of model. I just finished creating a multiplayer online party game using only Claude Code. I didn't edit a single line. However, there is no way someone who doesn't know how to code could get where I am with it. You have to have an intuition on the sources of a problem. You need to be able to at least glance at the correct and understand when and where the AI is flailing, so you k…
I was thinking of that, but asking the right questions and learning the problem domain just a little bit "getting the gist of things" will help a complete newbie to generate code for a complex software. For example in your case there is the concept of message routing where a message that gets sent to the room is copied to all the participants. You have timers, animation sheets, events, triggers, etc. A question that…
Earlier quoted context omitted.
How is it the wrong tool for the job? In this particular case it's excellent, it can help you find proper abstractions.. without them you wouldn't realize. I kind of view this use case as enhanced code linters
If that's how engineers used it, sure, but instead many pretend they're brilliant by committing 10k lines they don't understand. I quit my last very good job because I became so fed up with this situation. It was bad enough before the CTO started using LLMs. It was ABSURD after. (This was a YC company that sold quickly after I quit, at a loss, presumably because they didn't know what else to do)
someone holding a hammer by the head and failing at getting the nail in doesnt mean a hammer is a bad tool for nailing
Not directly related, but an anecdote: well before AI, I was talking to a Portfolio Solutions Manager or something from JP Morgan. He was an MD at the firm and very full of himself. He told me, "You guys, your job is....you just Google search your problem and copy paste a solution, right?". What I found hilarious is that he also told me, "The quants, I hate that they keep their C++ code secret. I opened up the execut…
My own tangential gripe (a bit related to yours though): the factory work began when Agile crept into the workplace. Additionally, lint, unit tests, code reviews... all this crap just piled on making programming worse still. It stopped being fun to code around that point. Too many i's to dot to make management happy.