[HN Gopher] LLM-powered tools amplify developer capabilities rat...
___________________________________________________________________
LLM-powered tools amplify developer capabilities rather than
replacing them
Author : matthewsinclair
Score : 175 points
Date : 2025-04-21 14:36 UTC (8 hours ago)
(HTM) web link (matthewsinclair.com)
(TXT) w3m dump (matthewsinclair.com)
| skydhash wrote:
| > Traditionally, coding involves three distinct "time buckets":
|
| > Why am I doing this? Understanding the business problem and
| value
|
| > What do I need to do? Designing the solution conceptually
|
| > How am I going to do it? Actually writing the code
|
| > For decades, that last bucket consumed enormous amounts of our
| time. We'd spend hours, days or weeks writing, debugging, and
| refining. With Claude, that time cost has plummeted to nearly
| zero.
|
| That last part is actually the easiest, and if you're spending
| inordinate amount of time there, that usually means the first two
| were not done well or you're not familiar with the tooling
| (language, library, IDE, test runner,...).
|
| There's some drudgery involved in manual code editing (renaming
| variable, extracting functions,...) but those are already solved
| in many languages with IDEs and indexers that automate them. And
| so many editors have programmable snippets support. I can
| genuinely say in all of my programming projects, I spent more
| time understanding the problem than writing code. I even spent
| more time reading libraries code than writing my own.
|
| The few roadblocks I have when writing code was solved by
| configuring my editor.
| jstanley wrote:
| How do you understand the problem without writing any code?
|
| It's possible that people's experiences are different to yours
| because you work on a specific type of software and other
| people work on other specific types of software.
| vlovich123 wrote:
| By building a high level abstract understanding of how things
| operate & then understanding how that abstractions need to be
| expressed. Writing code certainly is more concrete and can
| highlight mistakes like when there's a gap in your
| understanding vs spots where details matter more
| specifically.
|
| At many big tech companies I've worked out, an abstract
| design proposal precedes any actual coding for many tasks.
| These design proposals are not about how you lay out code or
| name variables, but a high level description of the problem
| and the general approach to solve the problem.
|
| Expressing that abstract thinking requires writing code but
| that's the "how" - you can write that same code many ways.
| codr7 wrote:
| If you haven't solved exactly the same problem before,
| specifying a solution before writing code is a bad idea
| imo. More often than not, it turns out that the prematurely
| defined general approach isn't very optimal.
|
| Which points at a pretty substantial limitation of LLM
| coding...
| skydhash wrote:
| The solution is always out there. The code is just an
| automated way to get it without the error prone way of
| humans doing manual calculations. But sometimes, your
| understanding is flawed, so the code you write is not the
| correct way to have the solution. Which is why you have
| to get actual correct answers (specs) before writing
| code.
|
| Correctness is not embedded in software. It's embedded in
| the real world.
| vlovich123 wrote:
| Typically I find a novel problem domain requires roughly
| about 3 attempts from scratch to get a maintainable
| longer-term solution. However, that still requires having
| some idea in mind to try before just writing code. Of
| course you might also do some prototyping on certain
| subparts of the problem but there's only so much of that
| that can be done and you're still trying out what
| expressing high level ideas looks like / how it works.
|
| I don't think there's anything where the first step is
| writing code. It's like saying the first step of solving
| a math problem is writing down equations.
| skydhash wrote:
| > _By building a high level abstract understanding of how
| things operate & then understanding how that abstractions
| need to be expressed. Writing code certainly is more
| concrete and can highlight mistakes like when there's a gap
| in your understanding vs spots where details matter more
| specifically._
|
| The whole argument behind TDD is that it's easier to write
| code that verify something than actually implement the
| code. Because it only have the answer, not the algorithm to
| solve the question.
|
| So for any code you will be writing, find the answers first
| (expected behavior). Then add tests. The you write the code
| for the algorithm to come up with the answer.
|
| Static typing is just another form of these. You tell the
| checker: This is the shape of this data, and it warns you
| of any code that does not respect that.
| vlovich123 wrote:
| And an even stronger approach than TDD would be to
| develop a formal proof in something like Coq. At some
| point you have to define your algorithm and it's easier
| when you actually have some inkling of how it would work
| rather than just trying to blindly get a test suite to
| pass.
| carlmr wrote:
| >How do you understand the problem without writing any code?
|
| Not OP, but I find this a very good question. I've always
| found that playing with the problem in code is how I refined
| my understanding of the problem. Kind of like how Richard
| Feynman describes his problem solving. Only by tinkering with
| the hard problem do you really learn about it.
|
| I always found it strange when people said they would plan
| out the whole thing in great detail and code later. That
| never worked for me, and I've also rarely seen it work for
| those proposing it.
|
| It may be because I studied control systems, but I've always
| found you need the feedback from actually working with the
| problem to course correct, and it's faster, too. Don't be
| scared to touch some code. Play with it, find out where your
| mental model is deficient, find better abstractions than what
| you originally envisioned before wrestling with the actual
| problems.
| mixmastamyk wrote:
| This is true when breaking new ground, but it's a rare
| occurrence. Most business problems are a few thousand years
| old. Yes, there were taxes paid in the ancient world.
| Espressosaurus wrote:
| They weren't solving hard realtime nonlinear control for
| hardware running on a custom ASIC in a domain only a
| literal handful of companies even operate in.
|
| Not everything has been solved for ten thousand years.
| mixmastamyk wrote:
| You misread. Also, that tech has been around for decades.
| 6510 wrote:
| If I have any representation of the problem in front of me
| the mind seems to attack it all by it self. I strongly
| suspect someone with more (or different) experience doesn't
| need this or gets better results by writing out a
| representation.
| corytheboyd wrote:
| I've grown weary of people repeating absolutisms they hear
| online, too.
|
| As is usually the truth in practice, it's a mess, which is
| why I've seen combinations of upfront planning and code
| spiking work the best.
|
| An upfront plan ensures you can at least talk about it with
| words, and maybe you'll find obvious flaws or great
| insights when you share your plan with others. Please, for
| the love of god, don't ruin it with word vomit. Don't
| clutter it with long descriptions of what a load balancer
| is. Get to the point. Be honest about weaknesses, defend
| strengths.
|
| Because enterprise corporate code is a minefield of trash,
| you just have to suck it up and go figure out where the
| mines are. I've heard so many complaints "but this isn't
| right! It's bad code! How am I supposed to design around
| BAD code!" I'll tell you how, you find the bad parts, and
| deal with them like a professional. It's annoying and slow
| and awful, but it needs doing, and you know it.
|
| By not doing the planning, you run the risk of building a
| whole thing, only to be told "well, this is nice, but you
| could have just done X in half the time." By not doing the
| coding, you risk blowing up your timeline on some obvious
| unknown that could have been found in five minutes.
| skydhash wrote:
| It's not building the whole architecture before coding.
| It's about getting all the answers before spending time
| coding things that will probably have hidden bugs.
|
| Sometimes you don't have a way to get the exact answers, so
| you do experiments to get data. But just like scientists in
| a lab, they should be rigorous and all assumptions noted
| down.
|
| And sometimes, there are easy answers, so you can get these
| modules out of the way first.
|
| And in other cases, maybe a rough solution is better than
| not having anything at all. So you implement something that
| solves a part of the problem while you're working on the
| tougher parts.
|
| Writing code without answers is brute-forcing the solution.
| But novel problems are rare, so with a bit of research,
| it's quite easy to find answers.
| hnthrow90348765 wrote:
| >And in other cases, maybe a rough solution is better
| than not having anything at all.
|
| POCs are better for customer-facing, product management
| driven work. This is because they can be bad at
| describing what they want. There's more risk of building
| the wrong thing.
|
| POCs can be okay for system design or back-end work (or
| really anything not involving vague asks), but chances
| are planning and deeper thinking will help you more there
| because the problems you solve tend to be less
| subjective. Less risk of building the wrong thing.
| skydhash wrote:
| Rough solution in this case is more like a sketch
| compared to a painting, a few hours of work instead a
| week or two. The painting can be the main goal, but a
| sketch can be useful for some part.
|
| Kinda like scaling. Instead of going for Kubernetes, use
| a few VPS and a managed database to get your first
| customers.
| vlovich123 wrote:
| And the article is overstating it as well. My confidence in the
| LLM's ability to reduce the "how" part is primarily based on
| "am I doing something the LLM is good at?". If I'm doing HTML
| React where there's a million examples of existing stuff, then
| great. The more novel what I'm asking is, the less useful the
| LLM becomes and the more stuff I need to handcode is. Just as
| with self-driving cars, this is a challenge because switching
| from "the LLM is generating the code" to "I'm hand-tweaking
| things" is equivalent to self-driving disconnecting randomly
| and telling you "you drive" in the middle of the highway. Oh
| and I've caught the LLM randomly inserting vulnerabilities for
| absolutely no reason (e.g. adding permissions to the iframe
| sandbox attribute when I complained about UI layout issues).
|
| It's a useful tool that can accelerate certain tasks, but it
| has a lot of sharp edges.
| bluefirebrand wrote:
| > If I'm doing HTML React where there's a million examples of
| existing stuff, then great
|
| I do quite a bit of this and even here LLMs seem extremely
| hit and miss, leaning towards the miss side more often than
| not
| ijk wrote:
| I think React is one of those areas where consistency is
| more important than individual decisions. With a lot of
| front-end webdev there's many right answers, but they're
| only right if they are aligned with the other design
| decisions. If you've ever had to edit a web page with three
| different approaches to laying out the CSS you know what I
| mean.
|
| LLMs _can_ do consistency, they're pretty good continuing a
| pattern...if they can see it. Which can be hard if it's
| scattered around the codebase.
| bluefirebrand wrote:
| > one of those areas where consistency is more important
| than individual decisions
|
| This describes any codebase in any programming language
|
| This is why "programming patterns" exist as a concept
|
| The fact that LLMs are bad at this is a pretty big mark
| against them
| skydhash wrote:
| Consistency is why frameworks and libraries exists. Once
| you start to see consistency in your UI views, that's a
| good sign to further refine it into components and
| eliminate boilerplate.
| namaria wrote:
| > LLMs _can_ do consistency
|
| They won't even consistently provide the same answer to
| the same input. Occasional consistency is inconsistency.
| bcrosby95 wrote:
| My favorite is when I ask it to fix a bug, and in the
| part of the code that doesn't change it still slightly
| rewords a comment.
| snovv_crash wrote:
| > Oh and I've caught the LLM randomly inserting
| vulnerabilities for absolutely no reason (e.g. adding
| permissions to the iframe sandbox attribute when I complained
| about UI layout issues).
|
| Yeah, now get the LLM to write C++ for a public facing
| service, what could possibly go wrong?
| hiAndrewQuinn wrote:
| >That last part is actually the easiest
|
| If it were, the median e.g. business analyst should be getting
| paid significantly more than the median software engineer.
| That's not what the data shows, however.
|
| >I can genuinely say in all of my programming projects, I spent
| more time understanding the problem than writing code.
|
| This is almost trivially true for anyone who understands the
| problem _via_ writing code, though.
| jimbokun wrote:
| > If it were, the median e.g. business analyst should be
| getting paid significantly more than the median software
| engineer.
|
| What if you replace "business analyst" with "software
| architect"?
| skydhash wrote:
| Or tech lead and senior engineer. Because they spend more
| time doing the first two than that last one.
| Snuggly73 wrote:
| I spend most of my time talking to stakeholders and BAs
| to help _them_ better understand what their actual
| problem is instead of coming to me with "we want this"
| :/
|
| Writing the code is the trivial part.
| danielbln wrote:
| Writing code is the trivial part, yet it can be quite
| time consuming. I know what I want, so I don't want to
| care about the trivial minutae, same as I care very
| little what machine code falls out of my compiler. LLMs
| aren't capable yet to enable this easily and reliably,
| but they present a (often useful) glimpse.
| otabdeveloper4 wrote:
| "Business analyst" is not a real job and problem domain
| analysis is done by software engineers in 100 percent of the
| workplaces I know.
| r00fus wrote:
| It's a real job - but more in IT and less software
| development. IT departments in many places prefer to do the
| buy rather than build since build is more expensive for
| them.
| Aperocky wrote:
| You're assuming only the last part is what software engineer
| do.
|
| The business analyst mostly just scratch the top half of the
| first part.
|
| But I do encourage them to go vibe coding! It's providing a
| lot of entertainment. On off chance, they would become one of
| us and would be most welcomed.
| hiAndrewQuinn wrote:
| I'm not, but any time spent on #3 is time not spent on #1
| and #2. So why wouldn't a profession specialized in the
| harder tasks make more money?
|
| My real point is claiming #3 is the easiest is just silly.
| It's obviously much easier to come up with good business
| ideas in the abstract than to bring them into being. The
| mixture works because software as a business is an O-ring
| problem. These 3 tasks are not cleanly separable, they're
| all part of a feedback loop together.
| Aperocky wrote:
| > What do I need to do? Designing the solution
| conceptually
|
| That's not respecting #2, which still fall squarely in
| engineering profession.
|
| The design of the solution are necessarily technical,
| otherwise it's just throwing a bunch of concept and big
| words to sounds cool and leads to nowhere.
|
| The outcome of this solution would then go back and
| influence #1 which is the behavior that customer see. If
| Steve Jobs couldn't fit all of his components into his
| iphone then it wouldn't have existed, and he might have
| to settle for something less, like an ipod.
|
| Obviously this would all exist in a ring and that's why
| everyone is continuously employed and mostly not fired
| once the product gets released.
| AlexCoventry wrote:
| What is an O-ring problem?
| corytheboyd wrote:
| I agree, they are very much exaggerating both time spent
| writing code, as well as the amount of time LLMs shave off. LLM
| coding very much does NOT take "near zero time," I would argue
| that sometimes it can take the same amount of time or longer,
| compared against simply knowing what you are doing, with tools
| you know how to use, referring to documentation you know how to
| interpret, understanding the systems around, the business
| around, what team A and C need in two quarters so we better
| keep it in mind... etc.
| Snuggly73 wrote:
| I had the weirdest experience the other day. I wanted to
| write an Expo React Native application - something I have
| zero experience with (I've been writing code non-stop since I
| was a kid, starting with 6502 assembly). I've leaned heavily
| on Sonnet 3.7 and off we went.
|
| By the end of the day (10-ish hours) all I got to show was
| about 3 screens with few buttons each... Something a normal
| React developer probably would've spat out in about a hour.
| On top of that, I can't remember shit about the application
| itself - and I can practically recite most of the codebases
| that I've spent time on.
|
| And here I read about people casually generating and erasing
| 20k lines of code. I dunno, I guess I am either holding it
| wrong, or most of the time developing software isn't spent
| vomiting code.
| Graphon1 wrote:
| Interesting. I had the exact opposite experience recently.
|
| I've also been writing code for a long time, did the 6502
| assembly thing way back when, and lots since then. For this
| current project I wanted to build a web app with a frontend
| in Angular and a backend in Java 21 relying on javalin.io
| for the services layer. It had a few other integrations as
| well - into a remote service requiring OAuth and also into
| subtlecrypto. After less than 10 hours I had a fully
| functioning MVP that was far superior to anything I could
| have created without an assistant. It gave me build files,
| even a test skeleton. Restyling the UI or reflowing the UX
| to include confirmations, additional steps, modals, ... was
| really easy. I just had to type it, and those changes would
| get made. It felt like I was "director of development" for
| a day.
|
| I used Aider, plugged into Gemini 2.5.
| Snuggly73 wrote:
| Well... In my case the scaffolding was done by the Expo
| template, used Expo libraries for social login and I
| wrote the Expo API backend functions.
|
| Was it productivity boost for me - yeah, cause I know
| mostly shit about React. But as an end result it just
| felt very underwhelming. Discussing it today with my
| brother (who lives and breathes FE) it apparently was.
|
| I guess I was just expecting... I dunno... more - people
| are claiming nX productivity boosts, and considering how
| the UI is mostly boilerplate...
| Snuggly73 wrote:
| Just to continue my train of thought, because I keep
| coming back to this.
|
| I think I was expecting that it will turn me into a FE
| developer and it will feel as natural and smooth as usual
| when I am in my element.
|
| It didn't. And the results weren't what you would get
| from a real FE dev. And it felt unsatisfactory, stressful
| and ultimately hollow.
|
| I guess _for me_ it would be fine for a throw away MVP -
| something that I don't want to put my heart into.
| jandrese wrote:
| I have a feeling that people who got bogged down in step 3 were
| the kind of people who write a lot of wordy corporate
| boilerplate with multiple levels of abstraction for every
| single thing. AKA "best practices" type coding.
|
| For me the most important part of a project is working out the
| data structures and how they are accessed. That's where the
| rubber meets the road, and is something that AI struggles with.
| It requires a bit too high a level of abstract thinking and
| whole problem conceptualization for existing LLMs. Once the
| data structures are set the coding is easy.
| exe34 wrote:
| same, the amount of work I have to put into thinking of what
| to say to the llm is the same or more work than just telling
| the compiler or interpreter what I want (in a language I'm
| familiar with), and the actual coding is the trivial part. in
| fact I get instant feedback with the code, which helps change
| my thinking. with the llm, there's an awkward translating for
| the llm, getting the code, checking that it might do what I
| want, and then still having to run it and find the bugs.
|
| the balance only shifts with a language/framework I'm not
| familiar with.
| lherron wrote:
| I agree for method-level changes, but the more you're
| willing to cede control for larger changes, even in a
| familiar language, the more an LLM accelerates you.
|
| For me, I give Gemini the full context of my repo, tell it
| the sweeping changes I want to make, and let it do the zero
| to one planning step. Then I modify (mostly prune) the
| output and let Cursor get to work.
| jimbokun wrote:
| I think it's useful to think of LLMs performing translation
| from natural language to a program language. If you already
| speak the programming language fluently, why do you need a
| translator?
| bluefirebrand wrote:
| > If you already speak the programming language fluently,
| why do you need a translator?
|
| And if you _don 't_ speak the language please spare us
| from your LLM generated vibe coding nonsense
| otabdeveloper4 wrote:
| Nah, these are the people who don't know the difference
| between a variable and a function call and who think FizzBuzz
| is a "leetcode interview problem".
| DonHopkins wrote:
| I hate it when variables won't and constants aren't and
| functions don't.
| ornornor wrote:
| Enterprise code with layers of abstraction isnt best
| practice. It's enterprise code.
| delecti wrote:
| I would imagine that's why they had "best practices" in
| quotes. Lots of enterprisey things get pushed as a "good
| practice" to improve reuse (of things that will never be
| reused) or extensibility (of things that will never be
| extended) or modularity (of things that will never be
| separated).
| palmotea wrote:
| Enterprise development has particular problems you won't
| find in other environments, for instance having hundreds
| of different developers with _widely_ varying levels of
| skill and talent, all collaborating together, often under
| immense time and budget pressure.
|
| The result ain't going to be what you get if you've got a
| focused group of 10x geniuses working on everything, but
| I think a lot of the aspects of "enterprise development"
| that people complain about is simply the result of making
| the best of a bad situation.
|
| I like Java, because I've worked with people who will
| fuck up repeatedly without static type checking.
| Tade0 wrote:
| I can attest to that and see it as the reason why Angular
| is still so popular in the enterprise world - it has such
| a strong convention that no matter the rate of staff
| rotation the team can keep delivering.
|
| Meanwhile no two React projects are the same because they
| typically have several dependencies, each solving a small
| part of the problem at hand.
| skydhash wrote:
| > _for instance having hundreds of different developers
| with widely varying levels of skill and talent_
|
| That's a management problem. Meaning you assess that risk
| and try to alleviate it. A good solution like you say is
| languages with good type checking support. Another is
| code familiarity and reuse through frameworks and
| libraries. A third may be enforcing writing tests to
| speed up code review (and checklist rules like that).
|
| It's going to be boring, but boring is good at that
| scale.
| DonHopkins wrote:
| Mindless repetition of something you've internalized and
| never think about and never get any better at is "Best
| Reflex" not "Best Practice".
| nyrikki wrote:
| While probably not useful for everyone, the best method for
| myself actually leverages that.
|
| I am using a modified form of TDD's red/green refactor,
| specifically with an LLM interface independent of my IDE.
|
| While I error on good code over prompt engineering, I used
| the need to submit it to both refine the ADT and domain
| tests, after creating a draft of those I submit them to the
| local LLM, and continue on with my own code.
|
| If I finish first I will quickly review the output to see if
| it produced simpler code or if my domain tests ADT are
| problematic. For me this avoids rat holes and head of line
| blocking.
|
| If the LLM finishes first, I approach the output as a code
| base needing a full refactor, keeping myself engaged with the
| code.
|
| While rarely is the produced code 'production ready' it often
| struggles when I haven't done my job.
|
| You get some of the benefits of pair programming without the
| risk of demoralizing some poor Jr.
|
| But yes, tradeoff analysis and choosing the least worst
| option is the part that LLM/LRMs will never be able to do
| IMHO.
|
| Courses for horses and nuance, not "best practices" as
| anything more than reasonable defaults that adjust for real
| world needs.
| xyzzy123 wrote:
| > Once the data structures are set the coding is easy.
|
| I don't always find this, because there's a lot of "inside
| baseball" and accidental complexity in modern frameworks and
| languages. AI assist has been very helpful for me.
|
| I'm fairly polyglot and do maintenance on a lot of codebases.
| I'm comfortable with several languages and have been
| programming for 20 years but drop me in say, a Java Spring
| codebase and I can get the job done but I'm slow. Similarly,
| I'm fast with TypeScript/CDK or Terraform but slow with
| cfndsl because I skipped learning Ruby because I already knew
| Python. I know Javascript and the DOM and the principles of
| React but mostly I'm backend. So it hurts to dive into a
| React project X versions behind current and try to freshen it
| up because in practice you need reasonably deep knowledge of
| not just version X of these projects but also an
| understanding of how they have evolved over time.
|
| So I'm often in a situation where I know exactly what I want
| to do, but I don't know the idiomatic way to do it in a
| particular language or framework. I find for Java in
| particular there is enormous surface area and lots of baggage
| that has accumulated over the years which experienced Java
| devs know but I don't, e.g. all the gotchas when you upgrade
| from Spring 2.x to 3.x, or what versions of ByteBuddy work
| with blah maven plugin, etc.
|
| I used to often experience something like a 2x or 3x hit vs a
| specialised dev but with AI I am delivering close to parity
| for routine work. For complex stuff I would still try to pair
| with an expert.
| palmotea wrote:
| > I have a feeling that people who got bogged down in step 3
| were the kind of people who write a lot of wordy corporate
| boilerplate with multiple levels of abstraction for every
| single thing. AKA "best practices" type coding.
|
| Or they're the kind of people who rushed to step 3 too fast,
| substantially skipping steps 1 and/or 2 (more often step 2).
| I've worked with a lot of people like that.
| alooPotato wrote:
| I think you're overly painting that process as a waterfall
| method. In reality, i think its more of a loop. You do the loop
| a bunch of times and the solution gets better and better. The
| act of coding sometimes exposes a lot more of the requirement
| questions you didn't even know to ask in the first few steps.
|
| So anything that can let you iterate the loop faster is good.
| The analogy is kind of like if you can make your compile and
| tests faster, its way easier to code. Because you don't just
| code and test at the very end, you do it as part of a thinking
| loop.
| skydhash wrote:
| You can get a lot of stuff designed before having to start
| the loop, just like you can get the boilerplate code written
| (or use a framework), before writing any business logic.
|
| Writing code to find specs is brute-forcing the solution.
| Which is only useful when there's no answer or data (kinda
| rare in most domains). Taking some time to plan and do
| research can resolve a lot of inconsistency in your starting
| design. If you have written the code before, then you'll have
| to refactor even if the program is correct, because it will
| be a pain to maintain.
|
| In painting, even sketching is a lot of work. Which is why
| artists will collect references instead, mentally select the
| part they will extract. Once you start sketching, the end
| goal is always a final painting, even if you stop and redo
| midway. Actual prototyping is called a study and it's a
| separate activity.
| bufferoverflow wrote:
| For many developers the first couple of items isn't a thing,
| we're just given requirements and the designs. At most, you can
| point out issues and do time estimates.
|
| For my current job coding is 90% of my time. The rest is
| meetings, deployments, ticket management. Most of the time
| coding isn't particularly hard, but it sure consumes lots of
| time. I've had many days with 1000+ line diffs.
| sanderjd wrote:
| How common is this, really? I've never had a job like this,
| since about my first year or so at the entry level.
| sitzkrieg wrote:
| over 15 yrs of embedded dev here and 1/2 is 90% the problem
| every project
| hdjjhhvvhga wrote:
| > That last part is actually the easiest, and if you're
| spending inordinate amount of time there, that usually means
| the first two were not done well or you're not familiar with
| the tooling (language, library, IDE, test runner,...).
|
| I'm not sure if you're familiar with modern JS frameworks.
| apwell23 wrote:
| > With Claude, that time cost has plummeted to nearly zero.
|
| not sure if anyone knows. how good would a bigquery-sql to
| scala parser generated code would be? can i use it without
| having to dig into generated code?
| gen220 wrote:
| I'm somebody who used to think your way until very recently
| (long-time vim user, fast typer, etc.).
|
| I'd recommend you give `aider` specifically a try. It's slowly
| taken over more and more of the "what" and "how" buckets
| outlined in the article, especially for large-surface-area code
| bases.
|
| It turns out, for me at least, there is a big mental activation
| hurdle between "what" and "how". I need a lot of focus time to
| pivot between "what" and "how" efficiently, especially for work
| that spans large parts of the codebase, and work that I'm not
| super excited about doing. Using `aider` has lowered this
| activation threshold dramatically. It's made "writing code"
| about as simple as talking about a technical solution with an
| intelligent colleague.
|
| I usually follow the format (1) describe the context of the app
| / problem you're trying to solve (2) describe what you know the
| solution will look like (3) ask it for clarifying questions /
| if it needs any examples or context to know the problem space
| better, and if the solution makes sense / do they see any
| issues with it? (4) ask it to outline the solution in greater
| detail, do not write code (5) add any clarifications, now do
| the thing.
|
| i.e. it's kind of similar to interacting with a super fast,
| eager, indefatigable junior engineer. Sometimes it misses
| things or misunderstands, but not nearly enough to make the
| juice not worth the squeeze. These days, I'd say I spend more
| time reading/editing claude-generated code, writing commit
| messages, and managing deployments than I do writing code. It's
| a higher level of abstraction and I get way more leverage out
| of the deal. The code I'm writing is, on balance, better than
| the code I wrote before. It took maybe a few months to get
| here, but I'm happier for giving it a shot.
| ivape wrote:
| If we go with this analogy, we don't have advanced mech suits yet
| for this. To think an IDE is going to be the "visor", and to
| think copy-and-pasting is going to be jury-rigged weapons on the
| Mech is probably not it. The future really needs to be Jarvis and
| that Iron Man suit, whatever the programming equivalent is.
|
| "Hey I need a quick UI for a storefront", can be done with voice.
| I got pretty far with just doing this, but given my experience I
| don't feel fully comfortable in building the mech-suit yet
| because I still want to do things by hand. Think about how wonky
| you would feel inside of a Mech, trying to acclimate your mind to
| the reality that your hand movements are in unity with the mech's
| arm movements. Going to need a leap of faith here to trust the
| Mech. We've already started attacking the future by mocking it as
| "vibe coding". Calling it a "Mech" is so much more inspiring, and
| probably the truth. If I say it, I should see it. Complete
| instant feedback, like pen to paper.
| Tijdreiziger wrote:
| > We've already started attacking the future by mocking it as
| "vibe coding".
|
| The term 'vibe coding' was coined by OpenAI's co-founder.
|
| https://x.com/karpathy/status/1886192184808149383
| codr7 wrote:
| Copy/paste coding isn't exactly a new idea, it just got a lot
| easier and more popular.
| scrlk wrote:
| > The developers who thrive in this new environment won't be
| those who fear or resist AI tools, but those who master them--who
| understand both their extraordinary potential and their very real
| limitations. They'll recognise that the goal isn't to remove
| humans from the equation but to enhance what humans can
| accomplish.
|
| I feel like LLMs are just the next step on the Jobs analogy of
| "computers are bicycles for the mind" [0]. And if these tools are
| powerful bicycles available to everyone, what happens
| competitively? It reminds me of a Substack post I read recently:
|
| > If everyone has AI, then competitively no one has AI, because
| that means you are what drives the differences. What happens if
| you and LeBron start juicing? Do you both get as strong? Can you
| inject your way to Steph's jumpshot? What's the differentiator?
| This answer is inescapable in any contested domain. The
| unconventionally gifted will always be ascendant, and any device
| that's available to everyone manifests in pronounced power laws
| in their favor. The strong get stronger. The fast get faster.
| Disproportionately so. [1]
|
| [0] https://youtu.be/ob_GX50Za6c?t=25
|
| [1] https://thedosagemakesitso.substack.com/p/trashbags-of-
| facts...
| iugtmkbdfil834 wrote:
| I don't think bicycle analogy is adequate. It seems that they
| are more like cars. And if we follow that analogy, it suggests
| that the direction of the evolution will depend on whether we
| make our society dependent on being able to drive cars and grow
| fat from lack of activity or use them in a more mindful 'for
| purpose intended' way.
| jrk wrote:
| Simon Willison nailed exactly this 2 years ago:
|
| > I've been thinking about generative AI tools as "bicycles for
| the mind" (to borrow an old Steve Jobs line), but I think _"
| electric bicycles for the mind"_ might be more appropriate.
|
| > They can accelerate your natural abilities, you have to learn
| how to use them, they can give you a significant boost that
| some people might feel is a bit of a cheat, and they're also
| quite dangerous if you're not careful with them!
|
| https://simonwillison.net/2023/Feb/13/ebikes/
| onefreecomputer wrote:
| https://packet.boutique/technohumanism/codex/index.html
|
| Technology is part of humanity. Just as a hammer extends the
| hand, so too does the LLM extend the mind.
| cellis wrote:
| If you and Lebron both had mech-suits you'd be equal in
| strength. Actually you might find that maybe you communicate
| better with the machine as you've had to communicate a lot more
| for work and have further refined those neural patterns. So
| actually, I would expect those with _exceptional communication
| skills_ and _creativity_ to be the best able to take advantage
| of AI. In a world where functional code in any language can be
| spat out at 1000 tokens /s, it matters a lot more that you can
| communicate your vision than understanding the inscrutable
| byte-level architecture of ARM-64 or how to write a CUDA
| kernal, or how to use a static class properly.
| coeneedell wrote:
| LeBron James still knows more about how to play basketball
| than whoever is in the mech suit opposite him.
| bionhoward wrote:
| sounds great as long as you don't make any product or service
| that competes with Claude. Can anyone name something in that
| category?
| ttul wrote:
| I started my career as a developer in the 1990s and cut my teeth
| in C++, moving on to Python, Perl, Java, etc. in the early-2000s.
| Then I did management roles for about 20 years and was no longer
| working at the "coal face" despite having learned some solid
| software engineering discipline in my early days.
|
| As an old geezer, I appreciate very much how LLMs enable me skip
| the steep part of the learning curve you have to scale to get
| into any unfamiliar language or framework. For instance, LLMs
| enabled me to get up to speed on using Pandas for data analysis.
| Pandas is very tough to get used to unless you emerged from the
| primordial swamp of data science along with it.
|
| So much of programming is just learning a new API or framework.
| LLMs absolutely excel at helping you understand how to apply
| concept X to framework Y. And this is what makes them useful.
|
| Each new LLM release makes things substantially better, which
| makes me substantially more productive, unearthing software
| engineering talent that was long ago buried in the accumulating
| dust pile of language and framework changes. To new devs, I
| highly encourage focusing on the big picture software engineering
| skills. Learn how to think about problems and what a good
| solution looks like. And use the LLM to help you achieve that
| focus.
| luckylion wrote:
| > So much of programming is just learning a new API or
| framework.
|
| Once you're good at it in general. I recently witnessed what
| happens when a junior developer just uses AI for everything,
| and I found it worse than if a non-developer used AI: at least
| they wouldn't confuse the model with their half-understood
| ideas and wouldn't think they could "just write some glue
| code", break things in the process, and then confidently state
| they solved the problem by adding some jargon they've picked
| up.
|
| It feels more like an excavator: useful in the right hands,
| dangerous in the wrong hands. (I'd say excavators are super
| useful and extremely dangerous, I think AI is not as extreme in
| either direction)
| alabastervlog wrote:
| It used to (pre-'08 or so) be possible to be "good at
| Google".
|
| Most people were not. Most _tech_ people were not, even.
|
| Using LLMs feels a _ton_ like working with Google back then,
| to me. I would therefore expect most people to be pretty bad
| at it.
|
| (it didn't stop being possible to be "good at Google" because
| Google Search improved and made _everyone_ good at Google,
| incidentally--it 's because they tuned it to make being "bad
| at Google" somewhat better, but eliminated much of the
| behavior that made it possible to be "good at Google" in the
| process)
| consumer451 wrote:
| This is an excellent analogy. I will be borrowing it. Thank
| you.
| sanderjd wrote:
| Fun fact, I recently started reading Designing LLM
| Applications[0] (which I'm very much enjoying by the way)
| and it draws this exact analogy in the intro!
|
| 0: https://www.oreilly.com/library/view/designing-large-
| languag...
| alabastervlog wrote:
| I _swear_ I didn 't steal mine from there, LOL. Maybe I'm
| on the right track if others are noticing similar things
| about the experience of using LLMs, though.
| sanderjd wrote:
| Yes exactly, I meant it as evidence that there is
| something to this insight. Also that it stuck with me in
| the book enough to make the connection when I saw your
| comment; it's that it struck me as a good point.
| consumer451 wrote:
| Thank you, you just sold me on an O'Reilly free trial.
| Let's see what damaged I can do to that book in 10 days.
| schainks wrote:
| > primordial swamp of data science
|
| This deeply resonates with me every time I stare at pandas code
| seeking to understand it.
| consumer451 wrote:
| I am pretty much in the same boat, although I was never that
| advanced a dev to begin with.
|
| It is truly amazing what a superpower these LLM tools are for
| me. This particular moment in time feels like a perfect fit for
| my knowledge level. I am building as many MVP ideas as quickly
| as I can. Hopefully, one of them sticks with users.
| Freedom2 wrote:
| Also agree. I've been playing with Godot for some super simple
| game dev, and it's been surprisingly fantastic at helping me
| navigate Godot's systems (Nodes, how to structure a game, the
| Godot API) so I can get to the stuff that I find enjoyable
| (programming gameplay systems).
|
| No, it's not perfect and I imagine there's some large warts as
| a result, but it was much, much better than following a bog-
| standard tutorial on YouTube to get something running, and I'm
| always able to go refactor my scripts later now that I'm past
| initial scaffolding and setup.
| sanderjd wrote:
| Yep, I absolutely relate to this. ChatGPT happened to come out
| right when I needed to learn how to use kubernetes, after
| having used a different container orchestrator. It made this
| _so_ much easier.
|
| Ever since, this has been my favorite use case, to cut through
| the accidental complexity when learning a new implementation of
| a familiar thing. This not only speeds up my learning process
| and projects using the new tool, it also gives me a lot more
| confidence in taking on projects with unfamiliar tools. This is
| extremely valuable.
| daxfohl wrote:
| I've been using it to learn Lean, the proof assistant language,
| and it's great. The code doesn't always compile, but the
| general structure and approach is usually correct, and it helps
| understand different ways of doing things and the pros, cons,
| and subtleties of each.
|
| From this it has me wondering if AI could increase the adoption
| of provably correct code. Dependent types have a reputation for
| being hard to work with, but with AI help, it seems like they
| could be a lot more tractable. Moreover, it'd be beneficial it
| the other direction too: the more constraints you can build
| into the type system of your domain model, the harder it will
| be for an AI to hallucinate something that breaks it. Anything
| that doesn't satisfy the constraints will fail to compile.
|
| I doubt it, but wishful thinking.
| Centigonal wrote:
| Yep, same. I'm an old hand at pandas, and writing a 300 line
| script in pandas and asking Claude to rewrite it to polars
| taught me polars faster than any other approach I've used to
| learn a new framework.
| bcrosby95 wrote:
| This may depend upon every individual, but for me "How am I going
| to do it" is not actually writing code. It's about knowing how
| I'm going to do it before I write the code. After that point, its
| an exercise in typing speed.
|
| If I'm not 100% sure something will work, then I'll still just
| code it. If it doesn't work, I can throw it away and update my
| mental model and set out on a new typing adventure.
| codr7 wrote:
| And the only way to be 100% sure is to have written exactly the
| same thing before, which makes zero sense.
| Hyperlisk wrote:
| That's not true. I just wrote a similar comment about design
| coming first. If you've written software for awhile you just
| know what it looks like and which design patterns will be
| useful. Then when you see what your LLM says is the right
| code you can glance at it and see if it is even on the right
| track.
|
| If you're trying to LLM your way to a new social site you're
| going to need to know what entities make up that site and the
| relationships they have ahead of time. If you have no concept
| of an idea then of course the LLM will be "correct" because
| there were no requirements!
|
| Software design is important today and will be even more
| important in the future. Many companies do not require design
| docs for changes and I think it is a misstep. Software design
| is a skill that needs to be maintained.
| strict9 wrote:
| A lot of good points here which I agree with.
|
| Another way to think about it is SWE agents. About a year ago
| Devin was billed as a dev replacement, with the now common
| reaction that it's over for SWEs and it's no longer a useful to
| learn software engineering.
|
| A year later there have been large amounts of layoffs that
| impacted sw devs. There have also been a lot of fluff statements
| attributing layoffs to increased efficiency as a result of AI
| adoption. But is there a link? I have my doubts and think it's
| more related to interest rates and the business cycle.
|
| I've also yet to see any AI solutions that negate the need for
| developers. Only promises from CEOs and investors. However, I
| have seen how powerful it can be in the hands of people that know
| how to leverage it.
|
| I guess time will tell. In my experience the current trajectory
| is LLMs making tasks easier and more efficient for people.
|
| And hypefluencers, investors, CEOs, and others will continue
| promising that just around the corner is a future in which human
| software developers are obsolete.
| apwell23 wrote:
| ceos found AI as escape hatch for their over hiring during
| pandemic boom year.
|
| they were just playing to this market reaction
|
| layoffs = bad
|
| layoffs because of AI = good
| namaria wrote:
| Yup. Also I am excited for the bump in my rates when the
| cycle inverts and there's a dearth of people who can code
| without the then defunct LLMs.
| antirez wrote:
| I agree that AI powered programming can give you a boost, and the
| points made in the post I would agree with _if_ they were not
| made about Claude Code or other "agentic" coding tools. The
| human-LLM boosting interaction exists particularly when you use
| the LLM in its chat form, where you inspect and reshape with both
| editing the code and explaining with words what the LLM produced,
| and where (this is my golden rule) you can only move code from
| the LLM environment to your environment after inspecting and
| manually cut & pasting stuff. Claude Code and other similar
| systems have a different goal: to allow somebody to create a
| project without much coding at all, and the direction is to
| mostly observe more the result itself of the code, that how it is
| written and the design decisions. This is _fine with me_ , I
| don't tell people what to do, and many people can't code, and
| with systems like that they can build a certain degree of
| systems. But: I believe that tody, 21 April 2025 (tomorrow it may
| change) the human+LLM strict collaboration on the code, where the
| LLM is mostly a tool, is what produces the best results possible,
| assuming the human is a good coder.
|
| So I would say there are three categories of programmers:
|
| 1. Programmers that just want to prompt, using AI agents to write
| the code.
|
| 2. Programmers, like me, that use LLM as tools, writing code by
| hand, letting the LLM write some code too, inspecting it,
| incorporating what makes sense, using the LLM to explore the
| frontier of programming and math topics that are relevant to the
| task at hand, to write better code.
|
| 3. Programmers that refuse to use AI.
|
| I believe that today category "2" is what has a real advantage
| over the other two.
|
| If you are interested in this perspective, a longer form of this
| comment is contained in this video in my YouTube channel. Enable
| the English subtitles if you can't understand Italian.
|
| https://www.youtube.com/watch?v=N5pX2T72-hM
| Hyperlisk wrote:
| This is my experience as well. I've been skeptical for a long
| time, but recent releases have changed my mind (it's important
| to try new things even if skeptical). Large context windows are
| game-changers. I can't copy/paste fast enough.
|
| The future is coming, but you still need fundamentals to make
| sure the generated code has been properly setup for growth.
| That means you need to know what you expect your codebase to
| look like before or during your prompting so you can promote
| the right design patterns and direct the generation towards the
| proper architecture.
|
| So software design is not going away. Or it shouldn't for
| software that expects to grow.
| noisy_boy wrote:
| > The human-LLM boosting interaction exists particularly when
| you use the LLM in its chat form
|
| I feel reassured to see that I'm not the only one who feels
| this way. With all the talk about in-IDE direct code editing, I
| was thinking that I was being somewhat of a luddite who feels
| like the chat form is the best balance between getting help
| from the AI and understanding/deciding how things are actually
| structured/working.
| Snuggly73 wrote:
| 2. is mostly what works for me.
|
| Usually when I am in the flow of writing code, I can think,
| write, tab away and review without breaking it. If I need a
| smallish (up to 100-ish lines) piece of code that I know the
| shape of - I would use the chat to generate it and merge it
| back after review.
|
| Letting the agent rip always has led to more pain and suffering
| down the line :(
| aerhardt wrote:
| I've also settled on a copy-paste LLM workflow.
|
| I can see the usefulness of agents however for (a) some tedious
| refactorings where the IDE features might not reach and (b)
| occasionally writing a first pass of a low-value module when I
| am low on energy.
|
| For the rest of stuff I feel very happy with copy-paste.
| Workaccount2 wrote:
| I question how much code and what kind of code is actually going
| to be needed when the world is composed entirely of junior
| engineers who can write 100 LOC a second?
|
| Will it just be these functional cores that are the product, and
| users will just use an LLM to mediate all interaction with it?
| The most complex stuff, the actual product, will be written by
| those skilled in mech suits, but what will it look like when it
| is written for a world where everyone else has a mech suit
| (albeit less capable) on too?
|
| Think like your mother running a headless linux install with an
| LLM layer on top, and it being the least frustrating and most
| enjoyable computing experience she has ever had. I'm sure some
| are already thinking like this, and really it represents a
| massive paradigm shift in how software is written on the whole
| (and will ironically resemble the early days of programming).
| daxfohl wrote:
| I doubt it will come to that. Most interactions are always
| going to be much easier with a dedicated UI than with a
| chatbot. In fact, I can't think of anything I use regularly
| that I'd rather replace the UI with chat.
| istjohn wrote:
| The UI will be a thin, flexible facade over a chatbot.
| otabdeveloper4 wrote:
| More a halloween costume than mech suit.
|
| Like a toy policeman costume so you can pretend you have
| authority and you know what you're doing.
| sebastiennight wrote:
| In the current state of things, it's maybe more of a Justin
| Hammer mech suit than a Tony Stark mech suit.
| marstall wrote:
| guessing the introduction of the mech suit reduced headcount on
| the loading deck ...
| sheepscreek wrote:
| Yep. It's the ultimate one person team. With the human playing
| the role of a team lead AND manager. Sometimes even the PM. You
| want to earn big bucks? Well, this is the way now. Or earn little
| bucks and lead a small but content life. Choice is yours.
| gyrovagueGeist wrote:
| How many people still play centaur chess?
| Aperocky wrote:
| > Experience Still Matters
|
| My personal opinion is that now experience matters _a lot more_.
|
| A lot of times, the subtle mistakes that LLM makes or wrong
| direction that it takes can only be corrected by experience. LLM
| also don't tend to question its own decisions in the past, and
| will stick with them unless explicitly told.
|
| This means LLM based project accumulate subtle bugs unless there
| is a human in the loop who can rip them out, and once a project
| accumulated enough subtle bugs it generally becomes unrecoverable
| spaghetti.
| diggan wrote:
| > LLM also don't tend to question its own decisions in the
| past, and will stick with them unless explicitly told.
|
| Dangerous as well, is that LLMs won't (unless aggressively
| prompted to) question your own decisions either, in contrast to
| something like a mentor which would help you discover a better
| way, if there is one.
| Aperocky wrote:
| That part didn't change with or without LLMs though. At least
| LLM is one more set of eye on my own decisions.
| warkdarrior wrote:
| I've never seen anyone claim that coding LLMs are mentors,
| but rather junior devs there to help you. Taking them as
| mentors changes the task completely. LLM-as-junior-dev
| definitely requires you to know what you want the code to do
| and what you expect as quality output.
| pjmlp wrote:
| Keep believing it is augmentation.
|
| The end game is outsourcing, instead of team mates doing the
| actual programing from the other side of the planet, it will be
| from inside the computer.
|
| Sure the LLMs and Agents are rather limited today, just like
| optimizating compilers were still a far dream in the 1960's.
| sly010 wrote:
| And just like optimizing compilers LLMs also emit code that is
| difficult to verify and no-one really understands, so when the
| shit hits the fan you have no idea what's going on.
| Aperocky wrote:
| Is it though? Most code that LLM emits are easier to
| understand than equivalent code by humans in my experience,
| helped by overt amount of comment added at every single step.
|
| That's not to say the output is correct, there are usually
| bugs and unnecessary stuff if the logic generated isn't
| trivial, but reading it isn't the biggest hurdle.
|
| I think you are referring to the situation where people just
| don't read the code generated at all.. in that case it's not
| really LLM's fault.
| bluefirebrand wrote:
| > Most code that LLM emits are easier to understand than
| equivalent code by humans in my experience
|
| Even if this were true, which I strongly disagree with, it
| actually doesn't matter if the code is easier to understand
|
| > I think you are referring to the situation where people
| just don't read the code generated at all.. in that case
| it's not really LLM's fault
|
| It may not be the LLM's "fault", but the LLM has enabled
| this behavior and therefore the LLM is the root cause of
| the problem
| akra wrote:
| That's kinda obvious that's their goal especially with the
| current focus on coding of most of the AI labs in most
| announcements - it may be augmentation now but that isn't the
| end game. Everything else these AI labs do, while fun seems
| like at most a "meme" to most people in relative terms.
|
| Most Copilot style setup's (not just in this domain) are
| designed to gather data and train/gather feedback before full
| automation or downsizing. If they outright said it they may not
| have got the initial usage needed to do so from developers.
| Even if it is augmentation it feels like at least to me the
| other IT roles (e.g. BA's, Solution Engineers maybe?) are safer
| than SWE's going forward. Maybe its because dev's have a skin
| in the game and without AI its not that easy of a job over time
| makes it harder for them to see. Respect for SWE as a job in
| general has fallen in at least my anecdotal conversations
| mainly due to AI - after all long term career prospects are a
| major factor in career value, social status and personal goals
| for most people.
|
| Their end goal is to democratize/commoditize programming with
| AI as low hanging fruit which by definition reduces its value
| per unit of output. The fact that there is so much discussion
| on this IMO shows that many even if they don't want to admit it
| there is a decent chance that they will succeed at this goal.
| alganet wrote:
| Expectation: mech suit with developer inside.
|
| Reality: a saddle on the developer's back.
|
| They really want a faster horse.
| submeta wrote:
| > How LLM-powered programming tools amplify developer
| capabilities rather than replace them
|
| This is my experience as well. You have to know what you want,
| how to interfere if things go in the wrong direction, and what to
| do with the result as well.
|
| What I did years ago with a team of 3-5 developers I can do now
| alone using Claude Code or Cursor. But I need to write a PRD,
| break it down into features, epics and user stories, let the llm
| write code, review the results. Vibe coding tools feel like half
| a dozen junior to mid level developers for a fraction of the
| cost.
| causal wrote:
| The article is correct about the current state of using LLMs, but
| I didn't see an explanation WHY they are like this; just more
| "how".
|
| I'm curious about the fundamental reason why LLMs and their
| agents struggle with executive function over time.
| namaria wrote:
| Theoretical limitations of multi-layer Transformer
| https://arxiv.org/abs/2412.02975
|
| On Limitations of the Transformer Architecture
| https://arxiv.org/abs/2402.08164
|
| Limits of Deep Learning: Sequence Modeling through the Lens of
| Complexity Theory https://arxiv.org/abs/2405.16674
|
| TL;DR transformers are inherently limited with tasks requiring
| composition of sequential steps
| dist-epoch wrote:
| > Chess provides a useful parallel here. "Centaur chess" pairs
| humans with AI chess engines, creating teams that outperform both
| solo humans and solo AI systems playing on their own. What's
| fascinating is that even when AI chess engines can easily defeat
| grandmasters, the human-AI combination still produces superior
| results to the AI alone. The human provides strategic direction
| and creative problem-solving; the machine offers computational
| power and tactical precision.
|
| Can we stop saying this? It hasn't been true for more than 15
| years.
| yobananaboy wrote:
| https://web.archive.org/web/20250421182808/https://matthewsi...
| Site got hugged
| AlexCoventry wrote:
| Archive.org link (site is down, for me.)
| https://web.archive.org/web/20250421152532/https://matthewsi...
___________________________________________________________________
(page generated 2025-04-21 23:00 UTC)