When you say "solved coding," what does this mean, what does it look like?

I have strong disagreement because it sounds like, by analogy or proxy, we have also "solved writing"

yetanotherjosh 4 hours ago | parent | next [-]

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."

▲

verdverm 3 hours ago | parent [-]

> no longer are concerned with writing or editing literal code

I'm not typing keys, but I am very much still concerned about the quality and nature of the code. Coding to me is more than pushing keys

> if you can define a really good PRD and sophisticated technical specs

I still believe we cannot waterfall software, the idea seems like taking a step backwards. How often do we learn about an unforeseen complexity only after getting into the implementation?

In my experience with agents, it's better to be iterative and in-the-loop. Start with a decent description, have them research the code/issue, write up an initial plan/design, work iteratively on writing code and updating design doc, review and finalize the code and markdown. Then future agents will have some resources to shortcut understanding the code base.

	▲	yetanotherjosh an hour ago \| parent [-]
		I'm not talking about not just punching the keyboard to type out the identifiers in the code. I'm talking about not making decisions about most classes and functions, most type definitions, most of the weedy logic within most modules, etc. If it can't be described in natural language as requirements, or in a typescript type or other data shape DSL (I think key data model types are probably still important to own), it's probably too weedy. Natural language test cases still define the expectations both at the product and architectural level and are essential for triangulating the agents on successful outcomes. A requirements and verification approach with agents is not waterfall any more than TDD is waterfall. Does thinking ahead and doing some planning equal waterfall? Does describing how a feature works to an end user, and making some key technical decisions, before you build it, mean waterfall? Does having some sense of what you're building first mean waterfall? With agents, you can specify (with PRD and technical specs) what you THINK it should do, and in minutes or hours or at most days, have the result, which you then learn from and iterate. If you didn't fully think it through, the agents will do one of three things: 1) decide for you, which you learn from 2) stop and ask, which you learn from 3) introduce bugs, which you learn from. It's extremely iterative.

▲

glimshe 4 hours ago | parent | prev | next [-]

"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.

▲

yetanotherjosh an hour ago | parent | next [-]

I'd separate "coding" from software engineering. Software engineering is not solved. The new challenge in software engineering is how to properly use AI to maximum leverage and nobody has solved that.

But, "coding" is, except that solving it means using techniques that are still barely understood and barely described today (something I'm hoping to be able to communicate better myself about). It is now possible (at least for most consumer software, I would not say applications where human life or extreme risk is involved) to work exclusively in the domain of natural language requirements, natural language architectural/design decisions, and natural language test cases, and deliver product of equal or better software quality than average human code authors could have produced. Even in a language that you plausibly don't actually know how to code in, because the language itself can often be separable from the requirements and verification process.

If someone who doesn't know a language or framework can plausibly produce better software using it, and faster, than a team of people who do know the language/framework (and I would strongly argue that is more than plausible now with models like Astra and Fable) then it's not just "coding is less expensive."

It's like saying computers make complex calculations less expensive. That's true, but it's missing the real paradigm shift.

▲

bengold14 3 hours ago | parent | prev | next [-]

I'm not trying to sound smart, I just think it encompasses what most people now acknowledge. LLMs write code faster and generally better than needed for most cases, and that seems to be becoming the prevalent opinion seeing as most folks have stopped doing PR reviews.

The problem is, without PR reviews & strict oversight, we're losing knowledge, system design & control of our codebases & products. Which is why, IMO, the coding is solved but the other parts which used to be so tightly coupled to programming are cropping up as their own issues.

	▲	bcrosby95 2 hours ago \| parent [-]
		This ties into my experience: greenfield projects turn bad way faster than legacy ones, because AI has no established patterns to key off and it does increasingly dumb shit.

▲

grumbel 4 hours ago | parent | prev [-]

"Reducing the cost of coding" would imply that you still have to code, but with current LLMs you no longer have to. You can write 100s of thousands of lines of code without ever having to touch a single line of code. Literally "here is a git repo, here is an issue, please fix".

You might still need to nudge the LLM in the right direction or stop it from going off weird tangents, but none of that involves touching actual code yourself.

▲

verdverm 4 hours ago | parent [-]

What is coding? Pushing keys or knowing the right keys to push?

Ai can push a lot of keys very fast, but not always the right ones

if they need to be reminded to follow the coding standards, visible in the very code they are working on, what has been solved?

▲

grumbel 3 hours ago | parent [-]

> What is coding?

Opening the IDE and typing program code. With LLMs you don't have to use an IDE, you don't have look at program code, you don't have to care about coding standards. You ask the chatbot to write you a program/feature/fix and chatbot does it.

Is chatting with a chatbot still "coding"?

The part that isn't fully solved is just the software architecture side of things, do you want library A or library B, or write it all from scratch? LLM can do all three, but if you aren't careful it might go down a route that you don't like. But that again can be fixed with chat, "replace A with B", not coding.

	▲	tripleee 3 hours ago \| parent [-]
		So lets say you plan the software architecture and take a person off the street, give them a frontier model and tell them to clone Figma given your architecture How far would they get?

▲

KeplerBoy 4 hours ago | parent | prev | next [-]

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.

▲

mwillis 3 hours ago | parent | prev | next [-]

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.

▲

sampullman 4 hours ago | parent | prev | next [-]

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.

	▲	verdverm 3 hours ago \| parent [-]
		I agree that writing is much harder, largely because there is no way to get concrete feedback for "does it work" I still think they produce shoddy or sus code too often, an artifact of the current generation's training to try anything and everything until it "completes the task". They have a hard time even with that concept, which is part of "coding" imo

▲

4 hours ago | parent | prev | next [-]

[deleted]

▲

gslepak 4 hours ago | parent | prev | next [-]

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.

	▲	verdverm 4 hours ago \| parent [-]
		even setting aside the artistic side of the profession, I see these things make all sorts of basic mistakes, so even the mechanical part doesn't seem "solved" ime

▲

ActorNightly 4 hours ago | parent | prev [-]

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.

	▲	verdverm 4 hours ago \| parent [-]
		I'm well on my way down this path too, but that is a process implemented in markdown. I don't see coding as solved, or a solvable thing at all, like writing To solve something, there must be a defined problem, what is the problem that was solved. Or perhaps it is just "coding is solved" is the turn of phrase de jour be ause we haven't yet found a more succinct and accurate way to describe the paradigm shift When it comes to non technical people using Ai to build things on code, the outcomes are on average pretty poor, which i see as evidence that the driver and their expertise behind the Ai matters a lot. A notable example is Terence Tao's conversation with ChatGPT, us math normies could never have done that. The same applies to coding agents ime