It this point, a whole lot of teams have been leaning into AI-first, not-entirely-reviewed code since around March this year.

That means we are already 6-8 months in, and not far from having a full year of experience of what that actually looks like, albeit weirdly influenced by the increase in model capabilities during that period.

I'm looking forward to those retrospectives. Did this turn out to work OK for the teams doing it? What were the biggest failings and/or surprises? With hindsight, did this produce good quality software?

▲

lumost 2 hours ago | parent | next [-]

I think the biggest shift is in predictability. Will something be done today, next week, or next month - nobody knows. Will we converge on a bug free state? not sure.

So far AI works great at fast moving work which you will probably recode or throw away in a month or two anyway (e.g. a startup) but is weak at maintaining a large code base that you rely on. At least part of this is cultural, as the cost of misalignments between team members can be quickly translated into broken software.

▲

wild_egg 2 hours ago | parent [-]

I don't disagree but

> Will we converge on a bug free state?

I have never witnessed this state in my two decades of software work. Why would we think AI will magically achieve this?

▲

kg 2 hours ago | parent [-]

Software robustness, at least in terms of "has the app crashed on any client machines today", is achievable. It's just expensive enough to achieve that most people (rightly or not) don't prioritize it, and the more moving parts (like third party libraries or language runtimes) your application has the harder it is to achieve. Maybe AI will lower the cost of achieving that.

When I worked on Guild Wars every server or user crash went to a shared inbox and was bucketed so we could identify and act on new crashes. IIRC we maintained very, very low production crash rates and could prove that many of the crashes were due to hardware faults.

Similarly, Mozilla tries to analyze and act on every crash report they get in the field. If a webpage visited by even a small % of the customer base was causing crashes, the team worked to try and fix the crash to deliver stability. If it was a high-traffic webpage it got treated as a high-priority task - I remember Farmville breaking was basically a 3-alarm fire back when it was extremely popular.

"No bugs at all" is an even higher bar, but it probably is possible for simpler applications with the use of stuff like theorem provers. I'd love to see someone try it in production but I think the return on investment for that is probably super super negative.

	▲	jaggederest 24 minutes ago \| parent [-]
		I operate on a "no known bugs" basis with quite a bit of effort invested to try to find new, unknown bugs. The idea that every crash isn't acted on is kind of a crazy one, to me. Not every crash is actually actionable in e.g. a mobile app, but every one should at least get an eyeball in my opinion. This, to me anyway, is the bare minimum of "caring about software quality". If you do this regularly you'll have very solid code, and it's interesting that I have the perception at least that Guild Wars was a quality product. There's another layer, where you do that for subthreshold issues like UI inconvenience, etc, but that's bonus, I think.

▲

KasianFranks 2 hours ago | parent | prev | next [-]

Have been at it since Nov 23rd 2025 with a first commit with Opus 4.5 - it was rough at first but after about year well worth it. You can also tell where so many just get stuck in the mud due to lack of direct experience with all the engineering silos (from bare metal sys admin to QA eng silos outside of standard software engineering core) it takes to roll out a new kind of technology company while scaling a new kind of commercialization model, also managed by AI and AI native from the ground up.

▲

sick_of_slop an hour ago | parent | prev [-]

[dead]