[estebank]

Most of the time is spent figuring what the right thing to do is, not writing the implementation. Sometimes the process of writing the implementation surfaces new considerations about what the right thing is, but still, producing text to feed to a compiler is not the bulk of the work of a software engineer. It is to unearth requirements and turn them into repeatable software.

[powvans]

Feels like lately most of the time is spent arguing about or at least worrying about whether or not AI is going to replace all software developers.

[pydry]

Or dealing with the idiotic fallout of somebody who sucks at coding or even has never coded in their life trying to make that happen.

[7e]

If you’re spending time thinking and not experimenting, then it’s because experimentation is expensive. With an LLM you don’t have to try to predict a complex system in advance, experiments are so cheap to can just converge to a solution directly. None of this pontificating; it’s really not that useful anymore.

[Silhouette]

With an LLM you don’t have to try to predict a complex system in advance, experiments are so cheap to can just converge to a solution directly.

We saw a similar philosophy in TDD advocacy many years ago. Search for something like "Sudoku Jeffries" to see how that went. Then search for "Sudoku Norvig" to see what it looks like when you actually understand the problem.

The idea that you can somehow iterate your way to a solution when you have no idea where you're trying to go or even which direction your next step should be in has always seemed absurd to some of us but in the era of LLMs there's no longer any doubt. In the agentic era (can we call a few months an "era"?) I estimate that 90% or more of the writing I've read about how to use agents most effectively came down to making sure there is a clear specification for what they need to implement first and then imposing extensive guard rails to make sure their output does in fact follow that specification. It's all about doing enough design work up front to remove any ambiguity before coding the next part of the implementation and almost everyone claiming any sort of real world success with coding agents seems to have reached a similar conclusion.

[dasil003]

This is very naive and reductive thinking. Experiments have a cost, you really have to think carefully about what you are trying to learn. Even when code is cheap, traffic and time are still huge constraints, and you better make sure your hypothesis actually makes sense for your goals, because AI is more than happy to fill in the blanks with a plausible but completely wrong proposal.

More broadly, it's well understood that experiments are not a replacement for design and UX. Google is famously great at the former and terrible at the latter. Sure the AI maxxers will say the machines are coming for all creative endeavours as well, but I'm going to need more evidence. So far, everything good I've seen come from AI still had a human at the wheel, and I don't see that changing any time soon.

[vintermann]

Even writing code the good old way, of course we experiment. I remember the old rule "Plan to throw away the first one. You will anyway." But then there's the "second system effect" where the second system is supposedly always overengineered and trying to take every possibility into account.

And then there's the times when the quick sloppy poc you planned to throw away gets forced into production and is still impossible to change ten years down the road.

AI makes all these problems so much less painful.

I worked at a company which had a huge monolithic ERP system (their product, to be clear) with no good separation between the GUI layer and presentation layer. The GUI was also dependent on an ancient version of the Borland C++ compiler. They put in a humongous effort to move to a slightly more modern UI library, and a client server architecture.

However, someone had decided that messages in xml or json were too inefficient, they already had performance issues. So they went with a binary message protocol of their own design - with no features for protocol update. Everything communicating with the server had to be on exactly the same version, or it would throw an error. So of course they very, very rarely updated the protocol.

I think the best help of AI will be to clean up such real life messes of soul-crushing architectural regrets. Will it do it perfectly, certainly not, but I wouldn't do it perfectly myself either if I was forced to do it - and I'd take a hell of a lot more time to do it.

[avador]

I think you and 7e are both right. Being able to iterate some N orders of magnitude quicker is a big deal. This doesn’t eliminate design and UX. Rather, it merges it with high iteration speed to produce a form of “play”.

“Play” is what produced at least two (likely more) generations of attentive (and therefore competent) programmers. The hype around LLMs is painful, yes, but attentive human minds will ultimately bust through it.

[GolfPopper]

And before long you have a solution that is made up of a thousand pieces of spaghetti that neither you nor anyone else understands. And when your solution becomes too brittle to use, cannot be maintained, or fails catastrophically, then what? Just hope that's someone else's problem?

[gchamonlive]

Refactoring is cheap too, but you have to read your code and know when to stop and ask the agent to refactor, rewrite, adopt or change libs, fix issues presented by linters and code quality scanners, change abstractions and rethink the architecture.

