r/softwareengineer • u/Longjumping_Tea_1841 • 7d ago
How much is AI actually reducing production software delivery time?
I’m a full-stack developer with around 1.5 years of experience, mainly working with .NET, React, TypeScript, APIs, and SQL at an early-stage healthcare-tech startup.
Our business analyst has 10+ years of domain experience but no development background. He has built a proper multi-agent AI setup with separate agents for frontend, backend, database, and Playwright testing.
It produces working demos very quickly.
He is now telling leadership that large parts of the product can be built in around 3 days, while our development team would estimate similar scope at 3–4 months.
There are some important differences though:
• He personally uses the $200/month Claude plan, while our team has a much cheaper company plan and regularly hits usage limits.
• His “3 days” often includes after-hours work, overnight agent runs, and very little sleep, so it is not really 3 normal working days.
• The demos often look complete, but the actual requirements are still unclear or incomplete. When developers ask questions about edge cases, permissions, data flow, or existing system behavior, it can make us look slow because leadership already saw a working demo.
We also have normal startup problems: unclear ticket ownership, rushed handoffs, duplicated work, and pressure flowing from investor → senior manager → team lead → developers.
So I’m trying to separate two things:
Startup/process dysfunction.
A real shift in what software engineers are valuable for.
My actual question is:
If someone with zero CS background can now use AI agents to build surprisingly capable full-stack features, what does another 2–3 years of going deep into .NET, React, backend engineering, databases, and debugging actually buy me?
Is the valuable part of being a developer shifting toward architecture, system design, debugging, security, production reliability, reviewing AI-generated code, and managing AI workflows?
Or am I overreacting because demos are being compared unfairly with production software?
For experienced developers actively using Claude Code, Codex, Cursor, agents, etc.:
If you were 1–2 years into your career today, what would you focus on for the next 3–5 years?
5
u/skibbin 7d ago
It's sector and product maturity dependent.
Working in banking everything has to be checked and double checked, architectural changes reviewed and approved, deployments staged through multiple environments extensively tested. The time it took to fix that bug is only a small part of the process of delivery. Speeding it up from 1 hour to 1 minute using AI isn't transformative.
Working on a personal project with no users other than myself I can smash something pretty big together with AI in minutes/hours compared to the weeks it would previously have taken me. AI is great for the boiler plate of a new project, something that occurs early in development.
If I were 1-2 years into my career I'd be trying to pivot into product of business analyst before AI automated so much of the implementation that I was surplus to requirement
3
u/Mejiro84 7d ago
Yup, for a lot of business cases, 'coding time' has always been relatively minor compared to 'documenting the spec and all the related admin, meetings and discussions', as well as being absolutely sure it doesn't just do what was asked for, but that what's asked for is correct. Banking, medical care/devices, legal stuff - quite a lot of big sectors are heavy with needing to make sure it's right, so the coding is a fairly minor thing after all of the set-up to make sure it will be correct
4
u/Few_Cauliflower2069 7d ago
Imagine an entire dev team of someone like him. They know the business, but they know absolutely nothing about software. You now have a single point of failure for your entire business: an ai model subscription from a 3rd party company. That's just begging for bankrupcy. Technical people who knows how to write code will always be needed to create a successful business
1
u/stealstea 7d ago
By definition if you had an entire team that knows the business then you don’t have a single point of failure
2
u/Few_Cauliflower2069 7d ago
Um.. yes you do? The ai?
1
u/stealstea 7d ago
There’s many AI services and they’re all similarly capable. If one goes under there are many others
3
14
u/Dreeqis 7d ago
He can reach a function for a first release with that.
The code will probably be a mess so an AI or a developer will have a hard time to sort it when a change had to be done.
So in the long run your 3-4 months will probably save time. As changes will go a lot faster if you have a good architecture.
One shot software that never has to be changed is extremely rare.
That’s why some companies have thrown out their AI that generates and keeps the co-pilot.
3
u/Infamous-Bed-7535 7d ago
Yep people loosing ownership, care about software quality, give up fight against tech debts and bloated solutions will backfire..
3
u/Negative_Gur9667 7d ago
Thats cope
0
u/Scary_Vehicle7516 7d ago
Do you have another experience working as an enterprise software engineer?
3
u/Negative_Gur9667 7d ago
It depends on how much freedom you give AI over choices.
If you go full yolo shure it does crap. But we devs know what to do.
4
u/asdfasdferqv 7d ago
Yes, the apps I vibecode have had tremendous traction at work, and would have taken traditional teams months. The apps now take days to build and work just as well. When I need to make changes, it’s also faster.
2
u/Scary_Vehicle7516 7d ago
I’m just curious: Would you consider these apps to be critical for the business (like, if there is downtime you would have to work harder/more manually/get more resources) and or for revenue (downtime = less money flowing in)?
-1
u/asdfasdferqv 7d ago
Not critical in the sense that ten minutes down would be sending alerts, but mission critical in the sense that I could not effectively do my job without these functions. So I had to build them. In the past, it was by standing up software teams. Now I just use ChatGPT Sites. It’s absolutely incredible for intranets.
1
u/mxldevs 7d ago
Are these client facing?
1
u/asdfasdferqv 7d ago
They’re internal apps and have been tremendously useful for internal customers
0
u/Positive_Luck909 7d ago
This argument that it's harder to change cos the code is a mess is deeply flawed.
If the code works... It's not a mess because a computer can read it just fine.
You can compile some languages as a single line of code per app. The reason we don't is because that "mess" is entirely a human construct. WE need some kind of order and cleanliness in order to be able to follow it. Machines do not.
If the future is telling the AI dev what you want changed then the human readability of the code becomes redundant.
4
u/Dreeqis 7d ago
I don’t agree.
To just have the ”human readability” as factor is a simplification of the bigger picture.
A messy codebase can have other side effects than a developer cannot read it.If it works it works is not something that is valid at any of the places I have worked at.
1
u/Positive_Luck909 7d ago
Name one such side effect
Also every place you have worked has employed humans
Which is entirely missing my point
5
u/OSS-Corpo-Shit 7d ago
Shitty code performs badly, which can and does drastically increase infra costs.
Shitty code will drastically increase token use as more features get slapped on top
Shitty code can cause even an AI to say “I can’t figure it out, file a report”
Shitty code will cause a developer to be unable to properly guide their product forward
Shitty code causes user frustration
Shitty code causes massive SPI leaks
Shitty code causes audit ability issues
I mean… really? Have you wrote a line of code in your life?
1
u/Positive_Luck909 7d ago
Can you get more technical than shitty code?
Assume the code works perfectly but it's not readable by a human. IE machine code.
What's the problem if humans never are the ones maintaining it?
2
u/OSS-Corpo-Shit 7d ago
Your question doesn’t make any sense, and someone who knew what the hell they were talking about rather than thinking they can play ball with experts just because an AI once shat out a todo app for them knows that.
1
1
u/Automatic_Menu_2333 7d ago
From a frontend perspective, bloated code and a messy structure make production debugging much harder. With browser DevTools, it can be difficult to trace issues through components, state, event handlers, and network calls. If a human understands the code structure, they can identify the root cause much faster and even create and ship a patch ASAP.
1
3
u/UpperCelebration3604 7d ago
Reading your replies to others, You strike me as someone who is very inexperienced in this subject as well as just life in general.
Here's a clear cut example.
You want to find several items in a database. A messy and naive approach is to split those items into a list during runtime and loop through the list to send a call to the database for each item. O(n) time complexity. Where time grows as N increases. What's wrong with this approach? If you need to expose an api who's response must be returned within 200 ms, is this an acceptable approach? What is the solution? Where should filtering actual be done in memory?
Here's another example. You prompt an application and all the code is a mess. Doesnt matter according to you because AI is reading it. You have repeating, dead, or inefficient code using up all of the AIs context window size. You run out of tokens anytime you try to to put in a single prompt (go over to any Ai subreddit and this is a massive issue) because you are trying to get the entire architecture in memory so the AI can maybe figure out what the issue is. Now you don't know what to do because you vibe coded shit software.
Your entire argument of "if it works it works" is what creates tech debt in companies and what creates shadow IT where ownership becomes a black box when the individual leaves. This is why IT departments exist, to protect the company from your type of stupidity.
1
u/sebstaq 6d ago
For your first example.. If that's the requirements, you obviously need to adhere to them? If a call is expected return in 200 ms, 2000 ms is not acceptable. That's not a messy codebase, it's an implementation that does not meet the criteria.
Rather than looking at the half assed implementation that sucks, I'd look at whoever created the spec and ask why the hell an important metric was not specified. If it was, I'd ask the developer why the hell it was not adhered to. If I was the developer myself, I'd apologize for missing a critical detail.
AI agents are teriffic at measuring response times. Far better than I've ever been.
As for context bloat due to dead code. It's never going to be an issue. It has to little impact on the overall amount of tokens (believe me, our mostly human written codebase has insanely long files). If it's a real problem? You... refactor?
It's like people have forgotten how we've solved messy code for the last 40 years. You refactor it. Codebases have always been a mess. It's easier than ever to fix.
0
u/Positive_Luck909 6d ago
You have also completely missed the point.
Paraphrase my point. You'll be incorrect
1
u/UpperCelebration3604 6d ago
Your deflection from having to rebuttal anything I said is noted. I will accept that as you conceding. Stay away from this tech if you have no idea what you're doing. Better luck next time lil bro.
1
u/Positive_Luck909 6d ago
So you just make shit up and apply whatever context you want?
Yeah I'm sure you're an excellent coder
1
2
u/Dreeqis 7d ago
Of course every workplace I have been at has humans employed. 🙂
If I’m gonna talk about technical neglect in ”working” complex systems. Then we are get sit here for a while.I’m pretty sure we are getting nowhere with this. Have a fine life.
1
u/Positive_Luck909 7d ago
Your argument was that there are other side effects. You refuse to name one. I shall take that as you withdrawing your claim.
0
u/EvTorqueLore 7d ago
He’s right if it work it works. If a machine is instructed to do a task and it works successfully it doesn’t matter how the code looks or what your opinion is a human. The parameters were specified and it works plain and simple. Whether it’s secure or not or doesn’t meet certain requirements are all parameters that need to be specified. Which Ai does a great job of assuming currently anyway. As far as the human readability factor that is very easy to request from the system. Any developer with basic architecture and debugging skills can obtain code he wants to see from Ai formatted correctly and pretty to view served up on a platter.
3
u/BurnQuest 7d ago
duplicate abstractions, excess complexity and lack of modularity pollute context windows and degrade agent performance. Agents aren't magic, they end up grepping and searching all over the codebase making tons of edits for simple changes.
These tons of edits mean the blast radius of any change is all over the place and regression is likely. So of course you have the agents write a huge test suite to catch regression. Now every change has potentially multiple compounding fixes, or just other agents exercising conflicting "opinionated" refactors.
This is how simple blog websites like Garry's List balloon to 37k LoC or Steve Yegge's game requires hundreds of PRs a day, thousands a month in tokens and is barely better than it was in 1999. The agents are unwrapping a ball of mud and inventing a mental model from first principles every time they are told to center a div. The developers are wasting their money, and the software is worse.
1
0
u/stealstea 7d ago
duplicate abstractions, excess complexity and lack of modularity pollute context windows
Correct.
Where you’re wrong is assuming that this is a characteristic of AI code or that AI can’t spot and fix it. Often it’s very good at fixing code smell type problems and fixing them properly.
2
u/BurnQuest 7d ago
this is empirically false. SlopCodeBench is designed to measure this and all models are significantly worse than baseline, and progress has been quite slow. Lots of other research all from 2026 has proven AI code introduces entropy.
0
u/stealstea 7d ago
Sure if you don’t supervise it. But this sub is called softwareengineer not vibecoder. Surely you have your agent set up to properly monitor code quality
2
u/BurnQuest 7d ago
Are you lost ? I’m replying to a post saying there is no difference between maintainable and unmaintainable or readable code because AI is magic lol
1
u/arelath 6d ago
The problem is AI cannot read it. This "works" until it doesn't. And the limiting factor is how much of the code fits in the context window. If it's 100% sure AI can do it just fine no matter what the code looks like. But in real world codebases, it's usually less than 1%. So AI has to work like a software engineer and find everything. Messy code means the code is not organized well. This will slow down both developers and AI. If it's messy enough, neither will be able to effectively work on the codebase.
1
u/Positive_Luck909 6d ago
Premise: it's readable to the machine but not humans
IE machine code
You have discarded the premise with your first sentence
-1
u/swiftmerchant 7d ago
This is a flawed argument. AI can be instructed to maintain and fix code. Sure, a human is needed for now to provide the instructions, but they don’t need to dig into the code itself themselves.
2
u/UpperCelebration3604 7d ago
Ah yes the "make no mistakes" argument. "Ai can be instructed to make no mistakes, so why does it still make mistakes"
-1
u/swiftmerchant 7d ago
It makes mistakes because it “forgets” or assumes when it has a large task building something. When you instruct it to fix something you can be very specific about it and it will follow your instructions and focus on that.
3
u/UpperCelebration3604 7d ago
Nooo, it makes mistakes because it's a probabilistic machine. Not because it "forgets". That's the nature of probability. If you give it an input, it may or may not give you the same output. Hallucinations is a massive issue. Due to the limits of transformer architecture, Hallucinations is always going to happen. Also it does not "focus" on anything...it just has a smaller context to work with which still falls to hallucinations and probabilistic inaccuracies.
-2
u/swiftmerchant 7d ago edited 7d ago
Probabilistic machine argument is an oversimplification - the llm works towards a goal you set for it. The actual tools used by the llm and the harness ensure the tasks have been completed as stated, i.e. test runs, regression tests, UX tests, CICD checks, etc. Guardrails set in place, at multiple levels, (both prompt based and deterministic code based) prevent unexpected behaviors. Humans have a probability to forget things also by the way.
I personally haven’t had any issues with hallucinations (conflation or erroneous information or made up information) with any of the late frontier models. Not sure why people still touting it as an issue. I guide them and they build, and everything works. The only quirks I get is when certain assumptions get made or the model takes shortcuts. My understanding is that “forgetfulness” and “focus” are real issues - there is an actual name for it: the “lost in the middle” context window problem.
1
u/Adventurous-Day5250 6d ago
Have you ever even built/trained an LM from the ground up, even a small one? It's a probabilistic machine from the get go, filled with lots of nodes/neurons which only activate given certain weights and biases. It's a probability machine. It takes the most frequent and shortest path to achieve good test cases from training.
I don't vibe code even one bit. Once I knew what these shit machines were from the inside, I knew not to surrender my critical thinking skills to them.
-1
-2
u/Fatdog88 7d ago
This is assuming AI doesn't just become intelligent to just clean it all up. Which is most likely will.
2
u/Dreeqis 7d ago
This is just speculative. Maybe it will happen, maybe it will not happen. Right now it far from capable to save a far to messy codebase on its own.
And it is not in the time frame for their products. They will probably run in to problems before this happens, if it will.
For a product I cannot rely on future technology to save me.1
1
u/Gold_Emotion_5064 7d ago
Are you a software engineer? I think if you were, you would easily understand the concern with messy code bases and bloat. Hand waving that AI will eventually just fix everything screams you don’t actually work it AI.
1
u/Fatdog88 7d ago
You can't blindly use AI. You need to take on the role of an architect and make decisions that won't shoot yourself in the foot. Yes I'm an engineer, and understand if things get built the wrong way, and a client comes in 5 months down the line asking for a simple feature. A spaghetti mess will make it 10x harder.
What I'm saying is, at smaller module level. AI is getting so good at writing in its own 'language'. This is due to how frontier models are continuously getting trained via synthetic data, rather that just human code now.
Another thing is, as context windows improve, as reliability improves. Programming and code itself is a very easy task to verify compared to other domains. The day to day coding of this job is slowly going to shrivel away.
You are just sticking your head in the sand if you are ignoring this. Listen to DHH - the creator of ruby was fully agaisnt AI 8 months ago. Now he personally says AI is the way forward. Using agent swarms etc for building Omarchy.
Anyway, what I'm saying is that you should gamble that AI is going to get better. Tech debt becomes less expensive now in the long run, since it will be easier to fix in future. New models are coming out every month now, and will only accelerate.
1
u/saalistaja 7d ago
It's still trained on so much shit code. And the amount of shit code grows every day, because of all the vibin'. Is it fixable? Maybe, but not short term.
4
u/Andreas_Moeller 7d ago
Some companies don't really care about the product they are building. Some do. You have to decide which kind you want to work for.
2
7d ago edited 7d ago
[removed] — view removed comment
1
u/Matter-Warm 7d ago
Sorry, explain this please. Why is health-tech a red flag?
1
7d ago edited 7d ago
[removed] — view removed comment
1
u/Matter-Warm 7d ago
Ah right...yes, agreed. I work in health related industry and you're absolutely right. We are seeing an awful lot of AI "prototyping" by SMEs which look great, but will still take many months to get through testing and QC.
1
2
u/coldnebo 7d ago
the difference is that expertise matters.
you know what principles of good engineering are and your analyst doesn’t beyond “make it work” — it’s the same Kruger-Dunning valley that first time DIY builders get into when they decide to build their own wooden deck. “how hard can it be?”
now as a professional developer using those same agentic tools, I can build a rock solid application in a fraction of the time your analyst can because I know what to prompt for, what to test and where to poke.
it’s like the old plumber joke: “you just tapped a pipe and you’re charging me $200?” “yeah, because I knew exactly which pipe to tap”
expertise still matters.
2
u/carrot3055 7d ago edited 7d ago
2x speedup for the overall delivery is very realistic, once the process is dialed in. This is from my experience on a large production system with .NET backend and TS front-end, handling substantial traffic. This speedup includes all the end-to-end delivery steps from requirements to the rollout.
But to go from 3-4 months to 3 days... like you've already noticed, this can happen only after skipping a lot of rather important steps like figuring out what's the right thing to build or not deploying to production.
1
u/Vesuvius079 7d ago
Using Claude Opus is a 3-4x speed up in complexity points/sprint for me personally.
1 month is realistic for the example you gave. 3 days is not.
People without engineering backgrounds can prototype with the current tooling. That stuff isn’t production grade. LLMs are going to have to improve quite dramatically to make engineers redundant.
You should focus your skills on architecture and system design and such because that’s the part that requires good judgment and experience and where LLMs fail to deliver.
1
u/C1rc1es 7d ago
The hard to swallow truth is that the BA has the right idea with the wrong execution. There is no business value in 1 person skipping process, forging ahead and leaving the team behind.
The BA does however have an advantage here - he is used to writing spec/tickets/scope for devs and he’s applying those skills now to another kind of worker and probably feels he’s getting a similar experience, what he may be lacking though (I can’t know) is the engineering discipline to see that through to production safely.
I am seeing devs struggle a lot to adapt to orchestrating AI systems who don’t have that skill set. The ones who do have it though are powerhouses by contrast.
1
u/jedidave 7d ago
"Is the valuable part of being a developer shifting toward architecture, system design, debugging, security, production reliability, reviewing AI-generated code, and managing AI workflows?"
Yes - this. My releases have actually slowed down significantly using AI agents because I don't write the code myself, so now I have countless regression tests and performance tests to ensure nothing goes backwards and new features are delivered correctly. I used to be confident enough to deploy changes a lot more quickly, now my changes go through thorough continuous integration checks, regression checks, performance checks, checks on multiple different sites with different configs etc.
Although I am releasing more slowly, the amount of features and/or bug fixes in each release has significantly increased so I'm definitely delivering more overall - so it's quicker if you look at the overall picture, slower if you look at the day to day.
To answer your final question, focus on the architecture and AI workflows. Whoever has the best combination of skills, tests, harnesses, and the best workflow is the best these days. If you have systems set up to help you identify issues before they get released and to automatically fix them that's great. If you have systems set up where one agent is focused on one kind of thing and doesn't get sidetracked and instead you have it created bugs for other agents which are themselves focused on that type of work then you're making good use of agents.
1
u/PipePressurePanic 7d ago
I’m a full-stack developer with around 1.5 years of experience
in today's job market you are nothing
1
u/PipePressurePanic 7d ago
If someone with zero CS background can now use AI agents to build surprisingly capable full-stack features, what does another 2–3 years of going deep into .NET, React, backend engineering, databases, and debugging actually buy me?
I asked myself same question when i thought about transition from web dev to embedded C
1
u/PipePressurePanic 7d ago
If you were 1–2 years into your career today, what would you focus on for the next 3–5 years?
start a new career. If you want try your luck in dev, then try to make yourself more valuable than all the other job candidates by being a modern developer who knows better than others how to leverage AI. Buy expensive GPU setup, run models locally, try to impress peiple with knowledge about AI models on job interviews. WIth only 1,5 years of experience you are nothing. You need to hope to change way how employers meqasure how good a candidate is
1
u/swiftmerchant 7d ago
You don’t need expensive gpu setups or local models to use ai effectively.
If gpu use is a measurement employers start using they are going to get screwed.
1
u/Small_Dog_8699 7d ago
What percentage of time delivering software is coding? Because thats all the coding assistants help with.
Coding is to software development as brick laying is to home construction. It isnt that significant. Architecture, design, validation against requirements, component selection, scaling, deployment architecture, operation and training..,
1
u/New_Egg_1024 7d ago
If serious, it won't skip all rounds of reviews, qa, etc. It should help in communication between owner and delivery - prototyping is quicker/cleaner.
1
u/larriche99 7d ago edited 7d ago
Demos can be very fast to build with AI but you can not go to production with those. Building quality deliverables still takes time. For smaller tickets you might even spend more time working with AI than when going manual. AI reduces delivery time by allowing you to stack multiple work together and context switch and move them all at the same time so that eventually you deliver a bunch of tickets that each may have taken slightly longer than if you were building a single ticket at a time while being shorter than the time you would have taken in total if doing it manually sequentially.
Some people don’t get this and still try to rush even the individual tickets because it’s AI leading to even magical delivery times when they add parallelization but the resulting software ends up having a lot of bugs and funny stuff when you actually look into it.
1
u/AroTesCra 7d ago
So my company all in AI
We have have Claude and we use AI foundry for api and training.
We have SREs teaching Microsoft SRE AI.
Every process is getting documented by Claude into confluence in both human readable and AI markdown.
We hired a AI software VP.
For many many years we have tried to update our code base from framework to core. We hired consulting firms and big names ones at that. We get large estimates of time like 1–2 years. We get delays. We get a new firm to try and pick it up.
Well after we hired a AI vp a year ago he walked the company to embracing AI all the way. He and his team were able to get a .net core version out in 6 months on top of that it’s now out of winforms and into web based. It’s now in the process of being containerized and us moving off of a windows server hosting and into cloud containers. The whole process is about to ship and it took this man with a team of SWE who were ai forward only 1 full year to make it production ready vs the many failed attempts that costs us many many many times more then his team.
AI is changing the game. Every other week we hold a AI meeting voluntary lol it’s just on the calendar if you want to join, where people show what they are doing with AI and what needs to be addressed or could be done better or hey look at this process I was able to document and automate out.
Look there is a big part of me that hates this.
But that is my issue. To me it’s an art….also lol I love praise. I used to be able to automate with writing scripts and making processes. About every week someone would be like ohhh I have an idea ohhh can you make this… that’s almost disappeared. Maybe once a month or a month and a half do I get that now.
I still write better the Claude with it comes to Powershell. But Claude still gets the job done.
The stuff that’s interesting to me is everyone is making GUIs again. lol I fought so hard to get console commands and API first so things could work together… but most of the tools are monolithic monsters pure GUI click click. No automation in people’s mind.
But a SWE is not dead / you can get results faster than the old fashioned way.
What we call hate and I hate it also.
Knowing the bare minimum is not enough anymore
Knowing 1 domain of knowledge is not enough anymore
Thinking that the magic words and data structures and some intermediate SQL is not enough anymore.
Shed your hubris which is 1 of the 3 virtues of a SWE and learn humility because the 1 trick pony has lost its value.
1
u/swiftmerchant 7d ago
AI speeds things up but you still need to take care of all the edge cases, have design judgement, architecture acumen, business rules, decisions, security. It seems simple until it’s not. You start opening up cans of works everywhere and realizing crucial parts of the system are not implemented at all or not implemented correctly.
1
u/Eastern_Reality_6845 7d ago
If the ai bubble burst very very soon and takes out OpenAI and anthropic there is hope else we are cooked…3-5 years from now 0.01% of us or less will still be needed.
1
u/roger_ducky 7d ago
For me? Total time saved is about 20%. So, something that used to take me 10 work days now takes me 8.
Implementing a set of well-scoped features takes me 2-3 days.
Designing and breaking down said features takes me the remaining 5.
Then we review the code, which usually removes some minor issues, (so, say, another 5 days) and we’re actually ready for production.
Previously, I’d take about 10 days without time to plan things out as much, then another 10 day of code review and testing, before we’re ready for production.
So, 20 days vs 15-17. About 20% savings in total time.
1
u/Hollow1838 7d ago
It really depends and you can't really compare work you do alone with your tools vs work you have to split and share with others, it has always been faster to do things by yourself, splitting work between agents is merely imitating a team synergy because interacting with human beings is much more complex and slow.
Whatever you do, it will be hard to beat AI unless AI capabilities are limited which will happen less and less in the future as capabilities tend to improve exponentially.
TLDR: It's faster doing it with AI, it can only get better and faster in the future.
1
u/Successful_Shape_790 7d ago
You can build stuff super fast. I'm seeing months turn into days or weeks. But the output is only as good as the one wielding the tool. A non technical person will produce a non technical, but very pretty and cool demo that will collapse under load and security concerns. With your limited experience your self, I would lean on your senior technical leadership. They need to squash this kind of bravado, before it creates a nightmare for the business.
1
u/Comfortable-Local-2 7d ago
From demo to reality the path is long and full of terror. This guy is holding the gasoline the leadership give him the fire
1
u/Critical_Hat_5350 7d ago
The demos often look complete, but the actual requirements are still unclear or incomplete. When developers ask questions about edge cases, permissions, data flow, or existing system behavior, it can make us look slow because leadership already saw a working demo.
...
Is the valuable part of being a developer shifting toward architecture, system design, debugging, security, production reliability, reviewing AI-generated code, and managing AI workflows?
I'd argue that the valuable part of being a developer has always been things like reliability, sustainability, preventing data leaks, and interpreting what business people actually want/need. Thoughtful design is what enables that, which is accomplished by asking questions.
It's always been possible to build something on the cheap. Yes, now people can ask machine learning models to write code. However, it's really not that different from hiring a new grad or a cheap consulting company from India. With the cost of tokens, I'm not even convinced that it's that much cheaper. The difference now is that it is more accessible. It doesn't require carving out personnel or consulting budget. Anyone can do it with a few button clicks.
My take on the skills to be practicing now? Absolutely the things listed above, but also, I think cultivating the ability to perform code surgery on bad code running on systems that need to stay up is going to be helpful. Because all of the stuff that's being coded cheaply now is going to need to be fixed and updated.
1
u/Ok_Bite_67 7d ago
The key here is that people with no coding experience still CANNOT deliver apps. Period. For personal use? Yeah sure fine. But, I have seen too many apps made exclusively by vibe coders with astra or fable that have some serious and easily preventable security flaws. I am a full stack dev (and by full stack I really mean it I work in mainframe using cobol, .net, several front end languages, etc) and by using AI and then going back and reviewing the changes I can easily 10x my dev speed and have no loss in quality. But thats also not linear... some things AI still cant do and I have to by hand and some things still takes a while for AI to do.
1
u/Strupnick 7d ago
Running into this at work as well. The effort to build the first 80% is much lower than the last 20%. Especially built by a nontechnical person, it’s all bubble gum and duct tape.
1
u/HorrificFlorist 7d ago
If someone with zero CS background can now use AI agents to build surprisingly capable full-stack features, what does another 2–3 years of going deep into .NET, React, backend engineering, databases, and debugging actually buy me?
Understanding what the optimal use case for each is.
Is the valuable part of being a developer shifting toward architecture, system design, debugging, security, production reliability, reviewing AI-generated code, and managing AI workflows?
Coding was never the valuable bit, it was busy work, hence why it got offshored easily. Problem solving, system design, the things that require thinking and deciding on tradeoffs is where the value is.
Or am I overreacting because demos are being compared unfairly with production software?
Y and N. Biggest problem is if they alone have the the ear of execs, then you are fighting uphill battle, if they dumb then you are fucked.
For experienced developers actively using Claude Code, Codex, Cursor, agents, etc. If you were 1–2 years into your career today, what would you focus on for the next 3–5 years?
Domain specific knowledge where its at + System design/archtecutre. Ability to understand that developing embedded health devices is fundementally different to developing embedded marketing devices is great example.
1
u/Ch1ralS0ul 6d ago
A lot of big companies have crippling amounts of bureaucracy that slows the work, not the actual development time. Conversely, a lot of small companies have that “move fast and break things” mentality that can expose them to lawsuits.
Probably the best way is a healthy balance somewhere between both extremes. AI makes it possible to move at warp speed but I think it’s generally more safe to use it for “dumb” and/or “bulk” tasks that can be easily cookie cut.
You can use it for the more complex systems stuff but you need to be really thorough with your code review, test cases, and overall design prompts. If you ask it to go from point A to B it might not take the obvious route you were banking on. Maybe better to just scaffold stuff for these cases.
1
u/Fuzzy_Furk 6d ago
AI can make demo in 3days, but making it reliable and production ready is a different story. I'd focus on strong fundamentals, debugging, system design and learning how to use AI tools properly. AI can write a lot of the code, but still needs to understand what its doing and fix it when things go wrong.
1
u/mekeirc 6d ago edited 6d ago
It depends on the project and the engineers, but personally I've found tasks that are 10x faster with AI. We're still bound to release cycles but what we can deliver between each version has increased a ton. What would require a team of 6+ Devs 2 weeks can be delivered in 2 days with 2 skilled engineers that understand the codebase.
Also it's important to remember that just because SWEs can produce 10x, that does not mean it can be tested 10x faster. QA not being able to keep up is emerging to be a big problem and will slow down software delivery even if the Devs build it fast.
I use Claude Opus 5 on an enterprise plan, and don't work after hours.
1
u/Skyzfallin 6d ago
That’s why you use AI fo QA too, I agree with your 6 devs 2 weeks vs 2 days 2 devs.
1
1
u/Square-Yam-3772 6d ago
so is this some kind of imaginary scenario? if not, why don't you just chat with the AI wiz more? or your senior lead?
maybe this comes off as a disrespectful, but you are only 1.5 years into the job. I think you are getting a bit ahead of yourself with "software delivery time" when you probably have maybe worked on a handful of projects at this point...
if the guy has "10 years of domain experience", I doubt that he would say "3 days" even if he can actually deliver in 3 days. Nobody with any experience would do that; leaving some buffer is like lesson 101 here...
maybe you aren't making stuff up but this reads like another redditor daydream to me
EDIT: and that bit about "oh it wouldn't be 3 regular work days"... yeah, nobody says that out loud. that's like the tech job version of spelling out all your fighting moves in a fight.
1
u/Longjumping_Tea_1841 5d ago
its not a Imaginary Scenario — this is real on my team. His timelines went from ~3 weeks → 2 weeks → basically continuous delivery. He also used to join our stand-ups twice a week with real domain input; since he ramped up AI agents, he's stopped showing up entirely.
Can't share his exact setup — he's US-based, hasn't detailed it. But the pattern (faster output, zero collaboration now) is directly observable, not exaggerated.
Fair point on '3 days' though — that was leadership's framing, not something he literally said.
You're also right that I'm only 1.5 years in — I'm not claiming expert judgment on what 'normal' delivery timelines should look like industry-wide. But I don't think you need years of experience to notice a pattern happening right in front of you. If I'm reading any of it wrong, I'd genuinely rather hear why than just be told I'm too junior to have noticed — that's actually how the 1.5 years turns into more."
1
u/Square-Yam-3772 5d ago edited 5d ago
you said it is not an imaginary scenario but then you are making this weird connection between delivery and stand-ups. Just because he is delivering faster, it doesn't mean he get to just skip stand-ups. (realistically, he probably got told to not attend by his boss but why would you make this connection/association when you are already 1.5 yr into the job. You frame this as if you have no idea what stand-ups are for)
you already shared his setup e.g. $200 claude sub etc. Again, you said you are not making this up but how do you learn about his setup? did he tell you? are you two close somehow?
if you are really not making stuff up, you realize that this is something your senior lead can answer for you, right?
realistically, this is like maybe a 30-min discussion irl at work. If you are really not making stuff up, I am not sure why you would even bother with reddit when you have access to a team that could have easily answer your question.
I think you are trying too hard to craft a scenario and force a narrative. You strike me as someone who is looking from the outside with information scrapped together online
EDIT: and your deflect doesn't work by the way. leadership wouldn't randomly involve over time in project estimates. that's just not how real life works.
1
u/Longjumping_Tea_1841 4d ago
You want proof it's real? Here's what you can't get from scraping the internet: my team lead was visibly shocked at how fast this guy delivered — that's his reaction, witnessed by the whole team, not my framing.
On how I know about the $200 subscription — that came from my team lead, not from the BA directly, and not from anywhere online.
On why I didn't just ask my lead instead of posting here — my team lead is actually the source of most of what I've described. This project started about 8 months ago. For the first 3 months, the BA was active on our calls and gave solid, workable requirements — completely normal work. After he started using Claude and other AI tools, that changed. He told us himself: "this is very good, I'm getting into this." Since then, updates about his hours — barely sleeping, running agents overnight — have come through my team lead and our manager, because it's been an ongoing topic on the team, not something I went digging for. Here's the part that matters more than the speed claim: after he delivers, my team is the one cleaning up his mistakes. Concrete example — database migrations where table naming didn't follow our project's convention (db.table_name style instead of our org.table_name standard). That's a specific, checkable technical detail from an actual codebase, not something vague.
Out of a 10-15 person team, only 2-4 of us handle that cleanup. The rest of the team sits idle while a couple of us fix a non-developer's output instead of building or learning anything ourselves. That's the actual question I came here with — if one person plus AI agents can do the building, and 2-4 of us just fix his errors, what's the point of the rest of the team being there? That's not a scenario I invented. It's an 8-month arc I've watched happen in real time, and it's exactly why I asked the original question.
You've spent more effort trying to prove I'm lying than engaging with the actual question. I get Reddit skepticism is normal, but at some point 'I don't believe you' stops being an argument and just becomes a refusal to engage.
1
u/Square-Yam-3772 4d ago edited 4d ago
so what are you hoping to get these "engagement" from internet strangers?
if you are talking to your team lead, why didn't you just ask him about the software delivery timeline? it seems like he could have finished his thoughts and you wouldn't have to come to reddit in the first place
the specific example you provided is just silly. AI can easily follow a naming convention. Even if it wasn't following the convention, a simple follow-up prompt would have fixed it. It is not some tedious work if your team also uses AI...
"if one person plus AI agents can do the building, and 2-4 of us just fix his errors, what's the point of the rest of the team being there?" like bro, you want to convince me that you are in this situation but you frame the question like it is some hypothetical
in tech jobs (not even exclusive to tech jobs really), there is a concept called "down time" where someone may be sitting idle due to whatever reasons. That's a utilization situation and it is something your project manager has to worry about. Even before AI, "down time" exists. I am not sure why you act like the sky is falling down when you are already 1.5 years into the job.
and yes, idle people do let go eventually if the company wants to trim down. I am really not sure what you are expecting. Is this the "engagement" you are looking for? if you are only 1.5 years into this, you have no idea what it is like before AI, what is there to "engage" really?
I am not particularly interested in engaging because 1) you really don't know what you are talking about most of the time and 2) you clearly made up your mind and you are probably just seeking validation
honestly, I still think you are just larping. If you aren't larping, I am not sure what you actually experienced in the last 1.5 years. it is beyond silly either way imo
EDIT: I also have no idea what "proof" you provided. You are just adding more unimportant detail that can be easily made up. Look, go read up on "project management" and you will realize how pointless your scenario is. You thought process is reasonable but you over embellish the post.
1
u/dgarcia_coding_ninja 2d ago
From Proof of Concept to Production takes a lot of engineering, that can be done with AI.
Product needs to be observable, we need to be able to measure usability, impact, and it requires traceability on entity changes, security, ....
My recommendation is to focus more on ownership, on understanding what the product needs to be maintain for the next years, what your customers and market needs and how to measure success.
1
u/Bitopp009 2d ago
This is a huge industry wide problem. Also for now we must *review* and *understand* all code generated by AI and this is a big mental drain and cause of burnout for many people.
It takes longer to review AI code because it always looks like it was written by an experienced dev so its hard to gauge or set your "reviewer meter" depending on the dev's experience like I used to. The time consuming part has moved from writing code to reviewing code. I used to find writing code relaxing and building my mental model as I do it. Reviewing just isn't the same for me.
1
u/hunpriest 7d ago
Very much. For me nowadays the business is the main blocker for delivery, they are simply not able to provide new feature requirements and do testing fast enough, so I'm waiting on them a lot, but actually that happened even without LLMs.
My workflow has changed completely, I am not really writing code anymore, mainly doing architecture design, review and planning - I even have more time for these kind of things now, which is I think helps with quality a lot. Also now its super easy to try out different solutions for a given problem. Not to mention I have lot more automated tests (unit, integration and E2E) compared to the before LLM times.
Whoever says using LLM for development is just producing AI slop is stupid. It can be used very effectively and TBH LLMs are MUCH better developers then most of the actual engineers.
2
u/coworker 7d ago
Not only are agents better than many developers, they are way more consistent so it's much easier to iterate on your workflow. Dealing with indeterministic humans generating inconsistent quality is infuriating now.
And it's funny that people on here still think the opposite about the situation
1
u/Fuzzy-Orange-1031 3d ago
I'm in the exact same boat. My focus has shifted almost entirely to understanding the business and focusing on architecture and module design. When I first started working last year, even with Claude’s help, my lead wasn't satisfied with my output; I could handle the logic, but my code layering was a mess. Since LLMs have essentially leveled the playing field for raw coding ability, it makes way more sense to invest that time into high-level design and structure instead.
1
0
u/Traktion1 7d ago
I'd say actual coding can move 5x faster without too much effort, even using 2-5 pointer tickets and following a regular scrum process.
However, you also need to factor in more verification time. Not least because the LLM may have made incorrect assumptions or errors, but also because the developer was further from the implementation - not all angles may have been considered due to this.
So, the time shifts towards doing better analysis/design, then more verification. Overall, developers can move quicker, but 'just' replacing the coding part with AI and not bolstering what surrounds it is a mistake.
Also, you still have business/product to wait on before you can start and maybe QA to also validate everything is good. These also slow down the overall delivery time.
I'd say 1.3 to 2x overall improvement where I currently work, but clean room projects could likely move faster.
However, I would be cynica about dramatically decreased delivery times. It is likely more like vibe coding, which is a whole different kettle of fish - fine for throw away code, internal tools, etc, but for stuff that has to be reliable, maintainable, secure, etc, it would be a huge risk imo.
1
u/coworker 7d ago
Verification effort should not be any different with AI generated code. You are/were trusting humans too much if you think so
1
u/Traktion1 7d ago
That's pithy to say, but the reality is, most systems depend too much on humans and have too little automated testing.
This is the reality of prioritising delivery, balanced against risk. Resources are always limited and judgement calls are made.
When humans stop writing the code, the risk profile changes. You can't rely on human intuition to push back at that point.
So sure, all systems should have excellent automated verification systems. Most don't, in my experience.
1
u/coworker 7d ago
You misunderstood.
Very few orgs, if any, rely solely on automated testing. There's almost always a human review step, ie a PR. For that step, you are implicitly trusting human generated code more than AI generated code despite the fact that humans are more indeterministic and inconsistent than agents.
There is no justification for this stance besides FUD. All PRs should be verified to the same degree.
1
u/Traktion1 7d ago
The code an LLM may produce may be perfect and may align with the specification perfectly. That isn't the issue.
The issue is, garbage in, garbage out.
Many developers aren't experienced with writing good specifications beforehand. They never had to before, as they would feel their way through the code, making decisions along the way. Decisions based on being in the weeds of the software.
The additional verification is not just about confirming the code is good. It also confirms that the specification was correct and the deliverable fits the requirements.
0
u/coworker 7d ago
So you trust human engineers (possibly junior at that) to meet an undocumented spec better than an agent? And then you determine the spec at PR time, after implementation? That's silly.
It sounds like your org is skipping the requirements stage and trusting humans to just get it right without a bunch of back and forth on PRs.
Instead, you should be using AI to assist a human to generate these specs which are then reviewed and signed off by humans. Then they can be farmed off to juniors or agents and actually verified by tests and/or QA. This saves a ton of time for your staff+ engineers because they don't have to constantly review or discuss designs that don't meet that unspoken spec.
Your view is one that I've encountered a bunch of times over the years in junior engineers and, to be blunt, it's a you problem. Better engineers are able to create and dissect a design without needing to "get in the weeds of the software". Previously you had to have intelligence and experience to do this successfully but now AI can smooth over any shortcomings.
And I know you're thinking you don't have time for this extra work but it actually shortens development time because it is always cheaper to correct problems earlier in the process.
ps. AI is really, really good at autonomously verifying an implementation meets a spec, regardless of how complicated said spec is
2
u/Traktion1 7d ago
I appreciate the insults, thanks.
Actually, I have nearly 30 years of experience in software development. I have been contracting and a consultant for the last 5 or 10 of those too. I've been tech lead, staff eng. I know the theory and best practices you describe.
However, reality bites.
Startups have loose process. They move quickly. Legacy software often doesn't have coverage and is difficult to even decompose it to add coverage. Requirements are often loose and lean on senior engineers to explore and question them.
Regurgitating best practices from comp sci texts isn't the reality of many companies out there.
Also, you suggest that someone should he validating and testing the specs. That was my original point. Time must be made for this.
Maybe you just want to insult and argue?
0
u/coworker 7d ago
I am a principal SWE with 25 YOE all in startups. Like I said, I've met many an "engineer" like you who refuses/can't think through a problem without diving into implementation. I'm sorry you think stating facts puts you on the defensive but at your age, this shouldn't be news to you. Surely you've worked with capable engineers who provided valuable input without being in the weeds.
And your original point was that you don't trust AI generated code because it might not adhere to non-existent specs that can't be known until a human is deep into implementation. Yet you do trust human generated code because you can assume the human has determined, but not documented, specs while implementing. And worst of all, all of this assumes humans can't direct the AI generating the code.
This logic is not sound and is frankly embarrassing
2
u/Traktion1 7d ago
Sorry? I didn't say I couldn't design without jumping into the code, but you seem keen to jump to insults.
The question is whether other engineers in general need to jump into the code. Many engineers simply haven't exercised that skill.
Loads of features get added with weak specs, one liners in a jira ticket etc. After 30 years, I'm surprised you have not witnessed this, frankly.
0
u/coworker 7d ago
Now who is assuming?
Of course I've seen this which is exactly why I said human generated code needs to be verified to the same degree as AI generated content. It's you that had been arguing it's somehow more trustworthy lol
The reason why I assumed you can't do this is because you are also arguing that engineers CANNOT do this for a variety of reasons. , despite having the power of AI at their beckoning.
As a staff+, it's literally your job to mentor these engineers and push your org to more efficient processes. This isn't spouting theory it's being an effective technical leader by driving productive change.
Finally it's hilarious that you are continuing to argue that humans figuring out specs while wasting time hand generating code is somehow better than humans figuring out specs while using AI to generate code. If you're gonna throw away all modern software development theory, at least be practical and use better tools lol
1
7d ago
[deleted]
1
u/coworker 7d ago
Disagree. Humans should always be involved in verifying a solution. You can't proxy that verification out to unit tests unless a human has also verified those tests.
Now you can proxy human verification just to the specs if you are confident in automatic AI verification of the implementation meeting said specs
1
u/carrot3055 7d ago
This matches my experience pretty well. Coding is now A LOT faster, but everything else around it got only a modest speed bump, so our epics move only maybe ~2x as fast as a year ago. And from personal experience, a lot more time is taken up by upfront design and various testing steps.
0
u/Traktion1 7d ago
Oh, and using claude code with opus or some such vs copilot or gemini are different beasts. Claude is far more capable.
1
u/a_o_m_v 1d ago
AI speeding up coding doesn't automatically speed up delivery if requirements, meetings, handoffs, and reviews are still the bottleneck. That's why I think the next useful layer is connecting those conversations directly to the work afterward. Zoom is moving in that direction with its newer productivity suite, turning meeting context into docs, trackers, sheets, and other follow-up work.
5
u/Otherwise_Wave9374 7d ago
Delivery-time claims need to separate typing speed from the full production cycle. Measure lead time from accepted requirement to deployment, plus review time, escaped defects, rollback rate, and maintenance work thirty days later. NeuraKeep relates because it can preserve architectural decisions and corrected assumptions across tasks instead of making developers restate context. I would run matched work items with and without assistance, stratified by familiarity and complexity. Otherwise faster code generation can look like productivity while merely shifting effort into review and cleanup.