11 ms·

I don't think AI will make your processes go faster

• banner521520 4mo ago
  It's 2026 and the notion that you can get detailed enough requirements and specifications that you can one-shot a perfect solution needs to die.
  • dxdm 4mo ago
    You forgot to cite the source of your verbatim quote of an earlier comment here.
    • tardedmeme 4mo ago
      It's a karma farming bot.
• usernametaken29 4mo ago
  Instead of mandatory AI workshops simply cancel all meetings with more than 3 people and no written agenda. Instead block the meeting time for productive work. That’ll be 2000$ of advisory fees for the insane productivity gains I just unlocked you. You’re welcome
  • teaearlgraycold 4mo ago
    If people got paid for telling the truth you’d be rich.
    • steveBK123 4mo ago
      Yes, there are MANY in tech/non-tech management that will quietly admit that a lot of this top-down stuff is to create the appearance of motion to appease a higher more tech/AI ignorant authority.
• praneetbrar 4mo ago
  If the underlying workflow is noisy, ambiguous, or overloaded with coordination overhead, faster generation just produces more low-context output to review and reconcile.
• Havoc 4mo ago
  It absolutely will make some things faster. Anyone that has ever churned out some boilerplate code with it knows that. ...but yeah most organizational processes & people aren't set up for leveraging it and roll out will be slow (same on learning where it does / doesn't work).
  • sarchertech 4mo ago
    I’m not convinced. I’ve been using AI pretty heavily for about 18 months and agents for a little over 6 months. I’m currently working on a data migration for an enormous dataset. I’m writing the tooling in go, which is a language I used to be very familiar with, but that I hadn’t touched in about 12 years when I started this. It definitely helped me get back into go faster. But after the initial speed up, I found myself in the last 10% takes the other 90% of the time phase. And it definitely took longer for me to wrap my head around the code than it would have if I’d skipped the AI. I might have some overall speed up, but if so it’s on the order of 10-20%. Nothing revolutionary. I have been able to vibe code a few little one off tools that have made my life a little easier. And I have vibe coded a few iPad games for my kids for car trips, but for work I still have to understand the code and reading code is still harder than writing it. This is also not from lack of trying , I spent $1000 last week during a company wide “AI week”. Mostly on trying to get AI to replicate my migration tooling, complete with verification agents, testing agents, quality gates, elaborate test harnesses etc… I’d let Claude (opus 4.7 max effort) crank away overnight only to immediately find that had added some horrible new bug or managed to convince the verification agent that it wasn’t really cheating to pass my quality tests. What I learned from last week is that we are so far away from not needing to understand the code that everyone who says otherwise is probably full of shit. Other people who I trust who have been running the same experiments have told me the same thing. Until and unless we get to that point, it’s always going to be a 10-50% speed up (if that).
    • Havoc 4mo ago
      >if so it’s on the order of 10-20%. Nothing revolutionary. For many businesses that is revolutionary. Not sure that's enough magic to make the math work for the trillions being invested, but on a ground level within companies even small wins stack up. You may have burned through $1000 without getting much done, but from a company perspective they've probably got an employee with better instincts as to what does or doesn't work
• echelon 4mo ago
  It makes small teams without organizational overhead go lightning fast. It might be the ultimate tool of disruption.
  • michaelbuckbee 4mo ago
    Exactly. The larger the organization the less percentage time devs actually are doing dev work and the less direct benefit there is from AI assisted coding tools.
  • tgv 4mo ago
    I have a colleague who vibes the shit out of his part, and it results in large commits that take a lot of time to understand, and that makes cooperation practically impossible. LLMs are not team players.
    • plasticchris 4mo ago
      I get much different results than others when using these tools. Turns out there is some skill in wielding them, and knowing the domain in which you do.
    • echelon 4mo ago
      That's a you guys problem. Maybe one or both of you. Have you thought about pair programming together with the AI? My LLM outputs are intentional, in my style, and tightly reviewed by myself. I'm also emitting Rust, which I've found to be the very best language to work with in AI. The AST and language design is focused around control flow and error handling. The borrow checker, sum types, filtering and mapping makes it such that good design is idiomatic. There's a lot JavaScript, Python, PHP, and Java in the world. A lot of it isn't great. The architectures and styles are wildly varied too. Rust doesn't have that problem. The training data is really solid and idiomatic.
• kj4211cash 4mo ago
  On the one hand, this is a clean post that explains exactly what a lot of us have been thinking and seeing on the job at large organizations doing tech work. Dear Author, I agree with you 110% and want everybody else to come to understand what you have written. On the other hand, it feels like we've been over this tens of times recently, on HN specifically and IRL at work. Another blog post isn't going to convince leaders that this is how the world works when they are socially and financially incentivized to pretend like AI really will speed things up. So now I just wait for their AI projects to fail or go as slowly as previous projects and hope they learn something.
  • cmrdporcupine 4mo ago
    Yep. I have the luxury of having my mortgage paid off and being able to be a bit picky about my work for a little bit. So I am spending my days gardening and obsessively working on personal coding projects with these agentic tools. Y'know, building a high performance OLTP database from scratch, and a whole new logic relational persistent programming environment, a synthesizer based on some funky math, an FPGA soft processor. Y'know, normal things normal people do. So I know what these tools are capable of in a single person's hands. They're amazing. But I hear the stories from my friends employed at companies setting minimum token quotas or having leaderboards of people who are "star AI coders" telling people "not to do code reviews" and "stop doing any coding by hand" and I shake my head. I dipped my toes into some contract work in the winter and it was fine but it mostly degraded into dueling LLMs on code reviews while the founder vibe coded an entire new project every weekend. These tools suck for team work or any real team software engineering work. I'll just let this shake out and sit out until the industry figures it out. The only places that are going to be sane to work at are places with older wiser people on staff who know how to say "slow down!" and get away with it. In the meantime, quantities of cut rhubarb $5 a bunch in Hamilton, Ontario area for sale. Also asparagus. Lots and lots of asparagus.
    • jcgrillo 4mo ago
      Yeah I think moving forward one of the questions I'll be asking companies I interview with is "what does your seniority distribution look like and how do you intend to maintain it?"
• p2detar 4mo ago
  > Yes, AI can generate code quickly (whether that’s a good thing is open for debate), but that doesn’t mean it’s generating the correct code. No, the code is actually almost always correct. The way it’s added is probably not what you’re going to like, if you know your code base well enough. You know there’s some ceremony about where things are added, how they are named, how much comments you’d like to add and where exactly. Stuff like that seems to irritate people like me when not being done right by the agent, and it seems to fail even if it’s in the AGENTS.md. > If you were to give human developers the same amount of feature/scope documentation you would also see your productivity skyrocket. Almost 2 decades in IT and I absolutely do not believe this can ever happen. And if it does, it’s so rare, it’s not even worth talking about it.
  • nijave 4mo ago
    >No, the code is actually almost always correct That's not my experience, especially when the inputs are bugs or performance issues. It frequently hallucinates and misdiagnosis without a guiding hand. However, it can still RCA and analyze well and improve efficiency if you keep an eye on what it's doing and push it the right direction. > If you were to give human developers the same amount of feature/scope documentation you would also see your productivity skyrocket. I think you run into a ceiling how fast a person can digest and analyze the info compared to a machine
    • BoxedEmpathy 4mo ago
      What tools are you using? What settings? What process? What's your code review like? I think this varies a lot. I find with a c++ project I'm working on that the LLM needs a lot of guardrails and guidance, and still gets a lot wrong. But with a vite/js project it often one shots complex and intricate changes in large codebases.
      • nijave 4mo ago
        Claude Code with Opus 4.7 xhigh effort Datadog + Python with a little AWS It does better at writing code but diagnosing bugs and performance issues is a bit of a crapshoot. It's decent at diagnosing but when tasked with improving performance it gets a bit sketchy. It'll write something that runs but often times it either has subtle functionality changes or mediocre improvements Other times I'll repeatedly have to push it to find the root cause. It'll say "hey this downstream service threw an exception that propagated as a 500" and I'll have to remind it that's a first party service with info available in the trace and source code also available that it needs to continue investigating.
