I think it's about looking at what you're building and proactively suggesting/prototyping what else could be useful for the business. This does get tricky in large corps where things are often quite siloed, but can you think "one step ahead" of the product requirements and build that as well?

I think regardless if you build it, it's a good exercise to run on any project - what would you think to build next, and what does the business actually want. If you are getting closer on those requests in your head then I think it's a positive sign you are understanding the domain.

1. Use the tools to their fullest extend, push boundaries and figure out what works and what doesn't

2. Be more than your tools

As long as you + LLM is significantly more valuable than just an LLM, you'll be employed. I don't know how "practical" this advice is, because it's basically what you're already doing, but it's how I'm thinking about it.

Ultimately, software is for doing something, and that something can be a whole range of things. If you become really good at just a slice of that, things get a lot easier regardless of the general state of the industry.

1) Specialize in product engineering, which means taking on more business responsibility. Maybe it means building your own products, or maybe it means trying to get yourself in a more customer-facing or managerial role? Im not very sure. Probably do this if you think AI will be replacing most programmers.

2) Specialize in hard programming problems that AI can't do. Frontend is probably most at risk, low level systems programming least at risk. Learn Rust or C/C++, or maybe backend (C#\Java\Go) if you don't want to transition all the way to low level systems stuff.

That being said I don't think AI is really going to replace us anytime soon.

This is normal with all that is going on in the industry and the AI/ML hype. But, one should not allow that to lead to "analysis paralysis".

> specifically with how I should be positioning myself. ... Does anybody have any thoughts or suggestions on this?

You have a stable job; hence your entire focus (for now) should be to "grow" in your job/organization. This means taking more responsibilities both technical/non-technical and demonstrating your long-term commitment to management. On the technical side, start with "full stack development" both frontend and backend so you can contribute end-to-end to the entire product line. Learn/Use all available tools (AI and otherwise) to demonstrate independent initiative. Step up for any tasks which might not have a owner (eg. CI/CD etc.). Keep your boss/higher-ups informed so as to maintain visibility throughout the organization. Learn more about the problem domain, interact more with Marketing/Sales so as to become the liaison between Engineering and rest of the organization/clients.

Generally, all higher management look for initiative and independent drive so that they can delegate work with the assurance that it will be taken care of and that is what you need to provide.

AI will probably replace the bottom ~30-70%(depends who you ask) of dev jobs. Dont get caught in the dead zone when the bottom falls out.

Exactly how we'll train good devs in the future, if we don't give them a financially stable environment environment to learn in while they're bad, is an open question.

Maybe becoming full stack? Maybe understanding the industry a little deeper? Maybe analyzing your company's competitors better? That would increase your value for the business (a bit of overlap with product management though). Assuming you can now deliver the expected tech part more easily, that's what I'd do.

As for me, I've moved to a permanent product management position.

Build your own tools, need a small utility? Use an LLM to create it with you.

Create LLM-focused tools and adjust your workflows to be LLM-friendly.

I personally have a Taskfile setup that follows the same formula regardless of language. "task build" runs lint+test+build. Test and lint are kinda self-evident. All output is set to minimum, only errors are verbose (don't waste context on fancy output).

I also have tools for LLMs to use to find large code files, large and overly complex functions etc.

All project documentation lives in docs/ as markdown files with Mermaid charts.

This way I can just have the general "how to use a taskfile" instructions in my global WHATEVER.md and it'll work in every project.

Learn project management. Working with LLMs is exactly like project managing a bunch of smart and over eager junior coders who want to use every trick and pattern they learned at school for every tiny shell script.

Do a few test projects where you just pretend you're a non-techinical project lead and know WHAT you want but not HOW you want it done. Plan the project, split it into tasks (github tasks or beads[0] both work pretty well). Then have the LLM(s) tackle the tasks one by one and test the end result like a non-techical PM would do in a demo. Comment, critique and ask them to change stuff that doesn't work.

If you can afford it, bring in an outside consultant (Codex or Gemini), both of which are _really_ good at evaluating large codebases for duplication, test coverage, repetition, bad patterns etc. Give their responses verbatim to Claude and ask what it thinks about them.

Working with LLMs is a skill you just need to use to get a feel for it, it's not a science and more like an art. For example I can "feel" when Claude is doing its thing and being either overeager or trying to complete a task while ignoring the burning pile of unit tests it leaves behind and interrupt. it before it gets too far.

[0] https://github.com/steveyegge/beads

Answers I see are typically "be a product manager" or "start your own business" which obviously 95% of developers can't/don't want to do.

My .02$. Show you can tackle harder problems. That includes knowing which problems matter. That happens with learning a "domain", versus just learning a tool (e.g. web development) in a domain.

Change is scary, but thats because most aren't willing to change. Part of the "scare" is the fear of lost investment (e.g. pick wrong major or career). I can appreciate that, but with a little flexibility, that investment can be repurposed quicker today that in pre-2022 thanks to AI.

AI is just another tool, treat it like a partner not a replacement. That can also include learning a domain. Ask AI how a given process works, its history, regulations, etc. Go confirm what it says. Have it break it down. We now can learn faster than ever before. Trust but verify.

You are using Cursor, that shows a willingness to try new things. Now try to move faster than before, go deeper into the challenges. That is always going to be valued.