12 ms·

Senior Developer Skills in the AI Age

• thisdougb 2y ago
  This is interesting, thanks for posting. I've been searching for some sort of 'real' usage of AI-coding. I'm a skeptic of the current state of things, so it's useful to see real code. I know Python, but have been coding in Go for the last few years. So I'm thinking how I'd implement this in Go. There's a lot of code there. Do you think it's a lot, or it doesn't matter? It seems reasonably clear though, easy to understand. I'd have expected better documentation/in-line comments. Is that something that you did/didn't specify?
  • ManuelKiessling 2y ago
    With this project, I was really only interested in the resulting application, and intentionally not in the resulting code. I really wanted to see how far I can get with that approach. I will ask it to clean up the code and its comments and report back.
• Quarrelsome 2y ago
  This is extremely fascinating and finally something that feels extremely tangible as opposed to vibes based ideas around how AI will "take everyone's jobs" while failing to fill in the gaps between. This feels extremely gap filling. I find it quite interesting how we can do a very large chunk of the work up front in design, in order to automate the rest of the work. Its almost as if waterfall was the better pattern all along, but we just lacked the tools at that time to make it work out.
  • skizm 2y ago
    Waterfall has always been the best model as long as specs are frozen, which is never the case.
    • Quarrelsome 2y ago
      sure, but if you're generating the code in a very small amount of time from the specs then suddenly its no longer the code that is the source, its the specs. That's what waterfall always wanted to be and it failed because writing the code usually took a lot longer than writing the specs, but now perhaps, that is no longer the case.
      • datadrivenangel 2y ago
        Specs aren't done until the product is retired, thus, code ain't done either.
    • thisdougb 2y ago
      When I first started in dev, on a Unix OS, we did 'waterfall' (though we just called it releasing software, thirty years ago). We did a a major release every year, minor releases every three months, and patches as and when. All this software was sent to customers on mag tapes, by courier. Minor releases were generally new features. Definitely times were different back then. But we did release software often, and it tended to be better quality than now (because we couldn't just fix-forward). I've been in plenty of Agile companies whose software moves slower than the old days. Too much haste, not enough speed. Specs were never frozen with waterfall.
      • PaulDavisThe1st 2y ago
        The difference between agile and waterfall only really matters at the start of a project. Once it is deployed/released/in-use, the two approaches converge, more or less.
    • zelphirkalt 2y ago
      Many companies now engage in serial waterfalling.
    • kristiandupont 2y ago
      Only if you don't learn anything while developing. Which is also never the case.
  • reneherse 2y ago
    Great observations. As a frontend designer, not a developer, I'm intrigued by the techniques presented by the author, though most devs commenting here seem to be objecting to the code quality. (Way above my pay grade, but hopefully a solvable problem.) As someone who loves to nerd out on creative processes, it's interesting indeed to contemplate whether AI assisted dev would favor waterfall vs incremental project structure. If indeed what works is waterfall dev similar to the method described in TFA, we'll want to figure out how to use iterative process elsewhere, for the sake of the many benefits when it comes to usability and utility. To me that suggests the main area of iteration would be A) on the human factors side: UX and UI design, and B) in the initial phases of the project. If we're using an AI-assisted "neo waterfall" approach to implementation, we'll want to be highly confident in the specifications we're basing it all on. On regular waterfall projects it's critical to reduce the need for post-launch changes due to their impact on project cost and timeline.[1] So for now it's best to assume we need to do the same for an AI-assisted implementation. To have confidence in our specs document we'll need a fully fledged design. A "fully humane", user approved, feature complete UX and UI. It will need to be aligned with users' mental models, goals, and preferences as much as possible. It will need to work within whatever the technical constraints are and meet the business goals of the project. Now all that is what designers should be doing anyway, but to me the stakes seem higher on a waterfall style build, even if it's AI-assisted. So to shoulder that greater responsibility, I think design teams are going to need a slightly different playbook and a more rigorous process than what's typical nowadays. The makeup of the design team may need to change as well. Just thinking about it now, here's a first take on what that process might be. It's an adaptation of the design tecniques I currently use on non-waterfall projects. ---------- ::Hypothesis for a UX and UI Design Method for AI-assisted, "Neo-Waterfall" Projects:: Main premise: Designers will need to lead a structured, iterative, comprehensive rapid prototyping phase at the beginning of a project. | Overview: | • In my experience, the DESIGN->BUILD->USE/LEARN model is an excellent guide for wrangling the iterative cycles of a rapid prototyping phase. With each "DBU/L" cycle we define problems to be solved, create solutions, then test them with users, etc. • We document every segment of the DBU/L cycle, including inputs and outputs, for future reference. • The USE/LEARN phase of the DBU/L cycle gives us feedback and insight that informs what we explore in the next iteration. • Through multiple such iterations we gain confidence in the tradeoffs and assumptions baked into our prototypes. • We incrementally evolve the scope of the prototypes and further organize the UX object model with every iteration. (Object Oriented UX, aka OOUX, is the key to finding our way to both beautiful data models and user experiences). • Eventually our prototyping yields an iteration that fulfills user needs, business goals, and heeds technical constraints. That's when we can "freeze" the UX and UI models, firm up the data model and start writing the specifications for the neo-waterfall implementation. • An additional point of technique: Extrapolating from the techniques described in TFA, it seems designers will need to do their prototyping in a medium that can later function as a keyframe constraint for the AI. (We don't want our AI agent changing the UI in the implementation phase of the waterfall project, so UI files are a necessary reference to bound its actions.) • Therefore, we'll need to determine which mediums of UI design the AI agents can perceive and work with. Will we need a full frontend design structured in directories containing shippable markup and CSS? Or can the AI agent work with Figma files? Or is the solution somewhere in between, say with a combination of drawings, design tokens, and a generic component library? • Finally, we'll need a method for testing the implemented UX and UI against the USE criteria we arrived at during prototyping. We should be able to synthesize these criteria from the prototyping documentation, data modeling and specification documents. We need a reasonable set of tests for both human and technical factors. • Post launch, we should continue gathering feedback. No matter how good our original 1.0 is, software learns, wants to evolve. (Metaphorically, that is. But maybe some day soon--actually?) Designing and making changes to brownfield software originally built with AI-assistance might be a topic worthy of consideration on its own. ---------- So as a designer, that's how I would approach the general problem. Preliminary thoughts anyway. These techniques aren't novel; I use variations of them in my consulting work. But so far I've only built alongside devs made from meat :-) I'll probably expand/refine this topic in a blog post. If anyone is interested in reading and discussing more, I can send you the link. Email me at: scott [AT] designerwho [DOT] codes ---------- [1] For those who are new to waterfall project structure, know that unmaking and remaking the "final sausage" can be extremely complex and costly. It's easy to find huge projects that have failed completely due to the insurmountable complexity. One question for the future will be whether AI agents can be useful in such cases (no sausage pun intended).