• adam_patarino 4mo ago
  > Every software developer knows that you can’t make projects go faster just by typing faster. If that were the case we would all be taking typing lessons. So well said. AI is unveiling how the bureaucracy is the slow part.
  • jagged-chisel 4mo ago
    > AI is unveiling how the bureaucracy is the slow part. Computing has been doing that for decades. If your process is fucked, computers make it fucked faster. It’s just that now, we have entire generations alive that have never seem a world without digital computers. ~LLMs~ AI is a fun new lever in some uses so clearly it is finally the hammer that will drive the screws and bolts for us, with less effort on our part! They just have to learn from experience. It’s what you do when you can’t be bothered to learn the lessons of the past.
    • adam_patarino 4mo ago
      Completely agree. It amazes me how some folks think AI is unlike any other technology revolution. History repeats.
      • cmrdporcupine 4mo ago
        You're right it's just like any other mechanization/automation revolution. Except it's not. It's happening about 10x faster than any other I've seen or read about. Conceive how long it took just to get barcode scanners rolled out in grocery stores. Or direct payment terminals. Or how many decades it's been getting robotics into the manufacturing of cars at scale. I worked through the .com boom and I can tell you that "webification" took 10 years or more for most businesses (and many of them now just gave up and just have a Facebook page instead etc) This is a little insane what's happening now. It really does change everything. People who don't work in software I don't think have any idea what's coming.
        • steveBK123 4mo ago
• CharlieDigital 4mo ago
  > ...but that doesn’t mean it’s generating the correct code. Something I'm observing is that now a lot of the pressure moves to the product team to actually figure out the correct thing to build. Some product teams are simply not used to this and are YOLO-ing prototypes now, iterating, finding out they built and shipped the wrong thing, and then unwinding. Before, when there was the notion that "building is expensive", product teams would think things through, do user interviews up-front, actually do discovery around the customer + business context + underlying human process being facilitated with software. This has shortened the cycle to first working prototype, but I'd guess that in the longer scale, it extends the time to final product because more time is wasted shifting the deliverable and experience on the user during this process of discovery versus nailing most of the product experience in big, stable chunks through design. At the end of the day, there is a hidden cost to fast iterative shifts on the fundamental design of the software intended for humans to use and for which humans are responsible for operation. First is the cost on the end users who have to stop, provide feedback, and then retrain on each cycle. Second is that such compounding complexities in the underlying implementation as product learns requirements and vibe-codes the solution creates a system that becomes very challenging for humans to operationalize and maintain. Ultimately, I think the bookends of the software development process are being neglected (as author points out) to the detriment of both the end users and the teams that end up supporting the software. I do wonder if we're entering an "Ikea era" of software where we should just treat everything as disposable artifacts instead.
• phyzix5761 4mo ago
  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. 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, or in what format to return it. We would then spend a significant amount of time with the product person trying to figure out what they really wanted. In order to get good results with LLMs we need to do something similar. Vague requirements get vague results.
  • steveBK123 4mo ago
    > 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, or in what format to return it. We would then spend a significant amount of time with the product person trying to figure out what they really wanted. This is a big HN LLM discussion divide. I am in the same no-specs work background camp, and so the idea that the humans who input that into dev teams are suddenly going to get anything out of an LLM if they directly input the same is laughable. In my career most orgs there has been no product person and we just talked directly to end users. For that kind of org, it will accelerate some parts of the SWEs job at different multipliers, but all the non-dev work to get there with discussions, discovery, iteration, rework, etc remains. If the input to your work is a 20 page specification document to accompany multi-paragraph Jira tickets with embedded acceptance criteria / test cases / etc, then yes there is a danger the person creating that input just feed it into an LLM.
    • et1337 4mo ago
      I’ve never understood engineers who complain about vague specs… if the spec was complete, it would be code and the job would be done already! Getting a 20 page spec delivered from upon high and mechanically translating it to code without any chance to send feedback up the chain sounds like… a compiler.
      • 4mo ago
• r2ob 4mo ago
  Large corporations with orthodox methodologies will take time to extract the best benefits from AI. Small teams, which still remember the original Agile Manifesto, will soar and overtake their competitors.
  • enoint 4mo ago
    Speaking about the middle, once I was shown advice from ai that a particular ticket would stall at “frozen middle management” and should be shelved until “coordination” improved. That sounds accurate, but can you imagine what a token-obsessed PM might say?
    • r2ob 4mo ago
      Exactly, corporate bureaucracy kills progress
• eddy-sekorti 4mo ago
  Yes, it is true for large enterprises, but not for startups ans individual creators. AI is accelerating speed for anyone who is not stuck in Corporate breaucratic processes.
• sunir 4mo ago
  Our current most popular methods of using AI with software development is either waterfall or autocomplete. We aren't at a great pair programming experience yet. I presume that would improve speed and accuracy, but it's still unclear.
• shalmanese 4mo ago
  This is all substantially correct and gives us hints as to where to focus for AI to make the processes go faster. Eg: I had a product manager say to me that he envisions a future where any meeting with stakeholders that does not result in an interactive prototype by the end of the meeting would be considered a failure. This feels directionally correct to me. The other thing I expect to see is Vibecoding being the "Excel 2.0" where it allows significant self-serve of building interactive apps that's engaged in a continual war with IT to turn them into something with better security guarantees, proper access control & logging, scalability, change management etc. But the larger historical point here is that every revolutionary transition produces, in the early stages, "Steam Horses". The invention of the steam engine had people imagining that the future of transportation would involve horse shaped objects, powered by steam, pulling along conventional carts. It wasn't until later developments that we understood the function of transportation as divorced from the form. I started talking about Steam Horses originally in the context of MOOCs, which was a classic Steam Horse idea.
  • deleted 4mo ago
    [deleted]
  • skydhash 4mo ago
    > he envisions a future where any meeting with stakeholders that does not result in an interactive prototype by the end of the meeting would be considered a failure. Just learn something like balsamiq. You don't need code to build out a prototype. Just like you don't need actors and a camera when a few sketches can capture a scene.
  • sarreph 4mo ago
    Pete Koomen wrote about this phenomenon (“horseless carriages” instead of “steam horses”) here: https://koomen.dev/essays/horseless-carriages/ https://koomen.dev/essays/horseless-carriages/
• pu_pe 4mo ago
  Some organizations added a ton of process around software development because it is expensive and risky. They require a ton of approvals and sign-offs, then some managing overhead on top to check if their investment is on the right track. This approval process is bound to change by the fact that development is far cheaper and faster now. Another aspect that is not captured here is that the lawyers and subject matter experts will also be using AI to speed up their parts.
• sillysaurusx 4mo ago
  I actually have data on this. I’ve been building sharc, a Common Lisp port of Hacker News. https://www.github.com/shawwn/sharc https://www.github.com/shawwn/sharc If that sounds familiar, it’s because it’s what dang did over the course of several years. It’s taken a few weeks. I started right around May, and now it’s able to render large HN threads (900+ comments) within a factor of five of production HN performance. (Thank you to dang for giving actual performance numbers to compare against.) A couple days ago, mostly out of curiosity, I ran Claude with “/goal make this as fast as HN.” Somewhat surprisingly, it got the job done within a couple hours. I kept the experiment on separate branches, because the code is a mess, just like all AI generated code starts as. But the remarkable part is that it worked, and I can technically claim to have recreated HN within a few weeks. The real work is in the specifications. My port of HN is missing around a hundred features. Things from favorited comments, to hiding threads, to being able to unvote and re-vote. But catching up to HN is clearly a matter of effort (time spent actually working on the problem with Claude), not complexity. Each feature in isolation is relatively easy. Getting them all done within a short time span without ruining the codebase is the hard part. And I think that’s where a lot of people get tripped up: you can do a lot, but you have to manage it tightly, or else the codebase explodes into an unreadable mess. It’s true that if you don’t do that crucial step of “manage the results”, you’ll end up making more work for yourself in the long run, by a large factor. But it’s also true that AI sped me up so much that I was able to do in weeks what would’ve otherwise taken years (and did take dang years). I’m not claiming parity, just that I got close enough to be an interesting comparison point. AI can clearly accelerate us. But we need to be disciplined in how we use it, just like any other new tool. That doesn’t change the fact that it does work, and I think people might be underestimating how good the results can be.
  • rpdillon 4mo ago
    I've had a handful of software projects in my career land essentially on the day I predicted, sometimes several months out, and the commonality across all of those projects was that the specification was crystal clear. Two of them were actual ports of an existing piece of software over to a new system. And so any time we had a question about the implementation, we could look at the existing version and immediately have our questions answered about what "correct" was. I think projects where correct is very clearly defined can benefit from LLM acceleration, as you're describing here. But so much of modern software development is figuring out what the right thing to build is. And in those situations, I don't think LLMs provide nearly as much benefit.
• king_geedorah 4mo ago
  > If you were to give human developers the same amount of feature/scope documentation you would also see your productivity skyrocket. This is how I felt when I first started seeing people discuss things like AGENTS.md etc.
• delichon 4mo ago
  The promise of AI is in doing things at all that couldn't be automated before, at least economically. And when you find a use case where a bit of automated inference is sufficient and can replace human inference, it can wildly speed up a process, from when Susan has time for it, to right now.
