6 ms·

My "actual job" isn't to write code, but to solve problems. Writing code has just typically been how I've needed to solve those problems. That has increasingl

by vidarh 10mo ago

My "actual job" isn't to write code, but to solve problems. Writing code has just typically been how I've needed to solve those problems. That has increasingly shifted to "just" reviewing code and focusing on the architecture and domain models. I get to spend more time on my actual job.

thefaux 10mo ago
This feels like it conflates problem solving with the production of artifacts. It seems highly possible to me that the explosion of ai generated code is ultimately creating more problems than it is solving and that the friction of manual coding may ultimately prove to be a great virtue.
- Difwif 10mo ago
  This statement feels like a farmer making a case for using their hands to tend the land instead of a tractor because it produces too many crops. Modern farming requires you to have an ecosystem of supporting tools to handle the scale and you need to learn new skills like being a diesel mechanic. How we work changes and the extra complexity buys us productivity. The vast majority of software will be AI generated, tools will exist to continuously test/refine it, and hand written code will be for artists, hobbyists, and an ever shrinking set of hard problems where a human still wins.
  - hluska 10mo ago
    I’ll be honest with you pal - this statement sounds like you’ve bought the hype. The truth is likely between the poles - at least that’s where it’s been for the last 35 years that I’ve been obsessed with this field.
    - paulcole 10mo ago
      They may be early but they’re not wrong.
      - lazide 10mo ago
        That could be said about hover cars too.
        HumblyTossed 10mo ago
        The Moller car is just weeks away, haven't you heard?
      - taco_emoji 10mo ago
        self-driving cars are only 5 years away, just like 10 years ago
        pixl97 10mo ago
        "Airplanes are only 5 years away, just like 10 years ago" --Some guy in 1891. Never use your phrase to say something is impossible. I mean there are driverless Waymo's on the street in my area so your statement is already partially incorrect.
        HumblyTossed 10mo ago
        Nobody is saying it isn't possible. Just saying nobody wants to pay as much money as it's going to take to get there. At some point investors will say, meh, good 'nuff.
        player1234 10mo ago
        [dead]
        taco_emoji 9mo ago
        absolutely no one said that in 1891
        taco_emoji 9mo ago
        "Flying cars are only 5 years away, just like 10 years ago" --Some guy in 1985
    - HumblyTossed 10mo ago
      I feel like we are at the crescendo point with "AI". Happens with every tech pushed here. 3DTV? You have those people who will shout you down and say every movie from now on will be 3D. Oh yeah? Hmmm... Or the people who see Apple's goggles and yell that everyone will be wearing them and that's just going to be the new norm now. Oh yeah? Hmmm... Truth is, for "AI" to get markedly better than it is now (0) will take vastly more money than anyone is willing to put into it. (0) Markedly, meaning it will truly take over the majority of dev (and other "thought worker") roles.
  - player1234 10mo ago
    [dead]
  - Kbelicius 10mo ago
    > This statement feels like a farmer making a case for using their hands to tend the land instead of a tractor because it produces too many crops. Modern farming requires you to have an ecosystem of supporting tools to handle the scale and you need to learn new skills like being a diesel mechanic. This to me looks like an analogy that would support what GP is saying. With modern farming practices you get problems like increased topsoil loss and decreased nutritional value of produce. It also leads to a loss of knowledge for those that practice those techniques of least resistance in short term. This is not me saying big farming bad or something like that, just that your analogy, to me, seems perfectly in sync with what the GP is saying.
    - Talanes 10mo ago
      And those trade-offs can only pay off if the extra food produced can be utilized. If the farm is producing more food than can be preserved and/or distributed, then the surplus is deadweight.
  - teeray 10mo ago
    This is a false equivalence. If the farmer had some processing step which had to be done by hand, having mountains of unprocessed crops instead of a small pile doesn’t improve their throughput.
  - mcpar-land 10mo ago
    This is the classic mistake all AI hypemen make by assuming code is an asset, like crops. Code is a liability and you must produce as little of it as possible to solve your problem.
    - vidarh 10mo ago
      As an "AI hypeman" I 100% agree that code is a liability, which is exactly why I relish being able to increasingly treat code as disposable or even unnecessary for projects that'd before require a multiple developers a huge amount of time to produce a mountain of code.
- vidarh 10mo ago
  I measure what I do by output. Just about a week ago I launched a 100% AI generated project that shortcircuits a bunch of manual tasks. What before took 3+ weeks of manual work to produce, now takes us 1-2 days to verify instead. It generates revenue. It solved the problem of taking a workflow that was barely profitable and cutting costs by more than 90%. Half the remaining time is ongoing process optimization - we hope to fully automate away the reaming 1-2 days. This was a problem that wasn't even tractable without AI, and there's no "explosion of AI generated code". I fully agree that some places will drown in a deluge of AI generated code of poor quality, but that is an operator fault. In fact, one of my current clients retained me specifically to clean up after someone who dove head first into "AI first" without an understanding of proper guardrails.
  - bendmorris 10mo ago
    >This was a problem that wasn't even tractable without AI, and there's no "explosion of AI generated code". People often say this when giving examples, but what specifically made the problem intractable? Sometimes before beginning work on a problem, I dramatically overestimate how hard it will be (or underestimate how capable I am of solving it.)
Kamq 10mo ago
> My "actual job" isn't to write code, but to solve problems. Yes, and there's often a benefit to having a human have an understanding of the concrete details of the system when you're trying to solve problems. > That has increasingly shifted to "just" reviewing code It takes longer to read code than to write code if you're trying to get the same level of understanding. You're gaining time by building up an understanding deficit. That works for a while, but at some point you have to go burn the time to understand it.
- laurentiurad 10mo ago
  It's like any other muscle, if you don't exercise it, you will lose it. It's important that when you solve problems by writing code, you go through all the use cases of your solution. In my experience, just reading the code given by someone else (either a human or machine) is not enough and you end up evaluating perhaps the main use cases and the style. Most of the times you will find gaps while writing the code yourself.