• gsibble 2y ago
  I completely agree, as a fellow senior coder. It allows me to move significantly faster through my tasks and makes me much more productive. It also makes coding a lot less painful because I'm not making typos or weird errors (since so much code autocompletes) that I spend less time debugging too.
  • overgard 2y ago
    I dunno, I just had Copilot sneak in a typo today that took about ten minutes of debugging to find. I certainly could have made a similar typo myself if copilot hadn't done it for me, but, all the same copilot probably saved me a minute worth of typing today but cost me 10 minutes of debugging.
    • cube00 2y ago
      The vibe bros would have you believe your prompt is at fault and that you need add "don't make typos".
      • overgard 2y ago
        True, I didn't have five paragraphs on the proper way to handle bounding boxes and the conceptual use of bounding boxes and "please don't confuse lower for upper". All my fault!
    • miningape 2y ago
      Even if you made a similar typo you'd have a better understanding of the code having written it yourself. So it likely wouldn't have take 10 minutes to debug.
      • overgard 2y ago
        Conceptually it was a really simple bug (I was returning a bounding box and it returned (min, min) instead of (min, max)). So, I mean, the amount that AI broke it was pretty minor and it was mostly my fault for not seeing it when I generated it. But you know, if it's messing stuff up when it's generating 4 lines of code I'm not really going to trust it with an entire file, or even an entire function.
• only-one1701 2y ago
  Increasingly I’m realizing that in most cases there is a SIGNIFICANT difference between how useful AI is on greenfield projects vs how useful it is on brownfield projects. For the former: pretty good! For the brownfield, it’s often worse than useless.
  • whiplash451 2y ago
    Right, but AI could change the ratio of greenfield vs brownfield then (« I’ll be faster if I rewrite this part from scratch »)
    • robenkleene 2y ago
      I struggle to wrap my head around how this would work (and how AI can be used to maintain and refine software in general). Brownfield code got brown by being useful and solving a real problem, and doing it well enough to be maintained. So the AI approach is to throwaway the code that's proved its usefulness? I just don't get it.
  • the-grump 2y ago
    My experience on brownfield projects is the opposite.
  • echelon 2y ago
    I think there's a similar analogy here for products in the AI era. Bolting AI onto existing products probably doesn't make sense. AI is going to produce an entirely new set of products with AI-first creation modalities. You don't need AI in Photoshop / Gimp / Krita to manipulate images. You need a brand new AI-first creation tool that uses your mouse inputs like magic to create images. Image creation looks nothing like it did in the past. You don't need Figma to design a webpage. You need an AI-first tool that creates the output - Lovable, V0, etc. are becoming that. You don't need AI in your IDE. Your IDE needs to be built around AI. And perhaps eventually even programming languages and libraries themselves need AI annotations or ASTs. You don't need AI in Docs / Gmail / Sheets. You're going to be creating documents from scratch (maybe pasting things in). "My presentation has these ideas, figures, and facts" is much different than creating and editing the structure from scratch. There is so much new stuff to build, and the old tools are all going to die. I'd be shocked if anyone is using Gimp, Blender, Photoshop, Premiere, PowerPoint, etc. in ten years. These are all going to be reinvented. The only way these products themselves survive is if they undergo tectonic shifts in development and an eventual complete rewrite.