• chilmers 4mo ago
  It’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.
  • jillesvangurp 4mo ago
    Exactly and the tools weren't even that great for most of that year. They only got properly usable around the end of last year. At least for me. I'd call it more like half a year. If you don't like the state of technology with AI tools, just wait a few weeks. Things are still changing at a quite rapid pace. The scope of what is possible seems to shift regularly. A lot of what I did in the last weeks was complete science fiction even a year ago. This article makes a few good points though. AI won't magically make processes faster. You might actually have to change the process. A lot of processes in companies are about people and how they communicate. The more people you have, the more communication you get. It's an exponential. Using AI in that context just adds to the communication noise. But if you restructure your processes you might get different results. Most companies have not really gone through that process yet. It's too early to call success or failure. And especially non technical people have mostly not yet experienced any agentic tooling at all. We've yet to see how that will change companies. My guess is that some companies will be better at this than others. And we'll see a bit of darwinism play out.
  • ares623 4mo ago
    The ever changing scene is so convenient. Makes it impossible to criticize it in any meaningful way.
• Yokohiii 4mo ago
  Delivering more complete details for a task at hand is a noble goal, but there is a problem. Programming is a logical circuit breaker. There is a wide range of incompleteness that halts development or puts the solutions in an unpublishable state. A product person has no compiler, no RAM, no database, no state machine. There is nothing that can fail. There are probably strategies to weed out some issues, but none will be perfect. We need to combine reality with computers. Computers set the constraints and we can only check if we are in bounds of the constraints by solving the problems with computers. Oddly enough AI has so far nothing to offer to improve the "product people" problems.
• titaniumrain 4mo ago
  cars are not faster than horses
• rajatpal12 4mo ago
  [flagged]
• cmrdporcupine 4mo ago
  So we have spent 40 years trying to get management and investors to understand that 9 people can't make a baby in one month. There's no point in falling under the illusion that they'll finally get it now. This will all fall on deaf ears. They're convinced they're automating us out of existence when in fact they'll need the services of people who can surf complex systems more than ever. We will be able to do more than ever and potentially faster. The issue remains that most of the things these people ask us to do and want us to do and pay us to do remains basically stupid and as TFA points out, the last mile of getting shit properly shipped isn't going to speed up. It's going to slow down. If you want to see what happens when you put people in charge who sincerely believe in the "AI automates SWEs out of existence" mantra, take a look at the code quality of Claude Code and the recent "bun rewrite in Rust" fiasco.
  • parliament32 4mo ago
    I'm very much enjoying how Anthropic is basically an anti-advertisement of how things will go if you try to run a company with text generators. The univerally-despised customer support, constant outages, hilarious bugs in CC, and now how badly the bun acquisition backfired..
• phyzome 4mo ago
  Someone I know said "software is made of decisions". <https://siderea.dreamwidth.org/1219758.html https://siderea.dreamwidth.org/1219758.html> Seems very applicable here.
• elktown 4mo ago
  People are far too charitable about an industry with chronic short-term thinking. We'll just lower the standards to whatever fits the success story.
• somenameforme 4mo ago
  I think there's an interesting dichotomy. I find that for things I'm already capable at, LLMs are relatively inconsequential. But for things I'm no good at, it's a huge game changer. For a large company, that's going to be able to hire out most needed roles for any given project, this means the overall effect is going to be relatively inconsequential. At best, they may be able to cut down on labor costs by having one guy do a mediocre job at 5 people's jobs in exchange for a worse product. Short-term gains for long-term costs, wcgw? But for a small studio, or independent developer, LLMs are a big game changer. Being able to do a mediocre job at 5 people's jobs is a huge leap over trying to get by without those jobs - relying on third party assets or other sorts of content, or even worse - doing a really awful job of trying to improv those jobs. See the UI of basically any program ever that was clearly laid out by a programmer and not a designer. Or there's the whole trying to rip off stuff from dribbble, but lacking the skills to do so. Whereas with AI, you can suddenly competently rip off everything and everybody - it's basically their entire MO.
  • argee 4mo ago
    > I find that for things I'm already capable at, LLMs are relatively inconsequential. But for things I'm no good at, it's a huge game changer. What are the chances that this is the Gell-Mann amnesia effect? Sounds like the textbook definition of it. Personally, I find the exact opposite to be true. LLMs only help me when I already know exactly what I'm doing.
    • simondotau 4mo ago
      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.
      • argee 4mo ago
        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.
• hydra-f 4mo ago
  Handholding is an issue which is affected by 3 factors: the model, the tooling and the human expertise. Out of the three, the last is the weakest link, due to the fact that it takes the longest to nurture. Once tooling (e.g. agent harnesses, external tools) becomes more mature and consistent, the other 2 will become less of a bottleneck. If I were to take a gamble here, I would argue that development will at one point reach the more ideal scenario, whereas the project planning, the scoping, will become longer. Also, the documentation section will take almost the same as the development, slightly longer at the edges. The new ai-assisted era will most likely push companies to adopt a Waterfall management, rather than an Agile one.
• fHr 4mo ago
  Maybe my existing processes not but it can help you enormously. I literally found a problem with AI analyzing packages in Wireshark and it hinted and steered me in the direction in me finding the error setting in the end. Could a senior network guy found it? Yes but probably not even faster. Did I as a L2 SWE not being familiar with much of networking and the companies stack(was like 1 Month at this company) found it with no AI, absolutely no.
• hibikir 4mo ago
  Every large corporation is stuck in communication problems and approval processes. They have grown so large as to have minimal alignment between what the company attempts to produce, what makes the company profitable, and what people actually do. Enshittification, The Gervais Principle, Bullshit Jobs. Pick your favorite, flawed way to look at what is going on, it's all blind people touching different parts of the same elephant. The way AI makes your processes go faster will have little to do with cutting software development time in itself, but by letting an organization be made with fewer people, which in itself lowers your misalignment issues. A giant company of 200K people will still be about as messy as one today, but you might be able to do a lot more with the same number of people, just like a lone programmer today, without AI, already does quite a bit more than anyone could do by themselves the 80s. Maybe some of the advantages are that you don't need quite as many developers, or maybe you can use a smaller marketing team, or you don't need to spend that much time answering questions, because an LLM is doing it for you, and it's tracking what it's been asked of it, turning the questions into product research. Either way, the gains come from being able to run leaner, and therefore minimizing organizational misalignment.
  • TeriyakiBomb 4mo ago
    While this is true, it doesn’t stop businesses being overzealous with AI. It’s a compound issue of a decade of ZIRP, grow at all costs and then covid overhiring and AI is suddenly poised as some kind of magical panacea. The broader issue is the sheer number of businesses that build massively overcomplicated stacks, bought heavily into bandage solutions like AWS lambda, got on dumb tech bandwagons like big data, nosql etc. This is just another one. I think you can engineer yourself into being leaner, in some businesses AI will help but we’ve had over a decade of “we can just add more complexity” and it just does not work. I’m a rails guy. People forget for every unicorn there’s 10 9 figure businesses just ticking away on some niche with a VPS, rails and like 4-10 devs.
• bhuvisingh 4mo ago
  [flagged]
• sajithdilshan 4mo ago
  This is so true. Recently, I’ve been working on a project involving almost every department, including Product, Engineering, Compliance, Finance, etc.. We kicked things off late last year with a many meetings. Product was primarily coordinating between the teams, but engineers also met directly with non engineering departments to explain technical details and accelerate the timeline. However, while the engineering team successfully fast tracked development, UAT, and production testing largely thanks to AI other departments only began digging deeper into the project toward the end of April. To be fair, they do use AI in their workflows to some extent, but they haven't adapted their processes to keep pace with engineering's increased productivity. In my opinion, this lag is mostly because many employees in those departments are older and hesitant to change their routines. While I understand that resistance to change is a natural human trait, what comes to my mind is this beautiful German adage, "Wer nicht mit der Zeit geht, geht mit der Zeit" which loosely translates to, "Who doesn't change with time is left behind by time"
• pron 4mo ago
  There is another problem. For developers, productivity means "functionality produced per hour of work", but that's not what productivity means for businesses. To them, productivity means "money produced per hour of work", and because AI costs money, it is this number that needs to go up (not quite, as it's more "value" than money, but until the economy adjusts they are similar). Even if we could considerably reduce the time between releases and/or do it with fewer people at scale across the industry, for it to pay off, we'll need to see a corresponding rise in demand for software and/or features. Another option is that lower software costs would significantly reduce the cost of whatever non-software product the software supports (manufactured good, electricity, services, telecom etc.) but I don't know in which industry the cost of software is a large portion of the overall product cost. And there's another thing. A company that makes tractors can't produce food without land. A company that makes metal machining equipment can't make cars without the raw materials. But a software company that makes software that automatically makes software could just produce the result software itself rather than sell the software-making software. If AI ever reaches the point it makes software at a marginal cost that's not much higher than the cost of the AI itself, what would be the incentive of selling that AI?
