AI and the Future of the Engineering Profession
The question isn't whether AI replaces developers. It's which part of today's work is getting cheaper, and which isn't. Here's what's actually changing in hiring, in the junior role, in the economics of solo development, and in accountability for code a human didn't write, with no hype in either direction.
The wrong question and the right one
"Will AI replace developers" is an imprecisely framed question, and that imprecision is exactly what fuels most of the panic and most of the unfounded calm around this topic at the same time. The right question is different: which part of today's developer work is getting cheap enough to become a routine, interchangeable service available to anyone who can frame a task clearly, and which part keeps requiring a rare, expensive skill that doesn't automate the same way.
This question doesn't just concern people already working in the industry. It concerns people still deciding whether to enter it at all. A prospective student choosing a major, or a junior looking for a first job, reads headlines about "AI writing all the code" and concludes that entering the profession no longer makes sense. That's exactly the hasty conclusion the imprecise framing of the original question produces, and one reason for writing this piece is to offer a more precise frame for people making decisions like that right now, not just for people already deep in the profession riding out a change in the rules mid-career.
In the piece on AI for developers, I already stated this thesis briefly: writing code as such is getting cheaper, and will keep getting cheaper. The ability to understand what actually needs to be built, how it should behave in the context of a real system, and how to verify the result is genuinely correct isn't getting cheaper, because that's exactly what remains the bottleneck even with perfectly capable AI tools. Here I'm unpacking that thesis across the whole arc of the profession: hiring, the junior role, the economics of solo development, accountability for code a human didn't write themselves, and an honest forecast a few years out.
I'm writing this not as a futurist with a confident stare into a crystal ball, but as an engineer living through these changes daily in practice, including the fact that this exact piece was written alongside Claude Code. Wherever I'm not sure, I'll say so directly, rather than presenting a personal opinion as an irrefutable fact.
Worth stating upfront what this piece won't do. It won't offer a cheerful "AI will never replace a real engineer," or a panicked "in three years there won't be any programmers left." Both extremes are equally convenient because they remove the need to think through the details: the first reassures with no analysis, the second scares with no analysis. The real picture is more complicated and less convenient for a short slogan, and that's exactly why it's worth working through in detail instead of settling for one of the two ready-made positions.
Will AI replace developers: a breakdown with no hype
The most honest answer: it depends what you mean by "developer." If that's someone whose only value is turning an already fully specified task into syntactically correct code in a specific language, that role really is shrinking fast, because that's exactly what AI agents keep getting better and cheaper at doing every year. If that's someone whose value lies in making sense of a murky, poorly specified problem, designing a solution that accounts for constraints nobody explicitly stated, and being accountable for that solution actually working in production, that role isn't just surviving, it's getting more concentrated and better paid, because the supply of people like that grows more slowly than the demand for their work.
It helps to break a developer's job down into its component parts and evaluate each one's trajectory separately, rather than talking about the profession as one indivisible activity, because it's exactly this blending of fundamentally different tasks into the single concept of "programmer work" that produces most of the confusion in debates about the profession's future. Writing syntactically correct code from a finished spec. Designing architecture against constraints that often go unstated. Debugging a system where the cause of a failure is hidden behind several layers of abstraction. Communicating with the people setting the task, on whom budget and timelines depend. Being accountable for a result that's actually correct, not just one that looks correct. The first piece automates fastest. The other four either automate much more slowly, or don't automate on any foreseeable horizon at all, because they run into the nature of the task itself, understanding implicit context, trust between people, accountability for consequences, rather than technical difficulty.
A useful historical parallel, one I also covered in the piece on AI for developers: the profession has already gone through similar transitions more than once, just at different levels of abstraction. The move from assembly to high-level languages didn't eliminate the programming profession, it eliminated the need to keep processor registers in your head. The move from writing your own data structures to using standard libraries didn't eliminate the profession, it shifted the value from being able to write a good search tree to being able to correctly pick an existing structure for the job. None of these transitions reduced the number of developers, they changed what counts as a developer's job.
The difference with the current transition isn't in direction, it's in speed. The move to high-level languages took years for the whole industry to adapt to. The move to agentic development is happening over the course of one or two years, and it's exactly that compressed speed that creates a sense of anxiety earlier, slower transitions didn't produce, even though what's happening structurally resembles stages the industry has already been through.
The compressed speed of this transition also means the industry has physically less time to work out new norms and practices than it had during previous transitions. Agreements about how to properly review agentic code, how to distribute accountability within a team, how to train junior engineers under the new conditions, usually form over years of collective trial-and-error practice. When the transition itself takes a year or two, those norms get worked out on the fly, in parallel with the technology's rollout rather than after it, and part of today's uncertainty in the industry comes down to exactly this lag between practices and norms and the speed at which the tool itself is changing.
How hiring will change in the coming years
Developer hiring is already changing, and it's happening not through positions disappearing entirely, but through a shift in selection criteria. The ability to quickly write a working algorithm in an interview, which was the standard hiring filter for decades, is losing its diagnostic value, because the same result today comes in seconds through an AI assistant, and an interview built around that skill increasingly fails to tell a strong candidate apart from someone who just knows how to use the tool.
Interviews are gradually shifting toward tasks that are harder to fully delegate to a model: working through an existing, poorly documented codebase, tracking down a non-obvious bug in a system with many interacting parts, defending an architectural decision under pointed follow-up questions. That doesn't mean technical interviews will disappear, it means their content will keep shifting from "write the code" to "make sense of the system and explain the decision."
Companies that keep hiring by the old criteria simply because those criteria are familiar and comfortable for whoever's running the interview risk selecting candidates for a skill that isn't actually the one the job requires. A candidate who nails classic algorithm problems in an interview but can't effectively delegate routine work to an AI agent and check the result will, in practice, turn out slower than a colleague with more modest algorithmic skills but a well-tuned agentic process. The gap between what an interview tests and what the job actually needs will keep growing until hiring processes catch up with how the work itself has changed.
A second notable shift: candidates who already know how to work effectively with AI agents as part of the workflow, rather than treating them as an optional toy, are getting more valuable. Companies that have restructured their processes around agentic development increasingly look for people who can plug into that process right away, rather than spending months adapting to the basic idea of delegating code to an agent.
A third shift concerns portfolios and resumes. A link to a personal project written entirely by the candidate from start to finish with zero AI tools is gradually losing the demonstrative value it used to have, simply because it's becoming unclear whether it shows a real skill or just a lack of access to current tools. A more informative signal becomes how a candidate explains the decisions inside a project, not the mere fact of its existence: why this specific architecture was chosen, what alternatives were considered and rejected, what went wrong along the way and how it got fixed.
Which engineering skills stay valuable
The list of skills that don't get cheaper along with writing code is fairly stable, and it's worth stating explicitly rather than leaving it as an abstract idea. First: the ability to state requirements precisely enough for a task to be solvable, but broadly enough not to miss the real problem behind a narrow technical spec. Second: systems thinking, the ability to hold in mind how a change in one part of a system will ripple into another, not always obvious, part. Third: the ability to judge whether a proposed solution, from a human or an agent, actually works correctly rather than just looking plausible.
A fourth skill, underrated more often than the rest: communicating with people, not with models. Convincing a team an architectural decision is right, negotiating realistic timelines with a product manager, explaining to non-technical leadership why technical debt is more expensive right now than it looks, none of these skills automate the way writing code does, because they run on human trust and human relationships, not on the technical correctness of a result.
Tellingly, this skill isn't new and isn't specific to the AI era, it mattered before too, it just stayed in the shadow of the more visible, easily measured skill of writing code. Companies spent years hiring and promoting primarily on visible technical output rather than communication quality, precisely because technical output is easier to measure objectively, while communication quality is hard to assess without prolonged observation. Now that writing code is disappearing as the bottleneck, the communication and organizational side of the job becomes more visible simply because there's no longer an equally weighty typing task standing next to it pulling attention away.
A fifth skill, specific to the age of AI agents: the ability to effectively frame a task for an agent and evaluate the result. This isn't the same skill as programming in the traditional sense, but it's not a trivial skill that comes naturally with no practice either. I covered it in detail in the piece on AI coding assistants in practice: setup, task framing, reviewing agent-written code, all of it is a distinct, growing-in-importance competency.
A sixth skill, less obvious but increasingly significant: knowing how to design a project's structure and documentation so it's easy to work with not just for a human, but for an agent too. I covered this in detail in the piece on architecture for AI-driven development: explicit naming conventions, a single entry point for agent instructions, modularity instead of convenient but tangled shortcuts. A developer who knows how to build architecture like that gets a compounding payoff from every agent working in their codebase, while a developer who ignores this side of the job pays a growing price for poor architecture with every new agentic session.
From developer to AI agent orchestrator
The role taking shape looks closer to an orchestra conductor than a musician playing a single part. A conductor doesn't need to play every instrument more virtuosically than the musicians themselves, but they do need to understand how each instrument's part should sound, where the parts need to come together, and what to do if one of the musicians is off-key. A developer working with several parallel AI agents on different parts of a system is doing a structurally similar job: not writing every line themselves, but accountable for making sure the combined output of every agent adds up to a coherent, correct system.
The conductor metaphor is useful in another sense too: a conductor who can't play a single instrument at all is physically incapable of telling whether a specific musician is off-key, and the same logic applies to orchestrating AI agents. Being able to effectively direct several agents in parallel requires enough of your own technical depth to notice when an agent's output is wrong, even if you personally haven't written the code behind that output by hand in a long time. Orchestration with no underlying technical understanding turns into blind trust in the output, which sooner or later leads to a serious mistake missed simply because there was no one there to notice it.
This role demands a different distribution of attention through the day than classic programming does. Less time goes into typing code, more into framing tasks, reviewing output, and resolving conflicts between parts of a system built by different agents or different people. This isn't lighter work in the sense of less load, it's a change in the nature of the load: it shifts from the motor skill of writing code to the cognitive load of continuous quality and consistency control.
Many developers used to the old distribution of attention experience this shift, at first, as a loss rather than a change in the nature of the work. Writing code gives an immediate, tangible sense of progress: lines appear on screen, a function starts working. Reviewing someone else's code, even an agent's, doesn't give that same immediate feeling, and for a while the new role can subjectively feel less satisfying, even if the person is objectively closing a larger volume of real work in the same time. That's a purely psychological adjustment, not a sign something's wrong, and it fades as practice in the new role accumulates.
The economics of solo development in the AI era
One engineer with a well-built agentic process today covers a volume of work that, a few years ago, would've needed a small team. That's not an exaggeration for a good line, it's a direct consequence of the fact that the routine part of implementation, which used to need several pairs of hands just to physically keep up with typing all the necessary code, now gets delegated to agents, leaving the human with architecture, review, and decisions.
I cover how this actually works in practice, including my own failures and working solutions, in detail in the piece on how I build AI products solo, including the specific trade-offs between the speed of solo decisions and the missing second opinion a team provides. Here it's worth locking in the general thesis: the economics of building a product are changing not just for large companies hiring fewer junior engineers, but for an individual person, who now has a realistic shot at building a product alone in cases that used to require a team or significant hiring capital.
This economics also changes which products are even worth starting to build. An idea that used to get screened out at the outset simply because it needed a team of three or four people for six months to test the hypothesis, resources one person rarely has without outside funding, can now get tested by one person in a noticeably shorter window. That doesn't mean the quality or complexity of a product one person can build has caught up to what a full team can build, but the barrier to even attempting it has dropped noticeably, and that changes the pool of people who decide to try at all.
A side effect of this shift worth stating directly: competition in low-barrier-to-entry niches is also growing, because more people are physically capable of trying a similar idea at the same time. That's not an argument against solo development as a strategy, it's an honest caveat to the optimistic picture: a lower barrier to entry lowers it for everyone at once, not just for the specific person reading this piece, and competitive advantage now more often comes down not to the mere fact of using AI tools, but to how well a specific person applies them and how deeply they understand the niche they're building in.
Junior developers in the AI era
Of every section in this piece, this one is probably the most sensitive, because it touches specific people at the earliest and most vulnerable stage of a career, not an abstract industry as a whole. Honesty matters more than optimism here. The classic path for a junior developer's growth was long built around doing routine, well-specified work under a senior's supervision, gradually gaining experience and moving to more complex tasks. AI agents are taking over exactly that routine work, and that genuinely narrows the classic path into the profession through simple, supervised tickets.
This creates a real organizational problem, significant for the entire industry over a horizon of several years, not just an individual problem for a specific junior looking for their first job right now. If the routine tasks that used to go to junior developers now go directly to an agent under a senior engineer's direction, where does the next generation of senior engineers come from ten years from now, if they never had the experience-accumulation stage through routine work that professional maturation used to rest on. That's a question the industry doesn't yet have a practice-tested answer to, and companies genuinely thinking about developing talent over a horizon of several years should be deliberately designing new paths for accumulating experience, rather than assuming the old mentorship model keeps working unchanged under the new conditions.
That doesn't mean the road is closed for new developers, it means it's changing shape. Value for a junior shifts from "I can quickly write code from a finished spec" to "I can quickly make sense of someone else's code, ask an agent the right question, and notice when the agent's output is wrong." That's a more demanding set of skills at the start of a career than before, and there's a real risk here: without deliberate practice at deep understanding, rather than just using finished answers from a model, a junior risks staying at the level of someone who knows how to run other people's solutions without understanding why they work.
Practical advice for anyone entering the profession right now: deliberately spend part of your time understanding the code an agent wrote, not just checking that it runs. The difference between using AI as a crutch that lets you skip understanding, and using AI as an accelerator that frees up time for deeper understanding of the same task, determines whether a junior grows into someone who genuinely knows their craft, or someone dependent on a tool with no grasp of what's happening underneath.
A specific practice that helps hold this balance, worth turning into a habit from the very first weeks on the job: after an agent solves a task, spend a few minutes explaining the solution to yourself or a colleague in your own words, with no peeking at the code. If the explanation doesn't come, that's a signal the task got solved but not understood, and it's worth going back and working through it before moving on to the next one. This takes discipline, because the speed at which an agent hands over a working result creates a temptation to just keep moving, without pausing on something that feels like a closed question already.
Responsibility for this adjustment doesn't rest solely on the junior themselves, who's often not experienced enough yet to independently notice the difference between a solved task and an understood one, it also rests on the companies and mentors who hire and train them. An organization that keeps measuring a junior's progress by the number of closed tickets, with no regard for whether they actually understand the code they wrote, risks growing a specialist so dependent on the tool that they'd be helpless without it on a task they would've solved on their own a year earlier.
AI and open source: how the ecosystem is changing
Open source has traditionally run on the volunteer labor of people solving their own problem and sharing the solution with everyone else. AI agents are changing the economics of that labor from both sides: on one hand, they lower the barrier to contributing, because a person doesn't need to hold the entire context of a large project in their head to propose a meaningful patch, an agent can help make sense of an unfamiliar codebase faster. On the other hand, they create a new load on maintainers: a growing number of automatically generated, not always high-quality pull requests that need filtering out noticeably increases the review burden on whoever maintains the project.
A specific symptom of this shift is already visible: maintainers of large projects regularly complain about pull requests that look technically competent, pass automated checks, but don't actually solve the stated problem, or solve it superficially, with no understanding of the project's broader context. Contributions like that eat up a reviewer's time roughly the same way a good patch does, because telling them apart at a glance, without digging into the details, is often impossible, and that's an asymmetry that doesn't favor the maintainer: it's become noticeably cheaper for a patch's author to produce a plausible-looking but shallow contribution than it is for a reviewer to carefully check it.
The long-term effect is still unclear, and honestly, I'm not ready to make a confident forecast here. One possible scenario: a widening of the already-existing gap between a small number of large, well-funded open source projects that can afford strict contribution moderation processes, and the many small projects maintained by one person, for whom a flood of low-quality AI-generated proposals could become an unmanageable load with no additional filtering tools.
There's also an opposite, more optimistic scenario worth keeping in mind: the same AI tools driving up the flow of proposals on the input side are also capable of helping on the review side, automatically filtering out obviously low-quality or incomplete patches before they reach a live maintainer's attention. Which of these two effects wins out, the growth rate of the load or the growth rate of tools filtering that load, will determine whether this era turns into a period of abundant contribution for open source or a period of maintainer burnout, and I don't have a confident answer yet for which scenario plays out in practice.
What research says about AI's effect on productivity
Honesty requires admitting here: there's no single, settled picture yet. Some research shows a substantial speedup in task completion when using AI assistants, especially on routine, well-specified tasks. Other, more narrowly focused work shows a mixed or even negative picture under specific conditions: for example, where an experienced developer already knows a specific large codebase extremely well, and the time spent framing a task for an agent and checking its output outweighs the gain from not typing the code by hand.
The difference in results across studies is explained mostly by differences in tasks and participant experience, not by an actual contradiction. The productivity boost from AI assistants is higher on new, unfamiliar codebases and on routine tasks, and lower or even negative on tasks in a deeply familiar system, where an experienced developer's intuition already works faster than the cycle of framing a request and checking the answer. A sensible conclusion from this unevenness: don't rely on the general belief that "AI definitely speeds up work" as a universal truth, and instead soberly assess for which specific type of task, in your own practice, that claim is actually true.
Worth adding a practical caveat for a reader who wants to lean on specific productivity-boost numbers from research like this: before trusting any specific figure, check what sample of developers and what type of task it was measured on, because those details usually determine far more about whether the result applies to your own situation than the headline percentage in a study's title or a news write-up about it.
There's also a methodological difficulty that explains part of the spread in results on its own: the subjective feeling of being faster and the objectively measured time to complete a task don't always match. A developer can feel faster with an AI assistant simply because someone else, the model, is now doing part of the routine, tedious work, even though the objective time to a finished result stayed about the same or even grew because of time spent framing requests and checking answers. The subjective feeling is easier to measure with a survey, the objective completion time requires more labor-intensive observation, and part of the hype around impressive productivity numbers probably reflects exactly this gap between feeling and objective measurement, rather than fabrication or error in any specific study.
Who's accountable when an AI agent breaks production
The accountability question isn't abstract: it comes up the very first time code an agent generated passes review, gets merged, and breaks something in production. The legal and organizational answer here is simple and, in my view, the only reasonable one: accountability rests with the person who approved the change and shipped it to production, not the tool they used. An agent isn't accountable in the sense a person is, it has no career, no reputation, and no employment contract that a mistake can damage.
The temptation to shift part of the blame onto the tool is psychologically understandable, especially right after an incident, when it's natural to look for an explanation that removes some personal fault. "The agent wrote bad code" sounds like an explanation, but it isn't an excuse, the same way "the compiler compiled a bug" was never considered an acceptable explanation from a programmer who made a logic error. The tool does exactly what it was asked to do, and accountability for whether the request was framed precisely enough, and the result checked thoroughly enough, stays with the person, regardless of how autonomous the tool feels in the moment of use.
This isn't an abstract argument. While working on this exact site, a real bug came up: the CMS crashed on re-saving a post because of a boolean field type mismatch between the backend and frontend. The code where that mismatch snuck in was written alongside Claude Code, but the accountability for the bug reaching production is mine, because I merged it without a test covering exactly that scenario. A tool doesn't check itself beyond what it was explicitly asked to check, and delegating the writing of code to an agent doesn't mean delegating accountability for the quality of the result.
A similar thing happened with the Cyrillic-transliteration bug in a post's slug, where two letters, the "hard sign" and "soft sign," letters that modify pronunciation and have no Latin equivalent, weren't disappearing from the generated URL the way they were supposed to. Both cases share the same underlying error structure: the code formally worked in the obvious scenarios and broke on a non-obvious edge case that neither I nor the agent thought of at the time of writing. In neither case did it make sense to blame the tool for failing to anticipate a scenario I hadn't explicitly stated myself, any more than it would make sense to blame a junior for a bug in a task that was poorly specified to begin with.
The practical consequence for teams adopting agentic development: the review and testing process needs to stay just as strict, sometimes stricter, for AI-written code as for human-written code, not get relaxed on the assumption that code written by AI is somehow automatically more reliable or needs less scrutiny.
There's a separate organizational question companies still have to work out for themselves, and I don't see the industry having a settled practice here yet: how accountability gets distributed if one person approved the code but an agent, configured and run by someone else, wrote it. In the classic code-review model, whoever left the approval is accountable for what they approved, regardless of who physically wrote the code. Agentic development doesn't change this principle in substance, but it complicates its practical application, because a reviewer now has to assess not just the code itself, but how sensibly the process that produced it was set up, and that requires understanding the agentic process itself, not just reading the diff.
How to stay a competitive developer
The practical takeaways from everything above add up to a concrete set of actions, not abstract anxiety. First: deliberately invest time in skills that don't get cheaper, systems thinking, the ability to assess a solution's correctness, communicating with people, rather than only studying whatever new AI tool just showed up for the sake of its novelty.
That doesn't mean ignoring new tools, they're appearing too fast for fully ignoring them to be a sensible strategy. It means keeping proportion: time spent learning a specific new tool is worth weighing against time spent developing skills that stay useful regardless of which specific tool turns out popular a year from now. A tool that's the favorite today can easily be obsolete in eighteen months, while systems thinking and the ability to work with people stay useful for decades.
Second: actively practice working effectively with AI agents as its own skill, rather than expecting it to show up on its own from passive use. I wrote about how a genuinely productive system around this kind of work is actually structured in the piece on productivity systems and the piece on focus and deep work: the ability to hold attention on a hard architectural problem without getting pulled away by every small snag through a quick check-in with an assistant is exactly the skill that separates an effective agent orchestrator from someone dependent on constant hand-holding.
Worth recalling here the review discipline I covered in the piece on AI code review: the ability to quickly and thoroughly review someone else's code, agent-written included, is becoming one of the central skills of the profession, not a side addition to writing code, as the share of self-written code in a workday shrinks and the share of reviewed and approved code grows.
Third, less obvious: protect yourself from the anxiety that, on its own, lowers the quality of your work. Anxiety about being replaced ties closely to impostor syndrome, which I covered in the piece on preventing burnout: trying to compensate for that anxiety with constant overwork and an attempt to "keep up with everything" usually makes the outcome worse, not better, because an exhausted specialist does worse at exactly the systems-thinking and quality-checking tasks that remain the most valuable part of the job.
The vicious cycle here is the same one that drives burnout in general: anxiety about your own replaceability drives overwork, overwork lowers the quality of systems thinking and attention to detail, that drop in quality confirms the original fear of "I'm not good enough next to what AI can do now," and the cycle repeats with renewed force. Breaking it takes the exact opposite action, not more effort: deliberately protecting time for rest and deep, single-tasked work precisely when the anxiety is telling you to do the opposite.
A fourth practical move rarely stated directly: build a reputation around the ability to solve a certain class of problem, not around a specific technology stack. A stack goes obsolete on a cycle of a few years, sometimes faster. A reputation for being someone who can make sense of complex, poorly specified systems and carry a solution through to production survives a change of specific tools and languages, because it isn't tied to what those specific tools happen to do today.
Where the profession is headed: a personal view
What follows is openly a personal opinion, not a forecast presented as fact.
By 2030, I expect the concept of "developer" to split more noticeably than it does today into several distinct, less similar roles: systems architects who design but rarely write code by hand; reliability and verification specialists whose main job is validating output produced by agents; and narrow domain experts whose value lies in deep subject-matter knowledge rather than universal programming ability.
I expect that the part of the industry currently living in a state of anxiety about "AI taking the job" will, within a few years, either adapt to the new structure of roles, or genuinely face a real drop in demand for its specific, narrow set of skills. That's not a cheerful forecast, and it's not a catastrophic one either, just an honest one: transitions of this scale always produce winners and losers, and which side any given person ends up on will be determined not by whether they use AI at all, but by whether they invested in skills that stay valuable as writing code gets cheaper.
I also expect that part of today's tools and practices, which look cutting-edge right now, will look by 2030 as outdated as programming practices from a decade ago look today. The specific setup details for a specific AI assistant that I cover in other pieces on this blog will almost certainly change beyond recognition. The principles behind those details, dividing accountability between human and agent, the importance of verifying output, the value of understanding a system over the ability to type code, will probably stay the same, just applied to different, more advanced tools.
I also expect the profession itself to become less uniform in its required skill set than it is today. The gap between an engineer working as an architect on a large system and an engineer running a single small project alone is already, in day-to-day tasks, bigger than the gap between two hypothetical "programmers" ten years ago, and I expect that divergence to keep growing rather than leveling out, as AI takes different shares of routine work away from these two roles to different degrees.
If this forecast turns out at least partly wrong in a few years, I'd rather admit that directly than quietly rewrite the piece after the fact. The date at the top of this piece marks the moment these thoughts were current, and that's the only honest guarantee any forecast like this can offer.
Whatever from this list turns out true, one thing seems more durable to me than any other prediction: the profession won't disappear, and it won't stay the same, at the same time. It'll keep existing in a form that's hard to predict in detail today, the same way a programmer from the nineties would struggle to recognize today's agentic workflow as the same profession, even though the continuity between them is obvious in hindsight. The only thing genuinely within my control right now is not trying to guess every detail of that future shape, but investing in what stays valuable under any reasonable scenario: understanding systems, honestly assessing your own work, and the ability to negotiate with other people about what's actually worth building in the first place.
Comments
No comments yet. Be the first.