• necovek 2y ago
  The premise might possibly be true, but as an actually seasoned Python developer, I've taken a look at one file: https://github.com/dx-tooling/platform-problem-monitoring-core/blob/main/src/platform_problem_monitoring_core/utils.py https://github.com/dx-tooling/platform-problem-monitoring-co... All of it smells of a (lousy) junior software engineer: from configuring root logger at the top, module level (which relies on module import caching not to be reapplied), over not using a stdlib config file parser and building one themselves, to a raciness in load_json where it's checked for file existence with an if and then carrying on as if the file is certainly there... In a nutshell, if the rest of it is like this, it simply sucks.
  • abid786 2y ago
    Doesn’t load_json throw if the file doesn’t exist?
    • isoprophlex 2y ago
      Yes but then why do the check in the first place
  • ilrwbwrkhv 2y ago
    Yup this tracks with what I have seen as well. Most devs who use this daily are usually junior devs or javascript devs who both write sloppy questionable code.
  • rybosome 2y ago
    Ok - not wrong at all. Now take that feedback and put it in a prompt back to the LLM. They’re very good at honing bad code into good code with good feedback. And when you can describe good code faster than you can write it - for instance it uses a library you’re not intimately familiar with - this kind of coding can be enormously productive.
    • necovek 2y ago
      I do plan on experimenting with the latest versions of coding assistants, but last I tried them (6 months ago), none could satisfy all of the requirements at the same time. Perhaps there is simply too much crappy Python code around that they were trained on as Python is frequently used for "scripting". Perhaps the field has moved on and I need to try again. But looking at this, it would still be faster for me to type this out myself than go through multiple rounds of reviews and prompts. Really, a senior has not reviewed this, no matter their language (raciness throughout, not just this file).
• jonnycoder 2y ago
  Very good concrete examples. AI is moving very fast so it can become overwhelming, but what has held true is focusing on writing thorough prompts to get the results you want. Senior developers have the experience to think through and plan out a new application for an AI to write. Unfortunately a lot of us are bogged down by working our day jobs, but we need to dedicate time to create our own apps with AI. Building a personal brand is never more important, so I envision a future where dev's have a personal website with thumbnail links (like a fancy youtube thumbnail) to all the small apps they have built. Dozens of them, maybe hundreds, all with beautiful or modern UIs. The prompt they used can be the new form of blog articles. At least that's what I plan to do.
  • owebmaster 2y ago
    > Building a personal brand is never more important the low-hanging fruit is to create content/apps to help developers create their personal brands through content/apps.
• motorest 2y ago
  What a high quality article, packed with gems. What a treat.
• datavirtue 2y ago
  That free GitHub Copilot though. Microsoft is a relentless drug dealer. If you haven't tried Copilot Edits yet, hold on to your hat. I started using it in a clean Express project and a Vue3 project in VS Code. Basically flawless edits from prompt over multiple files, new files...the works. Easy.
  • bsoles 2y ago
    But can it center a div?
• rs186 2y ago
  That prompt looks horrifying. I am not going to spend half an hour coming up with that prompt, tweaking it, and then spend many hours (on the optimistic side) to track down all the hallucinated code and hidden bugs. Have been there once, never going to do that again. I'd rather do it myself to have a piece of mind.
  • yeahitsgreat12 2y ago
    [flagged]
  • skydhash 2y ago
    I wonder how much time it would take with some samples from GitHub, and various documentation about python laying around (languages, cheatsheet, libraries)...
    • miningape 2y ago
      10 minutes tops, once you have the idea and you've thought it through a bit just spamming out the code isn't that hard nor does it take that long. If there's anything surprising (e.g. function call returns something a bit different than expected) it's fast enough to just read the docs and change your mental model slightly.
• ramesh31 2y ago
  This maps pretty well to my experience. Other devs will say things like "AI is just a stupid glorified autocomplete, it will never be able to handle my Very Special Unique Codebase. I even spent 20 minutes one time trying out Cursor, and it just failed" Nope, you're just not that good obviously. I am literally 10x more productive at this point. Sprint goals have become single afternoons. If you are not tuned in to what's going on here and embracing it, you are going to be completely obsolete in the next 6 months unless you are some extremely niche high level expert. It wont be a dramatic moment where anyone gets "fired for AI". Orgs will just simply not replace people through attrition when they see productivity staying the same (or even increasing) as headcount goes down.
  • __jochen__ 2y ago
    That's the problem. The new norm will be 10x of pre-AI productivity, nobody will be able justify hand-writing code. And until the quality bar of LLM's/their successors get much better (see e.g. comments above looking at the details in the examples given), you'll get accumulation of errors that are higher than what decent programmers get. With higher LOC and more uninspected complexity, you'll get significantly lower quality overall. The coming wave of AI-coded bugs will be fun for all. GOTO FAIL;
    • cglace 2y ago
      After spending a week coding exclusively with AI assistants, I got functional results but was alarmed by the code quality. I discovered that I didn't actually save much time, and the generated code was so complex and unfamiliar that I was scared to modify it. I still use Copilot and Claude and would say I'm able to work through problems 2-3x faster than I would be without AI but I wouldn't say I get a 10x improvement. My projects are much more complex than standard CRUD applications. If you're building simple back-office CRUD apps, you might see a 10x productivity improvement with AI, but that hasn't been my experience with more complex work.
  • williamdclt 2y ago
    Giving your anecdotal experience is only useful if you include anecdotal context: seniority, years of experience, technology, project size, sprint goal complexity…
