Melih Abdulhayoglu
I Love Writing Code. But Our Job Has Fundamentally Changed.
By Melih Abdulhayoglu
Let me start with a confession.
I am a software engineer. I love coding.
I love the intellectual challenge of solving a difficult technical problem. I love designing architectures, figuring out algorithms, debugging something that refuses to work, and that wonderful moment when everything finally comes together.
There is something deeply satisfying about taking an idea that exists only in your head and bringing it to life through code.
I understand that feeling because I am one of you.
Yes, I am a CEO. I am also a hands-on CTO. But I never stopped being a software engineer. Technology isn’t just something I manage from a boardroom. It is something I understand, work with, and genuinely enjoy.
So when I say that the role of the software engineer is undergoing the biggest transformation in its history, I am not speaking as some executive who has never written a line of code.
I am talking about my own profession. My own passion. The very thing I love doing.
And I believe we need to confront an uncomfortable reality:
Our job is no longer primarily to write code.
For decades, our value as software engineers came largely from our ability to translate ideas into code. Someone would explain what they wanted, and we would figure out how to build it.
We were the bridge between human imagination and executable software.
We learned languages, frameworks, design patterns, algorithms, data structures, and architectures. We became experts in transforming requirements into instructions that machines could execute.
And we were proud of it.
But something fundamental has changed.
For the first time in history, we are no longer the only intelligence capable of translating ideas into software.
AI can now write code, debug it, test it, refactor it, and increasingly build entire working systems.
And it is getting better at an extraordinary pace.
This isn’t just another productivity tool.
It is a fundamental change in what it means to be a software engineer.
And whether we like it or not, our profession must evolve.
1. We Are Making a Fundamental Mistake About AI
I see many software engineers using AI today.
They use it to autocomplete code, generate functions, explain errors, write tests, or suggest improvements.
They say things like:
“AI makes me a 30% faster programmer.”
That’s wonderful.
But I believe it misses the real revolution.
We are using AI to make an old way of working faster instead of realizing that AI enables an entirely new way of working.
Imagine the invention of the automobile.
Now imagine someone attaching an automobile engine to a horse carriage and celebrating because their carriage can travel faster.
They have gained an improvement, certainly.
But they have completely missed what the automobile actually makes possible.
That is what much of the software engineering profession is doing with AI today.
We are asking:
“How can AI help me write code faster?”
When we should be asking:
“Why am I writing this code myself in the first place?”
And more importantly:
“How can I use AI to build this entire solution, from beginning to end?”
These are fundamentally different questions.
The first keeps the human programmer at the center of code production, with AI assisting.
The second puts the engineer at the center of software creation, with AI performing much of the execution.
That distinction changes everything.
I would go so far as to reverse how we traditionally think about the relationship:
Your job is no longer to write code, with LLMs helping you write better code faster. Your job is to help LLMs write better code faster.
Read that again.
It’s a complete reversal of roles.
The engineer is no longer primarily the person executing the instructions.
The engineer is the person directing the intelligence that executes them.
2. The New Software Engineer Commands an Army of AI Agents
This is where I believe the real revolution begins.
Forget thinking of AI as a single chatbot sitting beside you while you program.
Instead, imagine yourself as the leader of an entire engineering organization.
Except many of the people doing the work are AI agents.
You have an agent responsible for understanding requirements.
Another for architecture.
Another for backend development.
Another for frontend development.
Another for database design.
Another for automated testing.
Another for security analysis.
Another for performance optimization.
Another for documentation.
And others that independently review what the first group has produced.
Some of these agents work in parallel. Some work sequentially. Some challenge the work of others. Some identify mistakes and send the work back for correction.
And you, the software engineer, orchestrate the entire operation.
You establish the vision.
You define the objectives.
You break the problem into manageable parts.
You decide which agents should do what.
You establish the constraints, interfaces, and acceptance criteria.
You evaluate the results and ensure that all the pieces come together into a functioning system.
You are no longer the person personally laying every brick.
You are the architect, project leader, and engineering director of an AI-powered construction operation.
Think about how fundamentally different that is.
Traditionally, your execution capacity was largely limited to what you could personally implement, or what a team of human developers could implement together.
Today, an individual engineer can increasingly coordinate multiple streams of AI-driven development.
Of course, more agents do not automatically mean better software. They can make mistakes, conflict with one another, and generate code that looks correct but isn’t.
That is why the engineering role doesn’t disappear.
It becomes even more important.
The quality of the output depends on how intelligently you organize, direct, constrain, and verify the work.
The engineer’s leverage is no longer limited by how fast their fingers can type, but by how effectively their mind can direct intelligence.
This is a very different profession from the one most of us trained for.
3. We Must Move Upstream: From HOW to WHAT and WHY
Let me explain what I mean by moving upstream.
For most of our careers, software engineers have spent a large portion of their time dealing with the how.
How do I write this function?
How should I organize these classes?
How do I implement this algorithm?
How do I connect these APIs?
How do I fix this particular error?
How do I get this framework to do what I want?
These questions are still important.
But they are increasingly questions that AI can handle.
So where does that leave us?
It pushes us upstream, closer to the vision itself.
The most valuable questions become:
What are we actually trying to achieve?
Why are we building this?
What is the optimal way for the overall system to function?
What are the requirements we haven’t considered?
How should the architecture support future changes?
What can go wrong?
How do we know the result is correct?
How do we orchestrate the work so that AI can deliver the complete solution?
This is where our expertise as engineers becomes incredibly valuable.
Because knowing how to write a function is one thing.
Knowing what system needs to exist, how its parts should interact, and how to ensure it works reliably is something much bigger.
We must evolve from translating vision into code to translating vision into instructions for AI systems that create the code.
That means becoming better thinkers, better architects, better problem solvers, and better communicators.
It means understanding the business and the user, not just the technology.
It means developing the ability to take something ambiguous and transform it into a precise specification that multiple AI agents can execute.
In this new world, a well-defined specification is a powerful engineering asset.
A badly specified problem can produce thousands of lines of perfectly valid code that solve the wrong problem.
And AI can generate that wrong solution remarkably quickly!
The engineer must make sure the intelligence is solving the right problem in the first place.
4. What Would I Actually Do Differently Today?
Let’s make this practical.
Imagine I want to build a completely new AI-native ticketing system.
Traditionally, I would assemble an engineering team, explain the requirements, assign responsibilities, and have developers begin implementing individual components.
We would have backend work, frontend work, database work, integration work, testing, debugging, and deployment.
The project could involve many people and considerable coordination.
And much of the time would be consumed by human beings manually producing code.
Today, I would approach the problem differently.
I would begin with the overall vision.
What must the system accomplish?
Who are the users?
What should the workflows look like?
How should AI interact with tickets?
When should humans be involved?
What integrations are necessary?
What are the security and reliability requirements?
What does success look like?
Then I would work with AI to refine that vision into a detailed technical specification.
From there, I would organize AI agents around the work.
An architecture agent could design the system.
A database agent could design the data structures.
A backend agent could implement the business logic.
A frontend agent could create the user experience.
A testing agent could develop test cases based on the requirements.
A security agent could analyze potential vulnerabilities.
Other agents could review, challenge, and improve what had been created.
Critically, I would not simply accept everything the agents produced.
I would challenge architectural decisions, inspect difficult areas, validate assumptions, require appropriate tests, and take responsibility for the final result.
But I would not make my own manual coding the default mechanism by which the project progresses.
That is the difference.
My job would be to take the project from vision to working product, with AI executing as much of the engineering work as it can reliably handle.
The workflow becomes:
Vision → Specification → Agent Orchestration → Execution → Verification → Delivery.
And then we iterate.
Not only on the software, but on how efficiently the entire AI-driven engineering process operates.
That is the future I want our engineering organizations to embrace.
5. Loving Code Is Not the Same as Needing to Write Every Line
This is the part I feel personally.
Because I genuinely love coding.
I enjoy getting into the details. Sometimes I want to implement something myself simply because I find the technical problem fascinating.
I don’t think that feeling is going away.
And I don’t think it should.
Software engineering is a creative discipline. There is beauty in elegant code, thoughtful architecture, and clever solutions.
AI doesn’t take that appreciation away from us.
But we need to distinguish between what we enjoy doing and where we create the most value.
I may enjoy spending hours solving an implementation problem.
But if I can direct AI to solve it in minutes, verify the outcome, and then use those hours to tackle a much bigger problem, shouldn’t I?
That is the real opportunity.
Not to stop enjoying programming.
But to stop allowing the mechanics of programming to limit what we can build.
I still believe every great software engineer should understand code deeply.
You need that knowledge to understand what AI is producing.
You need it to recognize a flawed architecture.
You need it to identify problems that automated tests might miss.
You need it to ask the right questions.
You need it to judge whether the solution is maintainable, secure, and reliable.
The ability to write code remains a valuable skill. The insistence on personally writing every line becomes an unnecessary constraint.
Our passion for coding should make us better at directing AI, not prevent us from adopting it.
6. Your Technical Expertise Isn’t Becoming Worthless. It’s Becoming More Powerful.
One of the objections I hear is that if AI writes the code, engineers will lose their technical skills.
I understand the concern.
But I believe it confuses the execution of a task with the knowledge required to supervise that task intelligently.
Consider an experienced software architect.
Their value is not simply their ability to type code.
Their value is their understanding of how systems work.
They know why one architecture will scale and another will fail.
They understand concurrency, state management, security boundaries, performance tradeoffs, and maintainability.
They can recognize dangerous assumptions.
They know when a seemingly simple implementation creates a much bigger problem downstream.
None of that knowledge becomes less valuable because AI can generate code.
In fact, that knowledge becomes more powerful when the engineer can apply it across many parallel workstreams instead of being consumed by implementing one component at a time.
This is the opportunity for experienced developers.
Your expertise becomes a force multiplier.
A technically weak engineer who blindly accepts AI-generated software can produce a great deal of bad software very quickly.
A technically strong engineer who knows how to orchestrate AI agents can potentially produce extraordinary results.
The difference is judgment.
The ability to know what is correct.
The ability to know what matters.
The ability to know what should be built and what should not.
And the ability to recognize when AI is confidently wrong.
AI makes software production easier.
It does not automatically make software engineering easy.
7. We Must Stop Measuring Engineers by the Code They Produce
As a CEO and CTO, this is something I believe we must change at the organizational level.
For too long, engineering productivity has been associated with coding activity.
How much code did you write?
How many tasks did you complete?
How many tickets did you close?
How long did the implementation take?
But these are not necessarily measures of value.
Our customers do not care how many lines of code we write.
They care whether our products solve their problems.
They care whether the software works, whether it is reliable, whether it is secure, and whether it helps them achieve their objectives.
Code is not the outcome. Code is an implementation artifact.
And if AI can generate that artifact effectively, there is no inherent business advantage in requiring a human to produce it manually.
Imagine two engineers.
The first spends two weeks writing an excellent software component by hand.
The second spends two days directing AI agents to implement the same component, rigorously testing it, reviewing the architecture, and ensuring it meets the same quality standards.
Assuming the results are equally good, which engineer has created more value?
The answer should be obvious.
Yet many organizations still celebrate the effort involved in producing code rather than the efficiency and quality of the outcome.
That must change.
We should measure engineering success by working capabilities delivered, quality, reliability, security, maintainability, and time to value.
We must reward engineers who find intelligent ways to deliver results.
Not simply those who spend the most hours doing the work manually.
8. The Biggest Obstacle May Be Our Own Identity
This may be the hardest part of the entire transition.
For many of us, being a software engineer is not just a job.
It is part of who we are.
We have invested years mastering programming languages, frameworks, algorithms, and techniques.
We have taken pride in being the people who can make computers do extraordinary things.
So when someone says that AI can now do much of what we have spent our careers mastering, it can feel threatening.
I understand that because I share that background.
But we should not confuse our professional identity with the particular tools or techniques we use.
We became engineers because we love solving problems.
Because we love building things.
Because we love understanding how systems work.
Because we enjoy turning imagination into reality.
Writing code was the means. Creating something was always the objective.
AI has changed the means.
It hasn’t removed the objective.
In fact, it has expanded what we can accomplish.
We can now attempt projects that previously would have been too expensive, too complicated, or too time-consuming.
We can experiment with ideas more rapidly.
We can explore multiple architectural approaches.
We can build and test prototypes at extraordinary speed.
We can spend more of our time thinking about the important problems instead of fighting with the mechanics of implementing them.
For someone who genuinely loves engineering, shouldn’t that be exciting?
I believe it is.
But only if we are willing to let go of the assumption that being a great engineer means personally writing the code.
9. Companies Need to Reinvent Their Engineering Organizations
This transformation isn’t just the responsibility of individual developers.
As a CEO and CTO, I recognize that leadership has an equally important responsibility.
We cannot tell engineers to embrace AI while continuing to organize development exactly as we did ten years ago.
We cannot simply buy AI coding tools, hand out subscriptions, and announce that we are now an AI-native engineering company.
That is not transformation. That is the old operating model with some new tools attached.
We need to redesign how engineering work happens.
Engineers must learn to manage parallel AI execution, maintain architectural consistency, and integrate independently produced components.
We must also rethink training.
Junior engineers need to learn engineering fundamentals, but they must also learn how to direct and evaluate AI.
Senior engineers need to develop the ability to manage increasingly sophisticated AI-driven development operations.
Engineering leaders must learn how to organize teams around outcomes rather than manual task allocation.
And companies must invest in the infrastructure that makes this possible.
We need AI agents with appropriate access to codebases, documentation, testing environments, build systems, and deployment pipelines.
We need to give them clear boundaries, reliable feedback loops, and rigorous ways to validate their results.
The objective is not to replace engineering discipline with AI-generated code. It is to make engineering discipline operate at a dramatically greater scale through AI.
The companies that understand this distinction will be in a much stronger position than those that merely use AI to autocomplete their existing workflows.
10. Don’t Confuse AI Adoption with AI-Native Engineering
There is an important distinction between using AI and truly embracing an AI-native approach.
A developer who asks ChatGPT to write a function is using AI.
A developer who uses AI to generate test cases is using AI.
A developer who asks an LLM to explain an unfamiliar codebase is using AI.
All of these are useful.
But none of them, by themselves, represents a fundamental transformation.
AI-native engineering begins when we redesign the entire development process around the capabilities of AI.
Instead of asking how AI fits into our existing workflow, we ask what the workflow should look like when intelligent agents can perform much of the implementation.
That means thinking about execution as something we orchestrate.
About verification as something we design.
About specifications as something we engineer.
And about the human role as the owner of the overall result.
We are already seeing evidence of this shift across the industry.
AI coding agents are moving beyond autocomplete and single-task assistance toward more autonomous development workflows.
They can explore repositories, modify multiple files, run commands, execute tests, and work through increasingly complex tasks.
But adopting these tools is not enough.
AI-generated software can still contain subtle defects, insecure assumptions, poor abstractions, and integration problems.
The goal is not to generate the maximum amount of code.
It is to create the maximum amount of reliable value.
The competitive advantage will belong to engineers and companies that master the orchestration and verification of AI-driven software development.
11. The Future Engineer Will Be Measured by Their Ability to Command Intelligence
Imagine the software engineer of the near future.
They begin the day not by opening an IDE to work through a long list of implementation tasks, but by reviewing the progress of multiple AI agents.
One agent has completed a backend feature.
Another has identified a design issue.
Another has produced a set of integration tests.
Another is investigating a performance bottleneck.
Another is preparing a new component.
The engineer reviews the results, resolves design questions, redirects work where necessary, and initiates new tasks.
They spend their time making decisions, defining objectives, exploring possibilities, and ensuring that all the work moves toward a coherent result.
They may still open an IDE and write code.
I certainly expect to.
But writing code is no longer the bottleneck around which the entire development process is organized.
The bottleneck moves from implementation capacity toward the quality of human judgment, specification, coordination, and verification.
This is a fundamentally more powerful position for an engineer to occupy.
Instead of being limited to one stream of implementation, they can oversee many.
Instead of spending days implementing one idea, they can investigate several approaches and evaluate the results.
Instead of focusing primarily on individual components, they can spend more time considering the system as a whole.
This is why I believe the software engineering profession is moving upstream.
The engineer becomes closer to the creator of the vision.
Closer to the architect of the solution.
Closer to the person ultimately responsible for transforming an idea into a real product.
That is not a downgrade of the profession.
It is an enormous expansion of what the profession can achieve.
12. Adapt or Die — And I Include Myself in That Challenge
Let me finish where I started.
I am a software engineer.
I love coding.
I still enjoy solving difficult technical problems and getting into the details of how software works.
That isn’t going to change.
But being both an engineer and a CEO/CTO gives me a particular perspective.
As an engineer, I appreciate the craft.
As a CTO, I understand the importance of architecture, technical quality, and sound engineering decisions.
As a CEO, I have to ask a different question:
Are we using the best available means to turn ideas into valuable products?
And increasingly, the answer must involve AI doing far more of the implementation work.
I cannot justify preserving an inefficient development process simply because it is the process I grew up with and enjoy.
And I cannot expect our engineers to evolve if I am unwilling to evolve myself.
Let’s remind ourselves why we became engineers in the first place.
We are engineers because we love solving challenges. Because we want to make life better for humanity.
We build bridges so people don’t have to swim across rivers.
We build cars so people can travel farther and faster.
We build machines, systems, and technologies that overcome human limitations, solve problems, and make things possible that once seemed impossible.
Engineering has always been about serving humanity.
And now we have been given an extraordinary new tool: Artificial Intelligence.
A tool that can help us solve more problems, tackle greater challenges, and deliver solutions to humanity faster and at a scale we could previously only dream of.
Why would we not embrace it?
Why would we insist on doing things the old way when we have an opportunity to accomplish so much more?
Our loyalty as engineers should never be to the tools we use. It should be to the problems we solve and the people who benefit from our solutions.
AI doesn’t change why we became engineers.
It gives us an extraordinary new way to fulfill that purpose.
This is not about executives telling developers that their skills no longer matter.
It is about engineers, including me, recognizing that our skills can now be applied at a much higher level.
I don’t want engineers to lose their passion for coding.
I want them to channel that passion into building things that were previously unimaginable.
I want engineers who can think deeply, design intelligently, solve difficult problems, and orchestrate entire armies of AI agents to bring their ideas to life.
I want us to spend less time wrestling with implementation details that AI can handle and more time tackling the problems that actually matter.
I want us to move from being the people who write the code to being the people who command the intelligence that builds complete software systems.
And I want us to embrace this change with the same curiosity, excitement, and intellectual courage that made us engineers in the first place.
Because here is the reality:
AI is not waiting for us to become comfortable with the changes it is bringing.
The capabilities will continue to improve.
The cost of generating code will continue to fall.
The ability of individuals and small teams to build sophisticated software will continue to expand.
The expectations placed on software engineers will change accordingly.
Those who adapt will have extraordinary opportunities.
Those who insist on defining their value primarily by the code they personally write risk becoming increasingly irrelevant.
That is what I mean by adapt or die.
Not that engineers will cease to exist.
But that the old model of software engineering cannot remain unchanged.
Our profession isn’t dying. Our old job description is.
And in its place, something far more exciting is emerging.
A profession where engineering expertise can command extraordinary execution capacity.
Where an idea can become working software with dramatically less friction.
Where the limiting factor is increasingly not how much code we can personally write, but how intelligently we can define, direct, and verify what gets built.
So my message to every software engineer is simple.
I am one of you.
I love what we do.
And precisely because I love what we do, I believe we must have the courage to reinvent it.
Stop thinking of AI as your coding assistant.
Start thinking of yourself as the leader of an AI engineering workforce.
Move upstream. From HOW to WHAT and WHY.
Own the architecture. Own the decisions. Own the outcomes.
Let AI do the heavy lifting.
And never stop being an engineer.
Because the future does not belong to those who can write the most code.
It belongs to those who can turn the biggest ideas into reality by intelligently directing the machines that write it.
Adapt or die.
And yes, I still love coding.
But now I’m starting to love something else just as much: leading my own army of AI agents, turning vision into reality.
— Melih Abdulhayoglu
