Intent Programming and AI-Assisted Software Engineering

1. Rethinking programming

Programming is often equated with writing code in a programming language. Yet code is not programming itself; it is one of the representations people use to transfer a solution idea to a computer.

At its most basic level, a programming problem can be considered through the following chain:

Problem → mental model → algorithm → representation → execution

An engineer first tries to understand the problem and then designs a solution for it. The solution may be an algorithm, a state machine, a data flow, a rule set, a mathematical model, or a combination of these. A programming language makes it possible to express that solution in a form a computer can process.

For this reason, it is incomplete to view the history of programming only as the history of languages. It is also the history of our ability to tell machines what we want from increasingly higher levels of abstraction.

In the early periods, the programmer largely told the computer how it should operate. Today, with generative artificial intelligence and software-development agents, we increasingly describe what we want, the boundaries within which we want it, and the conditions a correct result must satisfy.

This change does not eliminate programming. It changes the layer of the programming activity that is directly visible to the human developer.

2. From moving closer to the machine to moving away from it

Every major development in the history of computer programming has hidden a certain class of detail from the programmer.

Machine code required working with numerical representations of processor instructions, while assembly language gave them symbolic names. High-level languages introduced variables, functions, and data structures instead of raw memory addresses and processor instructions. Operating systems abstracted a substantial part of hardware detail. Libraries and frameworks turned recurring infrastructure work into reusable components.

A rough progression can be described as follows:

Machine code
    ↓
Assembly
    ↓
High-level programming languages
    ↓
Libraries and runtimes
    ↓
Frameworks and domain-specific languages
    ↓
Visual and low-code development
    ↓
Natural-language, AI-assisted development

The common property of this progression is that, at each stage, the amount of detail the programmer must manage directly decreases.

A loop written in C may translate into many processor instructions at machine level. A single collection operation in Java may rely on memory management, runtime checks, and virtual-machine behavior. A Spring Boot annotation may stand on top of a broad infrastructure involving an HTTP server, routing, serialization, and dependency management.

AI-assisted programming can be viewed as a continuation of this abstraction trend.

Previously, we might write:

for (int i = 0; i < values.length; i++) {
    ...
}

For some tasks, we can now express an intention such as:

Group these records by date without changing the existing ordering behavior
and process them with the lowest possible additional memory cost.

The important difference is that artificial intelligence is not merely a syntax converter. It interprets the stated objective, uses context, generates possible solutions, and materializes them in a programming language.

3. From syntax to intent

In traditional programming, the central question in an engineer's mind is often:

“How do I express the algorithm I designed in this programming language?”

In AI-assisted development, the question is increasingly becoming:

“How do I express the behavior the system must exhibit, its boundaries, and the criteria for correctness?”

The change may appear small, but it shifts the center of software production.

Traditional flow:

Problem
  ↓
Algorithm
  ↓
Programming language
  ↓
Compiler / interpreter
  ↓
Machine

An intent-oriented flow is closer to:

Problem
  ↓
Intent
  ↓
Specification
  ↓
Context and constraints
  ↓
Artificial intelligence / agent
  ↓
Programming language
  ↓
Compiler / runtime
  ↓
Machine

The programming language has not disappeared. A new interpretation and generation layer has been inserted between the human and the programming language.

For this reason, calling natural language directly a “new programming language” can be technically misleading. Natural language is ambiguous; the same sentence can be interpreted in different ways. Java, C, or Rust, by contrast, have formal syntax and explicit semantic rules.

A more precise statement is:

Natural language is becoming one of the new high-level control interfaces of the programming process.

4. What is intent programming?

Intent programming can be considered a development approach in which the developer describes the behavior to be achieved, the boundaries, the properties that must be preserved, and the criteria for correctness instead of directly writing every implementation detail of the solution.

Here, “intent” is not merely a request such as:

Add user management.

A real engineering intent carries more information:

Preserve the behavior of the existing user-management flow.

Add the new user source to the existing authorization model.

Do not change the database schema.

Do not break existing API contracts.

Do not create any execution path that bypasses authorization checks.

Preserve the existing error semantics when external-service calls fail.

The developer is no longer describing only the requested behavior, but also the boundaries of the change space.

A more accurate model of intent programming is therefore:

Intent = what to do + what not to do + invariants to preserve + success criteria

When context, tools, and verification are added, an engineering process emerges:

Intent
+
Specification
+
Context
+
Constraints
+
Tools
+
Verification