• stldev 4mo ago
  The METR report continues to hold up. I would add "No Silver Bullet" to the reading list. Careful who you share this information with- better to roll with the kool-aid drinkers when they're holding the cards.
• codesentinel 4mo ago
  [flagged]
• hectdev 4mo ago
  [flagged]
• aminekhd 4mo ago
  [dead]
• max_flowly_run 4mo ago
  [flagged]
• Lapsa 4mo ago
  "In 1975, Dr. Joseph Sharp proved that correct modulation of microwave energy can result in wireless and receiverless transmission of audible speech."
• airstrike 4mo ago
  LLMs are great at two things: search and speed of generating code. I get most value from them when I'm asking it to either fill in the blanks of something already half implemented or when I need some feature in a given context/language that only exists in other languages
• neversupervised 4mo ago
  It’s completely wild to me that lifelong programmers come into contact with agentic coding and come to the conclusion that their jobs are safe for one reason or another. AI will definitely be able to write entire software, inclusive of figuring out requirements and asking the right questions. It’s not that far already. Why is it that everyone looks at weaknesses of a technology that didn’t exist a couple years ago instead of appreciating the incredible rate of improvement? I know why, because it’s inconvenient to the narrative of what makes us valuable. But still, our job is to turn ideas into a sequence of logical steps. Why can’t we do the same when forecasting the impact of AI on our jobs?
  • sevenzero 4mo ago
    >...the incredible rate of improvement? Because the "rate of improvement" is only astonishing in well understood areas and really only astonishing if you yourself are not that great at what you do. Speaking for myself here, my job is extremely safe given that my boss doesn't wanna sit there and prompt AI all day and i work in a fun little 4 person company. We already have plans for the 3 next years which involve me :-)
    • themgt 4mo ago
      Because the "rate of improvement" is only astonishing in well understood areas and really only astonishing if you yourself are not that great at what you do. This is a bold vague claim many on HN make, but never put back-of-napkin numbers on. e.g. do you think agentic Opus 4.7/GPT 5.5 are 95th percentile coders but you're 98th percentile? Or are you saying you're a middle-of-the-road 60th percentile coder and AI is 20th percentile so only 20% worst programmers should worry? Let's be specific about the claim being made.
  • timacles 4mo ago
    > it’s not that far already Do you have examples of (almost) entire software written by AI? AI excels at make toy versions of software, prototypes and skeletons. The closest things to fully functioning software created by AI that exists are all done by people that are experts in that particular field, ie software engineers.
• regnull 4mo ago
  You know, AI could help you to produce better-looking charts.
• nijave 4mo ago
  While I agree with the article, I think AI can speed up all steps in the Gantt chart. It's really good about aggregating and summarizing information. >Process blocked on human inputs Have AI check chat, email, issue tracker and see who it's blocked on and what latest status is. It may not save a huge amount of time but it can dig through the info pretty quick. >Exploration Once again, have it scour issue tracker, chat, customer suggestions, product documentation and summarize history and current status. Much quicker than setting up new meetings to try to rediscover and organize existing info. Another use case, have agent build prototype, hand to people, have AI summarize and integrate feedback. Claude or ChatGPT + Slack MCP + Jira MCP + Google Docs MCP + internal knowledgebase MCP + gh (GitHub) CLI + Datadog MCP--really 1 MCP per process in the Gantt chart--has been a huge boost at work just digging through context scattered all over the place and summarizing. That said, it definitely still needs supervision and hand holding along the way
• simonreiff 4mo ago
  The bottom line is that AI is genuinely useful at prototyping new features, acting as a sounding board, and generating quick initial drafts, even if the quality isn't uniformly excellent. It seems plausible to conclude that it will only take a little additional effort to refine and improve that initial draft to achieve excellence and truly high-quality, production-grade code. In reality, whole processes to build properly with AI-generated outputs and that mitigate thoroughly against the fundamental limitations and constraints of AI agents (many of which are not well understood even by daily users) really need to be invented and implemented. I think many things that were true prior to AI are still true or more so today, but new workflows and processes altogether are needed. I suspect that comprehensive, detailed planning and specification documentation must be assembled in advance of beginning code (akin to waterfall) when working with AI agents. Furthermore, I still believe customers and other key stakeholders need to be involved early and often so that the product can iterate towards a better ultimate end state (i.e., agile). Unlike prior to AI, it's completely plausible to implement both types of approaches, and they aren't mutually exclusive. We can do comprehensive, exhaustive, thorough planning and specification documentation prior to handing off to dedicated engineering and products teams, AND we can work quickly and iteratively via sprints that aim for frequent meetings and updates with the stakeholders that matter. I also think the same validation gates that mattered before -- linting, SASTs, but most importantly, comprehensive automated testing that gets run locally and in CI/CD and is regularly expanded to cover all expectations about the behavior and structure of newly-implemented functionality -- continue to matter now, more than ever. New tools and processes also must be built to make human review, the single biggest bottleneck in software development today, more simplified and streamlined, and less taxing. I think tools like CodeRabbit and Qodo can help automate and expedite the code-review and approval processes, but they would be even better if they were working off more surgical and tiny edits. Bloated, verbose AI-generated code edits are the core problem here. Process management techniques to mitigate the problem of AI code overload can prohibit the submission of AI-generated PRs, require senior engineer approval of any PRs prior to merging, or block the maximum number of lines or changes made. More sophisticated processes like Graphite's stacking of PRs are genuinely helpful in breaking down massive PRs into smaller chunks. Finally, precision-editing tools for AI coding assistants like HIC Mouse (full disclosure, my project) that move beyond the existing options available to AI agents of whole-file replacement or exact string-replacement to enable agents at the editing-tool layer to perform surgical, tiny changes that don't touch any unrelated content, giving agents specialized visibility, recovery, and next-step guidance mechanisms that safeguard AI workflows, can materially reduce AI code slop by alleviating burdens upstream of code reviewers, both automated and human. The bottom line: Shipping secure, production-grade code was never easy and always took a long time. It's not necessarily easier now just because certain aspects to the overall process can be generated much more rapidly. Arguably, the hardest parts like human review and approval are much harder now -- not easier. Solutions will take hard work and must be tested in the crucible of real-world enterprise usage. I am guessing that companies that deploy successful processes will be wildly profitable. Those that don't, including well-established incumbents, will fail. I do think AI absolutely can give organizations a game-changing boost in development velocity of genuinely high-quality code that might even be better than anything ever created previously. I also fully agree with the author that for many organizations, AI will not make their processes go faster and may even slow things down.
• shay_ker 4mo ago
  > "requirements were always the bottleneck" > "faster typing won't make you faster"..... I understand a Deloitte consultant has specific incentives. But let's first try to answer a baseline question: why do some companies have thousands of software engineers? What do they all do? And then, a follow-up: what is actually the bottleneck at most companies? What causes "requirements gathering" to take long?
  • JackSlateur 4mo ago
    What do they do ? Give power to their management ? "I am responsible for 50 people, I am important". "I managed over 250, I am important, give me money".
  • Etheryte 4mo ago
    Isn't the answer to both questions straightforward? Real life is complex and has nearly infinite degrees of freedom. This means it's hard to approximate in software. Over time, real life, your understanding of it and your approximation (the software) all change. Keeping the approximation accurate enough that it's useful takes considerable effort since now you need to understand both the real life and the previously existing approximation of it.
  • RaftPeople 4mo ago
    > And then, a follow-up: what is actually the bottleneck at most companies? What causes "requirements gathering" to take long? Complexity. In my experience (medium size businesses, i.e. 200 million to 2 billion annual revenue) we're trying to understand how a complex set of systems and business processes and different businesses (external partners) interact and then trying to morph all of that into a shape that now has capability X layered on top or in the middle. Here's a concrete example, business X that makes their own products and has retail stores as well as an ecom site wanted to add the ability to put complementary items built by other companies on the website and have them drop shipped from the vendors to the consumers. The final solution involved 21 different interfaces between 4 different systems (ecom system, store system, omni channel system, external drop ship mgmt system) as well as a new internal system to manage this activity. It's takes a significant amount of time to understand and solve for all of the low level details.
• ivansmf 4mo ago
  The article severely underestimates deployment times for large, world wide services. Usually the strategy is to have a smaller "blast radius" for deployments and going in stages that are also usually time bound ("let it bake"). It also does not account for outages and fixing things you only find in deployment. Programming languages like Python it using injection in Java (e.g. using Guice) either need pristine testing, and all test teams were converted to dev 20 years ago, or have a magical way to destroy all the help compilers and static analysis can give you. So yeah, you take the 4 weeks of development from your 6 month deployment, then add 6 weeks of debugging and retries by using AI. You're welcome that will be 3 million tokens, of which you wrote 1k, the rest was system prompts and "reasoning", which you do not control. This whole AI space is highly fixable, but requires investment no one seems to be willing to do, particularly in areas that were mistakes from the past.