• conductr 2y ago
  As a long time hobby coder, like 25 years and I think I’m pretty good(?), this whole LLM /vibecoding thing has zapped my creativity the past year or so. I like the craft of making things. I used tools I enjoy working with and learn new ones all the time (never got on the JS/react train). Sometimes I have an entrepreneur bug and want to create a marketable solution, but I often just like to build. Im also the kind of guy that has a shop he built, builds his own patio deck, home remodeling, Tinker with robotics, etc. Kind of just like to be a maker following my own creative pursuit. All said, it’s hard on me knowing it’s possible to use llm to spit out a crappy but functional version of whatever I’ve dreamt up with out satisfaction of building it. Yet, it also seems to now be demotivating to spend the time crafting it when I know I could use llm to do a majority of it. So, I’m in a mental quagmire, this past year has been the first year since at least 2000 that I haven’t built anything significant in scale. It’s indirectly ruining the fun for me for some reason. Kind of just venting but curious if anyone else feels this way too?
  • fragmede 2y ago
    Fascinating. it's gone the other way for me. because I can now whip up a serious contender to any SaaS business in a week, it's made everything more fun, not less.
    • cglace 2y ago
      So you can create a serious contender to Salesforce or Zapier in a week?
      • fragmede 2y ago
        like an Eventbrite or a shopmonkey. but yeah, you don't think you could? Salesforce is a whole morass. not every customer uses every corner of it, and Salesforce will nickel and dime you with their consultants and add ons and plugins. if you can be more specific as to which bit of Salesforce you want to provide to a client we can go deep.
        • 2y ago
• atemerev 2y ago
  This is excellent, and matches my experience. Those lamenting the loss of manual programming: we are free to hone our skills on personal projects, but for corporate/consulting work, you cannot ignore 5x speed advantage. It's over. AI-assisted coding won.
  • skydhash 2y ago
    Is it really 5x? I'm more surprised about 25+ years of experience, and being hard pressed to learn enough python to code the project. It's not like he's learning programming again, or being recently exposed to OOP. Especially when you can find working code samples about the subproblems in the project.
    • atemerev 2y ago
      It is 5x if you are already a senior SE knowing your programming language really well, constantly suggesting good architecture yourself ("seed files" is a brilliant idea), and not accepting any slop / asking to rewrite things if something is not up to your standards (of course, every piece of code should be reviewed). Otherwise, it can be 0.2x in some cases. And you should not use LLMs for anything security-related unless you are a security expert, otherwise you are screwed. (this is SOTA as of April 2025, I expect things to become better in the near future)
      • skydhash 2y ago
        > It is 5x if you are already a senior SE knowing your programming language really well, constantly suggesting good architecture yourself ("seed files" is a brilliant idea), and not accepting any slop / asking to rewrite things if something is not up to your standards (of course, every piece of code should be reviewed). If you know the programming language really well, that usually means you know what libraries are useful, memorized common patterns, and have some project samples laying out. The actual speed improvement would be on typing the code, but it's usually the activity that requires the least time on any successful project. And unless you're a slow typist, I can't see 5x there. If you're lacking in fundamental, then it's just a skill issue, and I'd be suspicious of the result.
• noodletheworld 2y ago
  > Once again, the AI agent implemented this entire feature without requiring me to write any code manually. > For controllers, I might include a small amount of essential details like the route name: [code] Commit history: https://github.com/dx-tooling/platform-problem-monitoring-core/commits/main/ https://github.com/dx-tooling/platform-problem-monitoring-co... Look, I honestly think this is a fair article and some good examples, but what is with this inane “I didn’t write any of it myself” claim that is clearly false that every one of these articles keeps bringing up? What’s wrong with the fact you did write some code as part of it? You clearly did. So weird.
  • ManuelKiessling 2y ago
    True, this needs to be fixed. What I wanted to express was that I didn’t do any of the implementation, that is, any logic. I need to phrase this better.
    • ManuelKiessling 2y ago
      Wait, I just saw what you meant: so no, for the Python tool my message stands. I did not write any code for it myself.
      • aerhardt 2y ago
        Not OP but did you edit the code via prompts, or was the whole thing a one-shot? That particular aspect is very confusing to me, I think you should clarify it.
        • ManuelKiessling 2y ago
          Absolutely not a one-shot, many iterations.
• colesantiago 2y ago
  Hot take: I don't see a problem with this and in fact we will see in a few years that senior engineers will be needed less in the future. I have a business which is turning in millions in ARR at the moment (made in the pandemic) it's a pest control business and we have got a small team with only 1 experienced senior engineer, we used to have 5 but with AI we reduced it to one which we are still paying well. Even with maintenance, we plan ahead for this with an LLM and make changes accordingly. I think we will see more organizations opting for smaller teams and reducing engineer count since now the code generated is to the point that it works, it speeds up development and that it is "good enough".
  • janderson215 2y ago
    This is interesting. Do you run a custom app in house? What are some of the main functions of the app? Internal or customer facing?
