The premise might possibly be true, but as an actually seasoned Python developer, I've taken a look at one file: <a href="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...</a><p>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...<p>In a nutshell, if the rest of it is like this, it simply sucks.
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.<p>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?
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.
That prompt looks horrifying.<p>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.<p>I'd rather do it myself to have a piece of mind.
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.<p>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.<p>I would hate to be a junior right now.
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.<p>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.<p><a href="https://royalicing.com/2025/infinite-bicycles-for-the-mind" rel="nofollow">https://royalicing.com/2025/infinite-bicycles-for-the-mind</a><p>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.<p><a href="https://royalicing.com/2025/test-driven-vibes" rel="nofollow">https://royalicing.com/2025/test-driven-vibes</a>
Aah.. I have been repeating this to my team for several days now. Thanks for putting this together.<p>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.<p>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.
> 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.<p>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.
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.<p>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.<p>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.
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.<p>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.
I'm skeptical that<p>1. Clearly define requirements<p>2. Clearly sketch architecture<p>3. Setup code tool suite<p>4. Let AI agent write the remaining code<p>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.<p>The agent will definitely(?) write the code faster, but quality and understanding (tech debt) can suffer.<p>IOW the real takeaway is that knowing the requirements, architecture, and tooling is where the value is. LLM Agent value is dubious.
I’ve been pretty moderate on AI but I’ve been using Claude cli lately and it’s been pretty great.<p>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.
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.<p>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.
The main questions I have with using LLMs for this purpose in a business setting are:<p>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.<p>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?
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.
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.<p>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.<p>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.<p>I'd have expected better documentation/in-line comments. Is that something that you did/didn't specify?
I completely agree, as a fellow senior coder. It allows me to move significantly faster through my tasks and makes me much more productive.<p>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.
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:<p>“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.”<p>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.<p>This costs speed yes, but I have more control and gain knowledge about the language I chose.
When working with AI for software engineering assistance, I use it mainly to do three things -<p>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)<p>2. Pasting in gigantic error messages or log files to help diagnose what's going wrong. (HIGHLY recommend.)<p>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.)<p>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.<p>I love it.
This post is pretty much my exact experience with the coding tools.<p>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.<p>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.<p>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.<p>Decisions..
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.<p>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.
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.<p>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.
As much as I am still sceptical about AI tools, the past month has been a revolution as a senior dev myself.<p>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.<p>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<p>As a generalist, I feel less overwhelmed<p>It's probably been the most enjoyable month at this job.
This is excellent, and matches my experience.<p>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.
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.<p>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.<p>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.
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.
> Once again, the AI agent implemented this entire feature without requiring me to write any code manually.<p>> For controllers, I might include a small amount of essential details like the route name: [code]<p>Commit history: <a href="https://github.com/dx-tooling/platform-problem-monitoring-core/commits/main/">https://github.com/dx-tooling/platform-problem-monitoring-co...</a><p>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?<p>What’s wrong with the fact you <i>did</i> write some code as part of it? You clearly did.<p>So weird.
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.<p>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.
> 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.<p>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.)<p>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.<p>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.<p>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
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.
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.
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.<p>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.<p>Even with maintenance, we plan ahead for this with an LLM and make changes accordingly.<p>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".
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?<p>No, the article was just something about enjoying AI. This is hardly anything related to <i>senior</i> software developer skills.
> … 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.<p>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.
The gap between Sr and Jr skills with close as AI gets better. AI is coming for the SR developer, be assured.<p>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.
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.
This maps pretty well to my experience.<p>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"<p>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.