7 ms·

Using AI to go faster is optimizing the wrong thing. At every place I've worked, the "code writing" part takes the least amount of time, compared to all the oth

Using AI to go faster is optimizing the wrong thing. At every place I've worked, the "code writing" part takes the least amount of time, compared to all the other things you need to do in order to implement a feature. Let's examine a feature that takes a day to code: First, you've got to plan everything, using whatever Agile or Waterfall planning ritual your company uses, get the task breakdown, file the JIRA tickets, decide who's doing the work. That all can take days or even weeks. Then you need to write a design doc with your proposed design, and get that reviewed by your peers/teammates. Again, another week for any substantial feature. If there are multiple teams involved, you need to get buy-in and design agreement among those multiple teams, let's add another week. At some places, you need approval to commence work, which can take multiple days, depending on the approver's schedule and availability. Then, you take a day and write the code and make sure it passes tests. Then, it's code review time, and this can involve a lot of back and forth with your team, resulting in multiple iterations and additional code reviews. Another "days or weeks" stretch. At bigger companies, you're going to need to pass all sorts of reviews from other departments, like legal, privacy, performance, accessibility, QA... even if done in parallel, let's add a conservative 2 weeks. Finally, you push to staging, and need to get some soak time internally among dogfooders, so you have some confidence that it's working. +1 week. Then you're ready to push from staging to prod, but since you work at a serious company, nothing goes to 100% prod right away--you need to slowly ramp up and check feedback/metrics in case you need to roll back. The ramp to fully launched could take another two weeks. So here's a feature that took, what, maybe two months from design to release, and we're falling all over ourselves to optimize the part that took a day so that it takes 5 minutes instead...

ajam1507 6mo ago
It very much depends on what kind of company you work for. You could never run a startup like this, for example.
ex-aws-dude 6mo ago
Not every company works like that Big tech has a lot of wankery like that but smaller companies can be fast and scrappy
- ryandrake 6mo ago
  It's a good point, and your username definitely checks out. I've also worked at a startup and some smaller companies, and still there's a LOT of "wankery" just different types. No, don't write the code yet, you need to present it to the CEO. Oh, we need to also present it to investors. Wait for a bit, because we have another deal coming down the pipe and we might have to change direction. Oh, a VIP customer just played golf with the founder and you need to go to his house to fix his setup. So much of the software engineer's job in the software industry doesn't involve writing code.
gwerbin 6mo ago
I think it depends a lot on how automated the agent is and how long you let it run for. Full automation where you try to build an entire piece of software with agents... yeah, no, we are not there yet. At least not a few you care about maintainability. Short-lived tightly-scoped agents can do alarmingly thorough and high-quality knowledge work, as long as the work itself is relatively mechanical and can either be carried out in independent chunks or sequentially. For example, a research agent like the Gemini "deep research" tool can save hours of digging around the web and compiling information. With careful prompting, sufficient background context, and good self-evaluation tools, an agentic loop can do very detailed data analysis, carry out serious statistics and machine learning projects, produce high-quality data visualization thereof, and put together a handy executive summary. They occasionally hallucinate, go off track, get confused, and make mistakes. But they "know" everything that's been published in English for the last 200 years, they never get tired, and the code they write is good enough for throwaway scripting. The real power of agents being able to write code is that they can be extremely self-sufficient and flexible in carrying out these kinds of tree- and sequence-structured knowledge work tasks. That's of course a different thing from "designing good software", which is neither tree-structured or sequential, and requires a level of intelligence (for lack of a better term) that LLMs do not seem to be capable of, at least not yet. But that's a more specific thing than just writing code in order to get stuff done that happens to require code.
CodeShmode 6mo ago
Or you can have a conversation with an agent to build up a requirements/plan spec, asking it to analyse existing code patterns. When it seems like the agent has a good understanding of what needs to be done and how. Ask it to implement, keeping changes as a local spike. Ask the agent questions about all the other teams' code, reaching out to them for questions it can't answer or clarification. With agent capabilities atm this is rare or can be done fairly async: "please confirm these things". Maybe realise your code architecture is completely wrong. Manually code up some new abstractions that fit better, write the learnings into the spec plan. Strip out any implementation that largely doesn't fit your updated abstractions. Ask the agent to migrate the code to the new structure. Repeat until spike is operational and you're happy with the abstractions used Chat with the agent to create a Design Doc for the approach in the spike. Create a single JIRA ticket for "Productionise CodeShmode's spike". Get reviews and feedback from stakeholders. Integrate feedback into your spike, or even the original spec document and regenerate the whole thing. So much of the ritual you've outlined here is overhead from working in a large org where roles are siloed. When one person is empowered to do more then the actual work per person goes down and the overhead becomes the dominant. But that overhead isn't needed anymore because one person can now do many people's work. I've whipped up spikes in a few days that would've been a month of work across a team multiple DDs and approvals. In the past this wasn't feasible so we would need to justify what those people would work on. Now you can whip it up, show a working demo and ask "should we productionise this"
- ryandrake 6mo ago
  I have no idea what a “spike” is, but this seems like a good way to build software when there are no consequences to getting it wrong. What happens if this “spike” violates someone’s patent or puts the company at legal/regulatory risk? What if it leaks users’ personal information? What if it introduces a vulnerability that my 13 year old can exploit? What if it crashes 2 million of your users’ devices because it didn’t anticipate some unusual configuration? What if the code totally conflicts with some other team’s future plans and you didn’t know because they never reviewed it? This kind of yolo “just try it” development only works if you are very small and low-profile, don’t have hundreds of millions of users, or your software is inconsequential (nobody cares if it goes down or doesn’t work).
