HN

Comments (189)

• Menu

  zero_shift
  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.
• Menu

  glouwbug
  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
• Menu

  MomsAVoxell
  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.
• Menu

  bengold14
  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.Edit: Since I seem to have touched a nerve - I've been working on a project to solve this: https://www.archme.io if you want to know my thoughts on the right abstraction
• Menu

  ecshafer
  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.
• vld_chk
  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.
• Menu

  hollowonepl
  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.
• Menu

  bentt
  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.
• Menu

  root_axis
  There is no "problem".The architecture and the intent don't matter to business folks, it never has, and with LLMs it matters less than ever.Vibe code into production is satisfactory regardless of architectural understanding or intent. If there are issues, just have the LLM spin up some agents to play whackamole until the issues are pushed beyond visibility.Ultimately, the idea that we can hang onto fleeting engineering disciplines misunderstands where the industry is going, regardless of any assessment of the LLMs capabilities.
• Menu

  tangled
  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.
• Menu

  softwaredoug
  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.
• Menu

  meowface
  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.
• kraftman
  We've had team changes and product manager changes and lack of documentation for so long that this was the state of our team anyway: no one knows why it was done and no one wants to break it.
• sdcfgy
  No the problem is allowing changing of system architecture or intent because the AI just did it and being totally trained to mentally surrender to the whims of it.
• Menu

  aabajian
  I don't mean to be mean, but the problem is that AI has exposed how much programming is designed around human usability. C/Rust/Go wrap assembly. TypeScript wraps JS. Java/Python wrap C.Do you need all these layers of abstraction when the human is no longer looking at the code?Best analogy is forgetting how to use a slide rule following the advent of calculators. The former was made to make hand-calculation of logarithms easy. The latter does these calculations directly (obviating the need for a slide rule at all).I think what humans still need to learn are the theory and domain fundamentals for their industry. If that industry is computer science, that means algorithms, calculus, linear algebra, etc. I think the future of CS is then (a) theoretical human-drive design and (b) prompt engineering to implement and verify that design.It would also be helpful to have domain knowledge outside of CS as having the skills to build something is nearly commoditized (outside of the above fundamentals).
• Menu

  andy_ppp
  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.
• sam_lowry_
  These year and a few next ones will be the years when everything was possible.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.
• biosboiii
  My boss-boss asked me to do a presentation on a topic I actively research for quite a while now.Scheduled a quick call to align me on what he expects - normally he wouldn't do that but he has attached a big agenda written by Claude what the presentation could show, and invited two other product colleagues of mine.I came to a Miro board of the Claude Agenda, put into Miro using the MCP.Honestly, just tiring. Asked my colleagues if they would just put the Claude agenda into Miro with Claude, what they need me for when an AI could just narrate it.
• ake2l
  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
• Menu

  chinathrow
  Clicks on blog, sees AI generated template, leaves.Enough, already.
• kevin_nisbet
  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.
• herunan
  You could argue the same with high-level vs low-level programming languages. But I do get that English is so abstracted and non-deterministic that we're kinda clueless of what's going on. At the same time, I do think that maintaining code does require some level of understanding. And unless you straight up one-shot something perfectly, you still want to test manually and tweak with a few more prompts, adding a level of 'how does this work?'.This is also freeing up time to explore things that before you wouldn't have been able to even start. New fields in tech are opening up. It's all about the model, compute, plugins, third parties... and more to come!And this is not limited to code, but also how the world works. It's all being abstracted into prompts. Funnily enough, I'm also learning that way...just taking less time to get to the point. But this is not the first time we go through this. Eg. Google vs a library. And like anything, if no one knows anything anymore how do we distinguish from one another? There's a level of wanting to understand in order to distinguish ourselves from the rest in the serendipity of everyday life.Call me naive, but something tells me we're going to start being much more open to just exploring the world with all this time we just bought ourselves thanks to technology. We were always gonna get to this point and there'll undeniably be bumps ahead.
