Most software engineers I know use AI in some form now.
Maybe it is for debugging, boilerplate, tests, docs, SQL queries, shell commands, or quick...
For further actions, you may consider blocking this person and/or reporting abuse
This is an incredible perspective, Jeel. There is a massive difference between just using an AI chatbot to generate basic syntax snippets and actually engineering fully autonomous system workflows.
I've been trying to bridge this exact gap on my current project (an interactive, live portfolio over at roshansharma.co.in). I built a Next.js frontend integrated with an autonomous chat agent backed by a Supabase vector database for a custom RAG pipeline, complete withElevenLabs voice guide sync.
Since you have such a sharp focus on real-world AI engineering over boilerplate generation, I’d love it if you could take a look at the layout and architecture breakdown in my recent post. I'm always looking to refine my state logic and context retrieval methods—any technical feedback on areas I can improve or optimize would be huge!
Sure, I'll have a look and keep you posted. I have a lot to share, stay tuned! 🙂
Awesome, Jeel! I'm incredibly excited to hear your thoughts and dive into that feedback.
I actually just published a dedicated community update post detailing a major structural hardening pass I completed on the production environment (refactoring the UI/UX onboarding flow, handling client-side markdown parsing, and spinning up explicit data disclosures).
Since you have such a solid perspective on real-world engineering mechanics, I'd be incredibly grateful if you could check out the live site at roshansharma.co.in or drop your technical suggestions directly on that new write-up. If the implementation resonates with you, leaving a reaction or sharing your perspective on the post would mean the world. Looking forward to your insights!
Really appreciate this perspective. It highlights a massive shift in how we need to train the next generation of engineers.
Historically, juniors learned by wrestling with the syntax and boilerplate (the "easy" part AI handles now). If the value has shifted entirely to "shaping the work" and "verification," we need to teach system thinking and critical code review much earlier in a developer's career. The prompt isn't the skill; the judgment is.
Je pense que c'est exact, je conçois avec l'IA depuis déjà 3 mois et je comprends ce point de vu sur l'apprentissage. J'aimerais pouvoir augmenter mes compétences en vu de pouvoir mieux structurer mon travail et m'appliquer à la vérification du Code générer par l'IA.
I’m skeptical of trusting code generation to AI. In practice, models frequently violate established design patterns, break architectural boundaries, and introduce unexpected dependencies, which increases technical debt and reduces system predictability. Generated code may be syntactically correct but often fails to preserve critical invariants, module contracts, and non-functional requirements (performance, security, observability).
A far more acceptable paradigm is for an LLM to act as a tool to train and orchestrate a specialized model (LM) that performs strictly bounded, verifiable tasks within well-defined limits.
Yip... I mean look at all the oopsie daisies from Claude... Deleting production DBs because someone just accepted, when Claude thought it was a test db. That being said, I do believe that how you use the AI is important to clarify. If you tell an AI "Make me a messenger app", it'll do just that, but without boat loads of context, it'll fail to create the product you envisioned as a simple example. It was one of the things I struggled with the most when I started UnitBuilds, is simply figuring out how to orchestrate LLMs to not step on eachother's toes, build an actually useful app, make sure it's actually tested and not just unit tests, make sure it's secure (ai loves AllowAnonymous), make sure it's robust (they also dont really do invalid data guards well), all things that honestly just make them more of a burden than effective. But it was because I treated AI like it knew everything and could do anything. Fact is, it cant, atleast not all at once. But when you tell it 'here's file 1, here's file 2, create a bridge for Parameter A', it'll do it flawlessly. Context is a burden to AI, not a silver bullet and people need to understand that. If you bloat your context, it hallucinates. If you keep it tight, it works much better. MCPs also help alot, knowledge graphs, codebase maps, dependency graphs, etc. So it can detect breaking changes before it makes them. All little things, each adding maybe 0.1% better output quality, but in the end it becomes a trial and error run, rather than a suicide bomber training camp.
This matches what I’ve seen in real repos. AI makes it easy to generate patches, but the real bottleneck is still understanding scope and boundaries before touching code.
Most breakages come from unclear requirements, not bad generation.
The line about already deciding how you'll verify the change before prompting is the whole game for me. Clean-looking output is the trap, because review effort scales with how much code you accepted, not how much you wrote, so a fast 200-line diff can cost more attention than it saved. I've started treating "what test or check proves this is right" as the first prompt instead of the last.
Back to basics with domain modeling
Je trouve aussi 👍