It's never been easier to replace chunks of code with sane software patterns, but you have to have a feel for those patterns. And also understand what's under the hood.

You folks speak like the only function of the agent is to spit code and features. Get a grip and treat your deliverables with care, otherwise you only have yourself to blame, not the AI.

[microflash]

Refactoring is not cheap when you take into account the cost of not breaking things.

[gchamonlive]

When we say "X is cheap" it's in comparison to doing things manually, not irresponsibly

[megous]

You actually get what you ask for. And you can ask for anything, vaguely or not.

You'll end with spaghetti if you'll play a bad manager and only ever allocate time for new features and never for cleanups.

You can go through code, add REFACTOR comments based on your tastes and thoughts, and get your result and iterate to your heart's wishes. You just don't need to do the direct code typing.

[a10c]

That's the point. Your prototype doesn't need to be pretty. It just needs to prove that the value is there for it to be made pretty.

[avador]

Order of operations: Make it work. Make it right. Make it fast.[0]

[0]: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

[didgetmaster]

Unfortunately, too many developers (especially in the AI era) stop after the first item.

[snvzz]

Stop... short of.

[antonvs]

> If you’re spending time thinking and not experimenting, then it’s because experimentation is expensive.

No, because no amount of experimentation can solve many of the problems that have been solved by thinking. Even your claim about "experiments are cheap" requires thinking to decide what experiments to do. No one is generating all possible solutions that fit in X megabytes; you have to think to constrain the solution space.

[imtringued]

I've noticed that a lot of developers fall into a trap where they start a project or experiment because their mental model is that an LLM made the task effortless, but in reality they ended up spending more time, because they committed themselves to doing projects that bring correspondingly less value such as throwaway prototypes.

[stuaxo]

Well - you converge to a system, but do that by pruning what you don't want.

If you care about maintainability and quality (and I include maintaining using LLM based tools) then you need to understand what it does (in doing so you will find lots of things for it to fix - you'll probably find that the architecture it's chosen is not right for what you want too).

[jimbokun]

So the infinite monkeys with infinite typewriters approach.

[darepublic]

aka "swarms". cool sounding name for.. throw yet more mud at the wall. at unprecedented scales

[eweise]

AI is pretty good at figuring out what the right thing to do is.

[incanus77]

AI is pretty good at pulling from the body of existing solutions of what the right thing to do is.

[mkoryak]

I find that it often pulls a solution that is good enough for this problem today. Sometimes that is great, and other times it's just creating a pile of shit

[CyberDildonics]

AI is decent at solving problems that lots of people already solved a long time ago.

[didgetmaster]

Too many people believe that AI is going to come up with elegant solutions to problems that no one has ever solved before. Maybe someday, but for now it seems to be good at finding a solution that may be hidden away somewhere in stack overflow. If it just isn't there, then you are out of luck.

[munksbeer]

There is almost nothing new in computer programming. 99.999% of any code most of us on this forum write will be repeating patterns that have been written thousands of times before.

Tell a coding agent what your new thing needs to do, give it the absolute constraints, max response times, max failover times, and so on, tell it which technologies it has access to or could use, and then tell it to spend a lot of time going over and over the design, coming up with an initial X number of designs (I use 5), and then it must self criticise each one of them and weigh them up, narrow down to three, before finally presenting those three options to the user.

Now you read the options, understand them, realise that the AI has either converged on something very sensible, or it has missed something, so you tell it what it missed and iterate. Or it nailed something good, you pick the option you prefer, and tell it to come up with a more fleshed out high level design, describing the flow and behaviour deeply (NO CODE REFERENCES!). Then once you're happy, tell it to use that and write a comprehensive coding plan. Tell it specifically what coding patterns you prefer (you should have these in your AGENTS.md file already), what patterns to avoid (single threaded? multi-threaded? Avoid gc? How you typically deal with error conditions, etc etc).

Then have it start iteratively working on the coding plan, and it *MUST* have a strong feedback loop. If there is no feedback loop initially, I tell it to build one. It must be able to write very fluent integration tests (not just unit tests). It must be able to run the app and read the logs.

Do all this and I bet you get a better result that 80% of developers out there. Coding agents are extremely good when used well.