• outside1234 4mo ago
  Research tells us that only 15% of software engineering is the “writing code” part. It looks like we are rediscovering that.
• jldugger 4mo ago
  Fascinating, I was literally thinking about how to communicate this to coworkers the other day, literally down to the gantt chart. Now I don't even have to make one =) > We are now talking about software development, but this is applicable to all processes that take longer than you would like. Indeed, it's kind of a generalized version of Amdahl's law. Since we only speed up a portion of the work, there are upper bounds on time saved. Worse, work in progress tends to bunch up at a specific point: code review. A coworker of mine literally complained two months ago now that nobody was reviewing code (and that it was blocking his work). I'm not sure review delay has actually gotten better since.
• bicepjai 4mo ago
  Recent NYT podcast showcased how China and the US are putting time, effort, and money into using AI. I have to say I liked China’s approach of AI percolation into the economy than US approach of walled gardens with cloud. https://podcasts.apple.com/us/podcast/the-daily/id1200361736?i=1000767170935 https://podcasts.apple.com/us/podcast/the-daily/id1200361736...
• lmeyerov 4mo ago
  It's felt awhile similar to what we see in parallel computing: - shift towards throughput-oriented vs latency-oriented. Can juggle more tasks, but increasingly hard to speed up individual ones. - strong scaling is tough. Might even see slowdowns for individual tasks, so reliable benefits come from being able to juggle more and eat the per-task inefficiency - amdahl's law: we can't speed up tasks beyond their longest sequential (human) unit, so our work becomes identifying those bits and working on them. Related: you can buy bandwidth, but you can't buy latency
• reenorap 4mo ago
  This blog post is nonsensical and the arbitray time boxes aren't realistic. Not all development cycles or features require legal input and I would hazard most don't, even in Big Tech. Documentation takes seconds to generate. Same as tests. Feature development could take minutes to hours depending on how you iterate it. These days, all we do now is just think of a feature and add it within an hour using AI. We have a process that is a year old now that is fixing bugs that would have taken us hours or days and it spits out a fix in about 10-15 minutes that is 95% accurate. 5% is garbage, but 24 months ago, 95% of it was garbage so the progress is staggering. The longest pole is code review which is all human, but that will all be automated soon. Not everything will be much faster, but most processes will be 1-3 orders of magnitude faster. To ignore this or find excuses why LLMs/AI won't speed things up or remove the need for large swathes of humans is delusional and cope-ism.
  • garyfirestorm 4mo ago
    In my world automotive/mechanical engineering we are also observing how much AI can help you build a mental model, fetch unstructured data and help shape your understanding of the system. Onboarding new engg. figuring out what is what in the system. It could have taken hours before to fetch right info, now we are able to do this in seconds.
• ddosmax556 4mo ago
  This article assumes that AI only has an impact on the development phase which is certainly not true. It can speed up every part of the step. Including ideation, legal, documentation, development, and deployment. Ideation: Throw ideas back & forth, cross reference with knowledge bases, generate design documents. Documentation: Generate large parts of docs. Development: Clear. Deployment: Generate deployment manifests, tooling around testing, knowledge around cloud platforms. Every single step can be done better & faster with AI. Not all of them, but a lot. Even development. Yes some part of your job involves understanding the problem better than anyone & making solutions. But some parts are also purely chore. If you know you keed a button doing X, then designing that button, placing it, figuring out edge cases with hover & press states, connecting to the backend etc - this is chore that can be skipped. Same principle applies to almost all steps.
  • echelon 4mo ago
    The onus isn't on people using AI effectively to prove it to others. In fact, these disagreements and disbeliefs create opportunities and salients in the market.
    • obsidianbases1 4mo ago
      Indeed. I suspect most effective AI users are quietly making real progress toward their objectives. Anecdotally, I see a lot of problems/solutions content about AI that doesn't reflect at all the challenges I face. But trying to tell people that there are other ways of doing things, especially when it conflicts with token-maxxing, is a lost cause
    • ddosmax556 4mo ago
      I know and I agree. It sounds incredibly arrogant but it's frankly is a bid sad to see how much HN is lagging behind AI adaption. It's been 90% noise over the last 3-6 months about problems that aren't truly problems if you really look hard at what AI is capable to do already today. It's mostly ppl & process problems. I could post a comment like the one above below almost every article on AI. But it is what it is. It's an opportunity for anyone who doesn't bite into the cynical tone here for sure.
• slashdave 4mo ago
  > Every software developer knows that you can’t make projects go faster just by typing faster. You know, typing fast and accurately is kind of important. The new speed skill that developers now need is speed reading. LLMs just make copious amounts of output (from tests, documentation, diagnostics). They also produce code so quickly that a skill for focusing on weak points is so important.
  • deleted 4mo ago
    [deleted]
• brkn 4mo ago
  This post makes it sound like an engineers role is only the collection and filling of feature gaps, but leaves completely out that an engineer is also responsible for the feasibility of a feature. If you get a request for a feature, but you are aware of the current system's limitations, it is your job do come up with a solution which fits into the business sides given frame. But nowadays engineers have been so much drilled that showing resistance to management is portrayed as a lack of skill and not a lack of trust from management into their staff. And when it is clear that your management actually doesn't clear it just tells you how much of the self proclaimed mission is the real motivation behind these people. If the acceptance criteria of management does not meet your principles you might not be the right fit and if, in my opinion, the ac of management are mostly based on the next promise made to investors or by sales to prospects, their goal is to make money and not to develop a quality product.
  • huflungdung 4mo ago
    [dead]
• ChicagoDave 4mo ago
  Another post that doesn’t understand effective use of GenAI in software engineering. The assumption is that there’s no way to extract speed and accuracy matching business models. This isn’t obviously false to the majority of dev/arch’s because most are vibe-coding, but it is extremely obvious to the minority that has focused on accuracy first THEN speed. https://devarch.ai/ https://devarch.ai/
• dakolli 4mo ago
  I just spent a few days cleaning up someone's web app they created with Claude Code. There was more than 30k lines of DEAD code, and I was able to cut the code that was actually being used down by ~30-40%. If I just wrote this app myself It would have taken a day or two. LLMs are not helpful, they make everything worse. They make you worse, or reduce you to average at best. I really just don't see what ya'll are seeing. I have access to every model with no limits, Its not issue of "holding it correctly" I can assure you, I've tried. Yes it can create very small programs with low complexity, but anything of any size ends up as a literal Eldritch horror or with so many subtle bugs that make life miserable. I actually hate all of you that are pushing it onto people, its such a lie.
  • moron4hire 4mo ago
    Same, exact experience here. This one non-technical PM guy at work used Codex to develop a project I was expecting would fall on my plate. He asked me to do a code review on it. What it produced was riddled with SQL injection vulns and the UI was complete garbage. Off of that example, the key stakeholders on my project are demanding I start vibe-coding everything. I raised the security flag and now they are saying, "well, now we have a prototype and real development can continue," but it's clearly just to mollify me and make me shut up, because no such development effort on that other project has been planned, scheduled, budgeted, etc. They are kind of just sitting around on it, hoping they can get everyone distracted long enough to sneak it out the way it is. "But he did it in a week!" Yeah, it would have taken me only a week to make whatever of value actually was in that project. The reason our software projects at our company take longer than a week is not because of code, it's because we have an IT department that blocks production deployment of everything unless you literally get the president of the company to make them do it. That's not a repeatable process that every project can leverage. There was another project another more-technical-but-not-a-developer guy (he knows how to use MS Access) did in Claude Code where, yes, Claude could read a bunch of PDFs he got from the client, get the salient details out, made an Access database out of it, and made a static HTML website out of it to make those documents easier to search and navigate. But again, the UI was complete, unadulterated garbage. And, the best part, he spent several weeks on just getting Claude to reliably process the entire set of documents. He never could quite get it to end-to-end do the entire process. It kept missing documents and reprocessing the same ones over and over again. A for-loop to iterate over a directory of files would have taken 2 minutes to code by hand and he got stuck on it for over a month. AI will speed us up, my ass. Look, if AI means I never have to open another PowerPoint from a client to read a "quad chart" on one particular slide to get the data I need to do my project because my client doesn't understand that PowerPoint is not a data transmission format, fine. I'll be happy with just that: AI vision as a library I can call out to from my code, just like we've been trying to do with OCR but traditional OCR sucks at the job. But there's a bigger drumbeat than that and it ends in dilettantism and laying off the junior analyst and developer staff. I will be no party to that.