• windows2020 2y ago
  In my travels I find writing code to be natural and relaxing--a time to reflect on what I'm doing and why. LLMs haven't helped me out too much yet. Coding by prompt is the next lowering of the bar and vibe coding even more so. Totally great in some scenarios and adds noise in others.
• scandox 2y ago
  One of the possibly obsolete things I enjoy about working with a human junior dev is that they learn and improve. It's nice to feel all this interaction is building something.
  • plandis 2y ago
    It’s common practice to put your preferences and tips/advice into a readme solely for the LLM to consume to learn about what you want it to do. So you’d set things like code standards (and hopefully enforce them via feedback tools), guides for writing certain architectures, etc. Then when you have the LLM start working it will first read that readme to “learn” how you want it to generally behave. I’ve found that I typically edit this file as time goes on as a way to add semi-permanent feedback into the system. Even if your context window gets too large when you restart the LLM will start at that readme to prime itself. That’s the closest analogy I can think of.
• pphysch 2y ago
  I'm skeptical that 1. Clearly define requirements 2. Clearly sketch architecture 3. Setup code tool suite 4. Let AI agent write the remaining code Is better price-performance than going lighter on 1-3 and instead of 4, spending that time writing the code yourself with heavy input from LLM autocomplete, which is what LLMs are elite at. The agent will definitely(?) write the code faster, but quality and understanding (tech debt) can suffer. IOW the real takeaway is that knowing the requirements, architecture, and tooling is where the value is. LLM Agent value is dubious.
  • istjohn 2y ago
    We're just in a transitional moment. It's not realistic to expect LLM capabilities to leapfrog from marginally better autocomplete to self-guided autocoder without passing through a phase where it shows tantalizing hints of being able to go solo yet lacks the ability to follow through. Over the next couple years, the reliability, versatility, and robustness of LLMs as coders will steadily increase.
• denkmoon 2y ago
  Senior developer skills haven't changed. Wrangling paragraphs of business slop into real technical requirements, communicating these to various stakeholders, understanding how all the discrete parts of whatever system you're building fit together, being responsible for timelines, getting the rest of the team coordinated/aligned and on-track, etc. Actually coding is a relatively small part of my job. I could use an LLM for the others parts but my employer does not appreciate being given word salad.
  • 8note 2y ago
    with the ai age, i think its also making sure team members use ai in similar was to get repeatable results
• yoyohello13 2y ago
  I’ve been pretty moderate on AI but I’ve been using Claude cli lately and it’s been pretty great. First, I can still use neovim which is a massive plus for me. Second it’s been pretty awesome to offload tasks. I can say something like “write some unit tests for this file, here are some edge cases I’m particularly concerned about” then I just let it run and continue with something else. Come back a few mins later to see what it came up with. It’s a fun way to work.
  • ramon156 2y ago
    This sounds scarily like tasking interns, which only makes me empathize more and more with people studying CS. At what point is it even profitable anymore to teach a junior dev and keep them long enough until they can be considered senior
• burntcaramel 2y ago
  I agree, and I really like the concrete examples here. I tried relating it to the concept of “surprise” from information theory — if what the LLM is producing is low surprise to you, you have a high chance of success as you can compare to the version you wrote in your experienced head. If it’s high surprise then there’s a greater chance that you can’t tell right code from wrong code. I try to reframe this in a more positive light by calling it “exploration”, where you can ask follow up questions and hopefully learn about a subject you started knowing little about. But it’s important for you to realize which mode you are in, whether you are in familiar or unfamiliar waters. https://royalicing.com/2025/infinite-bicycles-for-the-mind https://royalicing.com/2025/infinite-bicycles-for-the-mind The other benefit an experienced developer can bring is using test-driven development to guide and constrain the generated code. It’s like a contract that must be fulfilled, and TDD lets you switch between using an LLM or hand crafting code depending on how you feel or the AI’s competency at the task. If you have a workflow of writing a test beforehand it helps with either path. https://royalicing.com/2025/test-driven-vibes https://royalicing.com/2025/test-driven-vibes
• ramoz 2y ago
  The gap between Sr and Jr skills with close as AI gets better. AI is coming for the SR developer, be assured. Also, Keyframing can be done in a more autonomous fashion. Sr Engineers can truly vibe code if they setup a proper framework for themselves. Key framing as described in the article is too manual.
  • barotalomey 2y ago
    > The gap between Sr and Jr skills with close as AI gets better. Sorry, but as the wind blows, we only have indications of the opposite so far and it's wildly reported as a generating losing their ability for deep thought, relying too much on automated code generation. This is especially damaging for juniors, who never get the chance to learn the tricks of the trade in the first place, and they're the ones having a hard time explaining what the code the LLM generated even does. Seniors will be few and far between, and we will charge premium for fixing up the crap LLM created, which will fit us great before retirement. Good luck when we are retired.
    • ramoz 2y ago
      The wind has blown from autocomplete to scaffolding entire applications. Where do you think this is heading? Your comment addresses another issue, again in isolated temporal fashion. You and I do not understand assembly language. Previous generations of engineers did.
      • barotalomey 1y ago
        > You and I do not understand assembly language. Having written z80 and x86 assembly since the 80s, being knee deep in several decompilation projects and a couple of emulators since then, I can safely tell you that I do know a handful assembly languages and at least 2 syntaxes. I believe other seniors have similar skill sets, for now.