• briandw
  I some very real way this has been true for a very long time. Does anyone know how a AMD Ryzen processor works? I mean does anyone understand in any detail how it works from machine code down to the transistors?Does anyone single person understand what’s happening when compiling a large C++ code base? Meaning, can anyone track the basket cast C++ language constructs down to the Clang IR to the optimized machine instructions? From there can any one person follow those machine instructions all the way through to the actual registers etc to actually running the code?
• Menu

  orimirs
  How can one learn system architecture while mainly vibe coding?
• Menu

  jarjoura
  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.
• Menu

  raahelb
  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.[0]: https://raahelbaig.com/entry/responsible-human-in-the-loop/
• Menu

  rencloudio
  I'm curious how much people who code this way now are spending in tokens every month? Where I work currently, we operate on a $200/month token usage limit. For me personally, this has prevented me from just endlessly prompting claude to fix bugs.Even with unlimited spend, it seems immensely beneficial to dig into the code base and fix a certain amount of bugs oneself. Oftentimes this is ends up being quicker than having to type out a detailed explanation of an issue in plain language, with the added benefit of maintaining intimate knowledge of the code base.
• Menu

  mvkel
  I'm not convinced that this matters anymore either. Knowing architecture was a vibe coding strength about three months ago. The modern models seem to handle it very well.
• chris_money202
  Feel like this has always been a problem, especially with large legacy codebases. Very few people ever knew everything. We just reach the problem faster now; it used to take years of churn and turnover.
• ttul
  You could say the same thing about the transition from assembler to C in the 1970s and early-1980s, albeit that was at vastly smaller scale of impact. It’s not that nobody knows _anything_. We still direct the machines, just in a different way. And if what comes out the other side satisfies our needs, does it matter what lies beneath?Tail risks have always existed in software development. The tail risk of a bug introduced by some dev who quit five years ago is similar to the tail risk of a bug introduced by Claude six months ago. Deal with it by building better visibility into how your systems work. Demand that your agents write good documentation to accompany their code-writing.If you’re doing it right these days, it means you’re thinking of a much bigger picture and containing downside risks as boldly as you’re expanding the frontier of upside opportunities.
• camdenreslink
  Why was the title of the HN post changed from the actual title of the blog post? I thought it was clear in its meaning.
• Menu

  runjake
  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. I recall another particularly large iteration happened when Windows NT 4.0 Server saw mass adoption. Suddenly, people who were effectively IT technicians were now sysadmins.Edit: grammar
• Menu

  benzible
  "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.
• ninjahawk1
  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.
• BiraIgnacio
  Agent Smith had it righthttps://youtu.be/JrBdYmStZJ4
• Menu

  nader
  I think there is definitely gonna be a shrinking of critical thinking as lots of people are gonna be lazy.
• piloto_ciego
  Has t this sort of thought been the constant refrain of every generation at the advent of new technology?
• mococa
  Companies will pay hard and high...
• Menu

  feverzsj
  The problem is always maintainability, which can only be achieved through human understanding of code.
• polalavik
  pretty AI-sympathetic vibes in this thread. I generally agree with the author despite everyones opinion (including my own) in this thread that AI can produce great code. Just becuase the code is good doesnt absolve the human-in-the-loop from understanding and clearly documenting and communicating what the system does.At the end of the day I'm not paying an engineer to send me claude all day. I'm paying someone to become an expert on a system, even if AI assisted. The product will be better if i have someone that deeply understands the system and where to point AI to. Someone that can understand the full big picture can also anticipate future needs - something AI cannot do at all.I'm in EE/embedded/FPGA work and you can make an absolute hell of a mess with AI in that world, so maybe everyones opinions are more based around front end software or something. I think people forget there are fields that do not have the huge data training base that frontend/backend software does. a large majority of good designs in FPGA are proprietary at big defense corps, not on stackoverflow and github.