• bob1029 4mo ago
  I think it will. The primary issue is simply that developers are the most immediately impacted by this technology. The combination of being able to adopt, willing to adopt, and the tech actually being incredibly good at developer related concerns is unique. The rest of the business will eventually catch up. I'm watching it happen in real time. It is agonizingly slow in most places, but it is happening. The developers being able to drain a one year long work queue in an afternoon is meaningless if the rest of the business cannot absorb the effects of that work in the same timeframe. The business will not leave your idle work queue on the table for long though. Keep pulling a vacuum on them and they will fill the space eventually.
• lakshjain1705 4mo ago
  Great explaination it is true that AI doesn't generates the correct programs everytime but sadly it has become a common practice to involve AI in every aspect of Software Engineering, and it is true that it made Software Engineers to become product manager and their work has become to debug and test the entire codebase which adds more frustation. Everything is OK, but the size of Gantt chart should be expanded.
• johnwheeler 4mo ago
  What a naïve article. People don’t write software this way anymore. A Gannt chart? We don’t use those anymore. People have to stop promoting this narrative of the AI doesn’t make you move faster as it’s not helping anybody. I get it. We all worked hard for our skills and it’s really difficult watching them get automated away, but it’s been this way since the printing press assembly lines and the industrial revolution itself. Things change, and you have to adapt to them and stop thinking about it from a centric point of view. The narrative people should be pushing is that you can build great things with AI. Of course you might not have a job for a while and yes, that’s a big deal but it doesn’t mean that AI is wrong or stupid. It means you have to adapt.
  • ikeke 4mo ago
    Where’s all the great products that have meant to be come about because of llm’s? At some point the “oh the models only improved recently” won’t work anymore.
• boron1006 4mo ago
  At least where I am we can’t and shouldn’t know all the requirements of a project beforehand^. Every project is an iterative learning process between the users, product and engineers. The problem is if everyone uses AI to replace their thinking it breaks that process and no one learns anything. ^ I say shouldn’t because I work in research engineering. Most of the needs of our users are pretty unique. We’ve had people come in and try and specify every piece of work, -and ended up building a crud app no one wanted or used.
• angarg12 4mo ago
  > 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 can get detailed enough requirements and specifications that you can one-shot a perfect solution needs to die. In my experience AI has made us able to iterate on features or ideas much faster. Now most of the friction comes from alignment and coordination with other teams. My take is that to accelerate processes we should reduce coordination overhead and empower individuals and teams to make decisions and execute on them.
  • pron 4mo ago
    > It's 2026 and the notion that you can get detailed enough requirements and specifications that you can one-shot a perfect solution needs to die. It's 2026 and the idea that even with detailed-enough requirements you can one-shot even a workable (let alone perfect) solution also needs to die. Anthropic failed to build even something as simple as a workable C compiler, not only with a perfect spec (and reference implementations, both of which the model trained on) but even with thousands of tests painstakingly written over many person-years. Today's models are not yet capable enough to build non-trivial production software without close and careful human supervision, even with perfect specs and perfect tests. Without a perfect spec and a perfect human-written test suite the task is even harder. Maybe in 2027.
    • SirHumphrey 4mo ago
      Most software is much simpler than a c compiler.
      • pron 4mo ago
        A workable C compiler is a ~10-50KLOC program, and a fairly simple one at that (batch, with no concurrency or interaction). That Anthropic's swarm of agents wrote 100KLOC before failing is a symptom of the problem. It's certainly possible that many programs are in the sub 5KLOC range, but it's definitely not "most software". Plus, almost no software has this level of detailed spec, ready-made tests, and a selection of existing implementations of the same spec. My first thought when reading Anthropic's description of the experiment was that it is unrealistically easy. It's hard to come up with realistic jobs in the 10-50KLOC range that would be this easy for an LLM. That it failed only shows how much further we still have to go.
• whatever1 4mo ago
  It definitely made the process of testing features with the users 10x faster. You can iterate, test and throw away bad ideas much much faster. The proper implementation and design still take time, but still faster in systems with a lot of available resources online.
• netcan 4mo ago
  >What people typically don’t do is look at why this is taking so long, and even more importantly: long duration does not automatically mean the problem originates there. To some extent, we tell as many lies as we can get away with. Some answers are more convenient then others. "Why" this is taking so long, like "why did this fail?" are prone to broadly agreed lies. Sometimes this is for obvious blame liability reasons. Often, this is because the lie conflicts with some "meta." One such fallacy is the idea that software=value. Code= money, because it cost money to write. Features=revenue. Etc. Irl.. startups produce features very quickly because they actually need features. They start with zero features. But... LinkedIn, visa or even Facebook.... What they are short on is opportunities to develop code with value. Ie... Something that will increase revenue. FB aren't resource constrained. They're demand constrained. If there were a "write code, make revenue" opportunity available... they'd have taken it already. This totally conflicts with the experience of working somewhere. That's because you have wishlists, road maps and deadlines.... and it always appears that demand for code is sky high.
• q8zd3 4mo ago
  Honest question: Does anyone know about any quantitative study or analysis on productivity gains using code assistants? Asking for numbers comparing between the "pre AI era" and now. Also, I have the impression that LLMs bring some gains or benefits for individuals but not relevant enough at the organization level.
  • adrianN 4mo ago
    I believe it is very hard to quantify „productivity“. I’m sure that for suitable definitions you can find gains from coding assistants. Personally I get more code written and more features implemented. Yet I’m very wary of coding assistants because I believe they deal a fatal blow to my ability to understand the system. All LLM generated code is (at best!) code that was written by an intern which I just helped with the design and reviewed (unless productivity expectations cut down my review time and I get LLM assistance for reviews too). My grasp on the inner working of that code is much more tenuous than had I written it myself. I will never become an expert by just reviewing code and prompting. For a while this is not a problem: I can work with my current mental model. But every generated PR erodes my expertise a little bit. Eventually my mental model won’t fit anymore. So how much of that model maintenance should I count into my productivity metric? Does that even matter or will the next model be able to reason well enough that my mental model doesn’t matter?
  • Supermancho 4mo ago
    Followup question: Does anyone know about any quantitative study or analysis on productivity without using code assistants? (as a baseline)
  • Izkata 4mo ago
    Here's the big one that was being passed around months ago, which nowadays usually gets dismissed out of hand because of when they did it (while ignoring the relative finding): https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/ https://metr.org/blog/2025-07-10-early-2025-ai-experienced-o... Here's a slightly more recent one focused more on comprehension/learning than productivity: https://www.anthropic.com/research/AI-assistance-coding-skills https://www.anthropic.com/research/AI-assistance-coding-skil... Metr attempted to redo that first one to get trends over time, but couldn't recruit enough developers to get reliable results for it.
• osigurdson 4mo ago
  It goes faster, at least for a while, if you don't look at the code.
• jorisw 4mo ago
  I could see two ways out - People need to be trained to use AI in ways that we don’t call slop, meaning half is made up by the LLM - To this effect, LLMs should be trained to ask for more input before offering any kind of final output
• lysecret 4mo ago
  Ai in my mind is a new primitive of computing, like compute a db blob storage.
• mactavish88 4mo ago
  I don't think we're going to be able to have rational conversations about this with C-level folks for quite some time. They mostly seem too wrapped up in copying each other to think clearly, and it's only when the bottom line starts suffering that we might be able to start asking some questions about their strategy.
• dsr_ 4mo ago
  Insofar as I have seen anyone get actual productivity boost from AI, the process went like this: We have a person who wants, effectively, a formatted report generated on demand from four sources. The current interface is four different programs, all of which were written by different groups inside the corp, but they also all draw from the same or similar databases. There's a unified login, but each interface has its own permissions. The company brings in an AI initiative and soon enough drops all security restrictions for the AI's access to the databases. The new formatted report gets generated through the use of a few tens of thousands of tokens each time, and about 5% of the time synthesizes non-existent data. A competent DBA and application programmer could have spent a week doing the same thing, producing a program which would do the job faster, cheaper (at run-time), secure and in a way which could be extended and debugged. But DBA and application programmer time is expensive up-front and the execs are gung-ho about the stock-price now that they are hip and trendy.
• himata4113 4mo ago
  This is wrong already because it makes the assumption is used only for development. No. AI is used all the way from the very start to the very end and after.
• r0l1 4mo ago
  [flagged]
  • emp17344 4mo ago
    This is an obvious bot. I hate this crap.
    • r0l1 4mo ago
      No, german speaking fellow using ai to fix my grammar. If you're nearby Munich, feel free to visit us in person :)
  • prh8 4mo ago
    Try commenting without using AI
    • r0l1 4mo ago
      No my choice.
• spoaceman7777 4mo ago
  I'm sure this take will age well.