- jvanderbot 10mo ago
  > often a benefit to having a human have an understanding of the concrete details of the system Further elaborating from my experience. 1. I think we're in the early stages, where agents are useful because we still know enough to coach well - knowledge inertia. 2. I routinely make the mistake of allowing too much autonomy, and will have to spend time cleaning up poor design choices that were either inserted by the agent, or were forced upon it because I had lost lock on the implementation details (usually both in a causal loop!) I just have a policy of moving slowly and carefully now through the critical code, vs letting the agent steer. They have overindexed on passing tests and "clean code", producing things that cause subtle errors time and time again in a large codebase. > burn the time to understand it. It seems to me to be self-evident that writing produces better understanding than reading. In fact, when I would try to understand a difficult codebase, it often meant that probing+rewriting produced a better understanding than reading, even if those changes were never kept.
- vidarh 10mo ago
  > It takes longer to read code than to write code if you're trying to get the same level of understanding. You're gaining time by building up an understanding deficit. That works for a while, but at some point you have to go burn the time to understand it. This is true whether an AI wrote the code or a co-worker, except the AI is always on hand to answer detailed questions about the code, do detailed analysis, and run extensive tests to validate assumptions. It is very rarely productive any more to dig into low level code manually.
eaglelamp 10mo ago
All employees solve problems. Developers have benefited from the special techniques they have learned to solve problems. If these techniques are obsolete, or are largely replaced by minding a massive machine, the character of the work, the pay for performing it, and social position of those who perform it will change.
blibble 10mo ago
this is the standard consultant vs employee angle if you're a consultant/contractor that's bid a fixed amount for a job: you're incentivised to slop out as much as possible to hit the complete the contract as quickly as possible and then if you do a particularly bad job then you'll be probably kept on to fix up the problems vs. an permanent employee that is incentivised to do the job well, sign it off and move onto the next task
- vidarh 10mo ago
  You're making flawed assumptions you have no basis for. Most of my work is on projects I have a long term vested interest in. I care far more about maximally leveraging LLMs for the projects I have a vested interest in - if my clients don't want to, that's their business. Most of my LLM usage directly affects my personal finances in terms of the ROI my non-consulting projects generate - I have far more incentives to do the job well than a permanent employee whose work does not have an immediate effect on their income.
  - blibble 10mo ago
    it appears as if I touched a nerve there I'm making no assumptions it is my observation of the contractor/employee relationship over my 20 year career, from tiny startups to megacorps (and having been on both sides of the fence)
    - vidarh 9mo ago
      So you just threw out an observation that has no relevance to what I wrote or my situation, and it implied no assumptions. Sure.
mythical_39 10mo ago
wait, did you see the part where the person you are replying to said that writing the code themself was essential to correctly solving the problem? Because they didn't understand the architecture or the domain models otherwise. Perhaps in your case you do have strong hands-on experience with the domain models, which may indeed have shifted you job requirements to supervising those implementing the actual models. I do wonder, however, how much of your actual job also entails ensuring that whoever is doing the implementation is also growing in their understanding of the domain models. Are you developing the people under you? Is that part of your job? If it is an AI that is reporting to you, how are you doing this? Are you writing "skills" files? How are you verifying that it is following them? How are you verifying that it understands them the same way that you intended it to? Funny story-- I asked a LLM to review a call transcript to see if the caller was an existing customer. The LLM said True. It was only when I looked closer that I saw that the LLM mean "True-- the caller is an existing customer of one of our competitors". Not at all what I meant.
- vidarh 10mo ago
  I saw that part and I disagreed with the very notion, hence why I wrote what I did. > Because they didn't understand the architecture or the domain models otherwise. My point is that requiring or expecting an in-depth understanding of all the algorithms you rely on is not a productive use of developer time, because outside narrow niches it is not what we're being paid for. It is also not something the vast majority of us do now, or have done for several decades. I started with assembler, but most developers have never-ever worked less than a couple of abstractions up, often more, and leaned heavily on heaps of code they do not understand because it is not necessary. Sometimes it is. But for the vast majority of us pretending it is necessary all the time or even much of the time is a folly. > I do wonder, however, how much of your actual job also entails ensuring that whoever is doing the implementation is also growing in their understanding of the domain models. Are you developing the people under you? Is that part of your job? Growing the people under me involves teaching them to solve problems, and already long before AI that typically involved teaching developers to stop obsessing over details with low ROI for the work they were actually doing in favour of understanding and solving the problems of the business. Often that meant making them draw a line between what actually served the needs they were paid to solve rather than the ones that were personally fun to them (I've been guilty of diving into complex low-level problems I find fun rather than what solves the highest ROI problems too - ask me about my compilers, my editor, my terminal - I'm excellent at yak shaving, but I work hard to keep that away from my work) > If it is an AI that is reporting to you, how are you doing this? Are you writing "skills" files? How are you verifying that it is following them? How are you verifying that it understands them the same way that you intended it to? For AI use: Tests. Tests. More tests. And, yes, skills and agents. Not primarily even to verify that it understands the specs, but to create harnesses to run them in agent loops without having to babysit them every step of the way. If you use AI and spend your time babysitting them, you've become a glorified assistant to the machine.
