DEV Community: Jose Abreu

The More I Use AI to Code, the More Engineering Judgment Matters

Jose Abreu — Tue, 03 Nov 2026 14:49:08 +0000

AI is changing the pace at which I can explore ideas and build software.

Working with PHP, APIs, databases, and data platforms, I see opportunities to use AI throughout development: understanding an unfamiliar part of a codebase, comparing approaches, working through an implementation, and finding questions I might otherwise overlook.

Tools such as Junie, Codex, and Claude are part of that shift for me. There is real value in being able to move between an idea and a possible implementation more quickly.

That increased capacity also changes where I need to focus my attention.

The more capable these tools become, the more carefully I need to apply my own engineering judgment. I still need to understand the code, the business rules behind it, and the consequences of putting it into production.

Where “vibe coding” fits

For me, the appeal of “vibe coding” is the short loop between describing an idea, seeing something take shape, and refining it.

That can be useful for exploring an interface, trying a different approach, or getting an early prototype in front of you. It creates room to experiment.

As that work moves toward something customers and colleagues will depend on, the questions become more demanding.

How does it fit into the existing application? Which assumptions did the model make? What happens when the input is incomplete, access is denied, or a dependency fails? Can another developer understand and maintain the result?

A successful demonstration is an encouraging milestone. Production software needs a deeper understanding of its behavior.

For me, staying true to the craft means carrying that understanding through the entire process.

Experience gives the partnership direction

Years of development experience shape the questions we know to ask.

When I look at a generated implementation, I need to consider more than whether the syntax looks familiar. I need to connect it to the system around it.

For example:

Does it implement the actual business rule?
Does it preserve the meaning of existing data?
Does it respect the application’s access rules?
Will it behave reasonably with realistic data volumes?
Does it handle errors in a way the rest of the application understands?
Can I explain why this approach belongs in this codebase?

Those questions are part of the value an experienced developer brings to AI-assisted work.

GitHub’s responsible-use guidance for Copilot acknowledges that generated code can appear valid while being incorrect or failing to reflect the developer’s intent. It recommends reviewing and testing suggestions, including their security implications and fit within the application.

My experience helps me give the tool better direction and recognize when an answer needs further investigation. It also reminds me to challenge my own assumptions.

Greater speed calls for more deliberate review

When code arrives quickly, there is a temptation to review it at the same pace.

That is where I think our attention to detail needs to become more refined.

Consider a PHP search endpoint generated with AI assistance. It uses prepared statements and returns the expected results for a sample search.

I would still want to inspect how the complete query is constructed.

PHP’s PDO documentation explains that placeholders represent data values. They cannot represent column names, SQL keywords, or arbitrary parts of a query. If the endpoint lets a user choose a sort column or direction, I would use a fixed mapping of supported options and inspect how those options become SQL.

I would also ask a separate question: Is this user allowed to see the records being returned?

A user being logged in does not establish permission to access every record. OWASP’s authorization guidance distinguishes identity verification from access decisions and recommends checking permissions on every request, including access to the specific resource involved.

This is the kind of detail that matters when reviewing an implementation. Query construction, access control, and business correctness each need attention.

The same care applies to generated tests. I need to review what they establish. A test built around the same mistaken assumption as the implementation can pass while the requirement remains unmet.

What a useful human–AI partnership looks like

The partnership works best when I bring clear context and remain engaged throughout the work.

The standard I want to maintain is straightforward:

Define the intended behavior. Describe the requirement, important constraints, and what a correct result should look like.
Provide relevant context. Include the project’s PHP and framework versions, existing conventions, and the parts of the application the change touches.
Work in focused changes. Keep each proposed change small enough to understand and review.
Examine the assumptions. Ask why an approach was chosen and what could cause it to fail.
Verify the result. Inspect the actual changes and check meaningful behavior against the original requirement.

A useful instruction to an assistant might be:

Before changing this endpoint, explain its current behavior and the assumptions you are making. Use the versions declared by this project. Preserve the required access rules and response format. Propose a focused change and identify cases we should verify, including empty results, invalid input, and denied access.

That gives the collaboration a clearer purpose.

AI can help propose implementations, explain alternatives, and identify possible gaps. I need to make the acceptance decision based on the code and its observed behavior.

If I ship it, I need to be able to explain it, debug it, and maintain it.

PHP security remains part of the craft

