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.
Totally agreed. I just released a book that attempts to describe the engineering process around it as I understand it.
leanpub.com/harness-engineering
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.
I noticed this shift in myself when I stopped asking AI to write code and started asking it why my code behaves a certain way.But that only works when the AI actually knows your codebase. Not the file you have open the whole thing. The call graph. What calls what. What breaks if you touch this.
I built something called N3MO(n3mo.shop) partly because I got tired of re-explaining my own project to my AI assistant every single session. Felt like onboarding a new intern every morning.Still figuring out if I'm using AI or engineering with it. Probably somewhere in between.
"AI amplifies the engineering loop that already exists" is the sharpest framing I have seen for this. The danger is not bad code — engineers already deal with that. The danger is that faster output gets mistaken for better engineering, and the verification discipline that took years to build gets quietly abandoned.
I see this especially in robotics and embedded systems, where the cost of a wrong assumption is measured in physical reality, not just a deploy rollback. Our team started treating every AI-assisted change as a hypothesis: we define the test before we accept the output. It slows things down but the failure modes are far more bounded.
The "think twice, code once" reframe is good, but I wonder if it undersells the deeper shift: good engineering with AI requires better problem definition, not just better review. Have you found that prompting skills and system design skills are diverging as AI becomes more capable?
same split happens in how teams use AI outputs, not just how engineers prompt. the paste-and-ship crew vs. the ones who actually know enough to review what came back. the gap between those two is bigger than the model choice.
Really agree with this - engineering is all about the architecture, observability design, caching not about the code itself
Je trouve aussi 👍
Back to basics with domain modeling
The use-it versus engineer-with-it split comes down to one habit: whether you treat the output as an answer or as a hypothesis. Using AI is accepting the generated code because it looks right; engineering with it is building the harness that catches the cases where looks-right and is-right diverge. The engineers who get leverage aren't prompting better, they're putting the model inside a system that verifies its output, so they can move fast precisely because something other than their own attention is checking. The ones who just use it inherit the model's failure modes at the model's speed. Engineering with AI is mostly designing where the model is allowed to be wrong and what catches it when it is.
Well to use chatgpt or claude is not an issue but the main thing is you must know the basics of the coding you can not just prompt, get the code and apply into your project. For I would suggest learn basic, tips, tracks and use css code generators as well that will help to save your time. Try this website cssawwwards.com as one stop shop for frontend developers, everything use free of cost.
AI is becoming less about asking questions and more about orchestrating outcomes. That's where the real leverage comes from.