HumblyTossed 10mo ago
You're right that a dev's job is to solve problems. However, one loses a lot of that if one doesn't think in computerese - and only reading code isn't enough. One has to write code to understand code. So for one to do one's _actual_ job, they cannot depend solely on "AI" to write all the code.
- vidarh 10mo ago
  We used to say that about people who wrote in C instead of assembler. Then we used to say that (any many still do) about people who opted for "scripting languages" over "systems languages". It's "true" in a sense. It helps. But it is also largely irrelevant for most of us, in that most of us are writing code you can learn to read and write in a tiny proportion of the time we spend in working life. The notion that you need to keep spending more than a tiny fraction of your time writing code in order to understand enough to be able to solve business problem will seem increasingly quaint.
  - HumblyTossed 10mo ago
    > The notion that you need to keep spending more than a tiny fraction of your time writing code in order to understand enough to be able to solve business problem will seem increasingly quaint. Completely disagree. Reading books doesn't make you an author. Reading books AND writing books makes you an author.
    - vidarh 10mo ago
      The entire point is we increasingly don't need to be authors. Most of us aren't paid to be authors in your analogy. (Which is good, because outside of your analogy, most authors are paid peanuts, and most of those of us who do write do so because we enjoy it, not as a job) But even if our jobs were to be authors, while I learned some things about writing books from writing the novels I have written and published, I learned far more from being a voracious reader for decades. I probably needed both, and I'm sure I'd improve as a writer past what I could from just reading by writing more, I think your analogy if anything is a perfect fit for my point that we don't need to spend more than a tiny proportion our time writing to be competent at it (I won't claim great). Many of us will probably keep doing it for fun, but it will be increasingly hard to justify "manual coding" at work.
notanastronaut 10mo ago
I'm in the same boat. There's a lot of things I don't know and using these models help give direction and narrow focus towards solutions I didn't know about previously. I augment my knowledge, not replace. Some people learn from rote memorization, some people learn through hands on experience. Some people have "ADHD brains". Some people are on the spectrum. If you visit Wikipedia and check out Learning Styles, there's like eight different suggested models, and even those are criticized extensively. It seems a sort of parochial universalism has coalesced, but people should keep in mind we don't all learn the same. ETA: I'd also like to say learning from LLMs are vastly similar, and some ways more useful, than finding blogs on a subject. A lot of time, say for Linux, you'll find instructions that even if you perform them to a tee, something goes pear shaped, because of tiny environment variables or a single package update changes things. Even Photoshop tutorials are not free of this madness. I'm used to mostly correct but just this side of incorrect instructions. LLMs are no different in a lot of ways. At least with them I can tailor my experience to just what I'm trying to do and spend time correcting that versus loading up a YT video trying to understand why X doesn't work. But I can understand if people don't get the same value as I do.
wiseowise 10mo ago
So what happens when LLM provider and/or internet is down or you're out of credits?
- vidarh 10mo ago
  If the internet is down I can't do most of my work with or without an LLM, and redundancy is a thing. The only way I'll run out of credits is if my company isn't liquid any longer in which case I have bigger problems. And there are plenty of LLM providers, almost only a few w/SOTA models but even for SOTA models there is no reason to be dependent on one.
taco_emoji 10mo ago
I don't care what my "actual" job is. I like writing code. I like exercising my brain in that way. I like building things. I do not want to be a supervisor of AI agents. I do not want to engineer prompts, I want to engineer software.
- vidarh 10mo ago
  I sympathise, in as much as I love writing code too, but I increasingly restrict that to my personal projects. It is simply not cost effective any more to write code manually vs. proper use of agents, and developers who resist that will find it increasingly hard to stay employed.
  - alfalfasprout 10mo ago
    > It is simply not cost effective any more to write code manually vs. proper use of agents, and developers who resist that will find it increasingly hard to stay employed. In practice, this isn't bearing out at all though both among my peers and with peers in other tech companies. Just making a blanket statement like this adds nothing to the conversation.
- direwolf20 10mo ago
  Devs are one of the last fields to be ruined by capitalism, but it has finally arrived here too.
pwython 10mo ago
My "actual job" is a designer, not a career engineer, so for me code has always been how I ship. AI makes that separation clearer now. I just recently wrote about this.[0] But I think the cognitive debt framing is useful: reading and approving code is not the same as building the mental model you get from writing, probing, and breaking things yourself. So the win (more time on problem solving) only holds if you're still intentionally doing enough of the concrete work to stay anchored in the system. That said, if you're someone like me, I don't always need to fully master everything, but I do need to stay close enough to reality that I'm not shipping guesses. [0] https://alisor.substack.com/p/i-never-really-wrote-code-now-thats https://alisor.substack.com/p/i-never-really-wrote-code-now-...
sodapopcan 10mo ago
> My "actual job" isn't to write code, but to solve problems. You're like 836453th person to say this. It's not untrue, but many of us will take writing over reviewing any day. Reviewing is like the worst part of the job.
- mcv 10mo ago
  I strongly prefer writing the code myself and letting AI review it, over the other way around.
- vidarh 10mo ago
  I use AI heavily to review the code too, and it makes it far simpler. E.g. "show me why <this assumption that is necessary for the code I'm currently staring at> holds" makes it far more pleasant to do reviews. AI code review tooling works well to reduce that burden. Even more so when you have that AI cod review tooling running as part of your agent loop first before you even look at a delivery. "prove X" is another one - if it can't find a test case that already proves X and resorts to writing code to prove X, you probably need more tests, and now you have one,.
  - sodapopcan 10mo ago
    You never quite learn things are well when you just read, though. I know no one really cares these days, though (sincerely).
    - vidarh 9mo ago
      Engaging in a conversation over why and evaluating evidence is not remotely the same as just reading.
acedTrex 10mo ago
Did you not read the comment you are replying too?
- vidarh 10mo ago
  I did. Did you read the comment you replied to?
  - rob 10mo ago
    Just curious, are these articles on your "blog" written by AI or are you writing them all by hand? https://hokstadconsulting.com/blog https://hokstadconsulting.com/blog Very impressive daily output! Keep up the good work.
    - discreteevent 10mo ago
      3 blogs a day, including Christmas day. Impressive indeed!