Keeping up with AI tools also means staying current with the technology underneath the application.

For PHP work, that includes the runtime, extensions, framework, Composer dependencies, and our own application logic.

As of November 3, 2026, PHP 8.4 and 8.5 are in active support, while PHP 8.2 and 8.3 receive security fixes only. PHP 8.2 reaches the end of security support on December 31, 2026. The official PHP supported-versions page is a useful reference when planning maintenance and upgrades.

Staying current means following security releases for a supported branch and assessing compatibility before moving an application forward. PHP’s 8.5 migration guide, for example, calls out incompatibilities that should be tested before switching production environments.

For a Composer-based project, two useful checks are:

composer audit --locked
composer check-platform-reqs

The first audits the packages recorded in the lock file against known security advisories and other dependency policies. The second checks whether the actual PHP and extension versions satisfy the requirements of installed packages. Both are documented in the Composer command reference.

These checks answer specific questions. Application behavior, authorization, and business logic still need their own review and testing.

An AI assistant can help interpret an advisory or work through a migration. I still need to verify the recommendation against current documentation and the application’s actual environment.

Keeping up at a faster pace

There is a growing amount to follow: AI tools, language releases, framework changes, database capabilities, and new development approaches.

I want that learning to feed back into better engineering decisions.

The learning process I want to keep strengthening has four parts:

Start with a real question.

What am I trying to improve—understanding an older codebase, reviewing changes, reducing repetitive work, or solving a specific application problem? A clear question gives new tools something useful to prove.

Use AI to accelerate understanding.

An assistant can help me work through unfamiliar terminology, compare approaches, or identify questions to investigate. When a decision depends on a specific capability or behavior, I want to check the original documentation.

Try the idea on a manageable problem.

A small experiment gives me something concrete to inspect. I can judge the quality of the result, the effort needed to review it, and how well it fits the existing system.

Carry useful lessons back into the work.

The knowledge becomes more valuable when it improves documentation, code reviews, shared conventions, or the next implementation.

That is how I want to grow alongside these tools: remain curious, experiment deliberately, and keep strengthening the fundamentals that let me evaluate what I am seeing.

The responsibility grows with the capability

I am excited about what AI-assisted development makes possible.

It gives experienced developers more room to explore ideas, work through difficult problems, and expand what we can accomplish. Making good use of that capacity requires active participation.

Our judgment, technical understanding, and care for the finished result need to grow alongside the tools.

For me, staying true to the craft means being able to stand behind the work—even when AI helped produce it.

Which parts of your development process have become more important as you have started using AI? Have you changed how you review code, test behavior, or keep up with security updates?

This article was drafted with AI assistance. Technical documentation is linked throughout.

Moving from MySQL to PostgreSQL: Building Flexible Search for the Next Phase of AI

Jose Abreu — Tue, 03 Nov 2026 14:05:21 +0000

I’ve spent a large part of my career working with PHP and MySQL, building applications, maintaining databases, developing APIs, and managing the processes that keep data platforms running.

That experience has taught me to pay attention to the connection between database design and the experience a customer has on the screen.

At AccuPoint Solutions, we’re transitioning from MySQL to PostgreSQL as we build the next phase of our intelligence platform. A major part of that work is supporting more flexible customer searches, more complex queries, and faster loading times.

The migration is also giving me an opportunity to think more carefully about the database foundation we need for AI-assisted search.

These are some of the capabilities and design questions that stand out to me as we move forward.

A flexible search tool creates many different workloads

A customer-facing search platform has to support a wide range of questions.

One customer might begin with geography and professional credentials. Another might start with firm characteristics. Someone else might combine those conditions, exclude certain records, add a date range, and choose a different sort order.

An illustrative search might be:

Find professionals licensed in selected states, with a business email available, whose firms match a particular set of characteristics.

That request can involve multiple tables, optional filters, inclusion and exclusion rules, sorting, and pagination.

A small change in the customer’s criteria can produce a very different query.

This is where the engineering challenge becomes interesting: how do we keep the experience responsive across the combinations customers actually use?

I want to evaluate the searches that return a few records, the searches that match a large audience, and the more complicated combinations that are easy to overlook during development.

The PostgreSQL capabilities that interest me

What attracts me to PostgreSQL is the range of tools available for matching the database design to different kinds of searches.

Here are several areas I’m paying attention to:

