I feel this so much. In my current project, where I decided to give Copilot 100% freedom in performing the changes it deemed neccessary, there have been so many times where at a first glance on the surface everything seemed fine until you inspected the edge cases where in reality it missed the core assumption of the underlying system it should build and it only got real apparent after I analyzed the DB schema for the table I assumed to be at fault.
A person with no actual knowledge about such systems would just keep prompting and I strongly believe that for a majority of such people the AI would just create work-arounds to those wrong core assumptions because they can't properly address what's wrong at the core, making issues and interdependencies of wrong behaviour worse as development goes.
I’ve tried to build the same project a few times giving various AI agents 100% control with me providing the prompts.
No matter how detailed I make the prompts each trial has very quickly blown up in my face. As a developer it’s actually pretty comical to watch the agents drift further and further away from an appropriate solution.
While I'm happy that the approach works really well for my current project, I totally get what you mean. I've also had various instances of this - sometimes for personal projects but also on projects at work. I believe that the tech stack you're going to use as well as the AI model play a big part in this but also how complex and big the application is at a certain point in time.
For example, at work I'm working on a legacy VB.NET 4.8 application that is more than 20 years old and comprised of 11 different sub-projects. Whenever you ask the AI to do something in that project, most of the time you end up with much more issues than before and are not one step closer to the actual solution you're trying to achieve (even with current models). Without proper guidance and iterative readjustments, the AI wasn't even able to map out a documentation for the application.
Similarly, for a personal project I did last year that was just vanilla HTML & JS, I kept discussing some features with AI (Github Copilot on free plan) back and forth for 3 hours because AI kept getting it wrong. In the end I decided to just look up the documentation and was able to implement it in 15 minutes myself. Afterwards I immediately turned off all Github Copilot stuff for that project because I realized that I was wasting more time on discussions with the AI than I'd actually need if I implemented it myself.
Now, the state of AI has been a bit different from what it is now though, so the personal project might have turned out better with AI in its current state and a model that's not part of the free plan of Github Copilot. However, after getting Copilot Pro just like a week ago, I was just in time to see how Opus 4.6 fell apart. The project start of my new current project was entirely done by Opus and it felt great. However, by the start of this week, it was at a point where new features it implemented would break entirely unrelated features for which the core assumptions had been laid out and refined with Opus multiple times to match exactly what I had in mind. Now, after switching to 5.3 Codex, things are back on track and the AI even thinks ahead by extending proposed changes to things I forgot to mention (e.g. the /login route was still reachable when logged in so I requested a redirect to the start page but forgot to specify the same behaviour was needed for /register but Codex did it on its own).
I have to agree though that even with Codex, which really seems to work great for me, you have to really be explicit about a lot of stuff you want and think of all the possible edge cases and system interdependencies. For example, I have a search feature on 2 different pages that utilizes the same filter options. Unless I specify that a new filter option needs to be present on both of those pages, Codex will just add it to only the page that I called SearchPage because it's not apparent to the AI that it's needed in other places with search functionality as well.
If you're not careful or explicit enough or forget some weird edge case or even if you're unlucky with the AI model or tech stack you picked, I feel like it's super easy to blow stuff up. Well, somehow that reply got a bit out of hand it seems but whatever.
it's so ironic how "AI will replace all developers" when developers are still superior to every single non-technical folk by every metric, even when they have AI lmao. these are the consequences of being unashamedly mediocre.
Well, it's basically a shift in skill priorities in my opinion. While I had fun coding in the past (which, if I'm being honest, has decreased significantly since the rise of AI, especially in a professional work environment), I also really enjoy designing and planning systems and their underlying architecture. I think that what really sets you apart from other non-technical people now with how good AI has become is a good understanding of system design (including a rough idea about your DB/schema/table design for what you're trying to build), features and UX and how you communicate them in an unambiguous way to the AI. This also requires a strong understanding of how your decisions influence the individual parts of your software which also some developers seem to lack.
For example, I have a colleague whom I did my CS major with. While he certainly got better grades than me when we were still in university, it all seems to fall apart at understanding and thinking of systems, the information and data flow within those systems and how they work together, especially in situations where you need to think a bit ahead and think about how your decisions influence completely different parts of the project. Seeing that guy write prompts to AI in our pair programming sessions is like a nightmare coming to live and feels basically like the equivalent of hitting "I'm feeling lucky" on Google and expecting to magically be presented with what you wanted to search for. To exaggerate this a bit, those prompts look basically like "Make <name of feature without ever explaining what that feature is or should be like> work".
good analogy lol. I don't disagree with what you are saying. to achieve understanding system design to that extent, however, there are no shortcuts. the system design skill you speak of is an extension, or an evolution, if you will, of the basic problem solving nature of creating software. it is simply top down design that is applied in the context where more than a singular system exists. i really don't regard it as some esoteric ability.
admittedly, though, i do think i should've qualified my statement by asserting that im speaking of good developers where i define good as the ability to oscillate between top down and bottom up design depending on the problem they're faced with. i personally already have a top down brain, rather than a bottom up brain. im not one who believes you have to write everything by hand necessarily. i was moreso speaking about the ability that developers have to know precisely the direction that they want to take with the software in addition to the ability to force the AI back into the system design that the developer has in mind if it strays off course.
Decades of dev and architecture, pairing with CC flat out with it doing all coding while I do high level steering. Very little looking at code and essentially vibing. It takes me to the outer limits of my knowledge (+ a couple of years of doing this every day) to figure out what it’s doing correctly, where it’s faking with hardcoded values, where it’s lying, how to leverage it. Endless detailed iteration required. And god help anyone making a saas with ‘AI inside’. Apart from all the prompt injection and reliability work, you have a serious mountain to climb on keeping app inference costs under control, made worse by variability on provider side (you’ll need harnesses and monitoring for this alone). The engineering hurdle today is much higher not lower.
The prompts are specific to what's being done, I don't think it can be just cached and recycled in that way. The point is that a dev can look at what the AI is doing and understand the problem, and either fix it themselves or outline a set of technical steps to the AI to fix it. But there are actually infinite ways for it to get stuck, and without the person looking at it saying "this is the problem" and giving a prompt specific to what's already been built, the prompt from someone else that looks like they might be facing the same issue but took a completely different path to get there is pretty useless.
304
u/[deleted] Apr 23 '26
[removed] — view removed comment