ASalazarMX 10mo ago
Then your job has turned into designing solutions, and asking a (sometimes unreliable) LLM to make them for you. If you keep at it, soon you'll accumulate enough cognitive debt to become a fossil, knowing what has to be done, but not quite how it is done.
- asdff 10mo ago
  And really where is your moat? Why pay for a senior when a junior can prompt an LLM all the same? People are acting like its juniors who are going to be out of work like companies are going to just keep paying seniors for their now obsolete skills.
  - player1234 9mo ago
    [dead]
  - vidarh 9mo ago
    Where do you think your moat is if you insist on sticking at a level of abstraction where the AI keeps eating into your job, instead of stepping up and handling architecture, systems design, etc. at a higher level?
- jackblemming 10mo ago
  So no different than management up to the CEO who simply “delegate” to the underlyings?
  - Talanes 10mo ago
    Except most those people have developed the separate skillset of playing work politics to make their job seem necessary.
  - ASalazarMX 9mo ago
    Exactly. A manager or CEO won't call themselves software engineers. If we change our role similarly in the development cycle, neither should we.
pranavj 10mo ago
Exactly this. The shift from "writing code" to "reviewing code and focusing on architecture" is the natural evolution. Every abstraction layer in computing history freed us to think at higher levels - assembler to C, C to Python, and now Python to "describe what you want." The people framing this as "cognitive debt" are measuring the wrong thing. You're not losing the ability to think - you're shifting what you think about. That's not a bug, it's the whole point.
- slekker 10mo ago
  The problem is that how do you review code if you don't know what it is supposed to look like? Creativity is not only in the problem solving step but also when implementing it, and letting an LLM do most of it is incredibly dangerous for the future, more so on juniors are gaining experience this way. The software quality will be much worse, and the churn even higher, and I will be in a farm with my chickens
coldtea 10mo ago
>My "actual job" isn't to write code, but to solve problems Solve enough problems relying on AI writing the code as a black box, and over time your grasp of coding will worsen, and you wont be undestanding what the AI should be doing or what it is doing wrong - not even at the architectural level, except in broad strokes. One ends like the clueless manager type who hasn't touched a computer in 30 years. At which point there will be little reason for the actual job owners to retain their services. Computer programming on the whole relying on the canned experience of the AI data set, producing more AI churn as ratio of the available training code over time, and plateuing both itself and AI, with the dubious future of reaching Singularity its only hope out of this.
- listenallyall 10mo ago
  To be fair, if you manage to stay employed for 30 years before people determine your skills are sub-standard, that's a lot better than most. But I generally agree with your point.
- alchemism 10mo ago
  Yet most organizations in existence pay the people “who hasn’t touched a computer in 30 years” quite a large amount of money to continue to solve problems, for some inscrutable reason… =)
  - bakugo 10mo ago
    Managers being overpaid and overvalued is a well known phenomenon, yes.
    - brookst 10mo ago
      It’s as old as the issue of narrowly-focused ICs having no appreciation for or interest in anything outside their narrow (but deep) expertise.
  - tayo42 10mo ago
    There is a track now for people to stay in engineering and get paid more then their manager
jedwards1211 10mo ago
Some of the biggest improvements I've made in the clarity and typesafety of the code I write came from seeing the weak points while slogging through writing code, and choosing or writing better libraries to solve certain problems. If everyone stops writing code I can only imagine quality will stagnate
- jedwards1211 10mo ago
  for example, I got fed up with the old form library we were using because it wasn't capable of checking field names/paths and field value types at compile time and I kept having unexpected runtime errors. I wrote a replacement form library that can deeply typecheck all of that stuff. If I had turned an AI loose against the original codebase, I think it would have just churned away copying the existing patterns and debugging any runtime errors that result. I don't think an AI would have ever voluntarily told me "this form library is costing time and effort, we should replace it with such and such instead"
- vidarh 9mo ago
  Everyone won't stop writing code. But not everone needs to code.
keybored 10mo ago
> My "actual job" isn't to write code, but to solve problems. Air quotes and more and more general words. The perfect mercenari’s tools. The buck stops somewhere for most of us. We have jobs, we are compelled to do them. But we care about how it is done. We care whether doing it in a certain will give us short term advantages but hinder us in the long term. We care if the process feels good or bad. We care if it feels like we are in control of the process or if we are just swimming in a turbulent sea. We care about how predictable the tools we use. Whether we can guess that something takes a month and not be off by weeks. We might say that we are the perfect pragmatists (mercenaris); that we only care about the most general description of what-is-to-be-done that is acceptable to the audience, like solving business problems, or solving technical problems, or in the end—as the pragmatist sheds all meaning from his burdensome vessel—just solving problems. But most of us got into some trade, or hobby, or profession, because we did concrete things that we concretely liked. And switching from keyboards to voice dictation might not change that. But seemingly upending the whole process might. It might. Or it may not. Certainly could go in more than one direction. But to people who are not perfect mercenaries or business hedonists[1] these are actual problems or concerns. Not nonsense to be dismissed with some “actual job” quip, which itself is devoid of meaning. [1] https://news.ycombinator.com/item?id=46692039 https://news.ycombinator.com/item?id=46692039
lomase 10mo ago
[dead]
palmotea 10mo ago
> I get to spend more time on my actual job. If you spend all your time on that, you might actually lose the ability to actually do it. I find a lot of "non core" tasks are pretty important for skill building and maintenance.
austinshea 9mo ago
A lot of people, who are on their way to doing truly professional work, have this epiphany. The place you need to get to is understanding that you are being asked to ensure a problem is solved. You’re only causing a larger problem by “solving” issues without both becoming an SME and ensuring that knowledge can be held by the organization, at all levels that the problem affects (onboarding, staff, project management, security, finance, auditors, c-suite.)