Search requirement

PostgreSQL capability worth evaluating

Customers combine several optional filters

Bitmap index scans that can combine index results with AND and OR

Searches repeatedly target a particular subset of records

Partial indexes defined by a condition

Customers search text in different ways

Full-text search, GIN indexes, and the pg_trgm extension

Some attributes are less uniform or change over time

JSONB and its indexing options

Multiple filters describe related attributes

Extended statistics to help the planner understand certain column relationships

MySQL has useful capabilities in these areas too. Its Index Merge optimization can combine index scans, and its functional indexes can index expression results.

For me, the useful comparison is how each database handles our particular data, queries, and application requirements.

Partial indexes offer a more targeted approach

A PostgreSQL partial index includes only records that satisfy a defined condition.

For example, here is an illustrative index for searches that repeatedly target active professionals:

CREATE INDEX professionals_active_state_name_idx ON professionals (state, last_name, id) WHERE is_active = true;

A compatible search could look like this:

SELECT id, first_name, last_name FROM professionals WHERE is_active = true AND state = 'NJ' ORDER BY last_name, id LIMIT 50;

This creates an index focused on the active subset. Its usefulness depends on that subset’s size, the query pattern, and the planner’s choices.

The planner also needs to establish that the query satisfies the index condition. Parameterized predicates can complicate that recognition.

For a configurable search builder, that makes the relationship between generated SQL and index design especially important.

Reference: PostgreSQL partial indexes.

Different text searches need different approaches

A platform may need several kinds of text matching:

An exact identifier lookup.
A search for words in a description.
A partial firm name.
A similarity search that can accommodate some spelling differences.

PostgreSQL provides full-text search, with GIN as its preferred index type for that workload. The pg_trgm extension provides another set of tools for text similarity and indexed pattern searches, including LIKE and ILIKE.

Those tools address different matching requirements. A name search and a document search deserve their own relevance and performance checks.

Trigram indexing also has limits: patterns without extractable trigrams can require a full-index scan. The actual search terms matter.

MySQL also supports full-text search. The opportunity I see in PostgreSQL is having additional approaches to evaluate within the relational platform.

References: PostgreSQL full-text indexes, pg_trgm, and MySQL full-text search.

Flexible attributes still need deliberate data modeling

JSONB is another PostgreSQL feature that interests me for evolving metadata or attributes that do not fit one uniform structure.

PostgreSQL supports GIN indexing for several JSONB containment, existence, and path operations. MySQL also has a native JSON type and indexing approaches for extracted values and arrays.

My preference is to keep core identifiers, relationships, and frequently searched fields clearly modeled, then use flexible structures where they solve a specific problem.

The question is where each attribute belongs and how customers need to query it.

References: PostgreSQL JSONB indexing and MySQL JSON.

Query plans matter as much as the feature list

Flexible search makes execution plans especially useful.

In PostgreSQL, EXPLAIN (ANALYZE, BUFFERS) helps examine actual execution behavior, including row estimates, rows processed, and buffer activity. ANALYZE executes the query, so I would use it deliberately with representative searches.

MySQL also provides EXPLAIN ANALYZE. The habit of inspecting execution plans carries across the migration.

Some questions I want those plans to answer are:

How much data is examined before the first results are returned?\
Are row estimates reasonably close to the actual result?
Which joins, filters, and sorts account for the work?
Does a small change in the search criteria produce a significantly different plan?

There are useful details to watch. PostgreSQL’s bitmap index combination loses the indexes’ original ordering, so a query may still need an additional sort.

Related filters deserve attention too. Geography fields, for example, can be correlated. PostgreSQL’s extended statistics can help with certain relationships between columns, although they need to be chosen and maintained for the relevant workload.

References: PostgreSQL EXPLAIN, combining indexes, planner statistics, and MySQL EXPLAIN.

Faster loading needs to be measured across the application

Customers experience the time between submitting a search and being able to use the results.

That includes database execution, application processing, response size, network delivery, and browser rendering.

For this migration, I want the evaluation to cover:

Common searches and difficult combinations.
Broad results and highly selective results.
First-page results, pagination, and full exports.
Exact result counts and any supporting queries.
Multiple customers searching at the same time.
Search performance while data updates are running.

A quick first-page query can still leave the customer waiting if the endpoint also performs an expensive count or loads unnecessary data.

