← Back to context

Comment by turlockmike

8 days ago

[flagged]

I have read comments about this on X, here, and other places, yet I have ever seen there be proof this is an actual productivity boost.

I use Claude Opus (4.5, 4.6) all the time and catch it making making subtle mistakes, all the time.

Are you really being more productive (let’s say 3x times more), or just feel that way because you are constantly prompting Claude?

Maybe I’m wrong, but I don’t buy it.

  • > I use Claude Opus (4.5, 4.6) all the time and catch it making making subtle mistakes, all the time.

    Didn't we make subtle mistakes without AI?

    Why did we spend so much time debugging and doing code reviews?

    > Are you really being more productive (let’s say 3x times more)

    At least 2x more productive, and that's huge.

    • I think you’ve forgotten about the context of OP’s post. He said he uninstalled vscode and uses a dashboard for managing his agents. How are you going to be able to do code review well when you don’t even know what’s going on in your own project? I catch subtle bugs Claude emits because I know exactly what’s happening because I’m actively working with Claude, not letting Claude do everything.

      2 replies →

  • i really don't understand why people keep thinking this. i'm easily 10x more productive since Claude Code came out. it's insane how much stuff you can build quickly, especially on personal projects.

    • Of course personal projects are much quicker because usually personal projects don't have high code standards... I'm talking about production code.

  • typical experience when only using one foundational model TBH. results are much better if you let different models review each other.

    the bottleneck now is testing. that isn't going away anytime soon, it'll get much worse for a bit while models are good at churning code out that's slightly wrong or technically correct, but solving a different problem than intended; it's going to be a relatively short lived situation I'm afraid until the industry switches to most code being written for serving agents instead of humans.

    • The way LLMs work, different tokens can activate different parts of the network. I generally have 2-3 different agents review it from different perspectives. I give them identities, like Martin Fowler, or Uncle Bob, or whatever I think is relevant.

      1 reply →

> Software engineering is a mostly solved problem at this point

I guess that's why Claude Code has 0 open issues on Github. Since software engineering is solved, their autonomous agents can easily fix their own software much better and faster than human devs. They can just add "make no mistakes" to their prompt and the model can solve any problem!

Oh wait, they have 5,000+ open issues on Github[1]. I'm yet to be convinced that this is a solved problem

[1]: https://github.com/anthropics/claude-code/issues

  • The OP probably is the only person in their team. There's no other plausible explanation of this level of AI psychosis.

    PS: All in for AI agents I use all the time but sorry - SE is not a solved problem. Yet.

  • Indeed. In my view, "software engineering is a solved problem" is a roughly equivalent statement to "writing is a solved problem." I'm convinced that people who say this were never serious engineers to begin with, viewing code entirely as a means to an end.

    To me, code is both the canvas and deterministic artifact of deep thinking about program logic and data flow, as well as a way to communicate these things to other developers (including myself in the future). Outsourcing that to some statistical amalgam implies that the engineering portion of software engineering is no longer relevant. And maybe it's not for your run-of-the-mill shovelware, but as a profession I'd like to think we hold ourselves to a higher standard than that.

    Also, does the sum total of software engineering done up to this point provide a sufficient training set for all future engineering? Are we really "done"? That sounds absurd to me.

    I think people spouting absolutist statements like "software engineering is a solved problem" should largely be ignored.

> you need to embed your best practices in your agent and keep and eye on it and refine it over time.