by vidarh 10mo ago

thefaux 10mo ago

This feels like it conflates problem solving with the production of artifacts. It seems highly possible to me that the explosion of ai generated code is ultimately creating more problems than it is solving and that the friction of manual coding may ultimately prove to be a great virtue.

Difwif 10mo ago
This statement feels like a farmer making a case for using their hands to tend the land instead of a tractor because it produces too many crops. Modern farming requires you to have an ecosystem of supporting tools to handle the scale and you need to learn new skills like being a diesel mechanic. How we work changes and the extra complexity buys us productivity. The vast majority of software will be AI generated, tools will exist to continuously test/refine it, and hand written code will be for artists, hobbyists, and an ever shrinking set of hard problems where a human still wins.
- hluska 10mo ago
  I’ll be honest with you pal - this statement sounds like you’ve bought the hype. The truth is likely between the poles - at least that’s where it’s been for the last 35 years that I’ve been obsessed with this field.
  - paulcole 10mo ago
    They may be early but they’re not wrong.
    - lazide 10mo ago
      That could be said about hover cars too.
      - HumblyTossed 10mo ago
        The Moller car is just weeks away, haven't you heard?
    - taco_emoji 10mo ago
      self-driving cars are only 5 years away, just like 10 years ago
      - pixl97 10mo ago
        "Airplanes are only 5 years away, just like 10 years ago" --Some guy in 1891. Never use your phrase to say something is impossible. I mean there are driverless Waymo's on the street in my area so your statement is already partially incorrect.
        HumblyTossed 10mo ago
        Nobody is saying it isn't possible. Just saying nobody wants to pay as much money as it's going to take to get there. At some point investors will say, meh, good 'nuff.
        player1234 10mo ago
        [dead]
        taco_emoji 9mo ago
        absolutely no one said that in 1891
        taco_emoji 9mo ago
        "Flying cars are only 5 years away, just like 10 years ago" --Some guy in 1985
  - HumblyTossed 10mo ago
    I feel like we are at the crescendo point with "AI". Happens with every tech pushed here. 3DTV? You have those people who will shout you down and say every movie from now on will be 3D. Oh yeah? Hmmm... Or the people who see Apple's goggles and yell that everyone will be wearing them and that's just going to be the new norm now. Oh yeah? Hmmm... Truth is, for "AI" to get markedly better than it is now (0) will take vastly more money than anyone is willing to put into it. (0) Markedly, meaning it will truly take over the majority of dev (and other "thought worker") roles.
- player1234 10mo ago
  [dead]
- Kbelicius 10mo ago
  > This statement feels like a farmer making a case for using their hands to tend the land instead of a tractor because it produces too many crops. Modern farming requires you to have an ecosystem of supporting tools to handle the scale and you need to learn new skills like being a diesel mechanic. This to me looks like an analogy that would support what GP is saying. With modern farming practices you get problems like increased topsoil loss and decreased nutritional value of produce. It also leads to a loss of knowledge for those that practice those techniques of least resistance in short term. This is not me saying big farming bad or something like that, just that your analogy, to me, seems perfectly in sync with what the GP is saying.
  - Talanes 10mo ago
    And those trade-offs can only pay off if the extra food produced can be utilized. If the farm is producing more food than can be preserved and/or distributed, then the surplus is deadweight.
- teeray 10mo ago
  This is a false equivalence. If the farmer had some processing step which had to be done by hand, having mountains of unprocessed crops instead of a small pile doesn’t improve their throughput.
- mcpar-land 10mo ago
  This is the classic mistake all AI hypemen make by assuming code is an asset, like crops. Code is a liability and you must produce as little of it as possible to solve your problem.
  - vidarh 10mo ago
    As an "AI hypeman" I 100% agree that code is a liability, which is exactly why I relish being able to increasingly treat code as disposable or even unnecessary for projects that'd before require a multiple developers a huge amount of time to produce a mountain of code.
vidarh 10mo ago
I measure what I do by output. Just about a week ago I launched a 100% AI generated project that shortcircuits a bunch of manual tasks. What before took 3+ weeks of manual work to produce, now takes us 1-2 days to verify instead. It generates revenue. It solved the problem of taking a workflow that was barely profitable and cutting costs by more than 90%. Half the remaining time is ongoing process optimization - we hope to fully automate away the reaming 1-2 days. This was a problem that wasn't even tractable without AI, and there's no "explosion of AI generated code". I fully agree that some places will drown in a deluge of AI generated code of poor quality, but that is an operator fault. In fact, one of my current clients retained me specifically to clean up after someone who dove head first into "AI first" without an understanding of proper guardrails.
- bendmorris 10mo ago
  >This was a problem that wasn't even tractable without AI, and there's no "explosion of AI generated code". People often say this when giving examples, but what specifically made the problem intractable? Sometimes before beginning work on a problem, I dramatically overestimate how hard it will be (or underestimate how capable I am of solving it.)

Kamq 10mo ago

> My "actual job" isn't to write code, but to solve problems. Yes, and there's often a benefit to having a human have an understanding of the concrete details of the system when you're trying to solve problems. > That has increasingly shifted to "just" reviewing code It takes longer to read code than to write code if you're trying to get the same level of understanding. You're gaining time by building up an understanding deficit. That works for a while, but at some point you have to go burn the time to understand it.

