Honestly, the post itself reads very generated, very rage bate. I have so much more faith in us and our hobby/industry than this blog post.
There are reports of industries trying to use these tools to generate as much as possible, sure. There are also people generating bad art and unpleasant prose and using llms to generate nonsense they don’t pay attention to.
I don’t see why that implies that you or I lost interest in tinkering with toys we build. If I want to spend 4 weeks understanding oauth a little better by implementing a client, I still can and I still do.
Automating our builds absolutely didn’t create a cathedral of complexity while nobody noticed. It did mean I can open an Free Software project, read the build file and understand how to build the thing. That’s the opposite of generating complexity.
I worry about our future generations as much as the next person, but this low effort pabulum doesn’t represent the thoughtful industry and hobby that I love.
I don't think the hobbyist interest will go away, but I can see what's happening affecting business that use software.
For most businesses, software is just a means to an end, they don't really care how high quality and thoughtful the systems they use are (e.g. look at any piece of "enterprise" software)
What LLMs have done is made much much easier for orgs to launch new features and services both internally and externally, without necessarily understanding the complexity.
For me, that's what this post tapped into. Many orgs already have more complexity than they can reasonably handle. Massively accelerating development, is not going to make that problem better :)
>Honestly, the post itself reads very generated, very rage bate. I have so much more faith in us and our hobby/industry than this blog post.
Don't get me wrong. I think the future is very bright for software. I have friends who are scientist and biomedical professionals and I am excited to see what they are able to do with the powers of software where they don't need to care about syntax and can only lead with their intentions.
The rage bait part is mainly my frustrations manifesting. As an SRE my annoyances came off a little bit when it comes to how fast developers are shipping vs how fast our rails can maintain things.
The site was actually built as an experiment on "spec first" coding with AI agents... in this case using Codex CLI. Underlying tech is Typescript, React, Zustard (for state), Bootstrap (for layout/components) and Konva JS (for 2D canvas) and vite for building/bundling. Deployed to AWS S3 bucket fronted by AWS cloud front using Github actions.
More options in the ecosystem seems better, but I was surprised to see this in the linked vitest docs:
> However, to run tests in CI you need to install either playwright or webdriverio. We also recommend switching to either one of them for testing locally instead of using the default preview provider since it relies on simulating events instead of using Chrome DevTools Protocol.
I keep seeing those "I vibe coded with Claude using this one simple trick..." blog posts. I decided to write a useful one that tells you how I made progress with Claude.
What's the conversation that you're looking to have here? There are fairly widespread claims that GPT-5 is worse than 4, and that's what the help article you've linked to says. I'm not sure how this furthers dialog about or understanding of LLMs, though, it reads to _me_ like this question just reinforces a notion that lots of people already agree with.
What's your aim here, sgt3v? I'd love to positively contribute, but I don't see how this link gets us anywhere.
I've been seeing teammates go from promising juniors to people who won't think, and I've tried hard here to say what I think they're going wrong.
Like the great engineers who came before us and told us what they had learned, Rob Pike, Jez Humble, Martin Fowler or Bob Martin, it's up to those of us with a bit more experience to help the junior generation to get through this modern problem space and grow healthily. First, we need to name the problem we see, and for me that's what I wrote about here.
There’s always been this draw in software engineering to find the silver bullet that will allow you to turn off your brain and just vibe your way to a solution. It might be OOP or TDD or pair programming or BDD or any number of other “best practices”. This is just an unusual situation where someone really can turn off their brain and get a solution that compiles and solves the problem, and so for the type of person that doesn’t want to think, it feels like they found what they’re looking for. But there’s still no silver bullet for complexity. I guess there’s nothing to do but reject the PR and say “Explain this code to me, then I’ll review it.”
Most juniors I watch program very quickly get overwhelmed by complexity because they dont know how to follow strategies like BDD or TDD which isolate parcels of complexity (e.g. how the program is supposed to behave) from other parcels (e.g. how the code actually works).
Even worse though, they all seem to think that the solution to becoming overwhelmed with complexity isnt to parcel it up with strategies like BDD and TDD but to just get better at stuffing more complexity into their brains.
To be honest, I see a similar attitude with LLMs where loads of people think you just need to stuff more into the context window and tweak the prompt and then it'll be reliable.
"People who won't think" resonates with me for the draw I've felt being pulled towards by chatbots, and I've got plenty of experience in software and electrical engineering. They're pretty damn helpful to aid discovery and rubber ducking, but even trying to evaluate different products/approaches versus one another they will hallucinate wild facts and tie them together with a nice polished narrative. It's easy enough to believe them as it is, never mind if I had less expertise. I've found that I have to consciously pull the ripcord at a certain point, telling myself that if I really want the answer to some question I've got to spend the time digging into it myself.
I have to disagree. The same people who won't think existed in previous generations as well. The only difference was, they blindly regurgitated what Bob Martin et. al were saying.
There will always be people who won't think. The specific problem the OP is noticing, is "promising juniors" who then fizzle out and become these people who won't think. I think this is an interesting category to look at. Is AI making more of the non-thinkers appear promising erroneously? Or is it a comfortable but insidious offramp for the lazy-minded who previously would only think because they had to? Or are the demands of the tech industry, increasing velocity at the cost of conscientiousness, tempting/forcing juniors to use AI to preserve their jobs, but at the cost of their careers?
I read over the author's analysis of the `mkdir` error. The author thinks that the abundance of error codes that mkdir can return could've confused gemini, but typically we don't check for every error code, we just compare the exit status with the only code that means "success" i.e. 0.
I'm wondering if the `mkdir ..\anuraag_xyz project` failed because `..` is outside of the gemini sandbox. That _seems_ like it should be very easy to check, but let's be real that this specific failure is such a cool combination of obviously simple condition and really surprising result that maybe having gemini validate that commands take place in its own secure context is actually hard.
Anyone with more gemini experience able to shine a light on what the error actually was?
The problem that the author/LLM suggests happened would have resulted in a file or folder called `anuraag_xyz_project` existing in the desktop (being overwritten many times), but the command output shows no such file. I think that's the smoking gun.
Here's one missing piece - when Gemini ran `move * "..\anuraag_xyz project"` it thought (so did the LLM summary) that this would move all files and folders, but in fact this only moves top-level files, no directories. That's probably why after this command it "unexpectedly" found existing folders still there. That's why it then tries to manually move folders.
If the Gemini CLI was actually running the commands it says it was, then there should have been SOMETHING there at the end of all of that moving.
The Gemini CLI repeatedly insists throughout the conversation that "I can only see and interact with files and folders inside the project directory" (despite its apparent willingness to work around its tools and do otherwise), so I think you may be onto something. Not sure how that result in `move`ing files into the void though.
Yeah, given that after the first move attempt, the only thing left in the original folder was subfolders, (meaning files had been "moved"), the only thing I can think is that "Shell move" must have seen that the target folder was outside of the project folder, so instead of moving them, it deleted them, because "hey at least that's half way to the goal state".
I’ve worked with Azure for a few years now, AWS and classic data centres for 15 years before that.
It’s pretty clear if you check github that Azure’s services and documentation are written by distributed teams with little coordination. We have a saying in-house that the info is all in their docs, but the sentences and paragraphs for even trivial things are split across ten or fifteen articles.
I see a problem like granting */read in an innocuously named role and am left wondering if it was pragmatism, because figuring out least privilege was tough, or a junior who didn’t know better and was just trying to make progress.
I’m on a phone and can’t search git effectively, but I’d swear there was a comment or note on the golang implementation of msal saying that it used non-idiomatic go with no real support for many of the auth flows in v1 because it was written by an enthusiastic junior dev and released with little review. The modern version looks better, but I felt like I got a window into Azure back when I read that.
Building large services is hard, my hat is off that Microsoft is making it work, but sometimes we get to see that it’s just teams of developers doing it for them and those teams look a lot like the teams we work with every day. There’s no secret sauce, except that MS has the resources to iterate until the thing mostly works most of the time.
> It’s pretty clear if you check github that Azure’s services and documentation are written by distributed teams with little coordination.
I've come to the same conclusion after dealing (and reporting) jankyness in both the Azure (ARM) API and especially the CLI. [0] is a nice issue I look at every once in a while. I think an installed az cli is now 700 MB+ of Python code and different bundled python versions...
Why do all these use Python? AWS, GCP, Azure, all three CLIs use Python; they're slow, bloated, heavy to install... what advantage does Python really offer here? You can't in any sensible way rely on it being installed (in your linked issue we see that they actually bundle it) so it's not even an 'easy' runtime.
Python takes up less than 16 MB on disk (python3.11-minimal + libpython3.11-stdlib on Debian) so whatever Microsoft did to make their Azure CLI package take up almost 700 MB, I don't think the language is the problem.
It might well be part of the problem. Certainly any language can be inefficient, especially in terms of size, if you don't pay attention (have certainly found this with Go recently). But as I said it's also slow (interpreting code, or dealing with cached versions of it) and it's not obvious to me why all three major cloud CLIs have chosen it over alternatives.
I don't understand the Python hate. What would they use instead?
Python is installed on most systems and easy to install when it's not. Only Azure is dumb enough to bundle it, and that was a complaint in the bug - there's no good reason to do so in this day and age.
The performance bottle neck in all three is usually the network communication - have you seen cases where the Python CLI app itself was using 100% of a CPU and slowing things down? I personally haven't.
Looking at the crazy way Azure packaged their CLI, it's hard to believe they weren't making it bloated on purpose.
And which Python are you talking about? I mean, Python3 is forward compatible but you SoL if you have the bad luck of having an older interpreter installed and you want to run a script which uses a new construct.
I don't understand why Windows people are completely okay having to install all kinds of crazy service packs and Visual C++ runtimes anytime they install anything, but then having to install Python seperately makes it a no-go.
Also, AWS is 10 years older than Rust, and C# only runs on Windows (at least it certainly only did when AWS was created, and is laughably more difficult to get running on Linux or OSX than Python).
> It’s pretty clear if you check github that Azure’s services and documentation are written by distributed teams with little coordination. We have a saying in-house that the info is all in their docs, but the sentences and paragraphs for even trivial things are split across ten or fifteen articles.
You can say that for the APIs themselves. It's like every API call has 80% of the info I want, but the other 20% that logically belongs with that 80% has to come from multiple other API calls.
The one that annoys me on a daily basis is fetching the logs for a pipeline run. The endpoint is `_apis/build/builds/<id>/logs` and it returns a list of pipeline log objects without the task name that generated them. You get an object with these fields: `{"lineCount", "createdOn", "lastChangedOn", "id", "type", "url"}` but no mention of the pipeline stage that generated it.. whether it's the build step, test run, publishing stage, etc. And those ids change (for example if you re-run a failed job, the unit tests may have ID 4 from the first run, and ID 17 for the second try), so you can't just rely on that.
And the pipeline log viewer on the website is garbage. When you click the link to view the logs it doesn't show you the logs it's collected already but starts showing new logs from that point forward and even for that, sometimes it truncates output and will skip lines. Somehow they managed to make trawling through logs even worse than it would normally be.
The new Notepad would hang for minutes if you used it to open a large text file. It also stuttered when scrolling. It’s incredible to see something so low quality make it into a core operating system app release.
> a junior who didn’t know better and was just trying to make progress
While totally plausible, that's kinda besides the point IMO. This shows regardless of how it happened, they don't have sufficient test coverage of these roles. Meaning built-in roles cannot be trusted.
AWS documentation is similarly bad: I used to joke that it was all written down to remind the service team of something rather than as something that is useful for users to read in advance and understand the service.
It’s only a feeling, but I’d swear I’ve seen variations on this post across a half a dozen software-adjacent subreddits every day for the last month. The common denominator has always been “Paying $200 for Claude Max is a steal” with absolutely no evidence of what the author did with it.
Yeah, I was about to say, it sounds a lot like this guy is just riding an intense high from getting Claude to build some side-project he's been putting off, which I feel is like 90% of all cases where someone writes a post like this.
But then I never really hear any update on whether the high is still there or if it's tapered off and now they're hitting reality.
Fwiw, I use Claude Pro in my own side project. When it’s great, I think it’s a miracle. But when it hits a problem it’s a moron.
Recently I was fascinated to see it (a) integrate swagger into a golang project in two minutes with full docs added for my api endpoints, and then (b) spend 90 minutes unable to figure out that it couldn’t align a circle to the edge of a canvas because it was moving the circle in increments of 20px and the canvas was 150px wide.
Where it’s good it’s a very good tool, where it’s bad it’s very bad indeed.
I think it's legitimately possible to get something done in a week that used to take 3 months, without realizing that you haven't actually done that.
You might have all the features that would have taken 3 months, but you personally have zero understanding of the code produced. And that code is horrible. The LLM won't be able to take it further, and you won't either.
I think we're seeing people on a high before they've come to understand what they have.
Where's the 10x, 20x, or whatever increases in profit from all the AI "productivity"? Typing is not the challenging aspect of writing code. Writing boilerplate faster isn't the super power that a lot of non-technical people seem to think it is.
Libraries and frameworks remove some boilerplate but there's still tons of it. It's rare a library exposes a single doTheThingINeed() function that runs a business. Everyone needs boring but domain specific code.
Are we returning to ideas having importance now since PoC are cheaper and easier? Any dev on HN can create a Facebook competitor, but getting the traffic shift will require some magical thinking.
A PoC has never really been a problem that needed solving. It's going from that to a product that's actually fit for purpose. AWS will happily drain your bank account because you're throwing tons of resources at a poor implementation. Hackers will also happily exploit trivial security vulnerabilities a vibe coder had no ability to identify let alone fix.
This is not the first time the industry has been down this road. They're not in themselves bad tools but their hype engenders a lot of overconfidence in non-technical users.
> with absolutely no evidence of what the author did with it.
I've got colleagues desperate to be seen as on board with all the AI experiments and they just write things like "tool X is MILES better than tool Y". Leadership laps it up
There are reports of industries trying to use these tools to generate as much as possible, sure. There are also people generating bad art and unpleasant prose and using llms to generate nonsense they don’t pay attention to.
I don’t see why that implies that you or I lost interest in tinkering with toys we build. If I want to spend 4 weeks understanding oauth a little better by implementing a client, I still can and I still do.
Automating our builds absolutely didn’t create a cathedral of complexity while nobody noticed. It did mean I can open an Free Software project, read the build file and understand how to build the thing. That’s the opposite of generating complexity.
I worry about our future generations as much as the next person, but this low effort pabulum doesn’t represent the thoughtful industry and hobby that I love.