• runtime_terror 4mo ago
  I think the thing that gives human developers a leg up is the ability to read between the lines of a spec and have the ability to intuit the expected output more than an LLM in many cases. The human their cumulative experience over a career of the nuances behind every decision and their evolved context at their given company. This context allows them to take that one-line spec and extract tons of detail from it by knowing who wrote the ticket, what was the "trigger" for the ticket, what other work is being done in tandem that might need to be incorporated, etc. LLMs can be given this context but it's a manual process of transcription into its prompt/memory/skills and that content must be continually updated and refined. It just pushes lots of work to spec writing from the more intuitive nature of feature development a lot of us have a level of mastery over. Then you must constantly have a back-and-forth to refine the output. Any senior engineer knows that a lot of that communication is wasted energy. If I have a good idea of what I'm building I can develop the feature in a focused flow of output that I refine in an almost unconscious way because I don't need to translate intent into words, just code, and that process is incredibly automatic after years of developing software. When all the effort is placed into writing specs, re-prompting and then reviewing (often over and over again), that intuitive and automatic ability to build software degrades. Think of a time when you were mostly focused on PR reviews and not contributing to a project. You may have been able to help developers build better code, but if you were to jump into that project to contribute, there would be a real and painful effort to re-familiarize yourself and reconstruct that intuitive familiarity of the project. LLMs have many very useful qualities but so far I fear an over reliance on them can be more a hinderance than a benefit.
• justinhj 4mo ago
  Whilst the conclusion of the article certainly seems plausible, it glosses over the cost calculations and simplifies them too much. The cost of a subscription is somewhat offset by being guaranteed income regardless of usage, following the financial models of gyms. Whilst api costs represent both the convenience of on-demand pricing and the scale for applications with many users. Further, the costs of api and subscriptions need to cover the operating costs of the business, the massive SOTA training costs as well as the costs of inference. The true cost of serving tokens is buried in all of that in these enormous, opaque companies.
• siliconc0w 4mo ago
  People don't really understand that non-trivial software development isn't even 50% coding. The coding step is generally the 'easiest' part and given to Junior developers. In a large org most product changes span multiple systems and human operations. Seniors and even mid-level generally spend most of their figuring out how to shape the local priorities into a new arrangement of the existing cybernetic entity and then getting buy-in on that new vision given these other teams have their own priorities. This naturally involves a lot of tradeoffs and politics - senior engineers know to avoid adding 'weight' to their airframes and fight hard to avoid adding scope to the systems they're responsible for or divergence from their intended direction of travel. So compromises have to be struck or escalations to management to choose between priorities have to play out. Maybe AI solves that as well but that is a lot more difficult lift.
  • fastball 4mo ago
    LLMs mostly only being code-writers was true a year ago, but it is not true now. Now they are tool-callers, which means a coding agent can effectively: run lints/typechecks/tests (and fix resulting errors), dig into observability platforms to identify root cause of isses (e.g. on Sentry or similar), run benchmarks to identify slow code / hot paths, keep systems up to date by reading migration docs (and applying them) for new majors of consumed libs, etc. So sure, if you have none of these things set up to back-pressure agents and help them better understand the system, then they will just be dumb LLM code writers. But you can definitely go a lot further than that with the improvements that are rapidly happening to models and harnesses.
    • kawaiikouhai 4mo ago
      uh. I think code-writing is just colloquial for "low level implementation details". What he's pointing at is 1. LLMs have no social pull. Thus all the anti-AI outrage (LLMs cant defend themselves) 2. AI is shit at expert-lvl planning and higher level stuff (vision, architecture).
• gwbas1c 4mo ago
  I've found that AI is extremely useful when coding: For example, a task that used to take 3 days I can now do in about a day, in part because I can do things like have the agent write tests, or because I can have the agent start from some higher-level instructions which I can then clean up and debug. BUT: The article is 100% right that I spend a lot of time doing other tasks: Reviewing other teammates' work, interacting with colleagues, planning, ect. AI isn't quite as helpful there. For example, I find that co-pilot code reviews don't add a lot of value; and the AI isn't good at judging a UI. Maybe we'll get there soon? It's starting to look like the biggest challenge with AI is learning how to use it correctly.
• ryanmcbride 4mo ago
  Been having conversations like this with a client I've worked with. They get approved by corporate for us to use claude and ask how much faster we'll be able to move with it. I tell them "Us engineers will probably be able to deliver some of our stuff faster but it won't have even a slight effect on the actual deliverable because we've never been the bottle neck", it's the fact that the process to get an S3 bucket allocated takes (not exaggerating) 4 weeks there.
  • BoxedEmpathy 4mo ago
    This matches my experience. My previous position was at a FAANG and sometimes getting a VPN link setup for a new host would take a month of approvals. Writing actual code was maybe 10-20% of what I did. Most of it was meetings, design review, authorization requests, etc
• pvtmert 4mo ago
  Absolutely lovely article. > Software development is about translating a problem into a solution that a computer can understand and automatically resolve. Preferably in a secure and scalable way. True, meanwhile software engineering puts optional bit into the requirements bucket. (ie. Secure & Scalable) --- For the problem description and gathering requirements sentiment; I don't think we'll _ever_ have a 100% proper way of doing this. If we did, we'd basically solve any and all problems in the world. Nevertheless, I think AI can help with investigating and exploring the problem space. Especially when the problem is an already solved thing that the prompter hasn't gained enough expertise yet. Moreover, I think (and keep mentioning) we will see different kind of models in the near future. Those would be more specialized per industry, per language (both programming and human languages), even per field. Those will open up newer areas for employment & job market. Something like an "AI-trainer" but more of a knowledge-worker style. Although this can also be automated with LLMs, the limits on context length/size plus amount of compute required to re-train the models to iterate faster both are quite heavy.
  • rustystump 4mo ago
    That last paragraph sounds like a meta vp explaining to the engineers why it is important to log all their keystrokes and eye movements. Pinky promise we wont fire you. The trend I DO see at least based on JDs is a whole lots of “agents” which are glorified claude code but in the cloud with tools focus on a given industry or domain. If this is what you mean, then you are correct.
• KaiShips 4mo ago
  [flagged]
• sonnyproto 4mo ago
  I really love AI to be honest. I feel like I'm using it to achieve much more than I could ever dream of. It changed my life!
• sonnyproto 4mo ago
  To be honest, I think my process go 10x faster with AI. It's literally visible lmao.
• giancarlostoro 4mo ago
  AI is not supposed to bypass the process, but it can speed up things nonetheless, it can help with refactoring, writing boilerplate, finding errors you never even spotted before, and things that linters cannot catch. I see so many comments that seem to me like either they don't use standard known processes, or they assume AI doesn't need you to follow the standards. Can I ship more code and features? Absolutely I can, if I have a good set of requirements, and thorough testing. All AI written code needs to be reviewed and tested, and should be in discrete commits and pull requests, anyone pushing a PR with thousands of lines of code is a red flag, you wouldn't do it without AI, why would you do it with AI? Major rewrites / refactors are the only known exception, and even then I would argue that these should still have discrete commits you can switch to so you can see how things changed, and make a more informed decision. If you show me a massive one shot commit or PR I will deny it. Break it down into bits a normal developer can audit.
• vips7L 4mo ago
  It always comes back to Amdahl’s law.
• a3m_router_dev 4mo ago
  [flagged]
• doginasuit 4mo ago
  The general conversation on LLM assistance with coding is lacking nuance. > Yes, AI can generate code quickly (whether that’s a good thing is open for debate), but that doesn’t mean it’s generating the correct code. It really depends on what you asked it to do. Add a new feature? I wouldn't touch that code with a 10 foot pole. Create a service with an example of another service in your project that does something similar? It is going to nail that pretty much every time in 2026. Someone else put it really well: use LLMs as a fast typer, not a fast thinker. Don't have it generate any code you can't verify at a glance. Call in small completions that don't span more than a couple files, everything else is vibe coding.
• deleted 4mo ago
  [deleted]
• robertnowell 4mo ago
  > Every software developer knows that you can’t make projects go faster just by typing faster. If that were the case we would all be taking typing lessons. ^ this statement is false. typing infinitely fast would make software development much faster. typing infinitely fast would not make shipping useful products and features instantaneous, because there is product, technical, and organizational uncertainty that requires iteration and "cross functional collaboration" to figure out. but ai can make each iteration step a lot faster.