laurentiurad 10mo ago
It's like any other muscle, if you don't exercise it, you will lose it. It's important that when you solve problems by writing code, you go through all the use cases of your solution. In my experience, just reading the code given by someone else (either a human or machine) is not enough and you end up evaluating perhaps the main use cases and the style. Most of the times you will find gaps while writing the code yourself.
jvanderbot 10mo ago
> often a benefit to having a human have an understanding of the concrete details of the system Further elaborating from my experience. 1. I think we're in the early stages, where agents are useful because we still know enough to coach well - knowledge inertia. 2. I routinely make the mistake of allowing too much autonomy, and will have to spend time cleaning up poor design choices that were either inserted by the agent, or were forced upon it because I had lost lock on the implementation details (usually both in a causal loop!) I just have a policy of moving slowly and carefully now through the critical code, vs letting the agent steer. They have overindexed on passing tests and "clean code", producing things that cause subtle errors time and time again in a large codebase. > burn the time to understand it. It seems to me to be self-evident that writing produces better understanding than reading. In fact, when I would try to understand a difficult codebase, it often meant that probing+rewriting produced a better understanding than reading, even if those changes were never kept.
vidarh 10mo ago
> It takes longer to read code than to write code if you're trying to get the same level of understanding. You're gaining time by building up an understanding deficit. That works for a while, but at some point you have to go burn the time to understand it. This is true whether an AI wrote the code or a co-worker, except the AI is always on hand to answer detailed questions about the code, do detailed analysis, and run extensive tests to validate assumptions. It is very rarely productive any more to dig into low level code manually.

eaglelamp 10mo ago

All employees solve problems. Developers have benefited from the special techniques they have learned to solve problems. If these techniques are obsolete, or are largely replaced by minding a massive machine, the character of the work, the pay for performing it, and social position of those who perform it will change.

blibble 10mo ago

this is the standard consultant vs employee angle if you're a consultant/contractor that's bid a fixed amount for a job: you're incentivised to slop out as much as possible to hit the complete the contract as quickly as possible and then if you do a particularly bad job then you'll be probably kept on to fix up the problems vs. an permanent employee that is incentivised to do the job well, sign it off and move onto the next task

vidarh 10mo ago
You're making flawed assumptions you have no basis for. Most of my work is on projects I have a long term vested interest in. I care far more about maximally leveraging LLMs for the projects I have a vested interest in - if my clients don't want to, that's their business. Most of my LLM usage directly affects my personal finances in terms of the ROI my non-consulting projects generate - I have far more incentives to do the job well than a permanent employee whose work does not have an immediate effect on their income.
- blibble 10mo ago
  it appears as if I touched a nerve there I'm making no assumptions it is my observation of the contractor/employee relationship over my 20 year career, from tiny startups to megacorps (and having been on both sides of the fence)
  - vidarh 9mo ago
    So you just threw out an observation that has no relevance to what I wrote or my situation, and it implied no assumptions. Sure.

mythical_39 10mo ago

wait, did you see the part where the person you are replying to said that writing the code themself was essential to correctly solving the problem? Because they didn't understand the architecture or the domain models otherwise. Perhaps in your case you do have strong hands-on experience with the domain models, which may indeed have shifted you job requirements to supervising those implementing the actual models. I do wonder, however, how much of your actual job also entails ensuring that whoever is doing the implementation is also growing in their understanding of the domain models. Are you developing the people under you? Is that part of your job? If it is an AI that is reporting to you, how are you doing this? Are you writing "skills" files? How are you verifying that it is following them? How are you verifying that it understands them the same way that you intended it to? Funny story-- I asked a LLM to review a call transcript to see if the caller was an existing customer. The LLM said True. It was only when I looked closer that I saw that the LLM mean "True-- the caller is an existing customer of one of our competitors". Not at all what I meant.

vidarh 10mo ago
I saw that part and I disagreed with the very notion, hence why I wrote what I did. > Because they didn't understand the architecture or the domain models otherwise. My point is that requiring or expecting an in-depth understanding of all the algorithms you rely on is not a productive use of developer time, because outside narrow niches it is not what we're being paid for. It is also not something the vast majority of us do now, or have done for several decades. I started with assembler, but most developers have never-ever worked less than a couple of abstractions up, often more, and leaned heavily on heaps of code they do not understand because it is not necessary. Sometimes it is. But for the vast majority of us pretending it is necessary all the time or even much of the time is a folly. > I do wonder, however, how much of your actual job also entails ensuring that whoever is doing the implementation is also growing in their understanding of the domain models. Are you developing the people under you? Is that part of your job? Growing the people under me involves teaching them to solve problems, and already long before AI that typically involved teaching developers to stop obsessing over details with low ROI for the work they were actually doing in favour of understanding and solving the problems of the business. Often that meant making them draw a line between what actually served the needs they were paid to solve rather than the ones that were personally fun to them (I've been guilty of diving into complex low-level problems I find fun rather than what solves the highest ROI problems too - ask me about my compilers, my editor, my terminal - I'm excellent at yak shaving, but I work hard to keep that away from my work) > If it is an AI that is reporting to you, how are you doing this? Are you writing "skills" files? How are you verifying that it is following them? How are you verifying that it understands them the same way that you intended it to? For AI use: Tests. Tests. More tests. And, yes, skills and agents. Not primarily even to verify that it understands the specs, but to create harnesses to run them in agent loops without having to babysit them every step of the way. If you use AI and spend your time babysitting them, you've become a glorified assistant to the machine.

HumblyTossed 10mo ago

You're right that a dev's job is to solve problems. However, one loses a lot of that if one doesn't think in computerese - and only reading code isn't enough. One has to write code to understand code. So for one to do one's _actual_ job, they cannot depend solely on "AI" to write all the code.

