Wow, I think you have never had a chance to communicate with someone selling their expertise for $2/h. Unless your time is also worth $2/h, I think you would get better results prompting local 27B model.

Same problem though :). If an overseas employee knows the code and you don't, you have ceded ownership, problem solving ability & future direction of the project.

I would say it means you are building software but no longer are concerned with writing or editing literal code. Your concerns have moved up the stack to managing requirements, context, and verification processes.

Just to make this clear: if you can define a really good PRD and sophisticated technical specs, and a strong set of tests cases to pass, at the right level of architectural granularity, plus adversarial code review processes that triangulate and weed out most mistakes, SOTA agents can write the code autonomously, at or above the quality level of most human coding teams. I call that "solved" but only if you meet those context requirements. Which is still hard, not solved, at that layer.

Solving writing is not a good analogy IMO. Writing is for human consumption, and cannot be wrapped in objective requirements and verification processes. Certain forms of writing perhaps could be (can't think of one at the moment but I don't doubt some exist), and those forms might be good analogies for being "solvable" or "solved."

"solved coding" is type of thing you say if you want to sound smart.

Saying that LLMs have "reduced the cost of coding" would be boring. And using your analogy, pencils, typewriters and computers have all reduced the cost of writing, but writers are still around.

It solved coding as in it's significantly less of a bottleneck than it was before.

At least that's how I experience it. In the before times each non-trivial code change had a real opportunity cost as it would easily consume two days until I could even estimate whether this is worth looking deeper into.

maybe it’s more like “abstracted” away, in the same way higher-level languages “solved” needing to code via machine instruction sets. Higher level languages allowed humans to think more like themselves. AI puts another abstraction in front of the outcome, making it even more generally open to human thinking and less defined by the need to give machines exactly what they expect.

Today, human-language outlines / briefs / prompts are “compiled” to code which is itself then adapted to hardware. We are stretching less and less across the divide, doing less and less work on the terms of the machine. Now the farthest we’ll stretch is often formatted markdown - the most basic application of machine-parseable structure to very organic human thinking. Because we’re given the chance to be less precise, coherence suffers.

Writing is a means of expression and communication. Code can be those things, but that's not its primary purpose.

I think "solved coding" is taking it too far, but for many projects, the mechanical aspect of it has been removed or reduced greatly.

LLMs will have a much harder time "solving writing", because they cannot develop their own style and so are severely limited, creatively. This is less important for coding.

It means "for my requirements they're good enough."

They haven't solved coding.

Programming is an art form. And the better you get at it, the better kinds of ideas (abstractions) you can create.

This is something today's AI cannot do.

If everyone were to permanently switch to AI for software development, software innovation would cease.

Given a working system, like a web service or services, and their code, non technical people can now make effective changes with LLMs.

For example, nobody on our team writes manual code anymore, we have basically set up a harness where an engineer types up the requirements for a change, the system implements it given certain constraints, we have automated unit and integration tests that are ran, and if any errors pop up, they get fed back into the loop until fixed.

But to do that, you need to actually know what you are doing - you have to have good instructions to keep the agents in check and not start making mods outside of their bounds especially when the issue is with a dependant service that is causing errors.

tbh, I don't think of LLMs as junior-devs. Maybe 6 months ago, but now they are v. senior code-monkeys. They are masters of their craft, but their craft is narrow and lacks big picture, collaboration, org goals, etc.

Fair question - IMO it's the wrong abstraction for building and collaborating on a new product with a team.

To your point, it's not the wrong abstraction for solving code level bugs. Just like python is not the right abstraction for solving memory corruption or pointer mis-alignments.

See my edit on the right abstraction - how do we get humans able to collaborate with agents effectively, where knowledge flows both ways, without needing a human to read 10k LOC, or even just lots of long LLM responses, to follow along

I have been trying to define "understanding". Is it when you can predict something that you understood it? Or maybe when you can explain it? Or how about when you can control it? Or invent it.

This time I add another definition "when you can own it".