threethirtytwo 6mo ago
>Using AI to go faster is optimizing the wrong thing. At every place I've worked, the "code writing" part takes the least amount of time, compared to all the other things you need to do in order to implement a feature. Let's examine a feature that takes a day to code: Ai writes the plans now. I just review and modify.
AdieuToLogic 6mo ago
> Using AI to go faster is optimizing the wrong thing. At every place I've worked, the "code writing" part takes the least amount of time, compared to all the other things you need to do in order to implement a feature. This reminds me of one of my software engineering axioms: When making software, remember that it is a snapshot of your understanding of the problem. It states to all, including your future-self, your approach, clarity, and appropriateness of the solution for the problem at hand. Choose your statements wisely. > So here's a feature that took, what, maybe two months from design to release, and we're falling all over ourselves to optimize the part that took a day so that it takes 5 minutes instead... Well said.
- Terr_ 6mo ago
  > a snapshot of your understanding of the problem Relevant: Programming as Theory Building (1985) by Peter Naur. The actual text is rather stuffy, but basically the code+docs cannot replace the richer in-human-heads ideas for what the real-world problem is and how computers should (or shouldn't) be used to face the problem.
  - AdieuToLogic 6mo ago
    >> a snapshot of your understanding of the problem > Relevant: Programming as Theory Building (1985) by Peter Naur. Great reference and I agree. From the abstract in the PDF I have of same: Peter Naur’s classic 1985 essay “Programming as Theory Building” argues that a program is not its source code. A program is a shared mental construct (he uses the word theory) that lives in the minds of the people who work on it. If you lose the people, you lose the program. The code is merely a written representation of the program, and it’s lossy, so you can’t reconstruct a program from its code. Programming is a fascinating combination of mathematical determinism and pure expression of consciousness. Both are entirely abstract, whose worth is only quantified indirectly. Entire organizations are built upon these intangible work products. Careers are made, promotions given, "free valence problem solvers" allowed to soar, stock options issued to birth millionaires. But Valhalla is only reached if a cadre of engineers can "see" the system, both for what it is now as well as what it must become. EDIT: removed irrelevant "physical world" sentence fragment.
dilyevsky 6mo ago
1. models are now extremely good at totally automating tedious tasks such as updating dependancies, build/deploys scripts, unit tests, etc what used to take days now can takes minutes. Easily 50x speedup on this. This was non-trivial part of every engineer's day-to-day at an established company. "platform engineering" or whatever they call this now is dead. 2. technically risky ideas that you never would have tried because it didn't make sense from risk+effort/reward standpoint are now within reach. it isn't "go faster" per se but the speed at which you can try something out still changes the nature of engineering process.
- SpicyLemonZest 6mo ago
  > 1. models are now extremely good at totally automating tedious tasks such as updating dependancies, build/deploys scripts, unit tests, etc what used to take days now can takes minutes. Easily 50x speedup on this. This was non-trivial part of every engineer's day-to-day at an established company. "platform engineering" or whatever they call this now is dead. I confess that I don't understand why this isn't true, because it seems to be true on the micro level, but it really hasn't been my experience. The platform engineers I'm familiar with are desperately trying to tread water to keep their systems healthy against the now-higher code velocity without falling to pieces. (Perhaps people used to make minor day-to-day improvements while coding that Claude enables us to ignore?)
  - otabdeveloper4 6mo ago
    Because "platform engineering" isn't about writing bash scripts, it's about having a mental model of the system architecture. (Which the LLM definitely doesn't have.) Also, it's always the case where you think LLMs are great at doing whatever it is that you don't understand or value.
    - dilyevsky 6mo ago
      There was lot of lofty ideas around devops/pe and the like but ime the grim reality is that in most of managers’ heads it’s basically “tools that product engs don’t want to be concerned with” and like i said current models are really really good at this. Also disagree on the mental model thing - give opus 4.7 or latest codex access to your code, design mds and your logging mcp - in five minutes it will be better at debugging production issues than 90% of platform engineers I’ve worked with. It is truly over
ytoawwhra92 6mo ago
> First, you've got to plan everything, using whatever Agile or Waterfall planning ritual your company uses, get the task breakdown, file the JIRA tickets, decide who's doing the work. That all can take days or even weeks. Then you need to write a design doc with your proposed design, and get that reviewed by your peers/teammates. Again, another week for any substantial feature. If there are multiple teams involved, you need to get buy-in and design agreement among those multiple teams, let's add another week. At some places, you need approval to commence work, which can take multiple days, depending on the approver's schedule and availability. All the process you described exists to maximise the amount of time your software engineers spend writing code[0]. You put this process in place because software engineers are among the most expensive employees in the business. Their time being wasted is meaningful to the bottom line. Make the software engineers cheap enough and the need for a lot of this process evaporates. Companies that already _have_ these processes in place will be SOL because it's incredibly challenging to break a bureaucracy like that, but companies that either don't have these processes or manage to eliminate them will have a significant competitive advantage. Which shouldn't be news. Startups have always competed with established businesses via speed of execution. What's new is the ability to maintain that speed for longer. > At bigger companies, you're going to need to pass all sorts of reviews from other departments, like legal, privacy, performance, accessibility, QA... These are all in the firing line. If the company could outsource their legal liability to an external provider of these reviews, they would. [0] We'll just ignore the irony that much of this process ends up being foisted on the employees whose time you're hoping to save.
dionian 6mo ago
i remember having to write design docs at one team about 15 years ago. dont miss that. usually was 90% waste.

ajam1507 6mo ago

It very much depends on what kind of company you work for. You could never run a startup like this, for example.

ex-aws-dude 6mo ago

Not every company works like that Big tech has a lot of wankery like that but smaller companies can be fast and scrappy

ryandrake 6mo ago
It's a good point, and your username definitely checks out. I've also worked at a startup and some smaller companies, and still there's a LOT of "wankery" just different types. No, don't write the code yet, you need to present it to the CEO. Oh, we need to also present it to investors. Wait for a bit, because we have another deal coming down the pipe and we might have to change direction. Oh, a VIP customer just played golf with the founder and you need to go to his house to fix his setup. So much of the software engineer's job in the software industry doesn't involve writing code.

gwerbin 6mo ago

I think it depends a lot on how automated the agent is and how long you let it run for. Full automation where you try to build an entire piece of software with agents... yeah, no, we are not there yet. At least not a few you care about maintainability. Short-lived tightly-scoped agents can do alarmingly thorough and high-quality knowledge work, as long as the work itself is relatively mechanical and can either be carried out in independent chunks or sequentially. For example, a research agent like the Gemini "deep research" tool can save hours of digging around the web and compiling information. With careful prompting, sufficient background context, and good self-evaluation tools, an agentic loop can do very detailed data analysis, carry out serious statistics and machine learning projects, produce high-quality data visualization thereof, and put together a handy executive summary. They occasionally hallucinate, go off track, get confused, and make mistakes. But they "know" everything that's been published in English for the last 200 years, they never get tired, and the code they write is good enough for throwaway scripting. The real power of agents being able to write code is that they can be extremely self-sufficient and flexible in carrying out these kinds of tree- and sequence-structured knowledge work tasks. That's of course a different thing from "designing good software", which is neither tree-structured or sequential, and requires a level of intelligence (for lack of a better term) that LLMs do not seem to be capable of, at least not yet. But that's a more specific thing than just writing code in order to get stuff done that happens to require code.

CodeShmode 6mo ago

Or you can have a conversation with an agent to build up a requirements/plan spec, asking it to analyse existing code patterns. When it seems like the agent has a good understanding of what needs to be done and how. Ask it to implement, keeping changes as a local spike. Ask the agent questions about all the other teams' code, reaching out to them for questions it can't answer or clarification. With agent capabilities atm this is rare or can be done fairly async: "please confirm these things". Maybe realise your code architecture is completely wrong. Manually code up some new abstractions that fit better, write the learnings into the spec plan. Strip out any implementation that largely doesn't fit your updated abstractions. Ask the agent to migrate the code to the new structure. Repeat until spike is operational and you're happy with the abstractions used Chat with the agent to create a Design Doc for the approach in the spike. Create a single JIRA ticket for "Productionise CodeShmode's spike". Get reviews and feedback from stakeholders. Integrate feedback into your spike, or even the original spec document and regenerate the whole thing. So much of the ritual you've outlined here is overhead from working in a large org where roles are siloed. When one person is empowered to do more then the actual work per person goes down and the overhead becomes the dominant. But that overhead isn't needed anymore because one person can now do many people's work. I've whipped up spikes in a few days that would've been a month of work across a team multiple DDs and approvals. In the past this wasn't feasible so we would need to justify what those people would work on. Now you can whip it up, show a working demo and ask "should we productionise this"

ryandrake 6mo ago
I have no idea what a “spike” is, but this seems like a good way to build software when there are no consequences to getting it wrong. What happens if this “spike” violates someone’s patent or puts the company at legal/regulatory risk? What if it leaks users’ personal information? What if it introduces a vulnerability that my 13 year old can exploit? What if it crashes 2 million of your users’ devices because it didn’t anticipate some unusual configuration? What if the code totally conflicts with some other team’s future plans and you didn’t know because they never reviewed it? This kind of yolo “just try it” development only works if you are very small and low-profile, don’t have hundreds of millions of users, or your software is inconsequential (nobody cares if it goes down or doesn’t work).

threethirtytwo 6mo ago

AdieuToLogic 6mo ago

> Using AI to go faster is optimizing the wrong thing. At every place I've worked, the "code writing" part takes the least amount of time, compared to all the other things you need to do in order to implement a feature. This reminds me of one of my software engineering axioms: When making software, remember that it is a snapshot of your understanding of the problem. It states to all, including your future-self, your approach, clarity, and appropriateness of the solution for the problem at hand. Choose your statements wisely. > So here's a feature that took, what, maybe two months from design to release, and we're falling all over ourselves to optimize the part that took a day so that it takes 5 minutes instead... Well said.

Terr_ 6mo ago
> a snapshot of your understanding of the problem Relevant: Programming as Theory Building (1985) by Peter Naur. The actual text is rather stuffy, but basically the code+docs cannot replace the richer in-human-heads ideas for what the real-world problem is and how computers should (or shouldn't) be used to face the problem.
- AdieuToLogic 6mo ago
  >> a snapshot of your understanding of the problem > Relevant: Programming as Theory Building (1985) by Peter Naur. Great reference and I agree. From the abstract in the PDF I have of same: Peter Naur’s classic 1985 essay “Programming as Theory Building” argues that a program is not its source code. A program is a shared mental construct (he uses the word theory) that lives in the minds of the people who work on it. If you lose the people, you lose the program. The code is merely a written representation of the program, and it’s lossy, so you can’t reconstruct a program from its code. Programming is a fascinating combination of mathematical determinism and pure expression of consciousness. Both are entirely abstract, whose worth is only quantified indirectly. Entire organizations are built upon these intangible work products. Careers are made, promotions given, "free valence problem solvers" allowed to soar, stock options issued to birth millionaires. But Valhalla is only reached if a cadre of engineers can "see" the system, both for what it is now as well as what it must become. EDIT: removed irrelevant "physical world" sentence fragment.

dilyevsky 6mo ago

1. models are now extremely good at totally automating tedious tasks such as updating dependancies, build/deploys scripts, unit tests, etc what used to take days now can takes minutes. Easily 50x speedup on this. This was non-trivial part of every engineer's day-to-day at an established company. "platform engineering" or whatever they call this now is dead. 2. technically risky ideas that you never would have tried because it didn't make sense from risk+effort/reward standpoint are now within reach. it isn't "go faster" per se but the speed at which you can try something out still changes the nature of engineering process.

SpicyLemonZest 6mo ago
> 1. models are now extremely good at totally automating tedious tasks such as updating dependancies, build/deploys scripts, unit tests, etc what used to take days now can takes minutes. Easily 50x speedup on this. This was non-trivial part of every engineer's day-to-day at an established company. "platform engineering" or whatever they call this now is dead. I confess that I don't understand why this isn't true, because it seems to be true on the micro level, but it really hasn't been my experience. The platform engineers I'm familiar with are desperately trying to tread water to keep their systems healthy against the now-higher code velocity without falling to pieces. (Perhaps people used to make minor day-to-day improvements while coding that Claude enables us to ignore?)
- otabdeveloper4 6mo ago
  Because "platform engineering" isn't about writing bash scripts, it's about having a mental model of the system architecture. (Which the LLM definitely doesn't have.) Also, it's always the case where you think LLMs are great at doing whatever it is that you don't understand or value.
  - dilyevsky 6mo ago
    There was lot of lofty ideas around devops/pe and the like but ime the grim reality is that in most of managers’ heads it’s basically “tools that product engs don’t want to be concerned with” and like i said current models are really really good at this. Also disagree on the mental model thing - give opus 4.7 or latest codex access to your code, design mds and your logging mcp - in five minutes it will be better at debugging production issues than 90% of platform engineers I’ve worked with. It is truly over

ytoawwhra92 6mo ago

> First, you've got to plan everything, using whatever Agile or Waterfall planning ritual your company uses, get the task breakdown, file the JIRA tickets, decide who's doing the work. That all can take days or even weeks. Then you need to write a design doc with your proposed design, and get that reviewed by your peers/teammates. Again, another week for any substantial feature. If there are multiple teams involved, you need to get buy-in and design agreement among those multiple teams, let's add another week. At some places, you need approval to commence work, which can take multiple days, depending on the approver's schedule and availability. All the process you described exists to maximise the amount of time your software engineers spend writing code[0]. You put this process in place because software engineers are among the most expensive employees in the business. Their time being wasted is meaningful to the bottom line. Make the software engineers cheap enough and the need for a lot of this process evaporates. Companies that already _have_ these processes in place will be SOL because it's incredibly challenging to break a bureaucracy like that, but companies that either don't have these processes or manage to eliminate them will have a significant competitive advantage. Which shouldn't be news. Startups have always competed with established businesses via speed of execution. What's new is the ability to maintain that speed for longer. > At bigger companies, you're going to need to pass all sorts of reviews from other departments, like legal, privacy, performance, accessibility, QA... These are all in the firing line. If the company could outsource their legal liability to an external provider of these reviews, they would. [0] We'll just ignore the irony that much of this process ends up being foisted on the employees whose time you're hoping to save.

dionian 6mo ago

i remember having to write design docs at one team about 15 years ago. dont miss that. usually was 90% waste.