A good outcome does not depend only on a well-written instruction. In AI-assisted code generation, the decisive factor is usually not a “clever prompt,” but whether the project architecture, rules, examples, tools, memory, and boundaries are supplied as the right context.

5. Prompt engineering and intent programming are not the same thing

Writing effective instructions for an AI model is a useful skill. Treating that skill as the entirety of intent programming, however, is insufficient.

For example:

Write a faster version.

is an instruction, but it is not an engineering specification.

The word “faster” does not answer questions such as:

• Under what load?
• Mean latency or worst-case latency?
• Is throughput supposed to increase?
• May memory consumption increase?
• May consistency semantics change?
• Must result ordering be preserved?
• Is a behavior change allowed?
• On what hardware will the measurement be made?

For this reason, more mature AI-assisted software development shifts the focus from prompt engineering toward context engineering and specification engineering.

Information a capable AI agent may need includes:

• system architecture,
• coding rules,
• domain model,
• data model,
• API contracts,
• security boundaries,
• known technical debt,
• performance targets,
• previous architectural decisions,
• behaviors that must not change,
• acceptance criteria.

6. Vibe coding

The term “vibe coding” became widely used in 2025 after Andrej Karpathy described a working style in which the desired behavior is stated in natural language and progress is driven mainly by the observed result rather than by closely examining the details of the generated code.

In its simplest form, the process may look like this:

Write the request
   ↓
Let AI generate the code
   ↓
Run it
   ↓
If an error occurs, give the error message to AI
   ↓
Try the new version

This approach can be extremely productive for small utilities, experiments, personal applications, and rapid prototypes.

The problem arises when the same method is moved into production systems without regard to risk class.

A program:

“appearing to work”

and:

“behaving correctly under all defined conditions”

are not the same thing.

7. Structured AI-assisted development

There is a broad space between vibe coding and traditional engineering.

An experienced developer may:

1. analyze the problem,
2. define the solution boundaries,
3. make the architectural decision,
4. assign a specific subtask to the AI,
5. inspect the generated change,
6. diagnose a failure,
7. ask the AI to implement the correction.

Here, artificial intelligence is less a decision-maker and more an implementation accelerator.

8. Agentic engineering

A software agent is not merely a conversational model that produces a single answer.

It can receive a task, inspect the environment, read files, execute commands, observe the result, and determine its next step accordingly.

A simplified agent loop is:

Perceive the objective
    ↓
Plan
    ↓
Take action
    ↓
Observe the result
    ↓
Revise the plan if necessary
    ↓
Repeat

For this reason, having a powerful language model alone does not create a powerful software-development system.

9. The changing software-development life cycle

A traditional software-development life cycle can be summarized roughly as:

Requirements
↓
Analysis
↓
Design
↓
Coding
↓
Testing
↓
Deployment
↓
Maintenance

Agile methods and DevOps had already shortened the time between these stages substantially. Artificial intelligence is blurring the boundaries between them further.

Today, a developer can discuss a requirement, evaluate a data model, draft an API, generate code, prepare tests, inspect a failure, and write documentation within the same working session.

10. Why does architecture still matter?

Artificial intelligence can propose architectural options, but real architectural decisions are not composed only of technical facts.

For example:

• distributed or centralized?
• consistency or availability?
• low latency or high throughput?
• off-the-shelf product or in-house development?
• general solution or specialized solution?

The answers depend on business needs, operations, regulation, team structure, and expected future use.

11. Negative specification

A traditional requirement usually describes what the system should do:

The user must be able to export the report.

When AI is used to modify an existing and complex codebase, positive requirements alone may be insufficient.

It may also be necessary to state:

Do not change the existing authorization behavior.

Do not change the database schema.

Do not affect the proven behavior on the Listener side.

Do not add a new dependency.

Do not change concurrency semantics.

Such statements can be considered negative specifications.

A strong task definition in intent programming can contain four parts:

What will be done?
What will not be done?
What must remain unchanged?
How will correctness be demonstrated?

12. The codebase is not the whole system

An AI agent may read the entire source code and still fail to understand the complete system.

Codebase ≠ system

The real system is broader:

System =
Code
+ Data
+ Infrastructure
+ Hardware
+ Users
+ Operations
+ Security
+ History
+ Organizational constraints
+ Domain knowledge

This makes the problem of tacit knowledge particularly important in legacy systems.

13. What can artificial intelligence do well?

Current generative AI systems are especially effective in software-development tasks with strong recurring patterns.

Examples include:

