331–340 of 478 posts
“Before starting tasks, developers forecast that allowing AI will reduce completion time by 24%. After completing the study, developers estimate that allowing AI reduced completion time by 20%. Surprisingly, we find that allowing AI actually increases completion time by 19%--AI tooling slowed developers down.”
Shipping unreviewed, untested code into production is irresponsible. But not all code is production code, and in my experience most valuable work happens long before anything deserves architectural sign-off / big commercial commitment. Exploratory scripts, glue code—what I think of as digital duct tape between systems—scaffolding, probes, and throwaway POCs have always been messy and lightly governed. That’s kind of…
To the extent that no prototype could EVER end up in live - it had to be rewritten.
This allowed prototypes to move at brilliant speed, using whatever tech you wanted (I saw plenty of paper, powerpoint and flash prototypes). Once you proved the idea (and the value) then it was iteratively rebuild 'properly'.
At other companies I have seen things hacked together as a proof of concept, live years later, and barely supported.
I can see agentic working great for prototyping, especially in the hands of those with limited technical knowledge.
I think one fatal flaw is letting the agent build the app from scratch. I've had huge success with agents, but only on existing apps that were architected by humans and have established conventions and guardrails. Agents are really bad at architecture, but quite good at following suit. Other things that seem to contribute to success with agents are: - Static type systems (not tacked-on like Typescript) - A test suite…
I think one fatal flaw is letting the agent build the app from scratch. I've had huge success with agents, but only on existing apps that were architected by humans and have established conventions and guardrails. Agents are really bad at architecture, but quite good at following suit. Other things that seem to contribute to success with agents are: - Static type systems (not tacked-on like Typescript) - A test suite…
That's my experience too. Agent coding works really well for existing codebases that are well-structured and organized. If your codebase is mostly spaghetti—without clear boundaries and no clear architecture in place—then agents won't be of much help. They'll also suffer working in those codebases and produce mediocre results.
Regarding building apps and systems from scratch with agents, I also find it more challenging. You can make it work, but you'll have to provide much more "spec" to the agent to get a good result (and "good" here is subjective). Agents excel at tasks with a narrower scope and clear objectives.
The best use case for coding agents is tasks that you'd be comfortable coding yourself, where you can write clear instructions about what you expect, and you can review the result (and even make minor adjustments if necessary before shipping it). This is where I see clear efficiency gains.
Have had success at work, real value, real results.
Example: extracting a bunch of data from a tool we’re required to use at my company for getting a bunch of performance metrics. The data is useful but the interface is awful and it’s impossible to pull out trends and spot the real information I need from it. So, I threw Claude at it after months of dreaming of being able to better use the data. It generated for me in a few minutes all the data I could hope for in a CSV I was able to load into another tool that gave me deep insights almost immediately and allowed me to go make some different decisions I otherwise wouldn’t have.
What I did:
1. I have created and curated a set of sub-agents and commands/workflows for building things for me.
2. I used my build command, which details a workflow for refining, planning, implementing, code reviewing, testing, then conducting a final “product review” to determine if original requirements were met.
3. I then review the code myself before running it.
The code was solid (I’m also a very strong engineer and have tailored my agents and workflows to generate code I’d be comfortable with).
Another example: one of my teams went on a journey to convert one of our internal legacy frontend applications to a newer shared component library and eliminate old cruft that we inherited when we inherited the codebase.
The team was able to get this massive UI rewrite done in under two weeks, the updated code was better than the original code (it was all React to React, TypeScript to TypeScript), and we eliminated (literally) hundreds of thousands of lines of old hand-written over-abstracted code. Bundle sizes dramatically down, higher performance, more modern UX, and the thing is in production and working. Real value: faster product iteration in this now far smaller and easier-to-work-with codebase, far less technical debt, and faster builds, etc.
The team only used GitHub Copilot for this and it required a bunch of iteration and starting over with different instructions, but they got there and still managed to save a ridiculous amount of time; hand-writing the UI migration would have been one of those multi-month projects that went over schedule (I’ve seen and lived that movie many times before).
I’m still very skeptical of all the hype but I’ve seen very real, very valuable results out of this stuff.
edit: formatting
> The product has to work, but the code must also be high-quality. For me this has completely changed. The code needs to work. Bonus points when it is easy for a human to follow and has comments. But I don't do a full review anymore. I skim it and if I don't see an obvious flaw, it's lgtm. I also don't look into the bytecode / assembly to check whether the compiler did a good job.
In my personal experience (working as part of a team and not a solo dev), good documentation and well-documented/enforced practices can produce great results. That said, it’s not 100% perfect but neither are humans.
I'll bite. Here's my realtime Bluetooth heart rate monitor for linux, with text output and web interface. https://github.com/lowrescoder/BlueHeart This was 100% written by Claude Code, my input was limited to mostly accepting Claude suggestions except a couple of cases where I could make suggestions to speed up development (skipping some tests I knew would work). Particularly interesting because I didn't expect this…
It's a good demonstration of when agents still don't get everything right when you place things into Markdown documentation. You have to be really valiant and verify everything from top to bottom, if you want to control how things are implemented to that degree, otherwise the agent will still take shortcuts where they can. In https://github.com/lowrescoder/BlueHeart/blob/68ab2387a0c44e... for example, it doesn't actu…
Earlier quoted context omitted.
> A principal engineer at Google posted on Twitter that Claude Code did in an hour what the team couldn’t do in a year. I’ll bring the tar if you bring the feathers. That sounds hyperbolic but how can someone say something so outrageoulsy false.
Who are you referring to here? If you follow the link, you will see that the Google engineer did not say that.
> I’m not joking and this isn’t funny. We have been trying to build distributed agent orchestrators at Google since last year. There are various options, not everyone is aligned... I gave Cloud Code a description of the problem, it generated what we built last year in an hour.
So I see one error. GP said “couldn’t do”. The engineer really said “matched”.
Sure, here are my own examples: * I came up with a list of 9 performance improvement ideas for an expensive pipeline. Most of these were really boring and tedious to implement (basically a lot of special cases) and I wasn't sure which would work, so I had Claude try them all. It made prototypes that had bad code quality but tested the core ideas. One approach cut the time down by 50%, I rewrote it with better code an…
Are you serious? “Most of these were really boring and tedious to implement (basically a lot of special cases) and I wasn't sure which would work, so I had Claude try them all.” I doubt you verified the boring edge cases.