What models are you using? At this point I'd only use Opus 5.5 for any serious work where I care about the code, so I'm interested if you're still seeing brittle solutions with it

I don't know how you can expect a useful answer to that question without you and OP syncing up on what you're working on. The experiences of, say, a python network programmer vs a C/C++ GPU engineer are going to be worlds apart.

I think a lot of pointless arguments on HN stem from a failure to realize that "software" is too big of a field to generalize much of anything.

It depends on how you define brittle.

Functional code that is perhaps overly defensive or specific in ways that will require updating it in the future? All the time.

What many do not yet understand is that the maintenance burden is a fraction of the effort that it takes you to review the code, much less iterate on it.

I see people on here talk about a supposed eventual collapse of maintainability if they do not review or understand the code.

In reality this never happens. The latest models can salvage and refactor even the biggest mess; all you need to do is ask.

They could probably do it even if source code isn't available and you only have a binary to work with.

Brittle by building ever more increasing numbers of abstractions rather that take a coherent view of some things. So over time you have these "seams" that the code base ends up looking like a punk motor cycle jacket.

When it becomes trivial to create ad hoc solutions, I think the utility (and thus frequency) of behemoth code bases will decrease. Because you no longer need one giant monstrosity when you're only using 3% of its features when you can have a far more efficient and targeted solution that specifically caters to your 3%, and can be trivially expanded as desired.

In fact I think we're already at this scenario, but it hasn't had the predicted impact yet because the sort of people that realize we're here already overlaps perfectly with the sort already capable of developing their own software. When e.g. receptionists start tossing together their own productivity app in a few minutes, then revolutionary change is nigh.

> When e.g. receptionists start tossing together their own productivity apps in a few minutes, then we will have entered into the next phase of the economy.

This isn't a matter of tooling through. Receptionists won't start making their own productivity apps because most people do not default to "I will make my own thing to solve this".

Maybe some receptionists will, but most won't, just like most people won't patch their own drywall even though the tools are available in every hardware store

Now imagine somebody could just describe some damage to their drywall in a text message to their computer, and it'd be magically patched away. Suffice to say, nobody would be calling in for drywall repair. Before computers, there were computers. [1]

It's obvious in hindsight, but all of these complex numerical calculations we take for granted were often not done by the same people applying them in various ways. They'd hire computers instead, which were human calculators whose job it was to do the math.

The reason these jobs no longer exist is because calculators/computers not only solved these tasks, but completely trivialized the process to do so. We're entering into a world where many cognitive tasks, including software development, are going to be trivialized in a similar fashion - describe the problem, get an answer.

[1] - https://en.wikipedia.org/wiki/Computer_(occupation)

Perhaps, but I imagine that it would be difficult for the receptionist to spec such tools sufficiently such that they would want to use the tool. Also, how would this tool be distributed or accessed? Most people don't have package managers or even desktop environments that they can meaningfully modify. To use your example, the receptionist is likely running windows on a thin client that is maintained by an msp, so how would they install and use the tool?

People talk about AI solving coding, sure, to a large extent. The problems of design and ops completely confound the layperson. Just last year, a cousin mentioned they were using like lovable or something to build a webpage for their business idea. I offered to just throw it together for them, very simple crud. They gave me what they had on lovable, and they got no further than the landing page before they had no idea what to ask for, let alone how to ask for it. Prompts were literally "ok so now make the app" and the models like "well what about x y z"? You have to be technically inclined at the very least to get something remotely useful out of these things.

Deployment is only an issue because it's assumed to be unnecessary in a current environment. As that assumption changes, so will the default setups. Of course that introduces new vulnerabilities, but as LLMs also make a mess of everything security related (and future LLMs will likely make a mess current era 'LLM hardened' setups, onward) our approach towards security and the internet will change in ways that are difficult to predict today.

I agree that plenty of people are currently hesitant to use LLMs for technical purposes, but I don't think it's because they literally could not do it. LLMs will now code up entire workable apps from minimal/vague/contradictory descriptions. If somebody only got to a landing page it's because they only prompted for a landing page, possibly trying to mimic how a human developer might have previously built a site - and quickly getting lost. But if you just say 'make a website where people can order widgets, manage their orders, and do all related tasks' it'll get done, no technical knowledge needed.

So I think we're mostly in a transitory phase. As people realize how powerful these tools have become, adoption is simply unavoidable.

Maybe

Granted, people would have to be able to accurately describe what they want to the computer

Many people cannot use a calculator to find the area of a triangle because they don't remember the formula for the area of a triangle, or figure out an angle because they don't remember trig

It's entirely possible that using AI to create software will run into the same problem. It won't be a rising tide lifting all boats, but only the top % of boats

That's still a pretty substantial problem if it is the case

Just use super productivity and stop burning company resources on slop tokens

https://super-productivity.com/

CL (change list) is Google speak for a PR [1].

So, likely: Gemini Flash, Argon, Carbon [2]; and Claude Opus [3]. Maybe more.

https://google.github.io/eng-practices/review/developer/cl-d...

https://blog.google/innovation-and-ai/models-and-research/ge...

https://www.businessinsider.com/google-finally-lets-all-engi...

The models are great, but the experience resonates. It really depends on what you're doing, and ultimately, how much you care. A 10k LoC PR that feels “tacked on” should help you guess the size of the code base.

So do you care about getting 10k LoC to review, in a 1M LoC code base? How about 3 such PRs? How about reviewing another half a dozen, from colleagues? And doing that 2 or 3 times a week?

I end up in similar situations, the codebase I work on demands a level of professionalism opus5.5 can't muster on the first pass. Code review remains the bottleneck. Usually I approach it like a code review, reading through and as I find things I markup the code, then afterwords I have the agent collate all the feedback and we discuss and it re-implements. Usually I can simplify and improve a lot in like 3 passes.

One thing that speeds up the reviews and improves my ability to find issues and provide guidance is having the agent work on better review guides (think an html page rendered locally, with object diagrams, decisions/assumptions, animations of data flow if it makes sense, whatever). Those in hand I can read the codebase faster and talk against that document too. I think the end result is better code than I could previously write by hand, in probably 5x the speed.

Usually I can't do more than two projects in parallel though.

Yeah, that makes a ton of sense, I'm going to try this - I particularly like the idea of making animations of data flow.

Event Catalogue is something I have been using for this https://www.eventcatalog.dev/ only thing is no longer MIT license.

By far the skill I use the most is one I wrote called "resolve-review" from back in the 4.6 days. Just uses gh CLI and graphql to get inline comments, which I key with standard tags like nit/fixit. So during review, I open vscode so I can have an lsp and jump around refs more easily (only reason I still have vscode installed; frozen at v1.110.1 with ai completely disabled and I haven't got around to getting the same setup in neovim), leave comments, send review, then resolve review. I'm sure one could have hooks or scheduled tasks listening for this but it's good enough for me. Working on a thing to build a pipeline of such work, which I describe in a top-level comment.

I do not have any pressure to deliver anything (amateur), so I can only imagine how much it must suck for anyone on that hamster wheel given how much it bothers me. If anyone wants to work on something like this, drop me a line; I miss working with people.