Sincere question, how do beginners to the field (interns, juniors) do this when they don't have any best practices yet?

  • By working with other people, which I can't help but notice is missing from the parent comment.

    Unless you want to be a solopreneur (terrible idea while you don't know what you're doing and don't have the means to hire someone that does), look at pretty much any other comment in this thread.

  • it's the easiest as it's ever been to get started in a foreign code base: start up the agent and ask questions. more or less instant answers, basically zero confabulations nowadays.

    ...but since it's so easy to deliver stuff without actually knowing anything, learning means putting in the effort to resist temptation and use the agent as a teaching aid instead of an intern savant.

  • My advice for juniors is that it's too late to get entry level jobs for software engineering, but AI Automation engineering is just starting. Get a Claude code sub and build whatever you can imagine and focus on improving your own coding agent. Automate one more thing every day.

    • Software eng has always been automating repetitive decision making and processes. Code is just a series of steps computers/systems follow deterministically. Now we are automating the automation.

      I don't necessarily disagree with your advice, but goodness, I don't look forward to using any of the low quality software in the next decade. I hope the shareholders remain happy.

    • >improving your own coding agent

      ??????????

      write a thousand md files with detailed prompts (and called them skills)?

      is that what would get juniors hired? and paid real money? a stack of md files?

> If you aren't doing this level of work by now, you will be automated soon.

It's harder and harder to detect sarcasm these days but in case you're being serious, I've tested a similar setup and I noticed Claude produces perfectly plausible code that has very subtle bugs that get harder and harder to notice. In the end, the initial speedup was gone and I decided to rewrite everything by hand. I'm working on a product where we need to understand the code base very well.

  • I keep hearing “Claude creates subtle bugs”, but how is that different than people engineers? I’ve never worked in a bug free codebase

    • When you write the code yourself you are slowly building up a mental model of how said thing should work. If you end up introducing a subtle bug during that process, at least you already have a good understanding of the code, so it shouldn't be much of an issue to work backwards to find out what assumptions turned out to be incorrect.

      But now with Claude, the mental model of how your code works is not in your head, but resides behind a chain of reasoning from Claude Code that you are not privy too. When something breaks, you either have to spend much longer trying to piece together what your agent has made, or to continue throwing Claude at and hope it doesn't spiral into more subtle bugs.

    • Everybody produces bugs, but Claude is good a producing code that looks like it solves the problem but doesn't. Developers worth working with, grow out of this in a new project. Claude doesn't.

      An example I have of this is when I asked Claude to copy a some functionality from a front-end application to a back-end application. It got all of the function signatures right but then hallucinated the contents of the functions. Part of this functionality included a look up map for some values. The new version had entirely hallucinated keys and values, but the values sounded correct if you didn't compare with the original. A human would have literally copied the original lookup map.

      4 replies →

Very cool. What have you built with this method? Do you mind sharing details about the kinds of projects?

  • I mostly do this for work. These days I'm mostly building tooling for other devs. Observable memory system for coding, PR automation, CLI apps, dev coding dashboard, email automation. All of it integrating AI at various points (where intelligence is useful). All of that in the last two months alone.

    Claude code skills represent a new type of AI native program. Give your agent the file system, let it build tools to sync and manage data.

    • So you think your experience building tools for other devs is the same as every other domain of software to the point that you would declare the whole field of software engineering is a solved problem?

      Gamedev, systems programming, embedded development, 3D graphics, audio programming, mobile, desktop, physics/simulation programming, HPC, RTC, etc.. that’s all solved based on your experience?

    • Why are you building tools for other humans? Why are they programming in this world where you aren't programming but are also an insanely productive programmer?

Do you have any kind of proof you can show us? This reads like every other AI hype post but I have still never seen anyone demonstrate anything but proof of concept apps and imaginary workloads.

  • yeah, you'd think these commercial organizations would sit down with like, one marketer, and just put a non-trivial app together in real time and screen cap it all...

    like, we've had this technology for several decades now, and none of these AI tools are like: "This is so great, let me show everyone how to write a CRUD database with a notepad and calendar app" or whatever.

    • Several decades? Seriously?

      Several decades ago, we barely had the internet, rockets were single use only, and smart phones were coming any day now. CRISPR was yet to be named, social media meant movies from Blockbusters or HBO that you watched with friends. GLP-1 was a meh option for diabetics.

      I agree with your overall point but...your time frame is way off.

      1 reply →

Why exactly do you think people not doing that kind of work will be automated but your kind of work won't be automated?

If AI really is all that, then whatever "special" thing you are doing will be automated as well.

  • Thats exactly what we as software engineers do. We are constantly automating ourselves out of a job. The trick is that we never actually accomplish that, there will always be things for humans to do.

    We're discovering so much latent demand for software, Jevon's paradox is in full effect and we're working more than ever with AI (at least I am).

    • Software engineering is being automated. But building intelligent automation is just starting. AI engineer will be the only job left in the future as long as there are things to automate. It's really all the other jobs that will be automated first before AI engineer.

      1 reply →

    • OP compared AI to interns, and how they need to guide it and instuct it on simple things, like using unit tests. Well, what about when AI is actually more like an ultra talented programmer. What exactly would OP bring to the table apart from being able to ask it to solve a certain problem?

      Their comment about people who don't operate like them being out of a job might be true if AI doesn't progress past the current stage but I really don't see progress slowing down, at least in coding models, for quite some time.

      So, whatever relevance OPs specific methods have right now will quickly be integrated into the models themselves.

  • I don't disagree, aspects of that will be automated, but two things will remain: Intent and Judgement.

    Building AI systems will be about determining the right thing to build and ensuring your AI system fully understands it. For example, I have a trading bot that trades. I spent a lot of time on refining the optimization statement for the AI. If you give it the wrong goal or there's any ambiguity, it can go down the wrong path.

    On the back end, I then judge the outcomes. As an engineer I can understand if the work it did actually accomplished the outcomes I wanted. In the future it will be applying that judgement to every field out there.

    • How technical do you need to be with your optimization statements and outcome checking? Isn't that moat constantly shrinking if AI is constantly getting better?

    • Another way of saying this is most line engineers will be moving into management, but managing AIs instead of people.

  • I see variations of this non-stop these days, people who seem to be sure AI is going to automate everything right up to them.

>>>> Software engineering is a mostly solved problem at this point...

I'll believe it when AI can tell me when a project will be done. I've asked my developer friends about this and I get a blank stare, like I'm stupid for asking.