6 ms·

> Over the past year, I’ve watched engineers use AI to ship in days what used to take a team weeks. No, you didn't. You watched engineers use AI to ship in day

• tokioyoyo 6mo ago
  I commented this yesterday, I’ll repeat it again - what do you guys think organizations that have heavily leaned into AI are shipping nowadays? Most devs aren’t working on cutting edge, low level, mission critical systems. AI is great for that. Every company I personally know have been fast shipping features that are being used daily by millions of people for the past 7 months. We have the same thing on my team, and we also understand the limitations of AI generated code. If you’re more or less experienced, you can easily see the “good” and “bad” sides of it. So you kinda plan it out in a way that you can “evolve AI generated software”. I wouldn’t say the same thing in 2025 January, but it’s much different times now. Things are already working.
  • pron 6mo ago
    > If you’re more or less experienced, you can easily see the “good” and “bad” sides of it. So you kinda plan it out in a way that you can “evolve AI generated software”. If you're truly "managing fleets of agents" there's no way you're able to sift through the good and the bad in the output. If your AI-generated code is evolvable (which is hard to tell right now) then you're not writing it with "fleets of agents". If you are writing it with fleets of agents, I would bet it's not evolvable; you just haven't reached the breaking point yet.
    • tokioyoyo 6mo ago
      We’re not managing fleets of agents. They’re not productive for our workflows yet. It’s usually a couple of CC CLIs running and going back and forth on specific tasks we closely control.
      • pron 6mo ago
        They're not productive for any workflow is my point because they don't produce sustainable software, yet that's exactly what Armstrong is calling for. They don't work, and people experienced with AI workflows already know that. If you review the code and tell the agent to revert when it gets things wrong (not functionally but architecturally) you're fine. That's not what I was responding to.
        • snapcaster 6mo ago
          You're just wrong on this though, and I don't know why you aren't realizing it's a skill issue on your part
          • pron 6mo ago
            Nah, it's a skill issue on the part of those who believe in "agent swarms" (in fact, that's how I recognise AI noobs; they think swarms work). Studies (like this [1]) and Anthropic's experiements have told us they don't. We do experiments with software correctness and formal methods experts who actually dive deep into "swarm outputs" and try to put evolutionary pressure on them. Swarms simply cannot (yet) produce viable software. They do, however, produce software that for a while passes tests. What I think is happening is that people who believe swarms work just look at test results. But obviously, every software engineer has known for decades that tests can only tell you if your software works today; they can't tell you that it will work tomorrow. And the people who say that unreviewed agent output will work tomorrow are those who didn't review it closely enough, so they have no idea, either. [1]: https://arxiv.org/abs/2603.03823 https://arxiv.org/abs/2603.03823
            • 6mo ago
  • Zetaphor 6mo ago
    Most of the people making this argument vastly overestimate the quality of engineering and discipline that behind the software powering most corporations. CRUD apps are likely to be the most prominent type of application across industries, and most of them are crud
    • pron 6mo ago
      If the code is really simple, it's cheap to read it. When people don't read it (and when they need to use "fleets of agents"), it's because it's not so simple, and then the people who trust the outcome are those who don't know what it is that they've committed into the codebase. Their logic is no more than: the system hasn't collapsed under the load of 50 (or 500) changes so it probably won't collapse under the load of the next 500 (or 5000). Because that's how engineered systems work, right? If they're fine under light stress, they're fine under heavier stress.
      • amalfra 6mo ago
        > Because that's how engineered systems work, right? If they're fine under light stress, they're fine under heavier stress. Isn't this wrong? I thought engineered systems meant something designed with limits.
        • pron 6mo ago
          I was being sarcastic.
• randallsquared 6mo ago
  > In a year or so Look at the best models from Spring 2025, and compare with now (and similarly for Springs 2024 and 2025). Armstrong and lots of others are betting that this trend will continue, and if it does, the LLMs will ship code the LLMs understand, and whether any human specifically understands any particular part will mostly not matter.
  • pron 6mo ago
    And if the trend doesn't continue? I understand that a company with Coinbase's performance has little to lose and not many options, but many companies are in a better position. The problem is that executives could take the 15-20% productivity boost and be content, but they read stuff like this, get greedy, and they don't understand the risk they're taking.
    • randallsquared 6mo ago
      Agreed! That will be an... "interesting" outcome, if so, for a lot of these companies.
    • atonse 6mo ago
      Even if the trend doesn’t continue, the current models are very very good. They’re better than the average programmer in the industry, already.
      • zeroonetwothree 6mo ago
        Maybe at some coding benchmark. Certainly not at actually shipping and maintaining production grade software.
      • pron 6mo ago
        I don't know how anyone who carefully and closely reviews their output could possibly think that. Much of the time their code is fine, but every now and again they make a catastrophic (though often well-hidden) mistake that is so bad that all the tests pass but the codebase will be bricked if enough of those go in. They make such disastrous mistakes frequently enough that a decent-sized codebase can't last for more than 18-24 months. If the average programmer is this bad, then there must be better-than-average programmers reviewing the code. The problem with agents is that they can produce code at a far higher volume than the average programmer. Anyway, I don't know how well the average programmer programs, but if you commit agent-generated code without careful review, your codebase will be cooked in a year or two.
