Earlier quoted context omitted.
This feels to me like peak sfba mentality on par with "move fast and break things". Outside of trying to create a unicorn, is this really how people create things? It seems to me that in order to obtain the ability to build things that other people like, you need to go through the process of creating things they won't. Like a painter needs to paint a bunch of crappy paintings to learn how to create a good painting. I…
This is how successful things are created. By iterating on less successful things until they become successful. The cost of iterating (with software) dropped by a few orders of magnitude in the last few months.
Writing code is cheap now
171–180 of 522 posts
Re: Writing code is cheap now
#172Earlier quoted context omitted.
I want to use AI to ship more and more code faster and better . If AI means our product quality goes down we should figure out better ways to use it.
Shouldn't you want to ship less code that does more? Since when was LoC the relevant benchmark for engineering?
With coding agent projects I find that investing in DRY doesn't really help very much. Needing to apply the same fix in two places is a waste of time as a human. An agent will spot both places with grep and update them almost as fast as if there was just one.
It's another case where my existing programming instincts appear to not hold as well as I would expect them to.
Re: Writing code is cheap now
#173Earlier quoted context omitted.
This is how successful things are created. By iterating on less successful things until they become successful. The cost of iterating (with software) dropped by a few orders of magnitude in the last few months.
But you need to actually be the one doing the iterating, you can't outsource it. The entire point to doing the iteration is the process, not the artefacts.
Re: Writing code is cheap now
#174The cost of code never lived in the typing — it lived in the intent, the constraints, and the reasoning that shaped it. LLMs make the typing cheap, but they don’t make the reasoning cheap. So the economics shift, but the bottleneck doesn’t disappear.
For most non-hobby project, the cost of code was in breaking a working system (whether by a bona fide bug, or a change in some unspecified implicit assumption). That made changes to code incredibly expensive - often much more than the original implementation. It sounds harsh, but over the lifetime of a project, 10-lines/person/day is often a high estimate of the number of lines produced. It’s not because humans type…
if they are, then why would a human be so slow? You're not comparing the same situation.
Re: Writing code is cheap now
#175Earlier quoted context omitted.
I don’t think we can expect all workers at all companies to just adopt a new way of working. That’s not how competition works. If agentic AI is a good idea and if it increases productivity we should expect to see some startup blowing everyone out of the water. I think we should be seeing it now if it makes you say ten times more productive. A lot of startups have had a year of agentic AI now to help them beat their c…
OpenClaw went from first commit in late November to Super Bowl commercial (it's meant to be the tech behind that AI.com vaporware thing) in February. (Whether you think OpenClaw is good software is kind of beside the point.)
I don’t think anyone is arguing against code agents being good at prototypes, which is a great feat, but most SWE work is built on maintaining code over time.
Re: Writing code is cheap now
#176Earlier quoted context omitted.
Shouldn't you want to ship less code that does more? Since when was LoC the relevant benchmark for engineering?
Less code isn't as important as it used to be, because the cost of maintaining (simple) code has gone down as well. With coding agent projects I find that investing in DRY doesn't really help very much. Needing to apply the same fix in two places is a waste of time as a human. An agent will spot both places with grep and update them almost as fast as if there was just one. It's another case where my existing programm…
Is the goal basically a codebase where your interactions are mediated through an LLM?
Re: Writing code is cheap now
#177[dead]
It's widely accepted that you can't learn just by reading, you have to write. So only thinking and reviewing is a great way to lose all the business domain knowledge.
> the thinking part didn't get cheaper -- domain knowledge, edge cases, integration constraints -- none of that is free. what changed is you now review AI output instead of type your own, which is genuinely faster but not as different as it sounds
It's very different - you lose business domain knowledge if you're only reading.
Re: Writing code is cheap now
#178Earlier quoted context omitted.
> The new skill is mastering the craft of directing cheap inputs toward valuable outcomes. Strongly agree with this. It took me awhile to realize that "agentic engineering" wasn't about writing software it was about being able to very quickly iterate on bespoke tools for solving a very specific problem you have. However, as soon as you start unblocking yourself from the real problem you want to solve, the agentic eng…
It's funny that so many people are using AI and still hasn't really shown up in productivity numbers or product quality yet. I'm going to be really confused if this is still the case at the end of the year. A whole year of access to these latest agentic models has to produce visible economic changes or something is wrong.
At least, in my own experience.
Re: Writing code is cheap now
#179Earlier quoted context omitted.
But you need to actually be the one doing the iterating, you can't outsource it. The entire point to doing the iteration is the process, not the artefacts.
I'm finding I can iterate significantly faster if the coding agent is doing the typing for me, and learn at a faster rate as a result.
Re: Writing code is cheap now
#180Earlier quoted context omitted.
Definitely the market incentives for "good code" have never been worse, but I'm wouldn't be so sure the cost of migrating decent pieces of generated code to good code is worse than writing good code from whole cloth.
I find that implementing a sound solution from scratch is generally lower effort than taking something that already exists and making it sound. The former: 1) understand the problem, 2) solve the problem. The latter: 1) understand the problem, 2) solve the problem, 3) understand how somebody or something else understood & solved the problem, 4) diff those two, 5) plan a transition from that solution to this solution,…
That's specious reasoning. Code reviews are a safeguard against cowboy coding, and a tool to enforce shared code ownership. You might believe you know better than most of your team members, but odds are a fresh pair of eyes can easily catch issues you snuck in your code that you couldn't catch due to things like PR tunnel vision.
And if your PR is sound, you certainly don't have a problem explaining what you did and why you did it.