• mmazing 2y ago
  When working with AI for software engineering assistance, I use it mainly to do three things - 1. Do piddly algorithm type stuff that I've done 1000x times and isn't complicated. (Could take or leave this, often more work than just doing it from scratch) 2. Pasting in gigantic error messages or log files to help diagnose what's going wrong. (HIGHLY recommend.) 3. Give it high level general requirements for a problem, and discuss POTENTIAL strategies instead of actually asking it to solve the problem. This usually allows me to dig down and come up with a good plan for whatever I'm doing quickly. (This is where real value is for me, personally.) This allows me to quickly zero in on a solution, but more importantly, it helps me zero in strategically too with less trial and error. It let's me have an in-person whiteboard meeting (as I can paste images/text to discuss too) where I've got someone else to bounce ideas off of. I love it.
  • miningape 2y ago
    Same 3 is the only use case I've found that works well enough. But I'll still usually take a look on google / reddit / stackoverflow / books first just because the information is more reliable. But it's usually an iterative process, I find pattern A and B on google, I'll ask the LLM and it gives A, B and C. I'll google a bit more about C. Find out C isn't real. Go back and try other people commenting on it on reddit, go back to the LLM to sniff out BS, so on and so on.
• plandis 2y ago
  The main questions I have with using LLMs for this purpose in a business setting are: 1. Is the company providing the model willing to indemnify _your_ company when using code generation? I know GitHub Copilot will do this with the models they provide on their hardware, but if you’re using Claude Code or Cursor with random models do they provide equal guarantees? If not I wonder if it’s only a matter of time before that landmine explodes. 2. In the US, AFAICT, software that is mostly generated by non-humans is not copyrightable. This is not an issue if you’re creating code snippets from an LLM, but if you’re generating an entire project this way then none or only small parts of the code base you generate would then be copyrightable. Do you still own the IP if it’s not copyrightable? What if someone exfiltrates your software? Do you have no or little remedy?
• sivaragavan 2y ago
  Aah.. I have been repeating this to my team for several days now. Thanks for putting this together. I start every piece of work, green or brown, with a markdown file that often contains my plan, task breakdown, data models (including key fields), API / function details, and sample responses. For the tool part, though, I took a slightly different approach. I decided to use Rust primarily for all my projects, as the compile-time checks are a great way to ensure the correctness of the generated code. I have noticed many more errors are detected in AI-generated Rust code than in any other language. I am happy about it because these are errors that I would have missed in other languages.
  • manmal 2y ago
    > I have noticed many more errors are detected in AI-generated Rust code than in any other language. Is that because the Rust compiler is just a very strong guardrail? Sounds like it could work well for Swift too. If only xcodebuild were less of a pain for big projects.
    • sivaragavan 2y ago
      Yes, exactly. AI isn’t gonna check things like memory management, data type overflows and such, during generation. It would be great if we catch them at compile time. Regarding swift, totally hear you :) Also I haven’t tried generating swift code - wondering how well that would be trained as there are fewer open source codebases for that.
• justanotherunit 2y ago
  Interesting post, but this perspective seems to be the main focus, like all the time. I find this statement to be completely wrong usage of AI: “This is especially noteworthy because I don’t actually know Python. Yes, with 25+ years of software development experience, I could probably write a few lines of working Python code if pressed — but I don’t truly know the language. I lack the muscle memory and intimate knowledge of its conventions and best practices.” You should not use AI to just “do” the hard job, since as many have mentioned, it does it poorly and sloppy. Use AI to quickly learn the advantages and disadvantages of the language, then you do not have to navigate through documentation to learn everything, just validate what the AI outputs. All is contextual, and since you know what you want in high level, use AI to help you understand the language. This costs speed yes, but I have more control and gain knowledge about the language I chose.
  • ManuelKiessling 2y ago
    I agree 100%, but in this very specific case, I really just wanted a working one-off solution that I'm not going to spend much time on going forward, AND I wanted to use it as an excuse to see how far I can go with AI tooling in a tech stack I don't know. That being said, using AI as a teacher can be a wonderful experience. For us seniors, but also and probably more importantly, for eager and non-lazy juniors. I have one such junior on my team who currently speed-runs through the craft because he uses AI to explain EVERYTHING to him: What is this pattern? Why should I use it? What are the downsides? And so on. Of course I also still tutor him, as this is a main part of my job, but the availability of an AI that knows so much and always has time for him and never gets tired etc is just fantastic.
    • justanotherunit 2y ago
      Excellent insight, and that explains a lot of your decisions. Your junior example is a prime example of why AI can be such an awesome tool, just used correctly. Just awesome!
• switch007 2y ago
  As much as I am still sceptical about AI tools, the past month has been a revolution as a senior dev myself. I'm blasting through tickets, leaving more time to tutor and help junior colleagues and do refactoring. Guiding them has then been a multiplier, and also a bit of an eye opener about how little real guidance they've been getting up until now. I didn't realise how resource constrained we'd been as a team leading to not enough time guiding and helping them. I don't trust the tools with writing code very often but they are very good at architecture questions, outputting sample code etc. Supercharged google As a generalist, I feel less overwhelmed It's probably been the most enjoyable month at this job.
