5 ms·

Transformers can be used to automate testing, create deeper and broader specification, accelerate greenfield projects, rapidly and precisely expand a developer'

Transformers can be used to automate testing, create deeper and broader specification, accelerate greenfield projects, rapidly and precisely expand a developer's knowledge as needed, navigate unfamiliar APIs without relying on reference, build out initial features, do code review and so much more. Even if code is the right medium for specifying a program, transformers act as an automated interface between that medium and natural language. Modern high-end transformers have no problem producing code, while benefiting from a wealth of knowledge that far surpasses any individual. > Most people selling AI are predicting the obsolescence of human authors. It's entirely possible that we do become obsolete for a wide variety of programming domains. That's simply a reality, just as weavers saw massive layoffs in the wake of the automated loom, or scribes lost work after the printing press, or human calculators became pointless after high-precision calculators became commonplace. This replacement might not happen tomorrow, or next year, or even in the next decade, but it's clear that we are able to build capable models. What remains to be done is R&D around things like hallucinations, accuracy, affordability, etc. as well as tooling and infrastructure built around this new paradigm. But the cat's out of the bag, and we are not returning to a paradigm that doesn't involve intelligent automation in our daily work; programming is literally about automating things and transformers are a massive forward step. That doesn't really mean anything, though; You can still be as involved in your programming work as you'd like. Whether you can find paid, professional work depends on your domain, skill level and compensation preferences. But you can always program for fun or personal projects, and decide how much or how little automation you use. But I will recommend that you take these tools seriously, and that you aren't too dismissive, or you could find yourself left behind in a rapidly evolving landscape, similarly to the advent of personal computing and the internet.

interstice 1y ago
> Modern high-end transformers have no problem producing code, while benefiting from a wealth of knowledge that far surpasses any individual. It will also still happily turn your whole codebase into garbage rather than undo the first thing it tried to try something else. I've yet to see one that can back itself out of a logical corner.
- recursive 1y ago
  > It will also still happily turn your whole codebase into garbage rather than undo the first thing it tried to try something else. That's not true at all. ... It's only pretending to be happy.
- soulofmischief 1y ago
  That's a combination of current context limitations and a lack of quality tooling and prompting. A well-designed agent can absolutely roll back code if given proper context and access to tooling such as git. Even flushing context/message history becomes viable for agents if the functionality is exposed to them.
  - jashmatthews 1y ago
    Can we demonstrate them doing that? Absolutely. Will they fail to do it in practice once they poison their own context hallucinating libraries or functions that don’t exist? Absolutely. That’s the tricky part of working with agents.
- jcalvinowens 1y ago
  This is it for me. If you ask these models to write something new, the result can be okay. But the second you start iterating with them... the codebase goes to shit, because they never delete code. Never. They always bolt new shit on to solve any problem, even when there's an incredibly obvious path to achieve the same thing in a much more maintainable way with what already exists. Show me a language model that can turn rube goldberg code into good readable code, and I'll suddenly become very interested in them. Until then, I remain a hater, because they only seem capable of the opposite :)
  - soulofmischief 1y ago
    You'd be surprised what a combination of structured review passes and agent rules (even simple ones such as "please consider whether old code can be phased out") might do to your agentic workflow. > Show me a language model that can turn rube goldberg code into good readable code, and I'll suddenly become very interested in them. They can already do this. If you have any specific code examples in mind, I can experiment for you and return my conclusions if it means you'll earnestly try out a modern agentic workflow.