vidarh 10mo ago
We used to say that about people who wrote in C instead of assembler. Then we used to say that (any many still do) about people who opted for "scripting languages" over "systems languages". It's "true" in a sense. It helps. But it is also largely irrelevant for most of us, in that most of us are writing code you can learn to read and write in a tiny proportion of the time we spend in working life. The notion that you need to keep spending more than a tiny fraction of your time writing code in order to understand enough to be able to solve business problem will seem increasingly quaint.
- HumblyTossed 10mo ago
  > The notion that you need to keep spending more than a tiny fraction of your time writing code in order to understand enough to be able to solve business problem will seem increasingly quaint. Completely disagree. Reading books doesn't make you an author. Reading books AND writing books makes you an author.
  - vidarh 10mo ago
    The entire point is we increasingly don't need to be authors. Most of us aren't paid to be authors in your analogy. (Which is good, because outside of your analogy, most authors are paid peanuts, and most of those of us who do write do so because we enjoy it, not as a job) But even if our jobs were to be authors, while I learned some things about writing books from writing the novels I have written and published, I learned far more from being a voracious reader for decades. I probably needed both, and I'm sure I'd improve as a writer past what I could from just reading by writing more, I think your analogy if anything is a perfect fit for my point that we don't need to spend more than a tiny proportion our time writing to be competent at it (I won't claim great). Many of us will probably keep doing it for fun, but it will be increasingly hard to justify "manual coding" at work.

notanastronaut 10mo ago

I'm in the same boat. There's a lot of things I don't know and using these models help give direction and narrow focus towards solutions I didn't know about previously. I augment my knowledge, not replace. Some people learn from rote memorization, some people learn through hands on experience. Some people have "ADHD brains". Some people are on the spectrum. If you visit Wikipedia and check out Learning Styles, there's like eight different suggested models, and even those are criticized extensively. It seems a sort of parochial universalism has coalesced, but people should keep in mind we don't all learn the same. ETA: I'd also like to say learning from LLMs are vastly similar, and some ways more useful, than finding blogs on a subject. A lot of time, say for Linux, you'll find instructions that even if you perform them to a tee, something goes pear shaped, because of tiny environment variables or a single package update changes things. Even Photoshop tutorials are not free of this madness. I'm used to mostly correct but just this side of incorrect instructions. LLMs are no different in a lot of ways. At least with them I can tailor my experience to just what I'm trying to do and spend time correcting that versus loading up a YT video trying to understand why X doesn't work. But I can understand if people don't get the same value as I do.

wiseowise 10mo ago

So what happens when LLM provider and/or internet is down or you're out of credits?

vidarh 10mo ago
If the internet is down I can't do most of my work with or without an LLM, and redundancy is a thing. The only way I'll run out of credits is if my company isn't liquid any longer in which case I have bigger problems. And there are plenty of LLM providers, almost only a few w/SOTA models but even for SOTA models there is no reason to be dependent on one.

taco_emoji 10mo ago

I don't care what my "actual" job is. I like writing code. I like exercising my brain in that way. I like building things. I do not want to be a supervisor of AI agents. I do not want to engineer prompts, I want to engineer software.

vidarh 10mo ago
I sympathise, in as much as I love writing code too, but I increasingly restrict that to my personal projects. It is simply not cost effective any more to write code manually vs. proper use of agents, and developers who resist that will find it increasingly hard to stay employed.
- alfalfasprout 10mo ago
  > It is simply not cost effective any more to write code manually vs. proper use of agents, and developers who resist that will find it increasingly hard to stay employed. In practice, this isn't bearing out at all though both among my peers and with peers in other tech companies. Just making a blanket statement like this adds nothing to the conversation.
direwolf20 10mo ago
Devs are one of the last fields to be ruined by capitalism, but it has finally arrived here too.

pwython 10mo ago

My "actual job" is a designer, not a career engineer, so for me code has always been how I ship. AI makes that separation clearer now. I just recently wrote about this.[0] But I think the cognitive debt framing is useful: reading and approving code is not the same as building the mental model you get from writing, probing, and breaking things yourself. So the win (more time on problem solving) only holds if you're still intentionally doing enough of the concrete work to stay anchored in the system. That said, if you're someone like me, I don't always need to fully master everything, but I do need to stay close enough to reality that I'm not shipping guesses. [0] https://alisor.substack.com/p/i-never-really-wrote-code-now-thats https://alisor.substack.com/p/i-never-really-wrote-code-now-...

sodapopcan 10mo ago

> My "actual job" isn't to write code, but to solve problems. You're like 836453th person to say this. It's not untrue, but many of us will take writing over reviewing any day. Reviewing is like the worst part of the job.

mcv 10mo ago
I strongly prefer writing the code myself and letting AI review it, over the other way around.
vidarh 10mo ago
I use AI heavily to review the code too, and it makes it far simpler. E.g. "show me why <this assumption that is necessary for the code I'm currently staring at> holds" makes it far more pleasant to do reviews. AI code review tooling works well to reduce that burden. Even more so when you have that AI cod review tooling running as part of your agent loop first before you even look at a delivery. "prove X" is another one - if it can't find a test case that already proves X and resorts to writing code to prove X, you probably need more tests, and now you have one,.
- sodapopcan 10mo ago
  You never quite learn things are well when you just read, though. I know no one really cares these days, though (sincerely).
  - vidarh 9mo ago
    Engaging in a conversation over why and evaluating evidence is not remotely the same as just reading.

acedTrex 10mo ago

Did you not read the comment you are replying too?

vidarh 10mo ago
I did. Did you read the comment you replied to?
- rob 10mo ago
  Just curious, are these articles on your "blog" written by AI or are you writing them all by hand? https://hokstadconsulting.com/blog https://hokstadconsulting.com/blog Very impressive daily output! Keep up the good work.
  - discreteevent 10mo ago
    3 blogs a day, including Christmas day. Impressive indeed!

