Has the cost of building software dropped 90%?

Good write-up. I don't disagree with any of his points, but does anybody here have practical suggestions on how to move forward and think about one's career? I've been a frontend (with a little full stack) for a few years now, and much of the modern landscape concerns me, specifically with how I should be positioning myself.

I hear vague suggestions like "get better at the business domain" and other things like that. I'm not discounting any of that, but what does this actually mean or look like in your day-to-day life? I'm working at a mid-sized company right now. I use Cursor and some other tools, but I can't help but wonder if I'm still falling behind or doing something wrong.

Does anybody have any thoughts or suggestions on this? The landscape and horizon just seems so foggy to me right now.

Sheep farming sounds nice. Or making wooden furniture. Something physical.

Author here, thanks for your kind words!

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.

Nobody knows the answer.

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.

Don't chase specific technologies, especially not ones driven by for-profit companies. Chase ideas, become great in one slice of the industry, and the very least you can always fall back on that. Once established within a domain, you can always try to branch out, and feel a lot more comfortable doing so.

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.

Blind leading the blind, but my thinking is this:

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.

I think you're right about trying to stay one step ahead of product requirements. Maybe my issue here is that I'm looking for another "path" where one might not exist, at least not a concretely defined one. From childhood to now, things were set in front of me and I just sort of did them, but now it feels like we're entering a real fog of war.

It would be helpful, as you suggest, to start shifting away from "I code based on concrete specs" to "I discover solutions for the business."

Thanks for the reply (and for the original essay). It has given me a lot to chew on.

Thanks for the response. When you say "one slice of the industry", is the suggestion to understand the core business of whatever I'm building instead of being the "specs to code" person? I guess this is where the advice starts to become fuzzy and vague for me.

My suggestion would be to move to a higher level of abstraction, change the way which you view the system.

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.

Its always been foggy. Even without AI, you were always at risk of having your field disrupted by some tech you didn't see coming.

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.

Great question, hard to quickly answer.

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.

Realistically, someone else + LLM at -10% compensation will be employed

Also blind leading the blind here but I see two paths.

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.

Then why wasn't someone else employed at -10% compensation instead of you before LLMs?

Let's say LLMs add 50 "skill points" to your output. Developer A is at 60 skill points in terms of coding ability, developer B is at 40. The differential between them looks large. Now add LLMs. Developer A is at 110 skill points, developer B is at 90. Same difference, but now it doesn't look as large.

The (perceived, alleged) augmentation by LLMs makes individual differences in developer skill seem less important. From the business's perspective, you are not getting much less by hiring a less skilled developer vs. hiring a more skilled one, even if both of them would be using LLMs on the job.

Obviously, real life is more complicated than this, but that's a rough idea of what the CEO and the shareholders are grappling with from a talent acquisition standpoint.

ARE you the author? Or did you prompt AI to get this?

> but wonder if I'm still falling behind or doing something wrong.

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.

Use the best tools, the lowest tier of Claude Code is perfect for the stuff you do at home in the evenings and weekends. It's also by far the best at being a "pair coder" as it's chatty and tells you what it's doing and doesn't get confused if you hit ESC and tell it to do something else.

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

Another thing I'd suggest: look into and use non-coding AI tools that improve productivity. For example:

Zoom meeting transcriptions and summaries or Granola. A lot of context is lost when you take manual notes in meetings. If you use a tool that turns a meeting into notes automatically, you can use those notes to bootstrap a prompt/plan for agents.

We use "Notion AI" to transcribe meetings and it's actually pretty good, we just had a team meeting where we talked shit about stuff going on in the company along with actual tasks.

It picked just the tasks and actual points from the transcript and skipped all of the jokes and us bitching about processes =)

I would say that could be domain knowledge in your business, but as you said you do frontend it could be mobile, UI/UX, security, ...