• repetitive code generation,
• writing API clients,
• data transformations,
• basic algorithms,
• code explanation,
• documentation generation,
• format conversion,
• test scaffolding,
• identifying candidate defects,
• modernizing old API usage,
• locating relevant parts of a codebase,
• small- and medium-scale refactoring,
• multi-file implementation changes.

14. What can artificial intelligence not do reliably?

It would be inaccurate to answer this question with a permanent list of things AI “cannot do.” Model capabilities change rapidly.

A better approach is to examine reliability.

Possible problems include:

• missing context,
• incorrect assumptions,
• inventing nonexistent APIs or dependencies,
• overlooking edge cases,
• changes that appear locally correct but are globally wrong,
• interpreting the requirement differently from the intended meaning,
• silent behavioral changes.

The primary question should therefore not be:

“Can AI do this?”

but:

“What evidence justifies trusting this output as correct?”

15. As generation becomes easier, verification becomes harder

Before AI-assisted development, implementation was often one of the main bottlenecks.

Agents can now generate changes containing hundreds or thousands of lines within minutes.

A new bottleneck therefore appears:

Old bottleneck:
implementation

New bottleneck:
verification

A change generated by an agent in thirty seconds may require half an hour for an engineer to understand.

16. Testing is no longer only a defect-finding tool

In AI-assisted development, tests have an additional role.

A test is a machine-verifiable expression of intent.

For this reason, tests and evaluation sets are increasingly becoming a form of executable specification for artificial intelligence.

17. The determinism problem

Classical programming relies largely on deterministic structures.

f(x) → y

A generative model, however, performs probabilistic generation.

This creates an interesting engineering situation:

Probabilistic development process
        ↓
Software expected to behave deterministically

As a result, reproducibility, version control, diff review, testing, and traceability become more important.

18. Intent programming in critical systems

An error in a demonstration application and an error in a critical system do not belong to the same risk class.

In critical systems, incorrect behavior can cause:

• data loss,
• service interruption,
• security vulnerabilities,
• legal consequences,
• physical harm.

Therefore, in critical systems:

As risk increases
↓
specification precision should increase
↓
verification should increase
↓
observability should increase
↓
authority boundaries should narrow
↓
human oversight should become stronger

19. Misinterpreting speed in critical systems

The most visible advantage of AI tools is speed.

In software engineering, however, shorter development time is not by itself a measure of success.

A feature may be produced in ten minutes instead of two hours.

But if defect analysis takes two hours, if the change causes production incidents, creates technical debt, or introduces a security vulnerability, the real productivity gain is questionable.

20. The production rate of technical debt has also increased

Artificial intelligence can generate good code quickly.

For the same reason, it can generate bad code quickly.

It is therefore incorrect to treat artificial intelligence directly as a “quality enhancer.”

A more accurate statement is:

Artificial intelligence is a capacity multiplier.

21. Opportunity for junior developers

Artificial intelligence can significantly increase the productivity of a junior developer.

A junior developer can inspect an unfamiliar API, generate example code, ask for an explanation of an error message, compare alternative algorithms, and generate test scenarios.

Used correctly, it can substantially accelerate learning.

22. Risk for junior developers

The same tool can weaken learning when used differently.

If a developer gives instructions without fully understanding the problem, copies the generated code, accepts it when it appears to work, and returns to AI whenever an error occurs, that developer may produce working software while their engineering competence develops much more slowly.

One of the important questions is therefore:

If AI removes the implementation work we previously had to perform in order to become experts, how will new experts be trained?

23. The illusion of competence

With artificial intelligence, a junior developer can produce an architecture document, tests, application code, an API, or SQL within minutes that looks highly professional.

The resulting artifact may appear far more advanced than the person's actual level of knowledge.

Output that looks senior-level
≠
senior-level reasoning

24. The changing role of the senior developer

As AI reduces implementation cost, the reasoning ability of a senior developer may become more valuable.

An experienced engineer often knows from experience which solution should not be implemented, which architectural boundary must be preserved, which optimization is unnecessary, and which defect can have serious production consequences.

25. Skill atrophy for senior developers

The risk is not limited to junior developers.

If a senior developer delegates certain tasks entirely to artificial intelligence for years, they may lose reflexes in areas such as low-level debugging, SQL query analysis, memory behavior, or complex concurrency problems.

A healthy approach is not for artificial intelligence to think instead of the engineer, but to work with the engineer at a higher level of abstraction.

26. Who is a programmer?