• 0xbadcafebee 4mo ago
  The Gantt shown is an example of Waterfall, or some other method where there's a final destination for the software. 99.999% of software today is not made that way. In modern software development, there is no destination. On a 2-week basis, the business decides to change what the software is supposed to do. New features. New integrations. Changed features. Upgraded/replaced components. Larger scale. Different hosting. Over years, the software is fundamentally altered. Quality and testing goes out the window. There's a constant slog, not only of trying to deal with modifications in an ad-hoc way, but also in fighting entropy. The software becomes a living being, which gets injured, changes its lifestyle, ages. The company is a custodian of a monster, like a zoo keeper, trying to keep the depressed animal alive. Since humans are creatures of habit, all the same problems will happen with AI. But everything will be a little bit faster, and code reviews will make code a little bit better. But simultaneously, a lack of good tests and the desire for faster deployment will make everything a little bit worse. This push and pull will result in about the same level of software quality, but moving slightly faster. So in the end we will have a faster process. But nobody will really notice, because the rest remains a slog. We will all probably get burnt out faster. It's complex for a reason, and you can't remove the complexity without removing the reasons. You can't solve business problems with tools.
• forrestthewoods 4mo ago
  Here is my take on the same topic: The AI Productivity Paradox: Why the AI Multiplier is Less Than 2x. https://www.forrestthewoods.com/blog/the-ai-productivity-paradox/ https://www.forrestthewoods.com/blog/the-ai-productivity-par... My hypothesis is that AI greatly accelerates only a small portion of development. It's pretty effing great at prototypes. But the net acceleration factor is just not that large currently. Opus has been out for ~6 months. If AI were a net 100x multiplier then we'd be seeing what previously took 5 years ship in just 2.6 weeks. This is objectively not happening.
  • ikeke 4mo ago
    Boosters will say the org is shaped wrong!!
• 13moonforge 4mo ago
  [flagged]
• interpol_p 4mo ago
  There are a lot of ways that AI speeds up software development processes that aren't the actual software development. I am finding that lately I do not allow LLMs to write any code I am interested in maintaining. Or if they do, I have to micromanage them and it usually takes longer. They produce mediocre solutions, and often add redundant state ("Why did you add that state?" "Because we might need it in the future") That said, they are extremely good at: - Dev tools: creating debug tooling, debug screens, scripts that get the job done - Auxiliary development: landing pages, "what's new" screens, tedious boilerplate, gathering strings for localization - Prototyping: building full implementations quickly so you can see all the problems rather than having to anticipate them - Pure transformation: porting from one language or paradigm to another So while I agree with the article that the actual spec of the feature you are building needs just as much human thought, regardless of AI, the speed-ups around that are worth exploring An example I have from a recent feature development is adding CarPlay support to an existing app. We could have talked about it and designed it for weeks, but with an LLM I was able to get it running in my car in an hour, go for a drive, and feel it to understand whether it was a valuable direction. The code was a mess, most of it had to be thrown away, and the LLM couldn't even get the initial build functional (not much CarPlay training data, I expect). But it was an accelerator to answer the question "is it worth investing more time in this?"
• jocelyner 4mo ago
  [flagged]
• bybydev 4mo ago
  Worked at a place that spent a ton on an AI automation platform for a process that took 3 weeks. After months of setup, it still took 3 weeks. Nobody had bothered to map out that the real holdup was legal waiting 4 days for clarifications from the business side. AI can't fix bad inputs. Bottlenecks should receive predictable high quality inputs, that's the whole thing in one sentence.
• isaisabella 4mo ago
  yeah, the time on a single round of coding might decrease, but vibe coding also needs extra time on prompt engineering, and it may also requires many more rounds of refinement. In total it is not economic.
• deepsun 4mo ago
  Interestingly, there is already role for that called "business analyst". Their job is exactly what's written in here. But surprisingly, I saw them only at SWE vendors (aka head shops), probably because customers don't understand what they really want, and BAs translate their vague requirements for SWEs to work. I would say we are all gradually becoming BA/UX, even if we don't want to call ourselves that.
• 3vo-ai 4mo ago
  [flagged]
• JensRantil 4mo ago
  I guess one thing the article doesn't bring up is the fact that AI might enable more people with less coding expertise to contribute to software development. That _might_ speed things up. If that's true, you might be able to increase throughout by parallelising more of the work.
• bartimus 4mo ago
  The best analogy that made sense to me is that we used to have pistols and now we all got handed machine guns. You can fire far more, far faster, but it becomes much harder to operate accurately without collateral damage.
• danieltanfh95 4mo ago
  Make your customer, sales and product team prototype their idea with ai directly against the codebase or website before handing it to the dev team to filter off inconsistencies. Reduces communication costs.
• xiaosong001 4mo ago
  [flagged]
• wangii 4mo ago
  The idea of software developers' job is to translate specification into codes is dying. Now what I'm experimenting is to make my developers into competing project manager and developers are replaced by AI. I think the key advantages of developers, junior or senior, are the process + data oriented style of thinking, therefore way ahead of people from many other domain. I told my developers: the day of making good money by sitting in front of computer and typing is long gone. Go to the clients' scenes and build the whole thing from scratch, with some assistant from sales and domain experts. Now you are the PM.
• getmarketingai 4mo ago
  [flagged]
• michal_lola2 4mo ago
  [dead]
• par 4mo ago
  While this is all true and we keep beating this dead horse, the other reality is that while it may not take less time, it certainly takes less people now. And that can't be ignored.
• youre-wrong3 4mo ago
  I was reading this thinking “how is this guy not getting it?” And then I get to the bottom and saw he’s on Bluesky and not X, which explains why he doesn’t get AI.
• geopsist 4mo ago
  Non-engineer here, doing growth at a small company, using these tools on side projects as well. The thing i find expensive is how to trust the output. I am not a coder so i cant rate the code to know if it's right. I end up running a second model to check the first one's output or testing. That takes time as well :)
• jbs789 4mo ago
  My processes are going faster. My company is able to prototype and develop faster, no doubt. Obviously need to use the tools effectively and have the right people. This is true for any business.
• coder0x 4mo ago
  [flagged]
• vijay96238 4mo ago
  I am not sure about AI, but, human will work hard to make it go faster. And eventually human will figure out limitations.
• chris_explicare 4mo ago
  [flagged]
• flumes_whims_ 4mo ago
  How about a chatbot in front of feature requests that gets all the details the fist time?
• ojr 4mo ago
  well 2026 is easily the most software I shipped so AI is definitely making the process faster. Sad if you with agree with the post, I'm outlier though AI has enabled me to build several subscription apps that was able to make money, not a lot but it will compound trust me.
• dakial1 4mo ago
  I understand this post comes from the PoV of a developer, but the key point is: >Maybe this setup is faster compared to the old way of working. But I also think it’s an unfair comparison. Working like this requires a much deeper involvement of domain and product experts. This involvement would mean writing out every feature and bug fix down to the tiniest detail. The game-changer here with AI in software development is that now the Subject Matter Experts (SMEs) can directly guide AI (Claude Code, Cursor, Codex...etc) to translate the vision into code, review and iterate. Yes, you are removing the developer from this step of the process, at least to build the MVP version of the service/backend/frontend. By doing this,the process goes faster, as AI codes faster and the iteration with the SME goes way faster as well since there is no handover; you also lower the "quality attrition" of the process handover (in this case expert to developer), since the expert will explain the function to an AI that also has the deep knowledge in the expert field. Obviously developers still are needed for the refactoring/hardening/compliance of that vibe-coded solution with corporate architectural/security guidelines, but soon enough those things will be done by AI too. We are seeing this happening right now at all the big companies who are having a gigantic wave of employees (tech AND business) using Cursor, Claude Code and Codex. So the skills will need to change and SMEs and developers will probably merge into one person that will have deep domain expertise, some systems and architecture knowledge to work more effectively with AI. Of course this new reality will bring a lot of challenges. Like the software governance issue that some companies (e.g. Amazon) having problems with the huge proliferation of vibe coded solutions that overlap with each other (probably with different outputs) and create confusion in the business...
• abustamam 4mo ago
  I'm an AI maximalist (I haven't touched a line of code since Dec 2025, barring some config files) and I agree with the article. Most teams won't be meaningfully accelerated by AI because building was never the bottleneck in most orgs. Knowing what to build usually was. I routinely finish everything on my plate pretty quickly with LLMs, so my personally processes have accelerated. I've fired off agents to build stuff that I personally want out of the product but would have been infeasible to build manually. And I'd work on my tasks at the same time. But when I compare company roadmap this year to a few years ago, you can't tell that any needle has moved at all in terms of technology and features. That said, we're kinda in a weird era where the optics of AI usage is more important than anything because investors want to see it, because they think it will give their company a leg up on the competition, which is not necessarily true!
• scotty79 4mo ago
  From a very brief description, very quickly, AI can build me a thing that I don't want. But I didn't know I don't want it before it was built. With this new found knowledge I can refine my description and build another thing to find out other things I didn't want (and sometimes even some things I didn't describe that I might actually want). One of the strongest AI applications is requirement discovery.