johnnyjeans 1y ago
> That's simply a reality, just as weavers saw massive layoffs in the wake of the automated loom, or scribes lost work after the printing press, or human calculators became pointless after high-precision calculators became commonplace. See, this is the kind of conception of a programmer I find completely befuddling. Programming isn't like those jobs at all. There's a reason people who are overly attached to code and see their job as "writing code" are pejoratively called "code monkeys." Did CAD kill the engineer? No. It didn't. The idea is ridiculous.
- soulofmischief 1y ago
  > Programming isn't like those jobs at all I'm sure you understand the analogy was about automation and reduction in workforce, and that each of these professions have both commonalities and differences. You should assume good faith and interpret comments on Hacker News in the best reasonable light. > There's a reason people who are overly attached to code and see their job as "writing code" are pejoratively called "code monkeys." Strange. My experience is that "code monkeys" don't give a crap about the quality of their code or its impact with regards to the product, which is why they remain programmers and don't move on to roles which incorporate management or product responsibilities. Actually, the people who are "overly attached to code" tend to be computer scientists who are deeply interested in computation and its expression. > Did CAD kill the engineer? No. It didn't. The idea is ridiculous. Of course not. It led to a reduction in draftsmen, as now draftsmen can work more quickly and engineers can take on work that used to be done by draftsmen. The US Bureau of Labor Statistics states[0]: Expected employment decreases will be driven by the use of computer-aided design (CAD) and building information modeling (BIM) technologies. These technologies increase drafter productivity and allow engineers and architects to perform many tasks that used to be done by drafters. Similarly, the other professions I mentioned were absorbed into higher-level professions. It has been stated many times that the future focus of software engineers will be less about programming and more about product design and management. I saw this a decade ago at the start of my professional career and from the start have been product and design focused, using code as a tool to get things done. That is not to say that I don't care deeply about computer science, I find coding and product development to each be incredibly creatively rewarding, and I find that a comprehensive understanding of each unlocks an entirely new way to see and act on the world. [0] https://www.bls.gov/ooh/architecture-and-engineering/drafters.htm#tab-6 https://www.bls.gov/ooh/architecture-and-engineering/drafter...
nitwit005 1y ago
I don't disagree exactly, but the AI that fully replaces all the programmers is essentially a superhuman one. It's matching human output, but will obviously be able to do some tasks like calculations much faster, and won't need a lunch break. At that point it's less "programmers will be out of work" as "most work may cease to exist".
- throw234234234 1y ago
  Not sure about this. Coding has some unique characteristics that may it easier even if from a human perspective it requires some skill: - The cost of failure is low: Most domains (physical, compliance, etc) don't have this luxury where the cost of failure is high and so the validator has more value. - The cost to retry/do multiple simulations is low: You can perform many experiments at once, and pick the one with the best results. If the AI hallucinates, or generates something that doesn't work the agent/tool could take that error and simulate/do multiple high probability tries until it passes. Things like unit tests, compiler errors, etc make this easier. - There are many right answers to a problem. Good enough software is good enough for many domains (e.g. a CRUD web app). Not all software is like this but many domains in software are. What makes something hard to disrupt won't be intellectual difficulty (e.g. software harder than compliance analyst as a made up example), it will be other bottlenecks like the physical world (energy, material costs, etc), regulation (job isn't entirely about utility/output). etc.
  - weatherlite 1y ago
    > The cost of failure is low: Most domains (physical, compliance, etc) don't have this luxury where the cost of failure is high and so the validator has more value. This is not entirely sensible, some code touches the physical / compliance world. Airports, airplanes, hospitals, cranes, water systems, military they all use code to different degrees. It's true that they can perhaps afford to run experiments over landing pages, but I don't think they can simply disrupt their workers and clients on a regular basis.
    - throw234234234 1y ago