• Razengan
  The Computer Chronicles – Word Processing (1983)https://www.youtube.com/watch?v=Jt0OoXluC8g at 4:08: 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.
• Menu

  simonw
  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.
• Menu

  badrequest
  The plural of anecdote is not fact.
• wuliwong
  >We’ve had to know everything about the product/business from day 1I 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. ¯\_(ツ)_/¯
• runarberg
  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.
• raflueder
  "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.
• _doctor_love
  > 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.
• Menu

  zzzeek
  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
• Menu

  khelavastr
  People don't get fired for dishonesty or persistent failure like you'd expect.
• joshAg
  This is almost the same as saying "The problem is not the fentanyl, but that everyone keeps getting addicted or dying." In a very literal sense, yes, absolutely. There is a way to safely use fentanyl. But from a holistic point of view, the way to do so is so specific (ie multiple medical professionals prescribing and possibly even administering and monitoring vitals afterwards) and limited that for the general public is much more useful to just say "It's unsafe to use fentanyl unless following instructions from your medical provider." There's absolutely a way to use AI for coding that doesn't result in not actually knowing about the produced code, but it's so damn hard to get that right and you won't even realize you've fallen away from that knowledge until it's too late.The point about PMs is I think illustrative of this issue. Yes, great PMs who actually understand the product they want to build and can then turn that into something using engineering teams as a black box system exist. But by and large, no they don't. A massive part of why waterfall fell out of fashion is because it turns out most orgs don't have and can't find PMs/PM adjacent people who can build that knowledge, and you can see how agile attempts to correct for this by turning a pipeline into an OODA loop. If you can prevent pipeline flushes, it will beat that OODA loop, but it turns out as an industry we can't actually prevent enough pipeline flushes for that to be the case and we can (for the most part) use that OODA loop to eventually iterate into something a paying customer might give us money for.Part of the issue is that we're treating the AI like it's just another compiler or static code generator. It's not. The reason they're not is because they require a complete specification of what to output, ie the code. That level of specificity is what allows engineers to mostly stop caring about the assembler and just stay in their higher level code (the main exception being extremely hot loops in places too complex for the compiler to optimize well) and legitimately be able to say they understand the code without ever looking at the compiler/linker output. The entire point of AI for code generation is taking an incomplete specification and turning it into a completed one. If you review and understand every line of output the way almost no one did even before AI was a thing, then you're not going to fall into the trap of not knowing anything about your system anymore. But at the same time, you're not really going to get much benefit from AI either, because you're just replacing time spent coding with time spent reviewing code. It might even take you longer to review than it would to just code it yourself (i think every senior engineer who's mentored a junior dev knows this exact feeling).To actually get the benefit from AI you have to let go of looking at the code output at all, because looking at that output is the slow part and because just looking and reviewing still won't give you the same knowledge as actually implementing. The passenger aviation industry handles the second issue by preferring/requiring manual control in critical areas (takeoffs and landing) and using simulators to extensively train for manual recovery outside of the abilities of autopilot. For developers the second bit is actually why reviewing AI output is a fool's errand - it will give you the false confidence in your understanding of the system. That doesn't mean we have to embrace vibe-coding or accept slop. It means changing the engineering process from one that deals with a deterministic system to a stochastic one. As an aside, I think this is why upper level managers and executive are leaning into AI code generation so hard - engineering was already a stochastic black box system to them.
• gspr
  This is the kind of stuff AI-skeptics have warned about daily on this very site for the last year or two. We are met with "you'll be left behind" and "you're just coping" and "the future is coming".This shit is blatantly obvious. And if people keep pushing and pushing for LLMs to generate things that are actually used directly, the problem will grow so large that most people will barely remember a time when their job was something that could be understood.This is why generative AI sucks.
• Menu

  behnamoh
  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.
• henrydoughty
  [dead]
• iamheretoo
  [dead]
• ramsaybolton
  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.
• Menu

  827a
  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.
• Menu

  PaulHoule
  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.