• smrtinsert 6mo ago
  Yeah absolutely embarassing take. If I had a nickle for every time someone sent me some AI garbage that was supposedly "thoroughly vetted and cross checked agent output", I'd be at least a thousandaire (gotta keep it real). There are strengths, but if you think its writing stream of code and just using it as is, I would LOVE to compete against you.
• adamtaylor_13 6mo ago
  I am an engineer. I hire other engineers. I run a company that ships usable software for small businesses. We do this every day. I'm sorry to say, we are indeed shipping in days what used to take weeks.
  • MeetingsBrowser 6mo ago
    As a software engineer who also hires other software engineers, I’m curious about the disconnect in our experiences. I do systems programming. Before AI feature development roughly went like, design, implement, test, review with some back edges and a lot of time spent in test and review. AI has made the implementation part much faster, at the cost of even more time spent testing and reviewing, though still an improvement overall. We do not see the weeks to days improvement though. The bottleneck before was testing and reviewing, and they are even bigger bottlenecks now. What kind of work do you do, and what kind of workflow were you using before and after AI to benefit so much?
    • stavros 6mo ago
      Not the OP, but it might be that AI isn't as good at systems programming as it is at other domains, or it might be that you're using it differently than I am. I don't know which one it is (maybe AI just isn't good at writing the language you work with). For things like web frontents/backends, though, it works beautifully. I ship things in days that would take me weeks to write by hand, and I'm very fast at writing things by hand. The AI also ships many fewer bugs than our average senior programmer, though maybe not fewer bugs than our staff programmers.
      • rustystump 6mo ago
        In my experience ai has had far far more bugs than most of what i call senior engineers but far fewer than juniors. The boost is for what are glorified crud apps which it 1000x the tedious work. However, the choices it makes along the way quickly blows up without cleaning. Seniors know how to keep their workstation clean or they should.
• coffeefirst 6mo ago
  Ever notice how people making this claim never come with receipts?
  • dboreham 6mo ago
    This bothered me some months ago, so I began posting all the non-sensitive LLM sessions I made online. That way when someone makes an assertion I can present evidence.
• sobellian 6mo ago
  AI definitely leads to some productivity gain but the claims of 10x, 100x, 1000+x are (for now) irrational exuberance. Churning out prototype software has always been quick, and now it's blazing. But these LLMs are like Happy Gilmore. They get to the green in one shot then they orbit the hole with an extremely dubious short game. The virtue is in their parallelizability but you still need to review their work, lest you come back to it wrestling an alligator while a ruined TV tower husk sends spark showers over the pin.
  • jedberg 6mo ago
    > But these LLMs are like Happy Gilmore. They get to the green in one shot then they orbit the hole with an extremely dubious short game. Except that he got good at his short game by the end. LLMs will get there sooner than we think.
    • maccard 6mo ago
      I don’t think we will though. Because the “short game” is match the requirements of the agent operator. If we don’t care about the finer details that we let the LLMs infer, then we shouldn’t care if a human infers them (but yet we do). I think LLMs are great, and I think people who can use them to get to the green in one and take it from there will soar, just like people who could identify a problem and solve it themselves did in the past.
• SkyPuncher 6mo ago
  Yes, it can. I do this regularly. I have literally built and shipped multiple things that would have taken me many many months to do and I’ve done it in under a week. Many of these are LLM heavy features where the LLM can literally self-evaluate and self-optimize. I start with a general feature, it will generate adverse, synthetic data, it will build a feature, optimize it the figure out new places to improve. 1 year ago, this would have taken an entire team months to do, now, it’s 2 or 3 days of work.
  • audunw 6mo ago
    The C compiler was a prime example of an application where the LLM can self-evaluate/optimise, with one of the best set of tests could imagine. Yet the end result was a mess. I have experienced areas where high productivity can be had without much loss in quality. So I can believe it. But it really depends on what you’re doing and I firmly believe many companies will run out of easy stuff that we can blaze through with AI fairly quickly. At least that’s where we seem to be heading
  • aprilthird2021 6mo ago
    What's an example of such a thing? Just curious
  • sdevonoes 6mo ago
    And your parents must be proud of you. You’re just another cog
• daemin 6mo ago
  People that manage AI agents are not engineers as they do no engineering but are instead just supervisors.
  • terpimost 6mo ago
    What is the difference between supervisor and an architect in tech products area?
  • snapcaster 6mo ago
    only dorks care this much about being an "engineer" or "artist". Who gives a shit if misanthropes on websites consider you a real engineer?
  • runako 6mo ago
    Early in my career, people said this about programmers who (weakly) insisted on using assemblers. Then, about people using high-level languages like C. Then, about people using C++. Then, about people using "toy"/"scripting" languages like PHP and Python. About people who use ORMs instead of writing SQL directly. About people who use JavaScript ("not a real programming language" was the dis). People used to argue how it was the mark of a tourist to use anything more visual than Emacs. This slight won't stick, nobody cares, and it might end up sounding stupid later. You can't usefully insult a professional engineer in 2026 by pointing out that they haven't memorized ASCII or the Arm instruction set.