agentultra 1y ago
> That's simply a reality, just as weavers saw massive layoffs in the wake of the automated loom They didn’t just see layoffs. There were the constant wars with Napoleon and the War of 1812 causing significant economic instability along with highly variable capital investments in textile production at the time. They we’re looking at huge wealth disparity and losing their jobs for most meant losing everything. What many Luddite supporters were asking for in many parts of England were: better working conditions, a raise to minimum wage, abolishment of child labour, etc. Sabotage was a means to make such demands from a class that held almost all of the power. Many of those protestors were shot. Those who survived and were laid off were forced into workhouses. The capitalists won and got to write the history and the myths. They made it about the technology and not the conditions. They told us that the displaced workers found new, better jobs elsewhere. Programmers, while part of the labour class, have so far enjoyed a much better bargaining position and have been compensated in kind. Many of us also complain about the quality of output from AI as the textile workers complained about the poor quality of the lace. But fortunately the workhouses were shut down. Although poor quality code tends to result in people losing their life’s savings, having their identities stolen, etc. Higher stakes than cheap lace. History is not repeating but it sure does rhyme.
freekh 1y ago
> It's entirely possible that we do become obsolete for a wide variety of programming domains. That's simply a reality… It is not a reality since it has not happen. In the real world it has not happened. There is no reason to believe that the current rate of progress will continue. Intelligence is not like the weaving machines. A software engineer is not a human calculator.
- weatherlite 1y ago
  To be fair he didn't say it is the reality now, he said the possibility is a reality. At least that's how I read his sentence. And yeah, I do think it's a real possibility now.

interstice 1y ago

> Modern high-end transformers have no problem producing code, while benefiting from a wealth of knowledge that far surpasses any individual. It will also still happily turn your whole codebase into garbage rather than undo the first thing it tried to try something else. I've yet to see one that can back itself out of a logical corner.

recursive 1y ago
> It will also still happily turn your whole codebase into garbage rather than undo the first thing it tried to try something else. That's not true at all. ... It's only pretending to be happy.
soulofmischief 1y ago
That's a combination of current context limitations and a lack of quality tooling and prompting. A well-designed agent can absolutely roll back code if given proper context and access to tooling such as git. Even flushing context/message history becomes viable for agents if the functionality is exposed to them.
- jashmatthews 1y ago
  Can we demonstrate them doing that? Absolutely. Will they fail to do it in practice once they poison their own context hallucinating libraries or functions that don’t exist? Absolutely. That’s the tricky part of working with agents.
jcalvinowens 1y ago
This is it for me. If you ask these models to write something new, the result can be okay. But the second you start iterating with them... the codebase goes to shit, because they never delete code. Never. They always bolt new shit on to solve any problem, even when there's an incredibly obvious path to achieve the same thing in a much more maintainable way with what already exists. Show me a language model that can turn rube goldberg code into good readable code, and I'll suddenly become very interested in them. Until then, I remain a hater, because they only seem capable of the opposite :)
- soulofmischief 1y ago
  You'd be surprised what a combination of structured review passes and agent rules (even simple ones such as "please consider whether old code can be phased out") might do to your agentic workflow. > Show me a language model that can turn rube goldberg code into good readable code, and I'll suddenly become very interested in them. They can already do this. If you have any specific code examples in mind, I can experiment for you and return my conclusions if it means you'll earnestly try out a modern agentic workflow.

johnnyjeans 1y ago

> That's simply a reality, just as weavers saw massive layoffs in the wake of the automated loom, or scribes lost work after the printing press, or human calculators became pointless after high-precision calculators became commonplace. See, this is the kind of conception of a programmer I find completely befuddling. Programming isn't like those jobs at all. There's a reason people who are overly attached to code and see their job as "writing code" are pejoratively called "code monkeys." Did CAD kill the engineer? No. It didn't. The idea is ridiculous.

soulofmischief 1y ago
> Programming isn't like those jobs at all I'm sure you understand the analogy was about automation and reduction in workforce, and that each of these professions have both commonalities and differences. You should assume good faith and interpret comments on Hacker News in the best reasonable light. > There's a reason people who are overly attached to code and see their job as "writing code" are pejoratively called "code monkeys." Strange. My experience is that "code monkeys" don't give a crap about the quality of their code or its impact with regards to the product, which is why they remain programmers and don't move on to roles which incorporate management or product responsibilities. Actually, the people who are "overly attached to code" tend to be computer scientists who are deeply interested in computation and its expression. > Did CAD kill the engineer? No. It didn't. The idea is ridiculous. Of course not. It led to a reduction in draftsmen, as now draftsmen can work more quickly and engineers can take on work that used to be done by draftsmen. The US Bureau of Labor Statistics states[0]: Expected employment decreases will be driven by the use of computer-aided design (CAD) and building information modeling (BIM) technologies. These technologies increase drafter productivity and allow engineers and architects to perform many tasks that used to be done by drafters. Similarly, the other professions I mentioned were absorbed into higher-level professions. It has been stated many times that the future focus of software engineers will be less about programming and more about product design and management. I saw this a decade ago at the start of my professional career and from the start have been product and design focused, using code as a tool to get things done. That is not to say that I don't care deeply about computer science, I find coding and product development to each be incredibly creatively rewarding, and I find that a comprehensive understanding of each unlocks an entirely new way to see and act on the world. [0] https://www.bls.gov/ooh/architecture-and-engineering/drafters.htm#tab-6 https://www.bls.gov/ooh/architecture-and-engineering/drafter...