A programmer implements algorithms in code, uses data structures, understands programming languages, and fixes defects.

This is also the role most directly affected by artificial intelligence because syntactic generation and repetitive implementation work are among the software tasks most suitable for automation.

27. Who is a software developer?

A software developer does more than write code.

They consider the requirement, implementation, integration, testing, and maintenance of a feature together.

28. Who is a software engineer?

Software engineering is broader than producing code that works.

It aims to make a system reliable, maintainable, scalable, secure, measurable, and changeable.

29. The computer engineer

Computer engineering reminds us that software is not independent of hardware.

Real systems run on processors, memory, caches, storage, networks, input/output devices, and accelerators.

For this reason, in high-traffic and real-time systems, the difference between “working code” and an “appropriate engineering solution” becomes substantial.

30. The computer scientist

The idea that computer science loses its value in the age of artificial intelligence is incorrect.

Computability, complexity, algorithm analysis, graph theory, cryptography, information theory, and distributed algorithms remain fundamental.

AI can produce an O(n²) solution in a few seconds. Understanding why it collapses under millions of records requires computer-science knowledge.

31. Understanding software and writing code are diverging

A person can produce large applications while writing very little code directly.

This raises a question:

Can software be produced without understanding software?

To some extent, yes.

In complex systems, however, recognizing that an AI-generated solution is wrong usually requires sufficient knowledge of the same domain.

To evaluate what AI has done, you must understand that work yourself to a meaningful degree.

32. Lines of code are no longer a productivity metric

An agent can generate ten thousand lines of code in a few minutes.

Those ten thousand lines may create significant value, be unnecessary, or become technical debt.

Productivity should therefore be evaluated through measures such as problems solved, defect rate, production downtime, change failure rate, maintenance cost, performance, and security rather than the amount of generated code.

33. Performance engineering

Artificial intelligence can provide useful performance suggestions.

But an instruction such as “make it faster” is dangerous.

Latency ↔ throughput
Memory ↔ CPU
Consistency ↔ availability
Precomputation ↔ memory
Parallelism ↔ concurrency cost

Performance intent must be measurable.

34. Concurrency

Concurrency is one of the areas that requires particular care in AI-generated code.

Code may compile, pass tests, and work with a single user while still producing a race condition in production.

For critical concurrent behavior, inspecting output alone is therefore insufficient. The invariants that must be preserved should be stated explicitly.

35. Distributed systems

Intent programming becomes even more difficult in distributed systems.

Problems such as network partitions, delayed messages, retries, duplicate requests, ordering, clock skew, and partial failure arise across the system as a whole.

An AI system can satisfy a request to “add retries,” but an incorrect retry policy may cause the same operation to execute twice.

36. Cybersecurity

Artificial intelligence is a powerful assistant in security work.

It can scan code, identify weak patterns, correlate logs, and generate attack scenarios.

Security, however, is an adversarial domain.

The system must therefore also be evaluated under malicious input, while least privilege, attack surface, and trust boundaries are designed explicitly.

37. Digital forensics

Artificial intelligence can make it easier to examine large data sets in digital forensics.

In a forensic process, however, technical correctness is not enough; evidence integrity, traceability, reproducibility, and chain of custody also matter.

A model producing a convincing result does not make that result forensically reliable.

38. The trust problem

A response being fluent, detailed, or technical does not prove that it is correct.

Linguistic confidence ≠ epistemic confidence

In software engineering, the corresponding distinction can be expressed as:

Compiling code ≠ correct code

and

Code that passes tests ≠ a correct system under all conditions

39. Responsibility

Artificial intelligence can generate code.

An agent can modify code.

A system can be deployed automatically.

But when damage occurs in production:

“The model generated it that way.”

is not an engineering justification.

40. Artificial intelligence and legacy systems

One of the most valuable application areas for artificial intelligence may be old and complex codebases.

An agent can locate relevant files, explain call chains, identify old APIs, and suggest change points.

Legacy systems, however, contain more tacit knowledge.

41. Context engineering

One of the most important skills in AI-assisted software development is managing context.

Persistent context

Rules that apply to every task:

• architectural principles,
• coding standards,
• security boundaries,
• general constraints.

On-demand context

Information required only for a particular task:

• specific module documentation,
• data model,
• historical incident records,
• relevant source code.

42. Designing the system that produces software

In AI-assisted development, the engineer's output may increasingly be more than source code.

Specifications
+
Context
+
Agents
+
Tools
+
Tests
+
Quality gates
+
Feedback