Pagination deserves its own design decisions. Cursor-based pagination is worth evaluating for next-page navigation with a stable sort order. Interfaces that require arbitrary page jumps have different requirements.

I would also compare median and 95th-percentile response times under representative load. The slower end of the experience matters when customers can build many different searches.

The goal is consistent, useful performance across the workload.

The AI direction makes a reliable search foundation more important

As we build the next phase of the platform, I’m thinking about how customers can express what they want in more natural language.

That increases the importance of a well-defined search model.

A design principle I want to carry forward is:

Interpret the customer’s request.
Translate it into supported fields, operators, and values.
Validate the search against the customer’s permissions.
Build a parameterized query through the application’s search layer.
Return results with criteria the customer can understand and refine.

This gives AI-assisted search a clear connection to the existing search experience.

Semantic similarity is another possibility to evaluate. The optional pgvector extension adds vector similarity search to PostgreSQL, including exact search and approximate indexes such as HNSW and IVFFlat.

Approximate search trades some recall for speed. Combining it with restrictive filters needs testing because filtering can reduce the number of qualifying results returned.

For a business data platform, similarity still needs to work alongside exact criteria and access controls.

Natural-language filter building and vector similarity solve different problems. I want to choose each based on the customer’s task.

What I want to learn from the migration

The move to PostgreSQL is an opportunity to review our query construction, indexing strategy, data model, and application behavior together.

Result correctness is part of that work. Search behavior, sorting, case handling, dates, and null values all need careful validation across the transition.

I also want to understand the operational tradeoffs: index storage, update costs, statistics maintenance, and how the platform behaves as the data changes.

MySQL has been a substantial part of my engineering background. Working with PostgreSQL is expanding the set of approaches I can consider as our search requirements evolve.

The outcome I’m working toward is a platform where customers can ask more varied questions, receive dependable results, and benefit from AI features built on a reliable data foundation.

If you’ve migrated a platform with flexible customer searches, which changes made the biggest difference: the data model, indexes, query construction, or pagination?

Hi, I’m Jose: Lessons from Building PHP Applications and Data Platforms

Jose Abreu — Tue, 03 Nov 2026 12:59:13 +0000

Hi everyone, I’m Jose Abreu, Director of Engineering at AccuPoint Solutions.

I’ve spent more than a decade working across PHP development, MySQL databases, APIs, automation, and the systems that keep business applications running. My work also involves Laravel, JavaScript, Python, Google Cloud, and, increasingly, AI-assisted development.

I’m joining DEV to share practical lessons from that work and learn how other developers approach similar challenges.

Here are a few principles I keep coming back to.

Understand the workload before optimizing

Working with large datasets has made me pay close attention to how an application accesses its data.

Before changing a slow query, I want to understand the filters, joins, indexes, and amount of data being processed. I also want to know how often the query runs and what the user actually needs from the result.

My starting point is to examine the execution plan, check the results for correctness, and measure changes against a representative workload. Those habits are useful long before a database becomes especially large.

Make automated processes easy to understand

Data imports and background jobs deserve the same attention as the features users see.

For a data update, I care about questions such as:

Did the expected records arrive?

Were invalid or duplicate records handled?

Can I tell which step failed?

Can the process recover without creating inconsistent data?

Clear logging, validation, and recovery behavior make these systems much easier to maintain.

Learn the existing behavior before modernizing

Maintaining established applications teaches you how much business knowledge can live inside code.

Before changing a system, I want to understand the workflows people depend on, the integrations involved, and the assumptions behind its behavior.

That understanding helps me choose useful, manageable improvements. It also gives me a better basis for checking that a modernization effort preserves the things users rely on.

Bring engineering judgment into AI-assisted development

I’ve been using tools such as Claude, Codex, and PHPStorm Junie as part of my development work.

I’m interested in how they can help with understanding code, exploring implementation options, refactoring, and application modernization.

Review remains a central part of that process. I want to understand the generated code, check its assumptions, and verify how it behaves with real application requirements. Database access, permissions, error handling, and edge cases all deserve attention.

What I’d like to share here

I plan to write about PHP and Laravel development, MySQL performance, data pipelines, API integrations, cloud applications, and practical uses of AI in development.

I’m especially interested in the everyday decisions that make software easier to operate and maintain over time.

What is one lesson from maintaining production applications that changed how you approach development?