• quantadev 2y ago
  As of 2025, it's no longer the case that older developers (like me at 57) are at a disadvantage just due to potentially lessened sheer brain power, as we had in our 20s. The reason is simple: We know what all the terminologies are, how to ask for things with proper and sufficient levels of detail and context, we know what the pitfalls and common error patterns are, and on and on, from decades of experience. Working with AI has similarities to management positions. You need to be a generalist. You need to know a little about everything, more so than a lot about one thing. All this can ONLY come with age, just like wisdom can only come thru experience. I just hope that most hiring managers now realize this. With AI the productivity of younger developers has gone up by a factor of 10x, but the productivity of us "Seasoned" developers has gone up 100x. This now evens the playing field, I hope, where us experienced guys will be given a fair shake in the hiring process rather than what's been happening for decades where the 20-somethings pretend to be interviewing the older guys, because some boss told them to, but they never had any actual intentions of hiring anyone over 40, just on the bases of age alone, even if some older guy aces the interview.
  • ManuelKiessling 2y ago
    This is a great observation and a beautiful perspective. Would it be okay for you if I quote this on a revised version of the article (with proper attribution, of course)?
    • quantadev 2y ago
      Sure, you have my permission. However, in my own case, I'm not currently looking for a job, and never in my life did it take more than 2 weeks to FIND a job, when looking. Been coding 24x7x365 since 1981. :) ...however I'm absolutely certain there are many interviews I've aced and not gotten the job, primarily for being in an several undesirable categories that Silicon Valley progressive wokesters despise with a passion: 1) Over 40. 2) White 3) Male 4) Straight 5) Handsome 6) Rich 7) American, speaking perfect English. All 7 of those demographic stats about me are absolutely despicable to Silicon Valley hiring managers, and any one alone is enough for them to pass by a candidate over a different one lacking the trait. You can also quote, this post about Silicon Valley too, and there was even a time when such rants like this would've been CENSORED immediately by HackerNews. Thankfully they've lightened up a bit.
• austin-cheney 2y ago
  I didn’t see anything of substance in the article. For example if they benefited from AI just how beneficial was it? Did it shrink their code by any amount or reduce execution time? No, the article was just something about enjoying AI. This is hardly anything related to senior software developer skills.
• Olreich 2y ago
  You know what’s more fun than having a bad junior write crap code while you point out their mistakes? Writing good code yourself.
• yapyap 2y ago
  > Context on Code Quality (via HackerNews): The HackerNews discussion included valid critiques regarding the code quality in this specific Python project example (e.g., logger configuration, custom config parsing, potential race conditions). It’s a fair point, especially given I’m not a Python expert. For this particular green-field project, my primary goal was rapid prototyping and achieving a working solution in an unfamiliar stack, prioritizing the functional outcome over idiomatic code perfection or optimizing for long-term maintainability in this specific instance. It served as an experiment to see how far AI could bridge a knowledge gap. In brown-field projects within my areas of expertise, or projects demanding higher long-term maintainability, the human review, refinement, and testing process (using the guardrails discussed later) is necessarily much more rigorous. The critiques highlight the crucial role of experienced oversight in evaluating and refining AI-generated code to meet specific quality standards. We all know how big companies handle software, if it works ship it. Basically once this shit starts becoming very mainstream companies will want to shift into their 5x modes (for their oh so holy investors that need to see stock go up, obviously.) So once this sloppy prototype is seen as working they will just ship the shit sandwhich prototype. And the developers won’t know what the hell it means so when something breaks in the future, and that is when not if. They will need AI to fix it for them, cause once again they do not understand what is going on. What I’m seeing here is you proposing replacing one of your legs with AI and letting it do all the heavy lifting, just so you can lift heavier things for the moment. Once this bubble crumbles the technical debt will be big enough to sink companies, I won’t feel sorry for any of the AI boosties but do for their families that will go into poverty
  • namaria 2y ago
    Yup this is full on addiction mechanics. You use these generative tools, it feels great, the team and the organization feel great. But it's not warranted, the underlying thing is inherently flawed. When the good feeling fades and you need to up the dosage, you will find that your ability to function is declining and your dependency on the generative tools is increasing. Besides no one is thinking about the end game. If (and its a big if) this goes to plan and these generative tools can do everything. Well at that point the only software needed is the generative tool itself isn't it? There would be no need for anything else so anyone building stuff on top of it, or using it to build stuff, would be SOL. So best case scenario we all get addicted to fundamentally flawed technology because our ability to function independently has eroded too far, worst case there will be only foundational model companies operating in software.
