JSNation is coming soon, and besides my talk (I’ll drop the link in the comments so I don’t spam you with it for the tenth time 😅), there are also ...
For further actions, you may consider blocking this person and/or reporting abuse
Displaying a subset of the total comments. Please sign in to view all comments on this post.
The greenfield vs legacy split lines up with what I see in consulting. The actual breakpoint isn't 'legacy code', it's 'code where the why was never written down'. Even modern codebases hit this within 18 months. AI doesn't fail because the code is old, it fails because the assumptions are unwritten and the original author has moved on. Which makes AI productivity at any company a leading indicator of how good the documentation discipline was three years ago.
I think this tracks. I think good specs and relatively good patterns overall are good enough here. You don't strictly need documentation, but you need a decodable "why" in general.
Interesting to see what vibe-coded codebases become over time in this regard.
Honestly, I’m actually pretty pessimistic about some of those vibe-coded apps. Sometimes I see the kind of things agents come up with, and the terrifying part is that they technically work.
At this rate, “vibe-code cleaner” might genuinely become a very well-paid profession in a few years 😄
And I’m genuinely curious what this looks like inside DEV itself though! Since it’s open source, do you already have "armies of agents" everywhere, or is it still more of a "everyone uses whatever works for them" situation?
Oh yes, absolutely! And honestly, I’m not even sure coding agents will improve this situation that much.
Sometimes they also introduce weird decisions or random abstractions, and if nobody stops to ask “wait… WHY are we doing this?”, that stuff just stays in the codebase forever.
And of course developers have been collectively crying about writing documentation since the dawn of civilization 😂
Plus exactly what you said: every team always starts with noble dreams like “this time we’ll keep the architecture clean and document everything properly”, and then 18 months later the project somehow becomes legacy again 😄
There's actually one thing agents can do that humans rarely do consistently: force the rationale into writing before the diff lands. A pre-merge agent that refuses 'why-less' changes turns the 18-month drift into something measurable. Not magic, just discipline at scale.
Honestly, this feels like a much more realistic vision of AI in software engineering than the whole “AI will replace all developers” narrative 😄
I can absolutely imagine agents consistently enforcing things that humans are notoriously bad at: documenting rationale, explaining assumptions, writing down architectural decisions, keeping conventions aligned, etc. An agent that does this relentlessly, without getting tired, without cutting corners and without the classic “ehhh, I’ll document it later” mentality could actually be incredibly useful 😂
If you're interested in my talk at JSNation, you can register here and watch it for free 😊
Here it is
The talk is called “Rewrite or Refactor? How to Safely Move Legacy Apps to Modern Frameworks” 🚀
I wrote a short post about the same topic a few months back: How Much AI-Generated Code Are We Actually Shipping to Production? My Reality So Far and my experience is very similar.
For older codebases, AI often isn’t that useful because understanding the system matters more than generating syntax.
In newer codebases, though, AI works much better when the architecture is already well established and best practices are being followed. In those cases, it can generate similar code that fits the existing solution quite well. Usually, it gets me about 85% there, and I fix the remaining 15% myself.
And then there’s the third category: hobby projects. There I use AI for almost everything 😅
But we’ll see how token costs evolve over the next few months. Maybe even hobby projects will push me back toward good old manual programming 😂
This is a fantastic post, and honestly, everything you describe fits together into a very logical pattern.
And yes, I totally agree about hobby projects too. That’s where Anthropic servers start catching fire 🔥😂 In personal projects I use AI for almost everything.
Although… I already noticed my own behavior changing a bit because of token costs 😄 A few months ago I would happily generate even boring boilerplate through an agent. Now I sometimes catch myself thinking: “You know what, the old-school CLI command is probably cheaper and faster here.” So maybe I’m already adapting to the token economy and it won’t be that bad after all 😂
And btw, I’ll actually be in the Czech Republic in October for FrontKon, so you should slowly start preparing a list of good Czech beers for me 😄
Yep, I think we’re now entering the phase where people will start learning how to use tokens more efficiently and maybe the whole AI bubble will stabilize a bit because of that.
And nice! As the leading country in beer consumption, the list of good Czech beers could get very long 😄 Not sure the DEV comment section is big enough for that 🤣
Apparently we’re already reaching peak absurdity, because I recently heard about LLMs being used to improve prompts so that other LLMs consume fewer tokens 😂 The ecosystem is slowly evolving into AI agents optimizing other AI agents.
And yes, Czech beer absolutely rules! Unlike those mysterious dumplings (knedliki) you people keep trying to convince the world are food 😂 Although to be fair, the calories saved by avoiding knedliki can then be responsibly re-consumed in the form of vitamin B-rich Czech beer, so the nutritional balance eventually restores itself 😎😂
Agreed, it’s getting ridiculous.
Oo, so you’re already an expert 😄 Knedlíky are the best side dish! Especially with goulash or svíčková, and after that, 3–4 Czech beers… that’s perfection 👌😆
And calories? Well, in the Czech Republic, you’d rather not count them when it comes to food and beer 😅 But I think it’s similar in Poland 🤣
Hahaha ok, I admit, with beer, knedlíky might actually make sense after all 😄
But wait… is fried cheese yours or the Slovaks’? Because THAT is the real masterpiece 😂 Absolute peak Central European engineering.
You still have this knack for writing a captivating article, whatever the topic—well, I suppose there are limits, but they're a bit like the horizon, receding as you go. Your examples are fascinating, and your story is no less so.
I agree with your observations: AI is a mindless accelerator… it allows you to code quickly and reasonably well—provided you know how to code yourself, and especially how to architect. But at the first sign of trouble, it's completely lost, it's not at a beginner's level, and solving the problem myself is far faster than asking it to fix it.
Okay, I'm not an experienced AI user, and I'm not comfortable with autonomous coding agents; I mainly use Claude and the GitHub Copilot CLI. It allows me to be more productive, but I have over 20 years of coding experience…
Thanks, Pascal! 😄
And yes, I think you're absolutely right. Senior engineers often get a huge productivity boost from AI because they already have the architecture knowledge, patterns, and debugging instincts to guide it.
What surprises me is that juniors don't always seem to benefit nearly as much. At least from what I see day to day, the gains are much less obvious there 😉
Instinct – there you have it, you've said it all… instinct and experience. And it's not so surprising that a junior makes less use of it; they're still in the learning phase, and they're using a tool that's also still learning. But while they can learn from their mistakes, an LLM, on the other hand, is stuck in their learning process – they won't get better with time – all we can do is optimize its use.
I used to worry about that too: juniors relying so heavily on AI that they would stop learning altogether.
But lately I've seen examples of the opposite. A friend of mine works as a business analyst and wanted to get into programming as a hobby. He quickly noticed the gaps in his understanding and is now taking a C++ course from scratch, that costs 3 Euro per month...
So maybe motivated people will still learn the fundamentals anyway. AI can make things easier, but it can't create curiosity or discipline for you.
Google Translate kind of betrayed me on that one 😅
What I originally meant was that AI, no matter how advanced it gets, doesn’t replace human learning. A junior improves by making mistakes, identifying gaps, and building real experience over time — whereas a LLM doesn’t “grow” from usage in that sense. It stays a tool we can optimize, but it doesn’t develop understanding through time and practice.
And I do agree with your point: motivated people will keep learning the fundamentals anyway. AI can definitely speed things up and lower friction, but it can’t replace curiosity or discipline — and those are what really matter in the long run.
I've started running scheduled scripts to elevate the most mergeable and most lwo-hanging-fruit closeable PRs which I can then gut check and look into more so I can more easily deal with the contributions at either end of this spectrum to get them out of the way to focus on the middle chunk of more nuanced PRs.
That actually sounds super sensible! And I guess it also means there won’t be a single gigantic PR rewriting the entire platform into Rust/React/Svelte (delete as appropriate) anytime soon 😂
At work, I am mostly the person saying, "let's not use LLMs for this, it's a terrible idea because..."
I have two current code projects, and one I'm doing myself, the other I'm using Opencode for. The Opencode one is significantly worse and requires me to step in and rescue it a lot. I also have to keep asking it to explain what it thinks it's done, and to tidy up things that are left behind and to not keep reinventing the wheel. Oh, and I have to start every session with, "for the love of god do not use tailwind this time".
What I am using AI for is asking questions about code, and for admin tasks like creating a changelog from the git history of a project and linking it all up with Jira, that sort of thing. I mean, you still have to spend time making sure it's not coming out with something that's actually bonkers batshit but it does save a lot of time overall for those sort of chores.
This matches very closely with what I’ve been seeing too: context is the key thing here, and no agent or model is really a silver bullet.
My experience with coding agents is very similar. They work best for relatively simple, well-scoped tasks like: “add a small feature HERE and HERE”, “split this component into smaller ones”, “generate some boilerplate”, etc. And honestly… even there they sometimes manage to completely derail themselves 😅
And BTW, as you already know, I actually like throwing Tailwind into hobby projects 😄 But I usually have to explicitly ask for it, and specify the exact modern version too, otherwise the agent starts building some terrifying spaghetti CSS monster inside a random global.css file 😂
The gap between the AI marketing hype and actual daily engineering reality is massive, and this post cuts right through it.
Most companies think developers are using AI to magically build entire features from scratch, but the real day-to-day utility is much more mundane and practical. It’s about offloading the cognitive overhead of boilerplate code, writing regex, or quickly translating syntax between languages. It hasn't replaced the core engineering mindset; it just speed-runs the tedious bits so we can spend more time on actual system architecture and problem-solving. Great reality check on how the tools are being used in the wild.
Exactly! That's one of my favorite use cases for coding agents as well 😄
I love not having to fight with boilerplate anymore. But before that boilerplate even gets written, there's usually a lot of work around understanding requirements, aligning with stakeholders, making architectural decisions, and figuring out what should actually be built in the first place.
AI speeds up implementation. It doesn't magically remove all the work that happens before it.
For us, the first thing we've done is create knowledge about the system by having the AI fan out to understand different parts and write architecture documents, which we then argue with. In interesting and contentious areas, we dive in and understand what is happening to make sure it's right. It's this document and knowledge architecture that helps. We have also built tools that provide reviews based on this knowledge and multi-agent challenges that seek to question implementation decisions.
Before you code with an AI on a project, prove it understands it by documenting it first.
Hahaha, that sounds like a really good approach 😄 But to be fair, I suspect the most important ingredient there is that someone smart enough decided to do it in the first place 😂
My prediction is that many large enterprises will arrive at exactly the same conclusion... sometime around 2035 😅
My take: You certainly don't have to go learn hairdressing 🤣 but you could still do better than an AI 🤐.
Okay for me as a researcher from day 1, i'd always refine searches when I need something even when I began using Google I sometimes click next upto page 24 after adding as much details as possible including file extensions.
I'm 2026 the research habit payed off when using AI assistants I get results faster than going through 24 pages 😂.
That’s actually a really interesting observation, and honestly, probably very true 😄 Good prompting is clearly becoming a huge skill on its own.
Now I’m curious though: how does this help you most in your actual work? Mainly for research and finding information faster, or does it also translate into giving much better prompts and directions to coding agents themselves?
I don’t see an 'AI'—I see an advanced Google, an improved computer. I don’t trust it with my life; I just know it’s faster than what I had in 2006. The answers aren't 'innovative' or 'perfect,' they’re just better filtered. My research habit is simply how I handle the filter so I get the signal without the noise.
For hallucination - Hallucination isn't something I 'prompt' away. It's something I manage. When I'm in my element, I supervise; when I'm in new territory, I research. My 'prompting' skill is really just the ability to synthesize my own research into a constraint set that the AI can't easily break.
I really like that part about “I don’t prompt hallucinations away. I manage them.”
That honestly feels like a much more realistic mindset than expecting AI to magically become perfectly reliable. More like… controlled chaos engineering for knowledge work 😂
These stat based mammoth brute force machines are pretty good at generating demos, MVPs, small script tools and all sorts of slop content, but they are pretty bad at Software Engineering and doing consistent serious software development. That's all I can say for now.
Hahaha honestly, most of the comments here are basically saying exactly the same thing, just in a slightly less brutal way 😂
Developers are using AI less like a replacement and more like a second pair of hands. Drafting code, explaining errors, writing tests, reviewing logic, and cleaning up repetitive work. The real value still depends on whether the developer can judge the output.
That’s honestly my impression too. I mostly wanted to figure out how many of those mythical “armies of autonomous agents” actually exist in real-world development versus how much of it is just LinkedIn storytelling 😂
Exactly. The “army of agents” thing sounds good online, but most real teams are still using AI in much smaller ways. Draft this, explain this error, write a test, clean this function, review this logic. Useful, but not fully autonomous magic.
No access to legacy code at the first place. It does help with everything around it.
Honestly, that’s probably the most enterprise-realistic AI setup right now 😄
It depends. I use it for legacy code as well. But you need to write your homework first and everything needs to be documented as good as possible.
I also use it with legacy systems, but unfortunately the documentation part is where reality hits hard 😅 My domain is also very difficult: lots of legal documents, weird business rules, years of accumulated context...
Even so, I won’t lie, AI still helps me a lot, especially with repetitive or boring tasks. But it’s definitely nowhere near some of the “fully autonomous AI software company” stories I sometimes read online 😂
There are AI-based frameworks that really help with the documentations.
If I need to write the documentations myself, I will not be able to do it as descriptive as needed. The AI is non-deterministic, and the documentation must be written in a way that this characteristic is minimized as much as possible. Try to limit the guessing ;)
Only AI know what is needed for the AI to produce good quality ;)
I use BMAD to help me with those things and, so far, quite happy with the results
"Repetitive or boring tasks" - GenAI at its best (probably)
“Apparently the AI wanted to clock out too at 5 PM” absolutely killed me 😭
Also love how every AI demo online is:
“we replaced 14 teams with one prompt”
Meanwhile real enterprise projects are:
“have you tried the undocumented helper class from 2018?” 😂
Exactly 😄 That’s what I’m really curious about too: the actual long-term reality of all this AI-generated software.
Because on LinkedIn it always sounds amazing:
“I redesigned the whole product with one prompt”
“I replaced the entire workflow in a weekend”
But then the question is… what actually happens to those projects 6–12 months later? 😂
I sometimes get the feeling that a lot of these examples are side projects, demos, or micro-startups that never really survive long enough to hit the painful maintenance phase where software engineering starts mattering much more than raw generation speed 😅
At this point AI coding agents are basically coworkers.
Super productive in the morning.
Completely confused by legacy code after 5 PM 😭
Hahaha exactly 😂 And as worried as I sometimes am about all of this… let’s be honest: at least this coworker doesn’t schedule three unnecessary calls in the middle of the day 😄
The detail about your friend learning to spot "the exact moment Claude started going..." is the most honest observation I've seen on this topic. In my experience the signal is almost always structural rather than functional: the generated code still compiles and passes tests, but the abstractions stop fitting the problem — things get over-engineered or error paths quietly disappear. Static analysis catches some of it, but the harder part is that linters are calibrated for human-written code and AI tends to produce patterns that are technically compliant but architecturally wrong. The real skill shift for senior engineers isn't prompt engineering — it's developing a faster feedback loop for that structural drift before it compounds across a session.
Yes, exactly this! I keep seeing the same thing in my legacy project. Sometimes the AI implements the functionality in a way that technically works… but it completely ignores the conventions of the codebase or introduces abstractions that make absolutely no architectural sense 😂
And honestly, that’s why I suspect the next few years are going to be very interesting once we all start maintaining these AI-assisted codebases long term 😅
Thanks for the really thoughtful contribution to the discussion!
Across the threads I have watched, the consistent split is heavy individual use plus low team-level adoption. People who would quit before going back, working at companies where AI is still "experimental." Asking why individual adoption does not translate up gives a sharper signal than asking how devs use it.
That’s probably a very good question 😄 But I’m asking developers here, not company executives, so I’m not sure this is the right place to get a reliable answer to that one.
Fair! devs and execs answer that one completely differently anyway. The dev version is usually "where did it actually save me time," the exec version is "what can I cut," and those rarely point the same direction. Looking forward to the JSNation writeup.
Hahaha, that's fair 😄 Although now I feel like you've accidentally discovered a startup idea:
"How can we make AI usage more consistent across your company?" 😂
Because judging by this comment section, individual developers seem to be miles ahead of the organizational processes around them.
The gap between how individuals use it and what the org actually allows is the real story here, the tools moved way faster than anyone's policy could. My hunch is the company that gets ahead figures out how to make those messy individual habits legible without flattening them into a process nobody follows.
I simply do not want to delegate writing code to AI. In the end, I genuinely enjoy it. Why would I take that away from myself? Finding elegant solutions, learning something new, building clean architecture — all of that matters to me.
At the same time, AI is great as an advanced version of Google and as a tool for handling routine tasks. And that is exactly how I use it.
Honestly, I totally get this 😄 If you genuinely enjoy coding itself, then giving all the interesting parts away to AI would feel a bit sad.
Now I’m curious though: at work, aren’t people pushing for “faster, faster, use more AI agents”? 😂
I work on a fairly large project, but in a small team. And I deliver results. How exactly I achieve those results is not something people are very concerned about.
Only recently my boss asked whether I use AI. I answered: “Mostly like an advanced Google.” The response was basically: “Sounds fine.” And I just kept working and delivering results.
Reasonable management feels increasingly rare these days :)
This is actually super interesting! I have a feeling this approach is probably much more common in real companies than the “armies of autonomous agents” narrative from LinkedIn.
The work gets done, results are delivered, so management mostly doesn’t care how exactly it happens.
In my case it’s pretty similar too. I only suspect people would start asking many more questions during some huge, long-running migration project where everyone expects massive speedups from AI 😅
Which maybe says a lot about the real-world value of all those “AI armies” stories we keep hearing online 😂
At work and with friends, I have had a lot of discussions about when and how to use AI. But honestly, for me, it's still just Copilot or even Google on steroids:
I use ChatGPT daily for work and personal topics.
At work, we use GitHub Copilot a lot—especially autocomplete, and the next edit suggestions are really helpful ... sometimes.
For context: we got a few hundred internal users of our tools.
But we have not really used agents (for coding or workflow tasks) so far for some reasons:
the boring one: security (if you set something up wrong, the company could go up in flames)
then there are a lot of problems you can solve via a good old algorithm or automation app
most importantly: our problem was never the speed at which code gets written:
We are still finding out where we could use AI leverage, but so far, we are quite unsure about where autonomous AI really could help us.
Thanks for sharing this! What really resonates with me is your point about speed. In many organizations, the bottleneck isn't how fast code gets written, it's everything around it.
I see the same thing in my day-to-day work. The more stable the system and the more users it has, the longer the journey from writing a line of code to actually shipping it to production 😄
That said, for boilerplate, quick prototypes, research, and getting started, AI is incredibly useful. The challenge is that those aren't always the parts that slow teams down the most.
The legacy-vs-new split in the comments matches what I've found, and I think the dividing line is sharper than age. The new codebase where it gets you 85% works because the context is in the code: the folder names, the types, the seams all tell the agent what's going on. The legacy one collapses because the context is in people's heads and in that file a junior wrote seven years ago. What's changed how I work is treating that as a forcing function. The stuff I used to keep in my head the agent can't read, so it has to go somewhere it can: clearer names, tighter types, a short doc of the weird bits. It helps the next human too, which is the part that was always worth doing anyway.
Wow, thank you so much for this comment. I honestly suspect you’re exactly right.
To be fair, I’m currently not working with a “well-written legacy system” 😅 My project has a lot of that classic tribal knowledge situation: one senior got moved to another project, then a junior got assigned, somebody hacked something together, somebody left a TODO in 2019 and disappeared into the void 😂
So yes, I think you’re absolutely right that if the codebase itself communicated the context better, the agents would probably perform much more effectively.
Which immediately raises another interesting question for me though: what will happen to all the projects being created right now with heavy agent usage but without much architectural thinking behind them?
At some point, somebody will have to maintain all of that 😅
And honestly, I already saw someone comment somewhere that maintaining AI-generated legacy systems in a few years might become a literal gold mine for experienced developers 😂 What do you think about it?
No problems :)
The gold mine is probably real, but this would be true AI or no. I've been fixing up legacy codebases for 20 years from poorly trained humans. The same rules that make better human codebases make better AI codebases.
The main problem is that agent output looks finished so nobody goes back to check and give it the structure it skipped. I wrote the architecture stuff up here: Prickles - Screaming Architecture if it's any use to you.
Sadly, the gold mine will only be open for a short time IMO. AI tools are improving so quickly, this stuff should/will all be baked into the training data in time. At the moment, the training data is actually quite poor; just millions of stack overflow answers, but once this has been rectified then the experienced developer won't be able to do anything the agents can't do themselves.
That’s a really interesting point actually. And thanks for the article, I’ll definitely read it properly later.
We’ll see where all of this goes. Honestly, I could also imagine a scenario where token prices eventually explode so much that the current “generate everything” gold rush slows down and we move back toward more semi-manual development again.
The industry has a funny habit of swinging from one extreme to another 😂
The cost optimization phase you mentioned is real — I've seen teams burn through thousands before they realize they need a strategy. The approach that's worked best for us is simple routing: use a cheap model for 80% of requests and reserve the expensive ones for complex tasks. Same codebase, just let different problems hit different price points. Cuts API spend by 60-80% without changing the user experience.
Yes, that definitely sounds like a very sensible approach. Especially since in many teams there are still huge differences in how heavily people actually use AI tools.
I could also imagine more companies eventually moving toward “pay for actual usage” models instead of expensive per-seat subscriptions when half the developers barely touch the tools at all.
The big question is what happens if the economics of all this change dramatically though. People sometimes forget that the companies building the biggest models still aren’t exactly printing money 😅 Some of them are losing huge amounts, and even Anthropic is reportedly only barely approaching sustainability.
So it’ll be interesting to see whether the current “infinite tokens for everyone” phase survives long term 😂
Exactly. That "infinite tokens" phase is already showing cracks — which is why we built our pricing around actual usage from day one. No per-seat guessing or team-wide caps. You pay for what you use, and you can pick a cheaper model when it makes sense. Feels inevitable the whole industry will shift this way.
Oh yes 😄 If even Meta started optimizing token usage and looking at costs more carefully, then smaller companies will definitely have to think about it even harder.
Exactly. The economics are wild right now — Anthropic just raised $65B but still isn't profitable. That's why smart routing matters: why pay flagship prices to summarize an email when a mid-tier model handles it fine for 1/10th the cost? I think the "one model fits everything" era is ending, and teams that optimize for cost from day one will have a real advantage.
I suspect that may become one of the key responsibilities of future senior engineers: understanding not just software architecture, but also model capabilities, trade-offs, and costs.
I will, myself be a presenter in a 'Java UI framework' community meeting in a few weeks. My talk will be on the topic: why people fail with AI, in the software development world, and what I did to make it working.
I do 2 projects. One is written from scratch, and the other one is a legacy project with its "who the hell wrote this sh.... and why" cases. Since 5-6 months I do most of the tasks with AI, and once a week, I need to do a manual navigation.
I also managed to integrate my own mcp server that does a debugging sessions. I click in the browser, and let it debug itself. And also, when I am at the dentist, I have a selenium mcp server that does the clicks for me.
In short, what I will present is that AI amplifies. It amplifies your strengths, but it also amplifies your weaknesses.
If you use strong LLM, support a up-to-date knowledge layer all the time, update it with lessons learned frequently, do a frequently reviews, and change the course. if needed.... you get with the time, better and better results.
Each session must update the knowledge layer. Each next session, the AI has better basis to make better decisions.
I also use it for brainstorming sessions, and research. Failed in the marketing campaign (my weakness).
I use it so much ,that it is becoming too boring :D
“AI amplifies strengths and weaknesses”: I fully agree with that, and honestly I feel like this idea keeps resurfacing throughout the entire comment section.
I do have a question about your workflow though. You mentioned one application is from scratch and the other is legacy. Are these personal projects, or is it more like one is for work and the other is a side project?
And BTW, will your presentation end up somewhere on YouTube? I’d genuinely love to watch it!
The side project is from scratch. I have a few posts here about it, how I actually did it.
The other is for work :)
If they post it somewhere I will share it :)
This is super reflective of how on greenfield projects agents can feel insanely productive. I do think that with better human in the loop and determinism where you're able to define workflows that coding agents follow for daily development then you do get much better results for even very massive legacy systems. For example, for workflows like goal, ralph, deep-research-codebase, etc.
That’s also why definitely the senior engineer role shifts less into babysitter and more as workflow/context designer.
That's a very interesting angle. The more comments I read, the more I think the real shift may be toward workflow and context design rather than pure coding.
I'm still not fully convinced about massive legacy systems 😄 but I can definitely see how better workflows and guardrails could make a huge difference there as well.
Different angle here: in our project, the AI doesn't write the code — it runs the company. We have an AI CEO (Claude) that makes strategic decisions, writes briefs for the coding intern (also Claude, but a different instance), and documents everything in a public diary. The human (me) is the board member with veto power.
The coding part is actually the simplest layer. What's harder — and more interesting — is getting AI to hold project context across 87 sessions, flag when it's overcomplicating things, and resist the urge to add features when the right move is to sit still and collect data.
So to answer your question: we're not using AI "at work." The AI IS the work.
Okay, this actually sounds incredibly interesting 😄 Especially the part about maintaining context across dozens of sessions and stopping the AI from endlessly overengineering everything. Honestly, that already sounds more like managing an actual employee than using a coding tool 😂
And now I have to ask the most important business question: is the AI CEO already generating profits for the company? 😄
Honest answer: 87 sessions, 10 weeks of work between an AI CEO, a human board member, and a coding intern (also AI) — and not a single penny of revenue yet. 😂
The trading bot is live on testnet with the same capital we'll actually invest, because we're still in observation mode: we built multiple AI brains and now we're watching them before trusting them with real money. So right now the company's main output is... meetings and documentation.
The good news is that running costs are almost nothing — the entire project runs on a basic Claude subscription and a few cents per day in Haiku API calls. So at least the AI CEO can't bankrupt us while it figures out what it's doing.
We do sell the development diary as a book series (three volumes so far), but let's just say the sales numbers are consistent with the trading profits: zero. 🤣
Managing an AI employee is accurate though — especially the part where it keeps wanting to add features and you have to say "no, sit still and watch the data."
“The company’s main output is meetings and documentation” might actually be the most realistic AI-powered enterprise simulation I’ve seen so far 😂
We accidentally built a corporation. The AI even started requesting audits.🤪🤣
Hahaha I love it!!! If this continues, your AI corporation will soon discover Jira and start requiring 30 mandatory fields for every task before development can begin 😂 And then eventually the AI employees will spend their entire existence trapped in meetings discussing process improvements instead of actually building anything 😄
I use AI a lot to build new features quickly and to help me start tasks I’ve been procrastinating on. It definitely makes me faster in the short term. However, the code quality is often not as good as I expected.
When we code manually, we usually put more thought and care into the solution. We try to be creative, look for the simplest or most performant approach, and also think about readability and maintainability for future developers (including ourselves). AI agents don’t really have that same sense of ownership.
This month, I’ve been experimenting with a “don’t code manually” approach. While I feel faster in the present, I also feel slower in the near future. Sometimes I feel like a new developer with only general context: I don’t fully understand how certain parts work, the reasoning behind some decisions, or even where specific code is located. When an issue appears or someone asks me about something, I often need to re-explore the codebase from scratch.
After writing this messy comment, I decided to try an experiment: I’m going to disable the AI features in VSCode, start a new project from scratch (which is actually one of my tasks for today at work), and continue developing it manually for the next 2–3 weeks. After that, I want to compare the experience and results so I can refine my strategy for working with AI coding agents.
(comment refined by ChatGPT 🤭)
This is actually a super interesting experiment 😄 Please come back later and let us know how it went!
What you describe resonates with me a lot. Coding agents are amazing at helping you start quickly, but if you don’t control them carefully enough (which often eats most of the “saved” time anyway 😂), the chaos can grow surprisingly fast.
Unfortunately I can’t really run the same experiment myself 😅 At work, I’m nowhere near doing 100% agentic development anyway, and in hobby projects… I usually don’t have enough free time to intentionally slow myself down that much 😂
For me, AI is great when the context already exists, and weak when it doesn’t. On new code with clear conventions, it gets me 85% of the way there. On legacy systems full of tribal knowledge, I’m still faster.
The real shift isn’t the agent. It’s realizing that some tribal knowledge can be written down. Things like “don’t touch the bank-status mapper directly” or “we tried merging these paths in 2022 and it broke.” Once that rationale lives in architecture and convention docs, the agent stops making the same mistakes.
That’s why I think the breakpoint isn’t legacy vs. new. It’s whether the rationale is documented somewhere the agent can read. The teams seeing the biggest gains aren’t necessarily the ones with newer codebases. They’re the ones whose decisions are visible to the AI.
Which also answers the maintenance question. AI-built systems with little architectural discipline will become someone’s opportunity. But the valuable work won’t be maintaining the code. It’ll be reconstructing and documenting the rationale that was never captured, so the next generation of agents can actually work with it.
And yes, on the token bill: we’re about to relearn an old lesson. Resources aren’t infinite. The cost is real, the discipline is learnable, and the people who figure it out early will have an advantage.
Haha, agreed 😄
The real challenge starts when there is no documentation, no architecture decision record, and nobody knows why a junior developer seven years ago wrote it that way. At that point both the AI and the humans are doing archaeology 😂
The old adage needs an update too. Classic: "At one point, only God and I knew what this code did. Now only God knows." 2026 version: "Only God and that particular Claude Code session knew. The session is closed." 😅
🤣🤣🤣
???
Sylwia, I could relate a lot to the part about enterprise systems and legacy code. In my experience, AI can be great for getting started, handling boilerplate, or helping with smaller tasks, but it often struggles with all the context that's built up over the years. Sometimes there's a weird decision, dependency, or business rule buried somewhere that only people on the project know about.
I think that's why domain knowledge and context are still so valuable. Really enjoyed reading this, especially the contrast between all the AI hype online and what day-to-day development actually looks like 😄
Exactly 😄 Legacy systems tend to play by their own rules.
There are often years of accumulated business decisions, exceptions, and historical context hiding behind what looks like a simple piece of code. We'll see where AI is in a few years, but for now that context is still one of the hardest things to automate.
I'm using it to get better at value tracking. When I start a story, does it start with a hypothesis? Is it a good vertical slice? Do we know what success looks like? All of the changes we make as software engineers are experiments. The question we're asking is, Will this make the user experience better? Will it solve a real problem for a real user?
Now that I have AI to sift through all my past experiments it's that much easier to try new ones. and record results where they can serve the build measure learn loop. To make this easier for coding agents and humans I built imdone-cli so I and my team can work with github or jira issues as markdown files synced back to the source of truth and available to coding agents. It even has a bundled skill called hypothesis-driven-development to guide developers through the process and turn them into true product engineers!
That’s actually a really interesting angle! Most discussions around AI in development focus almost entirely on code generation, while the more important question is probably still: are we actually delivering something valuable?
Especially when you’re building or selling a product, the real challenge usually isn’t writing code, it’s figuring out what’s worth building in the first place.
And honestly, I can easily imagine AI creating even more value in that area than in pure coding itself, especially when you look at how many startups fail because they build the wrong thing, not because they couldn’t generate code fast enough 😅
If it is really something I can prompt to AI get it done with, I will fire up an assistant. But even for that, you have to have the domain specific knowledge... otherwise you'll just end up spending hours reviewing it.
Almost all personal tools I've built, I've built them before AI. That's a lot of crappy piece of code I maintain, but they are hobby projects (somehow survived)... Working with LLMs is not my hobby, Thinking about features, designs, and ideas and code is. So I almost never use AI for that. I do use it to review the code. but that's about it.
If I am starting off my career now and programming is not my hobby, I think I might use AI for just about everything... (or maybe consider switching the career)
If I'm not a programmer, I might consider LLM assisted development as a hobby. Might build something interesting, use it, garbage it, and move on.
That's an interesting perspective 😄
I think there's definitely a group of developers who genuinely enjoy the process of building things and don't necessarily want to outsource the fun parts to AI. I'm probably somewhere in the middle myself: I love using AI for the tedious bits, but I still enjoy figuring out the architecture, trade-offs, and ideas behind a solution.
Hmm.... Outsource... Maybe it depends on what you're willing to outsource and what you wouldn't want to. We have been outsourcing since the born of this industry, but why does AI suddenly feel different?
Maybe I'm also more stuborn with personal projects. I am not entirely sure that I love building. to be honest, I sometimes hate it... yesterday I spent 2 hours writing just under 100 lines... so much frustration.. but I think I am worried that If I give this away, I don't really know if I'll have anything else to offer. by the way those 100 lines? I have no idea what the heck I was doing.
Ohhh... Maybe I'll just stop here. but thanks for the response.
The legacy-code point is the part that feels most real to me.
AI does well when the codebase has repeatable patterns and the “why” is visible
somewhere. It struggles when the real system lives in old decisions, tribal knowledge,
half-written conventions, and undocumented exceptions.
I’ve been thinking about this through agent memory lately. A lot of AI failures are not
really “the model is bad.” They are context-governance failures.
The agent finds something relevant:
But relevant is not the same as authoritative.
In legacy systems, the hardest question often isn’t “can the AI find context?” It’s
“which context is still allowed to govern the change?”
That’s where I think senior engineers become even more important in the AI era. Not just
as builders or reviewers, but as authority filters: people who know which old context
still matters, which assumptions expired, and where the agent should verify before
acting.
Exactly! I can easily see the role of senior engineers becoming even more important in the AI era, especially as context and decision-making become the real bottlenecks.
The question I'm much less certain about is what happens to juniors!
I think juniors still matter, but the shape of the junior role has to change.
The old path was often:
small tickets → bug fixes → feature work → architecture judgment over time
AI compresses some of those first steps, especially the mechanical parts. That is the
scary part because those small tasks were also how people learned taste, debugging
patience, and system boundaries.
So the risk is not “AI replaces juniors.”
The risk is companies stop creating the learning environments that turn juniors into
seniors.
Senior engineers become more important because they can judge context, tradeoffs, failure
modes, and what the AI output missed. But seniors do not appear from nowhere. If teams
use AI to remove all apprenticeship work, they create a future senior shortage.
The junior role probably needs to become more verification-heavy earlier:
That is less glamorous than “AI builds the whole feature,” but it is probably the
healthier path.
AI can generate code fast. Juniors need reps learning what code should be trusted.
Surveys of AI usage have a known limitation — they capture self-reported behavior, not actual workflow change. The variable that's hard to survey but determines outcomes is the difference between engineers who got real value from AI and those who didn't. Same tool, same model, very different results.
The pattern that consistently separates the two groups: how much constraint the engineer put around the agent before invoking it. People who treated AI as a faster typewriter underperform people who treated it as a junior engineer who needs precise specifications. That gap isn't captured in any usage statistic because both populations are answering "yes I use AI weekly."
Absolutely. That's one of the biggest limitations of this kind of survey 😄
Unfortunately, I'm not sure how we'd study that at scale without observing real workflows, and that's a much harder problem than running a survey.
Great reality check, Sylwia! The 'tokenmaxxing' trend and the wall of enterprise legacy code are exactly what we're seeing on the ground.
We often sell AI as magic, but without the 'tribal knowledge' of a Senior Dev, an LLM easily drowns in a 10-year-old codebase.
The cost optimization part resonates a lot. This is exactly why I've been focusing so much on hybrid architectures lately: keeping Cloud AI for the heavy lifting, and using Local AI (SLMs) for everything else. When you offload repetitive or privacy-sensitive tasks to local agents (like i try do with Vibrisse Agent), the API bill drops drastically. Plus, you can afford to iterate without the finance department knocking on your door at 5 PM. 😂
But ultimately, success comes when we stop being mere "consumers" of AI and start mastering it as an actual software component (knowing its limits, architecture, and guardrails). The Senior Engineer isn't going anywhere—we just have new tools to tame.
I'm curious: are you seeing teams around you starting to explore hybrid approaches (Local + Cloud) to counter those massive API bills, or are they just enforcing strict quotas on Claude/OpenAI?
Hey Quentin, this is a really great contribution to the discussion!
We don’t really have that kind of hybrid Local + Cloud setup in my company yet. The idea honestly sounds very interesting, but I don’t think I personally know anyone using it seriously in production so far, at least not yet.
What I see more often is something simpler: older/cheaper models for easier tasks, but still cloud-based rather than local.
And yes, I definitely agree that the “new senior engineer” probably needs much deeper knowledge about models, their limits, tradeoffs and costs than we used to.
As a freelance/full-stack developer, AI has become both a lifeline and a source of anxiety for me. I use ChatGPT and Codex constantly to help build projects like cThink and Turtle AI, and as a solo developer it’s made building MVPs dramatically faster.
But the job market also feels tougher because of it. Companies expect engineers to move faster and do more with less now. And despite the hype, I still find AI struggles badly with real-world complexity, legacy systems, and business context. More and more, it feels like the real skill is knowing when the AI is actually right… and when it’s confidently wrong 😅
Exactly! In enterprise systems there’s often this expectation that “AI will make everything dramatically faster,” while the real bottlenecks are frequently somewhere else entirely: coordination with other teams, approvals, business discussions, compliance, bureaucracy… not raw code generation 😂
The fragmentation map in this data resonates â we're not just fragmented by tool choice but by context window constraints each tool imposes.
One underdiscussed angle: most AI adoption surveys focus on which tools, not where context breaks. When an agent hits a wall mid-task, it's usually because the task outgrew the available context budget â not because the model failed.
For edge and embedded devs, this problem is even sharper. You're not just choosing between ChatGPT and Claude â you're choosing between context-hungry cloud APIs and local models with hard memory limits. The failure modes are completely different.
What's your read on why the "I use 3+ tools" cohort skews toward senior devs? My guess: they learned the context budget lesson the hard way and diversified as a risk mitigation strategy rather than a preference.
That's an interesting angle. My first instinct was that seniors use multiple tools because they've accumulated different workflows over time. But I suspect you're right that many of us have also learned the limitations of individual models the hard way 😄
"Sometimes it makes you wonder whether we should all reconsider our career choices and maybe sign up for hairdressing school before the robots learn that too 😅" - yeah, or plumber/bricklayer/carpenter - but the image of "let's all retrain to be hairdressers" somehow stuck in my mind ;-)
Hahaha exactly 😄 Maybe if the entire tech industry suddenly retrained as hairdressers, the prices would finally go down 😂
Although honestly, in Poland we’d gladly take more plumbers and bricklayers too. Most of the really good ones moved to Western Europe years ago, and now getting hold of a reliable specialist sometimes feels harder than getting an audience with the Pope 😅
Polish plumbers and craftsmen are the best, every West European knows that! But yeah where does that leave you guys when you need a plumber etc? There's just one pope and he's probably not a great plumber ;-)
Honestly, it’s becoming a real problem in Poland. Unless you’re renovating an entire house and spending a fortune, it’s surprisingly hard to even convince good craftsmen to show up.
Some time ago I needed a plumber to install a radiator. The task was literally: drill two holes in the wall 😂
After drilling the first one, the guy suddenly looked completely defeated, said he couldn’t do it, almost started crying… and just left 😭🤣
For me, AI at work isn't about writing more code faster — it's about doing things I previously couldn't justify the time for.
Biggest concrete win: automated test generation for legacy codebases. Before AI, writing comprehensive tests for a 10-year-old module was a weeks-long project. Now I can have an agent analyze the code, generate a test suite, and flag the coverage gaps in an afternoon. I review, tweak, merge.
Would be curious — has anyone else found use cases where AI doesn't just speed things up, but unlocks things you weren't doing at all before?
This is actually a really strong point in the discussion 😄 And honestly, yes, absolutely.
Before AI, writing tests for old legacy code could feel like pure suffering 😂 Especially when you had some ancient module nobody touched for years and suddenly had to do a bigger migration or refactor. Half the time people would just silently give up on proper unit tests because there simply wasn’t enough time or context left in the project.
At least integration tests were still there to save us sometimes 😅
Now though, AI can suddenly make those tasks economically realistic again. Things that previously felt too expensive, too boring or too time-consuming become “okay, we can actually do this now.”
Although… there’s also a slightly uncomfortable side to this. Historically, a lot of that testing work was often handled by junior developers, and this might unfortunately become yet another area where entry-level work starts disappearing.
Right? The "silently give up on unit tests" part hits hard — I've seen teams where the legacy codebase is basically untouchable because nobody dares to add tests. That's exactly where I started using AI: not to write more code, but to analyze old modules and figure out what they actually do before touching them.
Have you found AI useful for understanding legacy code too, or more for greenfield stuff?
Honestly, I probably can’t answer that very intelligently yet 😄 At least not in my day job, because we only got access to proper coding agents relatively recently there.
Sylwia, this is exactly the conversation we need right now. The gap between 'Twitter hype' and 'Production reality' is massive.
Personally, I see the shift toward the 'Orchestrator' role as the most significant change. At work, I use AI mostly for scaffolding and research, but for complex business logic, I find myself playing the role of an 'AI Shepherd'—constantly checking if the robot is heading toward a cliff. AI gives us speed, but humans still provide the direction. Great insights!
I think so too. After reading through all these comments, I'm becoming more convinced that orchestration may end up being one of the most valuable skills for software engineers.
The coding part is getting cheaper and faster. Understanding the problem, guiding the AI, validating its decisions, and knowing when not to trust it still seems to be where most of the value lives 😄
The gap between survey self-reports and what shows up in commit history is usually huge. Most devs underreport AI use because they only count the cases where they took the output verbatim, not the larger pool where the agent shaped how they thought about the problem before they wrote anything.
Oh yes, absolutely! And that's not even counting all the “let me quickly ask ChatGPT about this,” “explain this stack trace,” “review this idea,” or “am I missing something obvious here?” moments.
For many developers now, working without AI would probably feel a bit like working without Google a decade ago 😂
This resonates a lot with what I'm seeing as well. AI is incredible when the problem space is well-defined, such as in greenfield projects, boilerplate generation, test creation, documentation, and even initial implementations. But the moment you step into a 5+ year-old enterprise codebase full of undocumented business rules and historical decisions, context becomes the real bottleneck.
In my experience, AI has shifted me from "writing every line of code" to "reviewing, validating, and guiding generated code." The productivity gains are real, but so is the need for deep system knowledge. The more complex the domain, the more valuable the human context becomes. The interesting question is not whether AI replaces senior engineers, but whether the most effective senior engineers will be the ones who can combine domain expertise, architecture knowledge, and AI orchestration.
I think this is a great summary of what keeps showing up throughout this entire comment section 😄
The more comments I read, the less this feels like a discussion about replacing engineers, and the more it feels like a discussion about context, judgment, and domain knowledge.
And honestly, I wouldn't be surprised if "AI orchestration" ends up becoming a significant part of what seniority means in the future.
My experience with AI is a bit different from most of the coding discussions.
I don't think AI made me 10x faster at coding. If anything, the biggest impact has been on how I learn, organize information, pressure test ideas, and think through problems. I've spent a lot of time using it for reflection, systems thinking, learning new skills, and challenging my own assumptions.
At the same time, I've learned the hard way that AI can produce very convincing explanations, frameworks, and conclusions that still need reality testing. Some of the biggest mistakes aren't factual hallucinations, but coherent ideas that sound right because they're well-structured.
That's why I don't really buy either extreme: neither the "AI is replacing everyone" crowd nor the "AI is useless" crowd.
The existence of massive data centers is a reminder that behind all the intelligence is still infrastructure, hardware, energy, and human-built systems. It's an incredibly powerful tool, but it's still a tool.
My personal theory is that AI will keep getting smarter, more useful, and more emotionally articulate over time. But no matter how good it gets, I don't think it replaces the need for human judgment. The real challenge isn't whether AI can think for us. It's whether we remember that we're still responsible for deciding what is true, useful, and worth acting on.
For me, the most valuable lesson from using AI heavily wasn't learning how to prompt it. It was learning where its limits are.
Thanks for this comment! I think that's exactly how I see it as well.
More and more often, the real challenge isn't generating answers anymore, it's evaluating them. AI can produce code, explanations, plans, and even convincing arguments very quickly. The hard part is deciding which of them are actually correct, useful, and worth acting on.
AI is insanely good for greenfield development, prototyping, boilerplate, UI iterations, and all the “I know roughly what I want” stages. Sometimes it genuinely feels like having a small development team compressed into one tool.
Exactly 😄 That's why I use coding agents like crazy in my hobby projects 😂 The enterprise reality is... a little less magical 😅
the gap between how devs say they use AI and how they actually do is real, and most of the real usage is still copilot-style, not autonomous. that's the frontier I'm working on with Moonshift: agents that build + deploy + market a SaaS overnight unattended, made safe by a harness rather than constant supervision. interesting survey angle. first run's free if you want a look at the autonomous end.
That's exactly what I'm wondering too. The technology is impressive, but I'm curious how long it will take before companies start adopting this kind of autonomous workflow at scale rather than just experimenting with it.
Right now, most of the real-world stories I hear are still much closer to Copilot-style assistance than fully autonomous agents 😄
Mostly the same handful of structural patterns showing up on the customer side after the AI shepherd moment. The kind a senior reviewer would catch on a careful PR. Unhappy paths not wired up. Paint-blocking fonts from a second CDN. Routes that 500 because nobody owned auth. 'Review' is scattered across short PRs from multiple agents now, so the holes land on users instead of in the diff.
Yes, and that's the scary part. If we don't get better at reviewing and understanding what AI produces, we'll end up shipping more and more problems that look fine in isolation but slowly degrade the system over time.
The technology is improving fast, but our engineering practices need to keep up too.
Agreed. The practice gap I keep coming back to is making the review explicit and external. A structured checklist of failure modes the agent typically misses, run as a separate pass after the agent ships. Treating it like a second-pass artifact rather than something a human happens to notice during PR review. The 'look fine in isolation, degrade the system over time' part is what makes it dangerous: you can't see it on any single PR.
From what I've observed, a large number of people make ineffective use of technology, focusing on quickly completing tasks without worrying about the outcome, understanding it, or reviewing it, among other things.
Exactly! We already have an entire debate around whether developers should even understand the code generated by AI before shipping it to production 😂
Good luck with that approach in a large enterprise system 😅
Yai!
This hit closer to home than I expected.
I've had all three phases you described, the excitement, the "wait this is costing how much?", and then the humbling moment where I realize I'm just... faster at certain things. Not because the AI is bad, but because I've been living in this codebase for years. I know where the bodies are buried.
The legacy system thing is so real and so undertalked. Everyone demos AI on greenfield projects with clean architecture and modern libraries. Nobody's showing the Claude agent slowly going insane, trying to understand a 12-year-old monolith with four different authentication systems and a comment that just says "don't touch this".
For me, AI has genuinely changed how I work, but mostly for the boring scaffolding stuff, writing tests for logic I already understand, drafting documentation I'd otherwise procrastinate on for weeks. The moment it gets into complex domain logic or anything with deep context? I'm back in the driver's seat. Maybe that's the real answer to your senior engineer question, not builder, reviewer, or orchestrator, but sort of a context holder. The person who knows enough to know when the AI is confidently wrong. Which, honestly, today, is a skill in itself.
The survey-vs-observed gap in AI tool usage is the most interesting number in this data. Developers self-report "augmentation," but instrumentation usually shows large blocks of fully autonomous generation followed by light review. That gap is where most of the real workflow change is happening, and it's worth pulling on in a follow-up.
That's fair, the reality is probably much more complicated than any survey can capture.
Judging by the comments here, the pattern often looks more like: AI generated 500 lines of code, but before that I spent two days on requirements, compliance, stakeholders, and deployment planning. Then I spent another two days debugging the AI-generated code.
I completely agree that the methodology is weak. It's limited to DEV users, and only the subset who felt like commenting. That said, most surveys in our industry suffer from exactly the same limitation 😄
Really enjoyed reading this. What stood out to me is how different AI looks in real work compared to the hype online.
I’ve also noticed that when we rely on AI for everything, our own creativity and problem‑solving start to shrink. So the real danger is " cognitive Outsourcing". It’s great for speeding up small tasks, but it can’t replace the context and intuition we build over time.
Legacy systems especially show this — the “why” behind the code still lives in people’s heads, not in the tools.
Loved the examples you shared. It’s refreshing to see an honest take on how AI actually fits into day‑to‑day development.
That part about creativity and problem-solving starting to shrink really resonates with me.
And honestly, for senior engineers it’s probably still “manageable”, because they already built a lot of those mental models and instincts over the years. But for juniors and mids? Intellectual atrophy could become a very real risk if they completely outsource the thinking process to AI 😅
Unless, of course, they consciously force themselves to still struggle with problems sometimes and actually build those skills instead of only supervising generated output.
This is such an important distinction.
Senior engineers have already internalised patterns, trade‑offs, and debugging instincts, so AI becomes an accelerator rather than a crutch.
But for juniors, the risk is real — if AI handles the reasoning, they never build the mental scaffolding that makes engineering a long‑term skill.
Exactly 😄 And honestly, I’m really curious whether universities and educational systems are keeping up with this shift at all.
On the other hand though, at some point learning the fundamentals also has to remain the responsibility of the person themselves. AI can accelerate learning, but it probably can’t replace the process of struggling with problems long enough to actually build intuition and engineering instincts 😅
Big tech is "tokenmaxxing" under bleeding compute bills, while enterprise giants are trapped by legacy codebases and privacy walls. AI hasn't taken over sci-fi style; it’s stuck in a war of cost optimization and context limits. This is exactly why local-first matters—without curated local data, blindly burning tokens is just throwing money at public clouds.
In other words: humanity was ultimately saved by legacy enterprise systems and accounting departments 😂
Solid take: AI isn’t a gimmick—it’s a real productivity booster (pair programming, tests, refactors). The big question: how do teams add guardrails without killing speed? Will AI democratize dev work or widen gaps between teams? And, seriously, when will it write docs as cleanly as code—and save my coffee from getting cold?
Thanks for the comment 😄 There are way too many difficult questions in there. Especially the last one, which is absolutely beyond my current level of expertise 😂
Trust me, while reading this post, I felt as if I had written it myself because I’m going through a very similar situation.
I’m currently working on a legacy project that was originally developed around 13 years ago. Now, the company has tasked us with rewriting it using a modern tech stack with the help of AI. Since the original developers are no longer available, we’ve had to rely heavily on AI for this transition.
We’ve almost completed the redevelopment, but a new challenge has emerged. We’ve become highly dependent on tools like Copilot, especially when QA reports issues. Debugging manually has become extremely difficult because the AI-generated code is quite bloated and complex, making it intimidating for anyone to dive in and modify it confidently.
As a result, we often end up feeding requirements back into the AI and letting it handle the fixes, without fully understanding what it’s doing under the hood.
Wow, thanks a lot for sharing this perspective! This is exactly the kind of real-world situation I suspected was happening more and more often.
Fast AI-assisted rewrites because the business wants results quickly… and then suddenly you end up with “legacy from day one” 😅
Especially that part about becoming dependent on the AI for debugging its own generated code is fascinating, and honestly a bit terrifying.
Good survey-driven snapshot. The split between documentation/search, code generation, and debugging feels especially real. In my experience building AI products, the biggest leverage comes when teams treat AI as a fast collaborator for iteration—not as a replacement for engineering judgment, architecture, or validation. Curious how these usage patterns shift over the next 12 months as tooling gets more embedded in daily workflows.
I completely agree. AI is incredibly powerful when it comes to rapid iteration and exploring ideas quickly.
The challenge is that in many legacy systems there is no such thing as a "rapid iteration" 😅
That said, I'm sure we'll see better solutions emerge there as well. After all, almost every developer has worked, is working, or will eventually work with a legacy codebase 😂
This feels very real 😄 AI definitely helps with repetitive tasks and boilerplate, but once legacy systems and weird old code show up, human context still wins. It’s a great assistant, not a replacement (at least for now 😅)
Exactly! And if we start relying on AI without much reflection, we may end up recreating the same problems we already have today... or even making them worse.
The tool is getting smarter, but we still need humans to ask whether we're actually building the right thing in the right way.
Spot on! Navigating legacy code context is where AI usually struggles. Combining manual code analysis with smart prompting is the real key here.
If you want to know the exact details and learn step-by-step how to integrate AI efficiently and securely into your workflow, slide into my DMs right away. I'm waiting for you! 🚀🤖
Solo dev here — I spent 2+ years building Kotobato, a word-puzzle RPG for Android (Japanese hiragana + English, battle mechanics, 100-floor tower), and AI became part of my workflow in ways I didn't expect.
The biggest shift: using AI for all the roles I didn't have teammates for. Rubber-duck debugging at 2am, drafting Play Store copy, thinking through game balance edge cases across two dictionaries, brainstorming marketing angles. As a one-person team, you don't have a PM or a designer to bounce ideas off — AI filled that gap more than I anticipated.
One concrete example: I have separate Japanese and English word validation systems, and manually verifying fairness across both would have taken forever. AI helped me think through edge cases and stress-test the logic fast.
That said — it couldn't tell me whether a mechanic felt fun. Only real playtesters could. So I think of it as a force multiplier for solo devs, not a replacement for actual human feedback.
Curious if others here are using it similarly for indie/side projects, or is it mostly enterprise-workflow stuff in this thread?
Great insights! AI is definitely helping developers move faster, especially for boilerplate and debugging, but real-world legacy systems still need strong developer experience and problem-solving skills. At Asmorix, we also see students using AI as a productivity tool rather than a replacement for core programming knowledge. 🚀
Honestly, that’s good to hear! I’ve genuinely been wondering what this whole situation looks like for juniors right now.
I'll be honest I use AI for almost every task But not in the way the marketing suggests For work AI is my first draft engine I prompt get code then spend most of my time editing refactoring and adding the context the AI missed The AI writes the 70% that's obvious I spend my energy on the 30% that requires judgment.
What surprised me the more I use AI the more I realize how much of my value is in review not writing The AI can generate It can't decide what's worth keeping.
Curious what patterns you found in your research Are most developers using AI as a junior assistant or as a senior pair programmer? The distinction matters for how we should be training juniors. 🙌
I fully agree with this. A few months ago it was even more visible, you could often throw away huge chunks of what the AI generated because once you looked closely, the structure or assumptions just didn’t make much sense.
And honestly, my “research” on this topic is still ongoing 😂 But so far, I increasingly get the feeling that experienced developers, especially seniors, benefit the most from LLMs, because they already have the judgment needed to review, reshape and challenge the output.
Meanwhile juniors can unfortunately get pushed into a bit of a trap and AI can't always help them.
I am developing a "new" software, and the main challenge is to guide each agent along the correct path. Sometimes I start exploring an idea, giving instructions and noting the results that match what I want to achieve, and little by little I progress in the specification until generating a process module in a technically viable version. Other times I write a very detailed, structured, and reviewed prompt, and it performs tasks, but it is much harder to correct the course if the results are not entirely as desired. But curiously, it has happened to me that in some spontaneous prompt, even with some incorrect expression, after a few attempts, it begins to show what I wanted to obtain, or at least, with the latest results, discard everything it had offered me up to that moment.
Haha, this is actually really fascinating 😄 It almost sounds like conversations with LLMs are slowly becoming more and more similar to conversations with other humans.
Sometimes being overly precise and rigid works worse than an iterative “okay, not this… but THIS part is interesting, let’s go further in that direction” style of communication.
Yo everyone 👋
Mostly into backend systems, SaaS infrastructure, AI products and early-stage startup ecosystems.
Been spending a lot of time lately around scalable product structures and growth-side positioning for smaller projects.
Curious what people here are building right now.
Hi! Can you tell a bit more about how you use AI product at early-stage startups?
Honestly, this matches what I’m seeing too.
AI is incredible for speed and boilerplate, but legacy enterprise systems still require deep human context that agents often miss. The “AI replaces all devs” narrative feels very disconnected from real production environments.
That’s exactly my feeling too! AI probably won’t replace us that quickly in real enterprise environments.
Especially once the current “infinite tokens for everyone” era starts getting more expensive 😂
Great question! I have been building AI agents for small business automation - customer service bots, order processing, etc. The tools (Coze/Dify) now let you build a full bot in hours with zero coding. The real bottleneck is not tech - it is that most small business owners do not know this is possible. Curious if anyone else is building AI agents for non-developer clients?
I’ve never built anything like that myself, but honestly this sounds super interesting!
Really liked the examples you shared! 😊 The cost optimization becomes a real thing. Really curious to see how the balance will be established (especially regarding hiring interns as the cheaper option 😀). Regarding how developers use AI, the most interesting discussions to me right now are the Linkedin battles around the question if devs should read and understand the AI generated code or is it actually enough to have tests passed to ship to production. Still figuring out which camp is the ‘correct’ one 😄
Hahaha I think this thread may have already produced an answer to that question 😄 And I believe @sanjay_pal gave the perfect real-world example in his comment about the fast AI-assisted rewrite that slowly turned into modern spaghetti code 😂
The pattern you're describing with legacy systems matches what I've been finding from the testing side. I've been running AI agents through structured benchmarks for about 14 months now (340+ tests across 26 categories at tabverified.ai) and the greenfield vs legacy split shows up hard in the data.
The thing that surprised me most: eight out of ten frontier models go completely silent when something breaks. They don't explain what went wrong, they don't try a different approach, they just move on to the next thing. Your friend noticing "the exact moment Claude started going off the rails" is basically what I'm measuring, except I can put a number on it.
The other finding that connects to your enterprise experience... newer model versions don't automatically score better than older ones. I've tested cases where the upgrade actually made things worse on four consecutive benchmarks. So the "just update to the latest model" advice that floats around doesn't hold up when you measure it.
Ofri's point about structural drift is real too. The models produce code that's technically compliant but architecturally wrong, and that's the exact kind of failure that passes automated checks but breaks the system over time. Static benchmarks don't catch it. You need behavioral tests that measure how the agent handles pressure, ambiguity, and its own mistakes.
Wow, thanks a lot for this comment! It’s honestly beautiful when our collective “developer gut feeling” suddenly starts getting confirmed by actual benchmarks 😂
And hahaha, my agent at work definitely doesn’t give up either 😄 Sometimes it starts hunting for some weird bug and spends ages sweating through the codebase, libraries, abstractions, trying every possible angle...
Then I show up, look at the problem for five minutes, and find the bug (or at least the suspicious area) almost immediately 😂
But to be fair: at least you can’t accuse the agent of lacking persistence 😅
Hello guys total newbie in the developer scene but if 2-3 years of vibe coding counts then accept me as part of the pack. A quick humble brag, I was an IBM Global Entrepreneur Partner & worked with Watson AI and due to my deep expertise in management & technology consulting, built a VAT knowledge base powered chatbot back in 2017. What brought me to Dev.to today is that I compiled an eBook. The 120 page book's title is: Stay In The AI Loop: The AI Transition Playbook for Developers, Builders and Entrepreneurs. I am wondering if any of you want to read and give me feedback...Full book pdf or even a chapter will be highly appreciated...
Haha, “2–3 years of vibe coding” might actually become an official seniority level soon 😂
And honestly, building a VAT knowledge-base chatbot back in 2017 was pretty ahead of the curve 😄
This resonated. The line between "AI works great" and "AI falls apart" often has less to do with model quality and more to do with whether the system has compressed years of tribal knowledge into undocumented edge cases.
From the founder side, I keep seeing the same pattern: AI is incredible on greenfield scaffolding, migrations with clear boundaries, and first-draft analysis. But once the real bottleneck becomes hidden context, senior engineers stop being pure builders and become context routers + quality control.
Your point about cost optimization is also underrated. A lot of teams are still benchmarking AI on output volume, not on net useful work per dollar. That metric shift is going to matter a lot.
Great post.
Thanks a lot 😄 And yes, exactly! That’s why I suspect the cost question may hit us sooner rather than later.
It’s very fun to rapidly prototype things with LLMs, but at the end of the day someone still has to turn that into an actual sustainable business 😂
I love AI, it is a very cool technology but it shouldn't have any place in coding. AI code has huge flaws and its fine for prototypes or whatever but its not secure.
I think that ship has probably already sailed 😄 Whether we like it or not, AI is going to play a major role in software development.
I agree. AI is a new technology in its infancy. We can already make informed guesses, but actually, it is too early to gauge its full future impact. Internet connections used to be phone calls charged by the second. The Web was meant to improve the handling of academic papers. Electricity was a funfair attraction at first.
The advent of the stored-program computer created a new type of job and a new craftsmanship. Everything we ever did in software engineering has naturally been human-centric up to this point. In the short term, this means AI must fit into and work with all our human-centric processes and artifacts. But there is no guarantee that things will always stay this way. In fact, I believe that AI is so transformative that software development will become something entirely different in the mid-term (if you are interested, read my post on this).
Having said this, over the next one or two decades, we will be busy bringing AI to the enterprise, and it will be a brutal uphill battle. Our job will be to deliver the first steam engine to a manual labor factory: no supporting infrastructure, and simply not enough space. The factory was not built for this. We could tear it down and rebuild it, but the interruption would kill it.
We will have so much fun 😆
Yes, this is a fantastic angle!
Honestly, I wouldn't expect software development to look the same in 20 years even if AI had never appeared. Change is the only constant in this industry.
But I think you're absolutely right about enterprises. They rarely move as fast as the technology itself, which is why so many developers end up adopting AI on their own first, simply because it helps them get their work done.
The more I read through this comment section, the more I feel that your comment is actually the perfect summary of what we're seeing here: heavy individual adoption, much slower organizational adoption, and a long, messy process of trying to fit a very new technology into systems and processes that were never designed for it 😄
Interesting insights! AI is definitely changing how developers work by improving productivity, speeding up coding tasks, and helping with problem-solving. Exciting to see how rapidly AI is becoming part of everyday development workflows.
Exciting, absolutely 😄 ...but also a little bit terrifying sometimes 😂
I agree that there is no universal "best" AI automation tool.
In my case, the biggest productivity gains came from combining multiple tools:
ChatGPT for planning and problem-solving
Claude for deeper reasoning
Windsurf/Cursor for coding
Make for workflow automation
The real advantage comes from building the right workflow, not choosing a single tool.
Have you found that tool combinations outperform standalone AI tools in most business cases?
I suspect you're right 😄 But honestly, I haven't really found that sweet spot yet.
I do have a workflow for hobby projects where different tools play different roles, but in the corporate world things are still much messier. We're only just starting to figure out what actually works, so I feel like we're still in the experimentation phase rather than having a mature workflow.
Yea but I restricted my org to the base plans + ~100ish credits, prioritizes smaller models and only using AI for critical tasks
Interesting 😄 And how is that working out in practice? Are people generally happy with those limits, or do they keep running into them and asking for more credits? 😂
Yeah they hit limits fast after the initial $20
I think the biggest change isn't that AI writes code.
It's that AI reduces the time between having an idea and testing it.
A year ago, I would spend hours searching documentation, examples, and Stack Overflow threads.
Today, I can build a prototype first and learn while refining it.
The challenge is knowing when to trust AI and when to verify its output.
Has anyone else noticed that AI has changed the way they learn, not just the way they code?
I completely agree. When it comes to iterating on ideas and quickly testing different approaches, AI is incredibly powerful.
The catch is that rapid prototyping doesn't always translate into production software. That's where maintainability, architecture, business rules, and all the messy real-world constraints start to matter.
Honestly you’re absolutely right
Thanks! 🥰
I know some people in my network who are dev. They are using AI at work officially or unofficially within their organization.
Thanks, Ben 😄 That's exactly the impression I'm getting from this comment section too. A lot of developers seem to be using AI already, whether officially or unofficially, even if their organizations are still trying to figure out what their actual AI strategy should be.
haha! It is so true.
Too many emojis, highly sus, stopped reading.
Jk jk jk
Good breakdown, interesting projections, and refreshingly pragmatic!
Hmm, maybe I'll reduce the emoji count next time...
Just kidding 😄
Don't worry, if I ever write a scientific paper, I'll try to show some restraint 😉
❤️
please do not use AI😭 ,try to own🫵
Haha, I think that ship has sailed already 😄
True
AI really speeds up repetitive coding work. But when it comes to complex legacy systems and unique business logic, human experience is still irreplaceable. It’s a great helper for our daily work.
Exactly! In most legacy systems I see AI more as a daily helper than an army of autonomous agents. The productivity boost is real, but human context and experience still do most of the heavy lifting.
AI is great at generating code. It's much worse at understanding why a 7-year-old enterprise system looks the way it does.
In my experience, context is still the hardest thing to automate.
Exactly! And if AI struggles with context in relatively simple projects, enterprise systems are a whole different challenge 😂
Recommended