ASalazarMX 10mo ago

Then your job has turned into designing solutions, and asking a (sometimes unreliable) LLM to make them for you. If you keep at it, soon you'll accumulate enough cognitive debt to become a fossil, knowing what has to be done, but not quite how it is done.

asdff 10mo ago
And really where is your moat? Why pay for a senior when a junior can prompt an LLM all the same? People are acting like its juniors who are going to be out of work like companies are going to just keep paying seniors for their now obsolete skills.
- player1234 9mo ago
  [dead]
- vidarh 9mo ago
  Where do you think your moat is if you insist on sticking at a level of abstraction where the AI keeps eating into your job, instead of stepping up and handling architecture, systems design, etc. at a higher level?
jackblemming 10mo ago
So no different than management up to the CEO who simply “delegate” to the underlyings?
- Talanes 10mo ago
  Except most those people have developed the separate skillset of playing work politics to make their job seem necessary.
- ASalazarMX 9mo ago
  Exactly. A manager or CEO won't call themselves software engineers. If we change our role similarly in the development cycle, neither should we.

pranavj 10mo ago

Exactly this. The shift from "writing code" to "reviewing code and focusing on architecture" is the natural evolution. Every abstraction layer in computing history freed us to think at higher levels - assembler to C, C to Python, and now Python to "describe what you want." The people framing this as "cognitive debt" are measuring the wrong thing. You're not losing the ability to think - you're shifting what you think about. That's not a bug, it's the whole point.

slekker 10mo ago
The problem is that how do you review code if you don't know what it is supposed to look like? Creativity is not only in the problem solving step but also when implementing it, and letting an LLM do most of it is incredibly dangerous for the future, more so on juniors are gaining experience this way. The software quality will be much worse, and the churn even higher, and I will be in a farm with my chickens

coldtea 10mo ago

>My "actual job" isn't to write code, but to solve problems Solve enough problems relying on AI writing the code as a black box, and over time your grasp of coding will worsen, and you wont be undestanding what the AI should be doing or what it is doing wrong - not even at the architectural level, except in broad strokes. One ends like the clueless manager type who hasn't touched a computer in 30 years. At which point there will be little reason for the actual job owners to retain their services. Computer programming on the whole relying on the canned experience of the AI data set, producing more AI churn as ratio of the available training code over time, and plateuing both itself and AI, with the dubious future of reaching Singularity its only hope out of this.

listenallyall 10mo ago
To be fair, if you manage to stay employed for 30 years before people determine your skills are sub-standard, that's a lot better than most. But I generally agree with your point.
alchemism 10mo ago
Yet most organizations in existence pay the people “who hasn’t touched a computer in 30 years” quite a large amount of money to continue to solve problems, for some inscrutable reason… =)
- bakugo 10mo ago
  Managers being overpaid and overvalued is a well known phenomenon, yes.
  - brookst 10mo ago
    It’s as old as the issue of narrowly-focused ICs having no appreciation for or interest in anything outside their narrow (but deep) expertise.
- tayo42 10mo ago
  There is a track now for people to stay in engineering and get paid more then their manager

jedwards1211 10mo ago

Some of the biggest improvements I've made in the clarity and typesafety of the code I write came from seeing the weak points while slogging through writing code, and choosing or writing better libraries to solve certain problems. If everyone stops writing code I can only imagine quality will stagnate

jedwards1211 10mo ago
for example, I got fed up with the old form library we were using because it wasn't capable of checking field names/paths and field value types at compile time and I kept having unexpected runtime errors. I wrote a replacement form library that can deeply typecheck all of that stuff. If I had turned an AI loose against the original codebase, I think it would have just churned away copying the existing patterns and debugging any runtime errors that result. I don't think an AI would have ever voluntarily told me "this form library is costing time and effort, we should replace it with such and such instead"
vidarh 9mo ago
Everyone won't stop writing code. But not everone needs to code.

keybored 10mo ago

> My "actual job" isn't to write code, but to solve problems. Air quotes and more and more general words. The perfect mercenari’s tools. The buck stops somewhere for most of us. We have jobs, we are compelled to do them. But we care about how it is done. We care whether doing it in a certain will give us short term advantages but hinder us in the long term. We care if the process feels good or bad. We care if it feels like we are in control of the process or if we are just swimming in a turbulent sea. We care about how predictable the tools we use. Whether we can guess that something takes a month and not be off by weeks. We might say that we are the perfect pragmatists (mercenaris); that we only care about the most general description of what-is-to-be-done that is acceptable to the audience, like solving business problems, or solving technical problems, or in the end—as the pragmatist sheds all meaning from his burdensome vessel—just solving problems. But most of us got into some trade, or hobby, or profession, because we did concrete things that we concretely liked. And switching from keyboards to voice dictation might not change that. But seemingly upending the whole process might. It might. Or it may not. Certainly could go in more than one direction. But to people who are not perfect mercenaries or business hedonists[1] these are actual problems or concerns. Not nonsense to be dismissed with some “actual job” quip, which itself is devoid of meaning. [1] https://news.ycombinator.com/item?id=46692039 https://news.ycombinator.com/item?id=46692039

lomase 10mo ago

[dead]

palmotea 10mo ago

> I get to spend more time on my actual job. If you spend all your time on that, you might actually lose the ability to actually do it. I find a lot of "non core" tasks are pretty important for skill building and maintenance.

austinshea 9mo ago

A lot of people, who are on their way to doing truly professional work, have this epiphany. The place you need to get to is understanding that you are being asked to ensure a problem is solved. You’re only causing a larger problem by “solving” issues without both becoming an SME and ensuring that knowledge can be held by the organization, at all levels that the problem affects (onboarding, staff, project management, security, finance, auditors, c-suite.)