Earlier quoted context omitted.
Sorry where are we seeing that it failed? It compiled multiple projects successfully albeit less optimized. " It lacks the 16-bit x86 compiler that is necessary to boot Linux out of real mode. For this, it calls out to GCC (the x86_32 and x86_64 compilers are its own). It does not have its own assembler and linker; these are the very last bits that Claude started automating and are still somewhat buggy. The demo vide…
> Sorry where are we seeing that it failed? Try it yourself. I've been using claude to make a project over the last few weeks. Its written ~70k LOC to solve a complex problem. I've found that it can get surprisingly far in a 1-shot, but about 90% of the work I've had it do (measured in time and tokens) is cleaning up the junk it outputs in its first pass. I'm finding my claude sessions have a rhythm like this: 1. Pla…
I don't think AI will make your processes go faster
401–410 of 490 posts
Re: I don't think AI will make your processes go faster
#402You can fire far more, far faster, but it becomes much harder to operate accurately without collateral damage.
Re: I don't think AI will make your processes go faster
#403> This exact thing is what software developers have been begging for since the beginning of the profession: Receiving a detailed outline of the problem and what the end result should look like. > This is often the part that slows down software development. Trying to figure out what a vague, title only, feature request actually means. But that is exactly what Software Engineering is!. It's 2026 and the notion that you…
Re: I don't think AI will make your processes go faster
#404It’s amazing to see some people talk with 100% confidence about the macro view of AI assisted development when we have had strong coding agents available for less than a year.
Re: I don't think AI will make your processes go faster
#405Re: I don't think AI will make your processes go faster
#406Earlier quoted context omitted.
Just because one isn’t good at a thing doesn’t preclude one from being a sufficiently passable judge of a thing. To wit, the answer pre-AI was to hire an expert on that thing, and you would then critically assess their work product, despite being unable to build it yourself.
True, but if you hire a generalist and they are consistently under-performing specifically in the subject matter where you are an expert, it may behoove you to take the rest of their work with a grain of salt as well.
Perhaps the best generalist skill when working in teams of specilists is "a reasonably accurate bullshit detector."
Re: I don't think AI will make your processes go faster
#407Earlier quoted context omitted.
The article pretty much plays out whats happening in our place, heavy use of AI in software development but we dont see us shipping faster, about same or perhaps slower (for other reasons). Its a weird feeling as were waiting for this utopia to kick-in but its not and were cant fully put our fingers on it.
The article and the AI skepticism crowd on HN read like the blind leading the blind to me. I'm at a FAANG. My org is moving much more quickly, maybe between 3-10x more quickly than we were pre-AI. We aren't seeing a spike in reliability issues. Things just get done faster. An org as large as mine has no right to move as fast as it does.
You have been asked multiple times by multiple commenters to provide a single example of something that reflects this incredible boost achieved by , you have ignored every request for this, and I suspect will ignore this one as well. HN is going to die unless we all start calling these constant deceptive practices out. I’ll leave others to parse your history and make their own judgements.
“Judge them by their fruits”
Re: I don't think AI will make your processes go faster
#408Earlier quoted context omitted.
True, but if you hire a generalist and they are consistently under-performing specifically in the subject matter where you are an expert, it may behoove you to take the rest of their work with a grain of salt as well.
The key is to understand what someone is actually good at, rather than lump them into some amorphous "generalist" category. Along with (presumptively) broad experience, a generalist is just a specialist at various things which often feel obtuse or reductive to delineate — e.g. "I'm a specialist at rapidly narrowing vague failures into specific causes, assessing scalability trade-offs, understanding edge-cases at the…
Re: I don't think AI will make your processes go faster
#409I think when LLMs first came out people thought they could just say something like, "Make a Facebook clone". But now we're realizing we need to be more exact with our requirements and define things better. That has always been the bottle neck in software. When I was working we used to get requirements that literally said things like, "Get data and give it to the user". No definition of what data is, where its stored,…
> I think when LLMs first came out people thought they could just say something like, "Make a Facebook clone". But now we're realizing we need to be more exact with our requirements and define things better. The annoying thing is that giving an LLM vague instructions like "make a Facebook clone" does work... in certain limited cases. Those being mostly the exact things a not-very-creative "ideas person" would think t…
I was doing an exercise boot camp when mobile apps started to hit big. The instructor came to me saying he needed an app. "Okay, what should the app do?" He had no idea, he just knew he needed an app.
Re: I don't think AI will make your processes go faster
#410Earlier quoted context omitted.
That's what a good PM and developer pair should be doing, it's just that it's a lot faster for both of them now to review and work in tandem to get the feature done, because the bottleneck is the code generation.
> That's what a good PM and developer pair should be doing, it's just that it's a lot faster for both of them now to review and work in tandem to get the feature done, because the bottleneck is the code generation. The bottleneck is understanding, never "code generation." Below is an an axiom which has served me well over the years. Perhaps it will for you as well. When making software, remember that it is a snapshot…