I was reflecting on this on Saturday in an unformed way, trying to trace the lineage of a decision made at work.
The code change itself doesn't specifically matter. But suffice to say, it was about an AI feature in one of our products.
The code was stamped by Claude driven by a prompt. The prompt was for a ticket generated with the Atlassian AI integration. Atlassian had digested docs made with AI. The docs came from strategy memos I'm 90% sure were written entirely by Claude.
The strategy was chosen by management at the urging of exec leadership. The execs now communicate mostly via AI written memos. I do not know how they make decisions, but they reference tech influencers, market conditions, customer expectations.
This gave me pause. Who had actually made the decision then? Arguably there has been several layers of human review, but the actual source of the decision was hard to pin down.
We were not building the feature because we wanted it. We were building it because we thought other people expected it.
Perhaps reflecting on the state of the market, I thought, could indicate who was actually in control.
Where do investor and customer expectations come from in 2026? It is very murky, at least in tech. There appears to be hype. Some hype comes from true believers, some comes from cynics. But both respond to market incentives that reward bigger and bigger claims.
Where does the market's "action" come from? What is the driver?
Investors do not really seem to understand what the tech is or its limitations. Some are passive operators. Others are just responding to the overall froth and speculation in the market - which becomes a runaway feedback cycle.
This left me lost.
Nobody in this ecosystem, I thought, is actually in control here.
Nobody is actually orienting work and action to real, concrete goals. It's all based on speculation and anxiety about the future.
So it is not only that nobody understands what the code does. It is that we cannot, or at least I cannot, explain the motivation. There doesn't seem to "be" any form of "intention" in this environment.
It has all been hollowed out, replaced either be inscrutable machines, or inscrutable incentives.
Ironically it rather resembles the kind of "misaligned" superintelligence we are supposed to be avoiding.
In many (most perhaps, but hard to know personally) companies, most people don't really understand the market they are in, the competition, their own products, the customers etc well enough to actually make good decisions. They also aren't likely to be around (or held responsible) for decisions as they play out over years. So what has historically happened is that people use proxies for good decisions and understanding - which are clever sounding documents and presentations.
This is a long winded way of saying "people made up clever/sensible sounding stuff". Now it's easier to do it with AI so the problem is worse. However, I'm not sure what you were looking for was ever really there - the "inscrutable machines" and "inscrutable incentives" were always quite inscrutable.
For me, at this company, which is struggling to develop a new value proposition, everyone is unfortunately using AI in a blatant way. It’s even worse when executives and management pressure us to move fast. Presentations, documents, and mockups all use AI, rinse and repeat, feeding it context, but somehow, nothing is moving. It’s just staying static.
Professors in grad school are also simply replying with chatgpt answers to any and all questions, including reviewing papers before they're submitted. I've learned to simply cut the middle man and ask the AI myself, though i cannot afford the pro subscription.
Anecdotally, I know people in the industry who tell me their job is "so easy" now because all they need to do is be a meat proxy for claude and take home the paycheck.
Question from someone written in AI? Just answer it in AI and send it back. What was it actually about - who cares? Bug comes in? Post the jira link in claude and don't even bother prompting anything else. If something critically breaks - well, eh, we'll deal with it then. FIRE (early retirement), a prediction their layoff is inevitable, and investing aggressively so you can finally escape actually working are often invoked in the same breath. Everyone feels like they're just trying to punch the drywall and grab as much copper wire out of the walls as they can until they're finally let go and/or the whole company fails.
There's a great deal of nihilism and cynicism in the industry currently, and it feels like LLMs are just greatly enabling it. Where you would've done a halfassed job previously, you'd now do an unchecked AI job.
Well it's the incentive given. A bit like the original comment writes above. If your performance and impact are measured by charts, meeting outputs, some kind of abstract KPIs and other means that traditionally kind of worked because people had agency, you are incentivized to just slopmaxx it. Otherwise you will fall behind your colleagues who slopmaxx and have a better number on their abstract KPI.
If you get called out on some issue or shitty implementation, you can just make Claude abstract it away behind more complexity to the point where people have a hard time doubting you because they don't have time to get into the details and verify things.
Grab as much as you can, invest in immovable property and other shit that has value after a stock crash and enjoy the ride
One of the more thoughtful observation's I've seen in this "space," one which offers an unsettling counterpoint to the claim in the original post that "AI Can't Drive Itself."
To your point, AI can drive itself; it's just that the fashion in which control occurs is distributed. Which is to say, the process (e.g. a feature being implemented, in some way, or at all) is not spontaneously occurring: it's emergent from the mesh of AI automation.
Niceties aside, it's pretty clear that humans are not in the loop in a meaningful way, much of the time. What emerges may hence not well be not aligned with business or technical needs. What it is aligned to may be impossible for we humans to discern.
Who controls the way a forest grows?
Ask a tree, get an answer, but don't forget, that's not the answer.
Exactly the same issues we are facing right now. And, well why wouldn't it end up like this? The promises of going 'faster' while ignoring the organisational processes capability to handle it is - and continues to be - the greatest delusion of this new age.
But, even in the face of all of this, we are seeing leaders asking for more. At some point the culture will collapse in on itself, and no one will understand anything anymore.
You could look at it as a kind of evolutionary pressure, where the AI driven companies that have no tether to reality are eventually extinct. Companies that are able to get a handle on the direction they are being dragged may have a fighting chance of survival.
It's like old fashioned Wordpress, edited by someone directly in production, on a shared host that probably is infested with who knows what, with little to no oversight except inscrutable emails, which in the old days were like a CEO of a small business emailing 'hey, the thing we spoke about on the phone, is it coming?' and no actual document trail.
Except for the enterprise customer and at enterprise prices.
This is why we are building Origin (originhq.com). Having a record of every prompt, tool call and model response enterprise wide allows you to answer these kinds of questions.
When you write something you constantly remodel your understanding through refactors and rewrites until you internalize it. By internalizing it you gain the capacity to reason about it (during critical downtime) and communicate it. An entire team that can communicate can solve problems together, from one guy's vision to products white boarding to engineering's infrastructure to UX and UI's artistry.
It boggles me we completely forgot that the world operated like this just 4 years ago
I feel this in my bones. My team is one of the most communicative in our org and have garnered a widely positive reputation I think largely as a result of our coming together every day to solve problems. Trying to get information out of the less communicative groups is like pulling teeth, i wonder how they get anything done at all
I am simultaneously deep down in the agentic treadmill and also supremely frustrated by this.
And I don't think it was ever necessary to go to the point where people just gave up authorship. These were choices made by adopting the "I'll do everything for you" agentic "harness" model that shipped with Claude Code but it was never inevitable.
e.g. we completely dropped fill-in-the-middle completion OG CoPilot auto completion model. That combined AI authorship with a human always in the mix and I actually really enjoyed it. It's just that the models involved were pretty stupid. We totally could have had IDE / shell / tooling integration that kept people in the driver's seat while automating parts of the drudgery away. Instead what we got was a simple chat loop with "oh, whatever, you go do it" being the ultimate result. Cuz, you'll totally review everything after and understand it, right?
The things should end by quizzing you on what was just made and if you don't pass, just throw it away. That'd be funny to watch.
The way I think about it is that understanding is formed in a top-down fashion now, instead of bottom-up. You can look at a feature developed by AI from the outside, and keep peeling the layers and examining them (or having AI explain them to you) until you learn how it works. It's like reading a textbook. It is different than writing the code yourself, or practicing the topic of the textbook yourself. But if you invest the time, it can be just as effective.
The issue of course is that if you do invest the time, then you're no longer saving time by using AI. You're just spending it reading and trying to understand something you didn't write. And that can be unpleasant in its own way.
My hot take is that for parts of a system that can be considered its core, forming a deep understanding is almost always important, and so is knowing how the different business domains integrate and where the connection points are. For many others, a high level understanding is sufficient. The difference is that now, with AI, you can make that choice. Before, you had to write everything yourself, and for any sufficiently complex and long-lived system it became impossible to hold all of it in your head.
I disagree that reading a textbook is just as effective as solving problems yourself (this is what i read your statement to mean). It seems fairly obvious from university experience that doing the homework yourself gets you better test grades in the end. You can of course have the AI write the homework but you can't then just watch the AI solve it lest it be drastically muted in effect. Trying things that fail, working hard towards a problem, banging your head against something impossible, these are all worthwhile endeavors. Of course reading the textbook is useful too, very useful! But the textbook does not teach you experience.
> It boggles me we completely forgot that the world operated like this just 4 years ago
I'd think that's what they call paradigm shift, and this probably repeated across generations from the introduction of the printing press, PC, the wheel, the internet to stochastic parrots that reduced what we still stubbornly insist require our special neurons to mere statistical modelling that can be aggressively scaled.
I am finding this, professionally, not so dramatic - but mostly because the industries in which I've consistently shipped code at scale involve review as a first principle, as in no un-tested, un-reviewed code gets shipped, because: safety critical/realtime requirements and certification specs, say so.
And having AI code to review is no different than any other code that ever was to review, so the review tooling is - as it necessitates - also benefited by lugubrious application of .. more AI. But: all AI is human reviewed.
So it's not a big impact. We just don't ship code that isn't 100% human reviewed, If that's insurmountable: you're doing it wrong. Use AI to make code readable again.
And then, also, put AI back in its box. Don't give devs 100% full-time API access to subscriptions: give them actual hardware to use, to go 100% local.
Local AI is, thus, the best AI, folks. Don't use more than you can run locally, is a great way to keep AI code properly maintainable.
The industry will prove this, itself, sooner or later: If you can't put your AI in its box for safe-keeping, you're doing it wrong, anyway... and should've already learned this practice as a habit, decades ago, vis a vis future-proof tooling... (See also: not logging everything you do with an AI? Big fail.)
Sure, the absolutely intoxicating addiction of Big Metal AI™ is going to put a lot of consumers in a deep, deep pit of Neo-Illiteracy - however: 'good' AI code is actually just good code.
> I am finding this, professionally, not so dramatic - but mostly because the industries in which I've consistently shipped code at scale involve review as a first principle, as in no un-tested, un-reviewed code gets shipped,
> And having AI code to review is no different than any other code that ever was to review
If your company is sticking to "everything needs (human) review" then you wont run into most of this. This issue is that a lot of companies are using AI as an excuse to remove that review process (either partially or entirely).
Yes, that is very real to me, the AI "revolution" is more of a battle between traditional devs trying to replace their managers with AI, and professional managers trying to get rid of the devs the same way. There is a wide degree and scope of knicker-twister'ing in these trenches.
Everyone can write code these days. Trouble is, all code has to be SIL-4 code now, because, human, you will never know if your compiler trusts your AI until you trust your compiler. This rule will be true for decades into the future, I'm willing to wager...
The post seems to be in line with some of my own direct observations. I've been pondering recently whether for many devs the use of AI is the death of the mental model.
We all interact with systems through mental models, but if many devs are just prompting claude when something doesn't work, they might read what claude found, but lose out on the exploration, debugging, and work that builds and reinforces the correct mental model and discourages the wrong one. And if devs are missing out on the mental models, will they actually be capable of driving efficient solutions to problems as the mental models get worse.
I see this everyday. The problem is code is the wrong abstraction for the work we do. LLMs have solved coding, but they haven't solved systems, collaboration or system maintenance.
I would say it means you are building software but no longer are concerned with writing or editing literal code. Your concerns have moved up the stack to managing requirements, context, and verification processes.
Just to make this clear: if you can define a really good PRD and sophisticated technical specs, and a strong set of tests cases to pass, at the right level of architectural granularity, plus adversarial code review processes that triangulate and weed out most mistakes, SOTA agents can write the code autonomously, at or above the quality level of most human coding teams. I call that "solved" but only if you meet those context requirements. Which is still hard, not solved, at that layer.
Solving writing is not a good analogy IMO. Writing is for human consumption, and cannot be wrapped in objective requirements and verification processes. Certain forms of writing perhaps could be (can't think of one at the moment but I don't doubt some exist), and those forms might be good analogies for being "solvable" or "solved."
"solved coding" is type of thing you say if you want to sound smart.
Saying that LLMs have "reduced the cost of coding" would be boring. And using your analogy, pencils, typewriters and computers have all reduced the cost of writing, but writers are still around.
"Reducing the cost of coding" would imply that you still have to code, but with current LLMs you no longer have to. You can write 100s of thousands of lines of code without ever having to touch a single line of code. Literally "here is a git repo, here is an issue, please fix".
You might still need to nudge the LLM in the right direction or stop it from going off weird tangents, but none of that involves touching actual code yourself.
It solved coding as in it's significantly less of a bottleneck than it was before.
At least that's how I experience it. In the before times each non-trivial code change had a real opportunity cost as it would easily consume two days until I could even estimate whether this is worth looking deeper into.
Writing is a means of expression and communication. Code can be those things, but that's not its primary purpose.
I think "solved coding" is taking it too far, but for many projects, the mechanical aspect of it has been removed or reduced greatly.
LLMs will have a much harder time "solving writing", because they cannot develop their own style and so are severely limited, creatively. This is less important for coding.
even setting aside the artistic side of the profession, I see these things make all sorts of basic mistakes, so even the mechanical part doesn't seem "solved" ime
Given a working system, like a web service or services, and their code, non technical people can now make effective changes with LLMs.
For example, nobody on our team writes manual code anymore, we have basically set up a harness where an engineer types up the requirements for a change, the system implements it given certain constraints, we have automated unit and integration tests that are ran, and if any errors pop up, they get fed back into the loop until fixed.
But to do that, you need to actually know what you are doing - you have to have good instructions to keep the agents in check and not start making mods outside of their bounds especially when the issue is with a dependant service that is causing errors.
I'm well on my way down this path too, but that is a process implemented in markdown. I don't see coding as solved, or a solvable thing at all, like writing
To solve something, there must be a defined problem, what is the problem that was solved. Or perhaps it is just "coding is solved" is the turn of phrase de jour be ause we haven't yet found a more succinct and accurate way to describe the paradigm shift
When it comes to non technical people using Ai to build things on code, the outcomes are on average pretty poor, which i see as evidence that the driver and their expertise behind the Ai matters a lot. A notable example is Terence Tao's conversation with ChatGPT, us math normies could never have done that. The same applies to coding agents ime
>The problem is code is the wrong abstraction for the work we do
My team recently spent two weeks on a wild goose chase trying to figure out why TensorFlow Lite was generating nonsensical OpenCL kernels. Well it turns out that LLVM had a few bugs in the RISC-V assembly for our platform that was leading to silent garbage. It took combing through assembly dumps, hexdumps, a lot of pain staking debugging, and going through the TensorFlow Lite source code to to track this down.
In your opinion, if code is the wrong abstraction to be working at, how do you approach this scenario?
Or more broadly, LLMs fundamentally don't "understand". They can simulate understanding and generate text/code/whatever, but they don't have will to engage with something holistically and "own" it.
I have been trying to define "understanding". Is it when you can predict something that you understood it? Or maybe when you can explain it? Or how about when you can control it? Or invent it.
This time I add another definition "when you can own it".
I think it is not needed to own every line of code anymore , but you should still have control and idea about the architetcure of the system. You should understand what componenets are there and what is the repsonsibility , how are the orchestrated and what are my quality gates where i messure if what i requested match the results. Thats why i build archkeel (https://github.com/rapiddweller/archkeel) and datamimic (https://github.com/rapiddweller/datamimic) ... to increaes the transparency and review surface for human ... to make the results easier to judge ... i think when we stop knowing anything, we can also stop burning token and ressources
I feel related to it. I switched companies at the end of July. First 4 weeks AI was giving me the feeling of freedom. No longer I need to understand tens thousand of lines of legacy codebases. Never onboarding was so easy. Just ask Claude and it tells me what happens here and how.
But after 2 months it starts to backfire me. I still know nothing. I have some understanding of the system design and core components but I have zero clue about how certain things are done under the hood. Because AI read code for me and code for me and I take it as my own understanding.
In last week I end up limiting my AI usage and forcing myself (it is really hard) to read and code at least a bit by myself to start having any idea about what is going on here.
In this moment there are a million ways to do things wrong.
But there are also some ways, maybe less than a million, to do things right.
Here's an anecdote about a way to do this wrong.
I have found with AI coding methods that there's a line where it becomes a hail-mary (in the American Football sense).
A hail-mary is when you throw the ball to the end zone and just pray someone catches it. This is almost always at the end of the game.
This moment with AI code is indicative that you can't put together a coherent plan so you just tell the agent to "make it good". It used to be that the results here would suck, but now the agents are really competent, so the results might be good.
But at that moment, that's your cue to back up. Because as soon as you take a solution that's so far detached from your understanding, you're underwater. The hail mary is not part of a larger game plan. It's the last play of the game. There's nothing after.
So as soon as you reach that moment in your coding, you're signaling that you're done understanding not just the code, but even the way it works at a high level. If you're still going to work with this code after, then back up and work with the AI to get more understanding of the problem.
Each to their own, and the market will decide in the end? If a company is going to (implicitly or explicitly) incentivize everyone to directly ship Claude’s output straight to production, and prioritize features above everything else, that’s a choice. Providing that I have a long enough runway, I’d love to have this company as my competitor? Yeah, year 1 will suck, because they’ll pull ahead, but if I can stay in the game until years 2 and 3…
Aside: this reminds me of running a “negative split” in a long distance race, where you aim to run the second half faster than the first. It’s very hard to do this because you have to be willing to let everyone else in your pace group pull waaay ahead, and running above race pace in the beginning feels “free” with all of the adrenaline. But if you do manage to stay disciplined, it’s a fantastic feeling to reach half-way with gas in the tank, and then start to reel in all those runners who sped by in the beginning.
> because they’ll pull ahead, but if I can stay in the game until years 2 and 3…
well as you said, the market will decide in the end. You may be even further behind in years 2 and 3. btw, we're already in "year 2 or 3" territory for some, i wonder how those companies are doing vs their competitors who adopted AI full throttle?
Most people say full agentic coding only got good enough for production at end of last year.
This year was the turning point for most companies. A lot of experiments going now right now.
Of course things can change drastically in the next years, as they already have in the last few.
Only thing I know is that it is really stressful working on this rat race
AI is not for programmers, they will always complain and given time and resources can of course produce better atomic code. AI is for a combination of a business analyst, architect and product manager in one person who has capacity in coding but decided this is limited role in the whole software engineering lifecycle. With the right attitude and of course certain level of micro management over AI (which they had to do with human programmers as well) they can achieve the same or similar results with much less communication friction, less people to maintain that teamwork and get closer to solving issues they find rather than discussing philosophy of programming and other manifestos of the craft that stopped being prestigious or unique and that’s the key point of complaint when AI is given wrong people to use.
Can they really achieve similar results though? If quality suffers greatly, and velocity eventually slows down due to huge tech debt, isn't that just a worse outcome?
I don't really understand all the negativity - I've delivered amazing robust solutions at about 10x my previous rate I think and can make dramatic cross code changes on awful legacy code bases with ease. I just added some complex prev/next navigation across a load of detail pages pages that rely on the current search, a new PDF generation system that uses a queue and workers and absolutely tones of changes to a legacy ERP system that would be unworkable without AI.
Dealing with legacy messes I used to get frustrated and bored of making the improvements, now it's easy to clean up code bases and write loads of tests. I asked Astra to come up with a plan for Playwright testing the whole App, I have not built it yet but the flows suggested were fantastic as was the ephemeral database we plan to create for CI.
I built my friends portfolio website almost entirely vibe coded in 4 hours and it looks unbelievable, we added so much slickness (he's a designer) just prompting together. I used a CMS I had never used once before and it was so so easy to do without any of the usual need to read docs about everything.
I've done so much devops now I'm actually fairly confident that me and an AI can do anything you want in terms of deployment/infra and scaling from AWS to Terraform to whatever.
Anyway my main concern about this technology is not that it is crap at coding it's that the improvements in how it codes and thinks are absolutely dramatic which is extremely scary - it has come so far in a year I wonder what the next year will bring.
Next year you may be unemployed (because your boss will cut by half the engineering department), or perhaps your salary will be cut by half (because your boss will route your other half of your salary to openai/anthropic), or perhaps you will get half insane (because your boss will ask you 10X the output you used to have but within the same timeframe)
Whatever the path is, regular engineers (90% of the people around here) will get screwed up one way or another. But hey, playing with LLM agents is cool!
It's not a given. It's about willpower and care. LLMs are the ultimate crutch. I over-rely on the crutch, more and more people will over-rely on the crutch. But it is still inherently a psychological problem.
You can still know things and get force multiplication out of LLMs, if you are disciplined and caring enough. In practice, most people won't be. And you can't force other people to be. But you can force yourself to be.
> You can still know things and get force multiplication out of StackOverflow, if you are disciplined and caring enough. In practice, most people won't be. And you can't force other people to be. But you can force yourself to be.
Yeah we forgot the goal of programming isn’t just to tell the computer what to do, it’s to program the programmer into thinking a deeper understanding of the problem.
AI is going to make, long term, Software Engineering more important. Getting requirements, user feedback, tests, product vision. These are key differentiators now.
If you can really get a good set of requirements, go and write all of your test cases out, and then throw it at an AI that will one shot it. Its perfect.
This page has been live long before AI appeared, I used Quartz [1] v3, now at v5. But added some features I like with AI, yes, but still keeping my beloved color theme and web style as I had it for a long, long time. The whole code for the second brain (ssp.sh/brain/*) is on GitHub, in case you want to check it [2], but you can also see the "Changelog" in the footer to see recent visual changes. But I'd be curious what makes you think it's AI-generated?
How humans can differentiate the things they make has been something I’ve been thinking about a bit recently. What markers signal to you this is AI generated?
I mean, the content doesn't look AI generated. I couldn't care less if someone AI generates their blog template, the rest of the content seems meaningful.
After experience on both ends of the spectrum, I arrived at the position that what we basically need is to be a "Responsible Human in the Loop (RHITL)" [0]
> You may not write the code by hand but you understand it enough to investigate and fix it when it fails. It is how I think we should leverage AI instead of becoming a meat proxy.
People keep saying this, but how realistic is that in reality? Even say a person is doing their best to do that, we all know that the alarm that doesn't trip 99% of the time isn't going to be closely monitored. Just look at what happens when people get used to "hands free" cruise control.
Not only that, but even if we assume best effort on the engineer, the business pressures don't often allow that. I'm under constant pressure to deliver more, faster with less people. The performance eval ladder at my company was just reworked to double the amount of deliverable features expected per job level per year. Our CEO told us we should be able to deliver what took us the past decade to deliver in a quarter, every quarter going forward.
How could you possibly have a human anywhere near that loop with those demands?
We've had team changes and product manager changes and lack of documentation for so long that this was the state of our team anymore: no one knows why it was done and no one wants to break it.
I agree writing completely new systems with LLMs is now near impossible to keep in your head, however, the onus is STILL on you the individual engineer. You are mistaken if you think that's changed.
So, if you're pooping out code, and committing it because tests still pass, and that's all you know, you're in for a treat. When an executive wants to know why a b0rked feature lost their department millions of dollars, guess who will have to answer for it, and its not the LLM.
My advice is to find ways to keep on top of how it all works, and if you're the only one who cares, well, then, that makes you even more valuable, not less.
This problem has existed long before AI became useful. As technology becomes more accessible, less knowledge is required to operate it. As that knowledge becomes less necessary, fewer people acquire it. Eventually the abstraction becomes so effective that entire layers of knowledge disappears from common practice.
As a person who's a solid generalist with over 30 years in various roles, I am completely and utterly shocked at how little foundational knowledge people in "senior" roles possess across a wide variety of technical fields.
I'm often treated like some wizard or oracle for knowing things that everybody in the field used to know, I just haven't retired yet.
AI didn't create this phenomenon, it's just the latest (and probably the fastest) iteration of it.
When you simply large amounts of information, the knowledge probably shifts to upper level reasoning, then complex reasoning develops on top of it again. But who knows.
"Nobody is resolving bugs" is weird. Coding agents are great at resolving bugs! So much of what I see posted here seems more about how coding agents are being misused rather than anything inherent to them.
"People are working 12 to 13 hours a day just to press enter. Nobody is reading anything."
Really? Seems like they're not making proper use of the tool. I've been reading MORE not less, and also learning more along the way. Just hitting "enter" is a choice, these tools are so powerful if you invest your curiosity, time and experience.
Sounds like they don't care about what they're doing in the first place, writing code by hand won't fix that.
Understanding code is trivial, with AI support. LLMs are better at summarizing and identifying side effects than writing code. Granted, not perfect, but about as good as a person.
Writers disagree on what effect word processing will have on the quality of our written language.
Some writers are concerned that computer assistance may promote dry bland writing.
If you don't understand how your system works, your ability to make good decisions about future work on that system quickly degrades.
I don't think you need to review every line of code, but you absolutely do need to be able to describe how the system works and its high level structure.
As is so often the case with coding agents, having experience as a tech lead or engineering manager really helps here. You are responsible for a large system that has been worked on by multiple different collaborator (both human and agentic). You need to be able to make smart, informed decisions about that system, and talk with credibility to other stakeholders about what it can and cannot do and sensible next steps for the project.
What will the path to a tech lead look like when it's no longer paved by thousands of hours of experience internalizing code? How do future tech leads avoid becoming like people who never got comfortable with fractions because they offloaded all arithmetic to calculators from an early age?
My hope/hunch is that the kids will be alright. Not learning effectively is a choice: if you want to get good, the paths to getting good are all still available to you.
We have never had as abundant a supply of tools to help us learn our craft. I expect that many people will thrive.
People who are a bit lazy and prone to cheating will be able to hurt themselves even more.
I had agents deep diving OpenCode source over the weekend, writing research docs, and helping me with a set of plugins. I learned quite a bit from the process and markdown walls, enough so that in later sessions I was able to point the model at where it was conflating concepts and help narrow its search.
Ai can help you learn if you are intentional about it.
>I don't think you need to review every line of code, but you absolutely do need to be able to describe how the system works and its high level structure.
I just don't see how you can truly reason about a system without delving into code. Tests aren't enough, running the software isn't enough, high level system architecture isn't enough.
>As is so often the case with coding agents, having experience as a tech lead or engineering manager really helps here ... You need to be able to make smart, informed decisions about that system
In my experience, engineering managers are too detached from the system to accurately reason about the system. Tech leads on the other hand usually can given enough time, but they tend to defer judgement to senior ICs on the team who are more familiar with the code.
Point is: there's no way to have your cake and eat it to. You either read the fucking code and keep a mental model of how the system works in your head, or you have an overstated confidence in your ability to reason about the system (and this has been a problem well before LLMs).
>We’ve had to know everything about the product/business from day 1
I know this is being hyperbolic but I thought this was an odd post to include. I've met plenty of data engineers that don't have great knowledge of the business/product and SWEs that do have that. ¯\_(ツ)_/¯
I predict we will see more and more of these convoluted rationales (i.e. excuses). All these basically boil down to: “I know AI is crap, but I have found a way to make it useful. Trust me.”
I am gonna appeal to Occam’s razor here and say, the integral variable here is AI, and the only variable you need to know is AI. The problem is AI.
that tweet about the fast moving startups looks like almost the hypothetical AI nightmare situation just dreamed up. Assuming it's real, i mean yeah, people shouldn't work for these stupid high-moving startups I guess. From my perspective, "when did startups NOT suck?". The code was always garbage at startups, the push to work 12 hour days was always at startups, "nobody is resolving bugs" ha well yes, welcome to a startup? I hope the guy is at least getting paid and doesnt have to hire a lawyer to get his checks like I did. startups suck
> But the final boss is, and always will be, maintainability.
Always has been, always will be.
I am actually hopeful that AI will finally break the industry and force a reckoning around this. Some of it goes to our economic system. New builds are usually capitalizable, flashy, and a great way to get promoted.
Doing ten to fifteen years of thankless maintenance, keeping a critical system alive with high quality? Usually nobody cares, and it's OPEX, not sexy.
This article assumes that this problem did not exist before AI. Especially in large companies like Google, the number of people who actually knew what they were doing was relatively small. The vast majority were just piggybacking on other people's work, which I absolutely hate. At least AI has made this obvious, and the difference between people is now their taste, which, for the majority of people, is bad news.
This! I work for a company that has several systems that are older than 20 years and no one really knows how they work. We are using AI to actually get insights in how they really works, to be able to rewrite and modernize the applications.
I can't read the source code since it's 8 million lines of code and written in a programming language I don't know and in a language I don't speak.
A man has to write program for himself and a man has to use the program. A man needs to define in code what the program does. If AI defines what code does then man has not written program for himself.
The future of engineering is product management. I don't believe there is any world left for people whose primary responsibility is opening pull requests; and we're seeing the angst against this happen from both directions. Engineers hate it. Leadership feels they don't need them. The truth is somewhere in the hazy middle; we're just in an uncanny valley right now where neither side can take the leap to cross the valley: the agents aren't good enough yet, and the bigger problem is that there's no job title or corpus of experience leadership can look to and say "Yeah that's the person we need in this role".
The labs saw this early, and thus many roles at the labs are "Member of Technical Staff". That's the future for every software team. You're not a software engineer anymore, but you're also not a PM, nor a designer. Think horizontal slices, not vertical: Every human's responsibility is to leverage AI to be an expert on everything necessary to deliver some vertical slice of the business.
Wouldn't engineering then be the safest place to be? Engineers have always been embedding loose requirements into runtime law. They (supposedly) understand the business model better than most and have the technical know how to validate that
Yes I think that's correct. But I'm worried less about safety and more about fit. Articles like this convince me that there are some engineers who will struggle to adapt to a world of "no one knows what's going on". Engineers have always had the benefit of making abstraction concrete, through the systemization of abstract business requirements into concrete code that the team would build a shared understanding of over time. But that doesn't seem to be where the industry is trending.
PMs have always lived in the world of dealing with hazy abstraction in both directions: Unclear requirements coming in, turned into unclear system capability whom they have to rely on the engineers to parse. This is where Engineers will have to get comfortable living now: Unclear requirements coming in, unclear code coming out. Its clear that many engineers aren't ready for this, and I don't blame us; it SUCKS. If I had ten dollars for every time I've heard a PM say "no one has any idea what's going on" over the past fifteen years, I wouldn't have to work anymore.
Engineers are probably still the role most suited to adapt to this new world, as you say, but I think people are still vastly underestimating how much they will be personally impacted by the changing industry. If you hate your job now, for reasons like those the article communicates, you'll hate it ten times more in a year.
Too many young people in startups without enough experience.
I was in a Hackathon for students which quite a few staff, like myself, infiltrated. The results were completely unfair, staff and teams with staff (like mine) cleaned up the awards.
In my case I was working with a student who was much better at writing platformers in Unity than I was and an another student who could draw the art we needed even if she'd been trained to think every problem we had interacting with each other had something to do with "the patriarchy".
Myself I'd been in many startups where the game was make a half-baked demo that you could demo on stage and get people excited about it. So everything from presenting broken software on stage and making it look not just perfect but enticing and developing software that has the qualities it takes to present it that way was routine for me, the bit that isn't routine is onboarding unexperienced people to this life in two days.
The more things are unprecedented, the more you need a longer view with more experience.
The code change itself doesn't specifically matter. But suffice to say, it was about an AI feature in one of our products.
The code was stamped by Claude driven by a prompt. The prompt was for a ticket generated with the Atlassian AI integration. Atlassian had digested docs made with AI. The docs came from strategy memos I'm 90% sure were written entirely by Claude.
The strategy was chosen by management at the urging of exec leadership. The execs now communicate mostly via AI written memos. I do not know how they make decisions, but they reference tech influencers, market conditions, customer expectations.
This gave me pause. Who had actually made the decision then? Arguably there has been several layers of human review, but the actual source of the decision was hard to pin down.
We were not building the feature because we wanted it. We were building it because we thought other people expected it.
Perhaps reflecting on the state of the market, I thought, could indicate who was actually in control.
Where do investor and customer expectations come from in 2026? It is very murky, at least in tech. There appears to be hype. Some hype comes from true believers, some comes from cynics. But both respond to market incentives that reward bigger and bigger claims.
Where does the market's "action" come from? What is the driver?
Investors do not really seem to understand what the tech is or its limitations. Some are passive operators. Others are just responding to the overall froth and speculation in the market - which becomes a runaway feedback cycle.
This left me lost.
Nobody in this ecosystem, I thought, is actually in control here.
Nobody is actually orienting work and action to real, concrete goals. It's all based on speculation and anxiety about the future.
So it is not only that nobody understands what the code does. It is that we cannot, or at least I cannot, explain the motivation. There doesn't seem to "be" any form of "intention" in this environment.
It has all been hollowed out, replaced either be inscrutable machines, or inscrutable incentives.
Ironically it rather resembles the kind of "misaligned" superintelligence we are supposed to be avoiding.
This is a long winded way of saying "people made up clever/sensible sounding stuff". Now it's easier to do it with AI so the problem is worse. However, I'm not sure what you were looking for was ever really there - the "inscrutable machines" and "inscrutable incentives" were always quite inscrutable.
Data can describe to you what exists. But it can’t tell you what you value.
What you describe is people who can’t tell the difference, and who let the machine (data) make the value judgments.
It bothers me to no end when I get an AI written response, especially from the executive team or any one of my co-workers
Question from someone written in AI? Just answer it in AI and send it back. What was it actually about - who cares? Bug comes in? Post the jira link in claude and don't even bother prompting anything else. If something critically breaks - well, eh, we'll deal with it then. FIRE (early retirement), a prediction their layoff is inevitable, and investing aggressively so you can finally escape actually working are often invoked in the same breath. Everyone feels like they're just trying to punch the drywall and grab as much copper wire out of the walls as they can until they're finally let go and/or the whole company fails.
There's a great deal of nihilism and cynicism in the industry currently, and it feels like LLMs are just greatly enabling it. Where you would've done a halfassed job previously, you'd now do an unchecked AI job.
If you get called out on some issue or shitty implementation, you can just make Claude abstract it away behind more complexity to the point where people have a hard time doubting you because they don't have time to get into the details and verify things.
Grab as much as you can, invest in immovable property and other shit that has value after a stock crash and enjoy the ride
If that happens on a large enough scale those investments won’t be worth much.
To your point, AI can drive itself; it's just that the fashion in which control occurs is distributed. Which is to say, the process (e.g. a feature being implemented, in some way, or at all) is not spontaneously occurring: it's emergent from the mesh of AI automation.
Niceties aside, it's pretty clear that humans are not in the loop in a meaningful way, much of the time. What emerges may hence not well be not aligned with business or technical needs. What it is aligned to may be impossible for we humans to discern.
Who controls the way a forest grows?
Ask a tree, get an answer, but don't forget, that's not the answer.
Except for the enterprise customer and at enterprise prices.
AI has become the thing you do, and what you do it with, to achieve it. It's a self-fulfilling chicken that is an egg that is a chicken.
It boggles me we completely forgot that the world operated like this just 4 years ago
And I don't think it was ever necessary to go to the point where people just gave up authorship. These were choices made by adopting the "I'll do everything for you" agentic "harness" model that shipped with Claude Code but it was never inevitable.
e.g. we completely dropped fill-in-the-middle completion OG CoPilot auto completion model. That combined AI authorship with a human always in the mix and I actually really enjoyed it. It's just that the models involved were pretty stupid. We totally could have had IDE / shell / tooling integration that kept people in the driver's seat while automating parts of the drudgery away. Instead what we got was a simple chat loop with "oh, whatever, you go do it" being the ultimate result. Cuz, you'll totally review everything after and understand it, right?
The things should end by quizzing you on what was just made and if you don't pass, just throw it away. That'd be funny to watch.
The issue of course is that if you do invest the time, then you're no longer saving time by using AI. You're just spending it reading and trying to understand something you didn't write. And that can be unpleasant in its own way.
My hot take is that for parts of a system that can be considered its core, forming a deep understanding is almost always important, and so is knowing how the different business domains integrate and where the connection points are. For many others, a high level understanding is sufficient. The difference is that now, with AI, you can make that choice. Before, you had to write everything yourself, and for any sufficiently complex and long-lived system it became impossible to hold all of it in your head.
I'd think that's what they call paradigm shift, and this probably repeated across generations from the introduction of the printing press, PC, the wheel, the internet to stochastic parrots that reduced what we still stubbornly insist require our special neurons to mere statistical modelling that can be aggressively scaled.
And having AI code to review is no different than any other code that ever was to review, so the review tooling is - as it necessitates - also benefited by lugubrious application of .. more AI. But: all AI is human reviewed.
So it's not a big impact. We just don't ship code that isn't 100% human reviewed, If that's insurmountable: you're doing it wrong. Use AI to make code readable again.
And then, also, put AI back in its box. Don't give devs 100% full-time API access to subscriptions: give them actual hardware to use, to go 100% local.
Local AI is, thus, the best AI, folks. Don't use more than you can run locally, is a great way to keep AI code properly maintainable.
The industry will prove this, itself, sooner or later: If you can't put your AI in its box for safe-keeping, you're doing it wrong, anyway... and should've already learned this practice as a habit, decades ago, vis a vis future-proof tooling... (See also: not logging everything you do with an AI? Big fail.)
Sure, the absolutely intoxicating addiction of Big Metal AI™ is going to put a lot of consumers in a deep, deep pit of Neo-Illiteracy - however: 'good' AI code is actually just good code.
> And having AI code to review is no different than any other code that ever was to review
If your company is sticking to "everything needs (human) review" then you wont run into most of this. This issue is that a lot of companies are using AI as an excuse to remove that review process (either partially or entirely).
Everyone can write code these days. Trouble is, all code has to be SIL-4 code now, because, human, you will never know if your compiler trusts your AI until you trust your compiler. This rule will be true for decades into the future, I'm willing to wager...
We all interact with systems through mental models, but if many devs are just prompting claude when something doesn't work, they might read what claude found, but lose out on the exploration, debugging, and work that builds and reinforces the correct mental model and discourages the wrong one. And if devs are missing out on the mental models, will they actually be capable of driving efficient solutions to problems as the mental models get worse.
I have strong disagreement because it sounds like, by analogy or proxy, we have also "solved writing"
Just to make this clear: if you can define a really good PRD and sophisticated technical specs, and a strong set of tests cases to pass, at the right level of architectural granularity, plus adversarial code review processes that triangulate and weed out most mistakes, SOTA agents can write the code autonomously, at or above the quality level of most human coding teams. I call that "solved" but only if you meet those context requirements. Which is still hard, not solved, at that layer.
Solving writing is not a good analogy IMO. Writing is for human consumption, and cannot be wrapped in objective requirements and verification processes. Certain forms of writing perhaps could be (can't think of one at the moment but I don't doubt some exist), and those forms might be good analogies for being "solvable" or "solved."
Saying that LLMs have "reduced the cost of coding" would be boring. And using your analogy, pencils, typewriters and computers have all reduced the cost of writing, but writers are still around.
You might still need to nudge the LLM in the right direction or stop it from going off weird tangents, but none of that involves touching actual code yourself.
Ai can push a lot of keys very fast, but not always the right ones
if they need to be reminded to follow the coding standards, visible in the very code they are working on, what has been solved?
At least that's how I experience it. In the before times each non-trivial code change had a real opportunity cost as it would easily consume two days until I could even estimate whether this is worth looking deeper into.
I think "solved coding" is taking it too far, but for many projects, the mechanical aspect of it has been removed or reduced greatly.
LLMs will have a much harder time "solving writing", because they cannot develop their own style and so are severely limited, creatively. This is less important for coding.
They haven't solved coding.
Programming is an art form. And the better you get at it, the better kinds of ideas (abstractions) you can create.
This is something today's AI cannot do.
If everyone were to permanently switch to AI for software development, software innovation would cease.
For example, nobody on our team writes manual code anymore, we have basically set up a harness where an engineer types up the requirements for a change, the system implements it given certain constraints, we have automated unit and integration tests that are ran, and if any errors pop up, they get fed back into the loop until fixed.
But to do that, you need to actually know what you are doing - you have to have good instructions to keep the agents in check and not start making mods outside of their bounds especially when the issue is with a dependant service that is causing errors.
To solve something, there must be a defined problem, what is the problem that was solved. Or perhaps it is just "coding is solved" is the turn of phrase de jour be ause we haven't yet found a more succinct and accurate way to describe the paradigm shift
When it comes to non technical people using Ai to build things on code, the outcomes are on average pretty poor, which i see as evidence that the driver and their expertise behind the Ai matters a lot. A notable example is Terence Tao's conversation with ChatGPT, us math normies could never have done that. The same applies to coding agents ime
My team recently spent two weeks on a wild goose chase trying to figure out why TensorFlow Lite was generating nonsensical OpenCL kernels. Well it turns out that LLVM had a few bugs in the RISC-V assembly for our platform that was leading to silent garbage. It took combing through assembly dumps, hexdumps, a lot of pain staking debugging, and going through the TensorFlow Lite source code to to track this down.
In your opinion, if code is the wrong abstraction to be working at, how do you approach this scenario?
Except a little worse, since they were raised alone in a library, act mostly the same, and have harsh limits on personal growth.
Which is really the same problem with coding.
The agentic model of it just taking over and doing everything is poisonous to effective long term team work.
We're well past the point where it's about the quality of the work they produce. It's the way they integrate (or rather, don't) into human practices.
This time I add another definition "when you can own it".
But after 2 months it starts to backfire me. I still know nothing. I have some understanding of the system design and core components but I have zero clue about how certain things are done under the hood. Because AI read code for me and code for me and I take it as my own understanding.
In last week I end up limiting my AI usage and forcing myself (it is really hard) to read and code at least a bit by myself to start having any idea about what is going on here.
Here's an anecdote about a way to do this wrong.
I have found with AI coding methods that there's a line where it becomes a hail-mary (in the American Football sense).
A hail-mary is when you throw the ball to the end zone and just pray someone catches it. This is almost always at the end of the game.
This moment with AI code is indicative that you can't put together a coherent plan so you just tell the agent to "make it good". It used to be that the results here would suck, but now the agents are really competent, so the results might be good.
But at that moment, that's your cue to back up. Because as soon as you take a solution that's so far detached from your understanding, you're underwater. The hail mary is not part of a larger game plan. It's the last play of the game. There's nothing after.
So as soon as you reach that moment in your coding, you're signaling that you're done understanding not just the code, but even the way it works at a high level. If you're still going to work with this code after, then back up and work with the AI to get more understanding of the problem.
So that's why that Andy Weir's book was named that!
Aside: this reminds me of running a “negative split” in a long distance race, where you aim to run the second half faster than the first. It’s very hard to do this because you have to be willing to let everyone else in your pace group pull waaay ahead, and running above race pace in the beginning feels “free” with all of the adrenaline. But if you do manage to stay disciplined, it’s a fantastic feeling to reach half-way with gas in the tank, and then start to reel in all those runners who sped by in the beginning.
well as you said, the market will decide in the end. You may be even further behind in years 2 and 3. btw, we're already in "year 2 or 3" territory for some, i wonder how those companies are doing vs their competitors who adopted AI full throttle?
Of course things can change drastically in the next years, as they already have in the last few.
Only thing I know is that it is really stressful working on this rat race
Dealing with legacy messes I used to get frustrated and bored of making the improvements, now it's easy to clean up code bases and write loads of tests. I asked Astra to come up with a plan for Playwright testing the whole App, I have not built it yet but the flows suggested were fantastic as was the ephemeral database we plan to create for CI.
I built my friends portfolio website almost entirely vibe coded in 4 hours and it looks unbelievable, we added so much slickness (he's a designer) just prompting together. I used a CMS I had never used once before and it was so so easy to do without any of the usual need to read docs about everything.
I've done so much devops now I'm actually fairly confident that me and an AI can do anything you want in terms of deployment/infra and scaling from AWS to Terraform to whatever.
Anyway my main concern about this technology is not that it is crap at coding it's that the improvements in how it codes and thinks are absolutely dramatic which is extremely scary - it has come so far in a year I wonder what the next year will bring.
Whatever the path is, regular engineers (90% of the people around here) will get screwed up one way or another. But hey, playing with LLM agents is cool!
You can still know things and get force multiplication out of LLMs, if you are disciplined and caring enough. In practice, most people won't be. And you can't force other people to be. But you can force yourself to be.
> You can still know things and get force multiplication out of StackOverflow, if you are disciplined and caring enough. In practice, most people won't be. And you can't force other people to be. But you can force yourself to be.
If you can really get a good set of requirements, go and write all of your test cases out, and then throw it at an AI that will one shot it. Its perfect.
We have both the tools and the skills.
Later, we will loose the skills because of AI and the depletion of natural resources will lead to the scarcity of the tools.
Enough, already.
[1] https://github.com/jackyzha0/quartz [2] https://github.com/sspaeti/second-brain-public
> You may not write the code by hand but you understand it enough to investigate and fix it when it fails. It is how I think we should leverage AI instead of becoming a meat proxy.
[0]: https://raahelbaig.com/entry/responsible-human-in-the-loop/
Not only that, but even if we assume best effort on the engineer, the business pressures don't often allow that. I'm under constant pressure to deliver more, faster with less people. The performance eval ladder at my company was just reworked to double the amount of deliverable features expected per job level per year. Our CEO told us we should be able to deliver what took us the past decade to deliver in a quarter, every quarter going forward.
How could you possibly have a human anywhere near that loop with those demands?
So, if you're pooping out code, and committing it because tests still pass, and that's all you know, you're in for a treat. When an executive wants to know why a b0rked feature lost their department millions of dollars, guess who will have to answer for it, and its not the LLM.
My advice is to find ways to keep on top of how it all works, and if you're the only one who cares, well, then, that makes you even more valuable, not less.
As a person who's a solid generalist with over 30 years in various roles, I am completely and utterly shocked at how little foundational knowledge people in "senior" roles possess across a wide variety of technical fields.
I'm often treated like some wizard or oracle for knowing things that everybody in the field used to know, I just haven't retired yet.
AI didn't create this phenomenon, it's just the latest (and probably the fastest) iteration of it.
Edit: grammar
https://youtu.be/JrBdYmStZJ4
Really? Seems like they're not making proper use of the tool. I've been reading MORE not less, and also learning more along the way. Just hitting "enter" is a choice, these tools are so powerful if you invest your curiosity, time and experience.
Sounds like they don't care about what they're doing in the first place, writing code by hand won't fix that.
https://www.youtube.com/watch?v=Jt0OoXluC8g at 4:08:
I don't think you need to review every line of code, but you absolutely do need to be able to describe how the system works and its high level structure.
As is so often the case with coding agents, having experience as a tech lead or engineering manager really helps here. You are responsible for a large system that has been worked on by multiple different collaborator (both human and agentic). You need to be able to make smart, informed decisions about that system, and talk with credibility to other stakeholders about what it can and cannot do and sensible next steps for the project.
We have never had as abundant a supply of tools to help us learn our craft. I expect that many people will thrive.
People who are a bit lazy and prone to cheating will be able to hurt themselves even more.
Ai can help you learn if you are intentional about it.
I just don't see how you can truly reason about a system without delving into code. Tests aren't enough, running the software isn't enough, high level system architecture isn't enough.
>As is so often the case with coding agents, having experience as a tech lead or engineering manager really helps here ... You need to be able to make smart, informed decisions about that system
In my experience, engineering managers are too detached from the system to accurately reason about the system. Tech leads on the other hand usually can given enough time, but they tend to defer judgement to senior ICs on the team who are more familiar with the code.
Point is: there's no way to have your cake and eat it to. You either read the fucking code and keep a mental model of how the system works in your head, or you have an overstated confidence in your ability to reason about the system (and this has been a problem well before LLMs).
I know this is being hyperbolic but I thought this was an odd post to include. I've met plenty of data engineers that don't have great knowledge of the business/product and SWEs that do have that. ¯\_(ツ)_/¯
I am gonna appeal to Occam’s razor here and say, the integral variable here is AI, and the only variable you need to know is AI. The problem is AI.
As I was reading the OP I kept thinking..well this sounds exactly like what used to happen before AI.
The more things change...
Always has been, always will be.
I am actually hopeful that AI will finally break the industry and force a reckoning around this. Some of it goes to our economic system. New builds are usually capitalizable, flashy, and a great way to get promoted.
Doing ten to fifteen years of thankless maintenance, keeping a critical system alive with high quality? Usually nobody cares, and it's OPEX, not sexy.
I can't read the source code since it's 8 million lines of code and written in a programming language I don't know and in a language I don't speak.
The labs saw this early, and thus many roles at the labs are "Member of Technical Staff". That's the future for every software team. You're not a software engineer anymore, but you're also not a PM, nor a designer. Think horizontal slices, not vertical: Every human's responsibility is to leverage AI to be an expert on everything necessary to deliver some vertical slice of the business.
PMs have always lived in the world of dealing with hazy abstraction in both directions: Unclear requirements coming in, turned into unclear system capability whom they have to rely on the engineers to parse. This is where Engineers will have to get comfortable living now: Unclear requirements coming in, unclear code coming out. Its clear that many engineers aren't ready for this, and I don't blame us; it SUCKS. If I had ten dollars for every time I've heard a PM say "no one has any idea what's going on" over the past fifteen years, I wouldn't have to work anymore.
Engineers are probably still the role most suited to adapt to this new world, as you say, but I think people are still vastly underestimating how much they will be personally impacted by the changing industry. If you hate your job now, for reasons like those the article communicates, you'll hate it ten times more in a year.
I was in a Hackathon for students which quite a few staff, like myself, infiltrated. The results were completely unfair, staff and teams with staff (like mine) cleaned up the awards.
In my case I was working with a student who was much better at writing platformers in Unity than I was and an another student who could draw the art we needed even if she'd been trained to think every problem we had interacting with each other had something to do with "the patriarchy".
Myself I'd been in many startups where the game was make a half-baked demo that you could demo on stage and get people excited about it. So everything from presenting broken software on stage and making it look not just perfect but enticing and developing software that has the qualities it takes to present it that way was routine for me, the bit that isn't routine is onboarding unexperienced people to this life in two days.
The more things are unprecedented, the more you need a longer view with more experience.
Who is teaching these young girls such foolish things?