nitwit005 1y ago

I don't disagree exactly, but the AI that fully replaces all the programmers is essentially a superhuman one. It's matching human output, but will obviously be able to do some tasks like calculations much faster, and won't need a lunch break. At that point it's less "programmers will be out of work" as "most work may cease to exist".

throw234234234 1y ago
Not sure about this. Coding has some unique characteristics that may it easier even if from a human perspective it requires some skill: - The cost of failure is low: Most domains (physical, compliance, etc) don't have this luxury where the cost of failure is high and so the validator has more value. - The cost to retry/do multiple simulations is low: You can perform many experiments at once, and pick the one with the best results. If the AI hallucinates, or generates something that doesn't work the agent/tool could take that error and simulate/do multiple high probability tries until it passes. Things like unit tests, compiler errors, etc make this easier. - There are many right answers to a problem. Good enough software is good enough for many domains (e.g. a CRUD web app). Not all software is like this but many domains in software are. What makes something hard to disrupt won't be intellectual difficulty (e.g. software harder than compliance analyst as a made up example), it will be other bottlenecks like the physical world (energy, material costs, etc), regulation (job isn't entirely about utility/output). etc.
- weatherlite 1y ago
  > The cost of failure is low: Most domains (physical, compliance, etc) don't have this luxury where the cost of failure is high and so the validator has more value. This is not entirely sensible, some code touches the physical / compliance world. Airports, airplanes, hospitals, cranes, water systems, military they all use code to different degrees. It's true that they can perhaps afford to run experiments over landing pages, but I don't think they can simply disrupt their workers and clients on a regular basis.
  - throw234234234 1y ago

agentultra 1y ago

> That's simply a reality, just as weavers saw massive layoffs in the wake of the automated loom They didn’t just see layoffs. There were the constant wars with Napoleon and the War of 1812 causing significant economic instability along with highly variable capital investments in textile production at the time. They we’re looking at huge wealth disparity and losing their jobs for most meant losing everything. What many Luddite supporters were asking for in many parts of England were: better working conditions, a raise to minimum wage, abolishment of child labour, etc. Sabotage was a means to make such demands from a class that held almost all of the power. Many of those protestors were shot. Those who survived and were laid off were forced into workhouses. The capitalists won and got to write the history and the myths. They made it about the technology and not the conditions. They told us that the displaced workers found new, better jobs elsewhere. Programmers, while part of the labour class, have so far enjoyed a much better bargaining position and have been compensated in kind. Many of us also complain about the quality of output from AI as the textile workers complained about the poor quality of the lace. But fortunately the workhouses were shut down. Although poor quality code tends to result in people losing their life’s savings, having their identities stolen, etc. Higher stakes than cheap lace. History is not repeating but it sure does rhyme.

freekh 1y ago

> It's entirely possible that we do become obsolete for a wide variety of programming domains. That's simply a reality… It is not a reality since it has not happen. In the real world it has not happened. There is no reason to believe that the current rate of progress will continue. Intelligence is not like the weaving machines. A software engineer is not a human calculator.

weatherlite 1y ago
To be fair he didn't say it is the reality now, he said the possibility is a reality. At least that's how I read his sentence. And yeah, I do think it's a real possibility now.