This system then produces code.

43. Teams composed of humans and agents

When AI agents are used as semi-autonomous software components that take on specific tasks, team structure may change.

Human
  ↓
Architectural decision and task definition

Agent
  ↓
Implementation

Test system
  ↓
Verification

Agent
  ↓
Correction

Human
  ↓
Final review

44. The fundamental skill of the future is systems thinking

Knowing a specific programming language does not become unimportant.

But by itself, it may no longer be a sufficient differentiator.

A strong engineer of the future will be able to evaluate the following chain as a whole:

Requirement
↓
Domain model
↓
Architecture
↓
Data
↓
Concurrency
↓
Security
↓
Performance
↓
Failure modes
↓
Operations
↓
Observability

45. Will software professions disappear?

It is not possible to provide a reliable number or date.

It is, however, highly plausible that task composition will change.

Work whose relative value may decrease includes:

• repetitive code generation,
• standard CRUD development,
• mechanical transformations,
• simple documentation production.

Work whose relative value may increase includes:

• domain knowledge,
• architecture,
• security,
• performance,
• specification,
• verification,
• systems thinking,
• technical accountability.

46. Will programming knowledge become unnecessary?

The amount of code knowledge required for simple software production may decrease.

As complexity and risk increase, however, the situation changes.

If a system performs financial transactions, processes personal data, carries very high traffic, operates in real time, or controls physical processes, engineering knowledge is required to evaluate the output of the production tool.

47. The philosophical dimension of intent programming

An engineer defines the requirement, designs the architecture, and states the constraints; an agent produces ten thousand lines of code, and the engineer reviews only the critical changes.

Who wrote the program in that case?

The artificial intelligence?

The engineer?

Or the system composed of the human and the artificial intelligence?

Authorship may increasingly approach the question:

Who designed the behavior?

48. The new boundary between human thought and machine production

Previously, most of the translation burden rested on the human:

Think through the algorithm
↓
Write the syntax
↓
Fix the errors

In the new approach, part of that translation is delegated to the model:

Human:
Objective + boundary + reasoning

AI:
Implementation + transformation + repetition

Human:
Verification + responsibility

49. Why might fundamental engineering knowledge become more important?

As abstraction rises, lower-level knowledge may be used less frequently in everyday work while becoming more valuable when it is critical.

A developer may not deal with memory layout every day. But when a production problem is caused by memory pressure, someone must be able to recognize it.

Fundamental knowledge may therefore become less of a mechanical skill used continuously and more of a capacity to break through abstraction and understand the lower layers when necessary.

50. A sound engineering model for intent programming

A practical working model can be organized as follows.

1. Define the problem.
2. Understand the existing system.
3. State the intent.
4. State the constraints.
5. Define the success criteria.
6. Provide the appropriate context.
7. Generate the change.
8. Verify it.
9. Observe production.
10. Feed the resulting knowledge back into the process.

Artificial intelligence then stops being a single “prompt → code” operation and becomes part of a closed-loop engineering system.

51. A concise engineering approach

In intent programming, the boundary between providing enough detail and providing unnecessary detail matters.

A long instruction is not always a good instruction.

The goal is not to tell the model everything, but to tell it the right things.

A good specification should be:

• concise,
• clear,
• internally consistent,
• measurable,
• bounded.

Intent programming is not about saying more.

It is about reducing ambiguity.

52. Conclusion

Every important abstraction layer in the history of programming has changed the way humans communicate with machines.

A new layer is now emerging:

Human
  ↓
Intent
  ↓
Specification
  ↓
Artificial intelligence / agent
  ↓
Source code
  ↓
Compiler / runtime
  ↓
Machine

This transformation is not the end of programming.

It is the next abstraction layer of programming.

As abstraction rises, engineering does not become unnecessary.

As generating code becomes easier, generating incorrect code also becomes easier.

As the volume of change grows, verification becomes harder.

As implementation details become less visible, the value of people who understand fundamental system behavior increases.

The most important distinction of the future may therefore not be between developers who use AI and those who do not.

A more meaningful distinction is between:

a person who can generate code with artificial intelligence

and

an engineer who can design, constrain, and verify a reliable system through artificial intelligence.

For programmers, code was the center for a long time.

In intent programming, the center is increasingly the definition of correct behavior.

Code still matters.

But code is no longer always the starting point.

Sometimes it is only an intermediate representation, generated by a machine from a well-expressed engineering idea.