He asked:
So bro, I have a question. I've been watching the development cycle transition from manually writing code to a more agentic way of development. Given your experience working in this kind of environment, what are your thoughts on this transition? What tips or advice would you give to developers who are trying to adapt to this new agentic approach?
It is a great question, and honestly, I think this transition is happening whether we like it or not.
The real question is no longer whether AI will replace developers. The more interesting question is: how will AI reshape the way we work, and where will our actual value as engineers lie?
For a long time, writing code was one of the most visible parts of software engineering. You had an idea, you opened your editor, and you translated that idea into syntax, functions, classes, APIs, and database queries. The ability to write good code was therefore closely tied to being a good engineer.
But that relationship is changing.
Today, an agent can take a relatively high-level description of a problem, inspect a codebase, create files, modify existing ones, run commands, execute tests, investigate errors, and iterate on its own. Problems that might previously have taken a developer several days can sometimes be reduced to hours or even minutes.
That is incredible.
But it also creates a new danger.
The danger is not that AI becomes too capable. The danger is that we become less capable because we stop thinking.
Embrace the tools, but don't become passive
My biggest piece of advice to developers is simple: embrace the tools, but don't let them make you passive.
We have seen this pattern before.
Stack Overflow made it dramatically easier to find solutions to programming problems. That was a huge improvement for developers, but it also created a generation of developers who could sometimes solve problems by searching, copying, and pasting without understanding why the solution worked.
Agents can create an even more extreme version of that problem.
Instead of copying a snippet, you can now ask an agent to build an entire feature. The temptation is to become a supervisor who simply watches the agent work, accepts the result, and moves on.
That is dangerous.
If you don't understand the system being built, you eventually lose the ability to distinguish between something that works and something that merely appears to work.
The goal shouldn't be to become an excellent AI operator at the expense of becoming a weaker engineer.
The goal should be to become a better engineer because AI amplifies your capabilities.
Brainstorm with humans, execute with agents
One of the biggest lessons I've learned is that not every part of software development should be delegated.
Before an agent writes a single line of code, there are questions that need to be answered.
What are we actually building?
Who are we building it for?
What problem are we solving?
What should the architecture look like?
What are the trade-offs?
What shouldn't we build?
These are fundamentally human questions.
I strongly believe that teams should spend more time brainstorming and validating ideas with humans and then use agents to accelerate execution.
Talk to your users. Talk to your designers. Talk to other engineers. Talk to the people who understand the business. Challenge assumptions. Sketch the architecture. Argue about trade-offs.
Then give the agent a well-defined problem.
In other words:
Brainstorm with humans. Execute with agents.
An agent should be a force multiplier for a good idea, not a machine for producing large amounts of code around a bad one.
This distinction becomes increasingly important because AI makes it incredibly cheap to build things.
And when building becomes cheap, deciding what to build becomes more valuable.
Protect your engineering muscle
There is another problem we need to take seriously: skill atrophy.
When an agent can solve a problem that would previously have required hours of debugging, there is a natural temptation to stop understanding the underlying mechanics.
Why learn how a database query planner works when the agent can optimize the query?
Why understand networking deeply when the agent can configure the server?
Why investigate a complicated race condition when the agent can inspect the logs and suggest a fix?
Because eventually, something will break in a way the agent doesn't understand.
And when that happens, you need to be the person who can reason about the system.
Prompt engineering is useful. Knowing how to communicate effectively with agents is becoming an important engineering skill. But I don't think it replaces the fundamentals.
Understanding operating systems, networking, databases, distributed systems, security, algorithms, architecture, concurrency, and debugging still matters.
In fact, I think it matters even more.
When AI generates more of the implementation, your understanding becomes the mechanism through which you evaluate that implementation.
You don't need to write every line anymore.
But you need to understand enough to know whether the lines should exist in the first place.
Treat agents like extremely fast junior engineers
One mental model I find useful is to treat AI-generated code like a pull request from a very fast junior developer.
A junior developer might produce something that works but has questionable abstractions. They might miss an edge case. They might introduce a security vulnerability. They might solve the immediate problem while creating a larger architectural problem somewhere else.
Agents can do exactly the same thing.
The difference is that an agent can produce hundreds or thousands of lines of code in the time it would take a human to write a small function.
That makes review more important, not less.
Never merge code you couldn't explain.
Never deploy something simply because the tests passed.
Never assume that because an agent confidently explained its solution, the solution is correct.
Ask questions.
Why was this approach chosen?
What happens if the input is malformed?
What happens under high load?
What happens when the network fails?
What happens when two requests happen simultaneously?
What happens when this database record doesn't exist?
What happens if the user refreshes halfway through the operation?
What happens six months from now when another developer needs to change this?
The ability to ask these questions is engineering.
The team changes too
The impact of agentic development becomes even more interesting when we stop thinking about individual developers and start thinking about teams.
A traditional development team might divide work into tickets and assign those tickets to individuals.
One developer works on authentication. Another works on payments. Another handles the frontend. Another works on the API.
But when agents dramatically increase individual throughput, simply giving everyone more tickets isn't necessarily the answer.
You can end up with a team that produces more code but creates more complexity.
The bottleneck moves.
It moves from implementation toward coordination, architecture, product decisions, review, and quality control.
This means engineering teams need to become more intentional about how work flows through the organization.
Instead of asking:
"How much code did we produce?"
we should increasingly ask:
"How much meaningful progress did we make?"
Those are not the same thing.
A developer who uses an agent to produce 10,000 lines of code has not necessarily been more productive than a developer who wrote 500 lines that solved the right problem.
In fact, the 10,000 lines might become tomorrow's technical debt.
Stay conscious
This is probably the part I worry about the most.
Agentic development can create the illusion of productivity.
You open your editor.
You describe a feature.
The agent starts working.
Files are changing.
Commands are running.
Tests are passing.
You feel productive.
But were you actually thinking?
Were you making decisions?
Did you understand why the agent chose that architecture?
Did you verify that the feature solves the user's actual problem?
Did you consider what happens outside the happy path?
It is possible to spend an entire day directing an agent and accomplish very little of actual value.
So I think developers need to develop a new form of discipline: conscious development.
Don't just supervise the agent. Stay mentally present.
Read the plan before execution.
Challenge the assumptions.
Review the diff.
Run the application.
Test the edge cases.
Look at the database.
Inspect the logs.
Ask the agent to explain its reasoning.
Then form your own conclusion.
The objective isn't to minimize your involvement.
It is to make your involvement higher leverage.
Agents should increase ambition, not laziness
There is also a more exciting side to all of this.
If agents can dramatically reduce the cost of implementation, developers should be able to attempt things they previously couldn't.
A solo developer can potentially build products that once required a small team.
A small team can potentially compete with much larger organizations.
A large engineering organization can spend more time on difficult problems rather than routine implementation.
That is an incredible opportunity.
But we shouldn't use the increased capacity simply to produce more CRUD applications, more dashboards, and more copies of existing products.
If implementation becomes cheaper, we should become more ambitious about the problems we attempt to solve.
The point of having a faster hammer isn't to hit more nails. Sometimes it's to build a bigger house.
The engineer's role is changing
I don't think the engineer of the future is simply someone who writes code faster.
I think the role is moving toward something closer to a systems thinker, architect, product thinker, and technical decision-maker.
You need to understand the problem deeply enough to describe it.
You need to understand the system deeply enough to design it.
You need to understand engineering deeply enough to challenge the implementation.
And you need to understand the users deeply enough to know whether what you're building is worth building at all.
AI can increasingly handle the mechanics of implementation.
But judgment remains incredibly difficult to automate.
Knowing what to build, why to build it, what trade-offs are acceptable, when something is good enough, when an architecture is going in the wrong direction, and when a seemingly small decision will create a massive problem later are all forms of judgment.
That is where I think a lot of our value will move.
So, are we in trouble?
Maybe. But I don't think the answer is as simple as "AI will replace developers."
Some developers will absolutely become less valuable.
The developers whose primary value is knowing syntax, memorizing APIs, or manually implementing predictable patterns are going to face increasing pressure.
But developers who can understand complex systems, communicate effectively, make good decisions, understand users, design architecture, debug difficult problems, and use AI effectively will probably become significantly more productive.
And that brings me back to the fundamental question.
Are we in love with the manual act of writing syntax, or are we in love with solving problems and bringing ideas to life?
If it's the former, then agentic development probably feels threatening.
If it's the latter, I think this is one of the most exciting periods to be a software engineer.
We are getting tools that can take our ideas and turn them into working software at a speed that would have seemed ridiculous a few years ago.
The challenge isn't to resist that.
The challenge is to make sure that we remain the engineers while using the machines.
Don't let the agent think for you.
Let it help you think better.
Don't let it replace your curiosity.
Use it to explore further.
Don't let it weaken your fundamentals.
Use it to push what you can build.
And most importantly, don't measure your value by how many lines of code you personally typed.
Measure it by the problems you can understand, the decisions you can make, and the things you can bring to life.
That, to me, is what it means to be an engineer in the agentic era.