• hansmayer 2y ago
  Skimming through the article, it lacks clear structure and I am not sure what is the author attempting to show? Some new skills he had to use? Formulating requirements? That he can write extremely long prompts? The Conclusion section looks just like something a GenAI tool would produce. Or a first-year student in an essay.
  • ManuelKiessling 2y ago
    I've taken this feedback to heart and tried to improve the structure a bit. The main message I want to bring across is two-fold: 1. Senior developers are in a great position to make productive use of AI coding tools 2. I have (so far) identified three measures that make AI coding sessions much more successful I hope the reworked version makes these more central and clear. I'm not a native English speaker, thus it's probably not possible for me to end up with an optimal version. Still, I hope the new approach works a bit better for you — would love to receive another round of feedback.
    • hansmayer 2y ago
      Hey, thanks for not being offended about an honest comment, not a lot folks could take it as maturely, as you did :) May I suggest to add a short summary, half page max, of the important results that you consider to have achieved at the beginning of the article? Kind of like how scientific articles prepend the content with an abstract. I think it would help a lot in building the expectations for reading the rest of it.
      • ManuelKiessling 2y ago
        I've doubled down and completely rewrote the whole thing today :-) https://news.ycombinator.com/item?id=43573755 https://news.ycombinator.com/item?id=43573755
• bsdimp 2y ago
  I yesterday set chatgpt to a coding task. It utterly failed. Its error handling was extensive, but wrong. It didn't know file formats. It couldn't write the code when i told it the format. The structure of the code sucked. The style was worse. I've never had to work so hard for such garbage. I could have knocked it out from scratch faster with higher quality.
• vessenes 2y ago
  This post is pretty much my exact experience with the coding tools. Basically the state of the art right now can turn me into an an architect/CTO that spends a lot of time complaining about poor architectural choices. Crucially Claude does not quite understand how to greenfield implement good architectures. 3.7 is also JUST . SO. CHATTY. It’s better than 3.5, but more annoying. Gemini 2.5 needs one more round of coding tuning; it’s excellent, has longer context and is much better at arch, but still occasionally misformats or forgets things. Upshot — my hobby coding can now be ‘hobby startup making’ if I’m willing to complain a lot, or write out the scaffolding and requirements docs. It provides nearly no serotonin boost from getting into flow and delivering something awesome, but it does let me watch YouTube on the side while it codes. Decisions..
• g8oz 2y ago
  The bit about being able to get something workable going in an unfamiliar tech stack hits home. In a similar vein I was able to configure a VyOS router, a nushell based api client and some MSOffice automation in Powershell with AI assistance. Not a big deal in and of itself but still very useful.
• JohnMakin 2y ago
  I'm not quite 40 but starting to feel the effects of age, AI has been a great tool if not for the fact it saves my hands. I don't have it write the logic for me, mostly just stuff like smart autocomplete etc. I battle really severe tendonitis, I've noticed a definite improvement since I started using code complete. As far as knowledge/experience, I worry about a day where "vibe coding" takes over the world and it's only the greybeards that have any clue WTF is going on. Probably profitable, but also sounds like a hellscape to me. I would hate to be a junior right now.
  • spoonfeeder006 2y ago
    Well, whats the difference between Vibe Coding in 5 - 10 years vs coding in C 5 - 10 years after compilers came out?
    • alternatex 2y ago
      Compilers produce verifiable results. Are we seriously comparing compilers to LLMs? It's like comparing math to sociology.
      • spoonfeeder006 2y ago
        Well, arguably so do LLMs. You put in the same input prompt, out comes the same code. But yeah, it is kinda different, but I'm just saying that as LLMs become better at understanding how to solve sub-problems, they may become reliable enough that coding via LLMs becomes the new norm, and learning how to effectively prompt will become a new skill for coders
  • curiousllama 2y ago
    I would love to be a junior right now. I would just hate becoming a senior, after having been a junior right now.
    • JohnMakin 2y ago
      well said
• amflare 2y ago
  > The very experience and accumulated know-how in software engineering and project management — which might seem obsolete in the age of AI — are precisely what enable the most effective use of these tools. I agree with the author here, but my worry is that by leaning on the LLMs, the very experience that allows me to uniquely leverage the LLMs now will start to atrophy and in a few years time I'll be relying on them just to keep up.
• scelerat 2y ago
  I find myself spending so much time correcting bad -- or perhaps, more appropriately, misguided -- code that I constantly wonder if I'm saving time. I think I am, but a much higher percentage of my time is doing hard work of evaluating and thinking about things rather than mentally easy things the AI is good at, but what used to give me a little bit of a break. Sometimes I liken the promise of AI to my experience with stereoscopic images (I have never been able to perceive them) -- I know there's something there but I frequently don't get it.
• hinkley 2y ago
  The biggest thing I worry about with AI is that its current incarnation is anathema to the directions I think software needs to go next, and I’m at a loss to see what the judo-throw will look like that achieves that. Rob Pike has the right idea but the wrong execution. As the amount of second and third party code we use increases, the search time goes up, and we need better facilities to reduce the amount of time you need to spend looking at the internals of one package because you need that time to look at three others. So clarity and discoverability both need to matter, and AI has no answers here, only more problems. IMO, a lot of the success of Java comes from having provided 80% of the source code with the JDK. You could spend so much time single stepping into code that was not yours to figure out why your inputs didn’t cause the outputs you expected. But those are table stakes now.
• lowsong 2y ago
  > … I believe our community should embrace it sooner rather than later — but like all tools and practices, with the right perspective and a measured approach. There is no such thing as a measured approach. You can either use LLM agents to abdicate your intellectual honesty and produce slop, or you can refuse their use.